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.