INTERNET-DRAFT DDS MIB April 1996
Definitions of Managed Objects for DDS Interface Types
Mon Apr 8 9:00:00 EST 1996
Expires: October 13, 1996
draft-ietf-trunkmib-dds-mib-00.txt
Mark A. Cotton
Eastern Research, Inc.
mcotton@erinc.com
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
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 ``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 ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim).
Abstract
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in TCP/IP-based internets.
In particular, it defines objects for managing Digital Data System
(DDS) interfaces. Along with the Definition of Managed Objects for
RS-232-like Hardware Devices using SMIv2 [TBD], this memo also pro-
vides basic management capabilities for DDS DSU/CSU-like interfaces.
This memo specifies a MIB module in a manner that is both compliant
to the SNMPv2 SMI, and semantically identical to the peer SNMPv1
Expires October 1996 [Page 1]
INTERNET-DRAFT DDS MIB April 1996
definitions.
Introduction
This document reflects work being done by the trunk-mib working
group (trunk-mib@cisco.com). This document defines a MIB that allows
DDS-type interfaces to be managed via SNMP. This is an attempt
to ensure that SNMP compliant DDS devices have a common MIB.
An attempt has been made to include devices which support DDS
secondary channel capability. This document is intended to allow
for the SNMP managment of the basic DDS CSU/DSU, with and without
rate adaption.
Table of Contents
1. The SNMPv2 Network Management Framework ............... 2
2. Objects ............................................... 2
2.1 Format of Definitions ................................ 3
3. Overview .............................................. 3
3.1 Binding between ifIndex and DDS Interfaces ........... 8
3.2 DDS Terminology ...................................... 8
3.3 DDS Statistics and Diagnostics ....................... 8
3.3.1 Performance and Availability ....................... 8
3.3.2 Network Alarms and Status Conditions ............... 9
3.3.3 Network Control Codes .............................. 9
3.3.4 Loopbacks and Their Methods ........................ 9
3.3.4.1 Non-Latching Loopbacks ........................... 9
3.3.4.2 Latching Loopbacks ............................... 9
4. Definitions ........................................... 10
4.1 DDS Configuration Table .............................. 11
4.2 DDS Diagnostics Table ................................ 13
4.4 DDS Statistics Table ................................. 15
4.5 DDS Interface Group .................................. 17
4.6 DDS Interface Compliance ............................. 18
5. Acknowledgements ...................................... 18
6. References ............................................ 19
7. Security Considerations ............................... 20
8. Author's Address ...................................... 20
1. The SNMPv2 Network Management Framework
The SNMPv2 Network Management Framework consists of four major
components. They are:
o RFC 1442 [1] which defines the SMI, the mechanisms used for
describing and naming objects for the purpose of management.
Expires October 1996 [Page 2]
INTERNET-DRAFT DDS MIB April 1996
o STD 17, RFC 1213 [2] defines MIB-II, the core set of managed
objects for the Internet suite of protocols.
o RFC 1445 [3] which defines the administrative and other
architectural aspects of the framework.
o RFC 1448 [4] which defines 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.
2.1. Format of Definitions
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 that
are specified in RFC1442 [1], RFC1445 [3], and RFC1448 [4].
3. Overview
This document defines managed objects for a Digital Dataphone Service
(DDS) interface. At present these objects apply to an interface
with an ifType value dds (TBD).
Editors note: The ifType value dds needs to be allocated by the IANA
prior to this memo's publication.
The following diagram shows the various internal organization of
Expires October 1996 [Page 3]
INTERNET-DRAFT DDS MIB April 1996
a typical DDS DSU/CSU.
+--------------------------+-----------------------+---+
| | | |
| D DSU section | CSU section | D |
V.35,| a | | D | N
RS232,| t | | S | E
or | a It is this section | This section of the | | T
RS530 | that would be resp- | unit is responsible | i | W
inter-| i onsible for the rate | for the loop rate and | n | O
face | n adaption and the de- | the detection of all | t | R
| t tection of the V.54 | network loop codes, | e | K
(DTE) | e loopback pattern. | even for that of the | r |
| r | DSU loopbacks. These | f |
| f | are the XOV codes that| a |
| a | are outlined in AT&T | c |
| c | TR62310. | e |
| e | | |
| | | |
+--------------------------+-----------------------+---+
The MIB contained herein describes objects for the management of
configuration, diagnostics, alarms, and statistics related to DDS
DSU/CSUs. These definitions are based on the AT&T DS0 Local Digital
Channel Description and Interface Specification (TR 62310 [8]).
The objects defined in this memo provide instrumentation for the
Network Interface. The instrumentation for the Data Interface, is
provided by the managed objects for the given type of interface,
e.g. RFC 1695 [TBD] for the case where the Data Interface is an
RS-232-like interface or RFC TBD [TBD] for the case where the Data
interface is a DS0 on a DS0-like interface.
A interface with the ifType of dds(TBD) implements the ifGeneral
group defined in the IF-MIB [TBD] and uses the standard interfaces
objects as follows:
ifTable Object Use for DDS Interfaces
-------------- -------------------------------------------
ifIndex Interface index.
ifDescr As per the interfaces MIB [TBD]
ifType dds(TBD)
ifSpeed The speed at which the DDS interface
is operating. This is the same as
the value in ddsPrimaryChannelSpeed
except when it has a value of 64 kbits/s.
Expires October 1996 [Page 4]
INTERNET-DRAFT DDS MIB April 1996
In that case, ifSpeed will have a value
of 72 kbits/s
ifPhysAddress The value of the Circuit Identifier assigned
by the service provider. If there is no
value assigned, this object should have
a length of zero..
ifAdminStatus As per the Interfaces MIB [TBD]
ifOperStatus As per the Interfaces MIB [TBD]
ifLastChange As per the Interfaces MIB [TBD]
ifName As per the interfaces MIB [TBD].
ifLinkUpDownTrapEnable Set to enabled(1).
ifHighSpeed Zero (the maximum line speed is 72 kbits/s).
ifConnectorPresent true(1)
The following diagram demonstrates how an SNMP managable DDS DSU/CSU
shelf could be connected to a router to allow the router WANs
access to the DDS circuits.
+-----+
| | | R interface Network i/f
|E | | +---------------------+
|t | R | 56KBPS | Line#A | DDS Circuit
|h | |---------------+ - - - - - - - - - +------>
|e | O | | |
|r | | 64KBPS | Line#B | DDS Circuit
|n | U |---------------+ - - - - - - - - - - +------>
|e | | | DDS DSU/CSU Shelf |
|t | T | 9600BPS | Line#C | DDS Circuit
| | |---------------+ - - - -- -- - - - - +------>
|-----+ E | | |
| | | 19200BPS | Line#D | DDS Circuit
|L | R |---------------+ - - - - -- - - - - +------>
|A | | |_____________________|
|N | |
| +-----+
The assignment of the index values could for example be:
ifIndex ifType Description
Expires October 1996 [Page 5]
INTERNET-DRAFT DDS MIB April 1996
------- --------- --------------------------
1 rs232(33) Line A - Data Interface
2 rs232(33) Line B - Data Interface
3 dds (TBD) Line A - Network Interface
4 dds (TBD) Line B - Network Interface
5 rs232(33) Line C - Data Interface
6 dds (TBD) Line C - Network Interface
7 rs232(33) Line D - Data Interface
8 dds (TBD) Line D - Network Interface
9 rs232(33) Router
10 rs232(33) Router
11 rs232(33) Router
12 rs232(33) Router
13 ethernetCsmaCd Ethernet port
For this example, ifNumber is equal to 13. Note the following
description of ifIndex: it describes ports on the managed device.
In this example, some ports are RS-232-like interfaces, some are
DDS-like interfaces, some are RS-232-like interfaces that are not
associated with the DDS DSU/CSU lines, and there is one port which
is the ethernet port on the device.
The relationship between the Data Interface and the corresponding
Network Interface is captured in the ifStackTable.
ifStackTable Entries for proxy-managed DSU/CSU shelf:
Higher Layer Lower Layer
1 3
2 4
5 6
7 8
9 1
10 2
11 5
12 7
If the DSU/CSU shelf is managed by itself by a local SNMP Agent, that
is to say not managed by the router-based agent, the situation would
be as follows.
The assignment of the index values could for example be:
ifIndex ifType Description
------- --------- --------------------------
1 dds (TBD) Line A - Network Interface
2 rs232(33) Line A - Data Interface
3 dds (TBD) Line B - Network Interface
4 rs232(33) Line B - Data Interface
Expires October 1996 [Page 6]
INTERNET-DRAFT DDS MIB April 1996
5 dds (TBD) Line C - Network Interface
6 rs232(33) Line C - Data Interface
7 dds (TBD) Line D - Network Interface
8 rs232(33) Line D - Data Interface
Again, the relationship between the Data Interface and the
corresponding Network Interface is captured in the ifStackTable.
ifStackTable Entries for directly-managed DSU/CSU shelf:
Higher Layer Lower Layer
2 1
4 3
6 5
8 7
The next diagram demonstrates how an SNMP managable CSU might
be integrated within the router itself.
+-----+---------------------+
| | | | Network interfaces
| | | DDS CSU |
|E | | Line#A | DDS Circuit
|t | R + - - - - - - - - - +------------------->
|h | | DDS CSU |
|e | O | Line#B | DDS Circuit
|r | + - - - - - - - - - - +------------------->
|n | U | DDS CSU |
|e | | Line#C | DDS Circuit
|t | T + - - - -- -- - - - - +------------------->
| | | DDS CSU |
|-----| E | Line#D | DDS Circuit
| | + - - - - -- - - - - +------------------->
|L | R | |
|A | | DDS CSU | DDS Circuit
|N | | Line#E +------------------->
+-----+---------------------+
If the DDS CSUs are integrated within the router itself, the interface
organization might be as follows.
The assignment of the index values could for example be:
ifIndex ifType Description
------- --------- --------------------------
1 dds (TBD) Line A - Network Interface
2 dds (TBD) Line B - Network Interface
Expires October 1996 [Page 7]
INTERNET-DRAFT DDS MIB April 1996
3 dds (TBD) Line C - Network Interface
4 dds (TBD) Line D - Network Interface
5 dds (TBD) Line E - Network Interface
6 ethernetCsmaCd Ethernet port
In this example, there is no Data Interface present, because the
Network Interfaces terminate within the router. The ifStackTable
entries would only show these Network Interfaces alone.
ifStackTable Entries for a router with integral CSUs:
Higher Layer Lower Layer
1 1
2 2
3 3
4 4
3.1. Binding between ifIndex and DDS Interfaces
For DDS circuits with the secondary channel activated, it is at
the present time unclear how these interfaces will be accessed.
Certainly they are capable of being managed via RFC1659, however
the binding between the actual interface and an ifIndex that is
representative of that interface has not yet been determined.
3.2. 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 [8].
3.3. DDS Statistics and Diagnostics
The next sections describe the alarms and diagnostics which directly
pertain to DDS DSU/CSUs, as per AT&T TR 62310 [8].
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.
Expires October 1996 [Page 8]
INTERNET-DRAFT DDS MIB April 1996
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, the network will forward a
control code (possibly abnormal station code - ASC) toward the CSU
at the customer interface. The exact codes transmitted and the
conditions necessary for their generation are detailed in section
5.3 (page 11) of AT&T TR 62310 [8].
3.3.3 Network Control Codes
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 DDS Interface Loopbacks and Their Methods
The two loopbacks defined by TR 62310 [8] 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
Expires October 1996 [Page 9]
INTERNET-DRAFT DDS MIB April 1996
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 pattern has ceased. On page 17 of
TR 62310 [8], the sequence for activating the latching loopbacks
are described in detail.
4. Definitions
DDS-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, Counter32
FROM SNMPv2-SMI
MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF
TruthValue, TimeStamp FROM SNMPv2-TC
ifIndex FROM IF-MIB
experimental FROM RFC1213-MIB;
-- this is the MIB module for the DDS objects
ddsMIB MODULE-IDENTITY
LAST-UPDATED "9604080900Z"
ORGANIZATION "IETF Trunk MIB Working Group"
CONTACT-INFO
" Mark A. Cotton
Postal: Eastern Research, Inc.
225 Executive Drive
Moorestown, NJ 08057
Tel: 609-273-6622
Fax: 609-273-1847
E-mail: mcotton@erinc.com"
DESCRIPTION
"The MIB module for Digital Dataphone Service
DSU/CSU-like hardware devices."
::= { experimental 99 }
ddsObjects OBJECT IDENTIFIER ::= { ddsMIB 1 }
ddsGroups OBJECT IDENTIFIER ::= { ddsMIB 2 }
ddsCompliances OBJECT IDENTIFIER ::= { ddsMIB 3 }
-- The DDS Objects consists of three tables:
--
-- DDS Configuration
-- DDS Diagnostics
-- DDS Statistics
Expires October 1996 [Page 10]
INTERNET-DRAFT DDS MIB April 1996
-- ***************************
-- the DDS Configuration Table
-- ***************************
ddsConfigTable OBJECT-TYPE
SYNTAX SEQUENCE OF DdsConfigEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The DDS Configuration table contains the basic
configuration variables for the CSU/DSU."
::= { ddsObjects 1 }
ddsConfigEntry OBJECT-TYPE
SYNTAX DdsConfigEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the DDS Configuration table."
INDEX { ifIndex }
::= { ddsConfigTable 1 }
DdsConfigEntry ::=
SEQUENCE {
ddsPrimaryChannelSpeed INTEGER,
ddsAllowSecondaryChannel TruthValue,
ddsAllowNetworkLoops TruthValue,
ddsTransmitClockSource INTEGER
}
ddsPrimaryChannelSpeed OBJECT-TYPE
SYNTAX INTEGER {
bps2400(1),
bps4800(2),
bps9600(3),
bps19200(4),
bps56000(5),
bps64000(6)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This variable configures the speed of the DDS
circuit. This object will actually configure the
speed of the line interface circuitry which connects
to the DDS line. The line interface circuitry must
be programmed to the same rate as that of the DDS
circuit that is provided by the carrier."
Expires October 1996 [Page 11]
INTERNET-DRAFT DDS MIB April 1996
::= { ddsConfigEntry 1 }
ddsAllowSecondaryChannel OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This variable allows or disallows the secondary
DDS channel which will run at the following speeds.
Primary channel speed Secondary channel speed
--------------------- -----------------------
2400 bps 133 bps
4800 bps 266 bps
9600 bps 533 bps
19200 bps 1066 bps
56000 bps 2666 bps"
::= { ddsConfigEntry 2 }
ddsAllowNetworkLoops OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
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 }
ddsTransmitClockSource OBJECT-TYPE
SYNTAX INTEGER {
loopTiming(1),
localTiming(2),
throughTiming(3)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This variable indicates where the CSU/DSU should
derive its timing from. The timing can either
come from the internal oscillator (local), the DTE
interface (through), or the network interface (loop -
the most common option)."
::= { ddsConfigEntry 4 }
Expires October 1996 [Page 12]
INTERNET-DRAFT DDS MIB April 1996
-- *************************
-- the DDS Diagnostics Table
-- *************************
ddsDiagTable OBJECT-TYPE
SYNTAX SEQUENCE OF DdsDiagEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The DDS diagnostic table contains the diagnostic element
variables for the CSU/DSU."
::= { ddsMIB 2 }
ddsDiagEntry OBJECT-TYPE
SYNTAX DdsDiagEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the DDS diagnostic table."
INDEX { ifIndex }
::= { ddsDiagTable 1 }
DdsDiagEntry ::=
SEQUENCE {
ddsLoopbackConfig INTEGER,
ddsSendTestCode INTEGER,
ddsInsertTestError TruthValue,
ddsTestErrorSeconds Counter32,
ddsLastTestStart TimeStamp
}
ddsLoopbackConfig OBJECT-TYPE
SYNTAX INTEGER (1..7)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object contains the loopback configuration of the
network interface of the DSU/CSU. It contains various
fields merged together to form a collection of bits in
a single variable. The bit-definitions are as follows.
1 ddsNoLoop - No loopback activated.
2 ddsCSULoop - Activate the CSU loopback.
This means that the DDS line
should be looped back toward the
network.
4 ddsLocalLoop - Activate the local network loop.
Expires October 1996 [Page 13]
INTERNET-DRAFT DDS MIB April 1996
This engages the local loopback
of the DSU/CSU which means that
the network interface should be
looped back toward itself.
This is used for self-diagnostic
purposes and is not a mode which
can be engaged by the TELCO.
It should be noted that ddsNoLoop should be the only
field set if all loops are to be disabled."
::= { ddsDiagEntry 1 }
ddsSendTestCode OBJECT-TYPE
SYNTAX INTEGER {
sendNoCode(1),
sendBERT2047(2),
sendAllZeroes(3),
sendRemoteLoopCode(4)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Activate the bit error-rate tester on the CSU/DSU,
which would send the BERT pattern toward the network
interface. This object is also used for issuing a
remote loopback command to the far-end DDS DSU/CSU."
::= { ddsDiagEntry 2 }
ddsInsertTestError OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Inserts a single bit error toward the network
interface. This object will only ever read FALSE."
::= { ddsDiagEntry 3 }
ddsTestErrorSeconds OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The errored-seconds counter. This object reflects
the counter which observes the bit-error-rate tester
errors being received on the network interface of the
DSU/CSU."
::= { ddsDiagEntry 4 }
ddsLastTestStart OBJECT-TYPE
Expires October 1996 [Page 14]
INTERNET-DRAFT DDS MIB April 1996
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Time stamp for when the BERT test was activated."
::= { ddsDiagEntry 5 }
-- ************************
-- the DDS Statistics Table
-- ************************
ddsStatisticsTable OBJECT-TYPE
SYNTAX SEQUENCE OF DdsStatsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The DDS alarm table contains the statistic counters for
the CSU/DSU."
::= { ddsMIB 3 }
ddsStatsEntry OBJECT-TYPE
SYNTAX DdsStatsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the DDS statistics table."
INDEX { ifIndex }
::= { ddsStatisticsTable 1 }
DdsStatsEntry ::=
SEQUENCE {
ddsLineStatus INTEGER,
ddsLOSCount Counter32,
ddsOOSCount Counter32,
ddsCMICount Counter32,
ddsOOFCount Counter32,
ddsFERRCount Counter32,
ddsBPVCount Counter32
}
ddsLineStatus OBJECT-TYPE
SYNTAX INTEGER (1..1023)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object contains the line status of the network
interface of the DDS DSU/CSU merged together to form
a collection of bits in a single variable. The bit
definitions are as follows.
Expires October 1996 [Page 15]
INTERNET-DRAFT DDS MIB April 1996
1 ddsNoAlarm - No alarm is present.
2 ddsLOS - Loss of signal.
4 ddsOOS - Out of service.
8 ddsCMI - Control mode idle.
16 ddsOOF - Out of frame.
32 ddsFERR - Frame error.
64 ddsBPV - Bipolar violation.
128 ddsCSULoop - The CSU loop is active.
256 ddsLocalLoop - The local network loop is active.
512 ddsOtherLoop - Some other loopback is active.
It should be noted that ddsNoAlarm status may only be
set when no other alarm or diagnostic condition is
present."
::= { ddsStatsEntry 1 }
ddsLOSCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The loss-of-signal errored-second count. This is
an error condition that occurs when the line interface
has detected that no receive signal is present. This
is usually declared after receiving 32 consecutive
zeroes on the receive data stream of the network
interface."
::= { ddsStatsEntry 2 }
ddsOOSCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The out-of-service errored-second count. This is
described in section 9.7.4 of AT&T TR 62310."
::= { ddsStatsEntry 3 }
ddsCMICount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The control-mode-idle errored-seconds count. This is
described in section 9.7.4 of AT&T TR 62310."
::= { ddsStatsEntry 4 }
ddsOOFCount OBJECT-TYPE
Expires October 1996 [Page 16]
INTERNET-DRAFT DDS MIB April 1996
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The out-of-frame errored-seconds count. This is
described in section 9.7.4 of AT&T TR 62310."
::= { ddsStatsEntry 5 }
ddsFERRCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The framing-error errored-second count. This condition
may only be detected in 64KBPS mode which uses a framing
pattern. This errored-second counter is incremented
whenever a second is sampled during which a framing
error occurred."
::= { ddsStatsEntry 6 }
ddsBPVCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The bipolar-violation errored-seconds count. This
counter is incremented whenever a second is sampled
during which at least one bipolar violation occurred."
::= { ddsStatsEntry 7 }
-- ***********************
-- The DDS Interface Group
-- ***********************
ddsInterfaceGroup OBJECT-GROUP
OBJECTS {
ddsPrimaryChannelSpeed,
ddsAllowSecondaryChannel,
ddsAllowNetworkLoops,
ddsTransmitClockSource,
ddsLoopbackConfig,
ddsSendTestCode,
ddsInsertTestError,
ddsTestErrorSeconds,
ddsLastTestStart,
ddsLineStatus,
ddsLOSCount,
ddsOOSCount,
ddsCMICount,
Expires October 1996 [Page 17]
INTERNET-DRAFT DDS MIB April 1996
ddsOOFCount,
ddsFERRCount,
ddsBPVCount
}
STATUS current
DESCRIPTION
"The objects required to instrument a Digital Dataphone
System (DDS) Interface."
::= { ddsGroups 1 }
-- ************************
-- DDS Interface Compliance
-- ************************
ddsInterfaceCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for Digital Dataphone System
(DDS) interfaces."
MODULE -- this module
MANDATORY-GROUPS { ddsInterfaceGroup }
::= { ddsCompliances 1}
END
5. Acknowledgements
This document was produced by the Trunk MIB Working Group:
Tracy Cox Bellcore
Fred Baker Advanced Computer Communications
James Watt Newbridge
Bill Versteeg Versteeg Codeworks
Steve Buchko Newbridge
Greg Celmainis Newbridge
Kaj Tesink Bellcore
Al Bryenton Bell Northern Research
Tom Easterday CIC
John Labbe Merit Corporation
Chris Sullivan Gandalf Ltd
Grant Hall Gandalf Ltd
Laurence V. Marks IBM Corp.
Kurt Hall Clear Communications Corp.
Expires October 1996 [Page 18]
INTERNET-DRAFT DDS MIB April 1996
Myron Hattig ADC Kentrox
Does my name go in here at all?
James Watt deserves my thanks for working with me in order to ensure
that this memo is compliant with the accepted philosophy of the
management framework.
I would like to thank Michael Nicolazzo and James Pollock, both
of Eastern Research, for supplying their comments and suggestions.
6. References
[1] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure
of Management Information for version 2 of the Simple Network
Management Protocol (SNMPv2)", RFC 1442, SNMP Research,Inc.,
Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon
University, April 1993.
[2] McCloghrie, K., and M. Rose, Editors, "Management Information
Base for Network Management of TCP/IP-based internets: MIB-II",
STD 17, RFC 1213, Hughes LAN Systems, Performance Systems
International, March 1991.
[3] Galvin, J., and K. McCloghrie, "Administrative Model for version
2 of the Simple Network Management Protocol (SNMPv2)", RFC 1445,
Trusted Information Systems, Hughes LAN Systems, April 1993.
[4] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol
Operations for version 2 of the Simple Network Management
Protocol (SNMPv2)", RFC 1448, SNMP Research,Inc., Hughes LAN
Systems, Dover Beach Consulting, Inc., Carnegie Mellon
University, April 1993.
[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.
Expires October 1996 [Page 19]
INTERNET-DRAFT DDS MIB April 1996
[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
Security issues are not discussed in this memo.
8. Author's Address
Mark A. Cotton
Eastern Research, Inc.
225 Executive Drive
Moorestown, New Jersey 08057
Phone: (609)-273-6622
EMail: mcotton@erinc.com
Expires October 1996 [Page 20]
