Issues and Next draft
"David L. Arneson (arneson@ctron.com)" <arneson@yeti.ctron.com> Wed, 09 September 1992 17:14 UTC
Return-Path: <owner-chassismib>
Received: by CS.UTK.EDU (5.61++/2.8s-UTK) id AA04411; Wed, 9 Sep 92 13:14:26 -0400
Received: from nic.near.net by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA04407; Wed, 9 Sep 92 13:14:16 -0400
Received: from ctron.com by nic.near.net id aa28582; 9 Sep 92 13:13 EDT
Received: from yeti.ctron ([134.141.40.159]) by ctron.com (4.1/SMI-4.1) id AA18344; Wed, 9 Sep 92 13:20:48 EDT
Received: by yeti.ctron (4.1/SMI-4.1) id AA03571; Wed, 9 Sep 92 13:13:00 EDT
Message-Id: <9209091713.AA03571@yeti.ctron>
To: chassismib@cs.utk.edu
Subject: Issues and Next draft
Reply-To: arneson@ctron.com
Date: Wed, 09 Sep 1992 13:12:48 -0400
From: "David L. Arneson (arneson@ctron.com)" <arneson@yeti.ctron.com>
I just want to take a moment and clean up loose ends. I going to be out of
the office for the next few days. So I wanted to get the next draft out to
you and put my 2 cents worth in on the current issues.
1. Interface mapping, I like Keith's idea of index type and feel that this
would make a fine addition as far as it goes. However I feel that it is
important that we try to present a logical to physical mapping of the
interfaces present in the chassis. This is what the table I suggested
would provide. It seems that this still needs to be indexed by
entity, segment, and interface. I don't belive that the interface
objects in the config table would answer that question. Enough said by
me on that subject I will shut up now and add what ever the group belives
is correct.
2. chasUpTime, we may have reached agreement on this. I feel that it is
important that we view the chassis MIB as being realized by a single entity.
Now your implementation may define this as being distributed then you may
wish to implement a chasUpTime on your own and base times from there.
3. The latest draft. I have made several editoral changes as suggested by
Keith. I present it to you for comment. When I come back I will make
the changes that are suggested and issue the document as an Internet
draft.
-------------------------------------------------------------------
Internet Draft Chassis MIB July 1992
Definitions of Managed Objects for a Chassis
Containing Multiple Logical Network Devices
21 July 12:11 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
Cabletron Systems, Inc.
kaycee@ctron.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 July 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 July 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 July 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.
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
sparse.
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.
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.
McCloghrie/Arneson/McMaster/Kaycee [Page 4]
Internet Draft Chassis MIB July 1992
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.
It is an implementation specific matter wether the
chasConfigTable is implemented as read-write or read-only.
McCloghrie/Arneson/McMaster/Kaycee [Page 5]
Internet Draft Chassis MIB July 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 xx }
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 a 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 6]
Internet Draft Chassis MIB July 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 7]
Internet Draft Chassis MIB July 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 MIB) at which a module in this
slot 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 vendor's 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 a NULL
string."
::= { chasSlotEntry 5 }
McCloghrie/Arneson/McMaster/Kaycee [Page 8]
Internet Draft Chassis MIB July 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 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 9]
Internet Draft Chassis MIB July 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,
chasEntityName
DisplayString,
chasEntityVersion
DisplayString,
chasEntityAdminStatus
INTEGER,
chasEntityOperStatus
INTEGER,
chasEntityArgument
OCTET STRING,
chasEntityTimeStamp
TimeTicks,
chasEntityParty
Party,
chasEntityCommunity
OCTET STRING,
McCloghrie/Arneson/McMaster/Kaycee [Page 10]
Internet Draft Chassis MIB July 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
rmon 9
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 11]
Internet Draft Chassis MIB July 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
sysObjectDescr. 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 sysObjectDescr."
::= { 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 12]
Internet Draft Chassis MIB July 1992
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Provides the 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.
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
with no errors or warnings. State
McCloghrie/Arneson/McMaster/Kaycee [Page 13]
Internet Draft Chassis MIB July 1992
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(32))
ACCESS read-write
STATUS mandatory
DESCRIPTION
"A variable that may be passed to an entity. The
value maybe passed upon 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
access its MIB view, and whether or not proxy is
performed. In order for a SNMP manager to be able
McCloghrie/Arneson/McMaster/Kaycee [Page 14]
Internet Draft Chassis MIB July 1992
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 15]
Internet Draft Chassis MIB July 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 each 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 16]
Internet Draft Chassis MIB July 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 17]
Internet Draft Chassis MIB July 1992
chasType OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Identifies the type of hub-based or standalone
device. A vendor's authoritative identification
of this chassis or device. 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
OBJECT IDENTIFIER { 0 0 }, which is a
syntactically valid object identifier."
::= { chasConfig 1 }
chasPhysicalChanges OBJECT-TYPE
SYNTAX Counterr
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
vendor 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
McCloghrie/Arneson/McMaster/Kaycee [Page 18]
Internet Draft Chassis MIB July 1992
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
}
chasConfigSlot OBJECT-TYPE
SYNTAX INTEGER (1..65535)
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The slot number of the chassis for this
configuration relationship."
::= { chasConfigEntry 1 }
McCloghrie/Arneson/McMaster/Kaycee [Page 19]
Internet Draft Chassis MIB July 1992
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
of this object.
It is an implementation-specific matter as to
McCloghrie/Arneson/McMaster/Kaycee [Page 20]
Internet Draft Chassis MIB July 1992
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 }
END
McCloghrie/Arneson/McMaster/Kaycee [Page 21]
Internet Draft Chassis MIB July 1992
7. Issues
Some question has been raised about the implementation of the
chasEntityAdminStatus, specifically the reset value. Should
this be included in the MIB?
There has been some discussion between the authors on the need
for including the relationship (if any) between segments and
interfaces within the chasConfigTable. If such a relationship
is required should it be defined by including an additional
object to the table as follows:
chasConfigIfIndex OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The value of the instance of the ifIndex object,
defined in [3], for the interface corresponding to
this segment connection.
For segment-connections which do not correspond to
interfaces or for which the interface index is
unknown, this object has the value zero."
::= { chasConfigEntry 5 }
8. 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
McCloghrie/Arneson/McMaster/Kaycee [Page 22]
Internet Draft Chassis MIB July 1992
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).
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 23]
Internet Draft Chassis MIB July 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 .................................... 4
5.3 The Segment Table ................................... 4
5.4 The Chassis Configuration Table ..................... 5
6 Definitions ........................................... 6
7 Issues ................................................ 22
8 References ............................................ 22
McCloghrie/Arneson/McMaster/Kaycee [Page 24]
/David Arneson [arneson@ctron.com] [ (603)332-9400 ]
- Issues and Next draft David L. Arneson (arneson@ctron.com)
- Re: Issues and Next draft Manu Kaycee
- Issues and Next draft Dan Romascanu
- Re: Issues and Next draft CASE