Network Working Group J. Quittek
Internet-Draft R. Winter
Intended status: Standards Track T. Dietz
Expires: December 29, 2011 NEC Europe Ltd.
June 27, 2011
Definition of Managed Objects for Battery Monitoring
draft-ietf-eman-battery-mib-01
Abstract
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it defines managed objects that provide information on
the status of batteries in managed devices.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on December 29, 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.
Quittek, et al. Expires December 29, 2011 [Page 1]
Internet-Draft Battery MIB June 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The Internet-Standard Management Framework . . . . . . . . . . 4
3. Structure of the Battery MIB Module . . . . . . . . . . . . . 4
4. Battery Technologies . . . . . . . . . . . . . . . . . . . . . 6
5. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
7.1. SMI Object Identifier Registration . . . . . . . . . . . . 20
7.2. Battery Technology Registration . . . . . . . . . . . . . 21
8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.1. Define Charging Cycle . . . . . . . . . . . . . . . . . . 21
8.2. Writable Notification thresholds . . . . . . . . . . . . . 21
8.3. Re-arming batteryLowNotification . . . . . . . . . . . . . 22
8.4. Add Charging Data of Batteries? . . . . . . . . . . . . . 22
8.5. Add batteryHealth? . . . . . . . . . . . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Normative References . . . . . . . . . . . . . . . . . . . 22
9.2. Informative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
Quittek, et al. Expires December 29, 2011 [Page 2]
Internet-Draft Battery MIB June 2011
1. Introduction
Today, more and more managed devices contain batteries that supply
them with power when disconnected from electrical power distribution
grids. Common examples are nomadic and mobile devices, such as
notebook computers, netbooks, and smart phones. The status of
batteries in such a device, particularly the charging status is
typically controlled by automatic functions that act locally on the
device and manually by users of the device.
In addition to this, there is a need to monitor battery status of
these devices by network management systems. This document defines a
portion of the Management Information Base (MIB) that provides means
for monitoring batteries in or attached to managed devices. The
Battery MIB module defined in Section 5 meets the requirements for
monitoring the status of batteries specified in
[I-D.ietf-eman-requirements].
The Battery MIB module serves for monitoring the battery status. It
does not implement a Power Monitor as defined in the framework for
energy management [I-D.ietf-eman-framework]. Amongst other things,
the Battery MIB allows to monitor:
o the current charge of a battery,
o the age of a battery (charging cycles),
o the state of a battery (e.g. being re-charged),
o last usage of a battery,
o maximum energy provided by a battery (remaining and total
capacity).
Further, means are provided for battery-powered devices to send
notifications when the current battery charge has dropped below a
certain threshold in order to inform the management system of needed
replacement. The same applies to the age of a battery.
There is already instrumentation for monitoring battery status on
many battery-driven devices, because this is already needed for local
control of the battery by the device. This reduces the effort for
implementing the managed objects defined in this document. For many
devices only additional software will be needed but no additional
hardware instrumentation for battery monitoring.
Since there are a lot of devices in use that contain more than one
battery, means for battery monitoring defined in this document
support addressing multiple batteries within a single device. Also,
batteries today often come in packages that can include
identification and might contain additional hardware and firmware.
The former allows to trace a battery and allows continuous monitoring
Quittek, et al. Expires December 29, 2011 [Page 3]
Internet-Draft Battery MIB June 2011
even if the battery is e.g. installed in another device. The
firmware version is useful information as the battery behavior might
be different for different firmware versions.
Not explicitly in scope of definitions in this document are very
small backup batteries, such as for example, batteries used on PC
motherboard to run the clock circuit and retain configuration memory
while the system is turned off. Other means may be required for
reporting on these batteries. However, the MIB module defined in
Section 3 can be used for this purpose.
A traditional type of managed device containing batteries is an
Uninterruptible Power Supply (UPS) system; these supply other devices
with electrical energy when the main power supply fails. There is
already a MIB module for managing UPS systems defined in RFC 1628
[RFC1628]. This module includes managed objects for monitoring the
batteries contained in an UPS system. However, the information
provided by these objects is limited and tailored the particular
needs of UPS systems.
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].
2. The Internet-Standard Management Framework
For a detailed overview of the documents that describe the current
Internet-Standard Management Framework, please refer to section 7 of
RFC 3410 [RFC3410].
Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. MIB objects are generally
accessed through the Simple Network Management Protocol (SNMP).
Objects in the MIB are defined using the mechanisms defined in the
Structure of Management Information (SMI). This memo specifies MIB
modules that are compliant to the SMIv2, which is described in STD
58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58,RFC
2580 [RFC2580].
3. Structure of the Battery MIB Module
The Battery MIB module defined in this document defines objects for
reporting information about batteries. All managed objects providing
information of the status of a battery are contained in a single
table called batteryTable. The batteryTable contains one conceptual
Quittek, et al. Expires December 29, 2011 [Page 4]
Internet-Draft Battery MIB June 2011
row per battery.
If there is an implementation of the Entity MIB module [RFC4133] that
identifies the batteries to be reported on by individual values for
managed object entPhysicalIndex, then it is REQUIRED that these
values are used as index values for the batteryTable.
The kind of entity in the entPhysicalTable of the Entity MIB module
is indicated by the value of enumeration object entPhysicalClass.
Since there is no value called 'battery' defined for this object, it
is RECOMMENDED that for batteries the value of this object is chosen
to be powerSupply(6).
The batteryTable contains three groups of objects. The first group
(OIDs ending with 2-8) provides information on static properties of
the battery. The second group of objects (OIDs ending with 9-16)
provides information on the current battery state, if it is charging
or discharging, how much it is charged, its remaining capacity, the
number of experienced charging cycles, etc.
batteryTable(1)
+--batteryEntry(1) [batteryIndex]
+-- --- Integer32 batteryIndex(1)
+-- r-n SnmpAdminString batteryIdentifier(2)
+-- r-n SnmpAdminString batteryFirmwareVersion(3)
+-- r-n Enumeration batteryType(4)
+-- r-n Unsigned32 batteryTechnology(5)
+-- r-n Unsigned32 batteryNominalVoltage(6)
+-- r-n Unsigned32 batteryNumberOfCells(7)
+-- r-n Unsigned32 batteryNominalCapacity(8)
+-- r-n Unsigned32 batteryRemainingCapacity(9)
+-- r-n Unsigned32 batteryChargingCycleCount(10)
+-- r-n DateAndTime batteryLastChargingCycleTime(11)
+-- r-n Enumeration batteryChargingState(12)
+-- r-n Unsigned32 batteryCurrentCharge(13)
+-- r-n Unsigned32 batteryCurrentVoltage(14)
+-- r-n Integer32 batteryCurrentCurrent(15)
+-- r-n Integer32 batteryTemperature(16)
+-- rwn Unsigned32 batteryLowAlarmPercentage(17)
+-- rwn Unsigned32 batteryLowAlarmVoltage(18)
+-- rwn Unsigned32 batteryReplacementAlarmCapacity(19)
+-- rwn Unsigned32 batteryReplacementAlarmCycles(20)
The third group of objects in this table (OIDs ending with 17-20)
indicates thresholds which can be used to raise an alarm if a
property of the battery exceeds one of them. Raising an alarm may
include sending a notification.
Quittek, et al. Expires December 29, 2011 [Page 5]
Internet-Draft Battery MIB June 2011
The Battery MIB defines two notifications, one indicating a low
battery charging state and one indicating an aged battery that may
need to be replaced.
4. Battery Technologies
Static information in the batteryTable includes battery type and
technology. The battery type distinguishes primary (not re-
chargeable) batteries from secondary (re-chargeable) batteries and
capacitors. The battery technology describes the actual technology
of a battery, which typically is a chemical technology.
Since battery technologies are subject of intensive research and
massively used technologies are often replaced by successor
technologies within an few years, the list of battery technologies
was not chosen as a fixed list. Instead, IANA has created a registry
for battery technologies at http://www.iana.org/assignments/eman
where numbers are assigned to battery technologies (TBD).
The table below shows battery technologies known today that are in
commercial use with the numbers assigned to them by IANA. New
entries can be added to the IANA registry if new technologies get
developed or if missing technologies are identified. Note that there
exists a huge number of battery types that are not listed in the IANA
registry. Many of them are experimental or cannot be used in an
economically useful way. New entries should be added to the IANA
registry only if the respective technologies are in commercial use
and relevant to standardized battery monitoring over the Internet.
Quittek, et al. Expires December 29, 2011 [Page 6]
Internet-Draft Battery MIB June 2011
+----------------------------+----------+
| battery technology | assigned |
| | number |
+----------------------------+----------+
| unknown | 1 |
| other | 2 |
| Zinc-carbon | 3 |
| Zinc-chloride | 4 |
| Oxy nickel hydroxide | 5 |
| lithium-copper oxide | 6 |
| lithium-iron disulfide | 7 |
| lithium-manganese dioxide | 8 |
| Zinc-air | 9 |
| Silver-oxide | 10 |
| Alkaline | 11 |
| Lead acid | 12 |
| Nickel-cadmium | 13 |
| Nickel-metal hybride | 14 |
| Nickel-zinc | 15 |
| Lithium ion | 16 |
| Lithium polymer | 17 |
| Double layer capacitor | 18 |
+----------------------------+----------+
5. Definitions
BATTERY-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
mib-2, Integer32, Unsigned32
FROM SNMPv2-SMI -- RFC2578
SnmpAdminString
FROM SNMP-FRAMEWORK-MIB -- RFC3411
DateAndTime
FROM SNMPv2-TC -- RFC2579
MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
FROM SNMPv2-CONF; -- RFC2580
batteryMIB MODULE-IDENTITY
LAST-UPDATED "201106261200Z" -- 26 june 2010
ORGANIZATION "IETF EMAN Working Group"
CONTACT-INFO
"General Discussion: eman@ietf.org
To Subscribe: http://www.ietf.org/mailman/listinfo/eman
Archive: http://www.ietf.org/mail-archive/web/eman
Quittek, et al. Expires December 29, 2011 [Page 7]
Internet-Draft Battery MIB June 2011
Editor:
Juergen Quittek
NEC Europe Ltd.
NEC Laboratories Europe
Kurfuersten-Anlage 36
69115 Heidelberg
Germany
Tel: +49 6221 4342-115
Email: quittek@neclab.eu"
DESCRIPTION
"This MIB module defines a set of objects for monitoring
batteries of networked devices and of their components.
Copyright (c) 2010 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD
License set forth in Section 4.c of the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info).
This version of this MIB module is part of RFC yyyy; see
the RFC itself for full legal notices."
-- replace yyyy with actual RFC number & remove this notice
-- Revision history
REVISION "201106261200Z" -- 26 June 2010
DESCRIPTION
"Initial version, published as RFC yyyy."
-- replace yyyy with actual RFC number & remove this notice
::= { mib-2 zzz }
-- zzz to be assigned by IANA.
--******************************************************************
-- Top Level Structure of the MIB module
--******************************************************************
batteryNotifications OBJECT IDENTIFIER ::= { batteryMIB 0 }
batteryObjects OBJECT IDENTIFIER ::= { batteryMIB 1 }
batteryConformance OBJECT IDENTIFIER ::= { batteryMIB 2 }
--==================================================================
-- 1. Object Definitions
Quittek, et al. Expires December 29, 2011 [Page 8]
Internet-Draft Battery MIB June 2011
--==================================================================
--------------------------------------------------------------------
-- 1.1. Battery Table
--------------------------------------------------------------------
batteryTable OBJECT-TYPE
SYNTAX SEQUENCE OF BatteryEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table provides information on batteries.
It contains one conceptual row per battery."
::= { batteryObjects 1 }
batteryEntry OBJECT-TYPE
SYNTAX BatteryEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry providing information on a battery."
INDEX { batteryIndex }
::= { batteryTable 1 }
BatteryEntry ::=
SEQUENCE {
batteryIndex Integer32,
batteryIdentifier SnmpAdminString,
batteryFirmwareVersion SnmpAdminString,
batteryType INTEGER,
batteryTechnology Unsigned32,
batteryNominalVoltage Unsigned32,
batteryNumberOfCells Unsigned32,
batteryNominalCapacity Unsigned32,
batteryActualCapacity Unsigned32,
batteryChargingCycleCount Unsigned32,
batteryLastChargingCycleTime DateAndTime,
batteryChargingState INTEGER,
batteryCurrentCharge Unsigned32,
batteryCurrentVoltage Unsigned32,
batteryCurrentCurrent Integer32,
batteryTemperature Integer32,
batteryLowAlarmCharge Unsigned32,
batteryLowAlarmVoltage Unsigned32,
batteryReplacementAlarmCapacity Unsigned32,
batteryReplacementAlarmCycles Unsigned32
}
batteryIndex OBJECT-TYPE
Quittek, et al. Expires December 29, 2011 [Page 9]
Internet-Draft Battery MIB June 2011
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This object identifies a battery for which status is
reported. Index values MUST be locally unique.
If there is an instance of the entPhysicalTable (defined in
the ENTITY-MIB module, see RFC 4133) with an individual
entry for each battery, then it is REQUIRED that values of
batteryIndex match the corresponding values of
entPhysicalIndex for the batteries. Otherwise, index values
may be chosen arbitrarily."
::= { batteryEntry 1 }
batteryIdentifier OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object contains an identifier for the battery.
Many manufacturers deliver not pure batteries but battery
packages including additional hardware and firmware.
Typically, these modules include an identifier that can be
retrieved by a device at which a battery has been installed.
The identifier is useful when batteries are removed and
re-installed at the same or other devices. Then the device
or the network management system can trace batteries and
achieve continuity of battery monitoring.
If the battery identifier cannot be represented using the
ISO/IEC IS 10646-1 character set, then a hexadecimal
encoding of a binary representation of the battery
identifier must be used.
The value of this object must be an empty string if there
is no battery identifier or if the battery idenitfier is
unknown."
::= { batteryEntry 2 }
batteryFirmwareVersion OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates the version number of the firmware
that is included in a battery module.
Quittek, et al. Expires December 29, 2011 [Page 10]
Internet-Draft Battery MIB June 2011
Many manufacturers deliver not pure batteries but battery
packages including additional hardware and firmware.
Since the bahavior of the battery may change with the
firmware, it may be useful to retrieve the firmware version
number.
The value of this object must be an empty string if there
is no firmware or if the version number of the firware is
unknown."
::= { batteryEntry 3 }
batteryType OBJECT-TYPE
SYNTAX INTEGER {
unknown(1),
other(2),
primary(3),
rechargeable(4),
capacitor(5)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates the type of battery.
It distinguishes between primary (not re-chargeable)
batteries, secondary (rechargeable) batteries and capacitors
which are not really batteries but often used in the same
way as a battery.
The value other(1) can be used if the battery type is known
but none of the ones above. Value unknown(2) is to be used
if the type of battery cannot be determined."
::= { batteryEntry 4 }
batteryTechnology OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates the technology used by the battery.
Numbers identifying battery types are registered at IANA.
A current list of assignments can be found at
<http://www.iana.org/assignments/eman>.
Value 0 (unknown) MUST be used if the type of battery
cannot be determined.
Value 1 (other) can be used if the battery type is known
Quittek, et al. Expires December 29, 2011 [Page 11]
Internet-Draft Battery MIB June 2011
but not one of the types already registered at IANA."
::= { batteryEntry 5 }
batteryNominalVoltage OBJECT-TYPE
SYNTAX Unsigned32
UNITS "millivolt"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object provides the nominal voltage of the battery
in units of millivolt (mV).
Note that the nominal voltage is a constant value and
typically different from the actual voltage of the battery.
A value of 0 indicates that the nominal voltage is unknown."
::= { batteryEntry 6 }
batteryNumberOfCells OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates the number of cells contained in the
battery.
A value of 0 indicates that the number of cells is unknown."
::= { batteryEntry 7 }
batteryNominalCapacity OBJECT-TYPE
SYNTAX Unsigned32
UNITS "milliampere hours"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object provides the nominal capacity of the battery
in units of milliampere hours (mAh).
Note that the nominal capacity is a constant value and
typically different from the actual capacity of the battery.
A value of 0 indicates that the nominal capacity is
unknown."
::= { batteryEntry 8 }
batteryActualCapacity OBJECT-TYPE
SYNTAX Unsigned32
UNITS "milliampere hours"
Quittek, et al. Expires December 29, 2011 [Page 12]
Internet-Draft Battery MIB June 2011
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object provides the actual capacity of the
battery in units of milliampere hours (mAh).
Note that the actual capacity needs to be measured and is
typically an estimate based on observed discharging and
charging cycles of the battery.
A value of 'ffffffff'H indicates that the actual capacity
cannot be determined."
::= { batteryEntry 9 }
batteryChargingCycleCount OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates the number of charging cycles that
that the battery underwent. Please note that the precise
definition of a recharge cycle varies for different kinds
of batteries and of devices containing batteries.
For batteries of type primary(1) the value of this object is
always 0.
A value of 'ffffffff'H indicates that the number of charging
cycles cannot be determined."
::= { batteryEntry 10 }
batteryLastChargingCycleTime OBJECT-TYPE
SYNTAX DateAndTime
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The date and time of the last charging cycle. The value
'0000000000000000'H is returned if the battery has not been
charged yet or if the last charging time cannot be
determined.
For batteries of type primary(1) the value of this object is
always '0000000000000000'H."
::= { batteryEntry 11 }
batteryChargingState OBJECT-TYPE
SYNTAX INTEGER {
unknown(1),
Quittek, et al. Expires December 29, 2011 [Page 13]
Internet-Draft Battery MIB June 2011
charging(2),
maintainingCharge(3),
noCharging(4),
discharging(5)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates the current charging state of the
battery.
Value unknown(1) indicates that the charging state of the
battery cannot be determined.
Value charging(2) indicates that the battery is being
charged in a way that the charge of the battery increases.
Value maintainingCharge(3) indicates that the battery is
being charged with a low current that compensates
self-discharging. This includes trickle charging, float
charging and other methods for maintaining the current
charge of a battery.
Value noCharging(4) indicates that the battery is not
charged or discharged by electric current between the
battery and electric circuits external to the battery.
Note that the battery may still be subject to
self-discharging.
Value discharging(5) indicates that the battery is being
discharged and that the charge of the battery decreases."
::= { batteryEntry 12 }
batteryCurrentCharge OBJECT-TYPE
SYNTAX Unsigned32
UNITS "milliampere hours"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object provides the current charge of the battery
in units of milliampere hours (mAh).
Note that the current charge needs to be measured and is
typically an estimate based on observed discharging and
charging cycles of the battery.
A value of 'ffffffff'H indicates that the current charge
cannot be determined."
Quittek, et al. Expires December 29, 2011 [Page 14]
Internet-Draft Battery MIB June 2011
::= { batteryEntry 13 }
batteryCurrentVoltage OBJECT-TYPE
SYNTAX Unsigned32
UNITS "millivolt"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object provides the current voltage of the battery
in units of millivolt (mV).
A value of 'ffffffff'H indicates that the current voltage
cannot be determined."
::= { batteryEntry 14 }
batteryCurrentCurrent OBJECT-TYPE
SYNTAX Integer32
UNITS "milliampere"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object provides the current charging or discharging
current of the battery in units of milliampere (mA).
Charging current is represented by positive values,
discharging current is represented by negative values.
A value of '7fffffff'H indicates that the current current
cannot be determined."
::= { batteryEntry 15 }
batteryTemperature OBJECT-TYPE
SYNTAX Integer32
UNITS "degrees Celsius"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The ambient temperature at or near the battery.
A value of '7fffffff'H indicates that the temperature
cannot be determined."
::= { batteryEntry 16 }
batteryLowAlarmCharge OBJECT-TYPE
SYNTAX Unsigned32
UNITS "milliampere hours"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
Quittek, et al. Expires December 29, 2011 [Page 15]
Internet-Draft Battery MIB June 2011
"This object provides the lower threshold value for object
batteryCurrentCharge. If the value of object
batteryCurrentCharge falls below this threshold,
a low battery alarm will be raised. The alarm procedure may
include generating a batteryLowNotification.
A value of 0 indicates that no alarm will be raised for
any value of object batteryCurrentCharge."
::= { batteryEntry 17 }
batteryLowAlarmVoltage OBJECT-TYPE
SYNTAX Unsigned32
UNITS "millivolt"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object provides the lower threshold value for object
batteryCurrentVoltage. If the value of object
batteryCurrentVoltage falls below this threshold,
a low battery alarm will be raised. The alarm procedure may
include generating a batteryLowNotification.
A value of 0 indicates that the no alarm will be raised for
any value of object batteryCurrentVoltage."
::= { batteryEntry 18 }
batteryReplacementAlarmCapacity OBJECT-TYPE
SYNTAX Unsigned32
UNITS "milliampere hours"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object provides the lower threshold value for object
batteryActualCapacity. If the value of object
batteryActualCapacity falls below this threshold,
a battery aging alarm will be raised. The alarm procedure
may include generating a batteryAgingNotification.
A value of 0 indicates that the no alarm will be raised for
any value of object batteryActualCapacity."
::= { batteryEntry 19 }
batteryReplacementAlarmCycles OBJECT-TYPE
SYNTAX Unsigned32
UNITS "milliampere hours"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
Quittek, et al. Expires December 29, 2011 [Page 16]
Internet-Draft Battery MIB June 2011
"This object provides the upper threshold value for object
batteryChargingCycleCount. If the value of object
batteryChargingCycleCount rises above this threshold,
a battery aging alarm will be raised. The alarm procedure
may include generating a batteryAgingtNotification.
A value of 0 indicates that the no alarm will be raised for
any value of object batteryChargingCycleCount."
::= { batteryEntry 20 }
--==================================================================
-- 2. Notifications
--==================================================================
batteryLowNotification NOTIFICATION-TYPE
OBJECTS {
batteryCurrentCharge,
batteryCurrentVoltage
}
STATUS current
DESCRIPTION
"This notification can be generated when the current charge
(batteryCurrentCharge) or the current voltage
(batteryCurrentVoltage) of the battery falls below a
threshold defined by object batteryLowAlarmCharge or
object batteryLowAlarmVoltage, respectively."
::= { batteryNotifications 1 }
batteryAgingNotification NOTIFICATION-TYPE
OBJECTS {
batteryActualCapacity,
batteryChargingCycleCount
}
STATUS current
DESCRIPTION
"This notification can be generated when the actual
capacity (batteryActualCapacity) falls below a threshold
defined by object batteryReplacementAlarmCapacity
or when the charging cycle count of the battery
(batteryChargingCycleCount) exceeds the threshold defined
by object batteryReplacementAlarmCycles."
::= { batteryNotifications 2 }
--==================================================================
-- 3. Conformance Information
--==================================================================
Quittek, et al. Expires December 29, 2011 [Page 17]
Internet-Draft Battery MIB June 2011
batteryCompliances OBJECT IDENTIFIER ::= { batteryConformance 1 }
batteryGroups OBJECT IDENTIFIER ::= { batteryConformance 2 }
--------------------------------------------------------------------
-- 3.1. Compliance Statements
--------------------------------------------------------------------
batteryCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for implementations of the
POWER-STATE-MIB module.
A compliant implementation MUST implement the objects
defined in the mandatory groups batteryDescriptionGroup
and batteryStatusGroup."
MODULE -- this module
MANDATORY-GROUPS {
batteryDescriptionGroup,
batteryStatusGroup
}
GROUP batteryAlarmThresholdsGroup
DESCRIPTION
"A compliant implementation does not have to implement
the batteryAlarmThresholdsGroup."
GROUP batteryNotificationsGroup
DESCRIPTION
"A compliant implementation does not have to implement
the batteryNotificationsGroup."
::= { batteryCompliances 1 }
--------------------------------------------------------------------
-- 3.2. MIB Grouping
--------------------------------------------------------------------
batteryDescriptionGroup OBJECT-GROUP
OBJECTS {
batteryIdentifier,
batteryFirmwareVersion,
batteryType,
batteryTechnology,
batteryNominalVoltage,
batteryNumberOfCells,
batteryNominalCapacity
}
STATUS current
DESCRIPTION
"A compliant implementation MUST implement the objects
Quittek, et al. Expires December 29, 2011 [Page 18]
Internet-Draft Battery MIB June 2011
contained in this group."
::= { batteryGroups 1 }
batteryStatusGroup OBJECT-GROUP
OBJECTS {
batteryActualCapacity,
batteryChargingCycleCount,
batteryLastChargingCycleTime,
batteryChargingState,
batteryCurrentCharge,
batteryCurrentVoltage,
batteryCurrentCurrent,
batteryTemperature
}
STATUS current
DESCRIPTION
"A compliant implementation MUST implement the objects
contained in this group."
::= { batteryGroups 2 }
batteryAlarmThresholdsGroup OBJECT-GROUP
OBJECTS {
batteryLowAlarmCharge,
batteryLowAlarmVoltage,
batteryReplacementAlarmCapacity,
batteryReplacementAlarmCycles
}
STATUS current
DESCRIPTION
"A compliant implementation does not have to implement the
object contained in this group."
::= { batteryGroups 3 }
batteryNotificationsGroup NOTIFICATION-GROUP
NOTIFICATIONS {
batteryLowNotification,
batteryAgingNotification
}
STATUS current
DESCRIPTION
"A compliant implementation does not have to implement the
notification contained in this group."
::= { batteryGroups 4 }
END
Quittek, et al. Expires December 29, 2011 [Page 19]
Internet-Draft Battery MIB June 2011
6. Security Considerations
This sections needs to be updated after changing four managed objects
from read-only to read-write.
There are no management objects defined in this MIB module that have
a MAX-ACCESS clause of read-write and/or read-create. So, if this
MIB module is implemented correctly, then there is no risk that an
intruder can alter or create any management objects of this MIB
module via direct SNMP SET operations.
Some of the readable objects in this MIB module (i.e., objects with a
MAX-ACCESS other than not-accessible) may be considered sensitive or
vulnerable in some network environments. It is thus important to
control even GET and/or NOTIFY access to these objects and possibly
to even encrypt the values of these objects when sending them over
the network via SNMP. These are the tables and objects and their
sensitivity/vulnerability:
o This list is still to be done.
SNMP versions prior to SNMPv3 did not include adequate security.
Even if the network itself is secure (for example by using IPsec),
even then, there is no control as to who on the secure network is
allowed to access and GET/SET (read/change/create/delete) the objects
in this MIB module.
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 this MIB module is properly configured to give access to
the objects only to those principals (users) that have legitimate
rights to indeed GET or SET (change/create/delete) them.
7. IANA Considerations
7.1. SMI Object Identifier Registration
The Battery MIB module defined in this document uses the following
IANA-assigned OBJECT IDENTIFIER value recorded in the SMI Numbers
registry:
Quittek, et al. Expires December 29, 2011 [Page 20]
Internet-Draft Battery MIB June 2011
Descriptor OBJECT IDENTIFIER value
---------- -----------------------
batteryMIB { mib-2 xxx }
[NOTE for IANA: Please allocate an object identifier at
http://www.iana.org/assignments/smi-numbers for object batteryMIB.]
7.2. Battery Technology Registration
Object batteryTechnology defined in Section 5 reports battery
technologies. 18 values for battery technologies have initially been
defined. They are listed in a table in Section 4.
For ensuring extensibility of this list, IANA has created a registry
for battery technologies at http://www.iana.org/assignments/eman and
filled it with the initial list given in Section 4.
New assignments of numbers for battery technologies will be
administered by IANA through Expert Review ([RFC5226]). Experts must
check for sufficient relevance of a battery technology to be added.
[NOTE for IANA: Please create a new registry under
http://www.iana.org/assignments/eman for battery types. Please fill
the registry with values from the table in Section 4]
8. Open Issues
8.1. Define Charging Cycle
The draft is not clear about what a charging cycle is. Is there any
commonly accepted definition of it? Apple's definition "A charge
cycle means using all of the battery's power, but that doesn't
necessarily mean a single charge. For instance, you could use your
notebook for an hour or more one day, using half its power, and then
recharge it fully. If you did the same thing the next day, it would
count as one charge cycle, not two, so you may take several days to
complete a cycle." (taken from: http://support.apple.com/kb/ht1519)
One way to deal with this is to let the HW manufacturer define this
and to come up with a definition for the case the manufacturer has
not defined it.
8.2. Writable Notification thresholds
Do we want to have the thresholds for sending notifications
(batteryLowAlarmPercentage, batteryLowAlarmVoltage,
batteryReplacementAlarmCapacity, batteryReplacementAlarmCycles) to be
Quittek, et al. Expires December 29, 2011 [Page 21]
Internet-Draft Battery MIB June 2011
read-write or read-only?
8.3. Re-arming batteryLowNotification
What needs to happen after sending a batteryLowNotification before
another batteryLowNotification can be sent for the same battery?
8.4. Add Charging Data of Batteries?
Shall we add charging data to the static battery information? This
would include boost voltage, float voltage, current limitation,
maximum duration at boost voltage, and maybe some more data.
This data seems to be relevant locally for the charger however
remotely this data does not seem to be that relevant.
8.5. Add batteryHealth?
Shall we add an object batteryHealth" that can include, for example,
SymetryAlarms for lead-acid technology?
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[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.
[RFC4133] Bierman, A. and K. McCloghrie, "Entity MIB (Version 3)",
RFC 4133, August 2005.
Quittek, et al. Expires December 29, 2011 [Page 22]
Internet-Draft Battery MIB June 2011
9.2. Informative References
[I-D.ietf-eman-requirements]
Quittek, J., Winter, R., Dietz, T., Claise, B., and M.
Chandramouli, "Requirements for Energy Management",
draft-ietf-eman-requirements-01 (work in progress),
March 2011.
[I-D.ietf-eman-framework]
Claise, B., Parello, J., and L. Silver, "Energy Management
Framework", draft-ietf-eman-framework-01 (work in
progress), March 2011.
[RFC1628] Case, J., "UPS Management Information Base", RFC 1628,
May 1994.
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC 3410, December 2002.
Authors' Addresses
Juergen Quittek
NEC Europe Ltd.
NEC Laboratories Europe
Network Research Division
Kurfuersten-Anlage 36
Heidelberg 69115
DE
Phone: +49 6221 4342-115
Email: quittek@neclab.eu
Rolf Winter
NEC Europe Ltd.
NEC Laboratories Europe
Network Research Division
Kurfuersten-Anlage 36
Heidelberg 69115
DE
Phone: +49 6221 4342-121
Email: Rolf.Winter@neclab.eu
Quittek, et al. Expires December 29, 2011 [Page 23]
Internet-Draft Battery MIB June 2011
Thomas Dietz
NEC Europe Ltd.
NEC Laboratories Europe
Network Research Division
Kurfuersten-Anlage 36
Heidelberg 69115
DE
Phone: +49 6221 4342-128
Email: Thomas.Dietz@neclab.eu
Quittek, et al. Expires December 29, 2011 [Page 24]
