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

Text File | 1993-09-24 | 11KB | 277 lines

INTERIM_MEETING_REPORT_

Reported by Thomas Holodnik/Carnegie Mellon University

Minutes of the Modem Management Working Group (MODEMMGT)

A meeting of the Modem Management Working Group was held in Baltimore,
June 28-29.


Agenda

   o Outline
   o Introductions
   o Broad issues
   o Structure of the MIB
   o Detailed review
   o Next meeting


Broad Issues

Security
    Options are
        - R/O on R/W objects (version 1 SNMP)
        - Allow SNMP sets (with version 1 or 2)
        - Leave it to the user to enable sets on each variable

Our strategy is to utilize SNMP Version 1 techniques to the extent
this is possible. There is a very large installed base of SNMP
version 1; using version 2 exclusively at this time would hamper the
immediate effectiveness of our work.

Utilizing SNMP Version 2 would address most (if not all?) security issues.

Size, Scope, and Expectations of the MIB

There are many common features we can collectively manage.  Apply the
80/20 rule; we may not create entries for every common Hayes AT
command or S register; we want to create entries for the 80% that is
useful and commonly implemented.

We can't require new features to be implemented in any modems, or
require changes to the way certain features are implemented. For
optional objects, it is best if they are grouped together. Maximize
the number of commonly managed objects.

Estimate the number of objects at 100 +/- 50.  Timeframe is to be
completed the end of the year.  Attempt to build a draft shortly, and
place it up for review.  Go through two cycles of draft and review and
submit it to the standards track before the end of the year. I/D that
is very close at the end of the year is the goal.

Estimate the date that the RFC emerges to be sometime 1Q94, pending
implementation from major vendors. Once its an RFC, it's safe to ship
conforming products.  Initially, the ID will define MIB objects in the
experimental space (i.e., don't ship products with support for
experimental objects). The RFC will specify objects in the SNMPv2
space.

When the names change, the OIDs change, the meaning of variables
cannot change.

The standards track proceeds as follows. Once a document is submitted
as an RFC, it passes through these steps: proposed standard -> draft
standard -> full standard.  Having working code insures uneventful
transitions from one level to the next.


The ITU group is developing V.im.  The TIA (TR 30.4) group is
developing another SNMPized V.im document.  The modem management group might
produce something close to these other groups, but cannot officially
tie their work to other bodies.

The V.im document is useful, but too exhaustive.  It ought to be
utilized/consulted for completeness, but many items in the document
are fairly common across all the submitted MIBs.

There was some discussion of the tension between wanting to manage the
commodity market in modems, while the modem vendors in attendance, and
the immediate implementations of the modem MIB will not be built upon
commodity-market modems, but the chassis mounted and managed modems.

To what we extent do we address FAX? V.Fast? Voice? Video?  Voice
interim standard?  FAX ought to be addressed.  Can't sell modems w/o
it.  Those features about FAX that are common to data transmission
ought to be supported.


Structure of the MIB

Leased line modems represent some unique challenges to the model we
construct.  In leased line modem applications, there may be multiple
logical connections over one physical modem connection, with
muliplexing done at the V.42 level.  These are fairly common among
users, according to modem vendors. These require multiple instances
for data dump/line interfaces, or multiple compression or error
correction protocols for one interface. Is this commodity?  Does this
represent the users view of modem like devices? Presented with this,
will the user understand how to manage a modem like device with this
MIB?

How do we define groups such that we can anticipate the kinds of
components that may be assembled in a modem like device?

We assume leased line modems are more like dial line modems than they
are not like them.  Our strategy is to produce one document that
describes both kinds of equipment, but that will have optional groups
for those features that are unique to synchronous and asynchronous,
leased and dialup modems.

In the MIB tree, we take the modem interfaces to be on a lower level
abstraction below the logical chassis subcomponent abstraction.  Use
the chassis MIB abstraction to characterize the modems in the
chassis.

There were two proposals for constructing the MIB:
    - placing the modem logically into the SNMP v2 interfaces MIB.
    - placing the modem logically into an entry under the chassis MIB.

It may make most sense to insert the modem into the table for the
chassis MIB. The chassis MIB is essentially a directory service for
the collection of devices it groups together.  It's a matter of
convenience.

Need three tables to describe the configuration and the features found
in the modem:
    capabilities  - available features
    configuration - what is configured for this modem
    current state - what settings are currently in use (i.e., negotiated
                        for the current session)

common groups (hopefully large) - mandatory status

Optional groups:
    dial line group (async implied here)
    leased line group
    Sync group
    security group
    compression group
    FAX group
    signal converter group
    call records
    events

Implementation note:  if you return other it indicates that you need
to refer to a enterprise specific MIB for further information.

There was discussion about the addition of a "call record" group,
which is intended to indicate a summary of information about the last
N sessions (where N was not defined) on each modem in the chassis.
Since many modem vendors implement call records of this sort in their
proprietary MIBs, moving it to the standard modem MIB seemed to make
sense. Possible applications of these call records might include
billing, security audits, performance, and fault management.

The discussion over call records demonstrated a difference in the
traditional view of SNMP Agents versus the proxy SNMP Agent for modem
management that many vendors are planning to implement. Most SNMP
agents are kept deliberately simple, with a view toward being fast,
and small. Most SNMP agents reside on devices that are not dedicated
to network management.  The SNMP proxy agent is likely to reside on a
card or on a PC with relatively plentiful amounts of memory and
processor available; the distinction being that the SNMP proxy agent
will reside on a device whose job it is to perform network
management.  Some parallels were drawn to the RMON MIB (RFC 1271).

Call records would be kept in addition to the globally maintained
counters for each modem, but would be a subset of the list.  The
contents of the call records was left unresolved for now.

Table management for Call Records:

Some ideas might be obtained from the RMON MIB (RFC 1271).  Other
information may be in RFC 1451 (SNMPv2).  Agent may have statically
defined limit on the number of call records.

There's an index into the table per call record. Use the SNMP get-next
operator to scan the call record table.  The last entry in the table
for this particular modem is retrieved when the next value returned is
identified by an object ID that doesn't match the same modem table
being scanned.  If the return value indicates a jump in the index, the
proxy agent lost records.

Events and Call Records should still be considered separately.



Action Items and Other Significant Points of Discussion

The attendees spent considerable time reducing the number of MIB objects
deemed to be of little use, while some conveyed additional information
that many felt was omitted in the initial MIB.


   o A general statement is needed about vendors that may not support
     all values in the range specified.  While many vendors may not
     support all values in the range specified, they will still be
     considered compliant with the MIB. RFC 1444 (SNMPv2 SMI) specifies
     that the range of the SYNTAX clause specifies the range that the
     variable may take which makes sense within the protocol.

   o A general statement is needed indicating that many settings are
     country-specific (i.e., that many are set according to national
     standards).  It may be permissible to change certain settings in
     one country but not another.  Certain features may only be useful
     in one country but not another.  Transmitter-level setting changes
     are illegal in some countries.  This needs to be noted in the MIB.
     Regulatory agencies take precedence over what is allowed in the
     MIB.

   o Is it desirable to manage remote modems via SNMP and modem proxy
     agents?  That is, in addition to managing the chassis modem, you
     may also need to manage the stand-alone modem (via SNMP). The
     mechanics for this were left unresolved.

   o Progress reports on V.id and V.Fast developments are needed.
     V.Fast will require additional objects or changes to existing
     objects.  A list of these should be kept to give V.Fast adequate
     treatment.  Power level adjustments are permitted under V.Fast.

   o The connect failure reasons will need to be edited (reduced to a
     manageable size).

   o The last call statistics group needs to be split into call
     statistics (to be renamed) and signal converter statistics.  It was
     decided that many statistics kept over the last call were not
     terribly useful, but that some information should be kept for
     summary and reporting purposes.

   o The list of MIB variables that need to be included in the call
     records should be developed further.  The architecture for call
     records needs to be clearly developed.

   o The modem MIB is to be experimental subtree 49.

   o A good way to measure throughput is needed.  Offered load is a
     strong factor in determining this.  There is no agreement on this
     yet.

   o The number of MIB variables and the time to construct the list of
     MIB variables, for the leased-sync area and the dial-asynch area,
     need to be carefully managed.  If either of the two areas bog down
     or blow up, it should be jettisoned into another MIB.



Next Meeting

No date was set, pending work between now and the IETF plenary meeting
in Amsterdam (7/12 through 7/16).

Proposals were:

1.) EIA/TIA  TR30.4 meets July 20, in Boston.
2.) Aug 23-27 INTEROP SF.  Weekend before INTEROP?



Attendees

Jay Bain                 [e-mail]
Les Brown                [e-mail]
Ted Brown                [e-mail]
Alan Clark               [e-mail]
Thomas Holodnik          [e-mail]
Mark Lewis               [e-mail]
James Logan              [e-mail]
Chris Payson             [e-mail]
Gregory Pearson
Bill Richards            [e-mail]
Rick Royston             [e-mail]
Erik Snoek               [e-mail]
Richard Stuart           [e-mail]
Steven Waldbusser        [e-mail]