A new and improved chasiss MIB
"David L. Arneson (arneson@ctron.com)" <arneson@yeti.ctron.com> Tue, 13 October 1992 14:32 UTC
Return-Path: <owner-chassismib>
Received: by CS.UTK.EDU (5.61++/2.8s-UTK) id AA18867; Tue, 13 Oct 92 10:32:14 -0400
Received: from nic.near.net by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA18863; Tue, 13 Oct 92 10:32:01 -0400
Received: from ctron.com by nic.near.net id aa22548; 13 Oct 92 10:31 EDT
Received: from yeti.ctron ([134.141.40.159]) by ctron.com (4.1/SMI-4.1) id AA00538; Tue, 13 Oct 92 10:31:50 EDT
Received: by yeti.ctron (4.1/SMI-4.1) id AA13333; Tue, 13 Oct 92 10:02:02 EDT
Message-Id: <9210131402.AA13333@yeti.ctron>
To: chassismib@cs.utk.edu
Subject: A new and improved chasiss MIB
Reply-To: arneson@ctron.com
Date: Tue, 13 Oct 1992 10:01:06 -0400
From: "David L. Arneson (arneson@ctron.com)" <arneson@yeti.ctron.com>
We have yet another chassis MIB for your review. I have added alot of text to the Overview section including an example. Perhaps this will clarify many of the questions that have been raised. As I remember we need to add the powersupply MIB to this document. This will happen in the near future. However I wanted to get this out to the working group for review as soon as possible. /David Arneson [arneson@ctron.com] [ (603)332-9400 ] Internet Draft Chassis MIB October 1992 Definitions of Managed Objects for a Chassis Containing Multiple Logical Network Devices October 13, 1992 Keith McCloghrie Hughes LAN Systems, Inc. kzm@hls.com David Arneson Cabletron Systems, Inc. arneson@ctron.com Donna McMaster SynOptics Inc mcmaster@synoptics.com Manu Kaycee Ungermann-Bass, Inc kaycee@andr.UB.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. 2. Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force McCloghrie/Arneson/McMaster/Kaycee [Page 1] Internet Draft Chassis MIB October 1992 (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 Keith McCloghrie (kzm@hls.com) and David Arneson (arneson@ctron.com) 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. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. McCloghrie/Arneson/McMaster/Kaycee [Page 2] Internet Draft Chassis MIB October 1992 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/McMaster/Kaycee [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 four tables: the Slot Table, the Entity Table, the Segment Table, and the Chassis Configuration Table. The remainder of this section will discuss the contents of these tables. In an effort to clarify the contents of the 4 tables the following example is presented. The discussion of each table 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 5.1. The Slot Table A table that contains information about the slots in this chassis. This table may be implemented as either dense or McCloghrie/Arneson/McMaster/Kaycee [Page 4] Internet Draft Chassis MIB October 1992 sparse. As presented in the above example 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.2. The Entity Table 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. Using the above example 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.3. The Segment Table A table that contains information about the network segments, contained within the chassis, and used to interconnect the chassis's logical networking devices. Using the above example this table would contain 2 conceptual rows one for each segment. 5.4. The Chassis Configuration Table 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 McCloghrie/Arneson/McMaster/Kaycee [Page 5] Internet Draft Chassis MIB October 1992 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 wether the chasConfigTable is implemented as read-write or read-only. Using the above example 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.5. 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 McCloghrie/Arneson/McMaster/Kaycee [Page 6] Internet Draft Chassis MIB October 1992 MIBs for each shelf in which each slot represents where the plug-in cards live. 5.6. Multiple Instanciations For each (logical or physical) chassis, it is possible to have multiple agents implement this MIB for the same chassis. However, there is no requirement to have more than one agent per chassis 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). McCloghrie/Arneson/McMaster/Kaycee [Page 7] Internet Draft Chassis MIB October 1992 6. Definitions CHASSIS-MIB DEFINITIONS ::= BEGIN IMPORTS experimental, TimeTicks, IpAddress FROM RFC1155-SMI Party FROM RFC1353-MIB -- SNMP Party MIB OBJECT-TYPE FROM RFC-1212; chassis OBJECT IDENTIFIER ::= { experimental 38 } chasSlot OBJECT IDENTIFIER ::= { chassis 1 } chasEntity OBJECT IDENTIFIER ::= { chassis 2 } chasSegment OBJECT IDENTIFIER ::= { chassis 3 } chasConfig OBJECT IDENTIFIER ::= { chassis 4 } -- the chassisBase group -- Implementation of the chassisBase group is mandatory. chasNumSlots OBJECT-TYPE SYNTAX INTEGER (0..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 McCloghrie/Arneson/McMaster/Kaycee [Page 8] Internet Draft Chassis MIB October 1992 STATUS mandatory DESCRIPTION "A table that contains information about the slots in this chassis." ::= { chasSlot 2 } chasSlotEntry OBJECT-TYPE SYNTAX ChasSlotEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A list of information for each slot in the chassis." 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 STATUS mandatory McCloghrie/Arneson/McMaster/Kaycee [Page 9] Internet Draft Chassis MIB October 1992 DESCRIPTION "The type of module plugged into 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 } chasSlotEmpty OBJECT IDENTIFIER ::= { chasSlot 3 } chasSlotUnknown OBJECT IDENTIFIER ::= { chasSlot 4 } 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..32)) 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/McMaster/Kaycee [Page 10] 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/McMaster/Kaycee [Page 11] Internet Draft Chassis MIB October 1992 -- The 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 in this chassis." ::= { chasEntity 1 } chasEntityEntry OBJECT-TYPE SYNTAX ChasEntityEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Information concerning a logical networking device in the chassis." 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 TimeTicks, chasEntityParty Party, chasEntityCommunity OCTET STRING, McCloghrie/Arneson/McMaster/Kaycee [Page 12] Internet Draft Chassis MIB October 1992 chasEntityIpAddress IpAddress } chasEntityIndex OBJECT-TYPE SYNTAX INTEGER (1..65535) ACCESS read-only STATUS mandatory DESCRIPTION "A unique index for the logical networking device 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 logical networking device. 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 + 2^3)." ::= { chasEntityEntry 2 } chasEntityObjectId OBJECT-TYPE McCloghrie/Arneson/McMaster/Kaycee [Page 13] Internet Draft Chassis MIB October 1992 SYNTAX OBJECT IDENTIFIER ACCESS read-only STATUS mandatory DESCRIPTION "The specific type of logical networking device. 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..32)) 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 enable(2), disable(3), reset(4), programload(5) McCloghrie/Arneson/McMaster/Kaycee [Page 14] Internet Draft Chassis MIB October 1992 } ACCESS read-write STATUS mandatory DESCRIPTION "Provides the administratively desired state of the given entity. A entity is activated by writing a value of enable(2). The 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 programload(5) specifies the entity should initiate a program load 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), nonFatalError(7), fatalError(8), loading(10) } ACCESS read-only STATUS mandatory DESCRIPTION "Provides operational status of the entity. A value of other(1) has 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 McCloghrie/Arneson/McMaster/Kaycee [Page 15] Internet Draft Chassis MIB October 1992 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." ::= { 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 transitions of chasEntityOperStatus from disable to enable However, exact usage is implementation specific." ::= { chasEntityEntry 8 } 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 McCloghrie/Arneson/McMaster/Kaycee [Page 16] Internet Draft Chassis MIB October 1992 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 } chasEntityNoParty OBJECT IDENTIFIER ::= { chasEntity 2 } 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. 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/McMaster/Kaycee [Page 17] Internet Draft Chassis MIB October 1992 -- 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 ACCESS read-only STATUS mandatory DESCRIPTION McCloghrie/Arneson/McMaster/Kaycee [Page 18] Internet Draft Chassis MIB October 1992 "The type of segment. For example, for an Ethernet segment this object would have the value: dot3 as defined in RFC 1284." ::= { chasSegmentEntry 2 } McCloghrie/Arneson/McMaster/Kaycee [Page 19] Internet Draft Chassis MIB October 1992 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 } chasTypeUnknown OBJECT IDENTIFIER ::= { chasConfig 5 } chasPhysicalChanges OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of physical changes that have occurred in the chassis. 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 ACCESS not-accessible STATUS mandatory McCloghrie/Arneson/McMaster/Kaycee [Page 20] Internet Draft Chassis MIB October 1992 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 INTEGER, chasConfigIndexValue INTEGER } chasConfigSlot OBJECT-TYPE SYNTAX INTEGER (1..65535) ACCESS read-write STATUS mandatory DESCRIPTION "The slot number of the chassis for this McCloghrie/Arneson/McMaster/Kaycee [Page 21] Internet Draft Chassis MIB October 1992 configuration relationship." ::= { chasConfigEntry 1 } chasConfigEntity OBJECT-TYPE SYNTAX INTEGER (0..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 (invalidation) of instances may have the implicit side-effect of removing (creating) other instances McCloghrie/Arneson/McMaster/Kaycee [Page 22] Internet Draft Chassis MIB October 1992 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 INTEGER 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 } chasConfigIndexTypeUnknown OBJECT IDENTIFIER ::= { chasConfig 6 } chasConfigIndexValue OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION McCloghrie/Arneson/McMaster/Kaycee [Page 23] 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 } END McCloghrie/Arneson/McMaster/Kaycee [Page 24] 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/McMaster/Kaycee [Page 25] Internet Draft Chassis MIB October 1992 Table of Contents 1 Abstract .............................................. 1 2 Status of this Memo ................................... 1 3 Management Framework .................................. 2 4 Objects ............................................... 3 4.1 Format of Definitions ............................... 3 5 Overview .............................................. 4 5.1 The Slot Table ...................................... 4 5.2 The Entity Table .................................... 5 5.3 The Segment Table ................................... 5 5.4 The Chassis Configuration Table ..................... 5 5.5 What is a Chassis ................................... 6 5.6 Multiple Instanciations ............................. 7 6 Definitions ........................................... 8 7 References ............................................ 25 McCloghrie/Arneson/McMaster/Kaycee [Page 26]
- A new and improved chasiss MIB David L. Arneson (arneson@ctron.com)