Network Working Group J. Parello
Internet-Draft B. Claise
Intended Status: Standards Track Mouli Chandramouli
Expires: September 13, 2012 Cisco Systems, Inc.
March 12, 2012
Energy Object Context MIB
draft-ietf-eman-energy-aware-mib-05
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 13, 2012.
<Parello, Claise> Expires Sep 11 2012 [Page 1]
Internet-Draft < Energy Object Context MIB > March 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............................................. 4
1.1. Energy Management Document Overview..................5
2. The Internet-Standard Management Framework............... 5
3. Requirements and Use Cases............................... 5
4. Terminology.............................................. 6
Energy Management.........................................6
Energy Management System (EnMS)...........................7
ISO Energy Management System..............................8
Energy....................................................8
Power.....................................................8
Demand....................................................8
Power Quality.............................................9
<Parello, Claise> Expires Sep 13, 2012 [Page 2]
Internet-Draft < Energy Object Context MIB > March 2012
Electrical Equipment......................................9
Non-Electrical Equipment (Mechanical Equipment)...........9
Energy Object.............................................9
Electrical Energy Object..................................9
Non-Electrical Energy Object.............................10
Energy Monitoring........................................10
Energy Control...........................................10
Energy Device............................................10
Energy Device Component..................................10
Energy Management Domain.................................10
Energy Object Identification.............................11
Energy Object Context....................................11
Energy Object Relationship...............................11
Aggregation Relationship.................................11
Metering Relationship....................................12
Power Source Relationship................................12
Proxy Relationship.......................................12
Energy Object Parent.....................................12
Energy Object Child......................................13
Power State..............................................13
Power State Set..........................................13
Nameplate Power..........................................13
5. Architecture Concepts Applied to the MIB Module......... 14
5.1 Energy Object Identification.........................17
5.2 Energy Object Context................................18
5.3 Links to Other Identifiers...........................19
5.4 Child: Energy Object Relationships...................20
5.5 Parent: Energy Object Relationships..................21
5.6 Energy Object Identity Persistence...................22
6. MIB Definitions......................................... 22
7. Security Considerations................................. 38
8. IANA Considerations..................................... 39
9. References.............................................. 40
9.1. Normative References................................40
9.2. Informative References..............................41
10. Acknowledgments........................................ 42
OPEN ISSUE:
1. Is the UUID always 45 bytes? eoProxyParentUUID has
a current size of " OCTET STRING (SIZE(0..45))".
2. use the UUID as index for a table
- it is a design decision whether to use integer
indexes (and to think careful about there
persistency properties), UUIDs in some fixed size
<Parello, Claise> Expires Sep 13, 2012 [Page 3]
Internet-Draft < Energy Object Context MIB > March 2012
compact binary format (perhaps rendered by
DISPLAY-HINTS)
- If the UUID is represented as a URI that conforms
to RFC 4122, the correct datatype is DisplayString
(i.e., visible ASCII) - non-ASCII octets are
impossible in the RFC 4122 encoding.
3. From http://www.ietf.org/proceedings/82/slides/eman-1.pdf
(Do we need eoMeteringChildrenList,
eoPoweringChildrenList, eoAggregatingChildrenList,
eoProxyingChildrenList?
- Bit vector representation of parent/child
relationship
4. Compliance with ENTITY-MIB
5. Reuse of eoethPortIndex, eoethPortGrpIndex indices
from PoE MIB and lldpLocPortNum from Lldp MIB
6. Comments on review of draft-ietf-eman-energy-
aware-mib-04
1. Introduction
The EMAN standards provide a specification for Energy
Management. This document defines a subset of a Management
Information Base (MIB) for use with network management protocols
for Energy monitoring of network devices and devices attached to
the network and possibly extending to devices in the industrial
automation setting with a network interface.
The focus of the MIB module specified in this document is on
the identification of Energy Objects and reporting the context
and relationships of Energy Objects as defined in [EMAN-FMWK].
The module addresses Energy Object Identification, Energy Object
Context, and Energy Object Relationships.
<Parello, Claise> Expires Sep 13, 2012 [Page 4]
Internet-Draft < Energy Object Context MIB > March 2012
1.1. Energy Management Document Overview
This document specifies the ENERGY-OBJECT-CONTEXT-MIB module.
This document is based on the Energy Management Framework [EMAN-
FMWK] and meets the requirements on identification of Energy
Objects and their context and relationships as 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, and describes the common aspects of between
existing Energy 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].
3. Requirements and Use Cases
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
<Parello, Claise> Expires Sep 13, 2012 [Page 5]
Internet-Draft < Energy Object Context MIB > March 2012
powered and metered are also presented. To address the network
scenarios, requirements for power and energy monitoring for
networking devices are specified in [EMAN-REQ]. 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)
- "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:
<Parello, Claise> Expires Sep 13, 2012 [Page 6]
Internet-Draft < Energy Object Context MIB > March 2012
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
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).
<Parello, Claise> Expires Sep 13, 2012 [Page 7]
Internet-Draft < Energy Object Context MIB > March 2012
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]
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.
<Parello, Claise> Expires Sep 13, 2012 [Page 8]
Internet-Draft < Energy Object Context MIB > March 2012
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
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
<Parello, Claise> Expires Sep 13, 2012 [Page 9]
Internet-Draft < Energy Object Context MIB > March 2012
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.
Energy Device
An Energy Device is an Energy Object that may be
monolithic or contain Energy Device Components.
Energy Device Component
An Energy Device Component is an Energy Object contained in
an Energy Device, for which the containing Energy Device
provides individual energy management functions. Typically,
the Energy Device Component is part the Energy Device
physical containment tree in the ENTITY-MIB [RFC4133].
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.
<Parello, Claise> Expires Sep 13, 2012 [Page 10]
Internet-Draft < Energy Object Context MIB > March 2012
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
1. Relationships can be named and could include
Aggregation, Metering, Power Source, Proxy.
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.
<Parello, Claise> Expires Sep 13, 2012 [Page 11]
Internet-Draft < Energy Object Context MIB > March 2012
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.
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.
<Parello, Claise> Expires Sep 13, 2012 [Page 12]
Internet-Draft < Energy Object Context MIB > March 2012
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
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
<Parello, Claise> Expires Sep 13, 2012 [Page 13]
Internet-Draft < Energy Object Context MIB > March 2012
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 Energy Object Context MIB module defined in this document
defines MIB objects for identification of Energy Objects, and
reporting context and relationship of an Energy Object. The
managed objects are contained in two tables eoTable and
eoProxyTable.
The first table eoTable (OIDs ending with 1-18) focuses on link
to the other MIB modules, context of the Energy Object and the
relationship of the Energy Object. The second table eoProxyTable
describes the proxy capabilities of a Energy Object Parent for a
specific local Energy Object Child. The global variable
eoTablePeristence deals with the persistence of identity of the
Energy Object.
+-- rwn TruthValue eoTablePersistence(1)
+- eoTable(2)
|
+- eoEntry(1) [entPhysicalIndex]
| |
| +-- r-n PethPsePortIndexOrZero eoEthPortIndex(1)
| +-- r-n PethPsePortGroupIndexOrZero eoEthPortGrpIndex(2)
| +-- r-n LldpPortNumberOrZero eoLldpPortNumber(3)
| +-- 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)
<Parello, Claise> Expires Sep 13, 2012 [Page 14]
Internet-Draft < Energy Object Context MIB > March 2012
| +-- r-n INTEGER eoPowerCategory(13)
| +-- r-n OCTET STRING eoMeteredBy(14)
| +-- r-n OCTET STRING eoPoweredBy(15)
| +-- r-n OCTET STRING eoAggregatedBy(16)
| +-- r-n OCTET STRING eoAggregatedBy(17)
| +-- r-n OCTET STRING eoChildrenList(18)
|
+- eoProxyTable(3)
|
+- eoProxyEntry (1)[eoProxyChild, eoProxyParentUUID]
| |
| +-- --n PhysicalIndex eoProxyChild(1)
| +-- --n OCTET STRING eoProxyParentUUID(2)
| +-- r-n BITS eoProxyAbilities(3)
The following UML diagram illustrates the relationship of the
MIB objects in the eoTable and eoProxyTable that describe the
identity, context and relationship an Energy Object.
+--------------------------+
| EO Context Information |
| ------------------------ |
| eoRoleDescription |
| eoKeywords |
| eoImportance |
| eoPowerCategory |
+--------------------------+
|
|
v
+--------------------------------+
|-> | EO Identification |
| | ------------------------------ |
<Parello, Claise> Expires Sep 13, 2012 [Page 15]
Internet-Draft < Energy Object Context MIB > March 2012
| | entPhysIndex (*) |
| | entPhysicalName (*) |
| | entPhysicalUris (*) (EO UUID) |
| |
| | eoEthPortIndex (**) |
| | eoEthPortGrpIndex (**) |
| | eoLldpPortNumber (***) |
| | eoAlternateKey |
| | |
| | eoDomainName |
| | eoMgmtMacAddress (optional) |
| | eoMgmtAddress (optional) |
| | eoMgmtAddressType (optional) |
| | eoMgmtDNSName (optional) |
| | |
| +--------------------------------+
| ^
| |
| |
| |
| +-------------------------------------------+
| | Relationships (optional) |
| | ----------------------------------------- |
| | eoMeteredBy (Parent(s) UUID list) |
| | eoPoweredBy (Parent(s) UUID list |
| | eoAggregatedBy (Parent(s) UUID list) |
| | eoProxyBy (Parent(s) UUID list) |
| | |
| | eoProxyAbilities (specific per parent) |
| | eoChildrenList (Child(ren) UUID list) |
| +-------------------------------------------+
|
|
| +-----------------------------------------+
| | 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
<Parello, Claise> Expires Sep 13, 2012 [Page 16]
Internet-Draft < Energy Object Context MIB > March 2012
As displayed in figure 1, the MIB objects can be classified in
different logical grouping of MIB objects.
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-OBJECT-CONTEXT-MIB module.
Every Energy Object MUST have a printable name assigned to it.
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-OBJECT-CONTEXT-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, 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.
<Parello, Claise> Expires Sep 13, 2012 [Page 17]
Internet-Draft < Energy Object Context MIB > March 2012
Other ENTITY MIB related managed objects, in addition to
entPhysicalIndex, entPhysicalName, and entPhysicalUris [RFC4133]
MAY be implemented. For example, to understand the relationship
between Energy Object Components and Energy Objects, the ENTITY-
MIB physical containment tree [RFC4133] MUST be implemented.
A second example deals with one of the ENTITY-MIB extensions: 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 network. The Energy Management Domain MUST be configured on
the Energy Object Parent. The Energy Object Children MAY
inherit the some of the domain parameters (possibly domain name,
some of the context information such as role or keywords,
importance) from the Energy Object Parent or the Energy
Management Domain MAY be configured directly in an Energy Object
Child.
5.2 Energy Object Context
Refer to the "Energy Object Context" section in [EMAN-FMWK] for
background information.
An Energy Object must provide a value for eoImportance 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.
<Parello, Claise> Expires Sep 13, 2012 [Page 18]
Internet-Draft < Energy Object Context MIB > March 2012
An Energy Object can be classified based on the physical
properties of the Energy Object. That Energy Object can be
classified as consuming power or supplying power to other
devices or that Energy Object can perform both of those
functions and finally, an Energy Object can be a passive meter.
Additionally, an Energy Object can provide an eoRoleDescription
string that indicates the purpose the Energy Object serves in
the network.
5.3 Links to Other Identifiers
While the entPhysicalIndex is the primary index for all MIB
objects in the ENERGY-OBJECT-CONTEXT-MIB module, the Energy
Management Systems (EnMS) must be able to make the link with the
identifier(s) in other supported MIB modules.
If the Energy Object is a PoE port, and if the Power over
Ethernet MIB [RFC3621] is supported by the Energy Object SNMP
agent, then the Energy Object eoethPortIndex and
eoethPortGrpIndex MUST contain the values of pethPsePortIndex
and pethPsePortGroupIndex [RFC3621].
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-OBJECT-CONTEXT-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.
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
<Parello, Claise> Expires Sep 13, 2012 [Page 19]
Internet-Draft < Energy Object Context MIB > March 2012
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
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".
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
<Parello, Claise> Expires Sep 13, 2012 [Page 20]
Internet-Draft < Energy Object Context MIB > March 2012
eoMeteredBy, eoPoweredBy, eoAggregatedBy, eoProxyBy, and
eoProxyAbilities objects are not instantiated. A zero length
octet string MAY also be returned in this case. The eoMeteredBy,
eoPoweredBy, eoAggregatedBy, eoProxyBy, and eoProxyAbilities
implementations are optional.
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).
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, eoAggregatedBy, and eoProxyBy. The 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.
<Parello, Claise> Expires Sep 13, 2012 [Page 21]
Internet-Draft < Energy Object Context MIB > March 2012
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. MIB Definitions
-- ************************************************************
--
--
-- This MIB is used for describing the identity and the
-- context information of Energy Objects in network
--
--
-- *************************************************************
ENERGY-OBJECT-CONTEXT-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY,
OBJECT-TYPE,
mib-2,
Integer32
FROM SNMPv2-SMI
TEXTUAL-CONVENTION, MacAddress, TruthValue
FROM SNMPv2-TC
MODULE-COMPLIANCE,
<Parello, Claise> Expires Sep 13, 2012 [Page 22]
Internet-Draft < Energy Object Context MIB > March 2012
OBJECT-GROUP
FROM SNMPv2-CONF
SnmpAdminString
FROM SNMP-FRAMEWORK-MIB
InetAddressType, InetAddress
FROM INET-ADDRESS-MIB
entPhysicalIndex, PhysicalIndex
FROM ENTITY-MIB;
energyAwareMIB MODULE-IDENTITY
LAST-UPDATED "201203120000Z"
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"
Mouli Chandramouli
Cisco Systems, Inc.
Sarjapur Outer Ring Road
Bangalore,
IN
Phone: +91 80 4426 3947
Email: moulchan@cisco.com
<Parello, Claise> Expires Sep 13, 2012 [Page 23]
Internet-Draft < Energy Object Context MIB > March 2012
DESCRIPTION
"This MIB is used for describing the identity and the
context information of Energy Objects"
REVISION
"201203120000Z"
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
<Parello, Claise> Expires Sep 13, 2012 [Page 24]
Internet-Draft < Energy Object Context MIB > March 2012
"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
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.
<Parello, Claise> Expires Sep 13, 2012 [Page 25]
Internet-Draft < Energy Object Context MIB > March 2012
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.
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. All alphanumeric
characters and symbols (other than a comma), such as #,
(, $, !, and &, are allowed. 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
<Parello, Claise> Expires Sep 13, 2012 [Page 26]
Internet-Draft < Energy Object Context MIB > March 2012
SYNTAX SEQUENCE OF EoEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table lists Energy Objects."
::= { energyAwareMIBObjects 2 }
eoEntry OBJECT-TYPE
SYNTAX EoEntry
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."
INDEX {entPhysicalIndex }
::= { 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,
eoAggregatedBy EnergyObjectList,
eoProxyBy EnergyObjectList,
eoChildrenList EnergyObjectList
}
eoEthPortIndex OBJECT-TYPE
SYNTAX PethPsePortIndexOrZero
MAX-ACCESS read-only
STATUS current
DESCRIPTION
<Parello, Claise> Expires Sep 13, 2012 [Page 27]
Internet-Draft < Energy Object Context MIB > March 2012
"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
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
<Parello, Claise> Expires Sep 13, 2012 [Page 28]
Internet-Draft < Energy Object Context MIB > March 2012
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."
::= { 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
<Parello, Claise> Expires Sep 13, 2012 [Page 29]
Internet-Draft < Energy Object Context MIB > March 2012
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
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
<Parello, Claise> Expires Sep 13, 2012 [Page 30]
Internet-Draft < Energy Object Context MIB > March 2012
"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'.
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),
<Parello, Claise> Expires Sep 13, 2012 [Page 31]
Internet-Draft < Energy Object Context MIB > March 2012
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
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
<Parello, Claise> Expires Sep 13, 2012 [Page 32]
Internet-Draft < Energy Object Context MIB > March 2012
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 }
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 16 }
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.
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 17 }
eoChildrenList OBJECT-TYPE
SYNTAX EnergyObjectList
<Parello, Claise> Expires Sep 13, 2012 [Page 33]
Internet-Draft < Energy Object Context MIB > March 2012
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 18 }
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
}
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."
<Parello, Claise> Expires Sep 13, 2012 [Page 34]
Internet-Draft < Energy Object Context MIB > March 2012
::= { 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.
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)."
<Parello, Claise> Expires Sep 13, 2012 [Page 35]
Internet-Draft < Energy Object Context MIB > March 2012
::= { 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
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
}
<Parello, Claise> Expires Sep 13, 2012 [Page 36]
Internet-Draft < Energy Object Context MIB > March 2012
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,
eoLldpPortNumber,
eoDomainName,
eoRoleDescription,
eoAlternateKey,
eoKeywords,
eoImportance,
eoPowerCategory
<Parello, Claise> Expires Sep 13, 2012 [Page 37]
Internet-Draft < Energy Object Context MIB > March 2012
}
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,
eoAggregatedBy,
eoProxyBy,
eoProxyAbilities,
eoChildrenList,
eoProxyAbilities
}
STATUS current
DESCRIPTION
"This group contains the collection of all the objects
related to the EnergyObject."
::= { energyAwareMIBGroups 2 }
END
7. Security Considerations
Some of the readable objects in these MIB modules (i.e., objects
with a MAX-ACCESS other than not-accessible) may be considered
sensitive or vulnerable in some network environments. It is
thus important to control even GET and/or NOTIFY access to these
objects and possibly to even encrypt the values of these objects
when sending them over the network via SNMP.
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:
<Parello, Claise> Expires Sep 13, 2012 [Page 38]
Internet-Draft < Energy Object Context MIB > March 2012
. 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.
8. IANA Considerations
The MIB module in this document uses the following IANA-assigned
OBJECT IDENTIFIER values recorded in the SMI Numbers registry:
Descriptor OBJECT IDENTIFIER value
---------- -----------------------
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
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.
<Parello, Claise> Expires Sep 13, 2012 [Page 39]
Internet-Draft < Energy Object Context MIB > March 2012
9. References
9.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.
[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-02, March
2012 .
<Parello, Claise> Expires Sep 13, 2012 [Page 40]
Internet-Draft < Energy Object Context MIB > March 2012
9.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] Schoening, B., Chandramouli, M, and B. Nordman,
"Energy Management (EMAN) Applicability Statement",
draft-ietf-eman-applicability-statement-00.txt, work
in progress, December 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
[IEEE1621] "Standard for User Interface Elements in
Power Control of Electronic Devices Employed
in Office/Consumer Environments", IEEE 1621,
December 2004.
<Parello, Claise> Expires Sep 13, 2012 [Page 41]
Internet-Draft < Energy Object Context MIB > March 2012
[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
10. 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 for
dramatically improving this draft.
Authors' Addresses
Benoit Claise
Cisco Systems, Inc.
De Kleetlaan 6a b1
Diegem 1813
BE
Phone: +32 2 704 5622
<Parello, Claise> Expires Sep 13, 2012 [Page 42]
Internet-Draft < Energy Object Context MIB > March 2012
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
Mouli Chandramouli
Cisco Systems, Inc.
Sarjapur Outer Ring Road
Bangalore
IN
Phone: +91 80 4426 3947
Email: moulchan@cisco.com
<Parello, Claise> Expires Sep 13, 2012 [Page 43]
