One document matched: draft-ietf-eman-energy-aware-mib-01.txt
Differences from draft-ietf-eman-energy-aware-mib-00.txt
Network Working Group J. Parello
Internet-Draft B. Claise
Intended Status: Standards Track Cisco Systems, Inc.
Expires: September 10, 2011 March 10, 2011
Energy-aware Networks and Devices MIB
draft-ietf-eman-energy-aware-mib-01
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance
with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as
"work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed
at http://www.ietf.org/shadow.html
This Internet-Draft will expire on September, 2011.
<Parello, Claise> Expires September 10 2011 [Page 1]
Internet-Draft <Energy-aware Networks and Devices MIB> Mar. 2011
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described
in Section 4.e of the Trust Legal Provisions and are provided
without warranty as described in the Simplified BSD License.
Abstract
This document defines a subset of the Management Information
Base (MIB) for power and energy monitoring of devices. The
module addresses devices identification, context information,
and the relationship between reporting devices, remote devices,
and monitoring probes.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" in this document are to
be interpreted as described in RFC 2119 [RFC2119].
Table of Contents
1. Introduction.............................................. 3
1.1. Energy Management Document Overview.................. 4
2. The Internet-Standard Management Framework................ 4
3. Use Cases................................................. 5
4. Terminology............................................... 5
5. Architecture Concepts Applied to the MIB Module........... 5
5.1 Power Monitor Information............................. 7
5.1.1. Power Monitor Name.............................. 7
5.1.2. Power Monitor Meter Domain...................... 8
5.1.3. Alternate Key................................... 8
5.1.4. Persistence..................................... 8
5.2 Links to other MIB Modules............................ 9
<Parello, Claise> Expires September 10, 2011 [Page 2]
Internet-Draft <Energy-aware Networks and Devices MIB> Mar. 2011
5.3 Power Monitor Parent and Child........................ 9
5.4 Power Monitor Context................................ 10
6. Structure of the MIB..................................... 10
7. MIB Definitions.......................................... 10
8. Security Considerations.................................. 23
9. IANA Considerations...................................... 24
10. References.............................................. 25
10.1. Normative References............................... 25
10.2. Informative References............................. 26
11. Acknowledgments......................................... 26
OPEN ISSUES:
1. Length and format of PowerMonitorId. The pmPowerMonitorID
should be a unique id that identfies the device in the
universe. A UUID using RFC 4122 seems to suffice. However an
x.509 certificate conforming to RFC 5280 could also be
appropriate. We have specified the field as variable 16 bytes
but would like feedback and consensus on the format that is
appropriate.
2. Do we want separate tables, as depicted in figure 1, as
opposed to a single pmTable?
3. Should the pmMgmtMacAddress, pmMgmtAddress,
pmMgmtAddressType, and pmMgmtDNSName also be implemented for
Power Monitor Parent?
1. Introduction
The EMAN standards provides network administrators with energy
management. This document defines a subset of the Management
Information Base (MIB) for use with network management protocols
for power and energy monitoring of network devices and devices
attached to the network, as specified in the Power Management
Architecture [EMAN-FMWK], which in turn, is based on the Power
Monitoring Requirements [EMAN-REQ].
This module's special focus is on monitoring energy-aware
networks and devices. The module addresses device
identification, context information, and relationships between
reporting devices, remote devices, and monitoring probes.
Devices and their sub-components may be characterized by the
power-related attributes of a physical entity present in the
ENTITY MIB [RFC4133], even though ENTITY MIB compliance is not a
<Parello, Claise> Expires September 10, 2011 [Page 3]
Internet-Draft <Energy-aware Networks and Devices MIB> Mar. 2011
requirement due to the variety and broad base of devices
concerned with energy management.
1.1. Energy Management Document Overview
This document, which specifies the Energy-aware Networks and
Devices MIB document is based on the Energy Management Framework
[EMAN-FMWK], per the Energy Management requirements specified in
[EMAN-REQ], which allows networks and devices to become energy
aware.
The Power and Energy Monitoring MIB [EMAN-MON-MIB] contains the
managed objects for monitoring of power states and energy
consumption/production. The monitoring of power states
includes: retrieving power states, properties of power states,
current power state, power state transitions, and power state
statistics. This MIB provides the detailed properties of the
actual energy rate (power) and of accumulated energy, along with
the power quality.
The applicability statement document [EMAN-AS] provides the list
of use cases, cross-reference between existing standards and the
EMAN standard, and shows how the EMAN framework relates to other
frameworks.
EDITOR'S NOTE: [EMAN-MON-MIB] and [EMAN-AS] are not EMAN working
group documents. Hence, these references will be changed in the
future.
2. The Internet-Standard Management Framework
For a detailed overview of the documents that describe the
current Internet-Standard Management Framework, please refer to
section 7 of RFC 3410 [RFC3410].
Managed objects are accessed via a virtual information store,
termed the Management Information Base or MIB. MIB objects are
generally accessed through the Simple Network Management
Protocol (SNMP). Objects in the MIB are defined using the
mechanisms defined in the Structure of Management Information
(SMI). This memo specifies MIB modules that are compliant with
SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58,
RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580].
<Parello, Claise> Expires September 10, 2011 [Page 4]
Internet-Draft <Energy-aware Networks and Devices MIB> Mar. 2011
3. Use Cases
Requirements for power and energy monitoring for networking
devices are specified in [EMAN-REQ]. The requirements in [EMAN-
REQ] cover devices typically found in communications networks,
such as switches, routers, and various connected endpoints. For
a power monitoring architecture to be useful, it should also
apply to facility meters, power distribution units, gateway
proxies for commercial building control, home automation
devices, and devices that interface with the utility and/or
smart grid. Accordingly, the scope of the MIB modules in this
document is broader than that specified in [EMAN-REQ].
4. Terminology
The definitions of basic terms like Energy Management, Energy
Monitoring, "Power, Energy, and Energy Consumption", Power
Monitor, Power Monitor Parent, Power Monitor Child, Power
Monitor Meter Domain, Power Level, and Manufacturer Power Level,
Nameplate Power, Power Proxy, Power Aggregator, Power
Distributor can be found in the Power Management Architecture
[EMAN-FMWK].
EDITOR'S NOTE: not sure if all terms will be used in the final
version of the draft
EDITOR'S NOTE: [EMAN-FMWK] is an informational non normative
reference. Is this fine?
5. Architecture Concepts Applied to the MIB Module
This section describes the basic concepts specified in the Power
Monitor Architecture [EMAN-FMWK], with specific information
related to the MIB module specified in this document
The following diagram shows the relationship of the identifying
information.
<Parello, Claise> Expires September 10, 2011 [Page 5]
Internet-Draft <Energy-aware Networks and Devices MIB> Mar. 2011
+-------------------------+
| _Child Specific Info __ |
+--------------------------+ | |
| Context Information | | pmParentId |
| _______________________ | | pmParentProxyAbilities |
| pmRoleDescription | | _pmMgmtMacAddress |
| pmKeywords | | pmMgmtAddress |
| pmImportance | | pmMgmtAddressType |
| pmCategory | | pmMgmtDNSName |
+--------------------------+ +-------------------------+
| |
| |
| |
v v
+-----------------------------------------+
| Power Monitor Information |
|_______________________________________ |
| pmIndex |
| pmPowerMonitorId |
| pmName |
| pmDomainName |
| pmAlternateKey |
+-----------------------------------------+
^
|
|
|
+--------------------------+
| Links to other MIBs |
| _______________________ |
| pmPhysicalEntity (*) |
| pmEthPortIndex (**) |
| pmEthPortGrpIndex (**) |
| pmLldpPortNumber (***) |
+--------------------------+
(*) Link with the ENTITY MIB [RFC4133]
(**) Link with the Power over Ethernet MIB [RFC3621]
(***) Link with LLDP MIBs [LLDP-MIB] [LLDP-MED-MIB]
Figure 1: MIB Objects Grouping
As displayed in figure 1, there are four different types of MIB
objects in the ENERGY-AWARE-MIB module:
1) The Power Monitor Information. See Section 5.1 Power Monitor
Information
<Parello, Claise> Expires September 10, 2011 [Page 6]
Internet-Draft <Energy-aware Networks and Devices MIB> Mar. 2011
2) The links to other MIB modules. See Section 5.2 Links to
other MIB Modules
3) The Power Monitor Child specific information. See Section 5.3
Power Monitor Parent and Child
4) The Context Information. See Section 5.4 Power Monitor
Context
5.1 Power Monitor Information
Refer to the "Power Monitor Information" section in [EMAN-FMWK]
for background information. An energy aware device is
considered an instance of a Power Monitor as defined in the
[EMAN-FMWK].
The Power Monitor information is specified in the MIB module
pmTable table. Every Power Monitor and MUST HAVE a unique Power
Monitor index pmIndex.
The pmIndex is a unique index greater than zero for each Power
Monitor. It is recommended that values be assigned sequentially
starting from 1.
The pmIndex is completed by the Power Monitor Universally Unique
Identifier [RFC4122] in the pmPowerMonitorId MIB object.
5.1.1. Power Monitor Name
Every Power Monitor SHOULD have a printable name pmName.
Possible pmName conventions are: textual DNS name, MAC-address
of the device, interface ifName, or a text string uniquely
identifying the Power Monitor. However, if entPhysicalName is
present for the respective pmPhysicalEntity (i.e. if the ENTITY-
MIB [RFC4133] is supported), then the pmName SHOULD be identical
to the entPhysicalName. The pmName SHOULD be unique in the
Power Monitor Meter Domain. As an example, in the case of IP
phones, pmName can be the device DNS name, while in the case of
router/switch line cards, the pmName should contain the
entPhysicalName.
To distinguish if a Power Monitor is considered producing,
consuming or metering power, the pmPowerCategory MIB object must be
implemented.
<Parello, Claise> Expires September 10, 2011 [Page 7]
Internet-Draft <Energy-aware Networks and Devices MIB> Mar. 2011
5.1.2. Power Monitor Meter Domain
Refer to the "Power Monitor Meter Domain" section in [EMAN-FMWK]
for background information.
When a Power Monitor Parent acts as a Power Aggregator or a
Power Proxy, the Power Monitor Parent and its Power Monitor
Child/Children MUST be a member of Power Monitor Meter Domain,
specified by the pmDomainName MIB Object. The pmDomainName,
which is part of the pmTable, is a read-write MIB object. Note
that the Power Monitor MUST belong to a single Power Monitor
Meter Domain.
The Power Monitor Meter Domain SHOULD map 1-1 with a metered or
sub-metered portion of the site. The Power Monitor Meter Domain
MUST be configured on the Power Monitor Parent. The Power
Monitor Children MAY inherit their domain values from the Power
Monitor Parent or the Power Monitor Meter Domain MAY be
configured directly in a Power Monitor Child.
5.1.3. Alternate Key
The pmAlternateKey object specifies a manufacturer defined
string that can be used to identify the Power Monitor. Since
Energy Management Systems (EMS) and Network Management Systems
(NMS) may need to correlate objects across management systems,
this alternate key is provided to provide such a link. This
optional value is intended as a foreign key or alternate
identifier for a manufacturer or EMS/NMS to use to correlate the
unique Power Monitor Id in other systems or namespaces. If an
alternate key is not available or is not applicable then NULL
should be returned.
5.1.4. Persistence
In some situations, the Power Monitor information should be
persistent across a reload. For example, in a static setup
where a switch monitors a series of connected PoE phones, there
is a clear benefit for the NMS if the pmIndex and all associated
information persist, as it saves a network discovery. However,
in other situations, such as a wireless access point monitoring
the mobile user PCs, there is not much advantage to persist the
Power Monitor Information. Therefore, a specific MIB object, the
pmTablePersistence, enables and disables the persistence
<Parello, Claise> Expires September 10, 2011 [Page 8]
Internet-Draft <Energy-aware Networks and Devices MIB> Mar. 2011
globally for all Power Monitors information in the ENERGY-AWARE-
MIB MIB module.
5.2 Links to other MIB Modules
The Power Monitor MUST contain the entityPhysicalIndex from the
ENTITY MIB [RFC4133] in the pmPhysicalEntity, if supported by
the Power Monitor. In case of Power over Ethernet (if the Power
over Ethernet MIB [RFC3621] is supported on the Power Monitor),
the Power Monitor pmethPortIndex and pmethPortGrpIndex MUST
contain the values of pethPsePortIndex and
pethPsePortGroupIndex, respectively. In case of LLDP-MED (if
the LLDP-MED MIB is supported on the Power Monitor), the Power
Monitor pmLldpPortNumber MUST contain the lldpLocPortNum from
the LLDP MIB [LLDP-MIB].
5.3 Power Monitor Parent and Child
Refer to the "Power Monitor Parent and Child" section in [EMAN-
FMWK] for background information. In order to link the Power
Monitor Child and the Power Monitor Parent, the pmParentId is
introduced.
The pmParentId, pmParentProxyAbilities, pmMgmtMacAddress,
pmMgmtAddress, pmMgmtAddressType, and pmMgmtDNSName MIB objects
are specific to Power Monitor Children.
The Power Monitor Child MUST set the pmParentId content to its
Power Monitor Parent pmIndex. In the case of Power Monitor
Parent, the pmParentId MUST be set to the null string
The Power Monitor Child can indicate that it wants its Power
Monitor Parent to proxy capabilities such as, energy reporting,
power state configurations, non physical wake capabilities (such
as WoL)), or any combination of capabilities. These capalities
are indicated in the pmPArentProxyAbilities object. In the case
of Power Monitor Parent, the pmParentProxyAbilities MUST be set
to "none" (0).
Since the communication between the Power Monitor Parent and
Power Monitor Child is out of the scope, a Power Monitor Child
can have additional objects used for easier identification by
the NMS: IP Address and DNS name. The MAC address is also
provided as a way to identify the Power Monitor Child: this
information is required, among other use case, by the wake on
lan feature.
<Parello, Claise> Expires September 10, 2011 [Page 9]
Internet-Draft <Energy-aware Networks and Devices MIB> Mar. 2011
5.4 Power Monitor Context
Refer to the "Power Monitor Context" section in [EMAN-FMWK] for
background information.
A Power Monitor can provide a pmImportance value in the range of
1..100 to help differentiate the use or relative value of the
device. The importance range is from 1 (least important) to 100
(most important). The default importance value is 1.
A Power Monitor can provide a set of pmKeywords. These keywords
are a list of tags that can be used for grouping and summary
reporting within or between Power Monitor Meter Domains.
Additionally, a Power Monitor can provide a pmRoleDescription
string that indicates the purpose the Power Monitor serves in
the network or for the site/business.
6. Structure of the MIB
The primary MIB object in this MIB module is the
EnergyAwareDeviceMIBObject. The pmTable table of
EnergyAwareDeviceMIBObject describes an entity in the network
that is a Power Monitor according the [EMAN-FMWK].
A Power Monitor that implements the EnergyAwareDeviceMIB
contains information describing itself as an entity in the
context of the network (such as its Power Monitor Meter Domain
pmDomainName) and attributes for describing its business context
(such as pmImportance, pmRoleDescription and pmKeywords).
The information in this MIB describes the device itself so that
the device is aware of its context in a communication network
with respect to power. The actual power usage, which is
described in [EMAN-FMWK], is specified in [EMAN-MON-MIB].
7. MIB Definitions
-- ************************************************************
--
--
-- This MIB is used to monitor power usage of network
-- devices
<Parello, Claise> Expires September 10, 2011 [Page 10]
Internet-Draft <Energy-aware Networks and Devices MIB> Mar. 2011
--
-- *************************************************************
ENERGY-AWARE-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY,
OBJECT-TYPE,
mib-2,
Integer32
FROM SNMPv2-SMI
TEXTUAL-CONVENTION, MacAddress, TruthValue
FROM SNMPv2-TC
MODULE-COMPLIANCE,
OBJECT-GROUP
FROM SNMPv2-CONF
SnmpAdminString
FROM SNMP-FRAMEWORK-MIB
InetAddressType, InetAddress
FROM INET-ADDRESS-MIB
PhysicalIndexOrZero
FROM ENTITY-MIB;
energyAwareMIB MODULE-IDENTITY
LAST-UPDATED "201103050000Z"
ORGANIZATION "IETF EMAN Working Group"
CONTACT-INFO
"WG Charter:
http://datatracker.ietf.org/wg/eman/charter/
Mailing Lists:
General Discussion: eman@ietf.org
To Subscribe: https://www.ietf.org/mailman/listinfo/eman
Archive: http://www.ietf.org/mail-archive/web/eman
Editors:
John Parello
Cisco Systems, Inc.
3550 Cisco Way
San Jose, California 95134
US
Phone: +1 408 525 2339
Email: jparello@cisco.com
<Parello, Claise> Expires September 10, 2011 [Page 11]
Internet-Draft <Energy-aware Networks and Devices MIB> Mar. 2011
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 to monitor power and energy in
devices."
REVISION
"201103050000Z"
DESCRIPTION
"Initial version, published as RFC XXXX."
::= { mib-2 xxxxx }
energyAwareMIBNotifs OBJECT IDENTIFIER
::= { energyAwareMIB 0 }
energyAwareMIBObjects OBJECT IDENTIFIER
::= { energyAwareMIB 2 }
energyAwareMIBConform OBJECT IDENTIFIER
::= { energyAwareMIB 3 }
-- Textual Conventions
PowerMonitorId ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"This object indicates the Power Monitor Universally
Unique Identifier."
REFERENCE
"IETF RFC 4122"
SYNTAX OCTET STRING (SIZE (16))
PethPsePortIndexOrZero ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"This textual convention is an extension of the
pethPsePortIndex convention, which defines a greater than
<Parello, Claise> Expires September 10, 2011 [Page 12]
Internet-Draft <Energy-aware Networks and Devices MIB> Mar. 2011
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, 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)
<Parello, Claise> Expires September 10, 2011 [Page 13]
Internet-Draft <Energy-aware Networks and Devices MIB> Mar. 2011
PowerMonitorKeywordList ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A list of keywords that can be used to group Power
Monitors for reporting or searching. If multiple keywords
are present, then this string will contain all the
keywords separated by the ',' character. For example, if
a Power Monitor were to be tagged with the keyword values
'hospitality' and 'guest', then the keyword list will be
'hospitality,guest'."
SYNTAX OCTET STRING (SIZE (0..255))
-- Objects
pmTablePersistence OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object enables/disables persistence for
all entries in the pmTable. A value of True enables the
persistence, while a value of False disables the
persistence."
::= { energyAwareMIBObjects 1 }
pmTable OBJECT-TYPE
SYNTAX SEQUENCE OF PmEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table lists Power Monitors."
::= { energyAwareMIBObjects 2 }
pmEntry OBJECT-TYPE
SYNTAX PmEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry describes the attributes of a Power Monitor.
Whenever a new Power Monitor is added or deleted a row in
the pmTable is added or deleted."
INDEX { pmIndex }
::= { pmTable 1 }
<Parello, Claise> Expires September 10, 2011 [Page 14]
Internet-Draft <Energy-aware Networks and Devices MIB> Mar. 2011
PmEntry ::= SEQUENCE {
pmIndex Integer32,
pmPowerMonitorId PowerMonitorId,
pmPhysicalEntity PhysicalIndexOrZero,
pmEthPortIndex PethPsePortIndexOrZero,
pmEthPortGrpIndex PethPsePortGroupIndexOrZero,
pmLldpPortNumber LldpPortNumberOrZero,
pmName SnmpAdminString,
pmDomainName SnmpAdminString,
pmRoleDescription SnmpAdminString,
pmMgmtMacAddress MacAddress,
pmMgmtAddressType InetAddressType,
pmMgmtAddress InetAddress,
pmMgmtDNSName SnmpAdminString,
pmAlternateKey SnmpAdminString,
pmKeywords PowerMonitorKeywordList,
pmImportance Integer32,
pmPowerCategory INTEGER,
pmParentId PowerMonitorId,
pmParentProxyAbilities BITS
}
pmIndex OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A unique value, greater than zero, for each Power
Monitor. It is recommended that values be assigned
sequentially starting from 1. The value for each pmIndex
must remain constant at least from one re-initialization
of the entity's network management system to the next re-
initialization."
::= { pmEntry 1 }
pmPowerMonitorId OBJECT-TYPE
SYNTAX PowerMonitorId
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates the Power Monitor UUID
identifier."
::= { pmEntry 2 }
pmPhysicalEntity OBJECT-TYPE
SYNTAX PhysicalIndexOrZero
MAX-ACCESS read-only
<Parello, Claise> Expires September 10, 2011 [Page 15]
Internet-Draft <Energy-aware Networks and Devices MIB> Mar. 2011
STATUS current
DESCRIPTION
"This object contains the index of a physical entity in
the ENTITY MIB [RFC4133]. This physical entity is the
given observation point. If such a physical entity
cannot be specified or is not known then the object is
zero."
::= { pmEntry 3 }
pmEthPortIndex OBJECT-TYPE
SYNTAX PethPsePortIndexOrZero
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This variable uniquely identifies the power Ethernet
port to which the attached device is connected [RFC3621].
If such a power Ethernet port cannot be specified or is
not known then the object is zero."
::= { pmEntry 4 }
pmEthPortGrpIndex OBJECT-TYPE
SYNTAX PethPsePortGroupIndexOrZero
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This variable uniquely identifies the group containing
the port to which a power Ethernet PSE is connected
[RFC3621]. If such a group cannot be specified or is not
known then the object is zero."
::= { pmEntry 5 }
pmLldpPortNumber OBJECT-TYPE
SYNTAX LldpPortNumberOrZero
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This variable uniquely identifies the port component
(contained in the local chassis with the LLDP agent) as
defined by the lldpLocPortNum in the [LLDP-MIB] and
[LLDP-MED-MIB]. If such a port number cannot be specified
or is not known then the object is zero."
::= { pmEntry 6 }
pmName OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-write
STATUS current
DESCRIPTION
<Parello, Claise> Expires September 10, 2011 [Page 16]
Internet-Draft <Energy-aware Networks and Devices MIB> Mar. 2011
"This object specifies a printable name, a text string,
for the Power Monitor. The pmName SHOULD be unique. If
pmPhysicalName is present for the respective
pmPhysicalEntity (i.e. if the ENTITY-MIB [RFC4133] is
supported), then the pmName SHOULD be identical to the
pmPhysicalName. If pmPhysicalName is not present, the
process to assign the pmName can be implementation
specific. Example: DNS Name, MAC address in canonical
form, ifName, etc.
However, if pmPhysicalName is present for the respective
pmPhysicalEntity (i.e. if the ENTITY-MIB [RFC4133] is
supported), then the pmName should be identical to the
pmPhysicalName."
::= { pmEntry 7 }
pmDomainName OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object specifies the name of a Power Monitor Meter
Domain for the Power Monitor. This object specifies a
null string if no Power Monitor Domain name is
configured. The value of pmDomainName must remain
constant at least from one re-initialization of the
entity's network management system to the next re-
initialization."
::= { pmEntry 8 }
pmRoleDescription OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object specifies an administratively assigned name
to indicate the purpose a Power Monitor serves in the
network.
For example, we can have a phone deployed to a lobby with
pmRoleDescription as 'Lobby IP phone'.
This object specifies a null string if no role
description is configured."
::= { pmEntry 9 }
pmMgmtMacAddress OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS read-only
<Parello, Claise> Expires September 10, 2011 [Page 17]
Internet-Draft <Energy-aware Networks and Devices MIB> Mar. 2011
STATUS current
DESCRIPTION
"This object specifies a MAC address of the Power
Monitor. This object only applies to Power Monitor
Children. For a Power Monitor Parent, the value SHOULD be
set to the null string."
::= { pmEntry 10 }
pmMgmtAddressType OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object specifies the pmMgmtAddress type, i.e. an
IPv4 address or an IPv6 address. This object only applies
to a Power Monitor Children. For a Power Monitor only
Parent, the value SHOULD be set to unknown(0)."
::= { pmEntry 11 }
pmMgmtAddress OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object specifies the management address as an IPv4
address or IPv6 address of Power Monitor. The IP address
type, i.e. IPv4 or IPv6, is determined by the
pmMgmtAddressType value. This object only applies to a
Power Monitor Children. For a Power Monitor, the value
SHOULD be set to the null string."
::= { pmEntry 12 }
pmMgmtDNSName OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object specifies the DNS name of the pmMgmtAddress.
This object only applies to a Power Monitor Children. For
a Power Monitor Parent, the value SHOULD be set to the
null string."
::= { pmEntry 13 }
pmAlternateKey OBJECT-TYPE
SYNTAX SnmpAdminString
<Parello, Claise> Expires September 10, 2011 [Page 18]
Internet-Draft <Energy-aware Networks and Devices MIB> Mar. 2011
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object specifies a manufacturer defined string that
can be used to identify the Power Monitor. Since Element
Management Systems (EMS) and Network Management Systems
(NMS) may need to correlate objects across management
systems, this alternate key is provided to provide such a
link. This optional value is intended as a foreign key or
alternate identifier for a manufacturer or EMS/NMS to use
to correlate the unique Power Monitor Id in other systems
or namespaces. If an alternate key is not available or is
not applicable then NULL should be returned."
::= { pmEntry 14 }
pmKeywords OBJECT-TYPE
SYNTAX PowerMonitorKeywordList
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object specifies a list of keywords that can be
used to group Power Monitors for reporting or searching.
This object specifies the null string if no keywords have
been configured. If multiple keywords are present, then
this string will contain all the keywords separated by
the ',' character. For example, if a Power Monitor were
to be tagged with the keyword values 'hospitality' and
'guest', then the keyword list will be
'hospitality,guest'.
If write access is implemented and a value is written
into the instance, the agent must retain the supplied
value in the pmKeywords instance associated with
the same physical entity for as long as that entity
remains instantiated. This includes instantiations
across all re-initializations/reboots of the network
management system."
::= { pmEntry 15 }
pmImportance OBJECT-TYPE
SYNTAX Integer32 (1..100)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object specifies a ranking of how important the
Power Monitor is (on a scale of 1 to 100) compared with
other Power Monitors in the same Power Monitor Meter
Domain. The ranking should provide a business or
<Parello, Claise> Expires September 10, 2011 [Page 19]
Internet-Draft <Energy-aware Networks and Devices MIB> Mar. 2011
operational context for the Power Monitor as compared to
other similar Power Monitors. This ranking could be used
as input for policy-based network management.
Although network managers must establish their own
ranking, the following is a broad recommendation:
90 to 100 Emergency response
80 to 90 Executive or business critical
70 to 79 General or Average
60 to 69 Staff or support
40 to 59 Public or guest
1 to 39 Decorative or hospitality"
DEFVAL { 1 }
::= { pmEntry 16 }
pmPowerCategory OBJECT-TYPE
SYNTAX INTEGER {
consumer(0),
provider(1),
meter(2)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object describes the Power Monitor and indicates
the expected power usage of the Power Monitor. A Power
Monitor could be designed or manufactured to be a
provider(1), consumer(0) or meter(2) of power.
The actual power direction is indicated by the sign of
pmPower, with positive representing consumption and
negative representing production, and may or may not
match the expected value of pmPowerCategory. In these
cases the two objects can be used to detect unexpected
conditions of the Power Monitor.
For example a generator with a category of provider(1)
that is malfunctioning and is consuming power as
indicated by a positive pmPower value."
::= { pmEntry 17 }
pmParentId OBJECT-TYPE
SYNTAX PowerMonitorId
MAX-ACCESS read-only
STATUS current
DESCRIPTION
<Parello, Claise> Expires September 10, 2011 [Page 20]
Internet-Draft <Energy-aware Networks and Devices MIB> Mar. 2011
"If the current Power Monitor has a Power Monitor Parent,
then its Power Monitor Id value is set in pmParentId.
This object only applies to Power Monitor Children. When
the Power Monitor is a Power Monitor Parent, the
pmParentId value MUST be set to the null string.
"
::= { pmEntry 18 }
pmParentProxyAbilities OBJECT-TYPE
SYNTAX BITS {
none(0),
report(1),
configuration(2),
wakeonlan(3)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object describes the capabilities of the Power
Monitor Parent (represented by the pmParentId) for the
Power Monitor Child, represented by the pmIndex. This
object only applies to a Power Monitor Child.
None (0) MUST be used when the Power Monitor represented
by the pmIndex is a Power Monitor Parent, and no other
bit can be set.
Report(1) indicates that the Power Monitor Parent reports
the usage for the Power Monitor Child.
Configuration(2) indicates that the Power Monitor Parent
can configure the Power Level for the Power Monitor
Child.
Wakeonlan(3) indicates that the Power Monitor Parent can
wake up the Power Monitor Child, whatever the mechanism."
::= { pmEntry 19 }
-- Conformance
energyAwareMIBCompliances OBJECT IDENTIFIER
::= { energyAwareMIBObjects 3 }
energyAwareMIBGroups OBJECT IDENTIFIER
::= { energyAwareMIBObjects 4 }
energyAwareMIBFullCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"When this MIB is implemented with support for
<Parello, Claise> Expires September 10, 2011 [Page 21]
Internet-Draft <Energy-aware Networks and Devices MIB> Mar. 2011
read-create, then such an implementation can
claim full compliance. Such devices can then
be both monitored and configured with this MIB."
MODULE -- this module
MANDATORY-GROUPS {
energyAwareMIBTableGroup
}
::= { energyAwareMIBCompliances 1 }
energyAwareMIBReadOnlyCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"When this MIB is implemented without support for
read-create (i.e. in read-only mode), then such an
implementation can claim read-only compliance. Such a
device can then be monitored but can not be configured
with this MIB."
MODULE -- this module
MANDATORY-GROUPS {
energyAwareMIBTableGroup
}
OBJECT pmTablePersistence
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT pmName
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT pmDomainName
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT pmRoleDescription
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT pmKeywords
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
<Parello, Claise> Expires September 10, 2011 [Page 22]
Internet-Draft <Energy-aware Networks and Devices MIB> Mar. 2011
OBJECT pmImportance
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
::= { energyAwareMIBCompliances 2 }
-- Units of Conformance
energyAwareMIBTableGroup OBJECT-GROUP
OBJECTS {
-- Note that object pmIndex is NOT
-- included since it is not-accessible
pmTablePersistence,
pmPowerMonitorId,
pmPhysicalEntity,
pmEthPortIndex,
pmEthPortGrpIndex,
pmLldpPortNumber,
pmName,
pmDomainName,
pmRoleDescription,
pmMgmtMacAddress,
pmMgmtAddressType,
pmMgmtAddress,
pmMgmtDNSName,
pmAlternateKey,
pmKeywords,
pmImportance,
pmPowerCategory,
pmParentId,
pmParentProxyAbilities
}
STATUS current
DESCRIPTION
"This group contains the collection of all the objects
related to the PowerMonitor."
::= { energyAwareMIBGroups 1 }
END
8. Security Considerations
Some of the readable objects in these MIB modules (i.e., objects
with a MAX-ACCESS other than not-accessible) may be considered
sensitive or vulnerable in some network environments. It is
<Parello, Claise> Expires September 10, 2011 [Page 23]
Internet-Draft <Energy-aware Networks and Devices MIB> Mar. 2011
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:
. Unauthorized changes to the pmDomainName, pmName,
pmRoleDescription, pmKeywords, and/or pmImportance MAY
disrupt power and energy collection, and therefore any
predefined policies defined in the network.
SNMP versions prior to SNMPv3 did not include adequate security.
Even if the network itself is secure (for example, by using
IPsec), there is still no secure control over who on the secure
network is allowed to access and GET/SET
(read/change/create/delete) the objects in these MIB modules.
It is RECOMMENDED that implementers consider the security
features as provided by the SNMPv3 framework (see [RFC3410],
section 8), including full support for the SNMPv3 cryptographic
mechanisms (for authentication and privacy).
Further, deployment of SNMP versions prior to SNMPv3 is NOT
RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to
enable cryptographic security. It is then a customer/operator
responsibility to ensure that the SNMP entity giving access to
an instance of these MIB modules is properly configured to give
access to the objects only to those principals (users) that have
legitimate rights to GET or SET (change/create/delete) them.
9. IANA Considerations
The MIB module in this document uses the following IANA-assigned
OBJECT IDENTIFIER values recorded in the SMI Numbers registry:
Descriptor OBJECT IDENTIFIER value
---------- -----------------------
energyAwareMIB { mib-2 xxx }
<Parello, Claise> Expires September 10, 2011 [Page 24]
Internet-Draft <Energy-aware Networks and Devices MIB> Mar. 2011
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.
10. References
10.1. Normative References
[RFC2119] S. Bradner, Key words for use in RFCs to Indicate
Requirement Levels, BCP 14, RFC 2119, March 1997.
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Structure of Management
Information Version 2 (SMIv2)", STD 58, RFC 2578, April
1999.
[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Textual Conventions for SMIv2",
STD 58, RFC 2579, April 1999.
[RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Conformance Statements for SMIv2", STD 58, RFC 2580,
April 1999.
[RFC3621] Berger, A., and D. Romascanu, "Power Ethernet MIB",
RFC3621, December 2003.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace ", RFC 4122,
July 2005.
[RFC4133] Bierman, A. and K. McCloghrie, "Entity MIB (Version
3)", RFC 4133, August 2005.
[LLDP-MIB] IEEE 802.1AB-2005, "Management Information Base
module for LLDP configuration, statistics, local system
data and remote systems data components", May 2005.
<Parello, Claise> Expires September 10, 2011 [Page 25]
Internet-Draft <Energy-aware Networks and Devices MIB> Mar. 2011
[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] Claise, B., Chandramouli, M., Parello, J., and
Schoening, B., "Power and Energy Monitoring MIB",
draft-claise-energy-monitoring-mib-06, (work in
progress), October 2010.
10.2. Informative References
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for Internet
Standard Management Framework ", RFC 3410, December
2002.
[RFC5226] Narten, T. Alverstrand, H., A. and K. McCloghrie,
"Guidelines for Writing an IANA Considerations Section
in RFCs ", BCP 26, RFC 5226, May 2008.
[EMAN-REQ] Quittek, J., Winter, R., Dietz, T., Claise, B., and
M. Chandramouli, "Requirements for Power Monitoring",
draft-ietf-eman-requirements-00 (work in progress),
December 2010.
[EMAN-FMWK] Claise, B., Parello, J., Schoening, B., and J.
Quittek, draft-ietf-eman-framework-00, (work in
progress), December 2010.
[EMAN-AS] Tychon, E., Laherty, M., and B. Schoening, "Energy
Management (EMAN) Applicability Statement", draft-
tychon-eman-applicability-statement-00, (work in
progress), October 2010
11. Acknowledgments
The authors would like to thank Juergen Quittek, Brad Schoening,
and Mouli Chandramouli for their help, as well as Michael Brown
for improving the text dramatically.
<Parello, Claise> Expires September 10, 2011 [Page 26]
Internet-Draft <Energy-aware Networks and Devices MIB> Mar. 2011
Authors' Addresses
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
<Parello, Claise> Expires September 10, 2011 [Page 27]
| PAFTECH AB 2003-2026 | 2026-04-24 02:33:05 |