Example 3
{3COM/PDD/PeteW}@pdd.3mail.3com.com Mon, 24 May 1993 12:28 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21602; 24 May 93 8:28 EDT
Received: from CS.UTK.EDU by IETF.CNRI.Reston.VA.US id aa21598; 24 May 93 8:28 EDT
Received: from localhost by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA07518; Mon, 24 May 93 08:04:23 -0400
X-Resent-To: chassismib@CS.UTK.EDU ; Mon, 24 May 1993 08:04:22 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 AA07510; Mon, 24 May 93 08:04:20 -0400
Received: from gw.3Com.COM by gatekeeper.3Com.COM with SMTP id AA12127 (5.65c/IDA-1.4.4-910725 for <chassismib@cs.utk.edu>); Mon, 24 May 1993 05:04:16 -0700
Received: by gw.3Com.COM id AA26916 (5.65c/IDA-1.4.4 for chassismib@cs.utk.edu); Mon, 24 May 1993 05:04:13 -0700
Date: Mon, 24 May 1993 12:54:00 -0700
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: {3COM/PDD/PeteW}@pdd.3mail.3com.com
Subject: Example 3
To: chassismib@cs.utk.edu
Message-Id: <930524.050758@3Mail.3Com.COM>
Msg-Date: 1993-05-24
Msg-Time: 12:53
Microsoft Mail v3.0 IPM.Microsoft Mail.Note From: Wilson, Peter To: Chassis MIB Subject: Example 3 Date: 1993-05-24 12:49 Priority: Fixed Font: 0001 Message ID: A2CAD6AC Conversation ID: A2CAD6AC ------------------------------------------------------------------------------ Dave Arneson raised the question of entities distributed over multiple cards. This example shows the way to achieve this for a bridge implemented using a port and bridge card. This can be extended to cover routers and terminal servers, or any other kind of entity. The examples so far have assumed that functional entities such as bridges and routers are imlemented on a single card. This is not always the case. This example shows one way of mapping a particular multi-card bridge implementation. The example considers a central 'bridge' card and a number of 'port cards' for various technologies. The chassis is assumed again to support 3 Ethernets and 3 Token Rings. ======================================================================= 3) Multi-Card Bridge 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 set. Set comprises: 1) Central Bridge Card 2) Bridge Port Card (802.3) 3) Bridge Port Card (802.5) A bridge comprises one central bridge card and a mixture of port cards. 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) Central Bridge: Bridge Element 802.3 port card: 802.3 Repeater Port Bridge Element 802.5 port card: 802.5 Repeater Port Bridge 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) Token Ring Card. Connected to Token Ring 1. Modular Slot (4) 802.5 Bridge Port Card Bridging to ring 1 Modular Slot (5) Central Bridge Card Modular Slot (6) 802.3 Bridge Port Card Bridging to repeater bus 1 Modular Slot (7) 802.3 Bridge Port Card Bridging to repeater bus 2 Modular Slot (8) Empty Modular Slot (9) Empty Modular Slot (10) Empty -------------------------------------------------------------------------- The entities in this configuration are: -------------------------------------------------------------------------- Repeater (1) Distributed across cards in slots 1 and the logical repeater ports by which the bridge port cards connect to the backplane. Repeater (2) Implemented by the card in slot 2 and the logical repeater port by which it connects to the bridge. Token Ring (1) Cards in slot 3 Bridge On the cards in slot 4, 5, 6 and 7 -------------------------------------------------------------------------- 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 Token Ring Port Group. Modular Slot (4).1 802.5 Port 1 Modular Slot (4).2 Bridge Element Modular Slot (5).1 Bridge Element Modular Slot (6).1 802.3 Port 1 Modular Slot (6).2 Bridge Element Modular Slot (7).1 802.3 Port 1 Modular Slot (7).2 Bridge Element -------------------------------------------------------------------------- Discrete equivalent of the chassis configuration. +----------+ | Bridge | +-+--+--+--+ | | | +------------+ | | +------------->|Token Ring 1| | | +------------+ +----------+ | | +----------+ |Repeater 1|<---+ +--->|Repeater 2| +----------+ +----------+ 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 | tokenRingMod| ".5 RLC..." | | | modularSlot | 4 | bridgePort | "Bridge Port"| | | modularSlot | 5 | bridgeCtrl | "Bridge" | | | modularSlot | 6 | bridgePort | "Bridge Port"| | | modularSlot | 7 | bridgePort | "Bridge Port"| | | modularSlot | 8 | emptyLoc | "Empty" | | | modularSlot | 9 | emptyLoc | "Empty" | | | modularSlot | 10 | emptyLoc | "Empty" | | +--------------+----------+--------------+--------------+---+ 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 | "4 port .3/.5 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 | +=================================================================+ | backplane | 1 | 1 | 1 | rptrBplane | | backplane | 1 | 2 | 2 | rptrBplane | | backplane | 1 | 3 | 0 | rptrBplane | | backplane | 1 | 4 | 3 | tkBplane | | backplane | 1 | 5 | 0 | trBplane | | backplane | 1 | 6 | 0 | trBplane | | modularSlot | 1 | 1 | 1 | rptrGroup | | modularSlot | 2 | 1 | 2 | rptrGroup | | modularSlot | 3 | 1 | 3 | trGroup | | modularSlot | 4 | 1 | 3 | trPort | | modularSlot | 4 | 2 | 4 | bridge | | modularSlot | 5 | 1 | 4 | bridge | | modularSlot | 6 | 1 | 1 | rptrPort | | modularSlot | 6 | 2 | 4 | bridge | | modularSlot | 7 | 1 | 3 | rptrPort | | modularSlot | 7 | 2 | 4 | bridge | +--------------+----------+----------+-------------+--------------+ 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. Note that this is a static picture. The model would allow there to be two central bridge cards and a number of port cards. The port cards can then be moved between the various central bridge cards as, for example, loading dictates. The implementation would allow automatically create a bridge entity for each central bridge card and assign the central card to that entity. Port cards could then be assigned to bridges as necessary.
- Example 3 {3COM/PDD/PeteW}