Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/modemmgt/modemmgt-minutes-93jul.txt

Text File | 1993-09-09 | 7KB | 196 lines

CURRENT_MEETING_REPORT_

Reported by Mark Lewis/Telebit Corporation

Minutes of the Modem Management Working Group (MODEMMGT)


Agenda

   o Introductions
   o Working group goals and schedule
   o Status of draft modem mib
   o Comments on draft modem mib
   o The next step


Introductions

There were 18 people present, several of whom said they were interested
in implementing a modem MIB in their products.  Also present were a few
modem users, a couple of modem manufacturers, and members of the Network
Management Directorate (NMDIR).


Working Group Goals and Schedule

It was discussed that this is the group's first meeting as a working
group at an IETF meeting.  A special two-day meeting had been held June
28-29 in Baltimore.

The major goal of this working group is to agree on a standard MIB for
managing modems.  The group would like to have an Internet-Draft written
and accepted by the group by the end of 1993.


Architecture of MIB

We discussed the idea of representing dial-up (switched), leased-line,
and network modems as separate but related modem instances (model 2
below).  In the diagram below, base objects refer to those which are the
same regardless of mode (e.g.  modem manufacturer).  Common objects are
those which may have different values for each mode (e.g.  transmit
output level).  Switched and leased refer to groups of objects that are
only relevant to that mode.

         +----------+            +----------+  +----------+
         |   Base   |            |   Base   |  |   Base   |
  +------+---+--+---+----+       +----------+  +----------+
  |  Common  |  | Common |       |  Common  |  |  Common  |

                                   1





  +----------+  +--------+       +----------+  +----------+
  | Switched |  | Leased |       | Switched |  |  Leased  |
  +----------+  +--------+       +----------+  +----------+

           Model 1                        Model 2

Model 1 presents the modem as a single instance with multiple instances
of variables which might have different values for different modes
(common).  Model 2 presents multiple modem instances, one for each mode
that the modem supports (e.g.  switched, leased-line).  For both models,
there would be a single instance of the objects related to the specific
mode (e.g.  switched, leased-line).

We discussed the trade-offs between the two models above.  Model 1
seemed better if the number of common objects were relatively small
compared to the number of base objects.  If the number were relatively
large, model 2 seemed preferable.

We were unclear how many common objects might have different values for
each mode.  It was roughly estimated that somewhere between 10-80
objects would fall into this common category.  It was noted that many
implementations probably don't care to have different values for each
mode.

Since the number of such objects is potentially large, there was general
agreement to use model 2.  This means management stations would deal
with multiple instances, one for each mode the modem supports (e.g.
switched, leased-line).  (Note that after the meeting more detailed
analysis was done which may indicate model 1 is more appropriate.)


MdmLineCapabilitiesEntry ::= SEQUENCE {
    mdmLineCapabilitiesIndex            INTEGER,
    mdmLineCapabilitiesID               OBJECT IDENTIFIER,
    mdmLineCapabilitiesEnableRequested  INTEGER,
    mdmLineCapabilitiesEnableGranted    INTEGER
}


We reviewed the capabilities table.  There was general agreement that
this fit the situation well.  It provided a flexible method to let the
agent describe the capabilities of the modem, as well as provide a way
to enable and disable them.

Someone voiced a request that there be a linkage between an interface
and a modem.  There was agreement that this would be valuable where the
modem was being used for packet connections using SLIP or PPP. It was
also agreed that this would not be possible in cases where the modem was
being used in character only mode.  The group resolved to coordinate
with the working group designing the interface MIB to provide such a
linkage.



                                   2





There was a lengthly discussion of the idea of providing a record of
calls for accounting and trouble-shooting.  The advisability of using
SNMP for accounting was considered.  Since virtually all modem vendors
provide such capabilities, it was decided to implement some method of
tracking calls.  Traps were deemed not suitable for this purpose.  It
was agreed that some type of a history of calls would be kept in the
agent.

Several possible implementations of a call history were considered:


   o Option 1
     Rely on the management station to poll the agent often enough to
     get all call records.  No traps were necessary using this approach.

   o Option 2
     Have the management station poll the agent, but also receive traps
     at a predefined point.  For example, the agent would send traps
     after writing some 25 out of 100 call records.  Note the predefined
     point could be configurable as a percentage.

   o Option 3
     Have the agent keep track of the last call record read by each
     management station.  It would then be possible to send a trap to a
     particular management station when it is in danger of missing a
     call record.  This assumes the same polling by the management of
     the agent.


Some of the trade-offs of these options were considered.  Option 1
doesn't use traps but requires a high enough poll frequency (or a large
amount of memory in the agent) to minimize the loss of call records.
Options 2 and 3 improve reliability, and differ in their complexity.

We considered the 30 some events which were included in the draft.
There was strong objection to defining 30 traps.  The group thought the
call history record provided an adequate record of the event.  It was
decided not to define traps for events.


The Next Step

The group hopes to produce the Internet-Draft by the end of July.  At
that point, it will be subject to review on the working group mailing
list.


Attendees

Toshiya Asaba            [e-mail]
John Ballard             [e-mail]

                                   3





Jim Barnes               [e-mail]
Jeff Case                [e-mail]
Michael Erlinger         [e-mail]
Marco Hernandez          [e-mail]
Mark Lewis               [e-mail]
Kim Chr.  Madsen         [e-mail]
George Mouradian         [e-mail]
David Perkins            [e-mail]
John Plate               [e-mail]
Lars Poulsen             [e-mail]
Marshall Rose            [e-mail]
Rick Royston             [e-mail]
Jon Saperia              [e-mail]
William Simpson          [e-mail]
Timon Sloane             [e-mail]
Steven Waldbusser        [e-mail]



                                   4