Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/fddimib/fddimib-minutes-90june.txt

Text File | 1993-02-17 | 8KB | 206 lines

CURRENT_MEETING_REPORT_



Reported by Jeff Case/U-Tenn

Minutes of the FDDI MIB Working Group June 12, 1990

These minutes were mistakenly not included in the last proceedings.

The FDDI MIB Working Group last met on June 12, 1990.  The meeting was
held between the IETF plenaries, in conjunction with the INTEROP 90 SNMP
Demo and FDDI Demo planing meetings at the Grand Kempinski Hotel in the
Dallas - Fort Worth area.

Goals

Since there were several attendees who were new to the work, the goals
of the group were reviewed.  The primary goal is to define an SNMP
compliant MIB for FDDI devices with objects which are based on those
defined in the ANSI FDDI specifications.  It is hoped that initial
implementations can be completed in time for demonstration in early
October.

The text of the current document draft was distributed and discussed.
The majority of the current text comes from the pertinent sections of
the ANSI FDDI SMT specification.  That text has been recast to align
with RFC conventions and to comply with the requirements of the SNMP,
MIB, and SMI specifications.  Only the minimal required changes to the
variables have been made and only the SMT variables which were
"required" have been retained.  The intent is have as close a
relationship between the SNMP and SMT management variables as is
technically possible.  In general, corresponding objects will have the
same semantics although they will necessarily have different syntaxes.

Several issues were discussed and some were resolved.

OBJECT NAMING:

A leaf of the Experimental portion of the Internet tree has been
allocated to FDDI:         fddi := { experimental 8 }

One issue with respect to naming is with respect to the object
descriptors to be associated with each object.  It is desirable that all
identical objects have identical object descriptors.  On the other hand,
it is desirable that all no two different objects have the same object

                                   1






descriptor.  While there are no guarantees that object descriptors are
globally unique as object identifiers are, it is desirable for user
interfaces that the mappings be both convenient and unambiguous.  Two
extreme positions are to:


   o adopt the object descriptors from SMT without change, even when the
     semantics and syntax of the underlying objects differ
   o adopt an entirely new set of object descriptors


A compromise position was suggested -- to use the SMT object descriptors
as much as possible, prefixing each with a standard prefix, and using
different object descriptors on those objects which are different from
their SMT counterparts.

It was brought up that other experimental MIBs (such as 802.3 and 802.5)
must also be experiencing this problem and that it should be resolved in
a consistent fashion for all MIBs.

Another issue with respect to object naming is with regard to the
assignment of object identifiers.  The SNMP FDDI MIB is a subset of the
SMT MIB at this time, with gaps in the tree for the objects which have
not been included.  It was agreed that whenever reasonably possible that
the trailing portions of the object identifiers would be assigned such
that if it is ever decided to include some of the optional SMT objects
in the SNMP MIB that they can be assigned in a parallel fashion.  That
is, the numbers will be assigned in a sparse manner.  It costs little or
nothing to do so.  Any gaps in the numbering will reserved for future
use.

bf PTIONAL SMT VARIABLES

Several minutes were spent discussing the inclusion of variables which
are labeled as optional in the ANSI document as optional in the SNMP
FDDI MIB.

Discussion centered around the meaning of the word "optional".  In the
SMT specification, there are two kinds of optional variables.  Some are
defined as optional because they pertain to an optional feature, and
others which are completely optional, independent of any FDDI feature or
function.  Optional in the Internet MIB pertains only to optional
functions.  If a function is implemented, all its MIB variables must
also be implemented.

There were two points of view in the room -- one that SNMP should only
use the mandatory variables, and second, that the entire SMT MIB should

                                   2






be carried over into the SNMP MIB and let users decide which variables
are useful.

The current draft includes only the variables that are listed as
mandatory in the SMT 6.2 MIB.

INSTANCE IDENTIFICATION

Instance Identifiers for MACs, PORTs, PATHs and ATTACHMENTs need to be
defined.  MAC instance identifiers are defined correctly in version 0.2
of the document.  PORT instance identifiers are similar to MACs.  They
index into the port table, starting at 1 up to fddiSMTMaster-Ct +
fddiSMTNon-Master-Ct.  PATHs are organized as two tables, the PATHCLASS
table and the NON-LOCAL PATH table.  The PATHCLASS table has a maximum
of two entries, one for local paths and one for non-local paths.  They
are indexed 1 and 2.  The NON-LOCAL PATH table has a maximum of two
entries, one for the primary path and one for the secondary path.  They
are indexed 1 and 2.  ATTACHMENT instance ids are identical to PORT ids.
In the case of a dual attach ATTACHMENT, indexing the ATTACHMENT table
with the PORT index for either PORT of the dual attachment will return
the same entry of the ATTACHMENT table.  The entry will NOT be returned
twice with a powerful getnext.

PROXY ADDRESSING

The proper mechanism(s) for addressing a particular SMT device via an
SNMP to SMT proxy were discussed.  This problem is very similar to
previous work with other MAC layer devices such as bridges.  Two
possible solutions have been used in those applications:


   o designate the target node through information contained in the
     community field
   o designate the target node through information contained in the
     instance portion of the object name for each object


Overloading the Community Field implies that every variable in the PDU
is for the same destination FDDI station.  Thus the station is viewed as
the system from SNMP's perspective.  Appending to the instance
identifier means that variables within a single PDU can be directed at
multiple stations within the LAN. Thus, the LAN is the system and
stations are part of that system.

The latter mechanism would have an effect on direct SNMP management of
FDDI, since all variables would need the appended addressing
information.  We could use a convention of an appended 0 to mean the

                                   3






local SMT to the SNMP Agent.

Appending to each id can result in lots of redundant addressing
information when when variables are all intended for the same station.
It also makes the powerful getnext request complex for the proxy when it
needs to locate the next lexicographically increasing MAC address
currently on the LAN.

This issue was left unresolved.  The chair will consult with other SNMP
experts about the issue and make an appropriate decision.

fddiSMTSetCounter AND fddiSMTSetTimeStamp

The variables fddiSMTSetCounter and fddiSMTSet TimeStamp were recombined
to make fddiSMTSetCount.  It is defined as OCTET STRING SIZE(12).  This
allows the full set count to be accessed as a single variable to
maintain consistency between the counter and the timestamp.  This change
will be reflected in the next draft.

ACTIONS AND EVENTS

Much work remains to be done on the mapping of SMT actions and events
into their SNMP counterparts.  This will be pursued in future versions
of the draft MIB.

NEXT MEETING:

The next meeting of the FDDI MIB Working Group will be held in
conjunction with the IETF plenary to be held at the University of
British Columbia, July 31 - August 3, 1990.

ACKNOWLEDGEMENT

The chair wishes to express gratitude to Nelson Ronkin, Synernetics, for
taking extensive notes which formed the basis for these minutes.



                                   4