Inter-entity connections.

[{3COM/PDD/PeteW}@pdd.3mail.3com.com]

Microsoft Mail v3.0 IPM.Microsoft Mail.Note
From: Wilson, Peter
To:  Chassis MIB
Subject:  Inter-entity connections.
Date: 1993-07-13 13:37
Priority: 
Fixed Font: 0001
Message ID: 24D88EC5
Conversation ID: 24D88EC5

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

This text proposes one way in which the chassis MIB one resource to one
module and one resource to one entity relationships can be maintained but
also how the MIB can be enhanced to include information that allows entity
interconnection information to be made visible in the MIB.

Basically the configuration MIB groups already available are augmented by
a interconnection group. The interconnection group contains 'link
definitions'. Each link definition describes a connection between two
entities in the chassis.

I'll describe this by means of an example. Consider a 3 port bridge which
has two Ethernet and one 802.5 port. The chassis also contains three other
entities, a token ring and two Ethernet. The bridge ports are connected to 
these
entities.

Now the configuration groups describe the equipement in the chassis as
follows:

Discrete equivalent of the chassis configuration.

                   +----------+
                   |  Bridge  |
                   +-+--+--+--+
                     |  |  |
                     |  |  +---------------+
     +--+--+----+    |  |    +-+--------+  |  +-----+------+
     |Repeater 1|<---+  +--->|Repeater 2|  +->|Token Ring 1|
     +----------+            +-+--------+     +-----+------+

The MIB to represent this configuration would be as follows:

Module Table:
+----------------------------------------------------------+
|location type | instance | Contents OID | Description |...| 

+==========================================================+
| backplane    |     1    |  multiServBp | ""          |   |
| modularSlot  |     1    |  repeaterMod | ".3 RLC..." |   |
| modularSlot  |     2    |  repeaterMod | ".3 RLC..." |   |
| modularSlot  |     3    |  tokenRingMod| ".5 RLC..." |   |
| modularSlot  |     9    |  bridgeMod   | "Bridge"    |   |
+--------------+----------+--------------+-------------+---+

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        |  tokenRing  | ".5 Token Ring"      |   |
| 4        |  bridge     | "3 port .3/.5 Bridge"|   |
+----------+-------------+----------------------+---+

The physical 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     |      3      |  tkBplane    |
| modularSlot  |     1    |    1     |      1      |  rptrGroup   |
| modularSlot  |     2    |    1     |      2      |  rptrGroup   |
| modularSlot  |     3    |    1     |      3      |  trGroup     |
| modularSlot  |     9    |    1     |      1      |  rptrPort    |
| modularSlot  |     9    |    2     |      2      |  rptrPort    |
| modularSlot  |     9    |    3     |      3      |  trPort      |
| modularSlot  |     9    |    4     |      4      |  bridge      |
+--------------+----------+----------+-------------+--------------+

The logical resource table describes the same relationships but using the
entity relationship as the SNMP index to provide direct entity to resource
mappings.

Now with reference to the picture above the MIB so far has not specified
the interconnection of entities. It is suggested that this information be
kept in a seperate optional MIB group. The new group will provide a
'entity, connected to entity' mapping. There are several ways this
information can be maintained, for example resource to resource, entity to
resource, resource to entity or straight entity to entity. Consider an
entity to entity table. This could simply contain the following
information:

Link Index     from                             to
 ------------------------------------------------------
    1         entity 1      connects to       entity 4
    2         entity 2      connects to       entity 4
    3         entity 3      connects to       entity 4
    4         entity 4      connects to       entity 1
    5         entity 4      connects to       entity 2
    6         entity 4      connects to       entity 3

This is not the most useful way of representing the information. There is
no way to ask which entities are connected without reading the whole
table. Neither is it possible to say by which resources the entities are
connected. Perhaps a better way is to use a resource to resource mapping.
This does however create the need to have some additional resources simply
to complete the mapping. Consider the bridge card as being described as 7
resources:

|<---- map to module ---->|          |<-to entity->|
+--------------+----------+----------+-------------+--------------+
|location type | instance | Resource | (Entity Id) | Resource OID |
+=================================================================+
|     ...      |    ...   |   ...    |     ...     |      ...     |
| modularSlot  |     9    |    1     |      1      |  rptrPort    |
| modularSlot  |     9    |    2     |      2      |  rptrPort    |
| modularSlot  |     9    |    3     |      3      |  trPort      |
| modularSlot  |     9    |    4     |      4      |  bridgePort  |*
| modularSlot  |     9    |    5     |      4      |  bridgePort  |*
| modularSlot  |     9    |    6     |      4      |  bridgePort  |*
| modularSlot  |     9    |    7     |      4      |  bridge      |
+--------------+----------+----------+-------------+--------------+
The bridge ports have been introduced for the purpose of providing a
complete mapping. They are not required unless the interconnection
information is to be supported. Note that the bridge ports are part of the
bridge entity, but that they actually transmit traffic via the .3 and .5
physical ports.

Now the interconnection table looks like this:

Link Index    from resource                   to resource
 ------------------------------------------------------
    1         modSlot.4.1      connects to     modSlot.4.4
    1         modSlot.4.2      connects to     modSlot.4.5
    1         modSlot.4.3      connects to     modSlot.4.6
    1         modSlot.4.4      connects to     modSlot.4.1
    1         modSlot.4.5      connects to     modSlot.4.2
    1         modSlot.4.6      connects to     modSlot.4.3

Note that no other resources need to be present in the mapping table.
These are the only inter-entity connections!

Note that in the 02 draft, there is now actually 2 ways of describing a
resource, either by it's (locType, loc, index) fixed triplet, or by the
(entity, resource-subindex) pair. The second description changes will
change when a resource is switched from one entity to another. Most of the
interconnection relationships are best defined in terms of entity/sub-
index. It is the entities that are interconnected, not the modules.

THE POINT
=========
As discussed at the Columbus meeting, the interconnection information is
important but it is too difficult to try to have one set of tables
describe everything. It just does not work. The configuration tables
should be just that. Interconnection should be represented in a seperate
table or group.

The recommendation then is to take the fairly stable draft-ietf-chassis-
mib-01.txt as the basis of a standard and build on that.
Forget the ever more complex overloading of the same tables and the ever
more complex and fuzzy definitions of entities, resources and modules.

Pete