Chassis MIB Proposal.

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

Microsoft Mail v3.0 IPM.Microsoft Mail.Note
From: Wilson, Peter
To:  Heads, Bob
     Moran, Paul
     Woodruff, Paul
     IETF-Chassis MIB
Subject:  Chassis MIB Proposal.
Date: 1992-12-04 16:26
Priority: 
Message ID: 2C8A5B3D
Conversation ID: 2C8A5B3D


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

I tried sending this proposal to the group the week after Washington and 
again a week later. It doesn't seem to be getting through so this time I've 
split the thing into two parts. The first is the descriptive text, the 
second a MIB proposal. The proposal follows on from the ideas I presented at 
Washington to make the chassis MIB more generic. The most important change 
is to reduce the relationship table between 3 things, module, entity and 
segment to a two way relationship between component and entity. I hope you 
find the suggestions here useful.

Pete
 ----------------------------------------------------------------------------  
 ------------------------------.


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

                                November 24, 1992


			Proposal By: Peter Wilson
			  [e-mail]

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.