Chassis MIB Proposal

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

FROM: Wilson, Peter

TO:  {[e-mail]}:ugate:3com                       DATE:  01-04-94
                                                              TIME:  09:39
CC:
SUBJECT:  Chassis MIB Proposal
PRIORITY:
ATTACHMENTS:

------------------------------------------------------------------------------
Below is my proposal, resent from last October, for a complete chassis MIB 
proposal.
==============================
I've spent some time going over the chassis MIB drafts trying to pull
together all the strands into a single MIB and to provide some
descriptive text. This is the result.

What I've done:
- Taken the most stable and discussed chassis MIB draft.
- Modified the power supply and sensor groups to be consistent with the
  modified model.
- Added an optional link table that can be used to describe the
  physical interconnection of elements in the chassis (without
  overloading the inventory tables).

There seemed to be quite a lot of interest in this MIB when the WG was being
disbanded, but very little since. I'd appreciate those of you
interested in the MIB at that time reading this proposal and returning
comments to myself. I will be at the November IETF meeting if you
would like to discuss any of this in person.

thanks
Pete
----------------------------------------------------------------------------
Definitions/Glossary
====================
Chassis:      A generic 'container'. Specifically for the purpose of this MIB
              implement network devices. A chassis can be viewed either from
              physical or logical perspective. Physically a chassis contains
              a number of modules. Logically a chassis contains a collection
              of functional 'entities'.

Module:       A module is a physical thing contained within a chassis. A
              particular chassis can contain any number of different types
              of module and any number of distinct instances of the same
              type of module. A module is distinguished from other modules
              in a chassis by its type and its position within the chassis.
              A module is itself a container of 'resources'.

Resource:     Each physical module comprises a number of resources. The
              resources can be of any kind, for example a repeater port,
              bridge relay etc.

Entity:       An entity is a functional unit within the chassis. An 'entity'
              is analogous to a seperate, standalone device. Examples of
              chassis entities are: Ethernet repeaters, bridges, routers,
              token ring concentrators.

Link:         A Link is a description of a known connection between two
              resources in the chassis. A particular chassis can describe
              its internal topological configuration by entries in a table
              of links in the MIB. Note that it is not necessary to
              describe all links in the chassis, only those that are useful.
              Refer to the MIB group descriptions for an example of
              how links can be used to describe mappings of multiple bridges
              and routers to the same physical network connections (the
              'brouter' scenario).

The Model
=========

For the purposes of this MIB a chassis is any device, or collection of
devices that together can be considered a single entity. For example,
traditional multi-slot 19" rack mounting chassis are included, as are the
newer stackable type devices. The MIB is not limited to such devices and so
could be used to describe any containment type of relationship. Note that if
necessary an instance of the 'chassis' could logically contain a sub chassis
to allow an arbitrarily deep containment hierarchy.

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, or location. Each type of location is specialised to hold a
particular type of item or module.  Examples of compartment types would be
network card slots, power supply bays and fan trays.  At any instant in time
each location in a chassis 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 Ethernet repeaters, bridges, routers
and terminal servers.

An entity is implemented using parts from one or more of the physical
modules in the chassis. 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, or
resources. A number of these resources 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
resource from which project teams are constructed. Each person is
specialised for a particular role within a project.

Floor       Function:Person     Project         Implemented By
(module)      (resource)        (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 resources 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 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 resource of all cards visible and allow the configuration of those
resources 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

Combining Resources 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 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