One document matched: draft-ietf-eman-battery-mib-09.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">
<!ENTITY rfc2578 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2578.xml">
<!ENTITY rfc2579 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2579.xml">
<!ENTITY rfc2580 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2580.xml">
<!ENTITY rfc1628 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1628.xml">
<!ENTITY rfc3410 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3410.xml">
<!ENTITY rfc6933 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6933.xml">
<!ENTITY id.draft-ietf-eman-requirements SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-eman-requirements-14.xml">
<!ENTITY id.draft-ietf-eman-framework SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-eman-framework-07.xml">
<!ENTITY id.draft-ietf-eman-energy-monitoring-mib SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-eman-energy-monitoring-mib-05.xml">
]>
<!--<?rfc strict="yes"?>-->
<?rfc toc="yes"?>
<?rfc tocompact="no"?>
<!--<?rfc footer="+++DRAFT_TXT+++"?>-->
<?rfc compact="yes"?>
<!--<?rfc subcompact="compact"?>-->
<?rfc symrefs="yes"?>
<rfc category="std" docName="draft-ietf-eman-battery-mib-09" ipr="trust200902">
<front>
<title abbrev="Battery MIB">Definition of Managed Objects for Battery Monitoring</title>
<author fullname="Jürgen Quittek" initials="J."
surname="Quittek">
<organization>NEC Europe Ltd.</organization>
<address>
<postal>
<street>NEC Laboratories Europe</street>
<street>Network Research Division</street>
<street>Kurfuersten-Anlage 36</street>
<code>69115</code>
<city>Heidelberg</city>
<country>DE</country>
</postal>
<phone>+49 6221 4342-115</phone>
<email>quittek@neclab.eu</email>
</address>
</author>
<author fullname="Rolf Winter" initials="R." surname="Winter">
<organization>NEC Europe Ltd.</organization>
<address>
<postal>
<street>NEC Laboratories Europe</street>
<street>Network Research Division</street>
<street>Kurfuersten-Anlage 36</street>
<code>69115</code>
<city>Heidelberg</city>
<country>DE</country>
</postal>
<phone>+49 6221 4342-121</phone>
<email>Rolf.Winter@neclab.eu</email>
</address>
</author>
<author fullname="Thomas Dietz" initials="T." surname="Dietz">
<organization>NEC Europe Ltd.</organization>
<address>
<postal>
<street>NEC Laboratories Europe</street>
<street>Network Research Division</street>
<street>Kurfuersten-Anlage 36</street>
<code>69115</code>
<city>Heidelberg</city>
<country>DE</country>
</postal>
<phone>+49 6221 4342-128</phone>
<email>Thomas.Dietz@neclab.eu</email>
</address>
</author>
<date/>
<!-- <date month="June" year="2011" /> -->
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>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.</t>
<t>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 a means
for monitoring batteries in or attached to managed devices. The Battery
MIB module defined in <xref target="definitions"/> meets the
requirements for monitoring the status of batteries specified in
<xref target="I-D.ietf-eman-requirements"/>.</t>
<t>The Battery MIB module provides for monitoring the battery status.
According to the <xref target="I-D.ietf-eman-framework">framework for
energy management</xref> it is an Energy Managed Object, and thus, MIB modules such as
the <xref target="I-D.ietf-eman-energy-monitoring-mib">Power and Energy Monitoring MIB</xref>
could in principle be implemented for batteries.
The Battery MIB extends the more generic aspects of energy management by adding
battery-specific information. Amongst other things, the Battery MIB enables
the monitoring of:</t>
<t><list style="symbols">
<t>the current charge of a battery,</t>
<t>the age of a battery (charging cycles),</t>
<t>the state of a battery (e.g. being re-charged),</t>
<t>last usage of a battery,</t>
<t>maximum energy provided by a battery (remaining and total capacity).</t>
</list></t>
<t>Further, means are provided for battery-powered devices
to send notifications when the current battery charge has dropped below a
certain threshold to inform the management system of needed
replacement. The same applies to the age of a battery.</t>
<t>Many battery-driven devices have existing instrumentation for monitoring the battery
status, 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.</t>
<t>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
tracing a battery and allows continuous monitoring 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. </t>
<t>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
<xref target="mibStructure"/> can be used for this purpose.</t>
<t>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
<xref target="RFC1628">RFC 1628</xref>. The UPS MIB module includes
managed objects for monitoring the batteries contained in an UPS system.
However, the information provided by the UPS MIB objects is limited and
tailored the particular needs of UPS systems.</t>
<t>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 <xref target="RFC2119">
RFC 2119</xref>.</t>
</section>
<section title="The Internet-Standard Management Framework">
<t>For a detailed overview of the documents that describe the current
Internet-Standard Management Framework, please refer to section 7 of
<xref target="RFC3410">RFC 3410</xref>.</t>
<t>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, <xref
target="RFC2578">RFC 2578</xref>, STD 58, <xref target="RFC2579"> RFC
2579</xref> and STD 58,<xref target="RFC2580">RFC 2580</xref>.</t>
</section>
<section anchor="mibOverview" title="Design of the Battery MIB Module">
<section anchor="mibStructure" title="MIB Module Structure">
<t>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 row
per battery.</t>
<t>Batteries are indexed by the entPhysicalIndex of the
entPhysicalTable defined in the <xref target="RFC6933">ENTITY-MIB
module</xref>. An implementation of the ENTITY-MIB module complying
with the entity4CRCompliance MODULE-COMPLIANCE statement is required
for compliant implementations of the BATTERY-MIB module.</t>
<t>If batteries are replaced with the replacing battery using the same
physical connector as the replaced battery had used, then the replacing
battery SHOULD be indexed with the same value of object entPhysicalIndex
as the replaced battery.</t>
<t>The kind of entity in the entPhysicalTable of the Entity MIB
module is indicated by the value of enumeration object entPhysicalClass.
All batteries SHOULD have the value of object entPhysicalClass set to
battery(14) in their row of the entPhysicalTable.</t>
<t>The batteryTable contains three groups of objects. The first group
(OIDs ending with 1-10) provides information on static properties of the
battery. The second group of objects (OIDs ending with 11-18) 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.</t>
<figure>
<artwork><![CDATA[
batteryTable(1)
+--batteryEntry(1) [entPhysicalIndex]
+-- r-n SnmpAdminString batteryIdentifier(1)
+-- r-n SnmpAdminString batteryFirmwareVersion(2)
+-- r-n Enumeration batteryType(3)
+-- r-n Unsigned32 batteryTechnology(4)
+-- r-n Unsigned32 batteryDesignVoltage(5)
+-- r-n Unsigned32 batteryNumberOfCells(6)
+-- r-n Unsigned32 batteryDesignCapacity(7)
+-- r-n Unsigned32 batteryMaxChargingCurrent(8)
+-- r-n Unsigned32 batteryTrickleChargingCurrent(9)
+-- r-n Unsigned32 batteryActualCapacity(10)
+-- r-n Unsigned32 batteryChargingCycleCount(11)
+-- r-n DateAndTime batteryLastChargingCycleTime(12)
+-- r-n Enumeration batteryChargingOperState(13)
+-- rwn Enumeration batteryChargingAdminState(14)
+-- r-n Unsigned32 batteryActualCharge(15)
+-- r-n Unsigned32 batteryActualVoltage(16)
+-- r-n Integer32 batteryActualCurrent(17)
+-- r-n Integer32 batteryTemperature(18)
+-- r-n SnmpAdminString batteryCellIdentifier(19)
+-- rwn Unsigned32 batteryAlarmLowCharge(20)
+-- rwn Unsigned32 batteryAlarmLowVoltage(21)
+-- rwn Unsigned32 batteryAlarmLowCapacity(22)
+-- rwn Unsigned32 batteryAlarmHighCycleCount(23)
+-- rwn Integer32 batteryAlarmHighTemperature(24)
+-- rwn Integer32 batteryAlarmLowTemperature(25)
]]></artwork>
</figure>
<t>The third group of objects in this table (OIDs ending with 20-25)
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.</t>
<t>The Battery MIB defines seven notifications for indicating</t>
<t><list style="numbers">
<t>a battery charging state change that was not triggered by writing
to object batteryChargingAdminState,</t>
<t>a low battery charging state,</t>
<t>a critical battery that cannot be used anymore for power supply,</t>
<t>an aged battery that may need to be replaced,</t>
<t>a battery exceed a temperature threshold,</t>
<t>a battery that has been connected,</t>
<t>disconnection of one or more batteries.</t>
</list></t>
<t>Notifications 2.-5. can use object batteryCellIdentifier
to indicate a specific cell or a set of cells within the battery
that have triggered the notification.</t>
</section>
<section anchor="technologies" title="Battery Technologies">
<t>Static information in the batteryTable includes battery type and
technology. The battery type distinguishes primary (not rechargeable)
batteries from rechargeable (secondary) batteries and capacitors.
The battery technology describes the actual technology of a battery,
which typically is a chemical technology.</t>
<t>Since battery technologies are subject of intensive research and
widely 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).</t>
<t>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
are 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.</t>
<figure>
<artwork><![CDATA[
+----------------------------+----------+
| battery technology | assigned |
| | number |
+----------------------------+----------+
| Unknown | 1 |
| Other | 2 |
| Zinc-carbon | 3 |
| Zinc chloride | 4 |
| Nickel oxyhydroxide | 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 |
+----------------------------+----------+
]]></artwork>
</figure>
</section>
<section anchor="cycles" title="Charging Cycles">
<t>The lifetime of a battery can be approximated using the measure of
charging cycles. A commonly used definition of a charging cycle
is the amount of discharge equal to the design (or nominal) capacity of the battery
<xref target="SBS"/>. This means that a single charging cycle
may include several steps of partial charging and discharging
until the amount of discharging has reached the design capacity of the
battery. After that the next charging cycle immediately starts.</t>
</section>
</section>
<section title="Definitions" anchor="definitions">
<?rfc include='BATTERY-MIB-09.xml'?>
</section>
<section title="Security Considerations">
<t>There are a number of management objects defined in this MIB
module with a MAX-ACCESS clause of read-write. 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.
These are the tables and objects and their sensitivity/vulnerability:
</t>
<t><list style="symbols">
<t>batteryChargingAdminState<vspace/>
Setting the battery charging state can be beneficial for an operator
for various reasons such as charging batteries when the price of
electricity is low. However, setting the charging state can be used by
an attacker to discharge batteries of devices and thereby switching
these devices off if they are powered solely by batteries. In particular,
if the batteryAlarmLowCharge and batteryAlarmLowVoltage can also be
set, this attack will go unnoticed (i.e. no notifications
are sent).</t>
</list></t>
<t><list style="symbols">
<t>batteryAlarmLowCharge and batteryAlarmLowVoltage<vspace/>
These objects set the threshold for an alarm to be raised when
the battery charge or voltage falls below the corresponding one
of them. An attacker setting one of these alarm values can
switch off the alarm by setting it to the 'off' value 0 or modify
the alarm behavior by setting it to any other value. The result
may be loss of data if the battery runs empty without warning
to a recipient expecting such a notification.</t>
</list></t>
<t><list style="symbols">
<t>batteryAlarmLowCapacity and batteryAlarmHighCycleCount<vspace/>
These objects set the threshold for an alarm to be raised when
the battery becomes older and less performant than required for
stable operation. An attacker setting this alarm value can
switch off the alarm by setting it to the 'off' value 0 or
modify the alarm behavior by setting it to any other value.
This may either lead to a costly replacement of
a working battery or too old or too weak batteries being used.
The consequence of the latter could e.g. be that a battery
cannot provide power long enough between two scheduled charging
actions causing the powered device to shut down and potentially
lose data.</t>
</list></t>
<t><list style="symbols">
<t>batteryAlarmHighTemperature and batteryAlarmLowTemperature<vspace/>
These objects set thresholds for an alarm to be raised when
the battery rises above/falls below them. An attacker setting one of
these alarm values can switch off these alarms by setting them to the
'off' value '7fffffff'H or modify the alarm behavior by setting
them to any other value. The result may e.g. be an unnecessary
shutdown of a device if batteryAlarmHighTemperature is set to too low
or damage to the device by too high temperatures if switched off or set to
too high values or by damage to the battery when it e.g. is being
charged. Batteries can also be damaged e.g. in an attempt to charge them
at too low temperatures. </t>
</list></t>
<t>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:</t>
<t>All potentially sensible or vulnerable objects of this
MIB module are in the batteryTable. In general, there are
no serious operational vulnerabilities foreseen in case of an
unauthorized read access to this table. However, privacy issues
need to be considered. It may be a trade secret of the operator
<list style="symbols">
<t>how many batteries are installed in a managed node (batteryIndex)</t>
<t>how old these batteries are (batteryActualCapacity and
batteryChargingCycleCount)</t>
<t>when the next replacement cycle for batteries can be expected
(batteryAlarmLowCapacity and batteryAlarmHighCycleCount)</t>
<t>what battery type and make are used with which firmware version
(batteryIdentifier, batteryFirmwareVersion, batteryType, and
batteryTechnology)</t>
</list></t>
<t>SNMP versions prior to SNMPv3 did not include adequate security. Even
if the network itself is secure (for example by using IPsec),
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.</t>
<t>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).</t>
<t>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 GET or
SET (change/create/delete) them.</t>
</section>
<section title="IANA Considerations">
<section title="SMI Object Identifier Registration">
<t>The Battery MIB module defined in this document uses the
following IANA-assigned OBJECT IDENTIFIER value recorded in
the SMI Numbers registry:
<figure>
<artwork><![CDATA[
Descriptor OBJECT IDENTIFIER value
---------- -----------------------
batteryMIB { mib-2 xxx }
]]></artwork>
</figure>
</t>
<t>[NOTE for IANA: Please allocate an object identifier at
http://www.iana.org/assignments/smi-numbers for object
batteryMIB.]</t>
</section>
<section title="Battery Technology Registration">
<t>Object batteryTechnology defined in
<xref target="definitions"/> reports battery technologies.
Eighteen values for battery technologies have initially been
defined. They are listed in a table in
<xref target="technologies"/>.</t>
<t>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 <xref target="technologies"/>.</t>
<t>New assignments of numbers for battery technologies
will be administered by IANA through Expert Review
(<xref target="RFC5226"/>). Experts must check for
sufficient relevance of a battery technology to be added.</t>
<t>[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
<xref target="technologies"/>]</t>
</section>
</section>
<section title="Open Issues">
<section title="Battery replacement">
<t>How to deal with IDs in case of replacement of a battery?
If a battery is replaced, shall the UUID in the entPhysicalTable
be replaced by a new one?. Proposal: keep the UUID for the
entity and use the batteryIdentifier to identify moving batteries.</t>
</section>
<section title="Compliance statements for notifications">
<t>Compliance statements for Notifications need to be
revisited and if necessary elaborated.</t>
</section>
</section>
<section title="Acknowledgements">
<t>We would like to thank Steven Chew and Bill Mielke for their
valuable input.</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc5226;
&rfc2578;
&rfc2579;
&rfc2580;
&rfc6933;
</references>
<references title="Informative References">
&id.draft-ietf-eman-requirements;
&id.draft-ietf-eman-framework;
&id.draft-ietf-eman-energy-monitoring-mib;
&rfc1628;
&rfc3410;
<reference anchor='SBS'>
<front>
<title>Smart Battery Data Specification</title>
<author></author>
<date month='December' year='1998' />
</front>
<seriesInfo name='Revision' value='1.1' />
</reference>
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 06:32:48 |