[peterw@pdd.3com.com: Chassis MIB Proposal]

Bob Stewart <rlstewart@eng.xyplex.com> Fri, 11 December 1992 15:34 UTC

Return-Path: <owner-chassismib>
Received: by CS.UTK.EDU (5.61++/2.8s-UTK) id AA14467; Fri, 11 Dec 92 10:34:28 -0500
Received: from xap.xyplex.com by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA14438; Fri, 11 Dec 92 10:33:31 -0500
Received: by xap.xyplex.com id <AA25895@xap.xyplex.com>; Fri, 11 Dec 92 11:06:47 -0500
Date: Fri, 11 Dec 1992 11:06:47 -0500
Message-Id: <9212111606.AA25895@xap.xyplex.com>
From: Bob Stewart <rlstewart@eng.xyplex.com>
To: chassismib@cs.utk.edu
Subject: [peterw@pdd.3com.com: Chassis MIB Proposal]


From: peterw@pdd.3com.com
Date: Fri, 11 Dec 92 15:26:48 GMT
To: rlstewart@eng.xyplex.com
Subject: Chassis MIB Proposal

Bob, Thanks for your 'ack' to my mail. A favour in your role as chassis MIB
chair! A short time ago I sent a 3 part chassis MIB proposal to the group.
I've tried a number times from various systems. Most I think didn't arrive, the
ones that did were corrupted. I've now got a Unix account but I get an
error message every time I try to send to chassismib@cs.utk.edu. Our MIS
people are looking into this. I've included the proposal below in a 1 part.
If you could forward this to the group I'd much appreciate it.

thanks in anticipation
Pete

                  Definitions of Managed Objects for a Chassis
                   Containing Multiple Logical Network Devices

                                November 24, 1992


			Proposal By: Peter Wilson
			  Peter_Wilson@3Com.com

Introduction
============

At the IETF meeting in Washington the definition of a chassis was discussed.
It seemed that between those present there was some ambiguity about what we
wanted the model to look like. Following on from that discussion it was
proposed that the chassis MIB become somewhat more generic. My aims in this
proposal are as follows:

1) To produce a more generic MIB. By this I want to get away from the idea
that a chassis contains slots, entities and segments. slots and segments are
somewhat implementation specific concepts. Segments may not even exist in
some network chassis implementations.

2) Reduce the complexity of relationships between parts of the MIB. The
current MIB defines a table of relationships between an entity, a slot and a
segment. From that model its unclear what relationships could exist and how
the configuration can be changed. From the application point of view
configuration of the device could be very difficult without having explicit
knowledge of each chassis.

3) Produce a MIB that provides good information for a generic chassis
management application, even if a particular chassis does not contain
knowledge of all the various things contained in that chassis. 

4) Make visible the components that make up a physical entity. In the
current proposal this information is implicit in the relationship table.
One does not know from the MIB what logical components are available on a
card. To change a relationship involves destroying that relationship and
creating another. There is no continuity between the various operations
and one has no way of identifying the component of a module being used
in an entity.

5) Move towards SNMPv2 (still a good way to go!)

This proposal needs specific MIB definitions to be added (moved from existing
proposal) to describe power supplies sensors etc.

The Model
=========

A chassis is a generic 'container'. It can be any shape and size and can
have any position.  Examples of things that constitute chassis are the
traditional network hub, PABX as well as less common items such as a room,
building, campus etc. One chassis can recursively contain other chassis, eg
a building could contain some rooms which in turn contain cabinets that
contain network hubs. 

There are two views of a chassis. Firstly the physical view. The physical
view considers the chassis to comprise a number of different types of
compartment. Each type of compartment is specialised to hold a particular
type of item or module.  Examples of compartment types would be corridors,
rooms, elevator shafts, network card slots and power supply bays. At any
instant in time each of these compartments may be occupied or empty. 

Secondly there is the logical or functional view.  In this view the chassis
is considered to contain a number of 'entities'.  Each entity provides some
function. Examples of entities would be company projects and Network
Repeaters.

An entity is implemented using parts from one or more physical modules. It
is necessary to describe the relationship between physical module and
logical entity. For the purposes of this relationship a physical module is
considered to comprise a number of logical components (resources?). A number
of logical components are joined together to construct an entity.

To illustrate these concepts consider a company to be the chassis. In this
example the physical modules are floors of a building and the logical
entities projects. Each floor comprises a number of people which are the
components from which project teams are constructed. Each person is
specialised for a particular role within a project. 

Floor		Function:Person	Project		Implemented By
(module)	(component)	(entity)	(relationship)
--------			-------		--------------
1 -	Marketing:Pete		xyz-thing	Marketing:Pete
	Marketing:Jeff				Development:Mike
	Development:Mike			Manufacturing:Dave
	Manufacturing:Alan
				abc-thing	Marketing:Jeff
2 -	Marketing:Jane				Development:Sharon
	Development:Sharon			Development:Michele
	Manufacturing:Dave			Manufacturing:Alan

3-	Development:Michele
	Marketing:Paul
	Development:James
	
Analysis of this example provide some interesting relationships that apply
equally to a network type device: 

1) Each physical entity comprises a number of logical components that
   can be used in the construction of an entity.
2) A logical component of one type may be substituted for a different
   component of the same type in a logical entity. eg James may be
   substituted for Mike but not for Jeff.
3) It is possible that at some time not all components are part of entities.
   It is however necessary to know all components that exist and the current
   use or otherwise of those components.

Having looked at a generic example consider a practical example of a chassis
that contains modules for the token ring and Ethernet. In this example
assume that each Ethernet and each Token Ring card contain 4 ports. There
currently exist 4 entities in the chassis, two Ethernet repeaters and 2
Token Rings. The chassis contains 4 locations that can contain modules and
the configuration is as follows:

Slot Number	Contains
    1		Ethernet Repeater Card
    2		802.5 Port Card
    3		Ethernet Repeater Card
    4		802.5 Port Card

The logical configuration of the chassis at a particular time is as follows:

Entity		Implemented By
------		--------------
Repeater 1	Module 1, Port 1, 2, 3
		Module 3, Port 2
Repeater 2	Module 1, Port 4
		Module 3, Port 1, 3
Token Ring 1	Module 2, Port 1, 2
Token Ring 2	Module 2, Port 3
		Module 4, Port 3
----------------------------------------
Module 2, Port 4		- Not currently used
Module 3, Port 4		-  "      "      "
Module 4, Port 1, 2, 4		-  "      "      "

Note that a MIB to represent and configure devices such as this must make
all components of all cards visible and allow the configuration of those
components into entities.

Now suppose that an operator needs an additional Ethernet repeater.
In order to do this a new Repeater entity is created and some of the
repeater ports are assigned to that entity. eg:

	create Repeater 3
	assign Module 3, Port 4 to Repeater 3 -- Currently unassigned
	assign Module 3, Port 1 to Repeater 3 -- Moved from Repeater 2

>> NOTE
>> ====
>> This model does not use the concept of Segment as currently specified
>> in the chassis MIB draft. There are a number of reasons for this:
>> 
>> 1) Segment is an implementation specific concept closely allied with
>> the idea of a dedicated backplane. A number of chassis implementations
>> do not physically have this concept/restriction.
>> 
>> 2) There is no analogous concept to segment in other types of chassis,
>> for example a building or company. 
>> 
>> 3) The 3 way mapping of module, entity and segment is complex and
>> difficult to implement in such a way that all information is
>> visible. In this model the three way module/entity/segment relationship
>> is replaced with a simpler two way component/entity relationship.
>>
>> There are a number of ways to achieve the same ends using this model.
>> Such implementations are described below:

Combining Components into Entities (Network Chassis)
==================================
1. Implicit Assignment
----------------------
This strategy requires the most effort from the chassis agent but
provides the best and easiest model for both the application writer
and the best abstraction for the user. It is applicable to both
chassis that use a hardwired backplane and those that use central or
distributed switching services to implement functions.

The chassis is required to implement a number of entities. The number
and type of entity implemented by a particular chassis depends on the
physical capabilities and design of that chassis. For example one
chassis may be designed with 3 Ethernet type busses on a backplane. In
this chassis it is possible to create 3 repeaters that use components
from more than one physical module. The chassis may also be capable of
implementing a number of additional repeaters provided only components
on the same card are used.

Implicit assignment says that the chassis is required to marshal
its inherent resources to best meet the requested configuration of the
manager. The managers requests are communicated by the creation and
destruction of entities and by the assignment of components to
entities. In the example of a chassis with 2 Ethernet backplanes the
stragtegy of the agent could be as follows:

manager			agent
-----------------------------------------------------------------
create Repeater		record repeaters existence
assign Mod 1, Port 1	add component to repeater, don't need a 
	to repeater	backplane yet!
assign Mod 1, Port 2	add component to repeater, don't need a 
	to repeater	backplane yet!
assign Mod 2, Port 1	Repeater crosses card boundaries so find a
			spare backplane and assign that to this
			repeater. Note that if there are no spare
			backplanes then the assignment is rejected.

Note that this approach makes repeater implementation transparent to a user.
The model is identical regardless of whether the chassis uses backplanes,
has central/distributed switching or any other implementation strategy. 

2. Explicit Assignment
----------------------
This is a more manual approach. The effort required in the agent is
potentially somewhat less but the savings are really nominal. In this model
the manager is responsible for assigning backplanes.

A backplane is simply a physical module in the same way that a repeater card
is a module. Because it is a module it also has logical components that can 
be assigned to entities. Now consider the same example of a repeater chassis
with 2 backplanes. The example is the same as above: Create a repeater and
assign a number of repeater ports to that repeater:

manager			agent
-----------------------------------------------------------------
create Repeater		record repeaters existence
assign Mod 1, Port 1	add component to repeater, don't need a 
	to repeater	backplane yet!
assign Mod 1, Port 2	add component to repeater, don't need a 
	to repeater	backplane yet!
assign Mod 2, Port 1	Request rejected. There is no assigned connection
			path to allow ports on different cards to be
			assigned to the same repeater.
assign Ether B'plane	Repeater can now span cards.
	1 to repeater
assign Mod 2, Port 1	Request successful.

NOTE: Variations on this theme are possible but the idea remains the same.
For example one could statically create 2 repeaters that always exist to
represent the two backplanes. Ports could be assigned to those repeaters.
Additional repeaters could be created but would not be allowed to span
cards. In a particular chassis there will also be a number of fixed entities
that always exist, although the components assigned to that entity may
differ.
----------------------------------------------------------------------
chasEntity		OBJECT IDENTIFIER ::= { chassis  2 }
chasConfig		OBJECT IDENTIFIER ::= { chassis  4 }
chasKnownTypes		OBJECT IDENTIFIER ::= { chassis  7 }
chasPhysical		OBJECT IDENTIFIER ::= { chassis  8 }
chasComponent		OBJECT IDENTIFIER ::= { chassis  9 }
chasKnownLocations	OBJECT IDENTIFIER ::= { chassis 10 }

phyLocationTable OBJECT-TYPE
	SYNTAX	SEQUENCE OF PhyLocationEntry
	ACCESS	not-accessible
	STATUS	mandatory
	DESCRIPTION "
A chassis comprises a number of modular locations. There are a number
of different types of location. For example there are locations that
can contain power supplies, others that contain fans and yet others
that can contain modular network cards. Further types can be defines.
For example the chassis MIB may be used to describe a building where
the locations are rooms, corridors, elevators etc.

This table summarises the different classes of location and the number
of occurrances of each type in the chassis. This table is indexed on
an integer that locally identifies the location type. Informational
columns identify each of the types uniquely by an object identifier."
	::= { chasPhysical 1 }

phyLocationEntry OBJECT-TYPE
	SYNTAX	PhyLocationEntry
	ACCESS	not-accessible
	STATUS	mandatory
	DESCRIPTION "
An entry in this table describes a type of location. For example a
network slot, power-supply bay etc"
	INDEX	{ locationTypeIndex }
	::= { phyLocationTable 1 }

PhyLocationEntry ::= SEQUENCE {
	locationTypeIndex	INTEGER,
	locationType		OBJECT IDENTIFIER,
	locationCount		INTEGER,
	locationName		DisplayString
}

locationTypeIndex OBJECT-TYPE
	SYNTAX			INTEGER ( 1..65535 )
	ACCESS			not-accessible
	STATUS			mandatory
	DESCRIPTION "
This is a simple index into this table and one of the indices into the
physical configuration table. One can traverse this table and
determine all the types of 'slot' that exist within this chassis."
	::= { phyLocationEntry 1 }

locationType OBJECT-TYPE
	SYNTAX			OBJECT IDENTIFIER
	ACCESS			read-only
	STATUS			mandatory
	DESCRIPTION "
This column uniquely identifies the 'type' of the slot. A number of
defined values exists, namely
	networkDeviceSlot
	powerSupplyBay
	fanPosition
	backplanePosition
other types can be added on a vendor specific basis."
	::= { phyLocationEntry 2 }

locationCount OBJECT-TYPE
	SYNTAX			INTEGER ( 1..65535 )
	ACCESS			read-only
	STATUS			mandatory
	DESCRIPTION "
This object identifies the number of instances of this location that
exist within this chassis. For example if there were a chassis that
had 10 slots availble for network devices then the value of this
column would be 10."
	::= { phyLocationEntry 3 }

locationName OBJECT-TYPE
	SYNTAX			DisplayString
	ACCESS			read-only
	STATUS			mandatory
	DESCRIPTION "
Each type of location in the chassis is given a textual name. This is
very useful for an application that knows how to deal with generically
defined locations suh as those defined within this MIB, but that are
only capable of dealing with other types as 'unknown'. In this case
the name string can be used to at least sensibly describe the location
to the user."
	::= { phyLocationEntry 4 }

--
phyConfigTable OBJECT-TYPE
	SYNTAX	SEQUENCE OF PhyConfigEntry
	ACCESS	not-accessible
	STATUS	mandatory
	DESCRIPTION "
This table identifies the current configuration of the chassis. The
physical configuration is defined in terms of physical items that reside at
certain physical locations in the chassis. A physical location is
described by a location type and a location. For example a location
type may be a power supply bay and the location is 1 indicating power
supply bay number 1. Note that this table is indexed on locationTypeIndex
and phyLocation. locationIndex is borrowed (shared with) from the 
phyLocationTable

Note that the table only contains information about locations that are
currently occupied by some entity."
	::= { chasPhysical 2 }

phyConfigEntry OBJECT-TYPE
	SYNTAX		PhyConfigEntry
	ACCESS		not-accessible
	STATUS		mandatory
	DESCRIPTION	"
An entry in this table describes the contents of a populated 'slot'
within the chassis. For example a particular row may contain an entry
for a power support in a particular power supply bay or could
describe a network card in a particular card slot."
	INDEX		{locationTypeIndex, phyLocation}
	::= { phyConfigTable 1 }

PhyConfigEntry ::= SEQUENCE {
	phyLocation		INTEGER,
	phyContentsObject	OBJECT IDENTIFIER,
	phySwVersion		DisplayString,
	phyHwVersion		DisplayString,
	phySerialNumber		DisplayString,
	phyDescription		DisplayString,
	phyLastChangeTime	TimeTicks,
	phyAdminStatus		INTEGER,
	phyOperStatus		INTEGER
}

phyLocation	OBJECT-TYPE
	SYNTAX		INTEGER
	ACCESS		not-accessible
	STATUS		mandatory
	DESCRIPTION	"
The location defines which instance of a particular class of locations
is being descibed by this entry. For example if the index for a row is
has locationTypeIndex refering to networkDeviceSlot and phyLocation is
7 then this entry in the table is describing the contents of the
network card in slot 7."
	::= { PhyConfigEntry 1 }

phyContentsObject	OBJECT-TYPE
	SYNTAX		OBJECT IDENTIFIER
	ACCESS		read-only
	STATUS		mandatory
	DESCRIPTION	"
Each physical item contained in the chassis is a stand-alone unit.
This type of that unit is defined through allocation of a product
object id. This column is the object id for the product at the
location described by this entry."
	::= { PhyConfigEntry 2 }

phySwVersion	OBJECT-TYPE
	SYNTAX		DisplayString
	ACCESS		read-only
	STATUS		mandatory
	DESCRIPTION	"
If the physical item described by this entry in the table contains
software then this column provides a string representation of the
version of that software. Not all items contain software. In these cases
this column will contain the NULL string"
	::= { PhyConfigEntry 3 }

phyHwVersion	OBJECT-TYPE
	SYNTAX		DisplayString
	ACCESS		read-only
	STATUS		mandatory
	DESCRIPTION	"
The version number of the hardware described by this entry in the table."
	::= { PhyConfigEntry 4 }

phySerialNumber	OBJECT-TYPE
	SYNTAX		DisplayString
	ACCESS		read-only
	STATUS		mandatory
	DESCRIPTION	"
The serial number of the module represented by this entry in the table."
	::= { PhyConfigEntry 5 }

phyDescription	OBJECT-TYPE
	SYNTAX		DisplayString
	ACCESS		read-only
	STATUS		mandatory
	DESCRIPTION	"
Textual description of this module. Using this string a manager can
describe an entity even if it is unaware of the function of the card.
This can go some way to preventing an update in an application simply
because a new type of card has been introduced, for example a new
repeater card with a different physical interface."
	::= { PhyConfigEntry 6 }

phyLastChangeTime	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 into this slot. If no module
has been inserted into this slot since the system last restarted this
object will have the value 0 (zero)."
	::= { PhyConfigEntry 7 }

phyAdminStatus	OBJECT-TYPE
	SYNTAX		INTEGER {
				enable(2),
				disable(3),
				reset(4),
				test(5)
			}
	ACCESS		read-write
	STATUS		mandatory
	DESCRIPTION	"
Provides the adminstratively desired state of the given module.

A module is enabled by writing the value enable(2).

A module may be deactivated by writing a value of disable(2). In a
disabled state a module does exist within the chassis but is benign. A
disabled module is available for subsequent activation.

Writing a value of reset(4) specifies that the module should initiate a
reset sequence. This value allows a suspect module to be 'kicked' into
a reset state without having to physically walk to the chassis and
perform the reset operation.

Writing a value of test(5) specifies that a module should intiate a
test sequence.

NOTE: Not all of these values need be supported for all modules in the
chassis. There are occassions when allowing certain operations would
compromise the state of the chassis, for example disabling the one and
only power-supply may not be an appropriate action."
	::= { PhyConfigEntry 8 }

phyOperStatus	OBJECT-TYPE
	SYNTAX		INTEGER {
				other(1),
				invalid(2),
				testing(3),
				operational(4),
				resetInProgress(5),
				warning(6),
				nonFatalError(7),
				fatalError(8)
			}
	ACCESS		read-only
	STATUS		mandatory
	DESCRIPTION	"
Provides operational status of the module.  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 phyAdminStatus to a value of
disable(3).  A value of invalid(2) could have the possible meaning that the
module exists but the chassis manager has no direct control over the module.
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 phyAdminStatus 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.  

For example if a modules value of phyAdminStatus is disable(3) and is set to
enable(2) then phyOperStatus may enter a state of testing(3) then change to
a value of operational(4)."
	::= { PhyConfigEntry 9 }

-- The chasEntity group.  Implementation of the chasEntity group
-- is mandatory.

-- Entity Table

chasEntityTable OBJECT-TYPE
    SYNTAX  SEQUENCE OF ChasEntityEntry
    ACCESS  not-accessible
    STATUS  mandatory
    DESCRIPTION
  "A table that contains information about the
  'logical' networking devices (entity) in this
  chassis."
    ::= { chasEntity 1 }

chasEntityEntry OBJECT-TYPE
    SYNTAX  ChasEntityEntry
    ACCESS  not-accessible
    STATUS  mandatory
    DESCRIPTION
  "Information concerning an entity in the chassis. SNMP requests allow
rows to be added and removed from this table. Adding a row to the table
signals the creation of a new logical network device. Removing a row
signals the deletion of a logical network device. Note that some
implementations may required some or all rows in this table to be
read-only through SNMP."
    INDEX  { chasEntityIndex }
    ::= { chasEntityTable 1 }

ChasEntityEntry ::= SEQUENCE {
	chasEntityIndex		INTEGER,
	chasEntityType		OBJECT IDENTIFIER,
	chasEntityDescr		DisplayString,
	chasEntityAdminStatus	INTEGER,
	chasEntityOperStatus	INTEGER,
	chasEntityTimeStamp	TimeTicks,
	chasEntityTargetParty	Party,
	chasEntityCommunity	OCTET STRING,
	chasEntityTDomain	OBJECT IDENTIFIER,
	chasEntityTAddress	TAddress,
	chasEntityRowStatus	RowStatus
}

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
-- REMOVED
-- Note that the bitmap entity function value is not generic and cannot
-- be extended to support new sevices as they become available. The
-- recommended way to determine the function of an entity is to either
-- decode the chasEntityObjectID OR access the entity
-- directly to determine the function of the entity.

chasEntityType  OBJECT-TYPE
    SYNTAX  OBJECT IDENTIFIER
    ACCESS  read-write
    STATUS  mandatory
    DESCRIPTION "
This value identifies the type of the functional entity. This value is
generally read only but may be written when requesting the agent to create a
new entity. Note that not all entities may be created. Some chassis may not
allow any entities to be created!. Standard types are:

	repeater8023	Ethernet Repeater
	tokenRing8025	Token Ring
	fddiRing	FDDI Ring
	bridge		Bridge Entity
	router		Router Entity
	brouter		Bridge/Router Combined Entity
	terminalServer	Terminal Server
	chassis		A contained (nested) chassis
	powerSupply	Power Supply
	networkMonitor	Network Monitoring Device
	chassisFan	Fan Entity
	displayPanel	Display Panel"
    ::= { chasEntityEntry 3 }

chasEntityDescr  OBJECT-TYPE
    SYNTAX  DisplayString (SIZE (0..255))
    ACCESS  read-write
    STATUS  mandatory
    DESCRIPTION
A textual description of the entity. When a new entity is created it will be
given a default description that may subsequently be over written."
    ::= { chasEntityEntry 4 }

-- chasEntityVersion  OBJECT-TYPE
-- REMOVED
-- Because a logical entity can be distributed over parts of a number of
-- physical modules it is not appropriate to have version information
-- about an entity. The version information belongs with the constituent
-- physical parts of the chassis.
--
-- eg a repeater may be constructed from two repeater cards. Card 1
-- is version 1.0 H/W of hardware and version 1.2 S/W. Card 2 is
-- version 1.1 H/W and 2.0 S/W. There is no meaningful way of
-- identifying the version of the entity. It is possible in some systems to
-- identify the version of the agent S/W being used to provide a view
-- of an entity, but this information does not belong in the entity
-- table.

chasEntityAdminStatus OBJECT-TYPE
    SYNTAX  INTEGER {
        unknown(1),   --  none of the following
        enable(2),
        disable(3),
        reset(4),
        test(5)
    }
    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 test(5) 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),
        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
-- REMOVED
-- Too implementation specific. This was decided I believe at the
-- Washington IETF.

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 }

chasEntityTargetParty  OBJECT-TYPE
    SYNTAX  Party
    ACCESS  read-only
    STATUS  mandatory
    DESCRIPTION "
Access to the detailed management information for an entity is provided
using one of a number of techniques. For this object I assume for the
present that the 'Party Reformation Act' is accepted. This area needs to be
revistited if that proposal is rejected.

Firstly the agent providing detailed information for this object may be
running SNMPv1. In this case there is NO target party and this object will
not exist for such a row.

Secondly SNMPv2 is being run on the chassis agent and the entity agent is
co-resident with that agent. In this case the target party defines the party
to be used to access management information about this entity. The party
exists at the same transport address as the chassis agent and so the
entityTAddress object will not exist for this row. Note that the
destination parties define access policy, not the target party so there only
needs to be a single target party for all privileges. To determine which
destination parties provide access to this target interrogate the SNMPv2
aclTable for entries with this party as the same target.

Next the agent for the entity may be entirely at a separate transport
address. If the agent at that address deals directly with this entity then
there will be no target party and so this object will not exist. Access to
the detailed view of the entity is provided in the same way as for a simple
device. The entityTAddress identifies where the agent for the entity
resides.

Finally the agent for the entity is resident at a separate transport
address and the agent at that address actually provides proxy access to the
entity. In this case the entityTAddress provides the address at which to use
this target party."
    ::= { chasEntityEntry 10 }


chasEntityCommunity  OBJECT-TYPE
    SYNTAX  OCTET STRING (SIZE (0..256))
    ACCESS  read-only
    STATUS  mandatory
    DESCRIPTION "
If the agent which implements the detailed view of this agent is resident at
the same transport address as the chassis agent, and the agent is using
SNMPv1, this object provides a community string that must be used to access
the correct view of the MIB. Note that in this model only one view of the
device is provided. There is no provision when using SNMPv1 with this MIB to
define a read-only and a read-write view of the entity!

If a community string is NOT required to access this entity then this object
will not exist for this row of the table."
    ::= { chasEntityEntry 11 }

chasEntityTDomain  OBJECT-TYPE
    SYNTAX  OBJECT IDENTIFIER
    ACCESS  read-only
    STATUS  mandatory
    DESCRIPTION "
If the agent which provides detailed access to the management information
for this entity does not execute at this transport address this object will
exist. If this object exists then it identifies the transport domain in which
the agent for this entity executes. An example of a transport domain is
rfc1351Domain (SNMP over UDP)"
    ::= { chasEntityEntry 12 }

chasEntityTAddress  OBJECT-TYPE
    SYNTAX  IpAddress
    ACCESS  read-only
    STATUS  mandatory
    DESCRIPTION "
If the agent which provides detailed access to the management information
for this entity does not execute at this transport address this object will
exist. If this object exists then it identifies the address at which the
agent exists."
    ::= { chasEntityEntry 13 }

chasEntityRowStatus OBJECT-TYPE
	SYNTAX		RowStatus
	ACCESS		read-write
	STATUS		mandatory
	DESCRIPTION " 
A manager may attempt to create new instances of 'entity' within this
chassis. Depending on the capabilities and design of the chassis none, some
or all types of entity may be created. To attempt to create a new entity the
following procedure should be followed:

	Locate an empty row in the entity table

	Set Row Status for that row to underConstruction
		If this fails then this chassis does not support
		entity creation

	Write the type of the desired entity to chasEntityType

	If this fails then there is insufficient resources available
		to create an entity of that type. For example trying
		to create certain types of entities is likely to
		always fail (ie creating a power supply)

	If this works the row status will automatically change to
		active and the new entity is available for
		the assignment of components.

To delete an entity set the row status to underDestruction. If the entity can
be deleted then the row representing this entity will immediately
dissappear. Note that all components assigned to this entity will become
unassigned and available for use in other entities."
	DEFVAL underCreation
	::= { chasEntityEntry 14 }

--
componentTable OBJECT-TYPE
	SYNTAX	SEQUENCE OF ComponentEntry
	ACCESS	not-accessible
	STATUS	mandatory
	DESCRIPTION "
Each physical module contains a number of logical components. Each logical
component is a building block for constructing functional entities. This
table contains an entry for each component in the chassis, the type of
entity this component can belong to and the current entity to which this
component is assigned."
	::= { chasComponent 1 }

componentEntry OBJECT-TYPE
	SYNTAX		ComponentEntry
	ACCESS		not-accessible
	STATUS		mandatory
	DESCRIPTION	"
This entry describes one logical component in the chassis at a particular
instant. Note that if the physical module on which this component resides is
removed from the chassis then this entry in the table will b destroyed.

Components may not be created or destroyed but can be assigned to different
entities in the system.

Each entry in the table is identified by it physical location (type and
position) and by a component index to distinguish between different
components at the same location. Note that the first two index values are
borrowed from/shared with other tables in this MIB."
	INDEX		{locationTypeIndex, phyLocation, compIndex}
	::= { componentTable 1 }

ComponentTable ::= SEQUENCE {
	compIndex		INTEGER,
	compEntityType		OBJECT IDENTIFIER
	compEntityAssignment	INTEGER
}

compIndex OBJECT-TYPE
	SYNTAX	INTEGER
	ACCESS	not-accessible
	STATUS	mandatory
	DESCRIPTION "
Each physical module in the chassis comprises a number of distinct logical
components. The compIndex allows unique identification of each of the
components within a particular module."
	::= { componentEntry 1 }

compEntityType OBJECT-TYPE
	SYNTAX	OBJECT IDENTIFIER
	ACCESS	read-only
	STATUS	mandatory
	DESCRIPTION "
Each component in a module may be assigned to a particular entity type.
This column defines a single value of chasEntityType. The column basically
gives information to the managemet station to say 'this componnt may only be
assigned to entities with chasEntityType equal to this objects value'. It is
a hint really to the application. The value in this column does not prevent
someone trying to assign, say, an 802.3 repeater port to a token ring entity
but gives advanced information that such a request will fail.

If the agent does not wish to restrict assignment of this component to
entities of a particular type this object should be set to the null object
identifier."
	::= {  componentEntry 2 }

compEntityAssignment OBJECT-TYPE
	SYNTAX	INTEGER
	ACCESS	read-write
	STATUS	mandatory
	DESCRIPTION "
Each component in the current physical configuration of the chassis is
present in this table. Most of those components will be assigned to a
particular entity. This object identifies the current assignment of this
component. The value of this object is the value of chasEntityIndex of the
entity to which this component is currently assigned.

If a component is not currently assigned to an entity this object will have
the value of zero. A manager may write a new entity value to this object. If
the entity accepts assignment of this component then the component is
removed from any old entity and assigned to the new entity.

If an attempt is made to assign this component to an inappropriate entity,
for example an 802.3 repeater port to a token ring entity, that request will
fail and the compEntityAssignment will contain its old value.

If zero is written to this object then that component is removed from its
current assignment and is not assigned to any other entity.

The behaviour of an unassigned component is specific to that implementation.
Examples of valid implementation behaviour would be:

Unassigned repeater component: Do nothing.
Unassigned bridge port: Connect to external port."

	::= {  componentEntry 3 }


-- TRAPs
-- These need to be defined. Use SNMPv1 or SNMPv2?
-- Traps should be generated for the following situations:
-- Module removed from chassis
-- Module added to chassis

repeater8023	OBJECT IDENTIFIER ::= { chasKnownTypes  1 }
tokenRing8025	OBJECT IDENTIFIER ::= { chasKnownTypes  2 }
fddiRing	OBJECT IDENTIFIER ::= { chasKnownTypes  3 }
bridge		OBJECT IDENTIFIER ::= { chasKnownTypes  4 }
router		OBJECT IDENTIFIER ::= { chasKnownTypes  5 }
brouter		OBJECT IDENTIFIER ::= { chasKnownTypes  6 }
terminalServer	OBJECT IDENTIFIER ::= { chasKnownTypes  7 }
chassis		OBJECT IDENTIFIER ::= { chasKnownTypes  8 }
powerSupply	OBJECT IDENTIFIER ::= { chasKnownTypes  9 }
networkMonitor	OBJECT IDENTIFIER ::= { chasKnownTypes 10 }
chassisFan	OBJECT IDENTIFIER ::= { chasKnownTypes 11 }
displayPanel	OBJECT IDENTIFIER ::= { chasKnownTypes 12 }

networkDeviceSlot	OBJECT IDENTIFIER ::= { chasKnownLocations 1 }
powerSupplyBay		OBJECT IDENTIFIER ::= { chasKnownLocations 2 }
fanPosition		OBJECT IDENTIFIER ::= { chasKnownLocations 3 }
backplanePosition	OBJECT IDENTIFIER ::= { chasKnownLocations 4 }

-- Complete Example --
----------------------
The following chassis is now described in terms of the tables in the MIB
shown above.

module type		location	description
-----------------------------------------------------------------
powerSupplyBay		  1		PSU 1
powerSupplyBay		  2		PSU 2
networkDeviceSlot	  1		802.3 Switch Rptr Line Card (4 port)
networkDeviceSlot	  2		802.3 Switch Rptr Line Card (4 port)
networkDeviceSlot	  3		802.3 Switch Rptr Line Card (4 port)
networkDeviceSlot	  4		802.3 Switch Rptr Line Card (4 port)
networkDeviceSlot	  5		802.3 Bridge Card (3 port)
networkDeviceSlot	  6		Empty
backplane		  1		Ethernetx3 Backplane

The components contained on each module are as follows:

PSU 1	comprises	5V dc supply
			12V dc supply
PSU 2	comprises	5V dc supply
			12V dc supply
Each 802.3 Rptr Line Card
			4x Repeater Port, each switchable to any backplane.
802.3 Bridge Card	Port 1, Port 2, Port 3, Bridge Comp
Backplane		Ether1, Ether2, Ether3

At a particular time these components are configured to provide 3 repeaters.
Two of the repeaters are bridged together using two of the 802.3 bridge
ports. The third bridge port provides an external backbone connection:

Repeater 1:	Slot 1, Port 1..4
Repeater 2:	Slot 2, Port 1..4
		Slot 3, Port 1..2
		Ether1
Repeater 3:	Slot 3, Port 3..4
		Ether2
Bridge Port 1:	Connects to Repeater 2
Bridge Port 2:	Connects to Repeater 3
Bridge Port 3:	External backbone connection

---------------------------------------------------------------------------
The proposed MIB would represent this chassis configuration in the following
way:

phyLocationTable:
-----------------
Type(networkDeviceSlot)		Count(6)	Name("Network Slot")
Type(powerSupplyBay)		Count(2)	Name("Power Supply")
Type(backplanePostition)	Count(1)	Name("Backplane")

phyConfigTable: (partial)
---------------
networkDeviceSlot.1
Conents(rptrCard)	Desc("802.3 Repeater Card")	OperStat(Operational)

networkDeviceSlot.2
Conents(rptrCard)	Desc("802.3 Repeater Card")	OperStat(Operational)

networkDeviceSlot.3
Conents(rptrCard)	Desc("802.3 Repeater Card")	OperStat(Operational)

networkDeviceSlot.4
Conents(rptrCard)	Desc("802.3 Repeater Card")	OperStat(Operational)

powerSupplyBay.1
Conents(PSU)		Desc("PSU")			OperStat(Operational)

powerSupplyBay.2
Conents(PSU)		Desc("PSU")			OperStat(Operational)

backplanePosition.1
Conents(EtherBackplane)	Desc("Ethernet Backplane")	OperStat(Operational)

The other columns in the phy config table provide information concerning a
particular module, eg version numbers etc. This information is not shown.
--------------------------------------------------------------------------

charEntityTable
---------------
Index(1)	repeater8023	"802.3 Repeater 1"
targetParty(xyz.1.1)		RowStatus(active)

Index(2)	repeater8023	"802.3 Repeater 2"
targetParty(xyz.1.2)		RowStatus(active)

Index(3)	repeater8023	"802.3 Repeater 3"
targetParty(xyz.1.3)		RowStatus(active)

Index(4)	bridge		"802.3x3 Bridge Module 1"
TAddress(123.234.12.23.0.161)	RowStatus(active)
	(Bridge has it's own SNMP stack)

Index(5)	powerSupply	"5V Power Supply"
No access information, implying part of same device as chassis MIB

Index(6)	powerSupply	"12V Power Supply"
No access information, implying part of same device as chassis MIB
--------------------------------------------------------------
>From the above table we know which modules exist and which entities exist
but there is no knowledge of how those entities are implemented. This is
provided by:

componentTable
--------------
networkDeviceSlot.1.1	Type(repeater8023)	Assignment(1)
networkDeviceSlot.1.2	Type(repeater8023)	Assignment(1)
networkDeviceSlot.1.3	Type(repeater8023)	Assignment(1)
networkDeviceSlot.1.4	Type(repeater8023)	Assignment(1)

networkDeviceSlot.2.1	Type(repeater8023)	Assignment(2)
networkDeviceSlot.2.2	Type(repeater8023)	Assignment(2)
networkDeviceSlot.2.3	Type(repeater8023)	Assignment(2)
networkDeviceSlot.2.4	Type(repeater8023)	Assignment(2)

networkDeviceSlot.3.1	Type(repeater8023)	Assignment(2)
networkDeviceSlot.3.2	Type(repeater8023)	Assignment(2)
networkDeviceSlot.3.3	Type(repeater8023)	Assignment(3)
networkDeviceSlot.3.4	Type(repeater8023)	Assignment(3)

networkDeviceSlot.4.1	Type(repeater8023)	Assignment(0)
networkDeviceSlot.4.2	Type(repeater8023)	Assignment(0)
networkDeviceSlot.4.3	Type(repeater8023)	Assignment(0)
networkDeviceSlot.4.4	Type(repeater8023)	Assignment(0)

networkDeviceSlot.5.1	Type(repeater8023)	Assignment(2)
networkDeviceSlot.5.2	Type(repeater8023)	Assignment(3)
networkDeviceSlot.5.3	Type(repeater8023)	Assignment(0)
networkDeviceSlot.5.4	Type(bridge)		Assignment(4)

powerSupplyBay.1.1	Type(powerSupply)	Assignment(5)
powerSupplyBay.1.2	Type(powerSupply)	Assignment(6)
powerSupplyBay.2.1	Type(powerSupply)	Assignment(5)
powerSupplyBay.2.2	Type(powerSupply)	Assignment(6)

backplanePosition.1.1	Type(repeater8023)	Assignment(2)
backplanePosition.1.2	Type(repeater8023)	Assignment(3)
backplanePosition.1.3	Type(repeater8023)	Assignment(0)

NOTE: All ports on module in slot 4 are currently unused. Behaviour unknown.
Third bridge port currently not assigned to an entity and so behaviour is
unknown. In this case the behaviour is to connect to an external port. This
information is in the domain of the bridge manager.

Backplane Ethernet 3 is also currently unused.
--------------------------------------------------------------------------
Suppose we wish to create a new repeater using the un-assigned ports on card
4. The following sequence would achieve this:

write entityTable.RowStatus.7, underCreation
	No errors for this example

write entityTable.chasEntityType.7, repeater8023
	No errors for this example

-- Entity now exists. Assign Components.

write componentTable.compEntityAssignment.networkDeviceSlot.4.1, 7
write componentTable.compEntityAssignment.networkDeviceSlot.4.2, 7
write componentTable.compEntityAssignment.networkDeviceSlot.4.3, 7
write componentTable.compEntityAssignment.networkDeviceSlot.4.4, 7

Now to use the current external bridge port to bridge this repeater instead
of it's current assignment it is necessary to assign a backplane then assign
the bridge.

write componentTable.compEntityAssignment.backplanePosition.1.3, 7
write componentTable.compEntityAssignment.networkDeviceSlot.5.3, 7

NOTE 1: Quite a number of the objects in the tables described above will be
configured due to hardware and design decisions. For example the
configuration of power supplies etc.

NOTE 2: In the example I've used the explicit backplane assignment system
described earlier. This is to illustrate more clearly how the backplane
segments are now handled. In many ways the implicit handling of backplanes
would be better.