CURRENT_MEETING_REPORT_ Reported by Jim Fenton/Combinet Minutes of the ISDN MIB BOF (ISDNMIB) ISDNMIB met in Danvers as a BOF and has since become a working group. The ISDNMIB BOF was held on 5 April and had approximately 45 attendees. The group was chaired by Ed Alcoff, Combinet, and Fred Baker, Cisco Systems. Mailing list: isdn-mib@combinet.com To subscribe: majordomo@combinet.com Include in body of message: subscribe isdn-mib e-mail address Fred Baker -- Cisco Systems draft-ietf-snmp-isdn-cisco-00.txt Cisco's MIB has no hardware control; it manages dial-neighbor relationships. It keeps some recent history, primarily for debugging (``call flap''). It manages dial-on-demand neighbors, permissions, etc., and uses the stack table model to represent link/channel relationships which change dynamically. The history table keeps caller/callee name/number, duration and time of call, and the reason for disconnect. Size and persistence of the history table are configurable. Gunter Roeck - Conware GmbH draft-roeck-isdn-mib-ext-00.txt Conware's MIB goals are to manage existing modules entirely with SNMP. Supports non-ISDN leased lines and ISDN dialup/leased lines with one MIB. Media independent multilink support. Support for backup lines; 1TR6, DSS1, ISDN leased lines; BRI and PRI support. NET3 is like DSS1. Static configuration, fixed relationship of links to B channels. No facility for oversubscribing. Exactly one neighbor per B channel. Roeck feels multilink and backup should not be part of ISDN MIB. Groups for non-ISDN leased lines, for B channel and neighbor configuration, and for multilink and backup handling (with a static relationship to B channels). No hardware-related information in the MIB. They are not PC board-based, so CAPI is not relevant. Call history group similar to Cisco's MIB. ISDN group has separate tables for configuration and statistics, also port status and accounting events. Global objects for channel count and firmware version. Supports a variable number of B channels; no direct visibility on number of BRIs, PRIs, etc. (i.e. number of D channels). Tryphon Chiotis -- Netmode draft-ietf-snmp-isdn-netmode-01.txt There are three groups: controller, contains general information about the controller; port group, contains information over connection over a single B channel; and connection group. Controller table: static information, e.g., S/N, I/O address, state of controller, D channel protocol. Points to MIB-II for data related information. Statistics table contains information on number of successful/reject connections, etc. Port table: Number/duration of connections, charges, inactivity time, etc. Points to ISDN facilities table to define which facilities will be engaged, points to interface group for information on packets over B channel. Connection table: information on a single connection, destination address, connection type, connection state, etc. Points to facilities table to define which facilities will be used. Facilities table keeps information on support services, e.g., call transfer, forwarding, advice of charge, reverse charging. Limited number of entries maintained. Extensions planned include SNMPv2, boards with bandwidth on demand capabilities, pointers to higher level management information. Ravi Subramaniam -- IBM draft-ietf-snmp-isdn-ibm-00.txt Multiple DLCs (PPP, FR) running over B channels. Applications using DLCs. ISDN interface table -- port attachment level objects, aggregate counter for all B channels. Call control MIB -- remote DTE call level management objects. Circuit table -- remote DTE operational objects. B channel table -- channel operational table. Objectives of an ISDN MIB A discussion on the objectives of an ISDN MIB was held: o Manage the controller - D channel attributes - TEI - Switch type - Layer 1 stuff (for BRI) - B channels - L2 and L3 o Status o Call neighbors - Who can call/be called o Statistics o Binding to B channels o Call history (debug/accounting) - Calls - Failures - at least recent o Interoperation - Multilink - Calls on other technologies - Differing B channel protocols Other issues: NFAS, use of digital modems vs. HDLC, etc. Need to index everything by base controller to support multiple BRI and/or PRI. There was general consensus that an ISDN MIB should consist of two MIBs: ISDN attributes, i.e., v.110/120 by neighbor; and dial-on-demand, i.e., attributes that are not ISDN specific. It was agreed to use RFC 1573 to define layering issues. It was also agreed that some issues/attributes should be dealt with in vendor-specific MIBs. ISDN MIB Design Goals and Non-Goals, Attributes, Etc. A discussion was held on ISDN MIB design goals and non-goals: o Goals: - Remote configuration/administration - Support all ISDN interfaces and switch types statistics - Call history - Traps o Non-goals: - Unusable or irrelevant info - Information in other MIBs - Multilink - Static neighbor-port relationship There was general agreement that the following attributes need support in an ISDN MIB: o Port configuration group o Basic configuration for each B and D channel o Call/neighbor group o Information related to each neighbor o Configuration and neighbor related statistics o Statistics group o B and D channel statistics o Accounting o Traps Guenter Roeck sat down before the meeting and concocted a way to merge the four proposed MIBs, based on a straight merge of the Conware and Cisco MIBs, and inclusions from the Netmode and IBM MIBs. It took this structure: o Port Configuration Group - Number of D and B channels - Additional information (e.g., firmware version, controller type) D channel table - Interface type (BRI, PRI, ...) - Switch type - Pointer to X.25 related info - Charging enabled/disabled flag - TBD, ifSpeed, ifStructure - B channel table - Associated D channel ifIndex - my_address (must not be neighbor based) - my_subaddress/my_eaz - Call forward information (?) - Security enable/disable flag o Call Neighbor Group - Configuration table -- describes each potential neighbor - Physical interface -- pointer to D or B channel; for SPV, leased lines, and CUG, else 0 (dynamic) - Permissions (incoming and outgoing) - Called number/subaddress - Closed user group - Connection type (dialup, SPV, leased, etc.), connection information - On demand, active, backup, passive - Timeout information - Callback, reverse charge, send own EAZ (1TR6) flags Max number of retries - TBD: Link later/encapsulation layer protocols (or use ifStack?) - TBD: ISDN L2/L3 protocols, OperStatus, AdminStatus o Statistics Table - Last call duration - Clear reason (ASCII) - Clear code (encoded) - Number of successful, failed, accepted, refused calls; time of last call attempt - Current status (administrative, operational) - Calling/called flag - Number of charged units for current/last call; calling number/subaddress for current/last call as delivered by net TBD: ifIndex for current/last call, B channel number, ... o Statistics Group - D channel Statistics - L1/L2/L3 - B channel Statistics o Accounting/History Group - Configuration/status info - Accounting/history table - TBD: Accounting event table - Event type (e.g., system-on, accounting-on, accounting-off, overflow, internal-error, delete-all), event time o Traps - Accounting/history table overflow - Connected/disconnected There was general agreement that the following attributes do not need to be supported: o Hardware related information, e.g., I/O addresses o Multilink related data o ISDN L1/L2/L3 specific data, e.g., timers, TEI information call forwarding information (is it useful in a router?) o Support of calling/called line information restriction opts (caller ID blocking) (security hole) o Information supported by ifTable There was general consensus that an ISDN MIB should not be ``router-specific'' and that products that support a headset or POTS interface should also be addressed. There was general agreement that the proposed MIB should be divided into two stand-alone MIBs produced by the same working group: one addressing call management on occasional access technologies (including but not limited to ISDN), and the other addressing ISDN specifically. The two together are necessary to manage an ISDN interface, but the occasional access MIB would be able to use V.25 bis, X.21, or other ``on demand'' technologies as well. Note that PPP Multilink might use an ISDN Call Neighbor as one of the links in a multilink bundle; the MIB structure needs to enable this to be straightforward. ISDN B channels should be type ``other''; ISDN D channels should be either ``BRI'' or ``PRI''. A suggestion was made that an ISDN MIB only handle things that are mandatory or commonly required with respect to ISDN service. Issues to be resolved: o How to connect incoming calls to upper layer? o How to get the called (remote) number from upper layers? o Multilink handling (several neighbor entries to same destination). o Do we expect the customer to enter calling/called number information? o Restrictive call permissions can be problematic with low disconnect (timeouts: server might respond after disconnect). o Do we need PPP/MLPPP configuration parameters? o Relationship (D and B channel interfaces) to ifEntries. o Differences between calling number (caller ID) and callback number (differ by leading or trailing digits or can be entirely different). There was a general consensus that an ISDN MIB Working Group be formed. Guenter Roeck volunteered to be the technical editor.