home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
ietf
/
modemmgt
/
modemmgt-minutes-93jun.txt
< prev
next >
Wrap
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 jbain@uds.mot.com
Les Brown brown_l@msm.cdx.mot.com
Ted Brown ewb@telebit.com
Alan Clark aclark@hayes.com
Thomas Holodnik tjh@andrew.cmu.edu
Mark Lewis Mark.S.Lewis@telebit.com
James Logan logan@penril.com
Chris Payson c_payson@telebit.com
Gregory Pearson
Bill Richards richards@gdc.com
Rick Royston rroyston@usr.com
Erik Snoek sdrierik@diamond.sara.nl
Richard Stuart dickstuart@attmail.com
Steven Waldbusser waldbusser@andrew.cmu.edu