draft-ietf-isdnmib-snmp-isdn-mib-07.txt   rfc2127.txt 
INTERNET-DRAFT ISDN MIB August 1996 Network Working Group G. Roeck, Editor
Request for Comments: 2127 cisco Systems
ISDN Management Information Base Category: Standards Track March 1997
draft-ietf-isdnmib-snmp-isdn-mib-07.txt
Fri Aug 23 09:15:06 PDT 1996
Guenter Roeck (editor) ISDN Management Information Base using SMIv2
cisco Systems
groeck@cisco.com
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document specifies an Internet standards track protocol for the
documents of the Internet Engineering Task Force (IETF), its Areas, and Internet community, and requests discussion and suggestions for
its Working Groups. Note that other groups may also distribute working improvements. Please refer to the current edition of the "Internet
documents as Internet-Drafts. Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as a "work in progress".
To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract Abstract
This memo defines an experimental portion of the Management Information This memo defines a portion of the Management Information Base (MIB)
Base (MIB) for use with network management protocols in the Internet for use with network management protocols in the Internet community.
community. In particular, it defines a minimal set of managed objects In particular, it defines a minimal set of managed objects for SNMP-
for SNMP-based management of ISDN terminal interfaces. ISDN interfaces based management of ISDN terminal interfaces. ISDN interfaces are
are supported on a variety of equipment (for data and voice) including supported on a variety of equipment (for data and voice) including
terminal adapters, bridges, hosts, and routers. terminal adapters, bridges, hosts, and routers.
This document specifies a MIB module in a manner that is compliant to This document specifies a MIB module in a manner that is compliant to
the SNMPv2 SMI. The set of objects is consistent with the SNMP the SNMPv2 SMI. The set of objects is consistent with the SNMP
framework and existing SNMP standards. framework and existing SNMP standards.
This document is a product of the ISDN MIB working group within the This document is a product of the ISDN MIB working group within the
Internet Engineering Task Force. Comments are solicited and should be Internet Engineering Task Force. Comments are solicited and should
addressed to the working group's mailing list at isdn-mib@cisco.com be addressed to the working group's mailing list at isdn-
and/or the author. mib@cisco.com and/or the author.
The current version of this document reflects changes made during the The current version of this document reflects changes made during the
last call period and the IESG review. last call period and the IESG review.
Table of Contents Table of Contents
1 The SNMPv2 Network Management Framework ......................... 3 1 The SNMPv2 Network Management Framework ...................... 2
2 Object Definitions .............................................. 3 2 Object Definitions ........................................... 2
3 Overview ........................................................ 4 3 Overview ..................................................... 3
3.1 Structure of the MIB .......................................... 4 3.1 Structure of the MIB ....................................... 3
3.1.1 General Description ......................................... 4 3.1.1 General Description ...................................... 3
3.2 Relationship to the Interfaces MIB ............................ 5 3.2 Relationship to the Interfaces MIB ......................... 4
3.2.1 Layering Model .............................................. 5 3.2.1 Layering Model ........................................... 4
3.2.2 ifTestTable ................................................. 8 3.2.2 ifTestTable .............................................. 8
3.2.3 ifRcvAddressTable ........................................... 8 3.2.3 ifRcvAddressTable ........................................ 8
3.2.4 ifEntry ..................................................... 8 3.2.4 ifEntry .................................................. 8
3.2.4.1 ifEntry for a Basic Rate hardware interface ............... 8 3.2.4.1 ifEntry for a Basic Rate hardware interface ............ 8
3.2.4.2 ifEntry for a B channel ................................... 9 3.2.4.2 ifEntry for a B channel ................................ 9
3.2.4.3 ifEntry for LAPD (D channel Data Link Layer) .............. 10 3.2.4.3 ifEntry for LAPD (D channel Data Link Layer) ........... 10
3.2.4.4 ifEntry for a signaling channel ........................... 12 3.2.4.4 ifEntry for a signaling channel ........................ 12
3.3 Relationship to other MIBs .................................... 14 3.3 Relationship to other MIBs ................................. 14
3.3.1 Relationship to the DS1/E1 MIB .............................. 14 3.3.1 Relationship to the DS1/E1 MIB ........................... 14
3.3.2 Relationship to the DS0 and DS0Bundle MIBs .................. 14 3.3.2 Relationship to the DS0 and DS0Bundle MIBs ............... 14
3.3.3 Relationship to the Dial Control MIB ........................ 14 3.3.3 Relationship to the Dial Control MIB ..................... 14
3.4 ISDN interface specific information and implementation hints 3.4 ISDN interface specific information and implementation hints
.............................................................. 14 ........................................................... 14
3.4.1 ISDN leased lines ........................................... 14 3.4.1 ISDN leased lines ........................................ 14
3.4.2 Hyperchannels ............................................... 15 3.4.2 Hyperchannels ............................................ 15
3.4.3 D channel backup and NFAS trunks ............................ 15 3.4.3 D channel backup and NFAS trunks ......................... 16
3.4.4 X.25 based packet-mode service in B and D channels .......... 16 3.4.4 X.25 based packet-mode service in B and D channels ....... 16
3.4.5 SPID handling ............................................... 16 3.4.5 SPID handling ............................................ 17
3.4.6 Closed User Groups .......................................... 17 3.4.6 Closed User Groups ....................................... 17
3.4.7 Provision of point-to-point line topology ................... 17 3.4.7 Provision of point-to-point line topology ................ 18
3.4.8 Speech and audio bearer capability information elements ..... 18 3.4.8 Speech and audio bearer capability information elements .. 18
3.4.9 Attaching incoming calls to router ports .................... 18 3.4.9 Attaching incoming calls to router ports ................. 19
3.4.10 Usage of isdnMibDirectoryGroup and isdnDirectoryTable ...... 19 3.4.10 Usage of isdnMibDirectoryGroup and isdnDirectoryTable ... 20
4 Definitions ..................................................... 20 4 Definitions .................................................. 21
5 Acknowledgments ................................................. 44 5 Acknowledgments .............................................. 47
6 References ...................................................... 44 6 References ................................................... 47
7 Security Considerations ......................................... 45 7 Security Considerations ...................................... 49
8 Author's Address ................................................ 46 8 Author's Address ............................................. 49
1. The SNMPv2 Network Management Framework 1. The SNMPv2 Network Management Framework
The SNMPv2 Network Management Framework presently consists of three The SNMPv2 Network Management Framework presently consists of three
major components. They are: major components. They are:
o the SMI, described in RFC 1902 [1] - the mechanisms used for o the SMI, described in RFC 1902 [1] - the mechanisms used for
describing and naming objects for the purpose of management. describing and naming objects for the purpose of management.
o the MIB-II, STD 17, RFC 1213 [2] - the core set of managed objects o the MIB-II, STD 17, RFC 1213 [2] - the core set of managed
for the Internet suite of protocols. objects for the Internet suite of protocols.
o the protocol, RFC 1157 [3] and/or RFC 1905 [4], - the protocol for o the protocol, STD 15, RFC 1157 [3] and/or RFC 1905 [4], -
accessing managed objects. the protocol for accessing managed objects.
The Framework permits new objects to be defined for the purpose of The Framework permits new objects to be defined for the purpose of
experimentation and evaluation. experimentation and evaluation.
2. Object Definitions 2. Object Definitions
Managed objects are accessed via a virtual information store, termed the Managed objects are accessed via a virtual information store, termed
Management Information Base or MIB. Objects in the MIB are defined the Management Information Base or MIB. Objects in the MIB are
using the subset of Abstract Syntax Notation One (ASN.1) defined in the defined using the subset of Abstract Syntax Notation One (ASN.1)
SMI. In particular, each object type is named by an OBJECT IDENTIFIER, defined in the SMI. In particular, each object type is named by an
an administratively assigned name. The object type together with an OBJECT IDENTIFIER, an administratively assigned name. The object
object instance serves to uniquely identify a specific instantiation of type together with an object instance serves to uniquely identify a
the object. For human convenience, we often use a textual string, specific instantiation of the object. For human convenience, we
termed the descriptor, to refer to the object type. often use a textual string, termed the descriptor, to refer to the
object type.
3. Overview 3. Overview
3.1. Structure of the MIB 3.1. Structure of the MIB
For managing ISDN interfaces, the following information is necessary: For managing ISDN interfaces, the following information is necessary:
o Information for managing physical interfaces. In case of ISDN o Information for managing physical interfaces. In case of ISDN
primary rate, this are usually T1 or E1 lines, being managed in the primary rate, this are usually T1 or E1 lines, being managed in
DS1/E1 MIB [12]. For Basic Rate lines, physical interfaces are the DS1/E1 MIB [12]. For Basic Rate lines, physical interfaces
managed by this MIB. are managed by this MIB.
o Information for managing B channels. o Information for managing B channels.
o Information for managing signaling channels. o Information for managing signaling channels.
o Optionally, information for managing Terminal Endpoints (TE). A o Optionally, information for managing Terminal Endpoints (TE).
Terminal Endpoint is a link layer connection to a switch. A Terminal Endpoint is a link layer connection to a switch.
o Optionally, information for managing a list of directory numbers. o Optionally, information for managing a list of directory numbers.
In order to manage connections over ISDN lines, the management of In order to manage connections over ISDN lines, the management of
neighbors and call history information is required as well. This peer information and call history information is required as well.
information is defined in the Dial Control MIB [15]. This information is defined in the Dial Control MIB [15].
The purpose for splitting the required information in two MIBs is to be The purpose for splitting the required information in two MIBs is to
able to use parts of this information for non-ISDN interfaces as well. be able to use parts of this information for non-ISDN interfaces as
In particular, the Dial Control MIB might also be used for other types well. In particular, the Dial Control MIB might also be used for
of interfaces, e.g. modems or X.25 virtual connections. other types of interfaces, e.g. modems or X.25 virtual connections.
Within this document, information has been structured into five groups, Within this document, information has been structured into five
which are described in the following chapters. groups, which are described in the following chapters.
3.1.1. General Description 3.1.1. General Description
This MIB controls all aspects of ISDN interfaces. It consists of five This MIB controls all aspects of ISDN interfaces. It consists of
groups. five groups.
o The isdnMibBasicRateGroup is used to provide information regarding o The isdnMibBasicRateGroup is used to provide information
physical Basic Rate interfaces. regarding physical Basic Rate interfaces.
o The isdnMibBearerGroup is used to control B (bearer) channels. It o The isdnMibBearerGroup is used to control B (bearer) channels.
supports configuration parameters as well as statistical
information related to B channels.
o The isdnMibSignalingGroup is used to control D (delta) channels. It supports configuration parameters as well as statistical
There are three tables in this group. The isdnSignalingTable and information related to B channels.
isdnSignalingStatsTable support ISDN Network Layer configuration
and statistics. The isdnLapdTable supports ISDN Data Link Layer
(LAPD) configuration and statistics.
o The optional isdnMibEndpointGroup can be used to specify Terminal o The isdnMibSignalingGroup is used to control D (delta) channels.
Endpoints. It is required only if there are non-ISDN endpoints There are three tables in this group. The isdnSignalingTable and
defined for a given D channel, or if additional information like isdnSignalingStatsTable support ISDN Network Layer configuration
Terminal Endpoint Identifier (TEI) values or Service Profile and statistics. The isdnLapdTable supports ISDN Data Link Layer
IDentifiers (SPID) is required to identify a given ISDN user. (LAPD) configuration and statistics.
o The optional isdnMibDirectoryGroup can be used to specify a list of o The optional isdnMibEndpointGroup can be used to specify
directory numbers for each signaling channel. It is required only Terminal Endpoints. It is required only if there are non-ISDN
if the directory numbers to be accepted differ from the endpoints defined for a given D channel, or if additional
isdnSignalingCallingAddress as specified in the isdnSignalingTable. information like Terminal Endpoint Identifier (TEI) values or
Service Profile IDentifiers (SPID) is required to identify a
given ISDN user.
o The optional isdnMibDirectoryGroup can be used to specify a
list of directory numbers for each signaling channel. It is
required only if the directory numbers to be accepted differ
from the isdnSignalingCallingAddress as specified in the
isdnSignalingTable.
3.2. Relationship to the Interfaces MIB 3.2. Relationship to the Interfaces MIB
This section clarifies the relationship of this MIB to the Interfaces This section clarifies the relationship of this MIB to the Interfaces
MIB [11]. Several areas of correlation are addressed in the following MIB [11]. Several areas of correlation are addressed in the
subsections. The implementor is referred to the Interfaces MIB document following subsections. The implementor is referred to the Interfaces
in order to understand the general intent of these areas. MIB document in order to understand the general intent of these
areas.
3.2.1. Layering Model 3.2.1. Layering Model
An ISDN interface usually consists of a D channel and a number of B An ISDN interface usually consists of a D channel and a number of B
channels, all of which are layered on top of a physical interface. channels, all of which are layered on top of a physical interface.
Furthermore, there are multiple interface layers for each D channel. Furthermore, there are multiple interface layers for each D channel.
There are Data Link Layer (LAPD) as well as Network Layer entities. There are Data Link Layer (LAPD) as well as Network Layer entities.
This is accomplished in this MIB by creating a logical interface This is accomplished in this MIB by creating a logical interface
(ifEntry) for each of the D channel entities and a logical interface (ifEntry) for each of the D channel entities and a logical interface
(ifEntry) for each of the B channels. These are then correlated to each (ifEntry) for each of the B channels. These are then correlated to
other and to the physical interface using the ifStack table of the each other and to the physical interface using the ifStack table of
Interfaces MIB [11]. the Interfaces MIB [11].
The basic model, therefore, looks something like this: The basic model, therefore, looks something like this:
| | | |
+--+ +--+ +--+ +--+
| D ch. | | D ch. |
|Layer 3| |Layer 3|
+--+ +--+ +--+ +--+
| | | | | | <== interface to upper | | | | | | <== interface to upper
+--+ +--+ +--+ +--+ +--+ +--+ layers, to be provided +--+ +--+ +--+ +--+ +--+ +--+ layers, to be provided
| D ch. | | B | | B | by ifStack table | D ch. | | B | | B | by ifStack table
|Layer 2| |channel| .... |channel| |Layer 2| |channel| .... |channel|
+--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+
| | | | | | <== attachment to physical | | | | | | <== attachment to physical
+--+ +--------+ +------------+ +----+ interfaces, to be provided +--+ +--------+ +------------+ +----+ interfaces, to be provided
| physical interface | by ifStack table | physical interface | by ifStack table
| (S/T, U or T1/E1) | | (S/T, U or T1/E1) |
+-----------------------------------+ +-----------------------------------+
Mapping of B/D channels to physical interfaces
Mapping of B/D channels to physical interfaces Each D channel can support multiple Terminal Endpoints. Terminal
Endpoints can either be one or multiple ISDN signaling channels, or
Each D channel can support multiple Terminal Endpoints. Terminal channels supporting X.25 based packet mode services.
Endpoints can either be one or multiple ISDN signaling channels, or
channels supporting X.25 based packet mode services.
To accomplish this, there can be multiple Network Layer entities on top To accomplish this, there can be multiple Network Layer entities on
of each ISDN Data Link Layer (LAPD) interface. The detailed model top of each ISDN Data Link Layer (LAPD) interface. The detailed
therefore looks something like this, including interface types as model therefore looks something like this, including interface types
examples: as examples:
+------+ +----+ +----+ +------+ +----+ +----+
|x25ple| |isdn| |isdn| Terminal Endpoints (X.25 or ISDN) |x25ple| |isdn| |isdn| Terminal Endpoints (X.25 or ISDN)
+--+---+ +-+--+ +-+--+ +--+---+ +-+--+ +-+--+
| | | | | |
| +------+ | | | <== Interface to upper layers, | +------+ | | | <== Interface to upper layers,
| | +------------+ | | to be provided by ifStack | | +------------+ | | to be provided by ifStack
| | | | | table | | | | | table
++-+-++ +-+-+ +-+-+ ++-+-++ +-+-+ +-+-+
|lapd | D channel |ds0| |ds0| B channels |lapd | D channel |ds0| |ds0| B channels
+--+--+ Data Link Layer +-+-+ +-+-+ +--+--+ Data Link Layer +-+-+ +-+-+
| | | | | |
+--+----------------------+------+--------------------+ +--+----------------------+------+--------------------+
| ds1 or isdns/isdnu | | ds1 or isdns/isdnu |
+-----------------------------------------------------+ +-----------------------------------------------------+
Detailed interface mapping Detailed interface mapping
IfEntries are maintained for each D channel Network Layer entity IfEntries are maintained for each D channel Network Layer entity
(Terminal Endpoint), for LAPD and for each B channel. (Terminal Endpoint), for LAPD and for each B channel.
The ifType for a Terminal Endpoint can be isdn(63) for ISDN signaling The ifType for a Terminal Endpoint can be isdn(63) for ISDN signaling
channels or x25ple(40) for X.25 based packet mode services. The ifType channels or x25ple(40) for X.25 based packet mode services. The
for D channel Data Link Layer (LAPD) interfaces is lapd(77). The ifType ifType for D channel Data Link Layer (LAPD) interfaces is lapd(77).
for B channels is ds0(81). The ifType for physical interfaces is the The ifType for B channels is ds0(81). The ifType for physical
matching IANA ifType, usually ds1(18) for Primary Rate interfaces or interfaces is the matching IANA ifType, usually ds1(18) for Primary
isdns(75)/isdnu(76) for Basic Rate interfaces. Rate interfaces or isdns(75)/isdnu(76) for Basic Rate interfaces.
The ifStackTable is used to map B channels and LAPD interfaces to The ifStackTable is used to map B channels and LAPD interfaces to
physical interfaces and to map D channel Network Layer interfaces physical interfaces and to map D channel Network Layer interfaces
(Terminal Endpoints) to LAPD. (Terminal Endpoints) to LAPD.
In the example given above, the assignment of index values could for In the example given above, the assignment of index values could for
example be as follows: example be as follows:
ifIndex ifType ISDN MIB tables Description ifIndex ifType ISDN MIB tables Description
indexed by ifIndex indexed by ifIndex
1 isdns(75) isdnBasicRateTable Basic Rate physical interface 1 isdns(75) isdnBasicRateTable Basic Rate physical interface
2 lapd(77) isdnLapdTable LAPD interface 2 lapd(77) isdnLapdTable LAPD interface
3 x25ple(40) isdnEndpointTable X.25 Packet Layer 3 x25ple(40) isdnEndpointTable X.25 Packet Layer
4 isdn(63) isdnSignalingTable ISDN signaling channel #1 4 isdn(63) isdnSignalingTable ISDN signaling channel #1
isdnEndpointTable isdnEndpointTable
5 isdn(63) isdnSignalingTable ISDN signaling channel #2 5 isdn(63) isdnSignalingTable ISDN signaling channel #2
isdnEndpointTable isdnEndpointTable
6 ds0(81) isdnBearerTable B channel #1 6 ds0(81) isdnBearerTable B channel #1
7 ds0(81) isdnBearerTable B channel #2 7 ds0(81) isdnBearerTable B channel #2
8 ppp(23) neighbor entry #1 (see below) 8 ppp(23) peer entry #1 (see below)
9 ppp(23) neighbor entry #2 (see below) 9 ppp(23) peer entry #2 (see below)
The corresponding ifStack table entries would then be:
The corresponding ifStack table entries would then be:
ifStackTable Entries ifStackTable Entries
HigherLayer LowerLayer HigherLayer LowerLayer
0 3 0 3
0 4 0 4
0 5 0 5
0 8 0 8
0 9 0 9
1 0 1 0
2 1 2 1
3 2 3 2
4 2 4 2
5 2 5 2
6 1 6 1
7 1 7 1
8 6 8 6
9 7 9 7
Mapping of B channels to upper interface layers is usually done using Mapping of B channels to upper interface layers is usually done using
the Dial Control MIB. For example, mapping on top of B channels might the Dial Control MIB. For example, mapping on top of B channels might
look as follows: look as follows:
+-------------------------------------------------------+ +-------------------------------------------------------+
| Network Layer Protocol | | Network Layer Protocol |
+------+ +-------+ +-------+ +-------+ +-------+ +------+ +------+ +-------+ +-------+ +-------+ +-------+ +------+
| | | | | | | | | | <== appears active | | | | | | | | | | <== appears active
+-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+
| PPP | | PPP | | F/R | | PPP | | F/R | | PPP | | PPP | | F/R | | PPP | | F/R |
| for | | for | | for | | for | | for | ifEntry with | for | | for | | for | | for | | for | ifEntry with
|Nbr 1| |Nbr 2| |switch |Nbr 3| |switch shadow |Peer1| |Peer2| |switch |Peer3| |switch shadow PeerEntry
| | | | | A | | | | B | NeighborEntry | | | | | A | | | | B |
+-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+
| | | | <== some actually are | | | | <== some actually are
+--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+
| B | | B | | B | | B | | B | | B | | B | | B | | B | | B |
|channel| |channel| |channel| |channel| |channel| |channel| |channel| |channel| |channel| |channel|
+--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+
| | | | | | | | | | | | | | | | | | | |
+------+ +-------+ +-------+ +-------+ +-------+ +------+ +------+ +-------+ +-------+ +-------+ +-------+ +------+
| Basic/Primary Rate Interface | | Basic/Primary Rate Interface |
+-------------------------------------------------------+ +-------------------------------------------------------+
Mapping of IP interfaces to Called Neighbors to B Channels Mapping of IP interfaces to Called Peers to B Channels
In this model, ifEntries are maintained for each peer. Each peer is
In this model, ifEntries are maintained for each neighbor. Each required to have an associated ifEntry. This interface can be of any
neighbor is required to have an associated ifEntry. This interface can kind, e.g. PPP or LAPB.
be of any kind, e.g. PPP or LAPB.
The Dial Control MIB can be used for all types of demand-access The Dial Control MIB can be used for all types of demand-access
interfaces, e.g., ISDN, modems or X.25 virtual connections. interfaces, e.g., ISDN, modems or X.25 virtual connections.
3.2.2. ifTestTable 3.2.2. ifTestTable
The ifTestTable is not supported by this MIB. The ifTestTable is not supported by this MIB.
3.2.3. ifRcvAddressTable 3.2.3. ifRcvAddressTable
The ifRcvAddressTable is not supported by this MIB. The ifRcvAddressTable is not supported by this MIB.
3.2.4. ifEntry 3.2.4. ifEntry
3.2.4.1. ifEntry for a Basic Rate hardware interface 3.2.4.1. ifEntry for a Basic Rate hardware interface
The ifGeneralGroup is supported for Basic Rate hardware interfaces. The ifGeneralGroup is supported for Basic Rate hardware interfaces.
ifTable Comments ifTable Comments
============== =========================================== ============== ===========================================
ifIndex Each ISDN Basic Rate hardware interface is ifIndex Each ISDN Basic Rate hardware interface is
represented by an ifEntry. represented by an ifEntry.
ifDescr Textual port description. ifDescr Textual port description.
ifType The IANA value of isdns(75) or isdnu(76), ifType The IANA value of isdns(75) or isdnu(76),
whichever is appropriate. whichever is appropriate.
ifSpeed The overall bandwidth of this interface. ifSpeed The overall bandwidth of this interface.
ifPhysAddress Return an empty string. ifPhysAddress Return an empty string.
ifAdminStatus The administrative status of the ISDN interface. ifAdminStatus The administrative status of the ISDN interface.
ifOperStatus The current operational status of this interface. ifOperStatus The current operational status of this interface.
The operational status is dormant(5) if The operational status is dormant(5) if
the interface is in standby mode, i.e. connected the interface is in standby mode, i.e. connected
to the network, but without call activity. to the network, but without call activity.
The operational status is down(2) if the hardware The operational status is down(2) if the hardware
has detected that there is no layer 1 connection has detected that there is no layer 1 connection
to the switch. to the switch.
For other values, refer to the Interfaces MIB. For other values, refer to the Interfaces MIB.
ifLastChange Refer to the Interfaces MIB. ifLastChange Refer to the Interfaces MIB.
ifLinkUpDownTrapEnable ifLinkUpDownTrapEnable
Refer to the Interfaces MIB. Refer to the Interfaces MIB.
ifConnectorPresent ifConnectorPresent
Refer to the Interfaces MIB. Refer to the Interfaces MIB.
ifHighSpeed Return zero. ifHighSpeed Return zero.
ifName Refer to the Interfaces MIB. ifName Refer to the Interfaces MIB.
3.2.4.2. ifEntry for a B channel 3.2.4.2. ifEntry for a B channel
The ifEntry for a B channel supports the ifGeneralGroup of the The ifEntry for a B channel supports the ifGeneralGroup of the
Interfaces MIB. Interfaces MIB.
ifTable Comments
============== ===========================================
ifIndex Each ISDN B channel is represented by an ifEntry.
ifDescr Textual port description. ifTable Comments
============== ===========================================
ifIndex Each ISDN B channel is represented by an ifEntry.
ifType The IANA value of ds0(81). ifDescr Textual port description.
ifSpeed The bandwidth of this B channel. ifType The IANA value of ds0(81).
Usually, this is the value of 56000 or 64000.
ifPhysAddress Return an empty string. ifSpeed The bandwidth of this B channel.
Usually, this is the value of 56000 or 64000.
ifAdminStatus The administrative status of this interface. ifPhysAddress Return an empty string.
ifOperStatus The current operational status of this interface. ifAdminStatus The administrative status of this interface.
Note that dormant(5) is explicitly being used ifOperStatus The current operational status of this interface.
as defined in the Interfaces MIB. Note that dormant(5) is explicitly being used
For other values, refer to the Interfaces MIB. as defined in the Interfaces MIB.
For other values, refer to the Interfaces MIB.
ifLastChange Refer to the Interfaces MIB. ifLastChange Refer to the Interfaces MIB.
ifLinkUpDownTrapEnable ifLinkUpDownTrapEnable
Refer to the Interfaces MIB. Refer to the Interfaces MIB.
ifConnectorPresent ifConnectorPresent
Refer to the Interfaces MIB. Refer to the Interfaces MIB.
ifHighSpeed Return zero. ifHighSpeed Return zero.
ifName Refer to the Interfaces MIB. ifName Refer to the Interfaces MIB.
3.2.4.3. ifEntry for LAPD (D channel Data Link Layer) 3.2.4.3. ifEntry for LAPD (D channel Data Link Layer)
The ifEntry for LAPD (D channel Data Link Layer) supports the The ifEntry for LAPD (D channel Data Link Layer) supports the
ifGeneralGroup and the ifPacketGroup of the Interfaces MIB. ifGeneralGroup and the ifPacketGroup of the Interfaces MIB.
ifTable Comments ifTable Comments
============== =========================================== ============== ===========================================
ifIndex Each ISDN D channel Data Link layer is represented ifIndex Each ISDN D channel Data Link layer is represented
by an ifEntry. by an ifEntry.
ifDescr Textual port description. ifDescr Textual port description.
ifType The IANA value of lapd(77). ifType The IANA value of lapd(77).
ifSpeed The bandwidth of this interface. Usually, this is ifSpeed The bandwidth of this interface. Usually, this is
the value of 16000 for basic rate interfaces or the value of 16000 for basic rate interfaces or
64000 for primary rate interfaces. 64000 for primary rate interfaces.
ifPhysAddress Return an empty string. ifPhysAddress Return an empty string.
ifAdminStatus The administrative status of this interface. ifAdminStatus The administrative status of this interface.
ifOperStatus The current operational status of the ISDN ifOperStatus The current operational status of the ISDN
LAPD interface. The operational status is LAPD interface. The operational status is
dormant(5) if the interface is in standby mode dormant(5) if the interface is in standby mode
(see Q.931 [8], Annex F, D channel backup (see Q.931 [8], Annex F, D channel backup
procedures). procedures).
For other values, refer to the Interfaces MIB. For other values, refer to the Interfaces MIB.
ifLastChange Refer to the Interfaces MIB. ifLastChange Refer to the Interfaces MIB.
ifLinkUpDownTrapEnable ifLinkUpDownTrapEnable
Refer to the Interfaces MIB. Refer to the Interfaces MIB.
ifConnectorPresent ifConnectorPresent
Refer to the Interfaces MIB. Refer to the Interfaces MIB.
ifHighSpeed Return zero. ifHighSpeed Return zero.
ifName Refer to the Interfaces MIB. ifName Refer to the Interfaces MIB.
ifMtu The size of the largest frame which can be ifMtu The size of the largest frame which can be
sent/received on this interface, sent/received on this interface,
specified in octets. Usually, this is the specified in octets. Usually, this is the
default value of 260 as specified in Q.921 default value of 260 as specified in Q.921
[6], chapter 5.9.3. [6], chapter 5.9.3.
ifInOctets The total number of octets received on this ifInOctets The total number of octets received on this
interface. interface.
ifInUcastPkts The number of frames received on this interface ifInUcastPkts The number of frames received on this interface
whose address is not TEI=127. whose address is not TEI=127.
ifInNUcastPkts Deprecated. Return the number of frames ifInNUcastPkts Deprecated. Return the number of frames
received on this interface with TEI=127. received on this interface with TEI=127.
ifInMulticastPkts Return zero. ifInMulticastPkts Return zero.
ifInBroadcastPkts Return the number of frames received ifInBroadcastPkts Return the number of frames received
on this interface with TEI=127. on this interface with TEI=127.
ifInDiscards The total number of received frames which have been ifInDiscards The total number of received frames which have
discarded. been discarded.
The possible reasons are: buffer shortage. The possible reasons are: buffer shortage.
ifInErrors The number of inbound frames that contained ifInErrors The number of inbound frames that contained
errors preventing them from being deliverable errors preventing them from being deliverable
to LAPD. to LAPD.
ifInUnknownProtos The number of frames with known TEI, but unknown ifInUnknownProtos The number of frames with known TEI, but unknown
SAPI (Service Access Point Identifier, SAPI (Service Access Point Identifier,
see Q.921 [6], chapter 3.3.3). see Q.921 [6], chapter 3.3.3).
ifOutOctets The total number of octets transmitted on this ifOutOctets The total number of octets transmitted on this
interface. interface.
ifOutUcastPkts The number of frames transmitted on this ifOutUcastPkts The number of frames transmitted on this
interface whose address is not TEI=127. interface whose address is not TEI=127.
ifOutNUcastPkts Deprecated. Return the number of frames ifOutNUcastPkts Deprecated. Return the number of frames
transmitted on this interface with TEI=127. transmitted on this interface with TEI=127.
ifOutMulticastPkts ifOutMulticastPkts
Return zero. Return zero.
ifOutBroadcastPkts ifOutBroadcastPkts
Return the number of frames transmitted Return the number of frames transmitted
on this interface with TEI=127. on this interface with TEI=127.
ifOutDiscards The total number of outbound frames which ifOutDiscards The total number of outbound frames which
were discarded. Possible reasons are: were discarded. Possible reasons are:
buffer shortage. buffer shortage.
ifOutErrors The number of frames which could not be ifOutErrors The number of frames which could not be
transmitted due to errors. transmitted due to errors.
ifOutQlen Deprecated. Return zero. ifOutQlen Deprecated. Return zero.
ifSpecific Deprecated. Return {0 0}. ifSpecific Deprecated. Return {0 0}.
3.2.4.4. ifEntry for a signaling channel 3.2.4.4. ifEntry for a signaling channel
The ifEntry for a signaling channel supports the ifGeneralGroup and the The ifEntry for a signaling channel supports the ifGeneralGroup and
ifPacketGroup of the Interfaces MIB. the ifPacketGroup of the Interfaces MIB.
ifTable Comments ifTable Comments
============== =========================================== ============== ===========================================
ifIndex Each ISDN signaling channel is represented by ifIndex Each ISDN signaling channel is represented by
an ifEntry. an ifEntry.
ifDescr Textual port description. ifDescr Textual port description.
ifType The IANA value of isdn(63). ifType The IANA value of isdn(63).
ifSpeed The bandwidth of this signaling channel. Usually, ifSpeed The bandwidth of this signaling channel. Usually,
this is the same value as for LAPD, i.e. 16000 this is the same value as for LAPD, i.e. 16000
for basic rate interfaces or 64000 for primary rate for basic rate interfaces or 64000 for primary rate
interfaces. interfaces.
ifPhysAddress The ISDN address assigned to this signaling channel. ifPhysAddress The ISDN address assigned to this signaling channel.
This is a copy of isdnSignalingCallingAddress. This is a copy of isdnSignalingCallingAddress.
ifAdminStatus The administrative status of the signaling channel. ifAdminStatus The administrative status of the signaling channel.
ifOperStatus The current operational status of this signaling ifOperStatus The current operational status of this signaling
channel. The operational status is dormant(5) if channel. The operational status is dormant(5) if
the signaling channel is currently not activated. the signaling channel is currently not activated.
For other values, refer to the Interfaces MIB. For other values, refer to the Interfaces MIB.
ifLastChange Refer to the Interfaces MIB. ifLastChange Refer to the Interfaces MIB.
ifLinkUpDownTrapEnable ifLinkUpDownTrapEnable
Refer to the Interfaces MIB. Refer to the Interfaces MIB.
ifConnectorPresent ifConnectorPresent
Refer to the Interfaces MIB. Refer to the Interfaces MIB.
ifHighSpeed Return zero. ifHighSpeed Return zero.
ifName Refer to the Interfaces MIB. ifName Refer to the Interfaces MIB.
ifMtu The size of the largest frame which can be ifMtu The size of the largest frame which can be
sent/received on this signaling channel, sent/received on this signaling channel,
specified in octets. Usually, this is the specified in octets. Usually, this is the
default value of 260 as specified in Q.921 default value of 260 as specified in Q.921
[6], chapter 5.9.3. [6], chapter 5.9.3.
ifInOctets The total number of octets received on this ifInOctets The total number of octets received on this
signaling channel. signaling channel.
ifInUcastPkts The number of frames received which are targeted ifInUcastPkts The number of frames received which are targeted
to this channel. to this channel.
ifInNUcastPkts Deprecated. Return the number of frames ifInNUcastPkts Deprecated. Return the number of frames
received on this signaling channel with TEI=127. received on this signaling channel with TEI=127.
ifInMulticastPkts Return zero. ifInMulticastPkts Return zero.
ifInBroadcastPkts Return the number of frames received ifInBroadcastPkts Return the number of frames received
on this signaling channel with TEI=127. on this signaling channel with TEI=127.
ifInDiscards The total number of received frames which have been ifInDiscards The total number of received frames which have been
discarded. discarded.
The possible reasons are: buffer shortage. The possible reasons are: buffer shortage.
ifInErrors The number of inbound frames that contained ifInErrors The number of inbound frames that contained
errors preventing them from being deliverable errors preventing them from being deliverable
to the signaling channel. to the signaling channel.
ifInUnknownProtos Return zero. ifInUnknownProtos Return zero.
ifOutOctets The total number of octets transmitted on this ifOutOctets The total number of octets transmitted on this
signaling channel. signaling channel.
ifOutUcastPkts The number of frames transmitted on this ifOutUcastPkts The number of frames transmitted on this
signaling channel whose address is not TEI=127. signaling channel whose address is not TEI=127.
ifOutNUcastPkts Deprecated. Return the number of frames ifOutNUcastPkts Deprecated. Return the number of frames
transmitted on this signaling channel with TEI=127. transmitted on this signaling channel with TEI=127.
ifOutMulticastPkts ifOutMulticastPkts
Return zero. Return zero.
ifOutBroadcastPkts ifOutBroadcastPkts
Return the number of frames transmitted Return the number of frames transmitted
on this signaling channel with TEI=127. on this signaling channel with TEI=127.
ifOutDiscards The total number of outbound frames which ifOutDiscards The total number of outbound frames which
were discarded. Possible reasons are: were discarded. Possible reasons are:
buffer shortage. buffer shortage.
ifOutErrors The number of frames which could not be ifOutErrors The number of frames which could not be
transmitted due to errors. transmitted due to errors.
ifOutQlen Deprecated. Return zero. ifOutQlen Deprecated. Return zero.
ifSpecific Deprecated. Return {0 0}. ifSpecific Deprecated. Return {0 0}.
3.3. Relationship to other MIBs 3.3. Relationship to other MIBs
3.3.1. Relationship to the DS1/E1 MIB 3.3.1. Relationship to the DS1/E1 MIB
Implementation of the DS1/E1 MIB [12] is not required for supporting Implementation of the DS1/E1 MIB [12] is not required for supporting
this MIB. It is however recommended to implement the DS1/E1 MIB on this MIB. It is however recommended to implement the DS1/E1 MIB on
entities supporting Primary Rate interfaces. entities supporting Primary Rate interfaces.
3.3.2. Relationship to the DS0 and DS0Bundle MIBs 3.3.2. Relationship to the DS0 and DS0Bundle MIBs
Implementation of the DS0 MIB [13] is optional. Implementation of the DS0 MIB [13] is optional.
Implementation of the DS0Bundle MIB [13] is required only if Implementation of the DS0Bundle MIB [13] may be required only if
hyperchannels are to be supported. hyperchannels are to be supported, depending on the multiplexing
scheme used in a given implementation. See chapter 3.4.2 for details
on how to implement hyperchannels.
3.3.3. Relationship to the Dial Control MIB 3.3.3. Relationship to the Dial Control MIB
Implementation of the Dial Control MIB [15] is required. Implementation of the Dial Control MIB [15] is required.
3.4. ISDN interface specific information and implementation hints 3.4. ISDN interface specific information and implementation hints
3.4.1. ISDN leased lines 3.4.1. ISDN leased lines
ISDN leased lines can be specified on a per-B-channel basis. To do so, ISDN leased lines can be specified on a per-B-channel basis. To do
the value of isdnBearerChannelType has to be set to leased(2). There is so, the value of isdnBearerChannelType has to be set to leased(2).
no signaling protocol support for leased line B channels, since there is There is no signaling protocol support for leased line B channels,
no signaling protocol action for these kinds of interfaces. since there is no signaling protocol action for these kinds of
interfaces.
If there is no signaling support available for an ISDN interface, this If there is no signaling support available for an ISDN interface,
must be specified in the appropriate interface specific table. For this must be specified in the appropriate interface specific table.
Basic Rate interfaces, isdnBasicRateSignalMode of isdnBasicRateTable For Basic Rate interfaces, isdnBasicRateSignalMode of
must be set to inactive(2). For Primary Rate interfaces, dsx1SignalMode isdnBasicRateTable must be set to inactive(2). For Primary Rate
of dsx1ConfigTable in DS1/E1 MIB [12] must be set to none(1). There are interfaces, dsx1SignalMode of dsx1ConfigTable in DS1/E1 MIB [12] must
no isdnLapdTable or isdnSignalingTable entries for such interfaces. be set to none(1). There are no isdnLapdTable or isdnSignalingTable
entries for such interfaces.
Depending on the leased line type and the service provider, the D Depending on the leased line type and the service provider, the D
channel can be used for data transfer. If this is the case the D channel can be used for data transfer. If this is the case the D
channel interface type is ds0(81) instead of lapd(77) and its usage is channel interface type is ds0(81) instead of lapd(77) and its usage
identical to B channel usage if there is no signaling channel available. is identical to B channel usage if there is no signaling channel
available.
For a Primary Rate interface which is entirely used as a leased line, For a Primary Rate interface which is entirely used as a leased line,
there is no ISDN specific information available or required. Such there is no ISDN specific information available or required. Such
leased lines can entirely be handled by the DS1/E1 MIB. leased lines can entirely be handled by the DS1/E1 MIB.
3.4.2. Hyperchannels 3.4.2. Hyperchannels
The active switch protocol defines if hyperchannels are supported, and The active switch protocol defines if hyperchannels are supported,
the actual support is implementation dependent. Hyperchannel and the actual support is implementation dependent. Hyperchannel
connections will be requested by the interface user at call setup time, connections will be requested by the interface user at call setup
e.g. by the neighbor connection handling procedures. time, e.g. by the peer connection handling procedures.
In the ISDN MIB, the isdnBearerMultirate object of isdnBearerTable can In the ISDN MIB, the isdnBearerMultirate object of isdnBearerTable
be used to check if hyperchannels are being used for an active call. can be used to check if hyperchannels are being used for an active
call.
If hyperchannels are being used, another interface layer is required to If hyperchannels are being used, multiplexing between the
map multiple B channels to a single hyperchannel. This is accomplished encapsulation layer and the B channels is required, since there is
by using the DS0Bundle MIB [13]. one encapsulation layer interface connected to several B channel
interfaces. This can be accomplished in two ways.
Each hyperchannel call is treated as one call in the o The DS0Bundle MIB [13] can be used to provide the multiplexing.
isdnSignalingStatsTable, independent of the number of B channels See the DS0Bundle MIB document for details.
involved.
For a hyperchannel call, all objects in the isdnBearerTable entries o The ifStackTable can be used to provide the multiplexing. In
related to this call (i.e., all isdnBearerTable entries associated to B this case, there are several ifStackTable entries with the same
channels used by the hyperchannel) have identical values. The related value of HigherLayer, and different values of LowerLayer.
objects in the isdnBearerTable are:
isdnBearerPeerAddress It is up to the implementor to decide which multiplexing scheme to
isdnBearerPeerSubAddress use.
isdnBearerCallOrigin
isdnBearerInfoType Each hyperchannel call is treated as one call in the
isdnBearerMultirate isdnSignalingStatsTable, independent of the number of B channels
isdnBearerCallSetupTime involved.
isdnBearerCallConnectTime
isdnBearerChargedUnits For a hyperchannel call, all objects in the isdnBearerTable entries
related to this call (i.e., all isdnBearerTable entries associated to
B channels used by the hyperchannel) have identical values. The
related objects in the isdnBearerTable are:
isdnBearerPeerAddress
isdnBearerPeerSubAddress
isdnBearerCallOrigin
isdnBearerInfoType
isdnBearerMultirate
isdnBearerCallSetupTime
isdnBearerCallConnectTime
isdnBearerChargedUnits
3.4.3. D channel backup and NFAS trunks 3.4.3. D channel backup and NFAS trunks
D channel backup is defined in Q.931 [8], Annex F. It describes Non- D channel backup is defined in Q.931 [8], Annex F. It describes Non-
Associated signaling and its use and functionality is basically Associated signaling and its use and functionality is basically
identical to Non Facility Associated Signaling (NFAS) trunks. identical to Non Facility Associated Signaling (NFAS) trunks.
Non Facility Accociated Signaling (NFAS) basically means that a D Non Facility Accociated Signaling (NFAS) basically means that a D
channel on a PRI interface is used to manage calls on other PRI trunks. channel on a PRI interface is used to manage calls on other PRI
This is required in North America for H11 channels, since all 24 time trunks. This is required in North America for H11 channels, since
slots are being used for B channels. all 24 time slots are being used for B channels.
According to Q.931, Annex F, the D channel backup feature can be According to Q.931, Annex F, the D channel backup feature can be
provided on a subscription basis and is network dependent. The D provided on a subscription basis and is network dependent. The D
channel backup procedure is described in detail in Q.931. channel backup procedure is described in detail in Q.931.
For D channel backup, the controlling isdnSignalingTable entry is For D channel backup, the controlling isdnSignalingTable entry is
layered on top of all attached LAPD interfaces. This layering is done layered on top of all attached LAPD interfaces. This layering is
using the ifStack table. There is only one active LAPD interface, done using the ifStack table. There is only one active LAPD
however. Inactive LAPD interfaces have an ifOperStatus of dormant(5). interface, however. Inactive LAPD interfaces have an ifOperStatus of
dormant(5).
NFAS trunks are also handled using the ifStack table. In this case, a NFAS trunks are also handled using the ifStack table. In this case, a
signaling channel is layered on top of a LAPD interface as well as on signaling channel is layered on top of a LAPD interface as well as on
top of all physical interfaces which are controlled by the signaling top of all physical interfaces which are controlled by the signaling
channel, but do not supply a D channel. channel, but do not supply a D channel.
3.4.4. X.25 based packet-mode service in B and D channels 3.4.4. X.25 based packet-mode service in B and D channels
X.25 based packet mode service over B channels can be handled using the X.25 based packet mode service over B channels can be handled using
Dial Control MIB by creating an appropriate neighbor entry. The the Dial Control MIB by creating an appropriate peer entry. The peer
neighbor entry ifType can then be x25(5), thus providing access to X.25 entry ifType can then be x25(5), thus providing access to X.25
service. service.
X.25 based packet mode service over D channels can be handled by X.25 based packet mode service over D channels can be handled by
creating an ifEndpointTable entry with an isdnEndpointIfType of creating an ifEndpointTable entry with an isdnEndpointIfType of
x25ple(40). The upper protocol layers can then be attached to this x25ple(40). The upper protocol layers can then be attached to this
interface using the ifStack table. interface using the ifStack table.
3.4.5. SPID handling 3.4.5. SPID handling
Service Profile IDentifiers (SPIDs) are defined for BRI interfaces only, Service Profile IDentifiers (SPIDs) are defined for BRI interfaces
and being used in North America. SPIDs are required for DMS-100, NI-1 only, and being used in North America. SPIDs are required for DMS-
and NI-2, and are optional for 5ESS. A switch can define up to 8 SPIDs 100, NI-1 and NI-2, and are optional for 5ESS. A switch can define
per BRI. up to 8 SPIDs per BRI.
Each Terminal Endpoint has a SPID assigned. It is normally built from Each Terminal Endpoint has a SPID assigned. It is normally built
the party number (calling address for outgoing calls) with a number of from the party number (calling address for outgoing calls) with a
digits prepended and appended. Since each network appears to be number of digits prepended and appended. Since each network appears
different, both the calling address and the SPID have to be stored. to be different, both the calling address and the SPID have to be
stored.
The SPID identifies the particular services that have been provisioned The SPID identifies the particular services that have been
for a terminal. If there are two B channels on a BRI, there can be two provisioned for a terminal. If there are two B channels on a BRI,
SPIDs, one for each of the two B channels. There can also be a single there can be two SPIDs, one for each of the two B channels. There
SPID, providing access to both B channels. can also be a single SPID, providing access to both B channels.
The SPID gets registered with the switch after link establishment. The SPID gets registered with the switch after link establishment.
There is one data link for each SPID. As part of terminal registration, There is one data link for each SPID. As part of terminal
an EID (Endpoint IDentifier) is defined by the switch. On incoming registration, an EID (Endpoint IDentifier) is defined by the switch.
calls, the switch may provide the EID, a called party number, or both, On incoming calls, the switch may provide the EID, a called party
depending on the ISDN code implemented in the switch. number, or both, depending on the ISDN code implemented in the
switch.
The EID has two bytes: USID (User Service IDentifier) and TID (Terminal The EID has two bytes: USID (User Service IDentifier) and TID
IDentifier). These are later used by some of the software versions (Terminal IDentifier). These are later used by some of the software
running on the switch side (e.g. compliant with NI-1, 5ESS custom) to versions running on the switch side (e.g. compliant with NI-1, 5ESS
broadcast SETUP messages with these included, so the correct endpoint custom) to broadcast SETUP messages with these included, so the
would accept the call. Other switch software versions identify the correct endpoint would accept the call. Other switch software
endpoint with the Called Party Number. versions identify the endpoint with the Called Party Number.
In the ISDN MIB, the SPID can be entered using the isdnEndpointSpid In the ISDN MIB, the SPID can be entered using the isdnEndpointSpid
object of isdnEndpointTable. The isdnSignalingCallingAddress, already object of isdnEndpointTable. The isdnSignalingCallingAddress,
being used to specify the calling number, cannot be used to record the already being used to specify the calling number, cannot be used to
SPID since the values of the SPID and the Calling Address may differ and record the SPID since the values of the SPID and the Calling Address
both may be required to be present. may differ and both may be required to be present.
3.4.6. Closed User Groups 3.4.6. Closed User Groups
Closed User Groups (CUG), as defined in I.255.1 [14], are supported for Closed User Groups (CUG), as defined in I.255.1 [14], are supported
circuit mode calls by ETSI (ETS 300 138) and 1TR6. In these networks, for circuit mode calls by ETSI (ETS 300 138) and 1TR6. In these
an ISDN address can have one or more Closed User Groups assigned. If networks, an ISDN address can have one or more Closed User Groups
there is more than one Closed User Group assigned to a given address, assigned. If there is more than one Closed User Group assigned to a
one of those is the preferred Closed User Group. For such addresses, given address, one of those is the preferred Closed User Group. For
only calls from assigned Closed User Groups are accepted by the network. such addresses, only calls from assigned Closed User Groups are
accepted by the network.
Thus, Closed User Groups are a parameter for neighbor entries and are Thus, Closed User Groups are a parameter for peer entries and are
defined in the Dial Control MIB. A neighbor entry attached to a Closed defined in the Dial Control MIB. A peer entry attached to a Closed
User Group has to point to an ISDN interface which is attached to the User Group has to point to an ISDN interface which is attached to the
Closed User Group in question. Closed User Group in question.
3.4.7. Provision of point-to-point line topology 3.4.7. Provision of point-to-point line topology
In the ISDN standards, there are two different meanings for the term In the ISDN standards, there are two different meanings for the term
"point-to-point". "point-to-point".
In ISDN standards, the term point-to-point are usually used for data In ISDN standards, the term point-to-point are usually used for data
link connections, i.e. layer 2 connections, where each layer 2 link connections, i.e. layer 2 connections, where each layer 2
connection from the TE to the network is a single point-to-point connection from the TE to the network is a single point-to-point
connection. Multiple connections of this kind may exist on one physical connection. Multiple connections of this kind may exist on one
(layer 1) connection, however, and in case of Basic Rate interfaces physical (layer 1) connection, however, and in case of Basic Rate
there may be several TE's connected to one physical line to the network. interfaces there may be several TE's connected to one physical line
to the network.
The second meaning of "point-to-point" refers to the line topology, i.e. The second meaning of "point-to-point" refers to the line topology,
to layer 1 connections. For Primary Rate interfaces, the line topology i.e. to layer 1 connections. For Primary Rate interfaces, the line
is always point-to-point. For Basic Rate interfaces, layer 1 point-to- topology is always point-to-point. For Basic Rate interfaces, layer
point connections do exist in several countries, usually being used for 1 point-to- point connections do exist in several countries, usually
connecting PBX systems to the network. being used for connecting PBX systems to the network.
The second meaning (layer 1 connections) is what will be referred to as The second meaning (layer 1 connections) is what will be referred to
"point-to-point" connection throughout this document. as "point-to-point" connection throughout this document.
For Basic Rate interfaces, the isdnBasicRateTable object For Basic Rate interfaces, the isdnBasicRateTable object
isdnBasicRateLineTopology can be used to select the line topology. isdnBasicRateLineTopology can be used to select the line topology.
3.4.8. Speech and audio bearer capability information elements 3.4.8. Speech and audio bearer capability information elements
The objects speech(2), audio31(6) and audio7(7), as being used in The objects speech(2), audio31(6) and audio7(7), as being used in
isdnBearerInfoType, refer to the Speech, 3.1 kHz Audio and old 7 kHz isdnBearerInfoType, refer to the Speech, 3.1 kHz Audio and old 7 kHz
Audio (now Multi-use) bearer capabilities for ISDN, as defined in Q.931 Audio (now Multi-use) bearer capabilities for ISDN, as defined in
[8], chapter 4.5.5, octet 3 of bearer capability information element. Q.931 [8], chapter 4.5.5, octet 3 of bearer capability information
element.
These capabilities are signaling artifices that allow networks to do These capabilities are signaling artifices that allow networks to do
certain things with the call. It is up to the network to decide what to certain things with the call. It is up to the network to decide what
do. to do.
The Speech Bearer Capability means that speech is being carried over the The Speech Bearer Capability means that speech is being carried over
channel, as in two people talking. This would be POTS-type speech. The the channel, as in two people talking. This would be POTS-type
network may compress this, encrypt it or whatever it wants with it as speech. The network may compress this, encrypt it or whatever it
long as it delivers POTS quality speech to the other end. In other wants with it as long as it delivers POTS quality speech to the other
words, a modem is not guaranteed to work over this connection. end. In other words, a modem is not guaranteed to work over this
connection.
The 3.1 kHz Audio capability indicates that the network carries the 3.1 The 3.1 kHz Audio capability indicates that the network carries the
kHz bandwidth across the network. This would (theoretically) allow 3.1 kHz bandwidth across the network. This would (theoretically)
modem signals to be carried across the network. In the US, the network allow modem signals to be carried across the network. In the US, the
automatically enters a capability of 3.1 kHz Audio on calls coming into network automatically enters a capability of 3.1 kHz Audio on calls
the ISDN from a POTS network. This capability restricts the network coming into the ISDN from a POTS network. This capability restricts
from interfering with the data channel in a way that would corrupt the the network from interfering with the data channel in a way that
3.1 kHz VoiceBand data. would corrupt the 3.1 kHz VoiceBand data.
7 kHz Audio was meant to signal the use of a higher quality audio 7 kHz Audio was meant to signal the use of a higher quality audio
connection (e.g., music from radio). It was changed to Multi-Use connection (e.g., music from radio). It was changed to Multi-Use
capability to allow it to be used for video-conferencing with fall back capability to allow it to be used for video-conferencing with fall
to audio. back to audio.
In some cases, the Speech or 3.1 kHz Bearer Capability provides a 56 In some cases, the Speech or 3.1 kHz Bearer Capability provides a 56
kbit/s data path through the network. Therefore, some people are kbit/s data path through the network. Therefore, some people are
setting up calls with the Speech or 3.1 kHz BC and transmitting 56 setting up calls with the Speech or 3.1 kHz BC and transmitting 56
kbit/s data over the connection. This is usually to take advantage of kbit/s data over the connection. This is usually to take advantage
favorable tariffs for Speech as opposed to Data. of favorable tariffs for Speech as opposed to Data.
On the incoming side, the equipment is usually configured to ignore the On the incoming side, the equipment is usually configured to ignore
Bearer Capability and either answer all Speech calls as 56 kbit/s data the Bearer Capability and either answer all Speech calls as 56 kbit/s
or to use one Directory Number for real speech and another for data. data or to use one Directory Number for real speech and another for
data.
3.4.9. Attaching incoming calls to router ports 3.4.9. Attaching incoming calls to router ports
In ISDN, there are several ways to identify an incoming call and to In ISDN, there are several ways to identify an incoming call and to
attach a router port to this call. attach a router port to this call.
o The call can be identified and attached to a router port using the
ISDN Calling Address, that is, the peer ISDN address. Since the
peer address is defined in a Dial Control MIB configuration entry
for this peer, this would be the most natural way to attach an
incoming call to a router port.
In this configuration, only a single isdnSignalingTable entry is o The call can be identified and attached to a router port using
required for each physical ISDN interface. Unfortunately, the ISDN the ISDN Calling Address, that is, the peer ISDN address. Since
Calling Address is not available in all countries and/or switch the peer address is defined in a Dial Control MIB configuration
protocols. Therefore, other means for attaching incoming calls to entry for this peer, this would be the most natural way to
router ports must be provided. attach an incoming call to a router port.
o The call can also be identified and attached to a router port using In this configuration, only a single isdnSignalingTable entry is
the ISDN Called Address. In this case, a distinct ISDN address or required for each physical ISDN interface. Unfortunately, the
subaddress must be specified for each of the router ports. ISDN Calling Address is not available in all countries and/or
switch protocols. Therefore, other means for attaching incoming
calls to router ports must be provided.
This can be accomplished in the ISDN MIB by creating a o The call can also be identified and attached to a router port
isdnSignalingTable entry for each of the router ports, and by using the ISDN Called Address. In this case, a distinct ISDN
connecting Dial Control MIB neighbor entries to the thereby created address or subaddress must be specified for each of the router
interface using the dialCtlNbrCfgLowerIf object of ports. This can be accomplished in the ISDN MIB by creating a
dialCtlNbrCfgTable. isdnSignalingTable entry for each of the router ports, and by
connecting Dial Control MIB peer entries to the thereby created
interface using the dialCtlPeerCfgLowerIf object of
dialCtlPeerCfgTable.
If this type of router port identification is used in an If this type of router port identification is used in an
implementation, it is up to the implementor to decide if there implementation, it is up to the implementor to decide if there
should be distinct TEI values assigned for each of the should be distinct TEI values assigned for each of the
isdnSignalingTable entries. For this reason, the isdnEndpointTable isdnSignalingTable entries. For this reason, the
permits specifying the same TEI value in multiple entries. It is isdnEndpointTable permits specifying the same TEI value in
recommended to use dynamic TEI assignment whenever possible. multiple entries. It is recommended to use dynamic TEI
assignment whenever possible.
The implementor should be aware that this type of configuration The implementor should be aware that this type of configuration
requires a lot of configuration work for the customer, since an requires a lot of configuration work for the customer, since an
entry in isdnSignalingTable must be created for each of the router entry in isdnSignalingTable must be created for each of the
ports. router ports.
o Incoming calls can also be identified and attached to router ports o Incoming calls can also be identified and attached to router
using a higher layer functionality, such as PPP authentication. ports using a higher layer functionality, such as PPP
Defining this functionality is outside the scope of this document. authentication. Defining this functionality is outside the
scope of this document.
3.4.10. Usage of isdnMibDirectoryGroup and isdnDirectoryTable 3.4.10. Usage of isdnMibDirectoryGroup and isdnDirectoryTable
In some switch protocol or PBX implementations, the Called Number In some switch protocol or PBX implementations, the Called Number
Information Element on incoming calls can differ from the Calling Number Information Element on incoming calls can differ from the Calling
on outgoing calls. Sometimes, the Called Number can be different for Number on outgoing calls. Sometimes, the Called Number can be
incoming Local Calls, Long Distance Calls and International Calls. For different for incoming Local Calls, Long Distance Calls and
Hunt Groups, the Called Number can be any of the numbers in the Hunt International Calls. For Hunt Groups, the Called Number can be any
Group. of the numbers in the Hunt Group.
The isdnDirectoryTable can be used to specify all these numbers. The isdnDirectoryTable can be used to specify all these numbers.
Entries in the isdnDirectoryTable are always connected to specific Entries in the isdnDirectoryTable are always connected to specific
isdnSignalingTable entries. No ifEntry is created for isdnSignalingTable entries. No ifEntry is created for
isdnDirectoryTable entries. Therefore, the isdnDirectoryTable can not isdnDirectoryTable entries. Therefore, the isdnDirectoryTable can
be used to attach incoming calls to router ports. For router port not be used to attach incoming calls to router ports. For router
identification, isdnSignalingTable entries should be created instead. port identification, isdnSignalingTable entries should be created
instead.
4. Definitions 4. Definitions
ISDN-MIB DEFINITIONS ::= BEGIN ISDN-MIB DEFINITIONS ::= BEGIN
IMPORTS IMPORTS
MODULE-IDENTITY, MODULE-IDENTITY,
NOTIFICATION-TYPE, NOTIFICATION-TYPE,
OBJECT-TYPE, OBJECT-TYPE,
Counter32, Counter32,
skipping to change at page 20, line 25 skipping to change at page 21, line 25
Integer32 Integer32
FROM SNMPv2-SMI FROM SNMPv2-SMI
DisplayString, DisplayString,
TruthValue, TruthValue,
TimeStamp, TimeStamp,
RowStatus, RowStatus,
TestAndIncr, TestAndIncr,
TEXTUAL-CONVENTION TEXTUAL-CONVENTION
FROM SNMPv2-TC FROM SNMPv2-TC
MODULE-COMPLIANCE, MODULE-COMPLIANCE,
OBJECT-GROUP OBJECT-GROUP,
NOTIFICATION-GROUP
FROM SNMPv2-CONF FROM SNMPv2-CONF
ifIndex, ifIndex,
InterfaceIndex InterfaceIndex
FROM IF-MIB FROM IF-MIB
IANAifType IANAifType
FROM IANAifType-MIB FROM IANAifType-MIB
transmission transmission
FROM RFC1213-MIB; FROM RFC1213-MIB;
isdnMib MODULE-IDENTITY isdnMib MODULE-IDENTITY
LAST-UPDATED "9608230910Z" -- Aug 23, 1996 LAST-UPDATED "9609231642Z" -- Sep 23, 1996
ORGANIZATION "IETF ISDN MIB Working Group" ORGANIZATION "IETF ISDN MIB Working Group"
CONTACT-INFO CONTACT-INFO
" Guenter Roeck " Guenter Roeck
Postal: cisco Systems Postal: cisco Systems
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
U.S.A. U.S.A.
Phone: +1 408 527 3143 Phone: +1 408 527 3143
E-mail: groeck@cisco.com" E-mail: groeck@cisco.com"
DESCRIPTION DESCRIPTION
skipping to change at page 21, line 43 skipping to change at page 22, line 46
The definition of this textual convention with the The definition of this textual convention with the
addition of newly assigned values is published addition of newly assigned values is published
periodically by the IANA, in either the Assigned periodically by the IANA, in either the Assigned
Numbers RFC, or some derivative of it specific to Numbers RFC, or some derivative of it specific to
Internet Network Management number assignments. (The Internet Network Management number assignments. (The
latest arrangements can be obtained by contacting the latest arrangements can be obtained by contacting the
IANA.) IANA.)
Requests for new values should be made to IANA via Requests for new values should be made to IANA via
email (iana@isi.edu)." email (iana@iana.org)."
SYNTAX INTEGER { SYNTAX INTEGER {
other(1), -- none of the following other(1), -- none of the following
dss1(2), -- ITU DSS1 (formerly CCITT) Q.931 dss1(2), -- ITU DSS1 (formerly CCITT) Q.931
etsi(3), -- Europe / ETSI ETS300-102 etsi(3), -- Europe / ETSI ETS300-102
-- plus supplementary services -- plus supplementary services
-- (ETSI 300-xxx) -- (ETSI 300-xxx)
-- note that NET3, NET5 define -- note that NET3, NET5 define
-- test procedures for ETS300-102 -- test procedures for ETS300-102
-- and have been replaced by -- and have been replaced by
-- I-CTR 3 and I-CTR 4. -- I-CTR 3 and I-CTR 4.
skipping to change at page 41, line 25 skipping to change at page 44, line 12
isdnMibCompliance MODULE-COMPLIANCE isdnMibCompliance MODULE-COMPLIANCE
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The compliance statement for entities which implement "The compliance statement for entities which implement
the ISDN MIB." the ISDN MIB."
MODULE -- this module MODULE -- this module
-- unconditionally mandatory groups -- unconditionally mandatory groups
MANDATORY-GROUPS { MANDATORY-GROUPS {
isdnMibSignalingGroup, isdnMibSignalingGroup,
isdnMibBearerGroup isdnMibBearerGroup,
isdnMibNotificationsGroup
} }
-- conditionally mandatory group -- conditionally mandatory group
GROUP isdnMibBasicRateGroup GROUP isdnMibBasicRateGroup
DESCRIPTION DESCRIPTION
"The isdnMibBasicRateGroup is mandatory for entities "The isdnMibBasicRateGroup is mandatory for entities
supporting ISDN Basic Rate interfaces." supporting ISDN Basic Rate interfaces."
-- optional groups -- optional groups
GROUP isdnMibEndpointGroup GROUP isdnMibEndpointGroup
skipping to change at page 43, line 49 skipping to change at page 46, line 45
OBJECTS { OBJECTS {
isdnDirectoryNumber, isdnDirectoryNumber,
isdnDirectorySigIndex, isdnDirectorySigIndex,
isdnDirectoryStatus isdnDirectoryStatus
} }
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"A collection of objects describing directory numbers." "A collection of objects describing directory numbers."
::= { isdnMibGroups 5 } ::= { isdnMibGroups 5 }
isdnMibNotificationsGroup NOTIFICATION-GROUP
NOTIFICATIONS { isdnMibCallInformation }
STATUS current
DESCRIPTION
"The notifications which a ISDN MIB entity is
required to implement."
::= { isdnMibGroups 6 }
END END
5. Acknowledgments 5. Acknowledgments
This document was produced by the ISDN MIB Working Group. Special This document was produced by the ISDN MIB Working Group. Special
thanks is due to the following persons: thanks is due to the following persons:
Ed Alcoff Ed Alcoff
Fred Baker Fred Baker
Scott Bradner Scott Bradner
Bibek A. Das Bibek A. Das
Maria Greene Maria Greene
Ken Grigg Ken Grigg
Stefan Hochuli Stefan Hochuli
Jeffrey T. Johnson Jeffrey T. Johnson
Glenn Kime Glenn Kime
Oliver Korfmacher Oliver Korfmacher
Kedar Madineni Kedar Madineni
Bill Miskovetz Bill Miskovetz
Mike O'Dowd Mike O'Dowd
David M. Piscitello David M. Piscitello
Lisa A. Phifer Lisa A. Phifer
Randy Roberts Randy Roberts
Hascall H. Sharp Hascall H. Sharp
John Shriver John Shriver
Robert Snyder Robert Snyder
Ron Stoughton Bob Stewart
James Watt Ron Stoughton
James Watt
6. References 6. References
[1] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and [1] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
S. Waldbusser, "Structure of Management Information for Version 2 S. Waldbusser, "Structure of Management Information for Version 2
of the Simple Network Management Protocol (SNMPv2)", RFC 1902, of the Simple Network Management Protocol (SNMPv2)", RFC 1902,
January 1996. January 1996.
[2] McCloghrie, K., and M. Rose, Editors, "Management Information Base [2] McCloghrie, K., and M. Rose, Editors, "Management Information Base
for Network Management of TCP/IP-based internets: MIB-II", STD 17, for Network Management of TCP/IP-based internets: MIB-II", STD 17,
skipping to change at page 45, line 29 skipping to change at page 48, line 37
specification", Rec. Q.932(I.452). specification", Rec. Q.932(I.452).
[10] ITU-T Recommendation "Digital subscriber Signaling System No. 1 [10] ITU-T Recommendation "Digital subscriber Signaling System No. 1
(DSS 1) - Signaling specification for frame-mode basic call (DSS 1) - Signaling specification for frame-mode basic call
control", Rec. Q.933. control", Rec. Q.933.
[11] McCloghrie, K. and F. Kastenholz, "Evolution of the Interfaces [11] McCloghrie, K. and F. Kastenholz, "Evolution of the Interfaces
Group of MIB-II", RFC 1573, Hughes LAN Systems, FTP Software, Group of MIB-II", RFC 1573, Hughes LAN Systems, FTP Software,
January 1994. January 1994.
[12] D. Fowler, "Definitions of Managed Objects for the DS1/E1/DS2/E2 [12] Fowler, D., "Definitions of Managed Objects for the DS1/E1/DS2/E2
Interface Types", RFCxxxx, Newbridge Networks, February 1996. Interface Types", Work in Progress.
[13] D. Fowler, "Definitions of Managed Objects for the DS0 and [13] Fowler, D., "Definitions of Managed Objects for the DS0 and
DS0Bundle Interface Types", RFCxxxx, Newbridge Networks, February DS0Bundle Interface Types", Work in Progress.
1996.
[14] ITU-T Recommendation "Integrated Services Digital Network (ISDN) [14] ITU-T Recommendation "Integrated Services Digital Network (ISDN)
General Structure and Service Capabilities - Closed User Group", General Structure and Service Capabilities - Closed User Group",
Rec. I.255.1. Rec. I.255.1.
[15] G. Roeck, "Dial Control Management Information Base", RFCxxxx, [15] Roeck, G., "Dial Control Management Information Base", RFC 2128,
cisco Systems, June 1996. March 1997.
7. Security Considerations 7. Security Considerations
Security issues are not discussed in this memo. Security issues are not discussed in this memo.
8. Author's Address 8. Author's Address
Guenter Roeck Guenter Roeck
cisco Systems cisco Systems
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
U.S.A. U.S.A.
Phone: +1 408 527 3143 Phone: +1 408 527 3143
Email: groeck@cisco.com EMail: groeck@cisco.com
 End of changes. 202 change blocks. 
614 lines changed or deleted 639 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/