From: anne@spider.co.uk (Anne Ambler)
Newsgroups: comp.dcom.isdn
Subject: Suggestions for an ISDN MIB (quite long)
Date: 17 Dec 92 18:40:02 GMT
Organization: Spider Systems Limited, Edinburgh, UK

Spider Systems develops ISDN Routers and Management Stations, and we are
therefore very interested in the progress of an ISDN MIB.

There has been some discussion of ISDN MIBs on the group "imib@netcs.com".
I also believe that the iplpdn group plan to discuss ISDN MIBs at the 
next IETF meeting in March.  Can anyone confirm this?  What is the 
relationship, if any, between the imib@netcs.com discussion list and 
the IETF?  Which group is the right one for discussion of ISDN MIBs?  Is
this too specialised for the generic snmp mailing group?  Please forgive
me if I am posting to the wrong groups.



Oliver Korfmacher (okorf@netcs.com) has posted a proposed draft MIB
and this message contains some general comments on it, plus an outline of 
our suggested MIB for ISDN.

My main comment on the netcs MIB is that it seems to be re-inventing 
what other MIBs already do.  I think its important that a dumb 
management station, which only supports MIB-II, should be able to find
out as much as possible about an ISDN interface.  As much use as possible 
should be made of MIB-II.  Also one day there will probably be a LAPD 
MIB, and we should use this.

I think the main problems in designing an ISDN MIB are as follows, and 
none of them are unique to ISDN. 
1) many B channels in one physical interface.  (c.f. X.25 logical connections)
2) there can be more than one physical interface to the ISDN net.  (c.f. 
   a dual X.25 interface)
3) Dial up.  A B channel can be connected to different things at different 
   times.  e.g. Net A in London one minute, Net B in Dusseldorf the next
   minute.  Any sort of dial up line will have these problems too.

The following diagram of ISDN may help:

                       +---------+
                       | Q.931   |
                       |(Call    |                   Layer 3
                       | control)|
                       +---------+
                            |
      B channel        +---------+
      protocols        |         |
                       |  LAPD   |                   Layer 2
          ||           |         |
          ||           +---------+
          ||                |
          || B channels     | D channel
          || (several)      |
          ||                |
       +-------------------------+
       |                         |
       |   Physical Interface    |                   Layer 1
       |                         |
       +-------------------------+
        


There are five sections to this proposed way of doing the ISDN MIB.
1. Use of Interfaces group of MIB-II for ISDN
2. ISDN Layer 1 specifics
3. Layer 2 (LAPB / Q.921)
4. Layer 3 (Q.931 / variants)
5. Higher Layers over B Channels

I haven't tried to put these ideas into a proper MIB format yet, but I 
have suggested how each table should be indexed.  Associated with each
table there should be an object identifier which gives the size of the 
table, and I haven't shown these either.

It also says nothing about traps.  

1. Use of Interfaces group of MIB-II for ISDN
---------------------------------------------
I think people have already commented that it would be sensible to use the 
MIB-II Interfaces Group to access a lot of the information about an ISDN line.

But what is an Interface (in the MIB-II sense)?  It can either be a physical
connection, i.e. a Basic or Primary Rate connection, or it can be a B or a 
D channel (or other types of channel e.g. H0, in the future).  The Interfaces
group is far more useful if an interface is a B or D channel.  The packet
and error counts are more meaningful, but perhaps most importantly the 
references that other MIBs make to ifIndex make most sense if ifIndex is
a B channel.

MIB-II gives basicISDN or primaryISDN as allowable values of ifType.
Is it possible to add isdnBChannel, isdnDChannel etc.?

At the end of this mail I've appended the Interfaces group of MIB-II, with 
extra lines (starting *** ) suggesting how each element should be used.

I know that for Primary Rate there would be 30 (or 23) B channels, and this
does seem a lot of entries in the Interface table.  But, lets face it, a 
device supporting Primary Rate is in many ways its like a box with 30 
serial lines, and they would appear in the Interfaces table.

2. ISDN Layer 1 specifics
-------------------------
This is where Layer 1 information that is not contained in MIB-II should go.
E.g. what connector type, and which B and D channels are associated with which 
physical interface.

    Connector Number
    Type                - Basic Rate, Primary Rate (Europe/US?)
    No. of B channels
    Connector(Jack) type
    Possibly some addressing information, e.g. which subaddress to use.

Indexed by connector number.

I guess only the subaddress should be writeable - the rest read only.
Addressing is a tricky question, as Multiple Subscriber Numbering means
that an ISDN line to an exchange (CO switch) can have several 
numbers, and Hunt Groups mean that a single number can (effectively) 
reach several ISDN lines.

A table to link physical B and D channels to their ifIndex would also be 
needed.

    Connector Number
    D channel or B channel no.
    ifIndex

Indexed by Connector Number, and by D/B channel no.
One might also want an equivalent table indexed by ifIndex to do the 
mapping in the reverse direction (i.e. given an ifIndex, which channel on 
which connector does it correspond to?).
Read only.

3. Layer 2 (LAPB / Q.921)
-------------------------
rfc1381 is an X.25 LAPB MIB, and I believe some work has been done 
on a CMIP "MIB" for LAPD.  I guess the LAPD MIB should take rfc1381 as 
a starting point.  I haven't thought much about what should go in here, 
except that it should be indexed by D channel number (i.e. the D channel's 
ifIndex), and should show the status of any LAPD connections, plus 
statistics on frames and errors.

4. Layer 3 (Q.931 / variants)
-----------------------------
I propose three tables, and some miscellaneous information.

For each D channel: 

a)  Call state table.  For all calls that are not in the null state:

    D channel ifIndex
    Call Reference
    Call State (e.g. Active)
    whether Incoming or Outgoing
    called address and sub-address
    calling address and sub-address
    associated B channel - identified by its ifIndex.  
    bearer capability - i.e. voice, 64k data etc.
    and more

Indexed by D channel ifIndex, and Call Reference.
Read only.

Call Reference is the only unique thing you can index this table by.
The B channel is no good as an index as not all calls will have a B 
channel associated with them - e.g. calls in the "Call Initiated" state 
won't yet have had a B channel assigned, and calls using "Temporary 
Signalling Connections" will never have a B channel.

b) Call statistics.  For all incoming and outgoing calls since sysUpTime=0

    D channel ifIndex
    Number of incoming calls offered to the higher layer(s) and accepted 
    Number of incoming calls offered to the higher layer(s) and not accepted 
    Number of incoming calls not offered to the higher layer(s)
    Number of outgoing calls answered by remote user
    Number of outgoing calls not answered by remote user
    Cause of most recent outgoing call failure

Indexed by D channel ifIndex.
Read only.


c) Q.931 Timers.  

    D channel ifIndex
    Timer number - as in Q.931 specification
    Timer value

Indexed by D channel ifIndex, and Timer number
Read, and for some implementations write.

d) Miscellaneous

    Flavour of "Q.931" supported (BTNR 191, VN3, 1TR6, US variants, plus
      version number).  
Read and in some implementations write.

    Software version number?
Read only

    Other configurable/non-configurable parameters.

5. Higher Layers over B Channels
--------------------------------
Layers 2, 3 etc on the B channel should be exactly the same as on a 
leased line or any other kind of interface.  They should not need a 
special ISDN MIB.  

e.g. for implementations that use PPP on the B channel - I thought I 
saw something about a PPP MIB.  It almost certainly uses ifIndex to 
indicate which interface is being referred to.

[Of course ISDN can carry voice, FAX, etc. as well as data]

What is missing?
----------------
The full subtlety of activated/connected status.
Priorities on the D channel?
Manufacturer - use what is in MIB-II System Group.
Encapsulation - should be solved in the same way as for (e.g.) leased lines 
or dial-up lines.  PPP MIB or rfc1294 MIB, when they exist.

Appendix 
--------
This contains extracts from MIB-II Interfaces group, with comments (starting 
*** ) suggesting exactly how these values should be used for an ISDN B or D 
channel.

          -- the Interfaces table

          -- The Interfaces table contains information on the entity's
          -- interfaces.  Each interface is thought of as being
          -- attached to a `subnetwork'.  Note that this term should
          -- not be confused with `subnet' which refers to an
          -- addressing partitioning scheme used in the Internet suite
          -- of protocols.
*** Have an interface per B or D channel (rather than per wire).  Does this
*** break what is said here?  It certainly fits better.  

.
.  (deleted)
.

          IfEntry ::=
              SEQUENCE {
                  ifIndex
                      INTEGER,
*** OK
                  ifDescr
                      DisplayString,
*** OK
                  ifType
                      INTEGER,
*** basicISDN and primaryISDN don't fit here.  What is needed is isdnBChannel,
*** isdnDChannel, isdnH0Channel etc.  B and D are the main ones.
                  ifMtu
                      INTEGER,
*** OK
                  ifSpeed
                      Gauge,
*** 64k for B.  16k or 64k for D (depending if its BRI or PRI)
                  ifPhysAddress
                      PhysAddress,
*** Problem with Multiple Subscriber numbers and subaddressing here.
                  ifAdminStatus
                      INTEGER,
*** For B channel:
***   Up = connected end-to-end
***   Down = not connected end to end, (but physical wire may be connected)
***   Testing = testing
*** For D channel:
***   Up = BRI - Interface activated, or interface connected?  There is 
***   difference, but not all equipment can detect whether its connected.
***   Down = not connected (ideally), but possibly not activated.
***   Testing = testing
                  ifOperStatus
                      INTEGER,
*** As above
                  ifLastChange
                      TimeTicks,
*** OK
                  ifInOctets
                      Counter,
*** For the B (or D) channel
                  ifInUcastPkts
                      Counter,
*** All packets are unicast?  Or are D channel packets on a S bus bcast?
                  ifInNUcastPkts
                      Counter,
*** see above
                  ifInDiscards
                      Counter,
*** OK
                  ifInErrors
                      Counter,
*** CRC or framing errors
                  ifInUnknownProtos
                      Counter,
*** OK
                  ifOutOctets
                      Counter,
*** OK - as for any HDLC serial line
                  ifOutUcastPkts
                      Counter,
*** all unicast
                  ifOutNUcastPkts
                      Counter,
*** all unicast
                  ifOutDiscards
                      Counter,
*** OK
                  ifOutErrors
                      Counter,
*** OK
                  ifOutQLen
                      Gauge,
*** OK - and only makes sense for a B or a D channel, not for an entire ISDN
*** interface
                  ifSpecific
                      OBJECT IDENTIFIER
*** What here?  Could point to the table described in section 2.
              }


-- 
Anne Ambler                         anne@spider.co.uk
Spider Systems                      tel. (44) 31 554 9424
Edinburgh, UK.