Network Working Group B. Claise Internet-Draft M. Chandramouli Intended Status: Standards Track J. Parello Expires: July 13, 2010 B. Schoening Cisco Systems, Inc. January 13, 2010 Energy Monitoring MIB draft-claise-energy-monitoring-mib-00 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 July 13 2010 [Page 1] Internet-Draft Jan 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 in effect on the date of publication of this document (http://trustee.ietf.org/license- info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. 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 Jan 13, 2011 [Page 2] Internet-Draft Jan 2010 Table of Contents 1. Introduction 4 2. The Internet-Standard Management Framework 4 3. Terminology 4 4. Concepts 5 5. Structure of the MIB 7 5.1. Link with the other IETF MIBs 7 6. MIB Definitions 8 7. Security Considerations 22 8. IANA Considerations 23 9. References 23 9.1. Normative References 23 9.2. Informative References 24 10. Authors' Addresses 24 Expires Jan 13, 2011 [Page 3] Internet-Draft Jan 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 Jan 13, 2011 [Page 4] Internet-Draft Jan 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. The value represents an exponent of 10. 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. 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 Expires Jan 13, 2011 [Page 5] Internet-Draft Jan 2010 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, meter-only, or energy consumer-producer. The emEnergyUsage, specified as Integer32, can have a positive and negative value, allowing to double-check the usage type in emEnergyUsageCategory, or determining whether the EnergyMonitor Entity consumes or produces power in case of "consumer-producer". An Energy Monitor Entity can have a user defined name - emName, an entityPhysicalIndex from the ENTITY-MIB [RFC4133] and its a unique energyMonitor index, emIndex. That EnergyMonitor Entity can be a member of a domain (a logical group). A domain is a logical grouping of EnergyMonitor Entities from the point of monitoring power consumption and also from the point of control of those EnergyMonitor Entities. Thus diverse policies can be configured for EnergyMonitor Entities belonging to different domains. For example, a given EnergyMonitor Entity as described by the emIndex, emPhysicalEntity and enName. 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 "presumed" (in other words not 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. Expires Jan 13, 2011 [Page 6] Internet-Draft Jan 2010 5. Structure of the MIB The primary MIB object in this MIB module is EnergyMonitorMIBObjects. 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 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. The EnergyMonitor Entities that are not modeled by entPhysicalIndex (for e.g. CPU, Memory, storage systems, ...) can be indexed with zero value in emPhysicalEntity, thanks to PhysicalIndexOrZero textual convention. If there are multiple entities with zero as an index, in order to distinguish between multiple entities, a extra index emDeviceId has been proposed, which would ensure uniqueness. 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. RFC 3433 [RFC3433] defines the ENTITY-SENSOR MIB module provides 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 Expires Jan 13, 2011 [Page 7] Internet-Draft Jan 2010 on measurement of energy consumption by networking equipment indexed by the entity MIB, this MIB proposes different power level states of networking equipment and a functionality to configure the power level states. RFC 4268 [RFC4268] 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 state models need to be developed. The Energy Monitoring MIB proposes the power states of entities in the Entity MIB. 6. MIB Definitions -- ************************************************************ -- -- -- 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 FROM SNMPv2-SMI MODULE-COMPLIANCE, NOTIFICATION-GROUP, OBJECT-GROUP FROM SNMPv2-CONF TEXTUAL-CONVENTION FROM SNMPv2-TC SnmpAdminString FROM SNMP-FRAMEWORK-MIB PhysicalIndexOrZero FROM ENTITY-MIB; energyMonitorMIB MODULE-IDENTITY LAST-UPDATED "201001130000Z" ORGANIZATION "Cisco Systems, Inc." Expires Jan 13, 2011 [Page 8] Internet-Draft Jan 2010 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. " ::= { 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 Expires Jan 13, 2011 [Page 9] Internet-Draft Jan 2010 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 to level G2 in ACPI. hibernate(3): No entity features are available. The entity may be available 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 Expires Jan 13, 2011 [Page 10] Internet-Draft Jan 2010 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 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) } Expires Jan 13, 2011 [Page 11] Internet-Draft Jan 2010 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 "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 exa(15), -- 10^15 peta(18), -- 10^18 zetta(21), -- 10^21 yotta(24) -- 10^24 } -- Objects Expires Jan 13, 2011 [Page 12] Internet-Draft Jan 2010 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 EnergyMonitor Entity, the device creates/destroys a row in the emTable." INDEX { emIndex } ::= { emTable 1 } EmEntry ::= SEQUENCE { emIndex Integer32, emDeviceId EnergyMonitorId, emPhysicalEntity PhysicalIndexOrZero, emDomainName SnmpAdminString, emName SnmpAdminString, emRoleDescription SnmpAdminString, emEnergyUnits EnergyMonitorPowerScale, emEnergyUsage Integer32, emEnergyUsageNameplate Integer32, emEnergyUsageAccuracy Integer32, emEnergyUsageCaliber INTEGER, emEnergyLevel EnergyMonitorLevel, emEnergyUsageCategory INTEGER } emIndex OBJECT-TYPE SYNTAX Integer32 (0..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- Expires Jan 13, 2011 [Page 13] Internet-Draft Jan 2010 initialization of the entity's network management system to the next re-initialization." ::= { emEntry 1 } emDeviceId OBJECT-TYPE SYNTAX EnergyMonitorId MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the EnergyMonitor identifier assigned to the device. This object value must be unique within the domain and non-null." ::= { emEntry 2 } emPhysicalEntity OBJECT-TYPE SYNTAX PhysicalIndexOrZero MAX-ACCESS read-only STATUS current 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 domain for the EnergyMonitor Entity. This object specifies a null string if no domain name is configured." ::= { emEntry 4 } emName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies an administratively assigned human readable name to the EnergyMonitor Entity. This object specifies a null string if no name is configured." ::= { emEntry 5 } emRoleDescription OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-write STATUS current Expires Jan 13, 2011 [Page 14] Internet-Draft Jan 2010 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 } 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. 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 maximum consumption for the fully populated EnergyMonitor Entity. This value is specified in SI units of watts with the magnitude of watts (milliwatts, kilowatts, etc.) indicated separately in emEnergyUnits. This value can by used for capacity and provisioning planning. It is typically a value provided via Expires Jan 13, 2011 [Page 15] Internet-Draft Jan 2010 experimentation and prediction from the manufacturer of the entity." ::= { emEntry 9 } emEnergyUsageAccuracy OBJECT-TYPE SYNTAX Integer32 (0..1000) MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates a percentage value in 10ths of a percent representing the accuracy to which the reported usage, reported by the emEnergyUsage can be assumed. Example 101 means the reported usage is accurate to +/- 10.1 percent. This value is zero if the accuracy is unknown." ::= { 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. - 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. 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. For example, a PC Model X draws 200W, while a PC Model Y draws 210W. - 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. Expires Jan 13, 2011 [Page 16] Internet-Draft Jan 2010 - 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. - trusted: This indicates that the usage data reported was reported from another source." ::= { emEntry 11 } emEnergyLevel OBJECT-TYPE SYNTAX EnergyMonitorLevel MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies the current power level for the EnergyMonitor Entity." ::= { emEntry 12 } emEnergyUsageCategory OBJECT-TYPE SYNTAX INTEGER { consumer(1), producer(2), meteronly(3), consumerproducer(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object specifies the energy usage type of the entity. Consumer: This indicates that the entity is consumes energy. Producer: This indicates that the entity generates energy. Meteronly: This indicates that the entity is a meter which reads the energy consumed or produced. Consumerproducer: This indicates that the entity is both a consumer and producer." ::= { emEntry 13 } emLevelTable OBJECT-TYPE SYNTAX SEQUENCE OF EmLevelEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Expires Jan 13, 2011 [Page 17] Internet-Draft Jan 2010 "This table lists the power usage 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 } emLevelMaxUsage OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current Expires Jan 13, 2011 [Page 18] Internet-Draft Jan 2010 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 } emEnable OBJECT-TYPE SYNTAX INTEGER { enable(1), disable(2) } 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 3 } 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 4 } -- Notifications emLevelChange NOTIFICATION-TYPE Expires Jan 13, 2011 [Page 19] Internet-Draft Jan 2010 OBJECTS { emEnergyLevel } STATUS current DESCRIPTION "The SNMP entity generates the EmLevelChange when the value of emEnergyLevel has changed." ::= { 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 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 Expires Jan 13, 2011 [Page 20] Internet-Draft Jan 2010 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 energyMonitorMIBTableGroup OBJECT-GROUP OBJECTS { -- Note that object emIndex is NOT -- included since it is not-accessiblej emDeviceId, 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 } Expires Jan 13, 2011 [Page 21] Internet-Draft Jan 2010 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 "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], Expires Jan 13, 2011 [Page 22] Internet-Draft Jan 2010 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 } 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. Expires Jan 13, 2011 [Page 23] Internet-Draft Jan 2010 [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. [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. 10. Authors' Addresses Benoit Claise Cisco Systems Inc. De Kleetlaan 6a b1 Expires Jan 13, 2011 [Page 24] Internet-Draft Jan 2010 Diegem 1813 BE Phone: +32 2 704 5622 Email: bclaise@cisco.com Mouli Chandramouli Cisco Systems, Inc. Sarjapur Outer Ring Road 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 Jan 13, 2011 [Page 25]