Power Supply MIB - Early Warning

Bob Stewart <rlstewart@eng.xyplex.com> Wed, 26 August 1992 19:38 UTC

Return-Path: <owner-chassismib>
Received: by CS.UTK.EDU (5.61++/2.8s-UTK) id AA10769; Wed, 26 Aug 92 15:38:39 -0400
Received: from xap.xyplex.com by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA10765; Wed, 26 Aug 92 15:38:33 -0400
Received: by xap.xyplex.com id <AA27052@xap.xyplex.com>; Wed, 26 Aug 92 15:38:03 -0500
Date: Wed, 26 Aug 1992 15:38:03 -0500
Message-Id: <9208262038.AA27052@xap.xyplex.com>
From: Bob Stewart <rlstewart@eng.xyplex.com>
To: chassismib@cs.utk.edu
Subject: Power Supply MIB - Early Warning


It has come to pass in the fullness of time that I'm finally getting around to
working on the synthesis document for a Power Supply MIB, which I agreed to do
at our first meeting.  I looked over the contributions (thank you to the few
who contributed), considered some input from some of our semi-tame hardware
types around here, and decided to run some ideas past y'all before I bother to
cast them in ASN.1.

My major concern is that power supplies, and the ability to observe or control
them, are going to vary a lot among hardware implementations.  Although we can
presume some ability to drive software, we must have a softer touch with
hardware.  This boils down to a desire to standardize some software features
but not place heavy requirements on hardware.  With that in mind, and direct
input as stated above, I came up with the following model.

A table of power supplies, indexed by power supply index, a small integer
which may correspond to a physical location in a chassis, either a regular
slot or a power supply slot.  Each entry contains:

	description - a textual description including vendor's name and
	version.

	status - unknown, empty, bad, warning, standby, engaged, redundant.
	Standby means believed usable but not supplying power.  Engaged means
	supplying power.  Redundant means supplying power but believed
	unnecessary (that n+1 business...).  Status is bad or warning if
	one or more outputs or environmental sensors indicates bad or
	warning, although the low level could be bad but overall status
	just a warning.

	events - number of times status has gone to warning or bad.

A table of outputs, indexed by power supply index and an additional small
integer.  I'd rather use voltage as the second index, but it can be negative
and I don't believe that's allowed.  An implementation can omit entries of
status "unknown", and could thus always have an empty table.  Each entry
contains:

	voltage - in hundredths of volts, nominal (expected) output, such as
	-5, +5, +12, -15, etc.

	status - unknown, bad, warning, good.  If unknown, supplied voltage
	is meaningless.

	supplied voltage - in hundredths of volts, power currently provided by
	this output.  Status of good and value of 0 together indicate supplied
	voltage is not available.

	warnings - number of times status has gone to warning.

	failures - number of times status has gone to bad.

Now we get really fancy.  A table of environmental statuses, indexed by power
supply index and (shudder) an OID.  Standard OIDs provided for humidity,
temperature, and fan.  An implementation may omit entries with status
"unknown" and thus could have an empty table.  Each entry contains:

	status - unknown, bad, warning, good.

	warnings - number of times status has gone to warning.

	failures - number of times status has gone to bad.

I considered values for current and maximum wattage but those hadn't appeared
in the submissions and I couldn't slick them in like I did voltages.  I also
considered the idea of separate groups of power supplies with separate
redundancy dependencies, but that's a lot of additional complexity unless
somebody really, really, really wanted it.

I'll give this a few days to settle, and then write up the result.  If I don't
hear anything, I'll assume everybody likes it and is busy implementing it.

	Bob