draft-ietf-isdnmib-dial-control-01.txt   draft-ietf-isdnmib-dial-control-02.txt 
Dial Control Management Information Base Dial Control Management Information Base
draft-ietf-isdnmib-dial-control-01.txt draft-ietf-isdnmib-dial-control-02.txt
Fri Nov 17 14:49:37 MET 1995 Mon Feb 5 21:53:26 MET 1996
Guenter Roeck (editor) Guenter Roeck (editor)
Conware GmbH Conware GmbH
roeck@conware.de roeck@conware.de
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas, and documents of the Internet Engineering Task Force (IETF), its Areas, and
its Working Groups. Note that other groups may also distribute working its Working Groups. Note that other groups may also distribute working
skipping to change at page 2, line 10 skipping to change at page 2, line 10
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast). ftp.isi.edu (US West Coast).
1. Introduction 1. Introduction
This draft defines an experimental portion of the Management Information This draft defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet Base (MIB) for use with network management protocols in the Internet
community. In particular, it describes managed objects used for community. In particular, it describes managed objects used for
managing demand access circuits, including ISDN. The set of objects managing demand access circuits, including ISDN.
will be consistent with the SNMP framework and existing SNMP standards.
This document specifies a MIB module in a manner that is both compliant
to the SNMPv2 SMI, and semantically identical to the peer SNMPv1
definitions.
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 be
addressed to the working group's mailing list at isdn-mib@cisco.com addressed to the working group's mailing list at isdn-mib@cisco.com
and/or the author. and/or the author.
2. The SNMPv2 Network Management Framework 2. The Community-based SNMPv2 Network Management Framework
The SNMPv2 Network Management Framework consists of four major The Community-based SNMPv2 Network Management Framework consists of four
components. They are: major components. They are:
o RFC 1442 [1] which defines the SMI, the mechanisms used for o RFC 1902 [1] which defines the SMI, the mechanisms used for
describing and naming objects for the purpose of management. describing and naming objects for the purpose of management.
o STD 17, RFC 1213 [2] defines MIB-II, the core set of managed o STD 17, RFC 1213 [2] defines MIB-II, the core set of managed
objects for the Internet suite of protocols. objects for the Internet suite of protocols.
o RFC 1445 [3] which defines the administrative and other o RFC 1901 [3] which defines the administrative and other
architectural aspects of the framework. architectural aspects of the framework.
o RFC 1448 [4] which defines the protocol used for network access to o RFC 1905 [4] which defines the protocol used for network access to
managed objects. 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.1. Object Definitions 2.1. Object Definitions
Managed objects are accessed via a virtual information store, termed the Managed objects are accessed via a virtual information store, termed the
Management Information Base or MIB. Objects in the MIB are defined Management Information Base or MIB. Objects in the MIB are defined
using the subset of Abstract Syntax Notation One (ASN.1) defined in the using the subset of Abstract Syntax Notation One (ASN.1) defined in the
skipping to change at page 4, line 27 skipping to change at page 4, line 27
The MIB, therefore, consists of three groups. The MIB, therefore, consists of three groups.
o The dialCtlConfiguration group is used to specify general o The dialCtlConfiguration group is used to specify general
configuration information. configuration information.
o The dialCtlNeighbor group is used to describe neighbors and o The dialCtlNeighbor group is used to describe neighbors and
neighbor statistics. neighbor statistics.
o The callHistory group is used to store call history information. o The callHistory group is used to store call history information.
These calls could be circuit switched or they could be virtual These calls could be circuit switched or they could be virtual
circuits. History of each and every call is stored, of sucessful circuits. History of each and every call is stored, of successful
calls as well as unsucessful and rejected calls. An entry will be calls as well as unsuccessful and rejected calls. An entry will be
created when a call is cleared. created when a call is cleared.
3.2. Relationship to RFC1573 3.2. Relationship to RFC1573
RFC 1573, the Interface MIB Evolution, requires that any MIB module RFC 1573, the Interface MIB Evolution, requires that any MIB module
which is an adjunct of the Interface MIB, clarify specific areas within which is an adjunct of the Interface MIB, clarify specific areas within
the Interface MIB. These areas were intentionally left vague in RFC the Interface MIB. These areas were intentionally left vague in RFC
1573 to avoid over constraining the MIB module, thereby precluding 1573 to avoid over constraining the MIB module, thereby precluding
management of certain media-types. management of certain media-types.
skipping to change at page 6, line 25 skipping to change at page 6, line 25
3.2.3. ifRcvAddressTable 3.2.3. ifRcvAddressTable
The ifRcvAddressTable usage will be defined in the MIBs defining the The ifRcvAddressTable usage will be defined in the MIBs defining the
encapsulation below the network layer. For example, if PPP encapsulation below the network layer. For example, if PPP
encapsulation is being used, the ifRcvAddressTable will be defined by encapsulation is being used, the ifRcvAddressTable will be defined by
PPP. PPP.
3.2.3.1. ifEntry for a single neighbor 3.2.3.1. ifEntry for a single neighbor
IfEntries will be defined in the MIBs defining the encapsulation below IfEntries will be defined in the MIBs defining the encapsulation below
the network leyer. For example, if PPP encapsulation is being used, the the network layer. For example, if PPP encapsulation is being used, the
ifEntry will be defined by PPP. ifEntry will be defined by PPP.
3.3. Multilink and backup line support 3.3. Multilink and backup line support
In order to support multilink and backup procedures, there may be In order to support multilink and backup procedures, there may be
several entries for a single neighbor in the dialCtlNbrCfgTable. several entries for a single neighbor in the dialCtlNbrCfgTable.
A single neighbor will be identified using the dialCtlNbrCfgId object of A single neighbor will be identified using the dialCtlNbrCfgId object of
the dialCtlNbrCfgTable. There may be several entries in the dialCtlNbrCfgTable. There may be several entries in
dialCtlNbrCfgTable with the same value of dialCtlNbrCfgId, but different dialCtlNbrCfgTable with the same value of dialCtlNbrCfgId, but different
ifIndex values. Each of those entries will then describe a possible ifIndex values. Each of those entries will then describe a possible
connection to the same neighbor. Such entries can then be used to connection to the same neighbor. Such entries can then be used to
handle multilink as well as backup procedures, e.g. by bundling the handle multilink as well as backup procedures, e.g. by bundling the
attached ifEntries using PPP multilink. attached ifEntries using PPP multilink.
3.4. Support for generic neighbors
Generic neighbors can for example be supported by permitting wild-card
characters (e.g., '?' or '*') in dialCtlNbrCfgAnswerAddress. A number
to be accepted could then be defined as partly (e.g., '*1234') or
entirely generic (e.g., '*').
A detailed specification of such a functionality is outside the scope of
this document.
However, the implementor should be aware that supporting generic
neighbors may cause a security hole. The user would not know where a
call is from, which could potentially allow unauthorized access.
4. Definitions 4. Definitions
4.1. Dial Control MIB 4.1. Dial Control MIB
DIAL-CONTROL-MIB DEFINITIONS ::= BEGIN DIAL-CONTROL-MIB DEFINITIONS ::= BEGIN
IMPORTS IMPORTS
MODULE-IDENTITY, MODULE-IDENTITY,
NOTIFICATION-TYPE, NOTIFICATION-TYPE,
OBJECT-TYPE, OBJECT-TYPE,
skipping to change at page 7, line 35 skipping to change at page 8, line 35
IANAifType IANAifType
FROM IANAifType-MIB FROM IANAifType-MIB
ifIndex, ifIndex,
ifOperStatus, ifOperStatus,
InterfaceIndex InterfaceIndex
FROM IF-MIB FROM IF-MIB
transmission transmission
FROM RFC1213-MIB; FROM RFC1213-MIB;
dialControlMib MODULE-IDENTITY dialControlMib MODULE-IDENTITY
LAST-UPDATED "9511171437Z" LAST-UPDATED "MIB_DATE"
ORGANIZATION "IETF ISDN Working Group" ORGANIZATION "IETF ISDN Working Group"
CONTACT-INFO CONTACT-INFO
" Guenter Roeck " Guenter Roeck
Postal: Conware GmbH Postal: Conware GmbH
Killisfeldstrasse 64 Killisfeldstrasse 64
76227 Karlsruhe 76227 Karlsruhe
Germany Germany
Tel: +49 721 9495 0 Tel: +49 721 9495 0
E-mail: roeck@conware.de" E-mail: roeck@conware.de"
DESCRIPTION DESCRIPTION
skipping to change at page 10, line 48 skipping to change at page 11, line 48
SYNTAX InterfaceIndex SYNTAX InterfaceIndex
MAX-ACCESS read-create MAX-ACCESS read-create
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"ifIndex value of an interface the neighbor will have to be "ifIndex value of an interface the neighbor will have to be
called on. For example, on an ISDN interface, this can be called on. For example, on an ISDN interface, this can be
the ifIndex value of a D channel or the ifIndex value of a the ifIndex value of a D channel or the ifIndex value of a
B channel, whatever is appropriate for a given neighbor. B channel, whatever is appropriate for a given neighbor.
As an example, for Basic Rate leased lines it will be As an example, for Basic Rate leased lines it will be
necessary to specify a B channel ifIndex, while for necessary to specify a B channel ifIndex, while for
'Semipermanente Verbindungen' (semi permanent connections) semi-permanent connections the D channel ifIndex has
in 1TR6, the D channel ifIndex has to be specified. to be specified.
If the interface can be dynamically assigned, this object If the interface can be dynamically assigned, this object
has a value of zero." has a value of zero."
DEFVAL { 0 } DEFVAL { 0 }
::= { dialCtlNbrCfgEntry 3 } ::= { dialCtlNbrCfgEntry 3 }
dialCtlNbrCfgOriginateAddress OBJECT-TYPE dialCtlNbrCfgOriginateAddress OBJECT-TYPE
SYNTAX DisplayString SYNTAX DisplayString
MAX-ACCESS read-create MAX-ACCESS read-create
STATUS current STATUS current
DESCRIPTION DESCRIPTION
skipping to change at page 12, line 8 skipping to change at page 13, line 8
unused, this is a zero length string." unused, this is a zero length string."
DEFVAL { "" } DEFVAL { "" }
::= { dialCtlNbrCfgEntry 6 } ::= { dialCtlNbrCfgEntry 6 }
dialCtlNbrCfgClosedUserGroup OBJECT-TYPE dialCtlNbrCfgClosedUserGroup OBJECT-TYPE
SYNTAX DisplayString SYNTAX DisplayString
MAX-ACCESS read-create MAX-ACCESS read-create
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Closed User Group at which the neighbor will be called, "Closed User Group at which the neighbor will be called,
as defined in [5], chapter 4.6.1. as defined in Q.931 [5], chapter 4.6.1.
If the Closed User Group is undefined for the given media If the Closed User Group is undefined for the given media
or unused, this is a zero length string." or unused, this is a zero length string."
DEFVAL { "" } DEFVAL { "" }
::= { dialCtlNbrCfgEntry 7 } ::= { dialCtlNbrCfgEntry 7 }
dialCtlNbrCfgSpeed OBJECT-TYPE dialCtlNbrCfgSpeed OBJECT-TYPE
SYNTAX INTEGER (0..2147483647) SYNTAX INTEGER (0..2147483647)
MAX-ACCESS read-create MAX-ACCESS read-create
STATUS current STATUS current
DESCRIPTION DESCRIPTION
skipping to change at page 19, line 12 skipping to change at page 20, line 12
0 will prevent any history from being retained in the 0 will prevent any history from being retained in the
callHistoryTable, but will neither prevent callCompletion callHistoryTable, but will neither prevent callCompletion
traps being generated nor affect other tables." traps being generated nor affect other tables."
::= { callHistory 2 } ::= { callHistory 2 }
-- callHistoryTable -- callHistoryTable
-- Table to store the past call information. The Destination number -- Table to store the past call information. The Destination number
-- and the call connect and disconnect time, the disconnection cause -- and the call connect and disconnect time, the disconnection cause
-- are stored. These calls could be circuit switched or they could -- are stored. These calls could be circuit switched or they could
-- be virtual circuits. History of each and every call is stored, -- be virtual circuits. History of each and every call is stored,
-- of successful calls as well as of unsuccessful and rejected calls.
-- An entry will be created when a call is cleared. -- An entry will be created when a call is cleared.
callHistoryTable OBJECT-TYPE callHistoryTable OBJECT-TYPE
SYNTAX SEQUENCE OF CallHistoryEntry SYNTAX SEQUENCE OF CallHistoryEntry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"A table containing information about specific "A table containing information about specific
calls to a specific destination." calls to a specific destination."
::= { callHistory 3 } ::= { callHistory 3 }
skipping to change at page 27, line 5 skipping to change at page 28, line 5
callHistoryReceiveBytes callHistoryReceiveBytes
} }
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"A collection of objects providing the Call History "A collection of objects providing the Call History
capability." capability."
::= { dialControlMibGroups 2 } ::= { dialControlMibGroups 2 }
END END
5. Acknowledgements 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
Bibek A. Das Bibek A. Das
Ken Grigg Ken Grigg
Jeffrey T. Johnson Jeffrey T. Johnson
Glenn Kime Glenn Kime
skipping to change at page 27, line 29 skipping to change at page 28, line 29
David M. Piscitello David M. Piscitello
Lisa A. Phifer Lisa A. Phifer
Randy Roberts Randy Roberts
Hascall H. Sharp Hascall H. Sharp
Robert Snyder Robert Snyder
Ron Stoughton Ron Stoughton
James Watt James Watt
6. References 6. References
[1] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure [1] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
of Management Information for version 2 of the Simple Network S. Waldbusser, "Structure of Management Information for Version 2
Management Protocol (SNMPv2)", RFC 1442, SNMP Research,Inc., Hughes of the Simple Network Management Protocol (SNMPv2)", RFC 1902,
LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon January 1996.
University, April 1993.
[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,
RFC 1213, Hughes LAN Systems, Performance Systems International, RFC 1213, Hughes LAN Systems, Performance Systems International,
March 1991. March 1991.
[3] Galvin, J., and K. McCloghrie, "Administrative Model for version 2 [3] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and
of the Simple Network Management Protocol (SNMPv2)", RFC 1445, S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901,
Trusted Information Systems, Hughes LAN Systems, April 1993. January 1996.
[4] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol [4] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and
Operations for version 2 of the Simple Network Management Protocol S. Waldbusser, "Protocol Operations for Version 2 of the Simple
(SNMPv2)", RFC 1448, SNMP Research,Inc., Hughes LAN Systems, Dover Network Management Protocol (SNMPv2)", RFC 1905, January 1996.
Beach Consulting, Inc., Carnegie Mellon University, April 1993.
[5] ITU-T Recommendation "Digital subscriber Signalling System No. 1 [5] ITU-T Recommendation "Digital subscriber Signalling System No. 1
(DSS 1) - ISDN user-network interface layer 3 specification for (DSS 1) - ISDN user-network interface layer 3 specification for
[6] ITU-T Recommendation "Generic procedures for the control of ISDN [6] ITU-T Recommendation "Generic procedures for the control of ISDN
supplementary services ISDN user-network interface layer 3 supplementary services ISDN user-network interface layer 3
specification", Rec. Q.932(I.452) specification", Rec. Q.932(I.452)
[7] ITU-T Recommendation "Digital subscriber Signalling System No. 1 [7] ITU-T Recommendation "Digital subscriber Signalling System No. 1
(DSS 1) - Signalling specification for frame-mode basic call (DSS 1) - Signalling specification for frame-mode basic call
control", Rec. Q.933 control", Rec. Q.933
7. Security Considerations 7. Security Considerations
Security issues are not discussed in this memo. Information in this MIB may be used by upper protocol layers for
security purpose.
The implementor should be aware that supporting generic neighbors as
described in section 3.4 may cause a security hole. The user would not
know where a call is from, which could potentially allow unauthorized
access if there is no other authentication scheme, e.g. PPP
authentication, available.
8. Author's Address 8. Author's Address
Guenter Roeck Guenter Roeck
Conware GmbH Conware GmbH
Killisfeldstrasse 64 Killisfeldstrasse 64
76137 Karlsruhe, Germany 76137 Karlsruhe, Germany
Phone: (49) 721 9495-0 Phone: +49 721 9495 0
Email: roeck@conware.de Email: roeck@conware.de
Table of Contents Table of Contents
1 Introduction .................................................... 2 1 Introduction .................................................... 2
2 The SNMPv2 Network Management Framework ......................... 3 2 The Community-based SNMPv2 Network Management Framework ......... 3
2.1 Object Definitions ............................................ 3 2.1 Object Definitions ............................................ 3
3 Overview ........................................................ 4 3 Overview ........................................................ 4
3.1 Structure of MIB .............................................. 4 3.1 Structure of MIB .............................................. 4
3.2 Relationship to RFC1573 ....................................... 4 3.2 Relationship to RFC1573 ....................................... 4
3.2.1 Layering Model and Virtual Circuits ......................... 4 3.2.1 Layering Model and Virtual Circuits ......................... 4
3.2.2 ifTestTable ................................................. 6 3.2.2 ifTestTable ................................................. 6
3.2.3 ifRcvAddressTable ........................................... 6 3.2.3 ifRcvAddressTable ........................................... 6
3.2.3.1 ifEntry for a single neighbor ............................. 6 3.2.3.1 ifEntry for a single neighbor ............................. 6
3.3 Multilink and backup line support ............................. 6 3.3 Multilink and backup line support ............................. 6
4 Definitions ..................................................... 7 3.4 Support for generic neighbors ................................. 6
4.1 Dial Control MIB .............................................. 7 4 Definitions ..................................................... 8
5 Acknowledgements ................................................ 27 4.1 Dial Control MIB .............................................. 8
6 References ...................................................... 27 5 Acknowledgments ................................................. 28
7 Security Considerations ......................................... 29 6 References ...................................................... 28
8 Author's Address ................................................ 29 7 Security Considerations ......................................... 30
8 Author's Address ................................................ 30
 End of changes. 23 change blocks. 
33 lines changed or deleted 57 lines changed or added

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