Chassis MIB Draft
"David L. Arneson (arneson@ctron.com)" <arneson@ctron.com> Thu, 12 November 1992 16:35 UTC
Return-Path: <owner-chassismib>
Received: by CS.UTK.EDU (5.61++/2.8s-UTK) id AA29367; Thu, 12 Nov 92 11:35:00 -0500
Received: from nic.near.net by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA29341; Thu, 12 Nov 92 11:34:29 -0500
Received: from ctron.com by nic.near.net id aa04285; 12 Nov 92 11:34 EST
Received: from yeti.ctron ([134.141.40.159]) by ctron.com (4.1/SMI-4.1) id AA24402; Thu, 12 Nov 92 11:34:09 EST
Received: by yeti.ctron (4.1/SMI-4.1) id AA01061; Thu, 12 Nov 92 11:33:33 EST
Message-Id: <9211121633.AA01061@yeti.ctron>
To: chassismib@cs.utk.edu
Subject: Chassis MIB Draft
Reply-To: arneson@ctron.com
Date: Thu, 12 Nov 1992 11:33:23 -0500
From: "David L. Arneson (arneson@ctron.com)" <arneson@ctron.com>
Hello Everyone, I wanted to get this draft out to everybody before the IETF. I was hoping to get a resolution to the chasEntityFunction problem but none seems forth comming. I have added the power supply and environment groups. I have defined individual groups for most everything. I have shifted our well know values into there own branch. Many of the outstanding comments have been added. Now not wanting to step on our chair's authority, I think we need to get the following done at our meeting next week. 1) Resolve chasEntity problem. I will expand the example as Dave Perkins suggested after this is resolved. 2) Come to an understanding on sections 5.8 and 5.9. 3) Reach agreement on chasEntityAdminStatus and chasEntityArgument. 4) A general review of the draft. Attached please find the next draft. Thank you, /David Arneson [arneson@ctron.com] [ (603)337-5064 ] ------------------------------ Internet Draft Chassis MIB October 1992 Definitions of Managed Objects for a Chassis Containing Multiple Logical Network Devices November 12, 1992 Keith McCloghrie Hughes LAN Systems, Inc. kzm@hls.com David Arneson Cabletron Systems, Inc. arneson@ctron.com Manu Kaycee Ungermann-Bass, Inc kaycee@andr.UB.com Bob Stewart Xyplex, Inc stewart@eng.xyplex.com Donna McMaster SynOptics Inc mcmaster@synoptics.com 1. Abstract This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular it defines objects for managing a chassis containing multiple (logical) networking devices, such as repeaters, bridges, routers, terminal servers, etc. McCloghrie/Arneson/Kaycee/Stewart/McMaster [Page 1] Internet Draft Chassis MIB October 1992 2. Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. This document, when finalized, will be submitted to the RFC editor as an extension to the SNMP MIB. Distribution of this memo is unlimited. Please send comments to the working group at chassismib@cs.utk.edu. 3. Management Framework The Internet-standard Network Management Framework consists of three components. They are: RFC 1155 which defines the SMI, the mechanisms used for describing and naming objects for the purpose of management. RFC 1212 defines a more concise description mechanism, which is wholly consistent with the SMI. RFC 1156 which defines MIB-I, the core set of managed objects for the Internet suite of protocols. RFC 1213, defines MIB-II, an evolution of MIB-I based on implementation experience and new operational requirements. RFC 1157 which defines the SNMP, the protocol used for network access to managed objects. McCloghrie/Arneson/Kaycee/Stewart/McMaster [Page 2] Internet Draft Chassis MIB October 1992 The Framework permits new objects to be defined for the purpose of experimentation and evaluation. 4. Objects Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the subset of Abstract Syntax Notation One (ASN.1) [4] defined in the SMI. In particular, each object has a name, a syntax, and an encoding. The name is an object identifier, an administratively assigned name, which specifies an object type. The object type together with an object instance serves to uniquely identify a specific instantiation of the object. For human convenience, we often use a textual string, termed the OBJECT DESCRIPTOR, to also refer to the object type. The syntax of an object type defines the abstract data structure corresponding to that object type. The ASN.1 language is used for this purpose. However, the SMI [1] purposely restricts the ASN.1 constructs which may be used. These restrictions are explicitly made for simplicity. The encoding of an object type is simply how that object type is represented using the object type's syntax. Implicitly tied to the notion of an object type's syntax and encoding is how the object type is represented when being transmitted on the network. The SMI specifies the use of the basic encoding rules of ASN.1 [5], subject to the additional requirements imposed by the SNMP. 4.1. Format of Definitions Section 6 contains the specification of all object types contained in this MIB module. The object types are defined using the conventions defined in the SMI, as amended by the extensions specified in [6,7]. McCloghrie/Arneson/Kaycee/Stewart/McMaster [Page 3] Internet Draft Chassis MIB October 1992 5. Overview This memo defines objects for the management of a chassis containing multiple slots, each of which can potentially contain a board/physical module performing some networking function(s). A physical module, or combinations of physical modules, might perform one or more of the functions of a networking device such as a router, bridge, terminal server, concentrator, management card, etc. Indeed, this relationship between physical module and function can be many-to-many. Thus, this memo uses the term 'entity' to refer to a logical networking device which may span parts of one or more modules. This type of chassis often contains one or more internal segments through which the logical devices are inter-connected to each other. These segments often use standard MAC and/or link-layer protocols even though their physical layer may be different to that normally used with that MAC or link-layer. This MIB contains 6 information groups: the Slot group, the Entity group, the Segment group, the Chassis Configuration group, the Power Supply Group, and the Environment Group. The remainder of this section will discuss the contents of these groups. 5.1. Example Chassis In an effort to clarify the contents of the slot, entity, segment, chassis configuration groups the following example is presented. The discussion of each group will refer to this example: Consider a simple 6 slot chassis that contains 1 bridge as entity 2. The chassis also contains 2 repeaters entities 1 and 3. The chassis is organized as follows: Slot Entity Segment 1 2 1 1 2 2 3 1 1 4 1 1 5 3 2 6 3 2 McCloghrie/Arneson/Kaycee/Stewart/McMaster [Page 4] Internet Draft Chassis MIB October 1992 5.2. The Slot Group This group contains an object that identifies the number of slots in the chassis. It also contains a table which contains information about the slots in this chassis. This table may be implemented as either dense or sparse. Implementation of this group is considered mandatory. As presented in the example in section 5.1 we have a 6 slot chassis. Notice that, physical modules reside is slots 1, and 3 thru 6. Slot 2 is empty. At this point the implementor has a choice. The table maybe implemented as either dense or sparse. If the table is implemented as dense then the table will have 6 conceptual rows and the conceptual row corresponding to slot 2 will be identified as empty. If the table is implemented as sparse then there will be no conceptual row for slot 2. 5.3. The Entity Group This group contains a table that contains information about the logical networking devices in this chassis. In addition it defines the means to access a MIB view for each such entity. These may be addressed either by the combination of chasEntityCommunity and chasEntityIPAddress or by chasEntityParty. These MIB views maybe defined by this agent or a different agent. Implementation of this group is considered mandatory since it provides MIB views, and a list of entities. Using the example in section 5.1 the entity table will have 3 conceptual rows, one each for the 2 repeaters and a third for the bridge, present in this table. 5.4. The Segment Group This group contains a table that contains information about the network segments, contained within the chassis, and used to interconnect the chassis's logical networking devices. Implementation of this group is optional. McCloghrie/Arneson/Kaycee/Stewart/McMaster [Page 5] Internet Draft Chassis MIB October 1992 Using the above example this table would contain 2 conceptual rows one for each segment. 5.5. The Chassis Configuration Group This group contains information about the chassis configuration. This includes type of chassis, chassis serial number, and the number of physical changes that have occured within the chassis. This group also contains a table that contains information about which entities are in which slots in the chassis and the segments to which they are connected. The objects, chasConfigIndexType and chasConfigIndexValue provide linkage from an entity's segment connection in this MIB to the management information contained in the entity's own MIB. In particular, these objects indicate that the particular segment connection of the entity in the slot represented by this conceptual row is identified within the entity's MIB by the object type named by chasConfigIndexType having the value given by chasConfigIndexValue. It is an implementation specific matter whether the chasConfigTable is implemented as read-write or read-only. Implementation of this group is optional. However since this group contains information about the chassis and a mapping of entities to slots and segments impelementation is desirable. If this group is implemented then the segment groups should also be implemented. Using the example in section 5.1 the configuration table would contain 6 conceptual rows. One for each slot, entity, segment combination defined in the example above. The first concpetual row would define the bridge entity in slot 1 with chasConfigIndexType of bridge port and chasConfigIndex value of 1. The other conceptual rows would be similar defining the bridge port and repeater ports. 5.6. The Power Supply Group This group contains a table of power supplies and a table of power supply outputs. The Power Supply Table contains the overall status of each power supply in the chassis. The Power McCloghrie/Arneson/Kaycee/Stewart/McMaster [Page 6] Internet Draft Chassis MIB October 1992 Supply Output Table contains status for each output of each power supply. Implementation of this group is optional. 5.7. The Environment Group This group contains a table of environmental sensors. The Environment Table contains the type and status of each sensor. Implementation of this group is optional. 5.8. What is a Chassis This MIB applies to a chassis. In its normal sense, a "chassis" is a collection of traditionally discrete network devices packaged in a single cabinet and power system. Indeed, the descriptions of the objects are phrased assuming such a "physical" chassis. However, these descriptions are not intended to exclude the application of this MIB to a "logical chassis". Examples of such logical chassis might be: - a building containing many network devices, where each room in the building might be considered as a logical "slot", - a geographical area containing many network devices, where each building in the area might be considered as a logical "slot". Note also that the MIB implementations for multiple (physical or logical) chassis might be arranged hierachically, i.e., a module/entity represented in one agent's chassis MIB might in fact represent a whole (lower-level) chassis. For example, in a equipment cabinet having multiple shelves with each shelf having multiple plug-in cards, the whole cabinet could be represented by an overall chassis MIB in which each "slot" represents a shelf, and there might also be individual chassis MIBs for each shelf in which each slot represents where the plug-in cards live. McCloghrie/Arneson/Kaycee/Stewart/McMaster [Page 7] Internet Draft Chassis MIB October 1992 5.9. Multiple Instantiations For each (logical or physical) chassis, it is possible to have multiple agents implement this MIB for the same chassis. However, is is expected that normally just one agent per chassis will implement this Chassis MIB. When multiple agents do implement this MIB for the same chassis, there is no "master" (in the sense of a point of control), and each agent must implement all mandatory parts of the MIB and each contain information on all entities/modules/segments in the chassis. Furthermore, the information in each such agent must be semantically identical (i.e., absolute values must be identical, and relative values must be equivalent). 6. Definitions CHASSIS-MIB DEFINITIONS ::= BEGIN IMPORTS experimental, TimeTicks, IpAddress, Counter FROM RFC1155-SMI Party FROM RFC1353-MIB; -- SNMP Party MIB -- 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) AutonomousType ::= OBJECT IDENTIFIER -- The object identifier is an independently extensible type -- identification value. It may, for example indicate a -- particular sub-tree with further MIB definitions, or -- define something like a protocol type or type of -- hardware. McCloghrie/Arneson/Kaycee/Stewart/McMaster [Page 8] Internet Draft Chassis MIB October 1992 chassis OBJECT IDENTIFIER ::= { experimental 38 } -- Groups within the chassis MIB chasSlot OBJECT IDENTIFIER ::= { chassis 1 } chasEntity OBJECT IDENTIFIER ::= { chassis 2 } chasSegment OBJECT IDENTIFIER ::= { chassis 3 } chasConfig OBJECT IDENTIFIER ::= { chassis 4 } chasPowerSupply OBJECT IDENTIFIER ::= { chassis 5 } chasEnviron OBJECT IDENTIFIER ::= { chassis 6 } -- Chassis MIB Know Types chasKnownTypes OBJECT IDENTIFIER ::= { chassis 7 } -- The chasSlot (chassis slot) group -- Implementation of the chasSlot group is mandatory. chasNumSlots OBJECT-TYPE SYNTAX INTEGER (1..65535) ACCESS read-only STATUS mandatory DESCRIPTION "Number of slots in this chassis." ::= { chasSlot 1 } -- The Slot Table -- It is an implementation specific matter if this table is -- dense. If the table is dense and the slot is empty then -- chasSlotModuleType should have the value chasSlotEmpty. -- In addition the values of chasSlotModuleDescr, -- chasSlotModuleVersion and chasSlotModuleSerialNumber -- should be set to null. chasSlotTable OBJECT-TYPE SYNTAX SEQUENCE OF ChasSlotEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A table that contains information about the slots in this chassis. For those slots that do not contain a physical module, the table may be McCloghrie/Arneson/Kaycee/Stewart/McMaster [Page 9] Internet Draft Chassis MIB October 1992 implemented to contain a conceptual row with the type of physical module set the 'chasSlotEmpty', or it may be implemented to have no conceptual row instance." ::= { chasSlot 2 } chasSlotEntry OBJECT-TYPE SYNTAX ChasSlotEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A list of information for each slot in the chassis. Conceptual rows may not be created or deleted with SNMP operations." INDEX { chasSlotIndex } ::= { chasSlotTable 1 } ChasSlotEntry ::= SEQUENCE { chasSlotIndex INTEGER, chasSlotModuleType OBJECT IDENTIFIER, chasSlotLastChange TimeTicks, chasSlotModuleDescr DisplayString, chasSlotModuleVersion DisplayString, chasSlotModuleSerialNumber DisplayString } chasSlotIndex OBJECT-TYPE SYNTAX INTEGER (1..65535) ACCESS read-only STATUS mandatory DESCRIPTION "The slot number of the chassis for which this entry contains management information." ::= { chasSlotEntry 1 } chasSlotModuleType OBJECT-TYPE SYNTAX OBJECT IDENTIFIER ACCESS read-only McCloghrie/Arneson/Kaycee/Stewart/McMaster [Page 10] Internet Draft Chassis MIB October 1992 STATUS mandatory DESCRIPTION "The type of physical module contained in this slot of the chassis. If the table is implemented as dense, a value of chasSlotEmpty indicates an empty slot. A value of chasSlotUnknown indicates that the type of module is unknown." ::= { chasSlotEntry 2 } chasSlotLastChange 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 removed from this slot. If no module has been inserted or removed from this slot since the last time the network management system was last re-initialized, then this object has a zero value." ::= { chasSlotEntry 3 } chasSlotModuleDescr OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) ACCESS read-only STATUS mandatory DESCRIPTION "A textual description of the module plugged into the slot. If not available this value should be set to a zero length string." ::= { chasSlotEntry 4 } chasSlotModuleVersion 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 hardware and firmware. If not realized this value should be set to the zero-length string." ::= { chasSlotEntry 5 } McCloghrie/Arneson/Kaycee/Stewart/McMaster [Page 11] Internet Draft Chassis MIB October 1992 chasSlotModuleSerialNumber OBJECT-TYPE SYNTAX DisplayString (SIZE (0..32)) ACCESS read-only STATUS mandatory DESCRIPTION "The serial number of the module present in the slot. If the slot table is implemented as dense and the slot is empty this value will be the zero length string. If no serial number is available for a module this value should set to a zero length string." ::= { chasSlotEntry 6 } McCloghrie/Arneson/Kaycee/Stewart/McMaster [Page 12] Internet Draft Chassis MIB October 1992 -- 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 (entity) in this chassis." ::= { chasEntity 1 } chasEntityEntry OBJECT-TYPE SYNTAX ChasEntityEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Information concerning an entity in the chassis. Conceptual rows may not be created or deleted with SNMP operations." INDEX { chasEntityIndex } ::= { chasEntityTable 1 } ChasEntityEntry ::= SEQUENCE { chasEntityIndex INTEGER, chasEntityFunction INTEGER, chasEntityObjectID OBJECT IDENTIFIER, chasEntityDescr DisplayString, chasEntityVersion DisplayString, chasEntityAdminStatus INTEGER, chasEntityOperStatus INTEGER, chasEntityArgument OCTET STRING, chasEntityTimeStamp McCloghrie/Arneson/Kaycee/Stewart/McMaster [Page 13] Internet Draft Chassis MIB October 1992 TimeTicks, chasEntityParty Party, chasEntityCommunity OCTET STRING, chasEntityIpAddress IpAddress } 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 } chasEntityFunction OBJECT-TYPE SYNTAX INTEGER (0..1023) ACCESS read-only STATUS mandatory DESCRIPTION "The generic function of the entity. The value is a sum. Starting from zero, for each type of generic function that the entity performs, 2 raised to a power is added to the sum. The powers are according to the following table: Function Power other 0 repeater 1 -- e.g. Ethernet repeater, -- e.g. FDDI concentrator bridge 2 router 3 terminalServer 4 agent 5 -- entity that defines chassis MIB services 6 -- e.g. MIB Walk tools manager etc mau 7 power 8 networkMonitor 9 -- e.g. RMON device For example, an entity performing both bridging and routing functions would have a value of 12 (2^2 + McCloghrie/Arneson/Kaycee/Stewart/McMaster [Page 14] Internet Draft Chassis MIB October 1992 2^3)." ::= { chasEntityEntry 2 } chasEntityObjectID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER ACCESS read-only STATUS mandatory DESCRIPTION "The specific type of entity. The value of this object is analagous to MIB-II's sysObjectId. In particular, it has the same value as would be returned if the SNMP Party (identified by chasEntityParty) and/or the community (identified by chasIpAddress and chasCommunity), were queried for sysObjectId." ::= { chasEntityEntry 3 } chasEntityDescr OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) ACCESS read-write STATUS mandatory DESCRIPTION "A textual description of the entity. The value of this object is analagous to MIB-II's sysDescr. In particular, it has the same value as would be returned if the SNMP Party (identified by chasEntityParty) and/or the community (identified by chasIpAddress and chasCommunity), were queried for sysDescr." ::= { chasEntityEntry 4 } chasEntityVersion OBJECT-TYPE SYNTAX DisplayString (SIZE (0..32)) ACCESS read-only STATUS mandatory DESCRIPTION "A textual description of the version/revision level for this entity's software." ::= { chasEntityEntry 5 } chasEntityAdminStatus OBJECT-TYPE SYNTAX INTEGER { unknown(1), -- none of the following McCloghrie/Arneson/Kaycee/Stewart/McMaster [Page 15] Internet Draft Chassis MIB October 1992 enable(2), disable(3), reset(4), programload(5), test(6) } ACCESS read-write STATUS mandatory DESCRIPTION "Provides the administratively desired state of the given entity. An entity is activated by writing a value of enable(2). An entity may be de-activated by writing a value of disable(3). In a disabled state, a entity does exist within the given chassis, but is benign. A disabled entity is available for subsequent activation. Writing a value of reset(4) specifies an entity should initiate a reset sequence. Writing a value of programload(5) specifies an entity should initiate a program load sequence. Writing a value of test(6) specifies an entity should initiate a testing sequence. Agent support of the writing of any of the values of this object is implementation-specific. For example, this object might be read only for entities that disabling would compromise the integrity of the chassis." ::= { chasEntityEntry 6 } chasEntityOperStatus OBJECT-TYPE SYNTAX INTEGER { other(1), -- none of the following invalid(2), testing(3), operational(4), resetInProgress(5), warning(6), McCloghrie/Arneson/Kaycee/Stewart/McMaster [Page 16] Internet Draft Chassis MIB October 1992 nonFatalError(7), fatalError(8), loading(10) } ACCESS read-only STATUS mandatory DESCRIPTION "Provides operational status of the entity. The following are possible definitions of the values. The exact definition of the values is implementation specific. A value of other(1) implies some undetermined state, possibly as a result of setting chasEntityAdminStatus to a value of disable(3). A value of invalid(2) could have the possible meaning that the entity exists but the chassis manager has no direct control of the entity. A value of testing(3) may be a diagnostic state. A value of operational(4) implies that the entity is running with no errors or warnings. State resetInProgress(5) implies equivalent of setting chasEntityAdminStatus to reset(4). The states of warning(6), nonFatalError(7), fatalError(8) reflect conditions detected during operation. The entity may or may not be still functional. State loading(10) is a result of asserting programload(5) in chasEntityAdminStatus. For example if an entities value of chasEntityAdminStatus is disable(3) and is set to enable(2) then chasEntityOperStatus may enter a state of testing(3) then change to a value of operational(4)." ::= { chasEntityEntry 7 } chasEntityArgument OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..32)) ACCESS read-write STATUS mandatory DESCRIPTION "A variable that may be passed to an entity. The value may be passed to the entity upon its restart and upon transitions of chasEntityOperStatus from disable to enable. However, exact usage is implementation specific." ::= { chasEntityEntry 8 } McCloghrie/Arneson/Kaycee/Stewart/McMaster [Page 17] Internet Draft Chassis MIB October 1992 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 9 } chasEntityParty OBJECT-TYPE SYNTAX Party ACCESS read-only STATUS mandatory DESCRIPTION "The SNMP Party which provides access to the detailed management information for this entity. Note that the definition of a SNMP Party includes the location at which it executes, the MIB view to which it provides access, the authentication and privacy algorithms and parameters required to access its MIB view, and whether or not proxy is performed. In order for a SNMP manager to be able to access the Party, that manager must have prior knowledge of the Party. In particular, the manager must know the location at which the Party executes. A party is named by an OBJECT IDENTIFIER. For a entity which is not managed through access to a SNMP Party, the value of this object is chasEntityNoParty." ::= { chasEntityEntry 10 } chasEntityCommunity OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..256)) ACCESS read-only STATUS mandatory DESCRIPTION "The SNMP Community which executes at the address chasEntityIpAddress, and provides access to the detailed management information for this entity. McCloghrie/Arneson/Kaycee/Stewart/McMaster [Page 18] Internet Draft Chassis MIB October 1992 For a entity which is not managed through access to a SNMP Community, the value of this object is the zero-length string." ::= { chasEntityEntry 11 } chasEntityIpAddress OBJECT-TYPE SYNTAX IpAddress ACCESS read-only STATUS mandatory DESCRIPTION "The address of the SNMP agent which responds to messages for the SNMP Community identified by chasEntityCommunity. When access is via proxy, this variable contains the address of the proxy agent. For a entity which is not managed through access to a SNMP Community, the value of this object is 0.0.0.0." ::= { chasEntityEntry 12 } McCloghrie/Arneson/Kaycee/Stewart/McMaster [Page 19] Internet Draft Chassis MIB October 1992 -- The chasSegment group. Implementation of the chasSegment group is -- optional. -- The Segment Table chasSegmentTable OBJECT-TYPE SYNTAX SEQUENCE OF ChasSegmentEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A table that contains information about the network segments, contained within the chassis, and used to interconnect the chassis's logical networking devices." ::= { chasSegment 1 } chasSegmentEntry OBJECT-TYPE SYNTAX ChasSegmentEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A list of information for a particular segment in the chassis." INDEX { chasSegmentIndex } ::= { chasSegmentTable 1 } ChasSegmentEntry ::= SEQUENCE { chasSegmentIndex INTEGER, chasSegmentType OBJECT IDENTIFIER } chasSegmentIndex OBJECT-TYPE SYNTAX INTEGER (1..65535) ACCESS read-only STATUS mandatory DESCRIPTION "A unique index for the network segment for which this entry contains information." ::= { chasSegmentEntry 1 } chasSegmentType OBJECT-TYPE SYNTAX OBJECT IDENTIFIER McCloghrie/Arneson/Kaycee/Stewart/McMaster [Page 20] Internet Draft Chassis MIB October 1992 ACCESS read-only STATUS mandatory DESCRIPTION "The type of segment. For example, for an Ethernet segment this object would have the value: dot3 as defined in RFC 1284, while a token-ring segment would have a value of dot5. A value of chasSegmentUnknown indicates that the type of segment is unknown." ::= { chasSegmentEntry 2 } McCloghrie/Arneson/Kaycee/Stewart/McMaster [Page 21] Internet Draft Chassis MIB October 1992 -- the chasConfig (configuration) group, implementation of the -- configuration group is optional. 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." ::= { chasConfig 1 } chasPhysicalChanges OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of physical changes that have occurred in the chassis since the agent was warm/cold started. This includes additions and removal of modules and entities. Other uses are implementation specific." ::= { chasConfig 2 } 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." ::= { chasConfig 3 } -- The Chassis Configuration Table chasConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF ChasConfigEntry McCloghrie/Arneson/Kaycee/Stewart/McMaster [Page 22] Internet Draft Chassis MIB October 1992 ACCESS not-accessible STATUS mandatory DESCRIPTION "A table that contains information about which entities are in which slots in the chassis and the segments to which they are connected." ::= { chasConfig 4 } chasConfigEntry OBJECT-TYPE SYNTAX ChasConfigEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A configuration relationship between an entity, a slot and a segment in the chassis. Such a relationship exists if the particular slot is occupied by the physical module (or one of the boards) performing (part of) the function of the particular entity, and is connected to a particular segment." INDEX { chasConfigSlot, chasConfigEntity, chasConfigSegment } ::= { chasConfigTable 1 } ChasConfigEntry ::= SEQUENCE { chasConfigSlot INTEGER, chasConfigEntity INTEGER, chasConfigSegment INTEGER, chasConfigStatus INTEGER, chasConfigIndexType OBJECT-IDENTIFIER, chasConfigIndexValue INTEGER } chasConfigSlot OBJECT-TYPE SYNTAX INTEGER (1..65535) ACCESS read-write STATUS mandatory McCloghrie/Arneson/Kaycee/Stewart/McMaster [Page 23] Internet Draft Chassis MIB October 1992 DESCRIPTION "The slot number of the chassis for this configuration relationship." ::= { chasConfigEntry 1 } chasConfigEntity OBJECT-TYPE SYNTAX INTEGER (1..65535) ACCESS read-write STATUS mandatory DESCRIPTION "The entity for this configuration relationship. The entity identified by this object is the same entity as identified by the same value of chasEntityIndex." ::= { chasConfigEntry 2 } chasConfigSegment OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-write STATUS mandatory DESCRIPTION "The segment for this configuration relationship. The segment identified by a non-zero value of this object is the same segment as identified by the same value of chasSegmentIndex. A value of 0 represents the 'null' segment; only entities in slots which are not connected to any segment identified by a value of chasSegmentIndex are connected to the 'null' segment." ::= { chasConfigEntry 3 } chasConfigStatus OBJECT-TYPE SYNTAX INTEGER { valid(1), invalid(2) } ACCESS read-write STATUS mandatory DESCRIPTION "The status of this configuration relationship. Writing a value of invalid(1) to an instance of this object causes the configuration relationship to be invalidated. Support for creating or invalidating instances of this object will normally be subject to the hardware limitations of the physical module in the referenced slot. When supported, the creation McCloghrie/Arneson/Kaycee/Stewart/McMaster [Page 24] Internet Draft Chassis MIB October 1992 (invalidation) of instances may have the implicit side-effect of removing (creating) other instances of this object, e.g., the creation of a new conceptual row in this table for a physical module which connects to exactly one segment, would remove the conceptual row corresponding to the module's prior segment connection. It is an implementation-specific matter as to whether the agent removes an invalidated entry from the table. Accordingly, management stations must be prepared to receive tabular information from agents that corresponds to entries not currently in use. Proper interpretation of such entries requires examination of the relevant chasConfigStatus object. It is implementation-specific as to whether write-access to this object is supported by an agent" ::= { chasConfigEntry 4 } chasConfigIndexType OBJECT-TYPE SYNTAX OBJECT-IDENTIFIER ACCESS read-only STATUS mandatory DESCRIPTION "An OBJECT IDENTIFIER which takes the value of the OID name of an object type, e.g., ifIndex, or rptrPortIndex, or dot1dBasePort, etc. The indicated object type together with the corresponding value of chasConfigIndexValue provide linkage between this segment connection and management information contained in the entity's own MIB. So, a value of { ifEntry 1 } would indicate ifIndex. A value of chasConfigTypeUnknown could indicate that the linkage doesn't exist or is unknown." ::= { chasConfigEntry 5 } chasConfigIndexValue OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION McCloghrie/Arneson/Kaycee/Stewart/McMaster [Page 25] Internet Draft Chassis MIB October 1992 "An INTEGER value which is the particular index value of the object type defined by chasConfigIndexType. This then identifies a particular interface/repeater port/bridge port etc. For segment-connections which do not correspond to interfaces or for which the index value is unknown, this object has the value zero. In this case chasConfigIndexType will have a value of chasConfigIndexTypeUnknown." ::= { chasConfigEntry 6 } McCloghrie/Arneson/Kaycee/Stewart/McMaster [Page 26] Internet Draft Chassis MIB October 1992 -- The chasPowerSupply (Power Supply) group, implementation of -- the power supply group is optional. -- the Power Supply table chasPowerSupplyTable OBJECT-TYPE SYNTAX SEQUENCE OF ChasPowerSupplyEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A list of power supply entries, one for each power supply in the chassis." ::= { chasPowerSupply 1 } chasPowerSupplyEntry OBJECT-TYPE SYNTAX ChasPowerSupplyEntry ACCESS not-accessible STATUS mandatory DESCRIPTION Values for a power supply." INDEX { chasPowerSupplyIndex } ::= { chasPowerSupplyTable 1 } ChasPowerSupplyEntry ::= SEQUENCE { chasPowerSupplyIndex INTEGER, chasPowerSupplyDescr DisplayString, chasPowerSupplyAdminStatus INTEGER, chasPowerSupplyOperStatus INTEGER, chasPowerSupplyHealthText DisplayString, chasPowerSupplyWarnings Counter, chasPowerSupplyFailures Counter } chasPowerSupplyIndex OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory McCloghrie/Arneson/Kaycee/Stewart/McMaster [Page 27] Internet Draft Chassis MIB October 1992 DESCRIPTION "An index value that uniquely identifies a power supply. This may correspond to a hardware power supply slot, which may or may not be the same as a network device slot (chasSlotIndex)." ::= { chasPowerSupplyEntry 1 } chasPowerSupplyDescr OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) ACCESS read-only STATUS mandatory DESCRIPTION "A textual description of the power supply, including the vendor's name and version." ::= { chasPowerSupplyEntry 2 } chasPowerSupplyAdminStatus OBJECT-TYPE SYNTAX INTEGER { unknown(1), enable(2), disable(3) } ACCESS read-write STATUS mandatory DESCRIPTION "Desired status of the power supply." ::= { chasPowerSupplyEntry 3 } chasPowerSupplyOperStatus OBJECT-TYPE SYNTAX INTEGER { unknown(1), empty(2), disabled(3), bad(4), warning(5), standby(6), engaged(7), redundant(8) } ACCESS read-only STATUS mandatory DESCRIPTION "Actual status of the power supply: - unknown(1) - status not known. - empty(2) - no power supply installed in slot - disabled(3) - unable to supply power due to McCloghrie/Arneson/Kaycee/Stewart/McMaster [Page 28] Internet Draft Chassis MIB October 1992 chasPowerSupplyAdminStatus - bad(4) - unable to supply power due to failure - warning(5) - supplying power but an output or sensor is bad or warning - standby(6) - believed usable but not supplying power - engaged(7) - supplying power - redundant(8) - supplying power but not needed It is an implementation specific matter whether the agent keeps entries with status unknown(1) or empty(2) in the table." ::= { chasPowerSupplyEntry 4 } chasPowerSupplyHealthText OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) ACCESS read-only STATUS mandatory DESCRIPTION "A textual description of the power supply's operational status. Agents may use this string to provide detailed information on current failures, including how they were detected, and/or instructions for problem resolution. The contents are agent-specific." ::= { chasPowerSupplyEntry 5 } chasPowerSupplyWarnings OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of times chasPowerSupplyOperStatus has gone to warning(5)." ::= { chasPowerSupplyEntry 6 } chasPowerSupplyFailures OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of times chasPowerSupplyOperStatus has gone to bad(4)." ::= { chasPowerSupplyEntry 7 } McCloghrie/Arneson/Kaycee/Stewart/McMaster [Page 29] Internet Draft Chassis MIB October 1992 -- the Power Supply Output table chasPowerSupplyOutputTable OBJECT-TYPE SYNTAX SEQUENCE OF ChasPowerSupplyOutputEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A list of power supply output entries, one for each output of each power supply in the chassis." ::= { chasPowerSupply 2 } chasPowerSupplyOutputEntry OBJECT-TYPE SYNTAX ChasPowerSupplyEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Values for a power supply output." INDEX { chasPowerSupplyIndex, chasPowerSupplyOutputIndex } ::= { chasPowerSupplyOutputTable 1 } ChasPowerSupplyOutputEntry ::= SEQUENCE { chasPowerSupplyOutputIndex INTEGER, chasPowerSupplyOutputStatus INTEGER, chasPowerSupplyOutputNominalVoltage Gauge, chasPowerSupplyOutputOfferedVoltage Gauge, chasPowerSupplyOutputOfferedWattage Gauge, chasPowerSupplyOutputWarnings Counter, chasPowerSupplyOutputFailures Counter } chasPowerSupplyOutputIndex OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "An index value that uniquely identifies an output for the power supply." McCloghrie/Arneson/Kaycee/Stewart/McMaster [Page 30] Internet Draft Chassis MIB October 1992 ::= { chasPowerSupplyOutputEntry 1 } chasPowerSupplyOutputStatus 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 2 } chasPowerSupplyOutputNominalVoltage 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 3 } chasPowerSupplyOutputOfferedVoltage 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." McCloghrie/Arneson/Kaycee/Stewart/McMaster [Page 31] Internet Draft Chassis MIB October 1992 ::= { chasPowerSupplyOutputEntry 4 } chasPowerSupplyOutputOfferedWattage 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 5 } chasPowerSupplyOutputWarnings OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of times chasPowerSupplyOutputStatus has gone to warning(3)." ::= { chasPowerSupplyOutputEntry 6 } chasPowerSupplyOutputFailures OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of times chasPowerSupplyOutputStatus has gone to bad(2)." ::= { chasPowerSupplyOutputEntry 7 } McCloghrie/Arneson/Kaycee/Stewart/McMaster [Page 32] Internet Draft Chassis MIB October 1992 -- the chasEnviron (Environment) group -- Implementation of this group is optional. -- the Environment table. 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." ::= { chasEnviron 1 } chasEnvironEntry OBJECT-TYPE SYNTAX ChasEnvironEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Values for a environmental sensor." INDEX { chasEnvironIndex } ::= { chasEnvironTable 1 } ChasEnvironEntry ::= SEQUENCE { chasEnvironSensor AutonomousType, chasEnvironStatus INTEGER, chasEnvironWarnings Counter, chasEnvironFailures Counter } chasEnvironSensor OBJECT-TYPE SYNTAX AutonomousType ACCESS read-only STATUS mandatory DESCRIPTION "The identification of an environmental sensor. Other AutonomousType values may be defined elsewhere, in association with specific protocols. However, this document assigns those of known interest as of this McCloghrie/Arneson/Kaycee/Stewart/McMaster [Page 33] Internet Draft Chassis MIB October 1992 writing." ::= { chasEnvironEntry 1 } 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 2 } chasEnvironWarnings OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of times chasEnvironStatus has gone to warning(3)." ::= { chasEnvironEntry 3 } chasEnvironFailures OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of times chasEnvironStatus has gone to bad(2)." ::= { chasEnvironEntry 4 } McCloghrie/Arneson/Kaycee/Stewart/McMaster [Page 34] Internet Draft Chassis MIB October 1992 -- Chassis MIB Well known type object identifiers -- Slot module types chasKnownModules OBJECT IDENTIFIER ::= { chasKnownTypes 1 } chasSlotEmpty OBJECT IDENTIFIER ::= { chasKnownModules 1 } chasSlotUnknown OBJECT IDENTIFIER ::= { chasKnownModules 2 } -- Entity party types chasKnownParty OBJECT IDENTIFIER ::= { chasKnownTypes 2 } chasEntityNoParty OBJECT IDENTIFIER ::= { chasKnownParty 1 } -- Well known segment types chasSegmentTypes OBJECT IDENTIFIER ::= { chasKnownTypes 3 } chasSegmentUnknown OBJECT IDENTIFIER ::= { chasSegmentTypes 1 } -- Configuration known types chasConfigTypes OBJECT IDENTIFIER ::= { chasKnownTypes 4 } chasTypeUnknown OBJECT IDENTIFIER ::= { chasConfigTypes 1 } chasConfigIndexTypeUnknown OBJECT IDENTIFIER ::= { chasConfigTypes 2 } -- Well known environmental sensor types wellKnownSensors OBJECT IDENTIFIER ::= { chasKnownTypes 5 } sensorOther OBJECT IDENTIFIER ::= { wellKnownSensors 1 } sensorTemperature OBJECT IDENTIFIER ::= { wellKnownSensors 2 } sensorFans OBJECT IDENTIFIER ::= { wellKnownSensors 3 } sensorHumidity OBJECT IDENTIFIER ::= { wellKnownSensors 4 } END McCloghrie/Arneson/Kaycee/Stewart/McMaster [Page 35] Internet Draft Chassis MIB October 1992 7. References [1] M.T. Rose and K. McCloghrie, Structure and Identification of Management Information for TCP/IP-based internets, Internet Working Group Request for Comments 1155. Network Information Center, SRI International, Menlo Park, California, (May, 1990). [2] J.D. Case, M.S. Fedor, M.L. Schoffstall, and J.R. Davin, Simple Network Management Protocol, Internet Working Group Request for Comments 1157. Network Information Center, SRI International, Menlo Park, California, (May, 1990). [3] K. McCloghrie and M.T. Rose (editors), Management Information Base for Network Management of TCP/IP-based internets: MIB-II, Internet Working Group Request for Comments 1213. Network Information Center, SRI International, Menlo Park, California, (March, 1991). [4] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization. International Standard 8824, (December, 1987). [5] Information processing systems - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Notation One (ASN.1), International Organization for Standardization. International Standard 8825, (December, 1987). [6] M.T. Rose, K. McCloghrie (editors), Concise MIB Definitions, Internet Working Group Request for Comments 1212. Network Information Center, SRI International, Menlo Park, California, (March, 1991). [7] K. McCloghrie, J. Davin, J. Galvin, Definitions of Managed Objects for Adminstration of SNMP Parties Internet Working Group Request for Comments 1353. Network Information Center, SRI International, Menlo Park, California, (July, 1992). McCloghrie/Arneson/Kaycee/Stewart/McMaster [Page 36] Internet Draft Chassis MIB October 1992 Table of Contents 1 Abstract .............................................. 1 2 Status of this Memo ................................... 2 3 Management Framework .................................. 2 4 Objects ............................................... 3 4.1 Format of Definitions ............................... 3 5 Overview .............................................. 4 5.1 Example Chassis ..................................... 4 5.2 The Slot Group ...................................... 5 5.3 The Entity Group .................................... 5 5.4 The Segment Group ................................... 5 5.5 The Chassis Configuration Group ..................... 6 5.6 The Power Supply Group .............................. 6 5.7 The Environment Group ............................... 7 5.8 What is a Chassis ................................... 7 5.9 Multiple Instantiations ............................. 8 6 Definitions ........................................... 8 7 References ............................................ 36 McCloghrie/Arneson/Kaycee/Stewart/McMaster [Page 37]
- Chassis MIB Draft David Arneson
- Re: Chassis MIB Draft Dave Minnich
- Chassis MIB Draft David Arneson
- Chassis MIB Draft David L. Arneson (arneson@ctron.com)
- Re: Chassis MIB Draft Bob Stewart