Network Working Group J. Parello Internet-Draft B. Claise Intended Status: Standards Track Cisco Systems, Inc. Expires: September 16, 2012 February 16, 2012 Energy-aware Networks and Devices MIB draft-ietf-eman-energy-aware-mib-04 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, 2012. Expires Sep 16 2012 [Page 1] Internet-Draft Feb 2012 Copyright Notice Copyright (c) 2012 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 a Management Information Base (MIB) for energy management of devices. The module addresses device identification, context information, and the relationships between reporting devices, remote devices, and monitoring devices. 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 Energy Management......................................... 6 Energy Management System (EnMS)........................... 6 ISO Energy Management System.............................. 7 Energy.................................................... 7 Power..................................................... 7 Demand.................................................... 8 Power Quality............................................. 8 Expires Sep 16, 2012 [Page 2] Internet-Draft Feb 2012 Electrical Equipment...................................... 8 Non-Electrical Equipment (Mechanical Equipment)........... 8 Energy Object............................................. 9 Electrical Energy Object.................................. 9 Non-Electrical Energy Object.............................. 9 Energy Monitoring......................................... 9 Energy Control............................................ 9 Energy Management Domain................................. 10 Energy Object Identification............................. 10 Energy Object Context.................................... 10 Energy Object Relationship............................... 10 Aggregation Relationship................................. 11 Metering Relationship.................................... 11 Power Source Relationship................................ 11 Proxy Relationship....................................... 11 Dependency Relationship.................................. 12 Energy Object Parent..................................... 12 Energy Object Child...................................... 12 Power State.............................................. 12 Power State Set.......................................... 13 Nameplate Power.......................................... 13 5. Architecture Concepts Applied to the MIB Module.......... 13 5.1 Energy Object Identification......................... 15 5.2 Energy Object Context................................ 17 5.3 Links to Other Identifiers........................... 17 5.4 Child: Energy Object Relationships................... 18 5.5 Parent: Energy Object Relationships.................. 19 5.6 Energy Object Identity Persistence................... 20 6. Structure of the MIB..................................... 20 7. MIB Definitions.......................................... 21 8. Security Considerations.................................. 37 9. IANA Considerations...................................... 38 10. References.............................................. 39 10.1. Normative References............................... 39 10.2. Informative References............................. 40 11. Acknowledgments......................................... 41 OPEN ISSUE: - Is the UUID always 45 bytes? eoProxyParentUUID has a current size of " OCTET STRING (SIZE(0..45))". 1. Introduction The EMAN standards provide network administrators with a specification for Energy Management. This document defines a Expires Sep 16, 2012 [Page 3] Internet-Draft Feb 2012 subset of a Management Information Base (MIB) for use with network management protocols for Energy monitoring of Electrical Equipments (for example network devices and devices attached to the network.) This focus of the MIB module specified in this document is on monitoring Energy Objects as defined in [EMAN-FMWK]. The module addresses Energy Object Identification, Energy Object Context, and Energy Object Relationships. 1.1. Energy Management Document Overview This document specifies the Energy-Aware Networks (ENERGY-AWARE- MIB ) MIB module. This document is based on the Energy Management Framework [EMAN-FMWK] and meets the requirements specified in the Energy Management requirements [EMAN-REQ]. A second MIB module required by the [EMAN-FMWK], the Power and Energy Monitoring MIB [EMAN-MON-MIB], monitors the Energy Objects for Power States, for the Power and Energy consumption. Power State monitoring includes: retrieving Power States, Power State properties, current Power State, Power State transitions, and Power State statistics. In addition, this MIB module provides the Power Quality properties of the Power and Energy, along with optional characteristics. 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. 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 SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. Expires Sep 16, 2012 [Page 4] Internet-Draft Feb 2012 3. Requirements and Use Cases Requirements for power and energy monitoring for networking devices are specified in [EMAN-REQ]. The scope of devices considered for energy monitoring and management are: communications network devices, routers and switches and various connected endpoints to the network. Beyond the typical networking devices, requirements are specified for metering devices, power distribution units, gateway proxies for commercial building control and batteries which provide in devices. Firstly, to illustrate the importance of energy monitoring in networks and secondly to list some of the important areas to be addressed by the energy management Framework, several use cases and network scenarios are presented in the EMAN applicability statement document [EMAN-AS]. In addition, for each scenario, the target devices for energy management, and how those devices powered and metered are also presented. Based on the requirements [EMAN-REQ], the [EMAN-FMWK] presents an solution approach. Accordingly, the scope of the MIB module in this document is in accordance to the requirements specified in [EMAN-REQ] and [EMAN-FMWK]. 4. Terminology EDITOR'S NOTE: - All terms are copied over from the version 4 of the [EMAN-TERMINOLOGY] draft. The only difference in definition is the Energy Management Domain, which has been improved, to address one comment from Bill Mielke. Hopefully, this version 4 is the final version. - "All" terms have been copied. Potentially, some unused terms might have to be removed (example Electrical Equipment". Alternatively, as this document is the first standard track document in the EMAN WG, it may become the reference document for the terminology (instead of cutting/pasting the terminology in all drafts) Expires Sep 16, 2012 [Page 5] Internet-Draft Feb 2012 - "Reference: herein" has not been copied over from the terminology draft. Energy Management Energy Management is a set of functions for measuring, modeling, planning, and optimizing networks to ensure that the network elements and attached devices use energy efficiently and is appropriate for the nature of the application and the cost constraints of the organization. Reference: Adapted from [ITU-T-M-3400] Example: A set of computer systems that will poll electrical meters and store the readings NOTES: 1. Energy management refers to the activities, methods, procedures and tools that pertain to measuring, modeling, planning, controlling and optimizing the use of energy in networked systems [NMF]. 2. Energy Management is a management domain which is congruent to any of FCAPS areas of management in the ISO/OSI Network Management Model [TMN]. Energy Management for communication networks and attached devices is a subset or part of an organization's greater Energy Management Policies. Energy Management System (EnMS) An Energy Management System is a combination of hardware and software used to administer a network with the primarily purpose being Energy Management. Reference: Adapted from [1037C] Example: A single computer system that polls data from devices using SNMP NOTES: 1. An Energy Management System according to [ISO50001] (ISO-EnMS) is a set of systems or procedures upon which organizations can develop and implement an energy policy, set targets, action plans and take into account legal requirements related to energy use. An EnMS allows organizations to improve energy Expires Sep 16, 2012 [Page 6] Internet-Draft Feb 2012 performance and demonstrate conformity to requirements, standards, and/or legal requirements. 2. Example ISO-EnMS: Company A defines a set of policies and procedures indicating there should exist multiple computerized systems that will poll energy from their meters and pricing / source data from their local utility. Company A specifies that their CFO should collect information and summarize it quarterly to be sent to an accounting firm to produce carbon accounting reporting as required by their local government. 3. For the purposes of EMAN, the definition from [1037C] is the preferred meaning of an Energy Management System (EnMS). The definition from [ISO50001] can be referred to as ISO Energy Management System (ISO-EnMS). ISO Energy Management System Energy Management System as defined by [ISO50001] Energy That which does work or is capable of doing work. As used by electric utilities, it is generally a reference to electrical energy and is measured in kilo-watt hours (kWh). Reference: [IEEE100] NOTES 1. Energy is the capacity of a system to produce external activity or perform work [ISO50001] Power The time rate at which energy is emitted, transferred, or received; usually expressed in watts (or in joules per second). Reference: [IEEE100] Expires Sep 16, 2012 [Page 7] Internet-Draft Feb 2012 Demand The average value of power or a related quantity over a specified interval of time. Note: Demand is expressed in kilowatts, kilovolt-amperes, kilovars, or other suitable units. Reference: [IEEE100] NOTES: 1. typically kilowatts 2. Energy providers typically bill by Demand measurements as well as for maximum Demand per billing periods. Power values may spike during short-terms by devices, but Demand measurements recognize that maximum Demand does not equal maximum Power during an interval. Power Quality Characteristics of the electric current, voltage and frequencies at a given point in an electric power system, evaluated against a set of reference technical parameters. These parameters might, in some cases, relate to the compatibility between electricity supplied in an electric power system and the loads connected to that electric power system. Reference: [IEC60050] Electrical Equipment A general term including materials, fittings, devices, appliances, fixtures, apparatus, machines, etc., used as a part of, or in connection with, an electric installation. Reference: [IEEE100] Non-Electrical Equipment (Mechanical Equipment) A general term including materials, fittings, devices appliances, fixtures, apparatus, machines, etc., used Expires Sep 16, 2012 [Page 8] Internet-Draft Feb 2012 as a part of, or in connection with, non-electrical power installations. Reference: Adapted from [IEEE100] Energy Object An Energy Object (EO) is a piece of equipment that is part of or attached to a communications network that is monitored, controlled, or aids in the management of another device for Energy Management. Electrical Energy Object An Electrical Energy Object (EEO) is an Energy Object that is a piece of Electrical Equipment Non-Electrical Energy Object A Non-Electrical Energy Object (NEEO) an Energy Object that is a piece of Non-Electrical Equipment. Energy Monitoring Energy Monitoring is a part of Energy Management that deals with collecting or reading information from Energy Objects to aid in Energy Management. NOTES: 1. This could include Energy, Power, Demand, Power Quality, Context and/or Battery information. Energy Control Energy Control is a part of Energy Management that deals with directing influence over Energy Objects. NOTES: 1. Typically in order to optimize or ensure its efficiency. Expires Sep 16, 2012 [Page 9] Internet-Draft Feb 2012 Energy Management Domain An Energy Management Domain is a set of Energy Objects where all objects in the domain are considered one unit of management. For example, power distribution units and all of the attached Energy Objects are part of the same Energy Management Domain. For example, all EEO's drawing power from the same distribution panel with the same AC voltage within a building, or all EEO's in a building for which there is one main meter, would comprise an Energy Management Domain. NOTES: 1. Typically, this set will have as members all EO's that are powered from the same source. Energy Object Identification Energy Object Identification is a set of attributes that enable an Energy Object to be: uniquely identified among all Energy Management Domains; linked to other systems; classified as to type, model, and or manufacturer Energy Object Context Energy Object Context is a set of attributes that allow an Energy Management System to classify the use of the Energy Object within an organization. NOTES: 1. The classification could contain the use and/or the ranking of the Energy Object as compared to other Energy Objects in the Energy Management Domain. Energy Object Relationship An Energy Objects Relationship is a functional association between one or more Energy Objects NOTES Expires Sep 16, 2012 [Page 10] Internet-Draft Feb 2012 1. Relationships can be named and could include Aggregation, Metering, Power Source, Proxy and Dependency. Aggregation Relationship An Energy Object may aggregate the Energy Management information of one or more Energy Objects and is referred to as an Aggregation Relationship. NOTES: 1. Aggregate values may be obtained by reading values from multiple Energy Objects and producing a single value of more significant meaning such as average, count, maximum, median, minimum, mode and most commonly sum [SQL]. Metering Relationship An Energy Object may measure the Power or Energy of another Energy Object(s) and is referred to as a Metering Relationship. Example: a PoE port on a switch measures the Power it provides to the connected Energy Object. Power Source Relationship An Energy Object may be the source of or distributor of Power to another Energy Object(s) and is referred to as a Power Source Relationship. Example: a PDU provides power for a connected host. Proxy Relationship An Energy Object that provides Energy Management capabilities on behalf of another Energy Object is referred to a Proxy Relationship. Example: a protocol gateways device for Building Management Systems (BMS) with subtended devices. Expires Sep 16, 2012 [Page 11] Internet-Draft Feb 2012 Dependency Relationship An Energy Object may be a component of or rely completely upon another Energy Object to operate and is referred to as a Dependency Relationship. Example: A Switch chassis with multiple line cards. Energy Object Parent An Energy Object Parent is an Energy Object that participates in an Energy Object Relationships and is considered as providing the capabilities in the relationship. Energy Object Child An Energy Object Child is an Energy Object that participates in an Energy Object Relationships and is considered as receiving the capabilities in the relationship. Power State A Power State is a condition or mode of a device that broadly characterizes its capabilities, power consumption, and responsiveness to input. Reference: Adapted from [IEEE1621] NOTES: 1. A Power State can be seen as a power setting of an Energy Object that influences the power consumption, the available functionality, and the responsiveness of the Energy Object. 2. A Power State can be viewed as one method for Energy Control Expires Sep 16, 2012 [Page 12] Internet-Draft Feb 2012 Power State Set A collection of Power States that comprise one named or logical grouping of control is a Power State Set. Example: The states {on, off, and sleep} as defined in [IEEE1621], or the 16 power states as defined by the [DMTF] can be considered two different Power State Sets. Nameplate Power The Nameplate Power is the maximal (nominal) Power that a device can support. NOTES: 1. This is typically determined via load testing and is specified by the manufacturer as the maximum value required for operating the device. This is sometimes referred to as the worst-case Power. The actual or average Power may be lower. The Nameplate Power is typically used for provisioning and capacity planning. 5. Architecture Concepts Applied to the MIB Module This section describes the basic concepts specified in the Energy Management 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. +--------------------------+ | EO Context Information | | ------------------------ | | eoRoleDescription | | eoKeywords | | eoImportance | | eoPowerCategory | +--------------------------+ | Expires Sep 16, 2012 [Page 13] Internet-Draft Feb 2012 | v +--------------------------------+ | EO Identification | |_------------------------------ | |->| entPhysIndex (*) | | | entPhysicalName (*) | | | entPhysicalUris (*) (EO UUID) | | | eoDomainName | | | eoMgmtMacAddress (optional) | | | eoMgmtAddress (optional) | | | eoMgmtAddressType (optional) | | | eoMgmtDNSName (optional) | | +--------------------------------+ | | | +------------------------------+ |--| Links to other Identifiers | | | ---------------------------- | | | eoEthPortIndex (**) | | | eoEthPortGrpIndex (**) | | | eoLldpPortNumber (***) | | | eoAlternateKey | | +------------------------------+ | | | +-------------------------------------------+ |--| EO Child Relationships (optional) | | | ----------------------------------------- | | | eoMeteredBy (Parent(s) UUID list) | | | eoPoweredBy (Parent(s) UUID list | | | eoDependentOf (Parent(s) UUID list) | | | eoAggregatedBy (Parent(s) UUID list) | | | eoProxyBy (Parent(s) UUID list) | | +-------------------------------------------+ | | | | +---------------------------------------+ | |-| EO Child ProxyRelationship (optional) | | | ------------------------------------- | | | eoProxyAbilities (specific per parent)| | | ------------------------------------- | | | | +-----------------------------------------+ |--| EO Parent Relationships (optional) | | --------------------------------------- | | eoChildrenList (Child(ren) UUID list) | +-----------------------------------------+ Expires Sep 16, 2012 [Page 14] Internet-Draft Feb 2012 +-----------------------------------------+ | EO Identity Persistence | | --------------------------------------- | | eoTablePersistence (boolean) | +-----------------------------------------+ (*) Compliance From 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 six different logical groups of MIB objects in the ENERGY-AWARE-MIB module: 1) The Energy Object Identification. See Section 5.1 "Energy Object Identification". Devices and their sub-components are characterized by the power-related attributes of a physical entity present in the ENTITY MIB [RFC4133]. 2) The Context Information. See Section 5.2 "Energy Object Context" 3) The links to other MIB modules. See Section 5.3 "Links to other Identifiers" 4) The Energy Object Child Relationships specific information. See Section 5.4 "Child: Energy Objects Relationship." 5) The Energy Object Parent Relationships specific information. See Section 5.5 "Parent: Energy Objects Relationship." 6) The Energy Object Identity Persistence. See Section 5.6 "Energy Object Identity Persistence" 5.1 Energy Object Identification Refer to the "Energy Object Information" section in [EMAN-FMWK] for background information about Energy Objects. Every Energy Object MUST implement the unique index, entPhysicalIndex, from the ENTITY MIB [RFC4133], which is used as index for the primary Energy Object information in the ENERGY-AWARE-MIB module. Expires Sep 16, 2012 [Page 15] Internet-Draft Feb 2012 Every Energy Object MUST have a printable name. Energy Objects MUST implement the entPhysicalName object specified in the ENTITY-MIB, which must contain the Energy Object name. By the [RFC4133] definition, the entPhysicalUris contains a white space separated list of Uniform Resource Identifier (s)(URIs). For the ENERGY-AWARE-MIB compliance, every Energy Object instance MUST implement the entPhysicalUris from the ENTITY MIB [RFC4133]. The entPhysicalUris MUST contain the Energy Object UUID, in a form consistent with [RFC4122]. Note that the entPhysicalUris, as inherited from the ENTITY-MIB, is a read-write managed object, and that, as a consequence the UUID could be set by a management system. As displayed in [RFC4122], the following is an example of the string representation of a UUID as a URN: urn:uuid:f81d4fae- 7dec-11d0-a765-00a0c91e6bf6. Other ENTITY MIB related managed objects, in addition to entPhysicalIndex, entPhysicalName, and entPhysicalUris [RFC4133] MAY be implemented. For example, if the Energy Object temperature is required, the managed objects from the ENTITY- SENSOR-MIB [RFC3433] should be supported. When an Energy Object Parent acts as a Power Aggregator or a Power Proxy, the Energy Object Parent and its Energy Object Child/Children MUST be members of the same Energy Management Domain, specified by the eoDomainName MIB Object. Each Energy Object MUST belong to a single Energy Management Domain or in other words, an Energy Object cannot belong to more than one Energy Management Domain. Refer to the "Energy Management Domain" section in [EMAN-FMWK] for background information. The eoDomainName, which is an element of the eoTable, is a read-write MIB object. The Energy Management Domain should map 1-1 with a metered or sub-metered portion of the site. The Energy Management Domain MUST be configured on the Energy Object Parent. The Energy Object Children MAY inherit their domain parameters from the Energy Object Parent or the Energy Management Domain MAY be configured directly in an Energy Object Child. The eoMgmtMacAddress, eoMgmtAddress, eoMgmtAddressType, and eoMgmtDNSName MIB objects SHOULD be implemented for Energy Object. Expires Sep 16, 2012 [Page 16] Internet-Draft Feb 2012 5.2 Energy Object Context Refer to the "Energy Object Context" section in [EMAN-FMWK] for background information. An Energy Object can provide a eoImportance 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. An Energy Object can provide a set of eoKeywords. These keywords are a list of tags that can be used for grouping and summary reporting within or between Energy Management Domains. Additionally, an Energy Object can provide an eoRoleDescription string that indicates the purpose the Energy Object serves in the network or for the site/business. 5.3 Links to Other Identifiers While the entPhysicalIndex is the primary index for all MIB objects in the ENERGY-AWARE-MIB module, the Energy Management Systems (EnMS) must be able to make the link with the identifier(s) in other supported MIB modules. The Energy Object eoethPortIndex and eoethPortGrpIndex 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 Energy Object SNMP agent. The Energy Object eoLldpPortNumber MUST contain the lldpLocPortNum from the LLDP MIB [LLDP-MIB], if the LLDP-MED MIB is supported on the Energy Object SNMP agent. The intent behind the links to the other MIB module identifier(s) is to correlate the instances in the different MIB modules. This will allow the ENERGY-AWARE-MIB MIB module to reference other MIB modules in cases where the Power over Ethernet and the LLDP MIB modules are supported by the SNMP agent. Some use cases may not implement any of these two MIB modules for the Energy Objects. However, in situation where any of these two MIB modules are implemented, the EnMS must be able to correlate the instances in the different MIB modules. Expires Sep 16, 2012 [Page 17] Internet-Draft Feb 2012 The eoAlternateKey alternate key object specifies a manufacturer defined string that can be used to identify the Energy Object. Since EnMS 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 EnMS to use to correlate the unique Energy Object Id in other systems or namespaces. If an alternate key is not available or is not applicable then the value is the zero-length string. 5.4 Child: Energy Object Relationships Refer to the "Energy Object Parent and Child" section in [EMAN- FMWK] for background information. In order to link the Energy Object Child and the Energy Object Parent, multiple objects are introduced in the MIB module. Depending on the Energy Object Relationship type, the following objects are appropriate: Metering Relationship -> eoMeteredBy Power Source Relationship -> eoPoweredBy Dependency Relationship -> eoDependentOf Aggregation Relationship -> eoAggregatedBy Proxy Relationship -> eoProxyBy, -> eoProxyAbilities Each object contains the list of Energy Object Parent UUIDs for the specific Energy Object Relationship type. The UUIDs MUST comply to the RFC 4122 specifications. The object contains URIs and, therefore, the syntax of this object must conform to RFC 3986 [RFC3986], section 2. Multiple URIs may be present and are separated by white space characters. Leading and trailing white space characters are ignored. For example, if an Energy Object Child is powered by two power sources, eoPoweredBy would contain the two power sources UUIDs, separated by a space: "urn:uuid:f81d4fae-7dec-11d0-a765- 00a0c91e6bf6 urn:uuid:abcdec11-7abc-23e1-b876-00a0c91e6bf8". Expires Sep 16, 2012 [Page 18] Internet-Draft Feb 2012 The eoProxyAbilities object is specific to the Proxy Relationship. This object describes the capabilities of the Energy Object Parent for the Energy Object Child represented by the entPhysicalIndex. The possible capabilities are: report, configuration, and/or wakeonlan. This object only applies to an Energy Object Child. If the Energy Object is not an Energy Object Child, or if the Energy Object doesn't have an Energy Object Relationship, the eoMeteredBy, eoPoweredBy, eoDependentOf, eoAggregatedBy, eoProxyBy, and eoProxyAbilities objects are not instantiated. A zero length octet string MAY also be returned in this case. The Energy Object Child can indicate that it wants its Energy Object Parent to proxy capabilities such as, energy reporting, power state configurations, non physical wake capabilities (such as Wake-on-LAN)), or any combination of capabilities. These capabilities are indicated in the eoProxyAbilities object. In the case of Energy Object Parent, the eoProxyAbilities MUST be set to "none" (0). Since the communication between the Energy Object Parent and Energy Object Child may not be via SNMP (as defined in EMAN- FMWK), an Energy Object Child can have additional MIB objects that can be used for easier identification by the EnMS. The optional objects eoMgmtMacAddress, eoMgmtAddressType eoMgmtDNSName 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 Energy Object with other keyed information that may be stored within the EnMS(s). The eoMeteredBy, eoPoweredBy, eoDependentOf, eoAggregatedBy, eoProxyBy, and eoProxyAbilities implementations are optional. 5.5 Parent: Energy Object Relationships When the Energy Object is an Energy Object Parent, the eoChildrenList object represents the list of Energy Object Child(ren) UUIDs. This UUID list will help in the network discovery of Energy Objects, using the Energy Object Parent as entry points. eoChildrenList has the same format as the eoMeteredBy, eoPoweredBy, eoDependentOf, eoAggregatedBy, and eoProxyBy. The Expires Sep 16, 2012 [Page 19] Internet-Draft Feb 2012 UUIDs MUST comply to the RFC 4122 specifications. The UUIDs MUST comply to the RFC 4122 specifications. The eoChildrenList object contains URIs and, therefore, the syntax of this object must conform to RFC 3986 [RFC3986], section 2. Multiple URIs may be present and are separated by white space characters. Leading and trailing white space characters are ignored. If the Energy Object is not an Energy Object Parent, the eoChildrenList objects is not instantiated. A zero length octet string MAY also be returned in this case. The eoChildrenList implementation is optional. 5.6 Energy Object Identity Persistence In some situations, the Energy Object 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 EnMS if the Energy Object Identification 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 Energy Object Information. Therefore, a specific MIB object, the eoTablePersistence, enables and disables the persistence globally for all Energy Objects information in the eoTable and eoProxyTable MIB tables. 6. Structure of the MIB The primary MIB object in this MIB module is the energyAwareMIB Object. The eoTable table of energyAwareMIB Object describes an entity in the network that is an Energy Object according the [EMAN-FMWK]. +-- rwn TruthValue eoTablePersistence(1) +- eoTable(2) | +- eoEntry(1) [entPhysicalIndex] | | | +-- r-n PethPsePortIndexOrZero eoEthPortIndex(1) | +-- r-n PethPsePortGroupIndexOrZero eoEthPortGrpIndex(2) | +-- r-n LldpPortNumberOrZero eoLldpPortNumber(3) Expires Sep 16, 2012 [Page 20] Internet-Draft Feb 2012 | +-- rwn SnmpAdminString eoDomainName(4) | +-- rwn SnmpAdminString eoRoleDescription(5) | +-- rwn MacAddress eoMgmtMacAddress(6) | +-- r-n eoMgmtAddressType eoMgmtAddressType(7) | +-- r-n InetAddress eoMgmtAddress(8) | +-- r-n SnmpAdminString eoMgmtDNSName(9) | +-- rwn SnmpAdminString eoAlternateKey(10) | +-- rwn EnergyObjectKeywordList eoKeywords(11) | +-- rwn Integer32 eoImportance(12) | +-- r-n INTEGER eoPowerCategory(13) | +-- r-n OCTET STRING eoMeteredBy(14) | +-- r-n OCTET STRING eoPoweredBy(15) | +-- r-n OCTET STRING eoDependentOf(16) | +-- r-n OCTET STRING eoAggregatedBy(17) | +-- r-n OCTET STRING eoAggregatedBy(18) | +-- r-n OCTET STRING eoChildrenList(19) | +- eoProxyTable(3) | +- eoProxyEntry (1)[eoProxyChild, eoProxyParentUUID] | | | +-- --n PhysicalIndex eoProxyChild(1) | +-- --n OCTET STRING eoProxyParentUUID(2) | +-- r-n BITS eoProxyAbilities(3) 7. MIB Definitions -- ************************************************************ -- -- -- This MIB is used for describing the identity and the -- context information of Energy Objects in network -- -- -- ************************************************************* ENERGY-AWARE-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, mib-2, Integer32 FROM SNMPv2-SMI TEXTUAL-CONVENTION, MacAddress, TruthValue Expires Sep 16, 2012 [Page 21] Internet-Draft Feb 2012 FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF SnmpAdminString FROM SNMP-FRAMEWORK-MIB InetAddressType, InetAddress FROM INET-ADDRESS-MIB entPhysicalEntry, PhysicalIndex FROM ENTITY-MIB; energyAwareMIB MODULE-IDENTITY LAST-UPDATED "201202150000Z" 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 Phone: +32 2 704 5622 Email: bclaise@cisco.com" DESCRIPTION "This MIB is used for describing the identity and the context information of Energy Objects" REVISION "201202150000Z" Expires Sep 16, 2012 [Page 22] Internet-Draft Feb 2012 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 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 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 from the Power Over Ethernet MIB [RFC3621], 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 Expires Sep 16, 2012 [Page 23] Internet-Draft Feb 2012 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) EnergyObjectList ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A list of Energy Object Universally Unique Identifiers (UUIDs). The UUIDs must comply to the RFC 4122 specifications. The object contains URIs and, therefore, the syntax of this object must conform to RFC 3986, section 2. Multiple URIs may be present and are separated by white space characters. Leading and trailing white space characters are ignored." REFERENCE "RFC 3986, Uniform Resource Identifiers (URI): Generic Syntax, section 2, August 1998. Expires Sep 16, 2012 [Page 24] Internet-Draft Feb 2012 RFC 4122, Uniform Resource Identifier (UUID) URN Namespace, July 2005." SYNTAX OCTET STRING (SIZE (0..65535)) EnergyObjectKeywordList ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A list of keywords that can be used to group Energy Objects for reporting or searching. If multiple keywords are present, then this string will contain all the keywords separated by the ',' character. White spaces before and after the commas are excluded, as well as within a keyword itself. For example, if an Energy Object were to be tagged with the keyword values 'hospitality' and 'guest', then the keyword list will be 'hospitality,guest'." SYNTAX OCTET STRING (SIZE (0..2048)) -- Objects eoTablePersistence OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This object enables/disables persistence for all entries in the eoTable and eoProxyTable. A value of True enables the persistence, while a value of False disables the persistence." ::= { energyAwareMIBObjects 1 } eoTable OBJECT-TYPE SYNTAX SEQUENCE OF EoEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table lists Energy Objects." ::= { energyAwareMIBObjects 2 } eoEntry OBJECT-TYPE SYNTAX EoEntry Expires Sep 16, 2012 [Page 25] Internet-Draft Feb 2012 MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describes the attributes of an Energy Object. Whenever a new Energy Object is added or deleted a row in the eoTable is added or deleted." AUGMENTS { entPhysicalEntry } ::= { eoTable 1 } EoEntry ::= SEQUENCE { eoEthPortIndex PethPsePortIndexOrZero, eoEthPortGrpIndex PethPsePortGroupIndexOrZero, eoLldpPortNumber LldpPortNumberOrZero, eoDomainName SnmpAdminString, eoRoleDescription SnmpAdminString, eoMgmtMacAddress MacAddress, eoMgmtAddressType InetAddressType, eoMgmtAddress InetAddress, eoMgmtDNSName SnmpAdminString, eoAlternateKey SnmpAdminString, eoKeywords EnergyObjectKeywordList, eoImportance Integer32, eoPowerCategory INTEGER, eoMeteredBy EnergyObjectList, eoPoweredBy EnergyObjectList, eoDependentOf EnergyObjectList, eoAggregatedBy EnergyObjectList, eoProxyBy EnergyObjectList, eoChildrenList EnergyObjectList } eoEthPortIndex OBJECT-TYPE SYNTAX PethPsePortIndexOrZero 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." ::= { eoEntry 1 } eoEthPortGrpIndex OBJECT-TYPE SYNTAX PethPsePortGroupIndexOrZero MAX-ACCESS read-only STATUS current Expires Sep 16, 2012 [Page 26] Internet-Draft Feb 2012 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." ::= { eoEntry 2 } eoLldpPortNumber 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." ::= { eoEntry 3 } eoDomainName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies the name of an Energy Management Domain for the Energy Object. This object specifies a zero-length string value if no Energy Management Domain name is configured. The value of eoDomainName must remain constant at least from one re-initialization of the entity's network management system to the next re- initialization." ::= { eoEntry 4 } eoRoleDescription OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies an administratively assigned name to indicate the purpose an Energy Object serves in the network. For example, we can have a phone deployed to a lobby with eoRoleDescription as 'Lobby phone'. This object specifies the value is the zero-length string value if no role description is configured." Expires Sep 16, 2012 [Page 27] Internet-Draft Feb 2012 ::= { eoEntry 5 } eoMgmtMacAddress OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only STATUS current DESCRIPTION "This object specifies a MAC address of the Energy Object. This object typically only applies to Energy Object Children. This object can be used as an alternate key to help link the Energy Object with other keyed information that may be stored within the EnMS(s). The eoMgmtMacAddress MIB object SHOULD be implemented for Energy Object Children, and MAY be implemented for Energy Object Parents." ::= { eoEntry 6 } eoMgmtAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "This object specifies the eoMgmtAddress type, i.e. an IPv4 address or an IPv6 address. This object MUST be implemented when eoMgmtAddress is populated. The eoMgmtAddressType MIB object SHOULD be implemented for Energy Object Children, and MAY be implemented for Energy Object Parents." ::= { eoEntry 7 } eoMgmtAddress 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 Energy Object. The IP address type, i.e. IPv4 or IPv6, is determined by the eoMgmtAddressType value. This object can be used as an alternate key to help link the Energy Object with other keyed information that may be stored within the EnMS(s). The eoMgmtAddress MIB object SHOULD be implemented for Energy Object Children, and MAY be implemented for Energy Object Parents." ::= { eoEntry 8 } eoMgmtDNSName OBJECT-TYPE Expires Sep 16, 2012 [Page 28] Internet-Draft Feb 2012 SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "This object specifies the DNS name of the eoMgmtAddress. This object can be used as an alternate key to help link the Energy Object with other keyed information that may be stored within the EnMS(s). The eoMgmtDNSName MIB objects SHOULD be implemented for Energy Object Children, and MAY be implemented for Energy Object Parents." ::= { eoEntry 9 } eoAlternateKey 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 Energy Object. Since Energy Management Systems (EnMS) 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 EnMS/NMS to use to correlate the unique Energy Object Id in other systems or namespaces. If an alternate key is not available or is not applicable then the value is the zero-length string." ::= { eoEntry 10 } eoKeywords OBJECT-TYPE SYNTAX EnergyObjectKeywordList MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies a list of keywords that can be used to group Energy Objects for reporting or searching. The value is the zero-length 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 an Energy Object were to be tagged with the keyword values 'hospitality' and 'guest', then the keyword list will be 'hospitality,guest'. Expires Sep 16, 2012 [Page 29] Internet-Draft Feb 2012 If write access is implemented and a value is written into the instance, the agent must retain the supplied value in the eoKeywords 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." ::= { eoEntry 11 } eoImportance OBJECT-TYPE SYNTAX Integer32 (1..100) MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies a ranking of how important the Energy Object is (on a scale of 1 to 100) compared with other Energy Objects in the same Energy Management Domain. The ranking should provide a business or operational context for the Energy Object as compared to other similar Energy Objects. This ranking could be used as input for policy-based network management. 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 } ::= { eoEntry 12 } eoPowerCategory OBJECT-TYPE SYNTAX INTEGER { consumer(0), producer(1), consumer-producer(2), meter(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object describes the Energy Object category, which indicates the expected behavior or physical property of the Energy Object, based on its design. An Energy Object Expires Sep 16, 2012 [Page 30] Internet-Draft Feb 2012 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 Energy Object category is meter(3). " ::= { eoEntry 13 } eoMeteredBy OBJECT-TYPE SYNTAX EnergyObjectList MAX-ACCESS read-only STATUS current DESCRIPTION "When this Energy Object is an Energy Object Child, this object represents the list of Energy Object Parent Universally Unique Identifiers (UUIDs) for the Metering Relationship. If this Energy Object is not an Energy Object Child, or if the Energy Object doesn't have a Metering Relationship, the object is not instantiated. A zero length octet string may also be returned in this case." ::= { eoEntry 14 } eoPoweredBy OBJECT-TYPE SYNTAX EnergyObjectList MAX-ACCESS read-only STATUS current DESCRIPTION "When this Energy Object is an Energy Object Child, this object represents the list of Energy Object Parent Universally Unique Identifiers (UUIDs) for the Power Source Relationship. If this Energy Object is not an Energy Object Child, or if the Energy Object doesn't have a Power Source Relationship, the object is not instantiated. A zero length octet string may also be returned in this case." ::= { eoEntry 15 } Expires Sep 16, 2012 [Page 31] Internet-Draft Feb 2012 eoDependentOf OBJECT-TYPE SYNTAX EnergyObjectList MAX-ACCESS read-only STATUS current DESCRIPTION "When this Energy Object is an Energy Object Child, this object represents the list of Energy Object Parent Universally Unique Identifiers (UUIDs) for the Dependency Relationship. If this Energy Object is not an Energy Object Child, or if the Energy Object doesn't have a Dependency Relationship, the object is not instantiated. A zero length octet string may also be returned in this case." ::= { eoEntry 16 } eoAggregatedBy OBJECT-TYPE SYNTAX EnergyObjectList MAX-ACCESS read-only STATUS current DESCRIPTION "When this Energy Object is an Energy Object Child, this object represents the list of Energy Object Parent Universally Unique Identifiers (UUIDs) for the Aggregation Relationship. If this Energy Object is not an Energy Object Child, or if the Energy Object doesn't have a Aggregation Relationship, the object is not instantiated. A zero length octet string may also be returned in this case." ::= { eoEntry 17 } eoProxyBy OBJECT-TYPE SYNTAX EnergyObjectList MAX-ACCESS read-only STATUS current DESCRIPTION "When this Energy Object is an Energy Object Child, this object represents the list of Energy Object Parent Universally Unique Identifiers (UUIDs) for the Proxy Relationship. Expires Sep 16, 2012 [Page 32] Internet-Draft Feb 2012 If this Energy Object is not an Energy Object Child, or if the Energy Object doesn't have a Proxy Relationship, the object is not instantiated. A zero length octet string may also be returned in this case." ::= { eoEntry 18 } eoChildrenList OBJECT-TYPE SYNTAX EnergyObjectList MAX-ACCESS read-only STATUS current DESCRIPTION "When this Energy Object is an Energy Object Parent, this object represents the list of Energy Object Children Universally Unique Identifiers (UUIDs). If this Energy Object is not an Energy Object Parent, the object is not instantiated. A zero length octet string may also be returned in this case." ::= { eoEntry 19 } eoProxyTable OBJECT-TYPE SYNTAX SEQUENCE OF EoProxyEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table describes the proxy capabilities of a Energy Object Parent for a specific local Energy Object Child. " ::= { energyAwareMIBObjects 3 } eoProxyEntry OBJECT-TYPE SYNTAX EoProxyEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describes the attributes of an Energy Object. Whenever a new Energy Object is added or deleted, a row in the eoProxyTable is added or deleted." INDEX { eoProxyChild, eoProxyParentUUID } ::= { eoProxyTable 1 } EoProxyEntry ::= SEQUENCE { eoProxyChild PhysicalIndex, eoProxyParentUUID OCTET STRING, eoProxyAbilities BITS } Expires Sep 16, 2012 [Page 33] Internet-Draft Feb 2012 eoProxyChild OBJECT-TYPE SYNTAX PhysicalIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object contains the entPhysicalIndex of the local Energy Object, i.e. the Energy Object Child in the context of this table." ::= { eoProxyEntry 1 } eoProxyParentUUID OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..45)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object describes the Universally Unique Identifier (UUID) of the Energy Object Parent. The UUID must comply to the RFC 4122 specifications. The object contains an URI and, therefore, the syntax of this object must conform to RFC 3986, section 2." REFERENCE "RFC 3986, Uniform Resource Identifiers (URI): Generic Syntax, section 2, August 1998. RFC 4122, Uniform Resource Identifier (UUID) URN Namespace, July 2005." ::= { eoProxyEntry 2 } eoProxyAbilities OBJECT-TYPE SYNTAX BITS { none(0), report(1), configuration(2), wakeonlan(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object describes the proxy capabilities of the Energy Object Parent (represented by the eoProxyParent in this table) for the local Energy Object Child (represented by the eoProxyChild in this table). None (0) is be used when the Energy Object Parent does not have any proxy abilities regarding the Energy Object Child. Expires Sep 16, 2012 [Page 34] Internet-Draft Feb 2012 Report(1) indicates that the Energy Object Parent reports the usage for the Energy Object Child. Configuration(2) indicates that the Energy Object Parent can configure the Power Level for the Energy Object Child. Wakeonlan(3) indicates that the Energy Object Parent can wake up the Energy Object Child (the mechanism is unspecified)." ::= { eoProxyEntry 3 } -- Conformance energyAwareMIBCompliances OBJECT IDENTIFIER ::= { energyAwareMIBObjects 4 } energyAwareMIBGroups OBJECT IDENTIFIER ::= { energyAwareMIBObjects 5 } 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. The entPhysicalIndex, entPhysicalName, and entPhysicalUris [RFC4133] MUST be implemented." MODULE -- this module MANDATORY-GROUPS { energyAwareMIBTableGroup } GROUP energyAwareOptionalMIBTableGroup DESCRIPTION "A compliant implementation does not have to implement." ::= { 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 Expires Sep 16, 2012 [Page 35] Internet-Draft Feb 2012 implementation can claim read-only compliance. Such a device can then be monitored but cannot be configured with this MIB. The entPhysicalIndex, entPhysicalName, and entPhysicalUris [RFC4133] MUST be implemented." MODULE -- this module MANDATORY-GROUPS { energyAwareMIBTableGroup } GROUP energyAwareOptionalMIBTableGroup DESCRIPTION "A compliant implementation does not have to implement the managed objects in this GROUP." OBJECT eoTablePersistence MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT eoDomainName MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT eoRoleDescription MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT eoKeywords MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT eoImportance MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { energyAwareMIBCompliances 2 } -- Units of Conformance energyAwareMIBTableGroup OBJECT-GROUP OBJECTS { eoTablePersistence, eoEthPortIndex, eoEthPortGrpIndex, Expires Sep 16, 2012 [Page 36] Internet-Draft Feb 2012 eoLldpPortNumber, eoDomainName, eoRoleDescription, eoAlternateKey, eoKeywords, eoImportance, eoPowerCategory } STATUS current DESCRIPTION "This group contains the collection of all the objects related to the EnergyObject." ::= { energyAwareMIBGroups 1 } energyAwareOptionalMIBTableGroup OBJECT-GROUP OBJECTS { eoMgmtMacAddress, eoMgmtAddressType, eoMgmtAddress, eoMgmtDNSName, eoMeteredBy, eoPoweredBy, eoDependentOf, eoAggregatedBy, eoProxyBy, eoProxyAbilities, eoChildrenList, eoProxyAbilities } STATUS current DESCRIPTION "This group contains the collection of all the objects related to the EnergyObject." ::= { energyAwareMIBGroups 2 } 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 Sep 16, 2012 [Page 37] Internet-Draft Feb 2012 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 eoDomainName, entPhysicalName, eoRoleDescription, eoKeywords, and/or eoImportance 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 by an IETF Area Director. The group of experts MUST check the Expires Sep 16, 2012 [Page 38] Internet-Draft Feb 2012 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. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", RFC 3986, January 2005 [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. Expires Sep 16, 2012 [Page 39] Internet-Draft Feb 2012 [LLDP-MED-MIB] ANSI/TIA-1057, "The LLDP Management Information Base extension module for TIA-TR41.4 media endpoint discovery information", July 2005. [EMAN-MON-MIB] M. Chandramouli, Schoening, B., Quittek, J., Dietz, T., and B. Claise "Power and Energy Monitoring MIB", draft-ietf-eman-energy-monitoring-mib-01, October 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. [RFC3433] Bierman, A., Romascanu, D., and K.C. Norseth, "Entity Sensor Management Information Base", RFC 3433, 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-05, work in progress, November 2011. [EMAN-FMWK] Claise, B., Parello, J., Schoening, B., and J. Quittek, "Energy Management Framework", draft-ietf- eman-framework-03, work in progress, October 2011. [EMAN-AS] Tychon, E., Schoening, B., Chandramouli, M, and B. Nordman, "Energy Management (EMAN) Applicability Statement", draft-tychon-eman-applicability-statement- 05.txt, work in progress, October 2011. [EMAN-TERMINOLOGY] J. Parello, "Energy Management Terminology", draft-parello-eman-definitions-04, work in progress, December 2011 [IEEE100] "The Authoritative Dictionary of IEEE Standards Terms" http://ieeexplore.ieee.org/xpl/mostRecentIssue.jsp?pun umber=4116785 Expires Sep 16, 2012 [Page 40] Internet-Draft Feb 2012 [IEEE1621] "Standard for User Interface Elements in Power Control of Electronic Devices Employed in Office/Consumer Environments", IEEE 1621, December 2004. [IEC60050] International Electrotechnical Vocabulary http://www.electropedia.org/iev/iev.nsf/welco me?openform [ISO50001] "ISO 50001:2011 Energy management systems - Requirements with guidance for use", http://www.iso.org/ [DMTF] "Power State Management Profile DMTF DSP1027 Version 2.0" December 2009 http://www.dmtf.org/sites/default/files/stand ards/documents/DSP1027_2.0.0.pdf [TMN] "TMN Management Functions : Performance Management", ITU-T M.3400 [NMF] "Network Management Fundamentals", Alexander Clemm, ISBN: 1-58720-137-2, 2007 [ITU-T-M-3400] TMN recommandation on Management Functions (M.3400), 1997 [1037C] US Department of Commerce, Federal Standard 1037C, http://www.its.bldrdoc.gov/fs-1037/fs- 1037c.htm [SQL] ISO/IEC 9075(1-4,9-11,13,14):2008 11. Acknowledgments The authors would like to thank Bill Mielke for his multiple reviews, Juergen Quittek, Brad Schoening, Juergen Schoenwaelder for their help, Michael Brown for improving the text dramatically, and most specifically Mouli Chandramouli for improving this draft. Authors' Addresses Expires Sep 16, 2012 [Page 41] Internet-Draft Feb 2012 Benoit Claise 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 Sep 16, 2012 [Page 42]