Network Working Group J. Parello Internet-Draft B. Claise Intended Status: Standards Track Cisco Systems, Inc. Expires: January 8, 2012 July 8, 2011 Energy-aware Networks and Devices MIB draft-ietf-eman-energy-aware-mib-02 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 September, 2011. Expires January 8 2012 [Page 1] Internet-Draft July 2011 Copyright Notice Copyright (c) 2011 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 Simplified BSD License. Abstract This document defines a subset of the Management Information Base (MIB) for power and energy monitoring of devices. The module addresses devices identification, context information, and the relationship between reporting devices, remote devices, and monitoring probes. Conventions used in this document 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 RFC 2119 [RFC2119]. Table of Contents 1. Introduction.............................................. 3 1.1. Energy Management Document Overview.................. 4 2. The Internet-Standard Management Framework................ 4 3. Requirements and Use Cases................................ 5 4. Terminology............................................... 5 5. Architecture Concepts Applied to the MIB Module........... 6 5.1 Power Monitor Information............................. 8 5.1.1. Power Monitor Identifier........................ 8 5.1.2. Links to other Identifiers...................... 8 5.1.3. Power Monitor Name.............................. 9 5.1.4. Power Monitor Meter Domain...................... 9 5.1.5. Power Monitor Identity Persistence............. 10 Expires January 8, 2012 [Page 2] Internet-Draft July 2011 5.2 Power Monitor Parent and Child....................... 10 5.3 Power Monitor Context................................ 11 6. Structure of the MIB..................................... 12 7. MIB Definitions.......................................... 12 8. Security Considerations.................................. 25 9. IANA Considerations...................................... 26 10. References.............................................. 27 10.1. Normative References............................... 27 10.2. Informative References............................. 28 11. Acknowledgments......................................... 28 OPEN ISSUES: 1. The terminology must be consistent for all EMAN drafts, and this one included. 2. Apparently, a Child can have different parents in the monitoring, control, and power distribution. And a Child can have multiple parents in each of the topologies. In other words, the different relationships as defined in the EMAN framework must be inserted in this draft, and the pmParentProxyAbilities re-worked. 3. Length and format of pmUUID. The pmUUID should be a unique id that identifies the device in the universe. A UUID using RFC 4122 seems to suffice. However an x.509 certificate conforming to RFC 5280 could also be appropriate. We have specified the field as variable 16 bytes but would like feedback and consensus on the format that is appropriate. 4. Some editor's notes. 1. Introduction The EMAN standards provides network administrators with energy management. This document defines a subset of the Management Information Base (MIB) for use with network management protocols for power and energy monitoring of network devices and devices attached to the network, as specified in the Power Management Architecture [EMAN-FMWK], which in turn, is based on the Power Monitoring Requirements [EMAN-REQ]. This focus of this MIB module is on monitoring energy-aware networks and devices. The module addresses device Expires January 8, 2012 [Page 3] Internet-Draft July 2011 identification, context information, and relationships between reporting devices, remote devices, and monitoring probes. Devices and their sub-components may be characterized by the power-related attributes of a physical entity present in the ENTITY MIB [RFC4133], even though ENTITY MIB compliance is not a requirement due to the variety and broad base of devices concerned with energy management. 1.1. Energy Management Document Overview This document, which specifies the Energy-Aware Networks and Devices MIB is based on the Energy Management Framework [EMAN- FMWK], and meets the requirements specified in the Energy Management requirements [EMAN-REQ], which allows networks and devices to become energy aware. The Power and Energy Monitoring MIB [EMAN-MON-MIB] contains the managed objects for monitoring of power states, along with the power and energy consumption of network devices. Monitoring of power states includes: retrieving power states, properties of power states, current power state, power state transitions, and power state statistics. This MIB provides the detailed properties of the actual energy rate (power) and of accumulated energy, along with the power quality. The applicability statement document [EMAN-AS] provides the list of use cases, cross-reference between existing standards and the EMAN standard, and shows how the EMAN framework relates to other frameworks. EDITOR'S NOTE: [EMAN-MON-MIB] and [EMAN-AS] are not EMAN working group documents. Hence, these references will be changed in the future. 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 with Expires January 8, 2012 [Page 4] Internet-Draft July 2011 SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 3. Requirements and Use Cases Requirements for power and energy monitoring for networking devices are specified in [EMAN-REQ]. The requirements in [EMAN- REQ] include communications network devices, such as switches, routers, and various connected endpoints. Beyond the networking devices, for a power monitoring framework to be useful, it should also apply to facility meters, power distribution units, gateway proxies for commercial building control, home automation devices, and devices that interface with the utility and/or smart grid. The use cases are specified in the EMAN applicability statement document [EMAN-AS]. EDITOR'S NOTE: say a few words about the use cases when we will have a stable version of the EMAN applicability statement document. Accordingly, the scope of the MIB module in this document is in accordance to the requirements specified in [EMAN-REQ] and the use cases in [EMAN-AS]. 4. Terminology The definitions of basic terms like Energy Management, Energy Monitoring, "Power, Energy, and Energy Consumption", Power Monitor, Power Monitor Parent, Power Monitor Child, Power Monitor Meter Domain, Power Level, and Manufacturer Power Level, Nameplate Power, Power Proxy, Power Aggregator, Power Distributor can be found in the Power Management Architecture [EMAN-FMWK]. EDITOR'S NOTE: all terms will be copied over in the final version of the draft. The reason is that [EMAN-FMWK] is an informational document, while this document is standard track. Expires January 8, 2012 [Page 5] Internet-Draft July 2011 5. Architecture Concepts Applied to the MIB Module This section describes the basic concepts specified in the Power Monitor Architecture [EMAN-FMWK], with specific information related to the MIB module specified in this document The following diagram shows the relationship of the identifying information. Expires January 8, 2012 [Page 6] Internet-Draft July 2011 +-------------------------+ | _Child Specific Info __ | +--------------------------+ | ----------------------- | | Context Information | | pmParentId | | ------------------------ | | pmParentProxyAbilities | | pmRoleDescription | | _pmMgmtMacAddress (*) | | pmKeywords | | pmMgmtAddress (*) | | pmImportance | | pmMgmtAddressType (*) | | pmPowerCategory | | pmMgmtDNSName (*) | +--------------------------+ +-------------------------+ | | | | | | v v +-----------------------------------------+ | Power Monitor Information | |_--------------------------------------- | |->| pmIndex | | | pmUUID | | | pmName | | | pmDomainName | | +-----------------------------------------+ | | | | +-------------------------------+ |--| Links to other Identifiers | | ----------------------------- | | pmPhysicalEntity (**) | | pmEthPortIndex (***) | | pmEthPortGrpIndex (***) | | pmLldpPortNumber (****) | | pmAlternateKey | +-------------------------------+ (*) May also be implemented by the Parent (**) Link with the ENTITY MIB [RFC4133] (***) Link with the Power over Ethernet MIB [RFC3621] (****) Link with LLDP MIBs [LLDP-MIB] [LLDP-MED-MIB] Figure 1: MIB Objects Grouping As displayed in figure 1, there are four different types of MIB objects in the ENERGY-AWARE-MIB module, linked to the Power Monitor Information objects, and in particular the pmIndex index: Expires January 8, 2012 [Page 7] Internet-Draft July 2011 1) The Power Monitor Information. See Section 5.1 Power Monitor Information" 2) The links to other MIB modules. See Section 5.1.2. "Links to other Identifiers" 3) The Power Monitor Child specific information. See Section 5.2 Power Monitor Parent and Child" 4) The Context Information. See Section 5.3 Power Monitor Context" 5.1 Power Monitor Information Refer to the "Power Monitor Information" section in [EMAN-FMWK] for background information. An energy aware device is considered an instance of a Power Monitor as defined in the [EMAN-FMWK]. 5.1.1. Power Monitor Identifier Every Power Monitor MUST HAVE a unique Power Monitor index pmIndex, which identifies the primary Power Monitor information in the ENERGY-AWARE-MIB module pmTable table. The pmIndex is a unique index greater than zero for each Power Monitor. It is recommended that values be assigned sequentially starting from 1. The pmIndex is complemented by the Power Monitor Universally Unique Identifier [RFC4122] in the pmUUID MIB object. 5.1.2. Links to other Identifiers While the pmIndex is the primary index for all MIB objects in the ENERGY-AWARE-MIB module, the Energy Management Systems (EMS) and Network Management Systems (NMS) must be able to make the link with the identifier(s) in other supported MIB modules. The Power Monitor pmPhysicalEntity MUST contain the entPhysicalIndex from the ENTITY MIB [RFC4133], if the ENTITY- MIB is supported by the Power Monitor SNMP agent. The Power Monitor pmethPortIndex and pmethPortGrpIndex MUST contain the values of pethPsePortIndex and pethPsePortGroupIndex from the Power over Ethernet MIB [RFC3621], if the Power over Ethernet MIB is supported by the Power Monitor SNMP agent. Expires January 8, 2012 [Page 8] Internet-Draft July 2011 The Power Monitor pmLldpPortNumber MUST contain the lldpLocPortNum from the LLDP MIB [LLDP-MIB], if the LLDP-MED MIB is supported on the Power Monitor SNMP agent. The intent behind the links to the other MIB module identifier(s) is certainly not to limit the scope of the ENERGY- AWARE-MIB to cases where the ENTITY-MIB, the Power over Ethernet, and the LLDP MIB modules are supported by the SNMP agent. Indeed, some use cases would not implement any of these three MIB modules on the Power Monitor. However, in situation where any of these three MIB modules is implemented, the EMS/NMS must be able to correlate the instances in the different MIB modules. The pmAlternateKey alternate key object specifies a manufacturer defined string that can be used to identify the Power Monitor. Since EMS/NMS may need to correlate objects across management systems, this alternate key is provided to facilitate such a link. This optional value is intended as a foreign key or alternate identifier for a manufacturer or EMS/NMS to use to correlate the unique Power Monitor Id in other systems or namespaces. If an alternate key is not available or is not applicable then NULL should be returned. 5.1.3. Power Monitor Name Every Power Monitor SHOULD have a printable name pmName. If the entPhysicalName is present for the respective pmPhysicalEntity, i.e. if the ENTITY-MIB [RFC4133] is supported, then the pmName SHOULD be identical to the entPhysicalName value specified in the ENTITY-MIB. If the entPhysicalName is not present, the process to assign the pmName can be implementation specific. Example: DNS Name, MAC address in canonical form, ifName, etc. Possible conventions for pmName are: a text string uniquely identifying the Power Monitor, textual DNS name, MAC-address of the device, interface ifName, etc... As an example, in the case of IP phones that don't support the ENTITY-MIB, the pmName can be the device DNS name, while in the case of router/switch line cards (which support the ENTITY-MIB), the pmName should contain the entPhysicalName. 5.1.4. Power Monitor Meter Domain Refer to the "Power Monitor Meter Domain" section in [EMAN-FMWK] for background information. Expires January 8, 2012 [Page 9] Internet-Draft July 2011 When a Power Monitor Parent acts as a Power Aggregator or a Power Proxy, the Power Monitor Parent and its Power Monitor Child/Children MUST be members of the same Power Monitor Meter Domain, specified by the pmDomainName MIB Object. The pmDomainName, which is an element of the pmTable, is a read- write MIB object. Note that the Power Monitor MUST belong to a single Power Monitor Meter Domain or in other words, a Power Monitor can not belong to more than one Meter Domain. The Power Monitor Meter Domain should map 1-1 with a metered or sub-metered portion of the site. The Power Monitor Meter Domain MUST be configured on the Power Monitor Parent. The Power Monitor Children MAY inherit their domain parameters from the Power Monitor Parent or the Power Monitor Meter Domain MAY be configured directly in a Power Monitor Child. 5.1.5. Power Monitor Identity Persistence In some situations, the Power Monitor identity information should be persistent even after a device reload. For example, in a static setup where a switch monitors a series of connected PoE phones, there is a clear benefit for the NMS if the pmIndex and all associated information persist, as it saves a network discovery. However, in other situations, such as a wireless access point monitoring the mobile user PCs, there is not much advantage to persist the Power Monitor Information. Therefore, a specific MIB object, the pmTablePersistence, enables and disables the persistence globally for all Power Monitors information in the ENERGY-AWARE-MIB module. 5.2 Power Monitor Parent and Child Refer to the "Power Monitor Parent and Child" section in [EMAN- FMWK] for background information. In order to link the Power Monitor Child and the Power Monitor Parent, the pmParentId is introduced. The Power Monitor Child MUST set the pmParentId content to its Power Monitor Parent pmUUID. In the case of Power Monitor Parent, the pmParentId MUST be set to the null string. The Power Monitor Child can indicate that it wants its Power Monitor Parent to proxy capabilities such as, energy reporting, power state configurations, non physical wake capabilities (such Expires January 8, 2012 [Page 10] Internet-Draft July 2011 as Wake-on-LAN)), or any combination of capabilities. These capabilities are indicated in the pmParentProxyAbilities object. In the case of Power Monitor Parent, the pmParentProxyAbilities MUST be set to "none" (0). Since the communication between the Power Monitor Parent and Power Monitor Child may not be via SNMP (as defined in EMAN- FMWK), a Power Monitor Child can have additional MIB objects that can be used for easier identification by the NMS. The optional objects pmMgmtMacAddress, omMgmtAddressType pmMgmtDNSName can be used to help identify the relationship between the child and other NMS objects. These objects can be used as an alternate key to help link the Power Monitor with other keyed information that may be stored within the NMS(s) or EMS(s). The pmParentId, pmParentProxyAbilities, pmMgmtMacAddress, pmMgmtAddress, pmMgmtAddressType, and pmMgmtDNSName MIB objects SHOULD be implemented for Power Monitor Children, and MAY be implemented for Power Monitor Parents. The pmParentId, and pmParentProxyAbilities MUST be implemented by Power Monitor Children. The pmMgmtMacAddress, pmMgmtAddress, pmMgmtAddressType, and pmMgmtDNSName MIB objects SHOULD be implemented for Power Monitor Children, and MAY be implemented for Power Monitor Parents. 5.3 Power Monitor Context Refer to the "Power Monitor Context" section in [EMAN-FMWK] for background information. A Power Monitor can provide a pmImportance value in the range of 1..100 to help differentiate the use or relative value of the device. The importance range is from 1 (least important) to 100 (most important). The default importance value is 1. A Power Monitor can provide a set of pmKeywords. These keywords are a list of tags that can be used for grouping and summary reporting within or between Power Monitor Meter Domains. Additionally, a Power Monitor can provide a pmRoleDescription string that indicates the purpose the Power Monitor serves in the network or for the site/business. Expires January 8, 2012 [Page 11] Internet-Draft July 2011 6. Structure of the MIB The primary MIB object in this MIB module is the energyAwareMIB Object. The pmTable table of energyAwareMIB Object describes an entity in the network that is a Power Monitor according the [EMAN-FMWK]. +-- rwn TruthValue pmTablePersistence(1) +- pmTable(2) | +- pmEntry(1) [pmIndex] | | | +-- --- Integer32 pmIndex(1) | +-- r-n PowerMonitorUUID pmUUID(2) | +-- r-n PhysicalIndexOrZero pmPhysicalEntity(3) | +-- r-n PethPsePortIndexOrZero pmEthPortIndex(4) | +-- r-n PethPsePortGroupIndexOrZero pmEthPortGrpIndex(5) | +-- r-n LldpPortNumberOrZero pmLldpPortNumber(6) | +-- rwn SnmpAdminString pmName(7) | +-- rwn SnmpAdminString pmDomainName(8) | +-- rwn SnmpAdminString pmRoleDescription(9) | +-- rwn MacAddress pmMgmtMacAddress(10) | +-- r-n pmMgmtAddressType pmMgmtAddressType(11) | +-- r-n InetAddress pmMgmtAddress(12) | +-- r-n SnmpAdminString pmMgmtDNSName(13) | +-- rwn SnmpAdminString pmAlternateKey(14) | +-- rwn PowerMonitorKeywordList pmKeywords(15) | +-- rwn Integer32 pmImportance(16) | +-- r-n INTEGER pmPowerCategory(17) | +-- r-n PowerMonitorId pmParentId(18) | +-- r-n BITS pmParentProxyAbilities(19) 7. MIB Definitions -- ************************************************************ -- -- -- This MIB is used for describing the identity and the -- context information of power monitors in network -- -- -- ************************************************************* Expires January 8, 2012 [Page 12] Internet-Draft July 2011 ENERGY-AWARE-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, mib-2, Integer32 FROM SNMPv2-SMI TEXTUAL-CONVENTION, MacAddress, TruthValue FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF SnmpAdminString FROM SNMP-FRAMEWORK-MIB InetAddressType, InetAddress FROM INET-ADDRESS-MIB PhysicalIndexOrZero FROM ENTITY-MIB; energyAwareMIB MODULE-IDENTITY LAST-UPDATED "201103050000Z" ORGANIZATION "IETF EMAN Working Group" CONTACT-INFO "WG Charter: http://datatracker.ietf.org/wg/eman/charter/ Mailing Lists: General Discussion: eman@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/eman Archive: http://www.ietf.org/mail-archive/web/eman Editors: John Parello Cisco Systems, Inc. 3550 Cisco Way San Jose, California 95134 US Phone: +1 408 525 2339 Email: jparello@cisco.com Benoit Claise Cisco Systems, Inc. De Kleetlaan 6a b1 Degem 1831 Belgium Expires January 8, 2012 [Page 13] Internet-Draft July 2011 Phone: +32 2 704 5622 Email: bclaise@cisco.com" DESCRIPTION "This MIB is used for describing the identity and the context information of power monitors in network " REVISION "201103050000Z" DESCRIPTION "Initial version, published as RFC XXXX." ::= { mib-2 xxxxx } energyAwareMIBNotifs OBJECT IDENTIFIER ::= { energyAwareMIB 0 } energyAwareMIBObjects OBJECT IDENTIFIER ::= { energyAwareMIB 2 } energyAwareMIBConform OBJECT IDENTIFIER ::= { energyAwareMIB 3 } -- Textual Conventions PowerMonitorUUID ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This object indicates the Power Monitor Universally Unique Identifier." REFERENCE "IETF RFC 4122" SYNTAX OCTET STRING (SIZE (16)) PethPsePortIndexOrZero ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "This textual convention is an extension of the pethPsePortIndex convention, which defines a greater than zero value used to identify a power Ethernet PSE port. This extension permits the additional value of zero. The semantics of the value zero are object-specific and must, therefore, be defined as part of the description of any object that uses this syntax. Examples of the usage of Expires January 8, 2012 [Page 14] Internet-Draft July 2011 this extension are situations where none or all physical entities need to be referenced." SYNTAX Integer32 (0..2147483647) PethPsePortGroupIndexOrZero::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "This textual convention is an extension of the pethPsePortGroupIndex convention, which defines a greater than zero value used to identify group containing the port to which a power Ethernet PSE is connected. This extension permits the additional value of zero. The semantics of the value zero are object-specific and must, therefore, be defined as part of the description of any object that uses this syntax. Examples of the usage of this extension are situations where none or all physical entities need to be referenced." SYNTAX Integer32 (0..2147483647) LldpPortNumberOrZero ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "This textual convention is an extension of the LldpPortNumber convention specified in the LLDP MIB, which defines a greater than zero value used to uniquely identify each port contained in the chassis (that is known to the LLDP agent) by a port number. This extension permits the additional value of zero. The semantics of the value zero are object-specific and must, therefore, be defined as part of the description of any object that uses this syntax. Examples of the usage of this extension are situations where none or all physical entities need to be referenced." SYNTAX Integer32(0..4096) PowerMonitorKeywordList ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A list of keywords that can be used to group Power Monitors for reporting or searching. If multiple keywords Expires January 8, 2012 [Page 15] Internet-Draft July 2011 are present, then this string will contain all the keywords separated by the ',' character. For example, if a Power Monitor were to be tagged with the keyword values 'hospitality' and 'guest', then the keyword list will be 'hospitality,guest'." SYNTAX OCTET STRING (SIZE (0..255)) -- Objects pmTablePersistence OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This object enables/disables persistence for all entries in the pmTable. A value of True enables the persistence, while a value of False disables the persistence." ::= { energyAwareMIBObjects 1 } pmTable OBJECT-TYPE SYNTAX SEQUENCE OF PmEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table lists Power Monitors." ::= { energyAwareMIBObjects 2 } pmEntry OBJECT-TYPE SYNTAX PmEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describes the attributes of a Power Monitor. Whenever a new Power Monitor is added or deleted a row in the pmTable is added or deleted." INDEX { pmIndex } ::= { pmTable 1 } PmEntry ::= SEQUENCE { pmIndex Integer32, pmUUID PowerMonitorUUID, pmPhysicalEntity PhysicalIndexOrZero, pmEthPortIndex PethPsePortIndexOrZero, pmEthPortGrpIndex PethPsePortGroupIndexOrZero, pmLldpPortNumber LldpPortNumberOrZero, Expires January 8, 2012 [Page 16] Internet-Draft July 2011 pmName SnmpAdminString, pmDomainName SnmpAdminString, pmRoleDescription SnmpAdminString, pmMgmtMacAddress MacAddress, pmMgmtAddressType InetAddressType, pmMgmtAddress InetAddress, pmMgmtDNSName SnmpAdminString, pmAlternateKey SnmpAdminString, pmKeywords PowerMonitorKeywordList, pmImportance Integer32, pmPowerCategory INTEGER, pmParentId PowerMonitorUUID, pmParentProxyAbilities BITS } pmIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique value, greater than zero, for each Power Monitor. It is recommended that values be assigned sequentially starting from 1." ::= { pmEntry 1 } pmUUID OBJECT-TYPE SYNTAX PowerMonitorUUID MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the Power Monitor UUID identifier." ::= { pmEntry 2 } pmPhysicalEntity OBJECT-TYPE SYNTAX PhysicalIndexOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the index of a physical entity in the ENTITY MIB [RFC4133]. 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." ::= { pmEntry 3 } pmEthPortIndex OBJECT-TYPE SYNTAX PethPsePortIndexOrZero Expires January 8, 2012 [Page 17] Internet-Draft July 2011 MAX-ACCESS read-only STATUS current DESCRIPTION "This variable uniquely identifies the power Ethernet port to which the attached device is connected [RFC3621]. If such a power Ethernet port cannot be specified or is not known then the object is zero." ::= { pmEntry 4 } pmEthPortGrpIndex OBJECT-TYPE SYNTAX PethPsePortGroupIndexOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "This variable uniquely identifies the group containing the port to which a power Ethernet PSE is connected [RFC3621]. If such a group cannot be specified or is not known then the object is zero." ::= { pmEntry 5 } pmLldpPortNumber OBJECT-TYPE SYNTAX LldpPortNumberOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "This variable uniquely identifies the port component (contained in the local chassis with the LLDP agent) as defined by the lldpLocPortNum in the [LLDP-MIB] and [LLDP-MED-MIB]. If such a port number cannot be specified or is not known then the object is zero." ::= { pmEntry 6 } pmName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies a printable name, a text string, for the Power Monitor. If the entPhysicalName is present for the respective pmPhysicalEntity, i.e. if the ENTITY- MIB [RFC4133] is supported, then the pmName SHOULD be identical to the entPhysicalName. If entPhysicalName is not present, the process to assign the pmName can be implementation specific. Example: DNS Name, MAC address in canonical form, ifName, etc. " ::= { pmEntry 7 } Expires January 8, 2012 [Page 18] Internet-Draft July 2011 pmDomainName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies the name of a Power Monitor Meter Domain for the Power Monitor. This object specifies a null string if no Power Monitor Domain name is configured. The value of pmDomainName must remain constant at least from one re-initialization of the entity's network management system to the next re- initialization." ::= { pmEntry 8 } pmRoleDescription OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies an administratively assigned name to indicate the purpose a Power Monitor serves in the network. For example, we can have a phone deployed to a lobby with pmRoleDescription as 'Lobby phone'. This object specifies a null string if no role description is configured." ::= { pmEntry 9 } pmMgmtMacAddress OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only STATUS current DESCRIPTION "This object specifies a MAC address of the Power Monitor. This object typically only applies to Power Monitor Children. This object can be used as an alternate key to help link the Power Monitor with other keyed information that may be stored within the NMS(s) or EMS(s). The pmMgmtMacAddress MIB object SHOULD be implemented for Power Monitor Children, and MAY be implemented for Power Monitor Parents." ::= { pmEntry 10 } pmMgmtAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only Expires January 8, 2012 [Page 19] Internet-Draft July 2011 STATUS current DESCRIPTION "This object specifies the pmMgmtAddress type, i.e. an IPv4 address or an IPv6 address. This object MUST be implemented when pmMgmtAddress is populated. The pmMgmtAddressType MIB object SHOULD be implemented for Power Monitor Children, and MAY be implemented for Power Monitor Parents." ::= { pmEntry 11 } pmMgmtAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "This object specifies the management address as an IPv4 address or IPv6 address of Power Monitor. The IP address type, i.e. IPv4 or IPv6, is determined by the pmMgmtAddressType value. This object can be used as an alternate key to help link the Power Monitor with other keyed information that may be stored within the NMS(s) or EMS(s). The pmMgmtAddress MIB object SHOULD be implemented for Power Monitor Children, and MAY be implemented for Power Monitor Parents." ::= { pmEntry 12 } pmMgmtDNSName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "This object specifies the DNS name of the pmMgmtAddress. This object can be used as an alternate key to help link the Power Monitor with other keyed information that may be stored within the NMS(s) or EMS(s). The pmMgmtDNSName MIB objects SHOULD be implemented for Power Monitor Children, and MAY be implemented for Power Monitor Parents." ::= { pmEntry 13 } pmAlternateKey OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies a manufacturer defined string that can be used to identify the Power Monitor. Since Energy Expires January 8, 2012 [Page 20] Internet-Draft July 2011 Management Systems (EMS) and Network Management Systems (NMS) may need to correlate objects across management systems, this alternate key is provided to provide such a link. This optional value is intended as a foreign key or alternate identifier for a manufacturer or EMS/NMS to use to correlate the unique Power Monitor Id in other systems or namespaces. If an alternate key is not available or is not applicable then NULL should be returned." ::= { pmEntry 14 } pmKeywords OBJECT-TYPE SYNTAX PowerMonitorKeywordList MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies a list of keywords that can be used to group Power Monitors for reporting or searching. This object specifies the null string if no keywords have been configured. If multiple keywords are present, then this string will contain all the keywords separated by the ',' character. For example, if a Power Monitor were to be tagged with the keyword values 'hospitality' and 'guest', then the keyword list will be 'hospitality,guest'. If write access is implemented and a value is written into the instance, the agent must retain the supplied value in the pmKeywords instance associated with the same physical entity for as long as that entity remains instantiated. This includes instantiations across all re-initializations/reboots of the network management system." ::= { pmEntry 15 } pmImportance OBJECT-TYPE SYNTAX Integer32 (1..100) MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies a ranking of how important the Power Monitor is (on a scale of 1 to 100) compared with other Power Monitors in the same Power Monitor Meter Domain. The ranking should provide a business or operational context for the Power Monitor as compared to other similar Power Monitors. This ranking could be used as input for policy-based network management. Expires January 8, 2012 [Page 21] Internet-Draft July 2011 Although network managers must establish their own ranking, the following is a broad recommendation: 90 to 100 Emergency response 80 to 90 Executive or business critical 70 to 79 General or Average 60 to 69 Staff or support 40 to 59 Public or guest 1 to 39 Decorative or hospitality" DEFVAL { 1 } ::= { pmEntry 16 } pmPowerCategory OBJECT-TYPE SYNTAX INTEGER { consumer(0), producer(1), consumer-producer(2), meter(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object describes the Power Monitor category, which indicates the expected behavior or physical property of the Power Monitor, based on its design. A Power Monitor can be a consumer(0), producer(1) or consumer-producer (2) or meter (3). There are devices with a dual mode - consuming energy and producing of energy and those are identified as consumer- producer. In some cases, a meter is required to measure the power consumption. In such a case, this meter Power Monitor category is meter(3). " ::= { pmEntry 17 } pmParentId OBJECT-TYPE SYNTAX PowerMonitorUUID MAX-ACCESS read-only STATUS current DESCRIPTION "If the current Power Monitor has a Power Monitor Parent, then the parent is uniquely identified by setting pmParentId of the child equal to the pmUUID of the parent. This object only applies to Power Monitor Children. When the Power Monitor is a Power Monitor Expires January 8, 2012 [Page 22] Internet-Draft July 2011 Parent, the pmParentId value MUST be set to the null string. " ::= { pmEntry 18 } pmParentProxyAbilities OBJECT-TYPE SYNTAX BITS { none(0), report(1), configuration(2), wakeonlan(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object describes the capabilities of the Power Monitor Parent (represented by the pmParentId) for the Power Monitor Child, represented by the pmIndex. This object only applies to a Power Monitor Child. None (0) MUST be used when the Power Monitor represented by the pmIndex is a Power Monitor Parent, and no other bit can be set. Report(1) indicates that the Power Monitor Parent reports the usage for the Power Monitor Child. Configuration(2) indicates that the Power Monitor Parent can configure the Power Level for the Power Monitor Child. Wakeonlan(3) indicates that the Power Monitor Parent can wake up the Power Monitor Child, whatever the mechanism." ::= { pmEntry 19 } -- Conformance energyAwareMIBCompliances OBJECT IDENTIFIER ::= { energyAwareMIBObjects 3 } energyAwareMIBGroups OBJECT IDENTIFIER ::= { energyAwareMIBObjects 4 } energyAwareMIBFullCompliance 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." Expires January 8, 2012 [Page 23] Internet-Draft July 2011 MODULE -- this module MANDATORY-GROUPS { energyAwareMIBTableGroup } ::= { energyAwareMIBCompliances 1 } energyAwareMIBReadOnlyCompliance 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 { energyAwareMIBTableGroup } OBJECT pmTablePersistence MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT pmName MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT pmDomainName MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT pmRoleDescription MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT pmKeywords MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT pmImportance MIN-ACCESS read-only DESCRIPTION Expires January 8, 2012 [Page 24] Internet-Draft July 2011 "Write access is not required." ::= { energyAwareMIBCompliances 2 } -- Units of Conformance energyAwareMIBTableGroup OBJECT-GROUP OBJECTS { -- Note that object pmIndex is NOT -- included since it is not-accessible pmTablePersistence, pmUUID, pmPhysicalEntity, pmEthPortIndex, pmEthPortGrpIndex, pmLldpPortNumber, pmName, pmDomainName, pmRoleDescription, pmMgmtMacAddress, pmMgmtAddressType, pmMgmtAddress, pmMgmtDNSName, pmAlternateKey, pmKeywords, pmImportance, pmPowerCategory, pmParentId, pmParentProxyAbilities } STATUS current DESCRIPTION "This group contains the collection of all the objects related to the PowerMonitor." ::= { energyAwareMIBGroups 1 } END 8. 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. Expires January 8, 2012 [Page 25] Internet-Draft July 2011 There are a number of management objects defined in these MIB modules with a MAX-ACCESS clause of read-write and/or read- create. Such objects MAY be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. The following are the tables and objects and their sensitivity/vulnerability: . Unauthorized changes to the pmDomainName, pmName, pmRoleDescription, pmKeywords, and/or pmImportance MAY disrupt power and energy collection, and therefore any predefined policies defined in the network. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example, by using IPsec), there is still no secure control over 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 GET or SET (change/create/delete) them. 9. 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 ---------- ----------------------- energyAwareMIB { mib-2 xxx } Additions to this MIB module are subject to Expert Review [RFC5226], i.e., review by one of a group of experts designated Expires January 8, 2012 [Page 26] Internet-Draft July 2011 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. 10. References 10.1. Normative 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. [RFC3621] Berger, A., and D. Romascanu, "Power Ethernet MIB", RFC3621, December 2003. [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace ", RFC 4122, July 2005. [RFC4133] Bierman, A. and K. McCloghrie, "Entity MIB (Version 3)", RFC 4133, August 2005. [LLDP-MIB] IEEE 802.1AB-2005, "Management Information Base module for LLDP configuration, statistics, local system data and remote systems data components", May 2005. [LLDP-MED-MIB] ANSI/TIA-1057, "The LLDP Management Information Base extension module for TIA-TR41.4 media endpoint discovery information", July 2005. Expires January 8, 2012 [Page 27] Internet-Draft July 2011 [EMAN-MON-MIB] M. Chandramouli, Schoening, B., Dietz, T., Quittek, J. and B. Claise "Energy and Power Monitoring MIB ", draft-claise-energy-monitoring-mib-08, May 2011. 10.2. Informative References [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet Standard Management Framework ", RFC 3410, December 2002. [RFC5226] Narten, T. Alverstrand, H., A. and K. McCloghrie, "Guidelines for Writing an IANA Considerations Section in RFCs ", BCP 26, RFC 5226, May 2008. [EMAN-REQ] Quittek, J., Winter, R., Dietz, T., Claise, B., and M. Chandramouli, " Requirements for Energy Management", draft-ietf-eman-requirements-03 (work in progress), June 2011. [EMAN-FMWK] Claise, B., Parello, J., Schoening, B., and J. Quittek, "Energy Management Framework", draft-ietf- eman-framework-02, June 2011. [EMAN-AS] Tychon, E., Laherty, M., and B. Schoening, "Energy Management (EMAN) Applicability Statement", draft- tychon-eman-applicability-statement-01.txt, work in progress, March 2011. 11. Acknowledgments The authors would like to thank Juergen Quittek, Brad Schoening, and Mouli Chandramouli for their help, as well as Michael Brown for improving the text dramatically. Authors' Addresses Benoit Claise Expires January 8, 2012 [Page 28] Internet-Draft July 2011 Cisco Systems, Inc. De Kleetlaan 6a b1 Diegem 1813 BE Phone: +32 2 704 5622 Email: bclaise@cisco.com John Parello Cisco Systems, Inc. 3550 Cisco Way San Jose, California 95134 US Phone: +1 408 525 2339 Email: jparello@cisco.com Expires January 8, 2012 [Page 29]