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 asaba@iij.ad.jp John Ballard jballard@microsoft.com 3 Jim Barnes barnes@xylogics.com Jeff Case case@cs.utk.edu Michael Erlinger mike@jarthur.claremont.edu Marco Hernandez marco@mh-slip.cren.edu Mark Lewis Mark.S.Lewis@telebit.com Kim Chr. Madsen kimcm@ic.dk George Mouradian gvm@arch3.att.com David Perkins dperkins@synoptics.com John Plate plate@ic.dk Lars Poulsen lars@cmc.com Marshall Rose mrose@dbc.mtview.ca.us Rick Royston rroyston@usr.com Jon Saperia saperia@tay.dec.com William Simpson Bill.Simpson@um.cc.umich.edu Timon Sloane timon@timon.com Steven Waldbusser waldbusser@andrew.cmu.edu 4