RFC-to-be - DDS MIB
jkrey@isi.edu Tue, 19 March 1996 20:18 UTC
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22063; 19 Mar 96 15:18 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa22058; 19 Mar 96 15:18 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11818; 19 Mar 96 15:18 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22029; 19 Mar 96 15:17 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa22025; 19 Mar 96 15:17 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa11796; 19 Mar 96 15:17 EST
Received: from akamai.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id <AA17184>; Tue, 19 Mar 1996 12:16:41 -0800
Date: Tue, 19 Mar 1996 12:19:03 -0800
X-Orig-Sender: iesg-request@IETF.CNRI.Reston.VA.US
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: jkrey@isi.edu
Posted-Date: Tue, 19 Mar 1996 12:19:03 -0800
Message-Id: <199603192019.AA11594@akamai.isi.edu>
Received: by akamai.isi.edu (5.65c/4.0.3-4) id <AA11594>; Tue, 19 Mar 1996 12:19:03 -0800
To: kostick@qsun2.ho.att.com
Subject: RFC-to-be - DDS MIB
Cc: iesg@isi.edu, rfc-editor@isi.edu
Deirdre,
The RFC Editor has received an "Informational" RFC-to-be on,
"Definitions of Managed Objects for DDS Interface Types".
Two week timeout is initiated: 2 April 96.
Joyce
------------------------------------------------------------
Network Working Group M. Cotton
Request for Comments: nnnn Eastern Research Incorporated
February 1996
Category: Informational
Definitions of Managed Objects for DDS Interface Types
Status of this Memo
This memo provides information for the Internet community. This
memo does not specify an Internet standard of any kind.
Distribution of this memo is unlimited.
Introduction
This RFC defines a MIB which allows DDS-type interfaces to be
managed via SNMP. This is an attempt to ensure that SNMP
compliant DDS devices have a common MIB. No attempt has been
made to include devices which support DDS secondary channel
capability. This RFC is intended to allow for the SNMP managment
of the basic DDS CSU/DSU, without rate adaption.
Table of Contents
1. The Network Management Framework ...................... 2
2. Objects ............................................... 2
2.1 Format of Definitions ................................ 3
3. Overview .............................................. 4
3.1 Binding between ifIndex and DDS Interfaces ........... 5
3.2 Objectives of this MIB Module ........................ 7
3.3 DDS Terminology ...................................... 7
3.3.1 Performance and Availability ....................... 3
3.3.2 Network Alarms and Status Conditions ............... 3
3.3.3 Network Control Codes .............................. 3
3.3.4 Loopbacks and Their Methods ........................ 3
3.3.4.1 Non-Latching Loopbacks ........................... 4
3.3.4.2 Latching Loopbacks ............................... 4
4. Definitions ........................................... 4
4.1 DDS Configuration Table .............................. 5
4.2 DDS Diagnostics Table ................................ 7
4.3 DDS Alarm Table ...................................... 10
4.4 DDS Statistics Table ................................. 12
5. Acknowledgements ...................................... 14
6. References ............................................ 14
7. Security Considerations ............................... 15
8. Author's Address ...................................... 15
Cotton [Page 1]
RFC nnnn DDS MIB February 1996
1. The Network Management Framework
The Internet-standard Network Management Framework consists of three
components. They are:
STD 16/RFC 1155 [1] which defines the SMI, the mechanisms used for
describing and naming objects for the purpose of management. STD
16/RFC 1212 [2] defines a more concise description mechanism,
which is wholly consistent with the SMI.
RFC 1156 [3] which defines MIB-I, the core set of managed objects
for the Internet suite of protocols. STD 17/RFC 1213 [4] defines
MIB-II, an evolution of MIB-I based on implementation experience
and new operational requirements.
STD 15/RFC 1157 [5] which defines the SNMP, the protocol used for
network access to managed objects.
The Framework permits new objects to be defined for the purpose of
experimentation and evaluation.
2. Objects
Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. Objects in the MIB are
defined using the subset of Abstract Syntax Notation One (ASN.1) [6]
defined in the SMI. In particular, each object has a name, a syntax,
and an encoding. The name is an object identifier, an
administratively assigned name, which specifies an object type. The
object type together with an object instance serves to uniquely
identify a specific instantiation of the object. For human
convenience, we often use a textual string, termed the OBJECT
DESCRIPTOR, to also refer to the object type.
The syntax of an object type defines the abstract data structure
corresponding to that object type. The ASN.1 language is used for
this purpose. However, the SMI [1] purposely restricts the ASN.1
constructs which may be used. These restrictions are explicitly made
for simplicity.
The encoding of an object type is simply how that object type is
represented using the object type's syntax. Implicitly tied to the
notion of an object type's syntax and encoding is how the object type
is represented when being transmitted on the network.
The SMI specifies the use of the basic encoding rules of ASN.1 [7],
subject to the additional requirements imposed by the SNMP.
2.1. Format of Definitions
Cotton [Page 2]
RFC nnnn DDS MIB February 1996
Section 4 contains contains the specification of all object types
contained in this MIB module. The object types are defined using the
conventions defined in the SMI, as amended by the extensions
specified in STD 16, RFC 1212 [2].
3. Overview
This RFC applies to DDS-type devices which are SNMP managable. The
MIB contained herein describes objects for the management of config-
uration, diagnostics, alarms, and statistics related to DDS CSU/DSUs.
The definitions contained herein are based on the AT&T Digital Data-
phone Service (DDS) Specification [8].
3.1. Binding between ifIndex and DDS Interfaces
The ddsifIndex variables in the tables are always equal to the
ifIndex in MIB II.
3.2. Objectives of this MIB Module
There are numerous things that could be included in a MIB for DS1
signals: the management of multiplexors, CSUs, DSUs, and the like.
The intent of this document is to facilitate the common management of
all devices with DS1 interfaces. As such, a design decision was made
up front to very closely align the MIB with the set of objects that
can generally be read from DS1 devices that are currently deployed.
3.3. DDS Terminology
The terms used in this document, that describe the line conditions
of a DDS interface, come from AT&T's technical reference document
TR62310 - DS0 Digital Local Channel Description and Interface
Specification.
3.3.1 Performance and Availability
The performance terms used are Errored Seconds (ES), Error-Free
Seconds (EFS), and Severely Errored Seconds (SES). An Errored
Second is any second during which at least one bit was in error.
An Error-Free Second is a second during which there were no bits
in error. A Severely Errored Second is a second during which the
error threshold of 1x10^-3 was exceeded.
3.3.2 Network Alarms and Status Conditions
When a failure occurs in the network, a control code will be
forwarded through the network to the DCE at the customer interface.
3.3.3 Network Control Codes
Cotton [Page 3]
RFC nnnn DDS MIB February 1996
Table 5.3 on page 13 of AT&T TR 62310 specifies the Network Control
codes in detail. A further discussion of the nature of the codes
is not warranted here.
3.3.4 Loopbacks and Their Methods
The two loopbacks defined by TR 62310 are CSU loopback and DSU
loopback. The CSU loopback is intended to loop the network
connection back to itself as close as is possible to the network
interface (NI). The DSU loopback is usually implemented as a
bidirectional loop located a close as possible to the DTE side
of the CSU/DSU.
These loopbacks may be activated by either a non-latching method
or latching method.
3.3.4.1 Non-Latching Loopbacks
The non-latching loopback is activated when the network sends a
loop-code byte alternated with a test pattern byte. The loop
must start after the detection of four consecutive bytes of the
loop code (CSU or DSU) and remain engaged until five consecutive
bytes are received without the loop code. The loop codes must be
replaced with a return-code when looped back toward the network.
This is used to synchronize the test pattern detector.
3.3.4.2 Latching Loopbacks
Latching loops are named such because a pattern is sent from the
network to the CSU/DSU to cause a loopback condition which will
remain in effect once the patttern has ceased. On page 17 of
TR 62310, the sequence for activating the latching loopbacks are
described in detail.
Another approach that is often used is to follow the V.54 modem
loopback specification (CCITT Recommendation V.54 [11]).
4. Definitions
RFCnnnn-MIB DEFINITIONS ::= BEGIN
IMPORTS
Gauge
FROM RFC1155-SMI
transmission, DisplayString
FROM RFC1213-MIB
OBJECT-TYPE
FROM RFC-1212;
-- This MIB module uses the extended OBJECT-TYPE macro as
Cotton [Page 4]
RFC nnnn DDS MIB February 1996
-- defined in RFC 1212.
-- this is the MIB module for the DDS objects
dds OBJECT IDENTIFIER ::= { transmission 99 }
-- *******************
-- The DDS Local Group
-- *******************
-- Implementation of this group is mandatory for all systems
-- that attach to a DDS Interface.
-- The DDS Local Group consists of four tables:
-- DDS Configuration
-- DDS Diagnostics
-- DDS Alarms
-- DDS Statistics
-- ***************************
-- the DDS Configuration Table
-- ***************************
-- The DDS configuration table contains the basic configuration
-- variables for the CSU/DSU.
ddsConfigTable OBJECT-TYPE
SYNTAX SEQUENCE OF DDSConfigEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"The DDS Configuration table."
::= { dds 1 }
ddsConfigEntry OBJECT-TYPE
SYNTAX DDSConfigEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"An entry in the DDS Configuration table."
INDEX { ddsIfIndex }
::= { ddsConfigTable 1 }
DDSConfigEntry ::=
SEQUENCE {
ddsIfIndex
INTEGER,
ddsSpeed
INTEGER,
ddsNetworkLoops
Cotton [Page 5]
RFC nnnn DDS MIB February 1996
INTEGER,
ddsTiming
INTEGER
}
ddsIfIndex OBJECT-TYPE
SYNTAX INTEGER (1..'7fffffff'h)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This value for this object is equal to the
value of ifIndex from the Interfaces table of
MIB II (RFC 1213)."
::= { ddsConfigEntry 1 }
ddsSpeed OBJECT-TYPE
SYNTAX INTEGER {
bps2400(0),
bps4800(1),
bps9600(2),
bps19200(3),
bps56000(4),
bps64000(5)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"This variable indicates the speed of the DDS
circuit."
::= { ddsConfigEntry 2 }
ddsNetworkLoops OBJECT-TYPE
SYNTAX INTEGER { disabled(0), enabled(1) }
ACCESS read-write
STATUS mandatory
DESCRIPTION
"This variable represents the loopback config-
uration of the DDS interface. If it is desired
that the CSU/DSU should not respond to latching
or non-latching loops from the network, then the
variable should be set to the disabled state. If
it is desirable to have the CSU/DSU respond to loops
from the network, then this variable should be set
to enabled."
::= { ddsConfigEntry 3 }
ddsTiming OBJECT-TYPE
SYNTAX INTEGER { internal(0), dte(1), network(2) }
ACCESS read-write
STATUS mandatory
Cotton [Page 6]
RFC nnnn DDS MIB February 1996
DESCRIPTION
"This variable indicates where the CSU/DSU should
derive its timing from. The timing can either
come from the internal oscillator, the DTE inter-
face, or the network interface (most common option)."
::= { ddsConfigEntry 4 }
-- *************************
-- the DDS Diagnostics Table
-- *************************
-- The DDS diagnostic table contains the diagnostic element
-- variables for the CSU/DSU.
ddsDiagTable OBJECT-TYPE
SYNTAX SEQUENCE OF DDSDiagEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"The DDS diagnostic table."
::= { dds 2 }
ddsDiagEntry OBJECT-TYPE
SYNTAX DDSDiagEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"An entry in the DDS diagnostic table."
INDEX { ddsDiagIndex }
::= { ddsDiagTable 1 }
DDSDiagEntry ::=
SEQUENCE {
ddsDiagIndex
INTEGER,
ddsCSULoop
INTEGER,
ddsLineLoop
INTEGER,
ddsRemoteLoop
INTEGER,
ddsDSULoop
INTEGER,
ddsLoopStatus
INTEGER,
ddsBERT
INTEGER,
ddsInsertError
INTEGER,
Cotton [Page 7]
RFC nnnn DDS MIB February 1996
ddsResetErrors
INTEGER,
ddsLocalErrorSeconds
Counter,
ddsRemoteErrorSeconds
Counter,
ddsSecondsInTest
Counter
}
ddsDiagIndex OBJECT-TYPE
SYNTAX INTEGER (1..'7fffffff'h)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This value for this object is equal to the
value of ifIndex from the Interfaces table of
MIB II (RFC 1213)."
::= { ddsDiagEntry 1 }
ddsCSULoop OBJECT-TYPE
SYNTAX INTEGER {
off(0),
on(1)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The local analog loopback of the DDS CSU/DSU."
::= { ddsDiagEntry 2 }
ddsLineLoop OBJECT-TYPE
SYNTAX INTEGER {
off(0),
on(1)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Loop the DDS line back to the network."
::= { ddsDiagEntry 3 }
ddsRemoteLoop OBJECT-TYPE
SYNTAX INTEGER {
off(0),
on(1)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
Cotton [Page 8]
RFC nnnn DDS MIB February 1996
"Issue a remote DSU loop to the far end CSU/DSU."
::= { ddsDiagEntry 4 }
ddsDSULoop OBJECT-TYPE
SYNTAX INTEGER {
off(0),
on(1)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Loop the DTE(DSU) port on the CSU/DSU."
::= { ddsDiagEntry 5 }
ddsLoopStatus OBJECT-TYPE
SYNTAX INTEGER {
noLoopsEnabled(0),
csuLoopEnabled(1),
dsuLoopEnabled(2)
}
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Loop status of the CSU/DSU."
::= { ddsDiagEntry 6 }
ddsBERT OBJECT-TYPE
SYNTAX INTEGER {
off(0),
bert2047(1),
allZeroes(2)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Activate the bit error-rate tester on the CSU/DSU."
::= { ddsDiagEntry 7 }
ddsInsertError OBJECT-TYPE
SYNTAX INTEGER { no(0), yes(1) }
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Inserts a single bit error in the NI data stream."
::= { ddsDiagEntry 8 }
ddsResetErrors OBJECT-TYPE
SYNTAX INTEGER { no(0), yes(1) }
ACCESS read-write
STATUS mandatory
Cotton [Page 9]
RFC nnnn DDS MIB February 1996
DESCRIPTION
"Reset the test error counters."
::= { ddsDiagEntry 9 }
ddsLocalErrorSeconds OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Local errored-seconds counter."
::= { ddsDiagEntry 10 }
ddsRemoteErrorSeconds OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Remote errored-seconds counter."
::= { ddsDiagEntry 11 }
ddsSecondsInTest OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Counter for the number of seconds that the CSU/DSU's
BERT has been activated."
::= { ddsDiagEntry 12 }
-- ********************
-- the DDS Alarms Table
-- ********************
-- The DDS alarm table contains the alarm status element
-- variables for the CSU/DSU.
ddsAlarmTable OBJECT-TYPE
SYNTAX SEQUENCE OF DDSAlarmEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"The DDS alarm table."
::= { dds 3 }
ddsAlarmEntry OBJECT-TYPE
SYNTAX DDSAlarmEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
Cotton [Page 10]
RFC nnnn DDS MIB February 1996
"An entry in the DDS alarm table."
INDEX { ddsAlarmIndex }
::= { ddsAlarmTable 1 }
DDSAlarmEntry ::=
SEQUENCE {
ddsAlarmIndex
INTEGER,
ddsLOSState
INTEGER,
ddsOOSState
INTEGER,
ddsCMIState
INTEGER,
ddsOOFState
INTEGER,
ddsFERRState
INTEGER,
ddsBPVState
INTEGER
}
ddsAlarmIndex OBJECT-TYPE
SYNTAX INTEGER (1..'7fffffff'h)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This value for this object is equal to the
value of ifIndex from the Interfaces table of
MIB II (RFC 1213)."
::= { ddsAlarmEntry 1 }
ddsLOSState OBJECT-TYPE
SYNTAX INTEGER { off(0), on(1) }
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The loss-of-signal status of the DDS CSU/DSU."
::= { ddsAlarmEntry 2 }
ddsOOSState OBJECT-TYPE
SYNTAX INTEGER { off(0), on(1) }
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The out-of-service status of the DDS CSU/DSU."
::= { ddsAlarmEntry 3 }
ddsCMIState OBJECT-TYPE
SYNTAX INTEGER { off(0), on(1) }
Cotton [Page 11]
RFC nnnn DDS MIB February 1996
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The control-mode-idle status of the DDS CSU/DSU."
::= { ddsAlarmEntry 4 }
ddsOOFState OBJECT-TYPE
SYNTAX INTEGER { off(0), on(1) }
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The out-of-frame status of the DDS CSU/DSU."
::= { ddsAlarmEntry 5 }
ddsFERRState OBJECT-TYPE
SYNTAX INTEGER { off(0), on(1) }
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The framing-error status of the DDS CSU/DSU."
::= { ddsAlarmEntry 6 }
ddsBPVState OBJECT-TYPE
SYNTAX INTEGER { off(0), on(1) }
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The bipolar-violation status of the DDS CSU/DSU."
::= { ddsAlarmEntry 7 }
-- ************************
-- the DDS Statistics Table
-- ************************
-- The DDS alarm table contains the statistic counters for
-- the CSU/DSU.
ddsStatisticsTable OBJECT-TYPE
SYNTAX SEQUENCE OF DDSStatsEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"The DDS statistics table."
::= { dds 4 }
ddsStatsEntry OBJECT-TYPE
SYNTAX DDSStatsEntry
ACCESS not-accessible
STATUS mandatory
Cotton [Page 12]
RFC nnnn DDS MIB February 1996
DESCRIPTION
"An entry in the DDS statistics table."
INDEX { ddsStatsIndex }
::= { ddsStatisticsTable 1 }
DDSStatsEntry ::=
SEQUENCE {
ddsStatsIndex
INTEGER,
ddsLOSCount
Counter,
ddsOOSCount
Counter,
ddsCMICount
Counter,
ddsOOFCount
Counter,
ddsFERRCount
Counter,
ddsBPVCount
Counter
}
ddsStatsIndex OBJECT-TYPE
SYNTAX INTEGER (1..'7fffffff'h)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This value for this object is equal to the
value of ifIndex from the Interfaces table of
MIB II (RFC 1213)."
::= { ddsStatsEntry 1 }
ddsLOSCount OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The loss-of-signal errored-second count."
::= { ddsStatsEntry 2 }
ddsOOSCount OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The out-of-service errored-second count."
::= { ddsStatsEntry 3 }
ddsCMICount OBJECT-TYPE
Cotton [Page 13]
RFC nnnn DDS MIB February 1996
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The control-mode-idle errored-seconds count."
::= { ddsStatsEntry 4 }
ddsOOFCount OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The out-of-frame errored-seconds count."
::= { ddsStatsEntry 5 }
ddsFERRCount OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The framing-error errored-seconds count."
::= { ddsStatsEntry 6 }
ddsBPVCount OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The bipolar-violation errored-seconds count."
::= { ddsStatsEntry 7 }
END
5. Acknowledgements
I would like to thank Michael Nicolazzo and James Pollock, both
of Eastern Research, for proofreading this document and supplying
their comments and suggestions.
6. References
[1] Rose M., and K. McCloghrie, "Structure and Identification of
Management Information for TCP/IP-based internets", STD 16, RFC
1155, Performance Systems International, Hughes LAN Systems, May
1990.
Cotton [Page 14]
RFC nnnn DDS MIB February 1996
[2] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions",
STD 16, RFC 1212, Performance Systems International, Hughes LAN
Systems, March 1991.
[3] McCloghrie K., and M. Rose, "Management Information Base for
Network Management of TCP/IP-based internets", RFC 1156, Hughes
LAN Systems, Performance Systems International, May 1990.
[4] McCloghrie K., and M. Rose, Editors, "Management Information Base
for Network Management of TCP/IP-based internets", STD 17, RFC
1213, Performance Systems International, March 1991.
[5] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
Network Management Protocol", STD 15, RFC 1157, SNMP Research,
Performance Systems International, Performance Systems
International, MIT Laboratory for Computer Science, May 1990.
[6] Information processing systems - Open Systems Interconnection -
Specification of Abstract Syntax Notation One (ASN.1),
International Organization for Standardization, International
Standard 8824, December 1987.
[7] Information processing systems - Open Systems Interconnection -
Specification of Basic Encoding Rules for Abstract Notation One
(ASN.1), International Organization for Standardization,
International Standard 8825, December 1987.
[8] AT&T Technical Reference, TR 62310, DS0 Digital Local Channel
Description and Interface Specification, August 1993.
[9] AT&T Technical Reference, TR 62411, ACCUNET T1.5 Service
Description And Interface Specification, December 1990.
[10] AT&T Technical Reference, TR 62421, ACCUNET Spectrum of
Digital Service, December 1989.
[11] CCITT Volume VIII, Recommendation V.54, Loop Test Devices for
Modems, November 1980.
7. Security Considerations
This RFC raises no security issues that I am aware of.
8. Author's Address
Mark A. Cotton
Eastern Research, Inc.
Cotton [Page 15]
RFC nnnn DDS MIB February 1996
225 Executive Drive
Moorestown, New Jersey 08057
Phone: (609)-273-6622
EMail: mcotton@erinc.com
Cotton [Page 16]
--------------5EFAB0F4EB2--
- RFC-to-be - DDS MIB jkrey