| Internet-Draft | POWEFF | October 2023 |
| Lindblad, et al. | Expires 22 April 2024 | [Page] |
This document motivates and specifies a data model to report power and energy efficiency of an asset. As highlighted during the IAB workshop on environmental impacts, visibility is a very important first step (paraphrasing Peter Drucker's mantra of "You cannot improve what you don't measure"). During the workshop the need for standardized metrics was established, to avoid proprietary, double counting and even contradictory metrics across vendors.¶
This Power and Energy Efficiency Telemetry Specification (POWEFF) is required to promote consistency across vendors and consumers, based on: 1. The definition of datasets and attributes defining a common data model utilized by the standard calculation to yield power and energy efficiency value for any asset or network element. 2. The standard calculations utilizing the specified datasets and attributes which will yield energy consumption and energy efficiency value for any asset or network element.¶
The model provides information and data requirements for calculating the Power and Energy Efficiency for specific assets. Assets can include hardware (physical or virtual), software, applications, or services.¶
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 22 April 2024.¶
Copyright (c) 2023 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.¶
The ability to speak a common language of how to measure power consumption, and how to use those measurements in calculations to derive meaningful data is an important business objective and central to developing customer insights. Today, vendors work independently to create methods of measurement and algorithms to calculate similar, yet inconsistent common data elements. When different business entities, responsible for developing multiple products and solutions, do not coordinate efforts, varying results causes confusion to downstream consumers of the data.¶
The Power and Energy Efficiency Telemetry Specification seeks to address this inconsistency by providing a single reference for these important activities, aiming to create value through insights.¶
POWEFF is considered a first phase of the Sustainability Telemetry Specification, as defined in the Sustainability Insights [I-D.draft-almprs-sustainability-insights-02] IETF draft.¶
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.¶
Terminology and abbreviations used in this document:¶
Refers to hardware, software, applications, or services. An asset can be physical or virtual, as defined in the Asset Lifecycle Management and Operations [I-D.draft-palmero-ivy-ps-almo-00] IETF draft.¶
Emissions directly caused by actions of the organization, such as when fossil fuels are burned when the organization is operating a fossil vehicle. See Greenhouse Gas protocol.¶
Emissions indirectly caused by actions of the organization, but under control of the organization. For example, when electric energy is purchased, causing a provider utility to make emissions on behalf of the organization. See Greenhouse Gas protocol.¶
Emissions the organization indirectly causes others to make, but outside the organizations direct control. Examples include the energy customers consume when operating the organization's products, or when employees commute to work at the organization. See Greenhouse Gas protocol.¶
Scope 4 :¶
Refers to the term used in Greenhouse Gas (GHG) accounting and reporting to describe emissions that occur as a result of an organization's value chain activities, but are not directly controlled or owned by the organization. Scope 4 emissions are considered indirect emissions and are typically associated with activities that are upstream or downstream from a organization's operations. Such as when equipment provided by the organization enables a video conference, without which greater emissions from business travel would have happened.¶
Carbon dioxide equivalents, a measure of the disruptive force of greenhouse gas emissions.¶
Refers to the electrical energy per unit time, supplied to operate an asset, such as a smartphone. It is usually measured in units of watts.¶
refers to the ability of an asset to perform its intended functions while minimizing energy consumption. It refers to the ratio between the useful output energy and input energy given by an asset. In a router or a switch, it is a measure of how efficiently the network element utilizes energy resources to transmit and process data or perform other network-related tasks. See Energy efficiency wikipedia.¶
The main objective of POWEFF is to measure and report power and energy related metrics and provide the necessary insights to improve the overall CO2eq emission for use cases of which the asset contributes during its use. Following product Lifecycle Accounting (LCA), POWEFF focuses on the Use stage defined by the GHG Protocol Accounting and Reporting Standard, which is in accordance with the ISO 14040:44 standards. It includes emissions from the use of goods and services sold by the reporting organization or vendor in the reporting year. A vendor’s Scope 3 emissions from use of sold products include the scope 1 and scope 2 emissions of end users. End users include both consumers and business customers that use final assets. It is important to note that Scope 3 category 11, reports around 75% of the total Scopes 1, 2 and 3 reported by a given asset. See Cisco ESG Reporting Hub.¶
Power and energy consumption Telemetry data available for different infrastructure vendors today is characterized by inconsistency and best effort:¶
Availability of primary data. Data is often only available on a case by case basis.¶
Varying APIs. Where Telemetry might be available, access methods, data contents and formats are specific to platforms or elements.¶
Limitations. Some useful or essential data items are never collected by the relevant hardware or software.¶
Precision. Data often contains significant margins of error, both from random noise and systematic errors.¶
Varying definitions. Calculated values use differing inputs and algorithms, limiting the value of any possible comparison and aggregation.¶
Formulate a Power and Energy Efficiency Telemetry Specification to promote consistency:¶
Definition of datasets and attributes that will define a common data model to report power and energy consumption on hardware and software assets¶
Define a standardized calculation utilizing the specified datasets and attributes which will yield an energy consumption value for any asset.¶
Implementing any Sustainability Solution at scale for customers with a broad range of equipment requires at minimum consistently available Power Consumption/Energy Efficiency Telemetry. Telemetry standardization will benefit numerous stakeholders, including Corporate Social Responsibility (CSR), who have a need for Power Consumption Telemetry data for a variety of needs.¶
Monitoring power and energy efficiency based on common metrics.¶
Enhance reporting and provide a comprehensive overview for potentially improving power usage during the operational phase.¶
Consumption per device, e.g. wireless environment.¶
Capabilities to optimize energy consumption when assets are not in use, e.g. idle and allocated power.¶
Hardware Lifecycle. Circular economy enables to restore product value at the end of life, there are several options, reuse, remanufacturing, recycling, repurpose, etc.¶
More elaborate use cases, e.g. define carbon footprint for network's usage, might also be derived from POWEFF model, even discussion and common understanding will be required.¶
The broad metric classes defined in previous sections that quantify power and energy efficiency can be modeled as shown in the information POWEFF model below (Figure 1). There is an inventory of all assets that the user or vendor possesses. The representation proposes an extension of the inventory module, and include attributes that provide insight to energy efficiency. Attributes defined as "role" of an asset or "location" of a network equipment are meaningful to compute energy efficiency and CO2eq footprint. Each asset will have attributes that determines power usage measured in a controlled environment, and energy consumption measured in production, this includes metrics related to the data traffic being processed by that particular asset. Based on those runtime and static measurements, power and energy metrics will be deduced.¶
For example, when a user needs to measure the power utilization of a specific type of asset, the power information might be retrieved from a database. The asset state (active or not) will determine the energy consumption. As different assets (modules or components) might be part of a specific chassis, they are aggregated to provide power related information as per the information model shown below (Figure 1).¶
+---------------------+
| ietf-poweff-derived |
+--------+------------+
|
+----------------+----------------+
v | v
+------------+-------+ | +--------+------------+
| ietf-poweff-static | | | ietf-poweff-traffic |
+------------+-------+ | +------------+--------+
| v |
| +--------------+----------+ |
| | ietf-poweff-environment | |
| +--------------+----------+ |
| | |
+--------------------+----------------+
v
+-----------------------+
| ietf-poweff-asset-ext |
+-----------------------+
The functional block that refers to poweff-derived, contains the logic to compute power consumed and energy efficiency by the specific assets, as well as the units of measurement.¶
From a simplification of the diagram, poweff-types and poweff-sensors have been excluded. They should be linked to poweff-environment, for the runtime measurements and to poweff-static, covering measurements given by the manufacturer. They described the sensor types, units of measurements and other meaningful caracteristics of sensors.¶
Describes and extends asset to cover sustainability use cases. Aligned with the network inventory, asset refers to hardware, software, applications, or services. An asset can be physical or virtual. This model provides the extension grafting point on top of an inventory model.¶
Evaluating systems should include benchmarks that can be standardized as well as network-specific configurations which may include multiple generations of hardware, a partially filled chassis, or different traffic loads. These data normally corresponds to values provided by the manufacturer.¶
Data for a specific asset that aligns to values provided by the manufacturer can be classified as “static” since they are unlikely to change.¶
It is important to note that those values have been measured under certain conditions, including benchmarks that can be standardized, and network-specific configurations that may include multiple generations of hardware, a partially filled chassis, or different traffic loads.¶
Each chassis is typically benchmarked for Idle, Typical=Operating, and Maximum capacity that might consist of temperature, hardware load, traffic, fans, CPU, memory, etc. For example, a particular chassis is rated to function in a 27C(Typical), 40C(Operating), and 55C(Max) temperature environment. Note that environmental temperature will not be the only required parameter required to retrieve relevant static data for an asset.¶
Describes the runtime values from the assets related to power environment; comprising of reading Voltage, Current, Power (Watts), Temperature, etc.¶
Describes the real-time interface and traffic reading from the asset. This module might overlap with current YANG standards implemented at the network device level, but this module offers a level of abstraction to do not only cover networking equipment and a common data module is proposed for consistency, which might map 1:1 to current standards.¶
Considers kpi's and metrics computed by an analytics engine, that typically the values provided will be calculated on the collector, even they could be also implemented by the asset.¶
Defines basic groupings for POWEFF sensor management¶
Defines basic quantities, measurement units and sensor types for the POWEFF framework¶
Includes common attributes to extend sustainability related use cases as defined in Sustainability Insights [I-D.draft-almprs-sustainability-insights-02] IETF draft. , i.e., carbon intensity factor, cost per kwh, etc.¶
<CODE BEGINS>
module ietf-poweff-asset-ext {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-poweff-asset-ext";
prefix ietf-poweff-asset-ext;
import ietf-lmo {
prefix ietf-lmo;
}
import ietf-lmo-assets {
prefix ietf-lmo-asset;
}
organization
"IETF OPSA (Operations and Management Area) Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/opsawg/>
WG List: <mailto:opsawg@ietf.org>
Editor: Jan Lindblad
<mailto:jlindbla@cisco.com>
Editor: Snezana Mitrovic
<mailto:snmitrov@cisco.com>
Editor: Marisol Palmero
<mailto:mpalmero@cisco.com>";
description
"This YANG module includes extra attributes which
complement sustainability for assets.
Copyright (c) 2021 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to
the license terms contained in, the Simplified BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
for full legal notices.";
revision 2023-10-12 {
description
"Initial revision to complement Asset Inventory Module as
part of the DMALMO YANG Model, with sustainability attributes";
reference
"RFC XXXX: DMALMO YANG Model";
}
augment /ietf-lmo:lmos/ietf-lmo:lmo/ietf-lmo:inst {
when "derived-from-or-self(../ietf-lmo:lmo-class, "+
" 'ietf-lmo-asset:asset')";
description
"Assets attributes related to sustainability";
leaf age {
type string;
description
"Age of the asset";
}
leaf site {
when "not(../ietf-lmo:parent/ietf-lmo:id)";
type string;
description
"location site name";
// FIXME: Make this a reference to a list of sites?
// FIXME: force this to be set for all assets that
// do not have a parent?
}
leaf modular {
type boolean;
description
"The asset is or is not modular";
}
leaf status {
type string;
description
"NEED to include: off, enabled, disabled, not present,
failed, reserved-on, standby";
//FIXME status is simply the most inconsistent field
//with wide variety of values reported. It is better
//to make this a Enum with fixed set list of states.
}
leaf slot {
type string;
mandatory "true";
description
"Defines the slot where the asset is placed in the chasssis.
Used to map the sensor to particular UID.";
}
leaf device-family {
type string;
description
"Device Family - may be derived from the product name or
product id. It is to be used for immplementation
purpose - filtering capability and future optimization
purposes";
}
}
}
<CODE ENDS>¶
<CODE BEGINS>
module ietf-poweff-environment {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-poweff-environment";
prefix ietf-poweff-environment;
import ietf-poweff-sensors {
prefix ietf-poweff-sensors;
}
import ietf-lmo {
prefix ietf-lmo;
}
import ietf-lmo-assets-inventory {
prefix ietf-lmo-asset;
}
organization
"IETF OPSA (Operations and Management Area) Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/opsawg/>
WG List: <mailto:opsawg@ietf.org>
Editor: Jan Lindblad
<mailto:jlindbla@cisco.com>
Editor: Snezana Mitrovic
<mailto:snmitrov@cisco.com>
Editor: Marisol Palmero
<mailto:mpalmero@cisco.com>";
description
"This YANG module includes the live reading from the network
devices related to the power environment. Dynamic/real-time
data read from the network device, basically reading Voltage,
Current, Power (Watts), and Temperature.
Copyright (c) 2021 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to
the license terms contained in, the Simplified BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
for full legal notices.";
revision 2023-10-12 {
description
"Initial revision to document power environmental related data";
reference
"RFC XXXX: ...";
}
augment /ietf-lmo:lmos/ietf-lmo:lmo/ietf-lmo:inst {
when "derived-from-or-self(../ietf-lmo:lmo-class, "+
" 'ietf-lmo-asset:asset')";
description
"Assets attributes related to power environment";
uses ietf-poweff-sensors:sensors-g;
}
}
<CODE ENDS>¶
<CODE BEGINS>
module ietf-poweff-static {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-poweff-static";
prefix ietf-poweff-static;
import ietf-poweff-sensors {
prefix ietf-poweff-sensors;
}
import ietf-lmo {
prefix ietf-lmo;
}
import ietf-lmo-assets-inventory {
prefix ietf-lmo-asset;
}
organization
"IETF OPSA (Operations and Management Area) Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/opsawg/>
WG List: <mailto:opsawg@ietf.org>
Editor: Jan Lindblad
<mailto:jlindbla@cisco.com>
Editor: Snezana Mitrovic
<mailto:snmitrov@cisco.com>
Editor: Marisol Palmero
<mailto:mpalmero@cisco.com> ";
description
"This YANG module includes power and energy efficiency
Product Data. Data for a specific asset that aligns to values
provided by the manufacturer can be classified as “static”
since they are unlikely to change during the lifetime of the
product/asset.
They are typically available in a form of data sheets or any kind
of simulation tools.
Copyright (c) 2021 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to
the license terms contained in, the Simplified BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
for full legal notices.";
revision 2023-10-12 {
description
"Initial revision to document power static data";
reference
"RFC XXXX: ...";
}
augment /ietf-lmo:lmos/ietf-lmo:lmo/ietf-lmo:inst {
when "derived-from-or-self(../ietf-lmo:lmo-class, "+
" 'ietf-lmo-asset:asset')";
description
"Assets attributes related to power static attributes";
uses ietf-poweff-sensors:power-static-g;
}
}
<CODE ENDS>¶
<CODE BEGINS>
module ietf-poweff-traffic {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-poweff-traffic";
prefix ietf-poweff-traffic;
import ietf-yang-types {
prefix yang;
}
import ietf-interfaces {
prefix if;
}
import ietf-lmo-assets-inventory {
prefix ietf-lmo-asset;
}
import ietf-lmo {
prefix ietf-lmo;
}
organization
"IETF OPSA (Operations and Management Area) Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/opsawg/>
WG List: <mailto:opsawg@ietf.org>
Editor: Jan Lindblad
<mailto:jlindbla@cisco.com>
Editor: Snezana Mitrovic
<mailto:snmitrov@cisco.com>
Editor: Marisol Palmero
<mailto:mpalmero@cisco.com>";
description
"This YANG module describes the live interface and traffic related
metrics. It should be based on rfc7223,
https://datatracker.ietf.org/doc/rfc7223/
Copyright (c) 2021 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to
the license terms contained in, the Simplified BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
for full legal notices.
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 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here.
";
revision 2023-10-12 {
description
"Initial revision to document power traffic data";
reference
"RFC XXXX: ...";
}
augment /ietf-lmo:lmos/ietf-lmo:lmo/ietf-lmo:inst {
when "derived-from-or-self(../ietf-lmo:lmo-class, "+
" 'ietf-lmo-asset:asset')";
description
"Traffic attributes related to sustainability";
container interfaces {
description "Interface parameters";
list interface {
key "name";
leaf name {
type leafref {
path "/if:interfaces/if:interface/if:name";
require-instance false;
}
description
"The name of the interface.";
}
leaf description {
type string;
description
"A textual description of the interface.
A server implementation MAY map this leaf to the ifAlias
MIB object. Such an implementation needs to use some
mechanism to handle the differences in size and characters
allowed between this leaf and ifAlias. The definition of
such a mechanism is outside the scope of this document.
Since ifAlias is defined to be stored in non-volatile
storage, the MIB implementation MUST map ifAlias to the
value of 'description' in the persistently stored
configuration.";
reference
"RFC 2863: The Interfaces Group MIB - ifAlias";
}
leaf if-index {
type int32;
description
"The ifIndex value for the ifEntry represented by this
interface";
reference
"RFC 2863: The Interfaces Group MIB - ifIndex";
}
leaf interface-type {
type string;
//TO_DO adjust type to identy interface-type or similar
description
"The type of the interface.
When an interface entry is created, a server MAY
initialize the type leaf with a valid value, e.g., if it
is possible to derive the type from the name of the
interface.
If a client tries to set the type of an interface to a
value that can never be used by the system, e.g., if the
type is not supported or if the type does not match the
name of the interface, the server MUST reject the request.
A NETCONF server MUST reply with an rpc-error with the
error-tag 'invalid-value' in this case.";
reference
"RFC 2863: The Interfaces Group MIB - ifType";
}
leaf bandwidth {
type yang:gauge64;
units "kbits/s";
description
"It is considered to be the Max bandwidth of the interface,
in kbps, it could also be called capacity";
}
leaf speed {
type yang:gauge64;
units "kbits/s";
description
"It is considered to be current bandwidth of the interface,
in kbps, it could also be called capacity";
}
leaf data-rate-frequency {
type string;
//TO_DO normalized to do not be string, as different devices
//will provide different implementation
description
"The length of time for which data is used to compute load
statistics, load-interval command in interface
configuration. Default value is 5min";
}
container statistics {
description "A collection of interface-related statistics
objects.";
leaf input-data-rate {
type uint64;
units "kbits/s";
mandatory "true";
description
"Input data rate in 1000's of bps. Average number of bits
received per second in the last load period
(300 sec by default)";
}
leaf input-packet-rate {
type uint64;
units "packet/s";
description
"Input packets per second. Average number of packets
received per second in the last load period
(300 sec by default)";
}
leaf output-data-rate {
type uint64;
units "kbits/s";
mandatory "true";
description
"Output data rate in 1000's of bps. Average number of bits
sent per second in the last load period
(300 sec by default)";
}
leaf output-packet-rate {
type uint64;
units "packet/s";
description
"Output packets per second. Average number of packets
sent per second in the last load period
(300 sec by default)";
}
}
description "Interface parameters for a specific interface";
}
}
}
}
<CODE ENDS>¶
<CODE BEGINS>
module ietf-poweff-derived {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-poweff-derived";
prefix ietf-poweff-derived;
import ietf-poweff-sensors {
prefix ietf-poweff-sensors;
}
import ietf-lmo {
prefix ietf-lmo;
}
import ietf-lmo-assets-inventory {
prefix ietf-lmo-asset;
}
organization
"IETF OPSA (Operations and Management Area) Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/opsawg/>
WG List: <mailto:opsawg@ietf.org>
Editor: Jan Lindblad
<mailto:jlindbla@cisco.com>
Editor: Snezana Mitrovic
<mailto:snmitrov@cisco.com>
Editor: Marisol Palmero
<mailto:mpalmero@cisco.com>";
description
"This YANG module includes power derived values per asset.
Typically, power derived values will be calculated on the
receiver, even those values may be provided by the devices as
well.
Typically we expect chassis to report total psu-input-power and
psu-output-power but ptr-bps-ratio may be derived on the receiver
side.
Copyright (c) 2021 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to
the license terms contained in, the Simplified BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
for full legal notices.";
revision 2023-10-12 {
description
"Initial revision to document power derived data";
reference
"RFC XXXX: ...";
}
augment /ietf-lmo:lmos/ietf-lmo:lmo/ietf-lmo:inst {
when "derived-from-or-self(../ietf-lmo:lmo-class, "+
" 'ietf-lmo-asset:asset')";
description
"Power derived attributes related to assets";
uses ietf-poweff-sensors:power-derived-g;
}
}
<CODE ENDS>¶
<CODE BEGINS>
module ietf-poweff-sensors {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-poweff-sensors";
prefix ietf-poweff-sensors;
import ietf-poweff-types {
prefix ietf-poweff-types;
}
organization
"IETF OPSA (Operations and Management Area) Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/opsawg/>
WG List: <mailto:opsawg@ietf.org>
Editor: Jan Lindblad
<mailto:jlindbla@cisco.com>
Editor: Snezana Mitrovic
<mailto:snmitrov@cisco.com>
Editor: Marisol Palmero
<mailto:mpalmero@cisco.com>";
description
"This YANG module defines basic groupings for POWEFF sensor
management.
Copyright (c) 2021 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to
the license terms contained in, the Simplified BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
for full legal notices.";
revision 2023-10-12 {
description
"Initial revision of POWEFF sensors";
reference
"RFC XXXX: ...";
}
grouping sensors-g {
description "sensors grouping";
container sensors {
description "list of sensors";
list sensor {
key "sensor-type";
description "list of sensors attached to this asset";
leaf sensor-type {
type identityref {
base ietf-poweff-types:sensor-type;
}
// FIXME: Are we fine with a single sensor of each type
// for each asset? I.e. is there ever a need for more than
// one Vin-sensor on a particular asset? Ever more than one
// Temp-sensor? If so, we need to add a second key here.
description
"Type of sensor sending data per asset:
Vin, Iin, Vout, Iout, Pin, Pout, Palloc, Temp, etc.
Sensor type specifies which unit of measurement is used.";
}
leaf sensor-location {
type string;
mandatory "true";
description
"Indicates the current location where the sensor is located
in the chassis,typically refers to slot";
}
leaf sensor-state {
type string;
description
"Current state of the sensor";
// FIXME: What does this mean?
}
leaf sensor-current-reading {
type string;
config false;
description
"Current reading of the sensor";
}
leaf sensor-accuracy-eligible {
type boolean;
default false;
description
"Used to identify which sensor/assets reading shall be
included in real metrics";
}
leaf sensor-accuracy {
type string;
must "../sensor-accuracy-eligible = 'true'";
description
"Maximum deviation to be considered. This attribute mainly
will apply to drawn power, which corresponds to PSU PowerIn
measured power or calculated power; assuming discrepancy
between Real Power, power collected from a power meter, and
power measured or calculated from the metrics provided by
the sensors";
}
container sensor-thresholds {
description
"Threshold values for the particular sensor.
Default values shall beprovided as part of static data
but when configurable need to be pulledfrom the device.
Ideally, the sensor should allow configuing
thesethreshold values";
leaf minor-low {
type string;
description
"minor-low";
}
leaf minor-high {
type string;
description
"minor-high";
}
leaf major-low {
type string;
description
"major-low";
}
leaf major-high {
type string;
description
"major-high";
}
leaf critical-low {
type string;
description
"critical-low";
}
leaf critical-high {
type string;
description
"critical-high";
}
leaf shutdown {
type string;
description
"shutdown";
}
}
}
}
}
grouping power-derived-g {
description
"define derived metrics";
container power-derived {
config false;
description "power derived attributes";
leaf heat-dissipation {
type string;
description
"It refers to Heat Transfer, i.e. heat transferred from
hotter object to coolerobject (1W = 3.412BTU/h)";
}
leaf rated-input-pwr-value {
type string;
mandatory "true";
description
"Total Input Power for the chassis and specific inventory
inside. The sum for all assets for specific hardware
configuration. Can be calculated for Typical, Operating, or
Maximum anticipated Capacity Load. Mainly used for
dimensioning based on benchmark data";
}
leaf asset-input-pwr {
type string;
mandatory "true";
description
"For a given asset, assumed input power means the rate of
electricity consumption in Watts provided by the network
device or sensor. Conditionally derived - if
the device/sensor can give actualpower draw then this
calculation is not required, and will be taken directly
from the sensor.";
}
leaf asset-output-pwr {
type string;
description
"Watts provided to the internal components for a given
asset. Only applicable to assets that provide output power,
such as PSUs. This is present here to accommodate chassis
that don’t provide Watt value currently. Ideal
implementation should provide Pout sensor reading";
//FIXME: add condition this is mandatory for when asset is
//chassis or PSU and not LC or Port;
}
leaf psu-input-power {
type string;
mandatory "true";
description
"Total input power per chassis, rate of the electricity
consumption in Watts. Sum of asset-input-pwr when uid=PSU.
It considers all operational PSU'́s to the chassis";
}
leaf psu-output-power {
type string;
mandatory "true";
description
"Total input power for chassis, rate of the electricity
consumption inWatts. Sum of asset-output-pwr when uid=PSU.
It considers alloperational PSU's to the chassis";
}
leaf psu-pwr-ratio {
type string;
mandatory "true";
description
"Define dynamic (current) power ratio taking into
consideration total system real power input vs used. Not
expected to be the same as PSU efficiency. Formula:
(psu-output-power / psu-input-power) * 100.0.
It considers all operational PSU ́s to the chassis.";
}
leaf energy-traffic-ratio {
type string;
mandatory "true";
description
"How much Watts is spent to move 100Gigaytes per
chassis within thetime period; Formula:
psu-output-power [Watt] /SUM of all interfaces
(input-data-rate-bits + output-data-rate-bits).
Measured over a period of 1hr. energy-traffic-ratio is
the value considered for the complete chassis and all
operational LC ́s/interfaces.";
}
}
}
grouping power-static-g {
description
"define static attributes";
container power-static {
description "power static attributes";
leaf max-amp {
type string;
mandatory "true";
description
"For a given asset, it is the current in Amperes that the
asset could withdraw at Maximum capacity";
}
leaf output-amp {
type string;
mandatory "true";
description
"For a given asset, it is the current in Amperes that the
asset couldwithdraw at Operating capacity.";
}
leaf input-amp {
type string;
mandatory "true";
description
"Current of an asset at a typical power consumption of
switch in Amperes. Somethimes refered to as input-current";
}
leaf max-output-pwr {
type string;
mandatory "true";
description
"For a given asset, it is the maximum power in Watts that
the asset could draw at Maximum capacity";
}
leaf output-pwr {
type string;
mandatory "true";
description
"For a given asset, it is the power in Watts that the
asset could withdraw at Operating capacity";
}
leaf typical-output-pwr {
type string;
mandatory "true";
description
"This value is an estimation of the average power usage
in Watts that the same configuration will use at Typical
capacity";
}
leaf accuracy-pwr {
type string;
description
"If known, the maximum deviation of power to be considered.
BU shouldprovide an estimation";
}
leaf inline-pwr {
type string;
mandatory "true";
description
"Available PoE Power i.e the power which can be passed over
ethernet cables to power devices.";
}
leaf psu-efficiency {
type string;
mandatory "true";
description
"Rating the PSU has been certified for against 80plus
certification specification. The amount of the actual power
delivered to the assetdivided by the electrical power drawn
from the main supply socket.i.e. Output Power of System/
Input Power of PSU. The objective for psu-efficiency values
is to reach 80+ certification.
Please refer to https://www.clearesult.com/80plus";
}
leaf voltage-type {
type string;
mandatory "true";
description
"AC/DC/HVDC. Note: DC typically gives an accurate measure,
but AC, due to the nature of the metric is not accurate";
}
leaf idle-pwr {
type string;
mandatory "true";
description
"Initial power allocated to the asset with no traffic load";
}
leaf max-temperature {
type string;
mandatory "true";
description
"Operating temperature - i.e max temperature tolerance
(temperaturerange expands to approximately -40°C to 85°C).
If the asset exceeds themax temperature limit, it either
slows down or stops completely";
}
leaf pwr-saving-mode {
type string;
mandatory "true";
description
"Does the asset support any power-saving software feature Y/N.
Will beexpanded in future releases";
}
}
}
}
<CODE ENDS>¶
<CODE BEGINS>
module ietf-poweff-types {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-poweff-types";
prefix ietf-poweff-types;
organization
"IETF OPSA (Operations and Management Area) Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/opsawg/>
WG List: <mailto:opsawg@ietf.org>
Editor: Jan Lindblad
<mailto:jlindbla@cisco.com>
Editor: Snezana Mitrovic
<mailto:snmitrov@cisco.com>
Editor: Marisol Palmero
<mailto:mpalmero@cisco.com>";
description
"This YANG module defines basic quantities, measurement units
and sensor types for the POWEFF framework.
Copyright (c) 2021 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to
the license terms contained in, the Simplified BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
for full legal notices.";
revision 2023-10-12 {
description
"Initial revision of POWEFF types";
reference
"RFC XXXX: ...";
}
identity sensor-class {
description "Sensor's relation to the asset it sits on.";
}
identity sc-input {
base sensor-class;
description "Sensor reports input quantity of the asset it sits
on.";
}
identity sc-output {
base sensor-class;
description "Sensor reports output quantity of the asset it sits
on.";
}
identity sc-allocated {
base sensor-class;
description "Sensor reports (maximum) allocated quantity of the
asset it sits on.";
}
identity sensor-quantity {
description "Sensor's quantity being measured.";
}
identity sq-voltage {
base sensor-quantity;
description "Sensor reports electric tension, voltage.";
}
identity sq-current {
base sensor-quantity;
description "Sensor reports electric current.";
}
identity sq-power {
base sensor-quantity;
description "Sensor reports power draw (energy per unit of time).";
}
identity sq-power-apparent {
base sq-power;
description "Sensor reports apparent power, i.e. average electrical
current times voltage (in VA).";
}
identity sq-power-true {
base sq-power;
description "Sensor reports true power, i.e. integral over current
and voltage at each instant in time.";
}
identity sq-energy {
base sensor-quantity;
description "Sensor reports actual energy drawn by asset.";
}
identity sq-co2-emission {
base sensor-quantity;
description "Sensor reports CO2 (carbon dioxide) emission by
asset.";
}
identity sq-co2eq-emission {
base sensor-quantity;
description "Sensor reports CO2 (carbon dioxide) equivalent
emission by asset.";
}
identity sq-temperature {
base sensor-quantity;
description "Sensor reports temperature of asset.";
}
identity sensor-unit {
description "Sensor's unit of reporting.";
}
identity su-volt {
base sensor-unit;
base sq-voltage;
description "Sensor unit volt, V.";
}
identity su-ampere {
base sensor-unit;
base sq-current;
description "Sensor unit ampere, A.";
}
identity su-watt {
base sensor-unit;
base sq-power;
description "Sensor unit watt, W.";
}
identity su-voltampere {
base sensor-unit;
base sq-power;
description "Sensor unit Volt*Ampere, VA.";
}
identity su-kw {
base sensor-unit;
base sq-power;
description "Sensor unit kilowatt, kW.";
}
identity su-joule {
base sensor-unit;
base sq-energy;
description "Sensor unit joule, J.";
}
identity su-wh {
base sensor-unit;
base sq-energy;
description "Sensor unit watthour, Wh.";
}
identity su-kwh {
base sensor-unit;
base sq-energy;
description "Sensor unit kliowatthour, kWh.";
}
identity su-kelvin {
base sensor-unit;
base sq-temperature;
description "Sensor unit kelvin, K.";
}
identity su-celsius {
base sensor-unit;
base sq-temperature;
description "Sensor unit celsius, C.";
}
identity su-farenheit {
base sensor-unit;
base sq-temperature;
description "Sensor unit farenheit, F.";
}
identity su-gram {
base sensor-unit;
base sq-co2-emission;
description "Sensor unit gram, g.";
}
identity su-kg {
base sensor-unit;
base sq-co2-emission;
description "Sensor unit kliogram, kg.";
}
identity su-ton {
base sensor-unit;
base sq-co2-emission;
description "Sensor unit ton, t.";
}
identity sensor-type {
description "Sensor's type, i.e. combination of class, quantity and
unit.";
}
identity st-v-in {
base sensor-type;
base sc-input;
base sq-voltage;
base su-volt;
description "Sensor reporting Voltage In to asset.";
}
identity st-v-out {
base sensor-type;
base sc-output;
base sq-voltage;
base su-volt;
description "Sensor reporting Voltage Out of asset.";
}
identity st-i-in {
base sensor-type;
base sc-input;
base sq-current;
base su-ampere;
description "Sensor reporting Current In to asset.";
}
identity st-i-out {
base sensor-type;
base sc-output;
base sq-current;
base su-ampere;
description "Sensor reporting Current Out of asset.";
}
identity st-p-in-apparent-watt {
base sensor-type;
base sc-input;
base sq-power-apparent;
base su-voltampere;
description "Sensor reporting Power In to asset as apparent (I*U)
power.";
}
identity st-p-out-apparent-watt {
base sensor-type;
base sc-output;
base sq-power-apparent;
base su-voltampere;
description "Sensor reporting Power Out of asset as apparent (I*U)
power.";
}
identity st-p-in-true-watt {
base sensor-type;
base sc-input;
base sq-power-true;
base su-watt;
description "Sensor reporting Power In to asset as true power.";
}
identity st-p-out-true-watt {
base sensor-type;
base sc-output;
base sq-power-true;
base su-watt;
description "Sensor reporting Power Out of asset as true power.";
}
identity st-p-allocated-watt {
base sensor-type;
base sc-allocated;
base sq-power;
base su-watt;
description "Sensor reporting Allocated Power for asset.";
}
identity st-w-j {
base sensor-type;
base sq-energy;
base su-joule;
description "Sensor reporting energy draw of asset in J.";
}
identity st-w-wh {
base sensor-type;
base sq-energy;
base su-wh;
description "Sensor reporting energy draw of asset in Wh.";
}
identity st-w-kwh {
base sensor-type;
base sq-energy;
base su-kwh;
description "Sensor reporting energy draw of asset in kWh.";
}
identity st-t-k {
base sensor-type;
base sq-temperature;
base su-kelvin;
description "Sensor reporting Temperature of asset in K.";
}
identity st-t-c {
base sensor-type;
base sq-temperature;
base su-celsius;
description "Sensor reporting Temperature of asset in °C.";
}
identity st-t-f {
base sensor-type;
base sq-temperature;
base su-farenheit;
description "Sensor reporting Temperature of asset in °F.";
}
}
<CODE ENDS>¶
POWEFF data models define the data schemas for power and energy efficiency data. POWEFF data models are based on YANG.¶
YANG is protocol independent. YANG data models can be used independently of the transport and can be converted into any encoding format supported by the network configuration protocol.¶
To enable the exchange of POWEFF data among all interested parties, deployment considerations that are out of the scope of this document, will need to include:¶
The data structure to describe all metrics and quantify relevant data consistently, i.e. specific formats like XML or JSON encoded message would be deemed valid or invalid based on POWEFF models.¶
The process to share and collect POWEFF data across the consumers consistently, including the transport mechanism. The POWEFF YANG models can be used with network management protocols such as NETCONF [RFC6241], RESTCONF [RFC8040], streaming telemetry, etc. OpenAPI specification could be considered to consume POWEFF metrics.¶
How the configuration of assets should be done.¶
The security considerations mentioned in section 17 of [RFC7950] apply.¶
POWEFF brings several security and privacy implications because of the various components and attributes of the information model. For example, each functional component can be tampered with to give manipulated data. POWEFF when used alone or with other relevant data, can identify an individual, revealing Personal Identifiable Information (PII). How the configuration of assets should be accomplished could lead to data being accessed by unauthorized entities.¶
Methods exist to secure the communication of management information. The transport entity of the functional model MUST implement methods for secure transport. This document also contains an Information model and Data-Model in which none of the objects defined are writable. If the objects are deemed sensitive in a particular environment, access to them MUST be restricted using appropriately configured security and access control rights. The information model contains several optional elements which can be enabled or disabled for the purpose of privacy and security. Proper authentication and audit trail MUST be included for all the users/processes that access POWEFF data.¶
This document registers URIs in the IETF XML registry [RFC3688]. Following the format in [RFC3688], the registrations defined below are requested:¶
URI: urn:ietf:params:xml:ns:yang:ietf-lmo Registrant Contact: The OPSA WG of the IETF. XML: N/A, the requested URI is an XML namespace.¶
This document registers YANG modules in the YANG Module Names registry [RFC7950]. Following the format in [RFC7950], the registrations defined below are requested:¶
name: ietf-poweff-environment namespace: urn:ietf:params:xml:ns:yang:ietf-poweff-environment maintained by IANA: N prefix: ietf-poweff-environment reference: RFC XXXX¶
RFC Editor Note: This section is to be removed during the final publication of the document.¶
version 00¶
Initial version.¶
This document was created by meaningful contributions from Per Andersson, Jeff Apcar, Derek Engi, Esther Roure Vila, Pascal Thubert, Klaus Verschure, Joel Goergen, Colin Seward, Michael King, Angelo Fienga and Suresh Krishnan.¶
The authors wish to thank them and many others for their helpful comments and suggestions.¶