Chassis MIB Example

{3COM/PDD/PeteW}@pdd.3mail.3com.com Thu, 15 April 1993 11:55 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id ab02539; 15 Apr 93 7:55 EDT
Received: from CS.UTK.EDU by IETF.CNRI.Reston.VA.US id aa02535; 15 Apr 93 7:55 EDT
Received: from localhost by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA21793; Thu, 15 Apr 93 07:22:37 -0400
X-Resent-To: chassismib@CS.UTK.EDU ; Thu, 15 Apr 1993 07:22:36 EDT
Errors-To: owner-chassismib@CS.UTK.EDU
Received: from gatekeeper.3Com.COM by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA21785; Thu, 15 Apr 93 07:22:32 -0400
Received: from gw.3Com.COM by gatekeeper.3Com.COM with SMTP id AA10941 (5.65c/IDA-1.4.4-910725 for <chassismib@cs.utk.edu>); Thu, 15 Apr 1993 04:22:28 -0700
Received: by gw.3Com.COM id AA29934 (5.65c/IDA-1.4.4 for chassismib@cs.utk.edu); Thu, 15 Apr 1993 04:22:25 -0700
Date: Thu, 15 Apr 93 12:11 PDT
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: {3COM/PDD/PeteW}@pdd.3mail.3com.com
Subject: Chassis MIB Example
To: chassismib@cs.utk.edu
Message-Id: <930415.042327@3Mail.3Com.COM>
Msg-Date: 1993-04-15
Msg-Time: 10:58

Microsoft Mail v3.0 IPM.Microsoft Mail.Note
From: Wilson, Peter
To:  Chassis MIB
Subject:  Chassis MIB Example
Date: 1993-04-15 10:52
Priority: 
Fixed Font: 0001
Message ID: 3BF7C030
Conversation ID: 3BF7C030

------------------------------------------------------------------------------

This mail contains the first in a number of examples of how to use the
new chassis model to represent various rack implementations. This
first example is more complete than some of the later ones will be so
it can act as an introduction to those that missed the IETF meeting.

In these examples I've first of all described the chassis and an
example configuration for illustration. This is followed by the actual
contents of important MIB variables and then some notes.

If anyone has any problems with strange $ signs appearing in the text, or
other 'mail' problems let me know.

Pete
=====================================================================
1) Simple 'current technology' chassis.
10 slot Single Ethernet backplane. Chassis contains one 'distributed'
repeater.  Individual cards can be removed from the backplane to form
isolated repeaters. A 2 port bridge module allows backbone connection.
Chassis contains dual redundant PSU modules and a fan tray.

Example Configuration:
 --------------------------------------------------------------------------
PSU Bay (1)             5 & 12V Power
PSU Bay (2)             5 & 12V Power
Fan Tray (1)            Fan Tray installed
Backplane (1)           Standard system backplane.
Modular Slot (1)        Repeater Card. Connected to repeater backplane.
Modular Slot (2)        Repeater Card. Connected to repeater backplane.
Modular Slot (3)        Repeater Card. Connected to repeater backplane.
Modular Slot (4)        Repeater Card. Isolated.
Modular Slot (5)        Repeater Card. Connected to repeater backplane.
Modular Slot (6)        Repeater Card. Connected to repeater backplane.
Modular Slot (7)        Repeater Card. Connected to repeater backplane.
Modular Slot (8)        Repeater Card. 2 port bridge.
Modular Slot (9)        Repeater Card. Empty
Modular Slot (10)        Repeater Card. Empty
 --------------------------------------------------------------------------

The entities in this configuration are:
 --------------------------------------------------------------------------
5V                  Power Supply
12V                 Power Supply
Fans
Repeater (1)        Distributed across cards in slots 1, 2, 3, 5, 6, 7 and 
the
                    logical repeater port by which the bridge connects to 
the
                    backplane.
Repeater (2)        Implemented by the isolated card in slot 4
Bridge              On the card in slot 8
 --------------------------------------------------------------------------

The 'resources' that need to be made visible to management are:
 --------------------------------------------------------------------------
PSU (1).1                 5V Power Source.
PSU (1).2                 12V Power Source.
PSU (2).1                 5V Power Source.
PSU (2).2                 12V Power Source.
Backplane (1).1           802.3 Repeater Backplane.
Modular Slot (1).1        Repeater Port Group.
Modular Slot (2).1        Repeater Port Group.
Modular Slot (3).1        Repeater Port Group.
Modular Slot (4).1        Repeater Port Group.
Modular Slot (5).1        Repeater Port Group.
Modular Slot (6).1        Repeater Port Group.
Modular Slot (7).1        Repeater Port Group.
Modular Slot (8).1        Repeater Port.
Modular Slot (8).2        Bridge Element.
 --------------------------------------------------------------------------
The entities in this configuration appear as:

+---------+     +------------+      +----------+
| 5V PSU  |     | Repeater 1 |------+ Bridge 1 |
+---------+     +------------+      +----------+
                +------------+
+---------+     | Repeater 2 |
| 12V PSU |     +------------+  +------------+
+---------+                     | Fan Tray   |
                                +------------+

Note that the MIB does not try to may the interconnection of the
bridge and repeater (1) visible. If these were discrete components
then that relationship would have to be determined in some way. This
is a small part of the network topology problem which won't be solved
by this group!

MIB contents for this simple example should be fairly obvious:

First of all the LocationType table. This describes all the different
types of location that this chassis contains. It is provided primarily
to allow the actual module table to be indexed on an integer rather
than an OID.
+----------------------------------------------------+
|location type | Type OID    | Description           |
+====================================================+
|      1       | psuBay      | "PSU Location"        |
|      2       | fanTray     | "Fan Location"        |
|      3       | backplane   | "Backplane"           |
|      4       | modularSlot | "Option Slot"         |
+--------------+-------------+-----------------------+

Module Table: Indexed by location type and instance. Note I've indicated
the location type by name. It is actually an integer index into the table
above.
+----------------------------------------------------------+
|location type | instance | Contents OID | Description |...| 

+==========================================================+
| psuBay       |     1    |  psu         | "PSU..."    |   |
| psuBay       |     2    |  psu         | "PSU..."    |   |
| fanTray      |     1    |  fanTray     | "Fan..."    |   |
| backplane    |     1    |  etherRptrBp | ".3 Rptr Bp"|   |
| modularSlot  |     1    |  repeaterMod | ".3 RLC..." |   |
| modularSlot  |     2    |  repeaterMod | ".3 RLC..." |   |
| modularSlot  |     3    |  repeaterMod | ".3 RLC..." |   |
| modularSlot  |     4    |  repeaterMod | ".3 RLC..." |   |
| modularSlot  |     5    |  repeaterMod | ".3 RLC..." |   |
| modularSlot  |     6    |  repeaterMod | ".3 RLC..." |   |
| modularSlot  |     7    |  repeaterMod | ".3 RLC..." |   |
| modularSlot  |     8    |  BridgeMod   | ".3 Bridge."|   |
| modularSlot  |     9    |  emptyLoc    | "Empty"     |   |
| modularSlot  |    10    |  emptyLoc    | "Empty"     |   |
+--------------+----------+--------------+-------------+---+
Notes: It is suggested that this table be dense in as much as there is
an entry for every location, even if that location is empty.

Entity Table: Indexed by a unique integer.
+----------+-------------+---------------------+---+
|Entity Id | Entity  OID | Description         |...|
+==================================================+
| 1        |  powerSource| "5V PSU..."         |   |
| 2        |  powerSource| "12V PSU..."        |   |
| 3        |  fan        | "Cooling Fan..."    |   |
| 4        |  repeater   | ".3 Rptr B'plane"   |   |
| 5        |  repeater   | ".3 Isolated Rptr"  |   |
| 6        |  bridge     | "2 port .3 Bridge"  |   |
+----------+-------------+---------------------+---+

The resource table provides information regarding all the resources in
the system. It also provides the mapping of resource to module and
from resource to entity. The resource table is indexed on location
type, instance and a resource number within that module. The location
type and instance provide the map to the module table. The assignment
column contains the id of the single entity to which this resource is
currently assigned.
                                           map
|<---- map to module ---->|          |<-to entity->|
+--------------+----------+----------+-------------+--------------+
|location type | instance | Resource | (Entity Id) | Resource OID |
+=================================================================+
| psuBay       |     1    |    1     |      1      |  psuResource |
| psuBay       |     1    |    2     |      2      |  psuResource |
| psuBay       |     2    |    1     |      1      |  psuResource |
| psuBay       |     2    |    2     |      2      |  psuResource |
| fanTray      |     1    |    1     |      3      |  fanResource |
| backplane    |     1    |    1     |      4      |  rptrBplane  |
| modularSlot  |     1    |    1     |      4      |  rptrGroup   |
| modularSlot  |     2    |    1     |      4      |  rptrGroup   |
| modularSlot  |     3    |    1     |      4      |  rptrGroup   |
| modularSlot  |     4    |    1     |      5      |  rptrGroup   |
| modularSlot  |     5    |    1     |      4      |  rptrGroup   |
| modularSlot  |     6    |    1     |      4      |  rptrGroup   |
| modularSlot  |     7    |    1     |      4      |  rptrGroup   |
| modularSlot  |     8    |    1     |      4      |  rptrPort    |
| modularSlot  |     8    |    2     |      5      |  bridgeRes   |
+--------------+----------+----------+-------------+--------------+

This illustrates the static configuration of the device. One of the
major benefits of the chassis concept is that the assignment of
physical resources to entities is dynamically configurable. So for
instance if one workgroup were behaving badly I could move the ports
representing that group to a seperate network from the management
station. In this very simple device the only real configurable
element is the ability to isolate a repeater card from the backplane.
This ability should be encapsulated in a standard chassis MIB without
recourse to enterprise specific enhancements. The way this proposal
deals with this is as follows:

1) An configurable implementation allows the entity table to have new
rows created. That is new 'entities' can be created on the fly. The
agent implementation will obviously restrict the types of entity that
can be created.

2) The model allows an entity to exist with no resources assigned to
it. Such an entity has now functionality, this only comes from
resources assigned to the entity.

3) In this example the agent allows the creation of repeater entities.
Isolating a repeater from the backplane creates a new repeater device,
represented by an entity. To isolate a card the management station
will create a repeater entity and assign a rptrGroup resource to that
entity. Creating the repeater entity means a row creation operation on
the entity table. An assignment is achieved simply by writing the id of
the new entity to the resource table.