What is a Slot/FRU/PhysDevice?

[[e-mail] (Jason Perreault)]

I haven't attended the last two IETFs, and from the minutes I
can't determine whether these issues have been raised, so....

I'm wondering whether a distinction needs to be made between
"physical device" and "slot", and whether the concept of
field-replaceable unit (FRU) needs to be introduced. While the
most common interrelationship among physDev-FRU-slot might be
1-1-1, two other cases probably are common enough to warrant 
some manner of treatment in the MIB:

--------------------------------------------------------------------------
MULTIPLE FRUs IN A SLOT (1-many-1)

  A slot might be occupied by more than one FRU, (eg, front-inserted 
  processing module + rear-inserted cabling interface module), which
  are separately identifiable products in the vendor's enterprise
  subtree. The current Slot Table probably would identify only the
  processing module. 

   Considerations:
   - need additional FRU index for slot table?
   - unique index value assigned to each FRU, or just count FRUs 
     starting from 1 for each slot?
   - unique FRU index values implies migrating module-identifying info 
     to a FRU Table?
   - some FRUs detectable only when some "primary" FRU installed and
     running.
--------------------------------------------------------------------------
MULTI-SLOT FRU (1-1-many)

  A FRU, owing to physical construction, might span two or more
  contiguous slots, although it is regarded as occupying only
  one of them from a functional standpoint. 

   Considerations:
   - need to distinguish among slots that are a) physically and 
     functionally occupied, b) physically obstructed but functionally 
     empty, and c) physically empty (unoccupied and unobstructed)?
   - need to identify specifically which FRU obstructs a slot?
   - need to distinguish whether a slot is fully, or only partially,
     obstructed? (Eg single-wide processor FRU in slot N attached to 
     double-wide cable interface FRU in slots N/N+1, is the "orphan" 
     processor receptacle in slot N+1 available)?
--------------------------------------------------------------------------

These examples lead me to consider a MIB structure that includes:

   a) a FRU Table that itemizes and identifies FRUs, and assigns to 
      each a unique index (chasFruIndex);
   b) a Slot Table indexed by { chasSlotIndex, chasFruIndex } to 
      identify slot/FRU associations. 

Most of the module-identifying information in the Slot Table migrates to
the FRU Table. An enumerated status object is defined for the Slot Table, 
having values of:

   other(1),   -- not classified by other enum value below;
   empty(2),   -- nothing in this slot, available for use;
   occupied(3), -- FRU functionally resides in this slot
   fullyObstructed(4),  -- indicated FRU (residing in another slot) 
                        -- fully obstructs this slot;
   partiallyObstructed(5) -- indicated FRU (residing in another slot)
                          -- partially obstructs this slot, ie obstructs
                          -- portion of slot normally "consumed" by this
                          -- FRU type.

If the same FRU index appears in different slots, then a multi-slot FRU 
is indicated, with the status object distinguishing in which slot(s) the 
FRU is considered to be installed, and which other slots (or portions
thereof) are rendered unavailable for use as a consequence of the FRU's
physical presence.

A definite downside of this MIB structure is that the WHAT and WHERE
(FRU type and location) information is distributed across two tables
(FRU and Slot) instead of one (as in the current Slot Table).

Having made this near-stream-of-consciousness presentation, I'll ask:

   To what level of detail ought the MIB seek to represent the
   physical composition of the chassis?


------------------------------------------------------
Jason Perreault           net   : [e-mail]
Coral Network Corp        voice : [phone] x228
Marlborough MA 01752      fax   : [phone]