Suggested power supply and environment M
{3COM/PDD/PeteW}@pdd.3mail.3com.com Thu, 03 June 1993 11:41 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02120; 3 Jun 93 7:41 EDT
Received: from CS.UTK.EDU by IETF.CNRI.Reston.VA.US id aa02115; 3 Jun 93 7:41 EDT
Received: from localhost by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA22508; Thu, 3 Jun 93 06:57:48 -0400
X-Resent-To: chassismib@CS.UTK.EDU ; Thu, 3 Jun 1993 06:57:48 EDT
Errors-To: owner-chassismib@CS.UTK.EDU
Received: from gatekeeper.3Com.COM by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA22500; Thu, 3 Jun 93 06:57:45 -0400
Received: from gw.3Com.COM by gatekeeper.3Com.COM with SMTP id AA24806 (5.65c/IDA-1.4.4-910725 for <chassismib@cs.utk.edu>); Thu, 3 Jun 1993 03:57:42 -0700
Received: by gw.3Com.COM id AA25242 (5.65c/IDA-1.4.4 for chassismib@cs.utk.edu); Thu, 3 Jun 1993 03:57:40 -0700
Date: Thu, 03 Jun 1993 11:55:00 -0700
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: {3COM/PDD/PeteW}@pdd.3mail.3com.com
Subject: Suggested power supply and environment M
To: chassismib@cs.utk.edu
Message-Id: <930603.040321@3Mail.3Com.COM>
Msg-Date: 1993-06-03
Msg-Time: 11:52
Microsoft Mail v3.0 IPM.Microsoft Mail.Note From: Wilson, Peter To: Chassis MIB Subject: Suggested power supply and environment MIB tables. Date: 1993-06-03 11:47 Priority: Message ID: 3A4E3E28 Conversation ID: 3A4E3E28 ------------------------------------------------------------------------------ As promised, heres some suggested definitions for the power supply objects. One thing that occurred to me while I was putting this together. Fans, sensors and PSUs are resources. In the tables below both power ouput and fans have an operational status. Is this something that may be generally useful for resources? Should the resource tables contain a chasPhyResOperStatus and chasLogResOperStatus? Note that both of these tables are optional. Without them PSU and sensors still appear in the chassis tables. I'm not convinced about the need for output warning and failures. We don't count these anywhere else (for example in the module table, transitions of oper status). Similarly for sensors. IF its not necessary to count sensor warnings and failures then adding resource operational status means the sensor table could go completely. Pete ======================================================== -- the Power Supply Output table. Note that this table contains -- additional information for resources that represent power -- supplies. As such this table has the same index as the resource -- table. When the MIB is represented in an SNMPv2 manner the -- index columns can be removed from this table and the INDEX -- clause can refer to the resource table. Alternatively since -- this table requires exactly the same indices as the resource -- table it is a good candidate for the AUGMENTS clause! -- chasPowerSupplyOutputTable OBJECT-TYPE SYNTAX SEQUENCE OF ChasPowerSupplyOutputEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Additional information for resource that represent source of power within the chassis." ::= { chasPowerSupply 2 } chasPowerSupplyOutputEntry OBJECT-TYPE SYNTAX ChasPowerSupplyEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Values for a power supply output." INDEX { chasPSLocationType, chasPSLocationIndex,chasPSResource} ::= { chasPowerSupplyOutputTable 1 } ChasPowerSupplyOutputEntry ::= SEQUENCE { chasPSLocationType INTEGER, chasPSLocationIndex INTEGER, chasPSResource INTEGER, chasPSOutputStatus INTEGER, chasPSOutputNominalVoltage Gauge, chasPSOutputOfferedVoltage Gauge, chasPSOutputOfferedWattage Gauge, chasPSOutputWarnings Counter, chasPSOutputFailures Counter } chasPSLocationType OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "A Power Supply resource exists on a particular module. This variable identifies the type part of the module on which this resource resides. It can be used with chasPSULocationIndex to index the module table for information about the module. The value of this object could be chasPowerSupplyBay, however some chassis implementations will not distinguish between slots that accept modular function card and those that accept power supplies. A slot can accept for example a power supply or a repeater line card." ::= { chasPowerSupplyOutputEntry 1 } chasPSLocationIndex OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "A power supply resource exists on a particular module. A module is identified by its location type and location instance. This variable identifies the instance part of the module identification on which this resource resides. It can be used with chasPSLocationType to index the module table for information about the module." ::= { chasPowerSupplyOutputEntry 2 } chasPSResource OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "A unique index for the power supply resource on this particular physical module." ::= { chasPowerSupplyOutputEntry 3 } chasPSOutputStatus OBJECT-TYPE SYNTAX INTEGER { unknown(1), bad(2), warning(3), good(4) } ACCESS read-only STATUS mandatory DESCRIPTION "Actual status of the power supply: - unknown(1) status not known - bad(2) unable to supply power due to failure - warning(3) supplying power but marginally - good(4) supplying power It is an implementation specific matter whether the agent keeps entries with status unknown(1) in the table. If unknown(1), offered values and counters are meaningless." ::= { chasPowerSupplyOutputEntry 4 } chasPSOutputNominalVoltage OBJECT-TYPE SYNTAX Gauge ACCESS read-only STATUS mandatory DESCRIPTION "In hundredths of a volt, the voltage the output is supposed to supply, such as -5, +5, +12, -15, etc." ::= { chasPowerSupplyOutputEntry 5 } chasPSOutputOfferedVoltage OBJECT-TYPE SYNTAX Gauge ACCESS read-only STATUS mandatory DESCRIPTION "In hundredths of a volt, the voltage actually offered by the output. If chasPowerSupplyOutputStatus is good(4), the value 0 means offered voltage is not available." ::= { chasPowerSupplyOutputEntry 6 } chasPSOutputOfferedWattage OBJECT-TYPE SYNTAX Gauge ACCESS read-only STATUS mandatory DESCRIPTION "In hundredths of a watt, the wattage actually offered by the output. If chasPowerSupplyOutputStatus is good(4), the value 0 means offered wattage is not available." ::= { chasPowerSupplyOutputEntry 7 } chasPSOutputWarnings OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of times chasPowerSupplyOutputStatus has gone to warning(3)." ::= { chasPowerSupplyOutputEntry 8 } chasPSOutputFailures OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of times chasPowerSupplyOutputStatus has gone to bad(2)." ::= { chasPowerSupplyOutputEntry 9 } -- -- the chasEnviron (Environment) group -- Implementation of this group is optional. -- && Because a sensor is a resource, its can be identified -- && by the OID in the resource table so chasEnvironSensor -- && is no longer required. chasEnvironTable OBJECT-TYPE SYNTAX SEQUENCE OF ChasEnvironEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A list of environmental entries, one for each environmental sensor in the chassis. This table augments the resources in the resource table for those entries which represent sensors." ::= { chasEnviron 1 } chasEnvironEntry OBJECT-TYPE SYNTAX ChasEnvironEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Values for a environmental sensor." INDEX { chasEnvironLocationType, chasEnvironLocationIndex, chasEnvironResource } ::= { chasEnvironTable 1 } ChasEnvironEntry ::= SEQUENCE { chasEnvironLocationType INTEGER, chasEnvironLocationIndex INTEGER, chasEnvironResource INTEGER, chasEnvironStatus INTEGER, chasEnvironWarnings Counter, chasEnvironFailures Counter, } chasEnvironLocationType OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory
- Suggested power supply and environment M {3COM/PDD/PeteW}
- Suggested power supply and environment M {3COM/PDD/PeteW}
- Suggested power supply and environment M {3COM/PDD/PeteW}