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