Pete's Chassis MIB - Assembled
musher@ccrelay.fibermux.com Fri, 07 January 1994 23:30 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16153; 7 Jan 94 18:30 EST
Received: from CS.UTK.EDU by IETF.CNRI.Reston.VA.US id aa16149; 7 Jan 94 18:30 EST
Received: from localhost by CS.UTK.EDU with SMTP (8.6.4/2.8s-UTK) id RAA24232; Fri, 7 Jan 1994 17:58:25 -0500
X-Resent-To: chassismib@CS.UTK.EDU ; Fri, 7 Jan 1994 17:58:23 EST
Errors-to: owner-chassismib@CS.UTK.EDU
Received: from uu.psi.com by CS.UTK.EDU with SMTP (8.6.4/2.8s-UTK) id RAA24212; Fri, 7 Jan 1994 17:57:39 -0500
Received: from fibermux.UUCP by uu.psi.com (5.65b/4.1.031792-PSI/PSINet) via UUCP; id AA06783 for ; Fri, 7 Jan 94 17:35:19 -0500
Received: from ccrelay.fibermux.com by fibermux.com (4.1/SMI-4.1) id AA06099; Fri, 7 Jan 94 13:08:43 PST
Received: from ccMail by ccrelay.fibermux.com id AA757976888 Fri, 07 Jan 94 13:08:08 PST
Date: Fri, 07 Jan 1994 13:08:08 -0800
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: musher@ccrelay.fibermux.com
Encoding: 68654 HEX
Message-Id: <9400077579.AA757976888@ccrelay.fibermux.com>
To: chassismib@cs.utk.edu
Subject: Pete's Chassis MIB - Assembled
From: <{3COM/PDD/PeteW}@PDD.3Mail.3Com.COM> at ccrelayout 1/4/94 9:39AM Subject: Chassis MIB proposal ------------------------------------------------------------------------------ Dan, I already updated my chassis MIB proposal last October and sent it to the chassis MIB mailing list. There was very little (no) interest at that point although activity in most other management related working groups had died down. There is a real need for a chassis MIB, but the problem is complex and I'm not convinced there is a will to find a solution at this stage. I'll resend my complete proposal to the chassis MIB mailing list (it might end up UUENCODED due to our Microsoft Mail gateway!) Pete Below is my proposal, resent from last October, for a complete chassis MIB proposal. ============================== I've spent some time going over the chassis MIB drafts trying to pull together all the strands into a single MIB and to provide some descriptive text. This is the result. What I've done: - Taken the most stable and discussed chassis MIB draft. - Modified the power supply and sensor groups to be consistent with the modified model. - Added an optional link table that can be used to describe the physical interconnection of elements in the chassis (without overloading the inventory tables). There seemed to be quite a lot of interest in this MIB when the WG was being disbanded, but very little since. I'd appreciate those of you interested in the MIB at that time reading this proposal and returning comments to myself. I will be at the November IETF meeting if you would like to discuss any of this in person. thanks Pete ---------------------------------------------------------------------------- Definitions/Glossary ==================== Chassis: A generic 'container'. Specifically for the purpose of this MIB implement network devices. A chassis can be viewed either from physical or logical perspective. Physically a chassis contains a number of modules. Logically a chassis contains a collection of functional 'entities'. Module: A module is a physical thing contained within a chassis. A particular chassis can contain any number of different types of module and any number of distinct instances of the same type of module. A module is distinguished from other modules in a chassis by its type and its position within the chassis. A module is itself a container of 'resources'. Resource: Each physical module comprises a number of resources. The resources can be of any kind, for example a repeater port, bridge relay etc. Entity: An entity is a functional unit within the chassis. An 'entity' is analogous to a seperate, standalone device. Examples of chassis entities are: Ethernet repeaters, bridges, routers, token ring concentrators. Link: A Link is a description of a known connection between two resources in the chassis. A particular chassis can describe its internal topological configuration by entries in a table of links in the MIB. Note that it is not necessary to describe all links in the chassis, only those that are useful. Refer to the MIB group descriptions for an example of how links can be used to describe mappings of multiple bridges and routers to the same physical network connections (the 'brouter' scenario). The Model ========= For the purposes of this MIB a chassis is any device, or collection of devices that together can be considered a single entity. For example, traditional multi-slot 19" rack mounting chassis are included, as are the newer stackable type devices. The MIB is not limited to such devices and so could be used to describe any containment type of relationship. Note that if necessary an instance of the 'chassis' could logically contain a sub chassis to allow an arbitrarily deep containment hierarchy. There are two views of a chassis. Firstly the physical view. The physical view considers the chassis to comprise a number of different types of compartment, or location. Each type of location is specialised to hold a particular type of item or module. Examples of compartment types would be network card slots, power supply bays and fan trays. At any instant in time each location in a chassis may be occupied or empty. Secondly there is the logical or functional view. In this view the chassis is considered to contain a number of 'entities'. Each entity provides some function. Examples of entities would be Ethernet repeaters, bridges, routers and terminal servers. An entity is implemented using parts from one or more of the physical modules in the chassis. It is necessary to describe the relationship between physical module and logical entity. For the purposes of this relationship a physical module is considered to comprise a number of logical components, or resources. A number of these resources are joined together to construct an entity. To illustrate these concepts consider a company to be the chassis. In this example the physical modules are floors of a building and the logical entities projects. Each floor comprises a number of people which are the resource from which project teams are constructed. Each person is specialised for a particular role within a project. Floor Function:Person Project Implemented By (module) (resource) (entity) (relationship) --------------------------------------------------------------------------- 1 - Marketing:Pete xyz-thing Marketing:Pete Marketing:Jeff Development:Mike Development:Mike Manufacturing:Dave Manufacturing:Alan abc-thing Marketing:Jeff 2 - Marketing:Jane Development:Sharon Development:Sharon Development:Michele Manufacturing:Dave Manufacturing:Alan 3- Development:Michele Marketing:Paul Development:James Analysis of this example provide some interesting relationships that apply equally to a network type device: 1) Each physical entity comprises a number of resources that can be used in the construction of an entity. 2) A logical component of one type may be substituted for a different component of the same type in a logical entity. eg James may be substituted for Mike but not for Jeff. 3) It is possible that at some time not all components are part of entities. It is however necessary to know all components that exist and the current use or otherwise of those components. Having looked at a generic example consider a practical example of a chassis that contains modules for token ring and Ethernet. In this example assume that each Ethernet and each Token Ring card contain 4 ports. There currently exist 4 entities in the chassis, two Ethernet repeaters and 2 Token Rings. The chassis contains 4 locations that can contain modules and the configuration is as follows: Slot Number Contains 1 Ethernet Repeater Card 2 802.5 Port Card 3 Ethernet Repeater Card 4 802.5 Port Card The logical configuration of the chassis at a particular time is as follows: Entity Implemented By ------ -------------- Repeater 1 Module 1, Port 1, 2, 3 Module 3, Port 2 Repeater 2 Module 1, Port 4 Module 3, Port 1, 3 Token Ring 1 Module 2, Port 1, 2 Token Ring 2 Module 2, Port 3 Module 4, Port 3 ---------------------------------------- Module 2, Port 4 - Not currently used Module 3, Port 4 - " " " Module 4, Port 1, 2, 4 - " " " Note that a MIB to represent and configure devices such as this must make all resource of all cards visible and allow the configuration of those resources into entities. Now suppose that an operator needs an additional Ethernet repeater. In order to do this a new Repeater entity is created and some of the repeater ports are assigned to that entity. eg: create Repeater 3 assign Module 3, Port 4 to Repeater 3 -- Currently unassigned assign Module 3, Port 1 to Repeater 3 -- Moved from Repeater 2 Combining Resources into Entities (Network Chassis) ================================== 1. Implicit Assignment ---------------------- This strategy requires the most effort from the chassis agent but provides the best and easiest model for both the application writer and the best abstraction for the user. It is applicable to both chassis that use a hardwired backplane and those that use central or distributed switching services to implement functions. The chassis is required to implement a number of entities. The number and type of entity implemented by a particular chassis depends on the physical capabilities and design of that chassis. For example one chassis may be designed with 3 Ethernet busses on a backplane. In this chassis it is possible to create 3 repeaters that use components from more than one physical module. The chassis may also be capable of implementing a number of additional repeaters provided only components on the same card are used. Implicit assignment says that the chassis is required to marshal its inherent resources to best meet the requested configuration of the manager. The managers requests are communicated by the creation and destruction of entities and by the assignment of components to entities. In the example of a chassis with 2 Ethernet backplanes the agtegy of the agent could be as follows: manager agent ----------------------------------------------------------------- create Repeater record repeaters existence assign Mod 1, Port 1 add component to repeater, don't need a to repeater backplane yet! assign Mod 1, Port 2 add component to repeater, don't need a to repeater backplane yet! assign Mod 2, Port 1 Repeater crosses card boundaries so find a spare backplane and assign that to this repeater. Note that if there are no spare backplanes then the assignment is rejected. Note that this approach makes repeater implementation transparent to a user. The model is identical regardless of whether the chassis uses backplanes, has central/distributed switching or any other implementation strategy. 2. Explicit Assignment ---------------------- This is a more manual approach. The effort required in the agent is potentially somewhat less but the savings are really nominal. In this model the manager is responsible for assigning backplanes. A backplane is simply a physical module in the same way that a repeater card is a module. Because it is a module it also has resources that can be assigned to entities. Now consider the same example of a repeater chassis with 2 backplanes. The example is the same as above: Create a repeater and assign a number of repeater ports to that repeater: manager agent ----------------------------------------------------------------- create Repeater record repeaters existence assign Mod 1, Port 1 add component to repeater, don't need a to repeater backplane yet! assign Mod 1, Port 2 add component to repeater, don't need a to repeater backplane yet! assign Mod 2, Port 1 Request rejected. There is no assigned connection path to allow ports on different cards to be assigned to the same repeater. assign Ether B'plane Repeater can now span cards. 1 to repeater assign Mod 2, Port 1 Request successful. NOTE: Variations on this theme are possible but the idea remains the same. For example one could statically create 2 repeaters that always exist to represent the two backplanes. Ports could be assigned to those repeaters. Additional repeaters could be created but would not be allowed to span cards. In a particular chassis there will also be a number of fixed entities that always exist, although the resources assigned to that entity may differ. ---------------------------------------------------------------------------- CHASSIS-MIB DEFINITIONS ::= BEGIN IMPORTS OBJECT-TYPE FROM RFC-1212 experimental, TimeTicks, IpAddress, Counter FROM RFC1155-SMI -- Textual Conventions DisplayString ::= OCTET STRING -- This data type is used to model textual information taken -- from the NVT ASCII character set. By convention, objects -- with this syntax are declared as having -- -- SIZE (0..255) Context ::= OBJECT IDENTIFIER -- This is a definition used to identify SNMPv2 'Contexts' used to -- represent views of different entities. TAddress ::= OCTET STRING -- Used to represent generic 'transport' addressing mechanisms. The -- protocol type determines how this address is interpreted. This is -- an SNMPv2 textual convention. chassis OBJECT IDENTIFIER ::= { experimental 38 } -- Groups within the chassis MIB chasInfo OBJECT IDENTIFIER ::= { chassis 1 } chasPhysical OBJECT IDENTIFIER ::= { chassis 2 } chasEntity OBJECT IDENTIFIER ::= { chassis 3 } chasResource OBJECT IDENTIFIER ::= { chassis 4 } chasPowerSupply OBJECT IDENTIFIER ::= { chassis 5 } chasEnviron OBJECT IDENTIFIER ::= { chassis 6 } -- Chassis MIB Known Types chasKnownTypes OBJECT IDENTIFIER ::= { chassis 7 } -- Values for known chasPhyLocationType. The types of -- location in the chassis. chasLocationTypes OBJECT IDENTIFIER ::= { chasKnownTypes 1 } chasModularSlot OBJECT IDENTIFIER ::= { chasLocationTypes 1 } chasPowerSupplyBay OBJECT IDENTIFIER ::= { chasLocationTypes 2 } chasFanTray OBJECT IDENTIFIER ::= { chasLocationTypes 3 } chasBackplane OBJECT IDENTIFIER ::= { chasLocationTypes 4 } chasFrontSlot OBJECT IDENTIFIER ::= { chasLocationTypes 5 } chasBackSlot OBJECT IDENTIFIER ::= { chasLocationTypes 6 } -- Values for chasModuleType. chasModuleTypes OBJECT IDENTIFIER ::= { chasKnownTypes 2 } chasLocationEmpty OBJECT IDENTIFIER ::= { chasModuleTypes 1 } chasModuleUnknown OBJECT IDENTIFIER ::= { chasModuleTypes 2 } -- Values for chasEntityObjectId. chasEntityTypes OBJECT IDENTIFIER ::= { chasKnownTypes 3 } -- Chassis components non-networking chasChassisEntities OBJECT IDENTIFIER ::= { chasEntityTypes 1 } chasPowerSupplyModule OBJECT IDENTIFIER ::= { chasChassisEntities 1 } chasChassis OBJECT IDENTIFIER ::= { chasChassisEntities 2 } chasMonitors OBJECT IDENTIFIER ::= { chasChassisEntities 3 } -- Basic Network Entities chasNetEntities OBJECT IDENTIFIER ::= { chasEntityTypes 2 } chas8023Repeater OBJECT IDENTIFIER ::= { chasNetEntities 1 } chas8025Ring OBJECT IDENTIFIER ::= { chasNetEntities 2 } chasFddiRing OBJECT IDENTIFIER ::= { chasNetEntities 3 } chasAtmSwitch OBJECT IDENTIFIER ::= { chasNetEntities 4 } chasFrameRelay OBJECT IDENTIFIER ::= { chasNetEntities 5 } -- Internetworking/Bridging chasConnectEntities OBJECT IDENTIFIER ::= { chasEntityTypes 3 } chasBridge OBJECT IDENTIFIER ::= { chasConnectEntities 1 } chasRouter OBJECT IDENTIFIER ::= { chasConnectEntities 2 } chasBrouter OBJECT IDENTIFIER ::= { chasConnectEntities 3 } chasGateway OBJECT IDENTIFIER ::= { chasConnectEntities 4 } chasSwitch OBJECT IDENTIFIER ::= { chasConnectEntities 5 } -- Values for chasPhyResType. chasResTypes OBJECT IDENTIFIER ::= { chasKnownTypes 4 } -- Chassis type resources. chasChassisRes OBJECT IDENTIFIER ::= { chasResTypes 1 } -- Basic Network Resource chasNetworkRes OBJECT IDENTIFIER ::= { chasResTypes 2 } chas8023RptrPort OBJECT IDENTIFIER ::= { chasNetworkRes 1 } chas8025MauPort OBJECT IDENTIFIER ::= { chasNetworkRes 2 } chasFddiPort OBJECT IDENTIFIER ::= { chasNetworkRes 3 } chasAtmPort OBJECT IDENTIFIER ::= { chasNetworkRes 4 } chas8023PortGroup OBJECT IDENTIFIER ::= { chasNetworkRes 5 } chas8025PortGroup OBJECT IDENTIFIER ::= { chasNetworkRes 6 } chasFddiPortGroup OBJECT IDENTIFIER ::= { chasNetworkRes 7 } chasAtmPortGroup OBJECT IDENTIFIER ::= { chasNetworkRes 8 } -- Backplane Network Resources (if required) chasBplaneRes OBJECT IDENTIFIER ::= { chasResTypes 3 } chas8023Bplane OBJECT IDENTIFIER ::= { chasBplaneRes 1 } chas8025Bplane OBJECT IDENTIFIER ::= { chasBplaneRes 2 } chasFddiBplane OBJECT IDENTIFIER ::= { chasBplaneRes 3 } chasMgmtBplane OBJECT IDENTIFIER ::= { chasBplaneRes 4 } chasAtmBplane OBJECT IDENTIFIER ::= { chasBplaneRes 5 } -- Internetworking/bridging resources (if required) chasConnectRes OBJECT IDENTIFIER ::= { chasResTypes 4 } chasBridgeRelay OBJECT IDENTIFIER ::= { chasConnectRes 1 } chasRouterRelay OBJECT IDENTIFIER ::= { chasConnectRes 2 } chasBrouterRelay OBJECT IDENTIFIER ::= { chasConnectRes 3 } chasSwitchMatrix OBJECT IDENTIFIER ::= { chasConnectRes 4 } -- Finally a value that can be used anywhere that an OID type identifier -- is required, but the definitive value is unknown. chasTypeUnknown OBJECT IDENTIFIER ::= { chassis 8 } -- chasInfo group (chassis information group). -- Implementation of this group is mandatory. chasType OBJECT-TYPE SYNTAX OBJECT IDENTIFIER ACCESS read-only STATUS mandatory DESCRIPTION "An authoritative identification of the type of hub-based or standalone chassis. By convention this value is allocated within the SMI enterprises subtree(1.3.6.1.4.1), and provides an easy and unambiguous means for determining `what kind of box' is being managed. If this information is not present or unknown, its value should be set to the value: chasTypeUnknown. Note that the value of this object is not the same as the value of sysObjId. sysObjId refers to the product running the agent and NOT the chassis itself. Eg there could be several variants of a management card for a single chassis." ::= { chasInfo 1 } -- && chasPhysicalChanges: Removed. Definition is too vague and the use -- && is unclear. Does it include moving a resource from one entity to -- && another? chasChassisSerialNumber OBJECT-TYPE SYNTAX DisplayString (SIZE (0..32)) ACCESS read-only STATUS mandatory DESCRIPTION "The serial number of the chassis. If no serial number is available then this object should be the zero length string." ::= { chasInfo 2 } -- chasPhysical group (physical configuration group). -- Implementation of this group is mandatory. chasPhyLocationTable OBJECT-TYPE SYNTAX SEQUENCE OF ChasPhyLocationEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "This table summarises the different classes of and types of modular physical locations in the chassis. This includes but is not limited to slots within a chassis, power supply bays and fan tray slots. Note that entries in this table cannot be created or deleted through external management." ::= { chasPhysical 1 } chasPhyLocationEntry OBJECT-TYPE SYNTAX ChasPhyLocationEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "An entry in the phyLocationTable" INDEX { chasPhyLocationTypeIndex } ::= { chasPhyLocationTable 1 } ChasPhyLocationEntry ::= SEQUENCE { chasPhyLocationTypeIndex INTEGER, chasPhyLocationCount INTEGER, chasPhyLocationType OBJECT IDENTIFIER, chasPhyLocationName DisplayString } chasPhyLocationTypeIndex OBJECT-TYPE SYNTAX INTEGER (1..65535) ACCESS read-only STATUS mandatory DESCRIPTION "This uniquely identifies the physical location type within the chassis." ::= { chasPhyLocationEntry 1 } chasPhyLocationCount OBJECT-TYPE SYNTAX INTEGER (1..65535) ACCESS read-only STATUS mandatory DESCRIPTION "Each physical location exists one or more times. This object defines the number of instances that exist for the specified location type." ::= { chasPhyLocationEntry 2 } chasPhyLocationType OBJECT-TYPE SYNTAX OBJECT IDENTIFIER ACCESS read-only STATUS mandatory DESCRIPTION "Uniquely identifies the 'type' of the physical location within the chassis." ::= { chasPhyLocationEntry 3 } chasPhyLocationDescr OBJECT-TYPE SYNTAX DisplayString ACCESS read-only STATUS mandatory DESCRIPTION "Each type of physical location within the chassis is given a textual name." ::= { phyLocationEntry 4 } chasModuleTable OBJECT-TYPE SYNTAX SEQUENCE OF ChasModuleEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "This table identifies the physical modules within the chassis. Each module is identified by means of its location within the chassis, as specified by reference to chasPhyLocationTable. If a location is empty then a particular implementation of this MIB may choose to include or exclude a row representing that location. If an implementation chooses to include a row for every location, then those rows representing empty slots will be identified by a value for chasModuleType of chasLocationEmpty." :: { chasPhysical 2 } chasModuleEntry OBJECT-TYPE SYNTAX ChasPhyModuleEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "An entry in this table that describes a physical module that is currently present at a given physcial location within the chassis." INDEX { chasModuleLocationType, chasModuleLocation } ::= { chasModuleTable 1 } ChasPhyModuleEntry ::= SEQUENCE chasModuleLocationType INTEGER, chasModuleLocation INTEGER, chasModuleType OBJECT IDENTIFIER, chasModuleSwVersion DisplayString, chasModuleHwVersion DisplayString, chasModuleSerialNumber DisplayString, chasModuleDescription DisplayString, chasModuleLastChange TimeTicks, chasModuleState INTEGER } chasModuleLocationType OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "An instance of a module is identified by the physical location in which it resides. The physical location is identified by location type and location index (instance of that location type). This value of this object identifies a row in the the chasPhyLocationTable, ie a value of chasPhyLocationTypeIndex." ::= { chasModuleEntry 1 } chasModuleLocation OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "An instance of a module is identified by the physical location in which it resides. The physical location is identified by location type and location index (instance of that location type). This object defines the instance of a particular location type. It must be within the bounds defined by chasPhyLocationCount for the conceptual row in the chasPhyLocationTable identified by chasModuleLocationType." ::= { chasModuleEntry 2 } chasModuleType OBJECT-TYPE SYNTAX OBJECT IDENTIFIER ACCESS read-only STATUS mandatory DESCRIPTION "An authoritative identification of the type of physcial module in this physical location. A value of chasModuleUnknown indicates that the type of physical module is unknown. A particular implementation of this MIB may be such that it contains an entry for every location in the chassis, including those that are empty. In such cases the value of this object for locations that are empty should be chasLocationEmpty." :== { chasModuleEntry 3 } chasModuleSwVersion OBJECT-TYPE SYNTAX DisplayString (SIZE (0..32)) ACCESS read-only STATUS mandatory DESCRIPTION "A textual description of the version/revision level for this module's software. If not applicable or the location represented by this row is empty then the value of this object should be a zero-length string." :== { chasModuleEntry 4 } chasModuleHwVersion OBJECT-TYPE SYNTAX DisplayString (SIZE (0..32)) ACCESS read-only STATUS mandatory DESCRIPTION "A textual description of the version/revision level for this module's firmware. If not available or the location represented by this row is empty then the value of this object should be a zero-length string." ::= { chasModuleEntry 5 } chasModuleSerialNumber OBJECT-TYPE SYNTAX DisplayString (SIZE (0..32)) ACCESS read-only STATUS mandatory DESCRIPTION "The serial number of the physical module present in this physical location. If no serial number is available for a particular row, or that row represents an empty location then the value of this object should be a zero length string." ::= { chasModuleEntry 6 } chasModuleDescription OBJECT-TYPE SYNTAX DisplayString (SIZE (0..32)) ACCESS read-only STATUS mandatory DESCRIPTION "A textual description of the physical module plugged that resides in this physical location. If not available for a particular row, or that row represents an empty location then the value of this object should be a zero length string." ::= { chasModuleEntry 7 } chasModuleLastChange OBJECT-TYPE Syntax TimeTicks ACCESS read-only STATUS mandatory DESCRIPTION "The value of MIB-II's sysUpTime (in the agent supporting this chassis MIB) at which a module was last inserted or initialized. If the module has not changed since the last network managment system reinitialized, or a particular row represents an empty slot then the value of this object will be zero." ::= { chasModuleEntry 8 } -- && Replaced chasModuleAdminStatus and chasModuleOperStatus with -- && chasModuleState. It was unclear what value should be returned when -- && reading the value of the Admin state and write-only parameters are -- && no longer in vogue. -- && -- && A state table for this object will be included in the text to this MIB chasModuleState OBJECT-TYPE Syntax INTEGER { other (1), enable (2), disable (3), reset (4), test (5), testInProgress (6), resetInProgress (7), operational (8), diabled (9), warning (10), nonFatalError (11), fatalError (12) } ACCESS read-write STATUS mandatory DESCRIPTION "This object may be read or written. Reading the value of this object returns the current state of the module, writing to this object requests a change in state of this module. The values enable(2), disable (3), reset (4) and test (5) are writable values. All other values are readable states. An SNMP error will occur on an attempt to write a any value other than one of the four above. It is not a requirement that all chassis support all read or write values, or that a single chassis support the same set of writable values for all modules. It may be inappropriate to support 'reset' for a power supply module! Writing an unsupported value to a particular instance of this object will return an SNMP error. The writable values for this object are: enable(2). An enabled module contains resources that are, or may be, part of entities within the chassis. If a disabled module is successfully enabled its state will change to operational(8). disable(3). If a module is disabled then it acts as though it were unpowered. A disabled module has no resources in the resource table. Disabling a module has the side-effect that all resources on that module are removed from the resource tables. Writing a value of reset(3) simulates a power-on reset sequence. It is not necessary to change the contents of the resource tables for the duration of the reset. Note: the module being reset could be that module on which this instance of the chassis MIB is running; reset is a transitory state. For the duration of the reset the module will enter a resetInProgrss(7) state. It is not a requirement that after a module is reset that it should enter the same state in which it existed before the reset. Writing a value of test(4) will start a self test sequence on the module. While the card is being tested the value of this object will be testInProgress(6). The readable values are: testInProgress (6). This is a transitory state that the card in which the module will exist during tests. resetInProgress (7). The chassis is currently being reset. operational (8). The module is fully operational. The resources on this module are represented in the resource table and may be participating in the implementation of entities in the chassis. diabled (9). The module has been disabled. warning (10). The module is operational but a minor error has been detected by the card. nonFatalError (11). The module is operational but a non-fatal error has been detected. The card is still participating in the inplementation of entities within the chassis, but it may not be functioning completely. fatalError (12). The card has detected a fatal error and is no longer active." ::= { chasModuleEntry 9 } -- The chasEntity group. Implementation of the chasEntity group -- is mandatory. -- Entity Table chasEntityTable OBJECT-TYPE SYNTAX SEQUENCE OF ChasEntityEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A table that contains information about the 'logical' networking devices (entities) in this chassis." ::= { chasEntity 1 } chasEntityEntry OBJECT-TYPE SYNTAX ChasEntityEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Information concerning an entity in the chassis. Rows may be created and deleted from this table as different chassis configurations are required. The table uses the SNMPv2 RowStatus type semantics for row control. The RowStatus type is NOT used in order to maintain compatibility with SNMPv1. To create a new entity in this chassis, first create a row in this table to represent that entity, then 'assign' resources to this entity to build the required configuration. If an entity is deleted from this table the resources that were part of that entity become 'floating' until they once again are assigned to an entity." INDEX { chasEntityIndex } ::= { chasEntityTable 1 } -- && Note that the chasEntityAdminStatus and chasEntityOperStatus objects -- && have been removed. Control of an entity as a whole is in the domain -- && of the management view of that entity and is outside of the scope of the -- && chassis MIB. -- && -- && This is NOT the case with the module state because that deals with -- && the physical modules of the chassis, which are hidden from the -- && specific management view of the entity. ChasEntityEntry ::= SEQUENCE { chasEntityIndex INTEGER, chasEntityObjectID OBJECT IDENTIFIER, chasEntityDescr DisplayString, chasEntityTimeStamp TimeTicks, chasEntityRowStatus INTEGER } chasEntityIndex OBJECT-TYPE SYNTAX INTEGER (1..65535) ACCESS read-only STATUS mandatory DESCRIPTION "A unique index for the entity for which this entry contains information." ::= { chasEntityEntry 1 } chasEntityObjectID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER ACCESS read-write STATUS mandatory DESCRIPTION "The specific type of entity. A value for this column MUST be specified when creating a row." ::= { chasEntityEntry 2 } chasEntityDescr OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) ACCESS read-only STATUS mandatory DESCRIPTION "A textual description of the entity. This string will be generated by the agent." ::= { chasEntityEntry 3 } chasEntityTimeStamp OBJECT-TYPE SYNTAX TimeTicks ACCESS read-only STATUS mandatory DESCRIPTION "The value of MIB-II's sysUpTime (in the agent supporting this MIB) at which this entity was last (re-)initialized. If the entity has not been initialized then this object has a zero value." ::= { chasEntityEntry 4 } chasEntityRowStatus OBJECT-TYPE SYNTAX INTEGER { -- The following two values are states: -- these values may be read or written. active (1), notInService (2), -- the following value is a state: -- this value may be read but not written. notReady (3), -- the following three values are actions: -- these values may be written, but not read. createAndGo (4), createAndWait (5), destroy (6) } ACCESS read-only STATUS mandatory DESCRIPTION "To create a row in this table the following procedure should be applies: 1. Find an unused index in the table. 2. In one packet write a value for chasEntityObjectID and chasEntityRowStatus to createAndGo OR 1. Find an unused index in the table. 2. Set chasEntityRowStatus to createAndWait, this will result in the value of chasEntityRowStatus becoming notReady. After this step the value of chasEntityObjectID will be {0.0}. 3. Set the value of chasEntityObjectID to identify the required entity type. An attempt to write an illegal, unsupported or inappropriate value to this object will result in an SNMP error and the value remaining unchanged. 4. Set the chasEntityRowStatus to 'active'. Note that there are a number of reasons why the may refuse to create an entity: a) The particular chassis does NOT permit the creation and deletion of entities through management operation. An attempt to create a row in this table with such an agent will result in an SNMP error. b) The chassis does not permit the creation of the specified type of entity. For example an attempt to create a fan! If method 1) is used to create the row the state of the row will remain notReady. c) The chassis insufficient resource to create any additional entities. The attempt to create a row under these conditions wil l return an SNMP error." ::= { chasEntityEntry 5 } -- The chasEntityViewTable is used to provide access to the various MIB -- views of the different entities in the chassis. Note that this table -- must allow an SNMPv1 implementation of the chassis agent to point to an -- entity accessed via a different SNMPv2 agent. This is particularly true -- while SNMPv2 is yet to become an established protocol. -- -- && Another constraint on this table is that it must allow the SNMP protocol -- && to be carried over various transport domains. For this reason the intern et -- && draft version of this table was inadequate. -- -- && I don't really like this table at all for the following reasons: -- && a) It is adequate to identify different views for SNMPv1 but does -- && not adequately identify SNMPv2 access. -- && b) Even for SNMPv1 there is no indication of the access privileges of -- && of the various views (which is read-only, which is read-write), -- && although this isn't really a problem with SNMPv1! -- && In some ways for SNMPv1 the table need more information, for SNMPv2 -- && that information is held in the SNMPv2 MIB party and context tables. chasEntityViewTable OBJECT-TYPE SYNTAX SEQUENCE OF ChasEntityViewEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A table of all MIB views orgainized by entity. Each entity may have a number of MIB views associated with it." ::= { chasEntity 2 } chasEntityViewEntry OBJECT-TYPE SYNTAX ChasEntityViewEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Defines a specific MIB view." INDEX { chasEntityViewEntityId, chasEntityViewIndex } ChasEntityViewEntry ::= SEQUENCE { chasEntityViewEntityId INTEGER, chasEntityViewIndex INTEGER, chasEntityTDomain OBJECT IDENTIFIER, chasEntityTAddress OCTET STRING, chasEntityCommunity DisplayString, chasEntityContext Context } chasEntityViewEntityId OBJECT-TYPE SYNTAX INTEGER (1..65535) ACCESS read-only STATUS mandatory DESCRIPTION "The unique entity for which this MIB view is defined. This is an instance of chasEntityIndex within the chasEntityTable." ::= { chasEntityViewEntry 1 } chasEntityViewIndex OBJECT-TYPE SYNTAX INTEGER (1..127) ACCESS read-only STATUS mandatory DESCRIPTION "Distinguishes this view of the entity from other possible views." ::= { chasEntityViewEntry 2 } chasEntityTDomain OBJECT-TYPE SYNTAX OBJECT-IDENTIFIER ACCESS read-only STATUS mandatory DESCRIPTION "This object identifies the protocol by which the view of the entity identified by this row in the table may be accessed. Note that different views of the same entity may be visible via different transport protocols. That is some bilingual stacks could include views visible via SNMPv1 over IP and also by SNMPv1 over IPX." ::= { chasEntityViewEntry 3} chasEntityTAddress OBJECT-TYPE SYNTAX TAddress ACCESS read-only STATUS mandatory DESCRIPTION "The transport service address by which the entity identified by this row of in the table may be accessed. The format of the address is determined by the value of chasEntityTAddress." ::= { chasEntityViewEntry 4} chasEntityCommunity OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..255)) ACCESS read-only STATUS mandatory DESCRIPTION "The SNMPv1 Community which is used to access, via the transport domain identified by chasEntityTDomain and chasEntityTAddress, the view of the entity identified by this row in the this table. If the view of the entity identified by this table row is not accessed by SNMPv1 then the value of this object for this row will be the zero length string. Note that it is possible to have seperate views of the same device accessed via different protocols. This is possible particular until SNMPv2 becomes established and is potentially true of bilingual agents." ::= { chasEntityEntry 5 } chasEntityContext OBJECT-TYPE SYNTAX Context ACCESS read-only STATUS mandatory DESCRIPTION "The SNMPv1 Context which is used to access, via the transport identified by chasEntityTDomain and chasEntityTAddress, the view of the entity identified by this row in the this table. If the view of the entity identified by this table row is not accessed by SNMPv2 then the value of this object for this row will be the NULL OID {0 0}. Note that it is possible to have seperate views of the same entity accessed via different protocols. This is possible particular until SNMPv2 becomes established and is potentially true of bilingual agents." ::= { chasEntityEntry 6 } -- The chasResource group. -- This defines a mapping of physical relationship (modules/resources) -- and a logical mapping of resource to entities. -- Implementation of the resource group is mandatory. -- Each physical module contains a number of logical -- resource. Each resource is a building -- block for constructing functional entities. This -- table contains an entry for each resource in the -- chassis, the type of entity this resource can -- belong to and the current entity to which this -- resource is assigned." -- NOTE. In this model a resource resides on a module and is -- entirely located on that module. This means there is a one to -- one correspondance of resource to module. -- NOTE. In this model a resource belongs to exactly ONE resource -- at any particluar time. This means that there is always a -- one to one correspondance of resource to entity. chasPhyResourceTable OBJET-TYPE SYNTAX SEQUENCE of ChasPhyResourceEntry ACCESS read-only STATUS mandatory DESCRIPTION "This table contains one entry per resource in a particular chassis configuration. The table identifies each resource by its physical location within the chassis. In this way the table provides a direct mapping from resource to module. The table contains columns which identify the entity to which each resource is currently assigned, if any and so an indirect mapping is provided from resource to entity. If a particular chassis allows the software, or management configuration of resources to entities then this table controls that assignment by allowing the chasPhyResAssignment to be writable." ::= { chasResource 1 } chasPhyResourceEntry OBJECT-TYPE SYNTAX ChasPhyResourceEntry ACCESS read-only STATUS mandatory DESCRIPTION "Defines a particular physical configuration relationship." INDEX { chasPhyResLocationType, chasPhyResLocation, chasPhyResIndex } ::= { chasResourceTable 1 } ChasPhyResourceEntry ::= SEQUENCE { chasPhyResLocationType INTEGER, chasPhyResLocation INTEGER, chasPhyResIndex INTEGER, chasPhyResType OBJECT IDENTIFIER, chasPhyResEntityType OBJECT IDENTIFIER, chasPhyResAssignment INTEGER, chasPhyResEntitySubIndex INTEGER } chasPhyResLocationType OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "A resource exists on a particular module. A module is identified by it's physical location. Physical location is defined location type and an instance of that physical location type. This object defines the location type. This object can be used in conjunction with chasPhyResLocation to index the module table." ::= { chasPhyResourceEntry 1 } chasPhyResLocation OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "A resource exists on a particular module. A module is identified by it's physical location. Physical location is defined location type and an instance of that physical location type. This object defines a particular instance of the physical location." ::= { chasPhyResourceEntry 2 } chasPhyResIndex OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "A unique index for the chassis resource on this particular physical module." ::= { chasPhyResourceEntry 3 } chasPhyResType OBJECT-TYPE SYNTAX OBJECT IDENTIFIER ACCESS read-only STATUS mandatory DESCRIPTION "The type of resource. A number of values for this object are defined at the start of this MIB module under the chasResTypes branch. Other values may be defined for specific enterprises." ::= { chasPhyResourceEntry 4 } chasPhyResEntityType OBJECT-TYPE SYNTAX OBJECT IDENTIFIER ACCESS read-only STATUS mandatory DESCRIPTION "The value of this object identifies the type of entity to which this resource may be assigned. Suitable values are defined at the start of this MIB module under the chasEntityTypes branch. This object is provided so that an intelligent management application can provide a list of suitable existing entites to which this resource may be assigned. For assigment to be successful, the value of this object must match the value of chasEntityObjectId in the chasEntityTable for the entity to which the resource is to be assigned." ::= { chasPhyResourceEntry 5 } chasPhyResAssignment OBJECT-TYPE SYNTAX INTEGER access read-write STATUS mandatory DESCRIPTION "Each resource may be 'assigned' to an existing entity. The value of this object identifies the entity to which this object is currently assigned. If the resource identified by a particular row in this table is not currently assigned to an entity then the value of this object for that row will be zero. Note that some implementations of this MIB may make this object writable. The effect of doing this is to allow standard management operations to dynamically reconfigure the resource of the chassis. Note that even if a specific implementation allows this object to be written, such operations may still fail if an illegal assignment is attempted. Illegal assignment includes assignment to a non-existent row, assignment to an inappropriate entity, eg an 802.3 repeater port to a token ring! Successfully changing the value of this object may have the side effect of changing the value of chasPhyResEntitySubIndex. The change will also be reflected in the chasLogResourceTable." ::= { chasPhyResourceEntry 6 } chasPhyResEntitySubIndex OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "A value that allows correlation with the cahsLogResourceTable. For each resource in this table which is assigned to an entity, there will be a corresponding row in the chasLogResourceTable. The row in the logical table is identified by indexing that table on the values of chasPhyResAssignment and chasPhyResEntitySubIndex. If a resource is not currently assigned to an entity, the value of this object for that resource will be zero and there will be no corresponding entry in chasLogResourceTable." ::= { chasPhyResourceEntry 7 } -- Logical configuration/resource table chasLogResourceTable OBJECT-TYPE SYNTAX SEQUENCE OF ChasLogResourceEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "This table contains a row for each resource in the system that is currently assigned to a particular entity. This table allows a direct mapping from entity to resource via the indices. The resource itself is identified by its location within the chassis. Note that no changes can be made to this table directly. The table will change when the physical configuration of the chassis changes or when the resource assignment is changed by access to chasPhyResourceTable." ::= { chasResource 2 } chasLogResourceEntry OBJECT-TYPE SYNTAX ChasLogResourceEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Defines a single logical relationship." INDEX { chasLogResourceEntity, chasLogResourceEntitySubIndex } ::= { chasLogResourceTable 1 } ChasLogResourceEntry SEQUENCE { chasLogResEntity INTEGER, chasLogResEntitySubIndex INTEGER, chasLogResLocationType INTEGER, chasLogResLocation INTEGER, chasLogResID INTEGER } chasLogResEntity OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The entity ID for which this logical configuration relationship exists." ::= { chasLogResourceEntry 1 } chasLogResEntitySubIndex OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "This object is used simply to provide for multiple resources assigned to a single entity." ::= { chasLogResourceEntry 2 } chasLogResLocationType OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "This object, in conjuntion with the value of chaLogResLocation identifies the module on which the resource refered to by this table row resides." ::= { chasLogResourceEntry 3 } chasLogResLocation OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "This object, in conjuntion with the value of chaLogResLocationType identifies the module on which the resource refered to by this table row resides." ::= { chasLogResourceEntry 4 } chasLogResID OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "A module potentially contains many resources. The value of this object identifies the specific resource instance on this module to which this table row defines an entity mapping." ::= { chasLogResourceEntry 5 } -- The chasInterconnect group. -- This group is OPTIONAL and is provided for those chassis that are -- prepared to or are capable of reporting internal resource interconnection -- information. The basic idea of this table is that it contains -- 'link descriptions'. Each such description documents a known connection -- between two resources in the chassis. There is no requirement to -- itemise all traffic links between resources in the chassis. For example -- if this were required then a link from every repeater port to every other -- repeater port in a repeater would be required. -- -- Useful interconnections that could be documented in this table are -- mappings from bridge and router ports to repeater ports. eg a -- bridge/router card contains a seperate bridge and router, but both share -- the same logical repeater ports to the backplane. eg: -- +-----------+ +----------------+ +-----------+ -- +<--]Bdge Port 1]<--] Bridge Relay ]-->]Bdge Port 2]-->+ -- ] +-----------+ +----------------+ +-----------+ ] -- ] ] -- V +-----------+ +----------------+ +-----------+ V -- +<--]Rter Port 1]<--] Relay Relay ]-->]Rter Port 2]-->+ -- ] +-----------+ +----------------+ +-----------+ ] -- ] ] -- +-------------+ +-------------+ -- ]Repeater Pt 1] ]Repeater Pt 2] -- +-------------+ +-------------+ -- Now in this case it is useful to know which bridge ports map to which -- repeater ports, given that both are in different entities. chasLinkTable OBJECT-TYPE SYNTAX SEQUENCE OF ChasLinkEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "This table contains entity/resource interconnection information. Note that this information in this table is read-only." ::= { chasInterconnect 1 } chasLinkEntry OBJECT-TYPE SYNTAX ChasLinkEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Each entry in this table describes a link between two resources." INDEX { chasLinkIndex } ::= { chasLinkTable 1 } ChasLogResourceEntry SEQUENCE { chasLinkIndex INTEGER, chasLinkFromLocType INTEGER, chasLinkFromLoc INTEGER, chasLinkFromResourceId INTEGER, chasLinkFromIf INTEGER, chasLinkToLocType INTEGER, chasLinkToLoc INTEGER, chasLinkToResourceId INTEGER, chasLinkToIf INTEGER } chasLinkIndex OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "This object is used to identify one of the link specifications in this table." ::= { chasLinkEntry 1 } chasLinkFromLocType OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "A link is defined to be between one resource and another. This object identifies is a partial definition of one end of the link. This object in conjuntion with chasLinkFromLoc and chasLinkFromResourceId identfiy the start of the link." ::= { chasLinkEntry 2 } chasLinkFromLoc OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "A link is defined to be between one resource and another. This object identifies is a partial definition of one end of the link. This object in conjuntion with chasLinkFromLocType and chasLinkFromResourceId identfiy the start of the link." ::= { chasLinkEntry 3 } chasLinkFromResourceId OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "A link is defined to be between one resource and another. This object identifies is a partial definition of one end of the link. This object in conjuntion with chasLinkFromLocType and chasLinkFromLoc identfiy the start of the link." ::= { chasLinkEntry 4 } chasLinkFromIfNumber OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "This object can be used to correlate the resource to an entry in an ifTable visible through the entity to which this resource belongs. Without this object there is no correlation between a resource and an entities ifTable. Note that if this value is zero then either the information is not available OR is not applicable." ::= { chasLinkEntry 5 } chasLinkToLocType OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "A link is defined to be between one resource and another. This object identifies is a partial definition of one end of the link. This object in conjuntion with chasLinkToLoc and chasLinkToResourceId identfiy the end of the link." ::= { chasLinkEntry 6 } chasLinkToLoc OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "A link is defined to be between one resource and another. This object identifies is a partial definition of one end of the link. This object in conjuntion with chasLinkToLocType and chasLinkToResourceId identfiy the end of the link." ::= { chasLinkEntry 7 } chasLinkToResourceId OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "A link is defined to be between one resource and another. This object identifies is a partial definition of one end of the link. This object in conjuntion with chasLinkToLocType and chasLinkToResourceId identfiy the end of the link." ::= { chasLinkEntry 8 } chasLinkFromIfNumber OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "This object can be used to correlate the resource to an entry in an ifTable visible through the entity to which this resource belongs. Without this object there is no correlation between a resource and an entities ifTable. Note that if this value is zero then either the information is not available OR is not applicable." ::= { chasLinkEntry 9 } -- 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! -- -- && Note that identifying PS resouces differently here to the -- && resource table is confusing. 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 INTEGER, chasPSOutputOfferedVoltage INTEGER, chasPSOutputOfferedWattage INTEGER, 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 INTEGER 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 INTEGER 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 INTEGER 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. -- && In the same way that each power supply is -- && a resource, so is each environmental monitor. This -- && table can also be described as an AUGMENTS or a shared -- && index with the resource table. In the long run it is -- && more economical on MIB objects to share the indices -- && with the resource table. In preparation for this I've -- && changed this table to use the location type and index -- && to identify rows in this table. -- && -- && 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 DESCRIPTION "A sensor resource exists on a particular module. This variable identifies the type part of the module on which this sensor resides." ::= { chasEnvironEntry 1 } chasEnvironLocationIndex OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "A sensor 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 sensor resides." ::= { chasEnvironEntry 2 } chasEnvironResource OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "A unique index for the resource on this particular physical module." ::= { chasEnvironEntry 3 } chasEnvironStatus OBJECT-TYPE SYNTAX INTEGER { unknown (1), bad (2), warning (3), good (4) } ACCESS read-only STATUS mandatory DESCRIPTION "Actual status indicated by the sensor. It is an implementation specific matter whether the agent keeps entries with status unknown(1) in the table. If unknown(1), counters are meaningless." ::= { chasEnvironEntry 4 } chasEnvironWarnings OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of times chasEnvironStatus has gone to warning(3)." ::= { chasEnvironEntry 5 } chasEnvironFailures OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of times chasEnvironStatus has gone to bad(2)." ::= { chasEnvironEntry 6 } END