Example 2
{3COM/PDD/PeteW}@pdd.3mail.3com.com Fri, 16 April 1993 15:33 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07729; 16 Apr 93 11:33 EDT
Received: from CS.UTK.EDU by IETF.CNRI.Reston.VA.US id aa07719; 16 Apr 93 11:33 EDT
Received: from localhost by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA10848; Fri, 16 Apr 93 10:45:04 -0400
X-Resent-To: chassismib@CS.UTK.EDU ; Fri, 16 Apr 1993 10:45:02 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 AA10822; Fri, 16 Apr 93 10:44:57 -0400
Received: from gw.3Com.COM by gatekeeper.3Com.COM with SMTP id AA17406 (5.65c/IDA-1.4.4-910725 for <chassismib@cs.utk.edu>); Fri, 16 Apr 1993 07:44:54 -0700
Received: by gw.3Com.COM id AA22839 (5.65c/IDA-1.4.4 for chassismib@cs.utk.edu); Fri, 16 Apr 1993 07:44:52 -0700
Date: Fri, 16 Apr 1993 10:21:00 -0700
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: {3COM/PDD/PeteW}@pdd.3mail.3com.com
Subject: Example 2
To: chassismib@cs.utk.edu
Message-Id: <930416.074603@3Mail.3Com.COM>
Msg-Date: 1993-04-16
Msg-Time: 10:20
Microsoft Mail v3.0 IPM.Microsoft Mail.Note
From: Wilson, Peter
To: Chassis MIB
Subject: Example 2
Date: 1993-04-16 10:15
Priority:
Fixed Font: 0001
Message ID: C527872E
Conversation ID: C527872E
------------------------------------------------------------------------------
Chassis MIB Example 2
A slightly more complex than the last example.
=======================================================================
2) Multi-Ethernet/Multi-Token Ring chassis.
Chassis has the following characteristics:
a) Support for 3 distributed Ethernet repeaters.
b) Support for 3 distributed Token Rings.
Cards in the range are:
a) 4 port Ethernet Line Card. Ports can be connected to one of the
chassis Ethernet backplanes or can be isolated. ie there is no per
port switching.
b) 4 port Token Ring card. Similar to Ethernet card. All ports
can be connected to one of the backplane rings or be isolated.
c) Bridge/Router line card. Has 2 Ethernet ports and 2 Token Ring
ports. Ethernet ports can be connected to any of the three backplane
Ethernets, Token Ring ports to any of the token ring backplanes.
d) Ethernet Terminal Server. Can be connected to any of the backplane
Ethernets.
Using the model each type of card can be described in terms of its
resources:
a) 4 port Ethernet Line Card: Ethernet Repeater Port Group
b) 4 port Token Ring Line Card: Ring Port Group
c) Bridge/Router: Ethernet Repeater Port 1
Ethernet Repeater Port 2
Token Ring Port 1
Token Ring Port 2
Bridge Element
Router Element
d) Terminal Server Ethernet Repeater Port
Terminal Server Element
The backplane is also characterised by its resources:
Repeater Bus 1
Repeater Bus 2
Repeater Bus 3
Token Ring 1
Token Ring 2
Token Ring 3
I'll ignore PSUs, Fans etc. If required these are mapped in the same
way as example 1.
Example configuration:
--------------------------------------------------------------------------
Backplane (1) Standard system backplane. As above.
Modular Slot (1) Repeater Card. Connected to repeater bus 1.
Modular Slot (2) Repeater Card. Connected to repeater bus 2.
Modular Slot (3) Repeater Card. Connected to repeater bus 1.
Modular Slot (4) Repeater Card. Isolated.
Modular Slot (5) Token Ring Card. Connected to Token Ring 1.
Modular Slot (6) Token Ring Card. Connected to Token Ring 1.
Modular Slot (7) Empty
Modular Slot (8) Empty
Modular Slot (9) Bridge/Router Card between repeater 1 & 2, TR 1.
Modular Slot (10) Terminal Server on Repeater bus 1
--------------------------------------------------------------------------
The entities in this configuration are:
--------------------------------------------------------------------------
Repeater (1) Distributed across cards in slots 1, 3 and the logical
repeater ports by which the bridge/router and terminal
server connects to the backplane.
Repeater (2) Implemented by the card in slot 2 and the logical
repeater
port by which it connects to the bridge/router.
Repeater (3) Isolated card in slot 4
Token Ring (1) Cards in slot 5 and 6.
Bridge On the card in slot 9
Router On the card in slot 9
--------------------------------------------------------------------------
Note that for this example the bridge and router functions are treated
as seperate entities. An alternative implementation is to treat them
collectively as a 'brouter'. This alternative is probably the most
common in practice.
The 'resources' that need to be made visible to management are:
--------------------------------------------------------------------------
Backplane (1).1 802.3 Repeater Bus.
Backplane (1).2 802.3 Repeater Bus.
Backplane (1).3 802.3 Repeater Bus.
Backplane (1).4 802.5 Token Ring.
Backplane (1).5 802.5 Token Ring.
Backplane (1).6 802.5 Token Ring.
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 Token Ring Port Group.
Modular Slot (6).1 Token Ring Port Group.
Modular Slot (9).1 Repeater Port 1
Modular Slot (9).2 Repeater Port 2
Modular Slot (9).3 Token Ring Port 1
Modular Slot (9).4 Token Ring Port 2
Modular Slot (9).5 Bridge Element
Modular Slot (9).6 Router Element
Modular Slot (10).1 Repeater Port.
Modular Slot (10).2 Terminal Server Element.
--------------------------------------------------------------------------
Discrete equivalent of the chassis configuration.
+-------------+ +----------+
|Terminal Serv| | Bridge |
+------+------+ +-+--+--+--+
| | | |
| | | +---------------+
| | | |
+--+--+----+ | | +-+--------+ | +-----+------+
+----------+
|Repeater 1|<---+ +--->|Repeater 2| |->|Token Ring 1| |Repeater
3|
+----------+ | | +-+--------+ | +-----+------+
+----------+
| | |
| | +---------------+
| | |
+-+--+--+--+
| Router |
+-+--+--+--+
Note that the MIB does not try to make the interconnection of the
entities visible. If these were discrete devices 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 example.
Location type table is trivial, basically same as before.
Module Table:
+----------------------------------------------------------+
|location type | instance | Contents OID | Description |...|
+==========================================================+
| backplane | 1 | multiServBp | "" | |
| modularSlot | 1 | repeaterMod | ".3 RLC..." | |
| modularSlot | 2 | repeaterMod | ".3 RLC..." | |
| modularSlot | 3 | repeaterMod | ".3 RLC..." | |
| modularSlot | 4 | repeaterMod | ".3 RLC..." | |
| modularSlot | 5 | tokenRingMod| ".5 RLC..." | |
| modularSlot | 6 | tokenRingMod| ".5 RLC..." | |
| modularSlot | 7 | emptyLoc | "Empty" | |
| modularSlot | 8 | emptyLoc | "Empty" | |
| modularSlot | 9 | brouterMod | "Brouter" | |
| modularSlot | 10 | termServer | ".3 TS..." | |
+--------------+----------+--------------+-------------+---+
Entity Table: Indexed by a unique integer.
+----------+-------------+----------------------+---+
|Entity Id | Entity OID | Description |...|
+===================================================+
| 1 | repeater | ".3 Rptr B'plane 1" | |
| 2 | repeater | ".3 Rptr B'plane 2" | |
| 3 | repeater | ".3 Isolated Rptr" | |
| 4 | tokenRing | ".5 Token Ring" | |
| 5 | bridge | "4 port .3/.5 Bridge"| |
| 6 | router | "4 port .3/.5 Router"| |
+----------+-------------+----------------------+---+
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 |
+=================================================================+
| backplane | 1 | 1 | 1 | rptrBplane |
| backplane | 1 | 2 | 2 | rptrBplane |
| backplane | 1 | 3 | 0 | rptrBplane |
| backplane | 1 | 4 | 4 | tkBplane |
| backplane | 1 | 5 | 0 | trBplane |
| backplane | 1 | 6 | 0 | trBplane |
| modularSlot | 1 | 1 | 1 | rptrGroup |
| modularSlot | 2 | 1 | 2 | rptrGroup |
| modularSlot | 3 | 1 | 1 | rptrGroup |
| modularSlot | 4 | 1 | 3 | rptrGroup |
| modularSlot | 5 | 1 | 5 | trGroup |
| modularSlot | 6 | 1 | 5 | trGroup |
| modularSlot | 9 | 1 | 1 | rptrPort |
| modularSlot | 9 | 2 | 2 | rptrPort |
| modularSlot | 9 | 3 | 4 | trPort |
| modularSlot | 9 | 4 | 0 | trGroup |
| modularSlot | 9 | 5 | 5 | bridge |
| modularSlot | 9 | 6 | 6 | router |
| modularSlot | 10 | 1 | 1 | rptrPort |
| modularSlot | 10 | 2 | 5 | terminalServ|
+--------------+----------+----------+-------------+--------------+
Note: The model allows a resource to exist in a state whereby it is not
currently assigned to any entity. This is indicated by a value of zero
in the assignment column.
Again this is a static picture. The ability to create new entities in
the chassis still applies. Suppose I insert two new repeater cards
into slots 7 and 8 and wish to create a new repeater using these. The
approach is exactly the same as the previous example. Create the
repeater entity in the entity table then assign the spare ethernet bus
and the repeater group on each new card to the entity.
==========================================================================
Food for Thought
================
The example I give above is a valid mapping of the chassis described.
It uses the traditional approach of backplanes and makes those
backplanes apparent to the user of the MIB.
An alternative mapping is to avoid the concept of ethernet busses and
token rings on the backplane. These concepts are simply an
implementation issue, they add nothing to the users understanding of
the system. In the alternative mapping slightly more intelligence is
delegated to the agent. The user groups repeater or token ring ports
into entities and the agent automatically allocates the backplanes
transparently as and when necessary. The busses and rings are removed
from the resource table. Now the chassis configuration of the
example may be described in this way:
The module and entity tables are identical. The resource tables
changes to:
map
|<---- map to module ---->| |<-to entity->|
+--------------+----------+----------+-------------+--------------+
|location type | instance | Resource | (Entity Id) | Resource OID |
+=================================================================+
| modularSlot | 1 | 1 | 1 | rptrGroup |
| modularSlot | 2 | 1 | 2 | rptrGroup |
| modularSlot | 3 | 1 | 1 | rptrGroup |
| modularSlot | 4 | 1 | 3 | rptrGroup |
| modularSlot | 5 | 1 | 5 | trGroup |
| modularSlot | 6 | 1 | 5 | trGroup |
| modularSlot | 9 | 1 | 1 | rptrPort |
| modularSlot | 9 | 2 | 2 | rptrPort |
| modularSlot | 9 | 3 | 4 | trPort |
| modularSlot | 9 | 4 | 0 | trGroup |
| modularSlot | 9 | 5 | 5 | bridge |
| modularSlot | 9 | 6 | 6 | router |
| modularSlot | 10 | 1 | 1 | rptrPort |
| modularSlot | 10 | 2 | 5 | terminalServ|
+--------------+----------+----------+-------------+--------------+
Consider the entity repeater 3. The only resource that is a part of
this is the repeater group in slot 4. The agent knows that there is no
need to connect this card to any backplane. Now suppose the user
wishes to reassign the first repeater port on the brouter card to
repeater 3 (resource modularSlot.9.1). This is achieved simply by
changing the assignment of the repeater port to repeater 3. The agent
determines that the repeater now requires the resource of more than
one card and dynamically assigns the spare backplane bus.
If there are insufficient resources for a particular assignment then
the assignment is rejected by the agent.
This model becomes very much more important in per-port switching
architectures where there is no backplane as such or where there are a
large number of available busses.
- Example 2 {3COM/PDD/PeteW}