Network Working Group B. Claise Internet-Draft M. Chandramouli Intended Status: Standards Track J. Parello Expires: August 5, 2010 B. Schoening Cisco Systems, Inc. February 5, 2010 Energy Monitoring MIB draft-claise-energy-monitoring-mib-01 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on July, 2010. Expires August 5 2010 [Page 1] Internet-Draft Feb 2010 Copyright Notice Copyright (c) 2010 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 (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Abstract This document defines the Management Information Base (MIB) for the energy monitoring of network elements. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Expires August 5, 2011 [Page 2] Internet-Draft Feb 2010 Table of Contents 1. Introduction............................................... 4 2. The Internet-Standard Management Framework................. 4 3. Terminology................................................ 4 4. Concepts................................................... 6 5. Structure of the MIB....................................... 9 5.1. Link with the other IETF MIBs............................10 5.1.1. Link with the ENTITY-MIB and the ENTITY-SENSOR-MIB.....10 5.1.2. Link with the ENTITY-STATE-MIB.........................11 5.1.3. Link with the POWER-OVER-ETHERNET MIB..................11 6. MIB Definitions........................................... 11 7. Security Considerations................................... 30 8. IANA Considerations....................................... 30 9. References................................................ 31 9.1. Normative References.....................................31 9.2. Informative References...................................31 10. Authors' Addresses....................................... 32 Expires August 5, 2011 [Page 3] Internet-Draft Feb 2010 1. Introduction This document defines a subset of the Management Information Base (MIB) for use with network management protocols for monitoring the power state and the energy consumption of network elements, taking into account the requirements specified in [POWER-MON-REQ]. In addition to energy monitoring, functionality to configure the power state of network elements is proposed. The MIB module in this document has been designed in order to be as flexible as possible, with twelve different power levels, in accordance to the Advanced Configuration and Power Interface SPECIFICATION (ACPI) specifications [ACPI]. The target devices include: routers, switches, attached devices such as Power over Ethernet (PoE) devices, middle boxes, home energy gateway, hosts and servers, sensor proxy, etc. However, the monitoring and configuration should be available for individual components of devices as well, such as line cards, processor cards, hard drives, etc. when those components are independent from a power state point of view. Those targets devices and components may be characterized by the power related attributes of a physical entity present in ENTITY-MIB, even though the ENTITY-MIB compliance is not a requirement. 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies MIB modules that are compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 3. Terminology EnergyMonitor Entity Expires August 5, 2011 [Page 4] Internet-Draft Feb 2010 An EnergyMonitor Entity is a system of one or more components, that provides power or draws power. It can be independently managed from a power monitoring and power state configuration point of view. This entity may be represented by a physical component referenced using the EntPhysicalTable from the Entity MIB RFC 2737. Examples of EnergyMonitor Entities are a router line card, a motherboard with a CPU, etc. EnergyMonitor Level A uniform way to classify power settings on an EnergyMonitor Entity. Levels are guidelines for the manufacturers of entity (e.g., shut, hibernate, sleep, standby). EnergyMonitor Scale A scale used to represent smaller or larger quantities of EnergyMonitor usage. It conforms to the standard prefixes for the SI (System International) units of measure. Measured values are represented in SI units obtained by BaseValue * 10 raised to the power of Scale. For example, if current usage of an EnergyMonitor Entity is 3, it could be 3 W, 3 mW, 3 KW, 3 MW depending on the value of EnergyMonitor Scale. EnergyMonitor Domain A EnergyMonitor Domain is a name or name space which logically groups together EnergyMonitor Entities that comprises a unit of manageable power consumption. For example, all phones in a floor, all EnergyMonitor Entities from a specific building, or all EnergyMonitor Entities of a specific device type for which a common profile is deployed. From the point of monitoring power consumption, it is useful to report the total energy consumed as the sum of energy consumed by all the EnergyMonitor Entities of the EnergyMonitor Domain. Expires August 5, 2011 [Page 5] Internet-Draft Feb 2010 4. Concepts EnergyMonitor Levels represent the one of twelve power management states of an entity. Each EnergyMonitor Level corresponds to a global, system, and performance state in the ACPI model. Level ACPI Global/System Name State Non-operational states: 1 G3, S5 Mech Off 2 G2, S5 Soft Off 3 G1, S4 Hibernate 4 G2, S3 Sleep, Save-to-RAM 5 G2, S2 Standby 6 G2, S1 Ready Operational states: 7 G0, S0, P5 Low 8 G0, S0, P4 Frugal 9 G0, S0, P3 Medium 10 G0, S0, P2 Reduced 11 G0, S0, P1 High 12 G0, S0, P0 Full For example, the energy state of the EnergyMonitor Entity is 9, to indicate the entity is medium power consumption operational state. The emEnergyUsageCategory MIB object, specified as a read-only object, specifies the energy usage type of the EnergyMonitor Entity: energy consumer, energy producer, or meter. The emEnergyUsage, specified as Integer32, can have a positive or negative value, corresponding with the usage type in emEnergyUsageCategory, determining whether the EnergyMonitor Entity consumes or produces power in case of "consumer" and "producer". An Energy Monitor Entity should have an emName, and a unique EnergyMonitor index emIndex, and potentially an entityPhysicalIndex from the ENTITY-MIB [RFC4133], if supported by the EnergyMonitor Entity. The emName can be configured or discovered by DNS. Possible emName are: textual DNS name, MAC- Expires August 5, 2011 [Page 6] Internet-Draft Feb 2010 address of the device, interface ifName, or a text string uniquely identifying the entity. The emName should ideally be unique. As an example, in the case of phones, emName can be discovered by DNS and can be the IP address or MAC-address. In the case of router/switch line cards, the emName shall be text string. That EnergyMonitor Entity can be a member of a EnergyMonitor Domain. The EnergyMonitor Domain could map 1-1 with a metered or sub-metered portion of the customers site. It can be used to further sub divide the deployment down to finer EnergyMonitor Domains such as a lab, data center, rack, etc. With the possible evolution of this draft, to a framework document, the notion of EnergyMonitor Domain shall be useful. For an EnergyMonitor Entity, instantaneous energy usage is reported using emEnergyUsage and the unit magnitude of measurement is specified in emEnergyUnits which is based on EnergyMonitorPowerScale. Nameplate power consumption of an EnergyMonitor Entity is specified by the vendor as the maximum capacity required to safely power the device. Often this label is a conservative number and is the worst case power draw of all elements in a fully configured system. While the actual utilization of an entity can be lower, Nameplate power consumption is important for power provisioning, capacity planning and billing. In addition, to measurement of power consumption, an approach to characterize the power demand is also presented in the MIB. It is well-known, in the electrical utility perspective, the demand charges can weigh on par with actual energy charges. So, in addition to measuring power consumption, it is useful to characterize the demand. The demand can be described as average power usage of an entity over a time window, called demand interval, typically 15 minutes. The highest peak demand measured over a time horizon, say 1 month or 1 year is often the basis for usage charge. For example, a single window of time of high usage can penalize the power consumption charges. It is relevant to measure the demand, only when there are actual power measurements from an EnergyMonitor Entity. There are cases, wherein the power measurement of an EnergyMonitor Entity is assumed, or predicted as pointed in the MIB OID EnergyUsageCaliber. Two tables are introduced to characterize the energy demand - emDemandTable and emDemandControlTable. emDemandControl Table consists of parameters of the duration of the demand interval specified in seconds, emDemandControlIntervalLength, (for e.g. Expires August 5, 2011 [Page 7] Internet-Draft Feb 2010 15 minutes); The number of demand intervals kept in the emDemandTable, emDemandControlIntervalNumber, ; emDemandControlSampleRate which is internal to the device to calculate energy usage. Judicious choice of SamplingRate would help in accurate measurement of energy and ensure that it does impose excessive polling burden. The emDemandControlStatus is useful to specify the power measurement is actual and thus to indicate if the emDemandTable entries exist or not. emDemand Table consists of measurements of energy DemandIntervalEnergyUsed, the scale of energy measurement - DemandIntervalEnergyScale and the maximum observed demand in a window - emDemandIntervalMaxf Various efficiency metrics can be derived and tracked with the usage data present in this MIB module. For example, - Per-packet energy costs for a networking device (router or switch) can be calculated by an network management system. The packets count can be determined from the traffic usage in the ifTable, [RFC2863], from the forwarding plane figure, or from the platform specifications - Watt-hour energy use from this MIB can be combined with utility energy sources to estimate carbon footprint and other emission statistics. An example is provided to illustrate the concepts. For example, a given EnergyMonitor Entity as described by the emIndex "7" emPhysicalEntity "5" and emName "switch2.foo.com". For that EnergyMonitor Entity, the energy measurement and power state is reported as follows: the units of measurement emEnergyUnits is "watts" (value 1), the instantaneous power usage enEnergyUsage is 100 watts, while the maximum power consumption as prescribed by the vendor emEnergyNamePlate is 300 watts. The emEnergyUsageCaliber indicates that the energy measurement is "actual". The power state of that EnergyMonitor Entity EmEnergyLevel is "9" to indicate medium power usage and emEnergyUsageCategory indicates the type of EnergyMonitor Entity consumer or producer of power or both. In addition, the maximum power consumption at the level emLevelMaxUsage is indicated as 150 watts. emDemandTable and emDemandControlTable are illustrated, following the same example. Firstly, in order to estimate demand, an interval to sample power usage should be specified, i.e. emDemandControlIntervalLength can be "900 seconds" and the number of consecutive intervals over which the maximum demand is calculated emDemandControlIntervalNumber as "10". The sampling rate internal to the EnergyMonitor Entity for measurement of Expires August 5, 2011 [Page 8] Internet-Draft Feb 2010 energy usage, emDemandControlSampleRate, can be "1000 milliseconds", as set by the EnergyMonitor Entity as a reasonable value. Then, the emDemandControlStatus is set to active (value 1) to indicate that the EnergyMonitor Entity should start monitor the usage as per the emDemandTable. For the indexes in the emDemandTable are the emIndex, which identifies the EnergyMonitor Entity and the emDemandIntervalStartTime, which denotes the start time of the demand measurement interval based on the sysUpTime. emDemandIntervalEnergyUsed is the measurement of the energy consumption over the time interval specified (emDemandControlIntervalLength) based on the EnergyMonitor Entity internal sampling rate (emDemandControlSampleRate). The units are derived from emDemandIntervalEnergyScale is based EnergyMonitorScale. For example, emDemandIntervalEnergyUsed can be "100" with emDemandIntervalEnergyScale equal to 0, the demand is 100 watt-hours. emDemandIntervalMax is the maximum demand observed can be "150 watt-hours". The emDemandTable has a buffer to retain a certain number of intervals, as defined by emDemandControlIntervalNumber. If the default value of "10" is kept, then the emDemandTable contains 10 demand measurements including the maximum. A brief explanation on how the maximum demand is calculated. The first observed demand measurement value is taken to be the maximum. With each measurement, based on numerical comparison, maximum demand may be updated. The maximum value is retained as long as the measurement is taking place. Based on periodic polling, the Network Management System can compute the maximum over a longer period, i.e. a month, 3 months, or a year. [POWER-MON-REQ] specifies some requirements about power states such as "the current state - the time of the last change", "the total time spent in each state", "the number of transitions to each state", etc... Such requirements are fulfilled thanks to the emLevelChange NOTIFICATION-TYPE, indexed by the emIndex and the emEnergyLevel, which is generated when the value of emEnergyLevel has changed for the EnergyMonitor Entity represented by the emIndex. Indeed, assuming that the SNMP notifications arrives to Network Management Station (NMS), the NMS can deduce all the information. 5. Structure of the MIB The primary MIB object in this MIB module is EnergyMonitorMIBObjects. Expires August 5, 2011 [Page 9] Internet-Draft Feb 2010 The emTable table defines the EnergyMonitor Entities, with a potential link to the entPhysicalIndex, when available. The EnergyMonitor Entities are used for describing and configuring the entities that are possible candidates for power management. The specific EnergyMonitor Level can be configured in the emTable. The emLevelTable table lists the maximum power usage at each EnergyMonitor Level for each EnergyMonitor Entity. Finally, the monitoring of all the EnergyMonitor Entities on the SNMP agent can be turned on/off with the emEnable MIB object. 5.1. Link with the other IETF MIBs 5.1.1. Link with the ENTITY-MIB and the ENTITY-SENSOR-MIB RFC 4133 [RFC4133] defines the Entity MIB module that lists the physical entities of a networking device (router, switch) and those physical entities listed indexed by entPhysicalIndex. From an energy management point of view, of interest are the physical entities that consume or produce energy. RFC 3433 [RFC3433] defines the ENTITY-SENSOR MIB module that provides a standardized way of obtaining information (current value of the sensor, operational status of the sensor, and the data units precision) from sensors embedded in networking devices. Sensors are associated with each index of entPhysicalIndex of the Entity MIB [RFC4133]. While the focus of the Energy Monitoring MIB, is on measurement of energy consumption by networking equipment indexed by the entity MIB, this MIB proposes a customized power scale for power measurement and different power level states of networking equipment and a functionality to configure the power level states. When this MIB module is used to monitor the energy consumption of devices such as routers and switches, the ENTITY-MIB and ENTITY-SENSOR-MIB should be implemented. In such cases, the EnergyMonitor Entities are modeled by the entPhysicalIndex through the emPhysicalEntity MIB object specified in the emTable. However, the ENTITY-SENSOR-MIB doesn't have the ANSI C12.x accuracy classes required for electricity, i.e., 1%, 2%, 0.5% accuracy classes. These ANSI and IEC Standards require that we use an accuracy class, and not the precision model in RFC3433. The emEnergyUsageAccuracy MIB object models this accuracy. Note that the emEntEnergyScale represents the scale is a more logical Expires August 5, 2011 [Page 10] Internet-Draft Feb 2010 representation (compared to entPhySensorScale), with the mantissa and the exponent values X * 10 ^ Y. Finally, one cannot assume that the ENTITY-MIB and ENTITY- SENSOR-MIB are implemented for all EnergyMonitor Entity that needs to be monitored. A typical example is a converged building gateway, monitoring several other devices in the building, doing the proxy between SNMP and a protocol such as BACNET. Another example is the home energy controller. In such cases, the emPhysicalEntity value contains the zero value, thanks to PhysicalIndexOrZero textual convention. As a consequence, the emEnergyMonitorId MIB object has been kept as the unique Energy Monitor Entity index. Finally, not that the emEntEnergyUsage is similar to entPhySensorValue [RFC3433] and the emEntEnergyScale is similar to entPhySensorScale [EDITOR NOTE: the proxy table will be added in the next version of the draft]. 5.1.2. Link with the ENTITY-STATE-MIB RFC 4268 [RFC4268] defines the Entity State MIB module that gives the operational states (enabled, disabled, testing) and alarm states and usage states (idle, active, busy) of the entities in the entity MIB. From an energy monitoring point of view, different power states to indicate the power state of the entities models need to be developed. The Energy Monitoring MIB proposes the power states of entities in the Entity MIB. 5.1.3. Link with the POWER-OVER-ETHERNET MIB Power-over-Ethernet MIB [RFC-3621] provides energy monitoring and configuration framework for power over Ethernet devices. The RFC uses a concept of group of ports of a switch to define power monitoring and management policy and does not use the entPhysicalIndex as index. For the purpose on hand, power monitoring of components of networking devices, RFC 3621 can not be applied. 6. MIB Definitions -- ************************************************************ -- Expires August 5, 2011 [Page 11] Internet-Draft Feb 2010 -- -- This MIB is used to monitor Energy Consumption of network -- devices -- -- ************************************************************* ENERGY-MONITOR-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, mib-2, Integer32, TimeTicks FROM SNMPv2-SMI MODULE-COMPLIANCE, NOTIFICATION-GROUP, OBJECT-GROUP FROM SNMPv2-CONF TEXTUAL-CONVENTION FROM SNMPv2-TC SnmpAdminString FROM SNMP-FRAMEWORK-MIB RowStatus, TimeInterval FROM SNMPv2-TC PhysicalIndexOrZero FROM ENTITY-MIB; energyMonitorMIB MODULE-IDENTITY LAST-UPDATED "201001130000Z" ORGANIZATION "Cisco Systems, Inc." CONTACT-INFO "Cisco Systems Customer Service Postal: 170 W Tasman Drive San Jose, CA 95134 USA Tel: +1 800 553-NETS E-mail: cs-snmp@cisco.com" DESCRIPTION "This MIB is used to monitor power usage in network Devices." REVISION "201001130000Z" DESCRIPTION "This Latest draft of this MIB module. " Expires August 5, 2011 [Page 12] Internet-Draft Feb 2010 ::= { mib-2 xxxxx } energyMonitorMIBNotifs OBJECT IDENTIFIER ::= { energyMonitorMIB 0 } energyMonitorMIBObjects OBJECT IDENTIFIER ::= { energyMonitorMIB 1 } energyMonitorMIBConform OBJECT IDENTIFIER ::= { energyMonitorMIB 2 } -- Textual Conventions EnergyMonitorLevel ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An enumerated integer value that represents the value of EnergyMonitor Level, a power setting at which a EnergyMonitor Entity uses power. The EnergyMonitor Levels are divided into six operational states, and six non-operational states. Each non-operational state corresponds to an ACPI (Advanced Configuration and Power Interface Specification, http://www.acpi.info/spec30b.htm) Global and System level state between G3 (hard-off) and G1 (sleeping). The operational levels represent a performance state, and correspond to ACPI states P0 (maximum performance & power) through P5 (minimum performance and minimum power). EnergyMonitor Entities need not support all levels, but a subset of the levels that can be mapped to their system state. mechoff(1) : An off state. No entity features are available. The entity is unavailable. No power is being consumed and the power Connector can be removed. This maps to the level G3 in ACPI. softoff(2) : Similar to off, but some components remain powered so the device can be woken from its off state. In soft-off, no context is saved and the device requires a complete boot when awakened. This maps Expires August 5, 2011 [Page 13] Internet-Draft Feb 2010 to level G2 in ACPI. hibernate(3): No entity features are available. The entity may be awoken without requiring a complete boot, but the time for availability is longer than sleep. This is generally the same as save-to- disk where DRAM context is not maintained. Minimal, nearly zero, or zero power is consumed. This maps to level G1, S4 in ACPI. sleep(4) : No entity features are available. The entity may be available but the time for availability is longer than standby. This is generally the same as save-to-RAM, where DRAM context is maintained. Minimal power is consumed. This maps to level G1, S3 in ACPI. standby(5) : Indicates some entity features may not be available. The entity may be available but the time for availability is longer than ready. Processor context is not maintained. Minimal power is consumed. This maps to level G1, S2 in ACPI. ready(6) : Indicates some entity features may not be available. The entity itself may be available but there may be a time delay for availability. Processors are not executing, but their context is maintained. Low or less power is consumed. This maps to level G1, S1 in ACPI. low(7) : Indicates some features may not be available and the entity has taken measures/options to provide less than frugal usage. This maps to ACPI State G0; which includes operational levels low to full. frugal(8) : Indicates some features may not be available and the entity has take measures/options to provide less than medium usage. medium(9) : Indicates all entity features are Expires August 5, 2011 [Page 14] Internet-Draft Feb 2010 available but the entity has taken measures/options to provide less than reduced usage. reduced(10) : Indicates all entity features are available but the entity has taken measures/options to provide less than high usage. high(11) : Indicates all entity features are available and power consumption is less than full. full(12) : Indicates all entity features are available and the entity is consuming the highest power." SYNTAX INTEGER { mechoff(1), softoff(2), hibernate(3), sleep(4), standby(5), ready(6), low(7), frugal(8), medium(9), reduced(10), high(11), full(12) } EnergyMonitorId ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A unique identifier for the EnergyMonitor Entity in the EnergyMonitor Domain. Implementation must ensure that the ID for each EnergyMonitor Entity is unique among all entities within the EnergyMonitor Domain. A Universally Unique Identifier (UUID) is typically used." REFERENCE "IETF RFC 4122" SYNTAX OCTET STRING (SIZE (16)) EnergyMonitorPowerScale ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION Expires August 5, 2011 [Page 15] Internet-Draft Feb 2010 "The EnergyMonitor Scale: an integer value that represents the units used to measure the power. The units are expressed in watts. I.e., -3 represents 10^-3 or milliwatts" REFERENCE "The International System of Units (SI), National Institute of Standards and Technology, Spec. Publ. 330, August 1991." SYNTAX INTEGER { yocto(-24), -- 10^-24 zepto(-21), -- 10^-21 atto(-18), -- 10^-18 femto(-15), -- 10^-15 pico(-12), -- 10^-12 nano(-9), -- 10^-9 micro(-6), -- 10^-6 milli(-3), -- 10^-3 units(0), -- 10^0 kilo(3), -- 10^3 mega(6), -- 10^6 giga(9), -- 10^9 tera(12), -- 10^12 peta(15), -- 10^15 exa(18), -- 10^18 zetta(21), -- 10^21 yotta(24) -- 10^24 } -- Objects emTable OBJECT-TYPE SYNTAX SEQUENCE OF EmEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table lists EnergyMonitor Entities." ::= { energyMonitorMIBObjects 1 } emEntry OBJECT-TYPE SYNTAX EmEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describes attributes of a EnergyMonitor Entity. Whenever the device creates/destroys a Expires August 5, 2011 [Page 16] Internet-Draft Feb 2010 EnergyMonitor Entity, the device creates/destroys a row in the emTable." INDEX { emIndex } ::= { emTable 1 } EmEntry ::= SEQUENCE { emIndex Integer32, emEnergyMonitorId EnergyMonitorId, emPhysicalEntity PhysicalIndexOrZero, emDomainName SnmpAdminString, emName SnmpAdminString, emRoleDescription SnmpAdminString, emEnergyUnits EnergyMonitorPowerScale, emEnergyUsage Integer32, emEnergyUsageNameplate Integer32, emEnergyUsageAccuracy Integer32, emEnergyUsageCaliber INTEGER, emEnergyLevel EnergyMonitorLevel, emEnergyUsageCategory BITS } emIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique value, greater than zero, for each EnergyMonitor Entity. It is recommended that values are assigned contiguously starting from 1. The value for each emIndex must remain constant at least from one re- initialization of the entity's network management system to the next re-initialization." ::= { emEntry 1 } emEnergyMonitorId OBJECT-TYPE SYNTAX EnergyMonitorId MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the EnergyMonitor UUID identifier. This object value must be unique within the EnergyMonitor Domain." ::= { emEntry 2 } emPhysicalEntity OBJECT-TYPE SYNTAX PhysicalIndexOrZero MAX-ACCESS read-only STATUS current Expires August 5, 2011 [Page 17] Internet-Draft Feb 2010 DESCRIPTION "This object contains the index of a physical entity in the ENTITY MIB. This physical entity is the given Observation Point. If such a physical entity cannot be specified or is not known then the object is zero." ::= { emEntry 3 } emDomainName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies the name of a EnergyMonitor Domain for the EnergyMonitor Entity. This object specifies a null string if no EnergyMonitor Domain name is configured. The value of emDomainName must remain constant at least from one re-initialization of the entity's network management system to the next re- initialization." ::= { emEntry 4 } emName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies a printable name, a text string, for the EnergyMonitor Entity. It is preferred, but not required that emName be unique. The process to assign the emName is implementation specific. Example: DNS Name, MAC address in canonical form, ifName, etc..." ::= { emEntry 5 } emRoleDescription OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies an administratively assigned name to indicate the purpose an EnergyMonitor Entity serves in the network. For example, we can have switches deployed to a lobby with emName as 'Lobby Switch' and emRoleDescription as 'IP Phones'. This object specifies a null string if no role description is configured." ::= { emEntry 6 } Expires August 5, 2011 [Page 18] Internet-Draft Feb 2010 emEnergyUnits OBJECT-TYPE SYNTAX EnergyMonitorPowerScale MAX-ACCESS read-only STATUS current DESCRIPTION "The magnitude of Watts for the usage value in emEnergyUsage and emEnergyUsageNameplate." ::= { emEntry 7 } emEnergyUsage OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the instantaneous consumption for the EnergyMonitor Entity. This value is specified in SI units of watts with the magnitude of watts (milliwatts, kilowatts, etc.) indicated separately in emEnergyUnits. If the EnergyMonitor Entity is a consumer (bit value 1 in emEnergyUsageCategory, the usage value will be positive. If the EnergyMonitor Entity is a producer (bit value 2 in emEnergyUsageCategory, the usage value will be negative. This should be less than or equal to the power that can be consumed at that specified level. " ::= { emEntry 8 } emEnergyUsageNameplate OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the rated maximum consumption for the fully populated EnergyMonitor Entity. The nameplate power requirements are the worst-case power consumption numbers and in almost all cases, are well above the expected operating level. Nameplate power is widely used for power provisioning. This value is specified in SI units of watts with the magnitude of watts (milliwatts, kilowatts, etc.) indicated separately in emEnergyUnits. Nameplate power is widely used for capacity and provisioning planning. It is typically a value provided via experimentation and prediction from the manufacturer of the entity." ::= { emEntry 9 } Expires August 5, 2011 [Page 19] Internet-Draft Feb 2010 emEnergyUsageAccuracy OBJECT-TYPE SYNTAX Integer32 (0..10000) MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates a percentage value in 100ths of a percent representing the accuracy to which the usage, reported by the emEnergyUsage can be assumed. Example 1010 means the reported usage is accurate to +/- 10.1 percent. This value is zero if the accuracy is unknown. ANSI and IEC define the following accuracy classes for power measurement: IEC 62053-22 & 60044-1 class 0.1, 0.2, 0.5, 1 & 3. ANSI C12.20 class 0.2 & 0.5" ::= { emEntry 10 } emEnergyUsageCaliber OBJECT-TYPE SYNTAX INTEGER { unknown(1), actual(2) , trusted(3), predicted(4), presumed(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object specifies how the usage value, reported by emEnergyUsage, is obtained. - unknown: This indicates that the way the usage is determined is unknown. In some cases, entities report aggregate power like what a lighting controller or aggregate controller does. In such cases it is not known whether the usage reported is actual or presumed. - actual: This indicates that the usage data reported is not presumed or predicted but the real power drawn. A PoE phone drawing X amount of power can be determined by reading from the port. For example, a PoE phone can report the actual usage as X W. - trusted: This indicates that the usage data reported was reported from another source. Trusted is higher caliber than predicted. Expires August 5, 2011 [Page 20] Internet-Draft Feb 2010 - predicted: This indicates that the actual power drawn cannot be determined. The value is an estimate based upon the device type, state, and/or utilization. Predicted is a higher caliber than presumed. For example, a switch is known to draw 200w when POE on all interfaces is disable, and 600w when POE is fully enabled. - presumed: This indicates that the actual power drawn cannot be determined but can be presumed from the model. Presumed is the lowest caliber. For example, a PC Model X draws 200W, while a PC Model Y draws 210W." ::= { emEntry 11 } emEnergyLevel OBJECT-TYPE SYNTAX EnergyMonitorLevel MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies the current power level (1..12) for the EnergyMonitor Entity." ::= { emEntry 12 } emEnergyUsageCategory OBJECT-TYPE SYNTAX BITS { consumer(1), producer(2), meter(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object specifies the energy usage type of the entity. An entity could be producing power when emEnergyUsageCategory is producer(2) or a consumer of power consumer (1) or a hybrid - consumer and producer(3). Negative values of energy usage are permissible to indicate the entities as energy sources. Consumer: This indicates that the entity is consumes energy. Producer: This indicates that the entity generates energy. Meter: This indicates that the entity is a meter which reads the energy consumed or produced." ::= { emEntry 13 } Expires August 5, 2011 [Page 21] Internet-Draft Feb 2010 emLevelTable OBJECT-TYPE SYNTAX SEQUENCE OF EmLevelEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table enumerates the maximum power usage in watts at each EnergyMonitor Level for each EnergyMonitor Entity. This table has an expansion dependent relationship on the emTable, containing rows describing each EnergyMonitor Level for the corresponding EnergyMonitor Entity." ::= { energyMonitorMIBObjects 2 } emLevelEntry OBJECT-TYPE SYNTAX EmLevelEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A emLevelEntry extends a corresponding emEntry. This entry displays max usage and delta values at each level. For example, the given the values of a EnergyMonitor Entity corresponds to a maximum usage of 11W at the level 2: Level MaxUsage Units 2 11 1" INDEX { emIndex, emLevelIndex } ::= { emLevelTable 1 } EmLevelEntry ::= SEQUENCE { emLevelIndex EnergyMonitorLevel, emLevelMaxUsage Integer32, emLevelEnergyUnits EnergyMonitorPowerScale } emLevelIndex OBJECT-TYPE SYNTAX EnergyMonitorLevel MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object indicates the level for which this entry describes the power usage." ::= { emLevelEntry 1 } Expires August 5, 2011 [Page 22] Internet-Draft Feb 2010 emLevelMaxUsage OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the maximum power usage for the EnergyMonitor Entity at the particular EnergyMonitor Level. This value is specified in SI units of watts with the magnitude of watts (milliwatts, kilowatts, etc.) indicated separately in emLevelEnergyUnits." ::= { emLevelEntry 2 } emLevelEnergyUnits OBJECT-TYPE SYNTAX EnergyMonitorPowerScale MAX-ACCESS read-only STATUS current DESCRIPTION "The magnitude of the watts for the usage value in emLevelMaxUsage." ::= { emLevelEntry 3 } emDemandControlTable OBJECT-TYPE SYNTAX SEQUENCE OF EmDemandControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Controls the setup of the demand table emDemandTable." ::= { energyMonitorMIBObjects 3 } emDemandControlEntry OBJECT-TYPE SYNTAX EmDemandControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry controls energy usage measurements." INDEX { emIndex } ::= { emDemandControlTable 1 } EmDemandControlEntry ::= SEQUENCE { emDemandControlIntervalLength TimeInterval, emDemandControlIntervalNumber Integer32, emDemandControlSampleRate Integer32, emDemandControlStatus RowStatus Expires August 5, 2011 [Page 23] Internet-Draft Feb 2010 } emDemandControlIntervalLength OBJECT-TYPE SYNTAX TimeInterval MAX-ACCESS read-write STATUS current DESCRIPTION " This object indicates the length of time in seconds over which the average demand is computed. The computation is based on EnergyMonitor Entity internal sampling rate of power consumption of the entity. The sampling rate may differ based on device capabilities. The average power consumption is computed over the length of the demand interval." DEFVAL { 900 } ::= { emDemandControlEntry 1 } emDemandControlIntervalNumber OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "The number of demand intervals over which the maximum demand is computed. Whenever the maximum number of entry is reached, the new demand interval replaces the oldest one, except if the oldest one is the emDemandIntervalMax." DEFVAL { 10 } ::= { emDemandControlEntry 2 } emDemandControlSampleRate OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "The sampling rate in milliseconds at which the EnergyMonitor Entity would poll the instantaneous value power value in order to compute the energy usage measurements in the emDemandTable. The EnergyMonitor should initially set up this sample rate to a reasonable value, i.e. a compromise between a low value that will give a good accuracy, and a too low value that will impact the EnergyMonitor Entity performance by requesting continuous polling." DEFVAL { 1000 } ::= { emDemandControlEntry 3 } Expires August 5, 2011 [Page 24] Internet-Draft Feb 2010 emDemandControlStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this row. An entry may not exist in the active state unless all objects in the entry have an appropriate value. If this object is not equal to active(1), all associated entries in the emDemandTable shall be deleted." ::= {emDemandControlEntry 4 } emDemandTable OBJECT-TYPE SYNTAX SEQUENCE OF EmDemandEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table lists EnergyMonitor energy usage measurements. Only when the Energy Monitor Entity has the emEnergyUsageCaliber value set to actual(2), this table will be populated." ::= { energyMonitorMIBObjects 4 } emDemandEntry OBJECT-TYPE SYNTAX EmDemandEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describes energy usage measurements." INDEX { emIndex, emDemandIntervalStartTime } ::= { emDemandTable 1 } EmDemandEntry ::= SEQUENCE { emDemandIntervalStartTime TimeTicks, emDemandIntervalEnergyUsed Integer32, emDemandIntervalEnergyScale EnergyMonitorPowerScale, emDemandIntervalMax Integer32 } emDemandIntervalStartTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS not-accessible STATUS current Expires August 5, 2011 [Page 25] Internet-Draft Feb 2010 DESCRIPTION "The time (in hundredths of a second) since the network management portion of the system was last re-initialized, as specified in the sysUpTime [RFC3418]. This object is useful for reference of interval period for which the demand is measured. " ::= { emDemandEntry 1 } emDemandIntervalEnergyUsed OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the energy used in units of watt- hours for the EnergyMonitor Entity over the defined interval. This value is specified in the common billing units of watts-hours with the magnitude of watt-hours (kW-Hr, MW-Hr, etc.) indicated separately in emDemandIntervalEnergyScale." ::= { emDemandEntry 2 } emDemandIntervalEnergyScale OBJECT-TYPE SYNTAX EnergyMonitorPowerScale MAX-ACCESS read-only STATUS current DESCRIPTION "This magnitude of watt-hours for the energy field in emDemandIntervalEnergyUsed." ::= { emDemandEntry 3 } emDemandIntervalMax OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object is the maximum demand ever observed in emDemandIntervalEnergyUsed since the monitoring started. This value is specified in the common billing units of watts-hours with the magnitude of watt-hours (kW-Hr, MW- Hr, etc.) indicated separately in emDemandIntervalEnergyScale." ::= { emDemandEntry 4 } emEnable OBJECT-TYPE SYNTAX INTEGER { enable(1), disable(2) Expires August 5, 2011 [Page 26] Internet-Draft Feb 2010 } MAX-ACCESS read-write STATUS current DESCRIPTION "A control object to activate/de-activate all EnergyMonitor Entities on the SNMP agent (e.g. Switch). enable: enables all EnergyMonitor Entities. disable: disables all EnergyMonitor Entities" ::= { energyMonitorMIBObjects 5 } emVersion OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "This object specifies the current version of the EnergyMonitor software running on a EnergyMonitor Entity." ::= { energyMonitorMIBObjects 6 } -- Notifications emLevelChange NOTIFICATION-TYPE OBJECTS { emIndex, emEnergyLevel } STATUS current DESCRIPTION "The SNMP entity generates the EmLevelChange when the value of emEnergyLevel has changed for the EnergyMonitor Entity represented by the emIndex" ::= { energyMonitorMIBNotifs 1 } -- Conformance energyMonitorMIBCompliances OBJECT IDENTIFIER ::= { energyMonitorMIB 3 } energyMonitorMIBGroups OBJECT IDENTIFIER ::= { energyMonitorMIB 4 } energyMonitorMIBFullCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "When this MIB is implemented with support for read-create, then such an implementation can claim full compliance. Such devices can then Expires August 5, 2011 [Page 27] Internet-Draft Feb 2010 be both monitored and configured with this MIB." MODULE -- this module MANDATORY-GROUPS { energyMonitorMIBTableGroup, energyMonitorMIBLevelTableGroup, energyMonitorMIBNotifGroup } ::= { energyMonitorMIBCompliances 1 } energyMonitorMIBReadOnlyCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "When this MIB is implemented without support for read-create (i.e. in read-only mode), then such an implementation can claim read-only compliance. Such a device can then be monitored but can not be configured with this MIB." MODULE -- this module MANDATORY-GROUPS { energyMonitorMIBTableGroup, energyMonitorMIBLevelTableGroup, energyMonitorMIBNotifGroup } OBJECT emName MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT emRoleDescription MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT emDomainName MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT emEnable MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { energyMonitorMIBCompliances 2 } -- Units of Conformance Expires August 5, 2011 [Page 28] Internet-Draft Feb 2010 energyMonitorMIBTableGroup OBJECT-GROUP OBJECTS { -- Note that object emIndex is NOT -- included since it is not-accessible emEnergyMonitorId, emPhysicalEntity, emDomainName, emName, emRoleDescription, emEnergyUnits, emEnergyUsage, emEnergyUsageNameplate, emEnergyUsageAccuracy, emEnergyUsageCaliber, emEnergyLevel, emEnergyUsageCategory, emEnable, emVersion } STATUS current DESCRIPTION "This group contains the collection of all the objects related to the Energy Monitor Entity." ::= { energyMonitorMIBGroups 1 } energyMonitorMIBLevelTableGroup OBJECT-GROUP OBJECTS { -- emLevelIndex, emLevelMaxUsage, emLevelEnergyUnits } STATUS current DESCRIPTION "This group contains the collection of all the objects related to the Energy Monitor level." ::= { energyMonitorMIBGroups 2 } energyMonitorMIBNotifGroup NOTIFICATION-GROUP NOTIFICATIONS { emLevelChange -- emLevelIndex } STATUS current DESCRIPTION Expires August 5, 2011 [Page 29] Internet-Draft Feb 2010 "This group contains the notifications for the energy monitoring MIB Module." ::= { energyMonitorMIBGroups 3 } END 7. Security Considerations Some of the readable objects in these MIB modules (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: All other objects and tables contain no data that is considered sensitive. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in these MIB modules. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of these MIB modules is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 8. IANA Considerations The MIB module in this document uses the following IANA-assigned OBJECT IDENTIFIER values recorded in the SMI Numbers registry: Descriptor OBJECT IDENTIFIER value ---------- ----------------------- EnergyMonitorMIB { mib-2 xxxxx } Expires August 5, 2011 [Page 30] Internet-Draft Feb 2010 Additions to this MIB module are subject to Expert Review [RFC5226], i.e., review by one of a group of experts designated by an IETF Area Director. The group of experts MUST check the requested MIB objects for completeness and accuracy of the description. Requests for MIB objects that duplicate the functionality of existing objects SHOULD be declined. The smallest available OID SHOULD be assigned to a new MIB objects. The specification of new MIB objects SHOULD follow the structure specified in Section 6 and MUST be published using a well- established and persistent publication medium. 9. References 9.1. Normative References [RFC4133] Bierman, A. and K. McCloghrie, "Entity MIB (Version 3)", RFC 4133, August 2005. [RFC-3621] Berger, A., and D. Romascanu, "Power Ethernet MIB", RFC3621, December 2003. [RFC3433] Bierman, A., Romascanu, D., and K. Norseth, "Entity Sensor Management Information Base", RFC 3433, December 2002. [RFC4268] Chisholm, S. and D. Perkins, "Entity State MIB", RFC 4268,November 2005. [POWER-MON-REQ] Quittek, J., Winter, R., Dietz, T., Claise, B., and M. Chandramouli, "Requirements for Power Monitoring", draft-quittek-power-monitoring- requirements-00 (work in progress), October 2009. [ACPI] "Advanced Configuration and Power Interface Specification", http://www.acpi.info/spec30b.htm 9.2. Informative References [RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, BCP 14, RFC 2119, March 1997. Expires August 5, 2011 [Page 31] Internet-Draft Feb 2010 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC5226] Narten, T. Alverstrand, H., A. and K. McCloghrie, "Guidelines for Writing an IANA Considerations Section in RFCs ", BCP 26, RFC 5226, May 2008. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet Standard Management Framework ", RFC 3410, December 2002. [RFC2863] McCloghrie, K., Kastenholz, F., "The Interfaces Group MIB", RFC 2863, June 2000. [RFC3418] Presun, R., Case, J., McCloghrie, K., Rose, M, and S. Waldbusser, " Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", RFC3418, December 2002. 10. Authors' Addresses Benoit Claise Cisco Systems Inc. De Kleetlaan 6a b1 Diegem 1813 BE Phone: +32 2 704 5622 Email: bclaise@cisco.com Mouli Chandramouli Cisco Systems, Inc. Sarjapur Outer Ring Road Expires August 5, 2011 [Page 32] Internet-Draft Feb 2010 Bangalore, IN Phone: +91 80 4426 3947 Email: moulchan@cisco.com John Parello Cisco Systems Inc. 3550 Cisco Way San Jose, California 95134 US Phone: +1 408 525 2339 Email: jparello@cisco.com Brad Schoening Cisco Systems Inc. 3550 Cisco Way San Jose, California 95134 US Phone: +1 408 525 2339 Email: braschoe@cisco.com Expires August 5, 2011 [Page 33]