Internet DRAFT - draft-cotton-dds-mib
draft-cotton-dds-mib
HTTP/1.1 200 OK
Date: Mon, 08 Apr 2002 23:22:12 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Wed, 03 Apr 1996 22:00:00 GMT
ETag: "2e7fac-8563-3162f4e0"
Accept-Ranges: bytes
Content-Length: 34147
Connection: close
Content-Type: text/plain
Network Working Group M. Cotton
Internet-Draft Eastern Research Incorporated
April 1996
Category: Informational
Definitions of Managed Objects for DDS Interface Types
<draft-cotton-dds-mib-00.txt>
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 document reflects work being done by the trunk-mib working
group (trunk-mib@cisco.com). This document 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.
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 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
Trunk MIB Working Group [Page 1]
RFC nnnn DDS MIB April 1996
7. Security Considerations ............................... 15
8. Author's Address ...................................... 15
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.
Trunk MIB Working Group [Page 2]
RFC nnnn DDS MIB April 1996
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
specified in STD 16, RFC 1212 [2].
3. Overview
This document 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].
The following diagram demonstrates how an SNMP managable 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 | | 56KBPS | Line#A | DDS Circuit
|t | R |---------------+ - - - - - - - - - +------>
|h | | | |
|e | O | 64KBPS | Line#B | DDS Circuit
|r | |---------------+ - - - - - - - - - - +------>
|n | U | | DSU/CSU Shelf |
|e | | 9600BPS | Line#C | DDS Circuit
|t | T |---------------+ - - - -- -- - - - - +------>
| | | | |
|-----| E | 19200BPS | Line#D | DDS Circuit
| | |---------------+ - - - - -- - - - - +------>
|L | R | |_____________________|
|A | |
|N +-----+
The following diagram shows the various internal organization of
a typical DDS DSU/CSU.
+---+-----------------------+-----------------------+---+
| | | | |
| R | DSU section | CSU section | D |
V.35,| | | | D | N
RS232,| i | | | S | E
or | n | It is this section | This section of the | | T
RS530 | t | that would be resp- | unit is responsible | i | W
Trunk MIB Working Group [Page 3]
RFC nnnn DDS MIB April 1996
inter-| e | onsible for the rate | for the loop rate and | n | O
face | r | adaption and the de- | the detection of all | t | R
| f | tection of the V.54 | network loop codes, | e | K
(DTE) | a | and loopback pattern.| even for that of the | r |
| c | This section also | DSU loopbacks. These | f |
| e | puts clocks out to | are the XOV codes that| a |
| | R interface for use | are outlined in AT&T | c |
| | by the DTE equipment.| TR62310. | e |
| | | | |
+---+-----------------------+-----------------------+---+
3.1. Binding between ifIndex and DDS Interfaces
The ifIndex is used throughout to identify the DDS interfaces
if more than one is available on the equipment in use.
3.2. Objectives of this MIB Module
As stated above, this MIB was designed soley for the management of
devices with DDS network interfaces. This would include, but is
not limited to DDS DSU/CSUs, routers with DDS network interfaces,
and the like. Since the devices currently deployed use enterprise
MIBs for this type of management, this MIB is proposed to allow
for a standardized management methodology.
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
Table 5.3 on page 13 of AT&T TR 62310 specifies the Network Control
Trunk MIB Working Group [Page 4]
RFC nnnn DDS MIB April 1996
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
MODULE-IDENTITY, OBJECT-TYPE FROM SNMPv2-SMI
MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF
TruthValue FROM SNMPv2-TC
ifIndex FROM IF-MIB
transmission FROM RFC1213-MIB;
-- this is the MIB module for the DDS objects
dds OBJECT IDENTIFIER ::= { transmission 99 }
Trunk MIB Working Group [Page 5]
RFC nnnn DDS MIB April 1996
-- *******************
-- 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 Statistics
-- ***************************
-- the DDS Configuration Table
-- ***************************
ddsConfigTable OBJECT-TYPE
SYNTAX SEQUENCE OF DDSConfigEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"The DDS Configuration table contains the basic
configuration variables for the CSU/DSU."
::= { dds 1 }
ddsConfigEntry OBJECT-TYPE
SYNTAX DDSConfigEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"An entry in the DDS Configuration table."
INDEX { ifIndex }
::= { ddsConfigTable 1 }
DDSConfigEntry ::=
SEQUENCE {
ddsPrimaryChannelSpeed
INTEGER,
ddsAllowSecondaryChannel
TruthValue,
ddsAllowErrorCorrection
TruthValue,
ddsAllowNetworkLoops
TruthValue,
ddsTransmitClockSource
INTEGER,
ddsAllowDteRateAdaption
TruthValue,
ddsDteChannelSpeed
INTEGER,
Trunk MIB Working Group [Page 6]
RFC nnnn DDS MIB April 1996
ddsDteClockSource
INTEGER
}
ddsPrimaryChannelSpeed 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 1 }
ddsAllowSecondaryChannel OBJECT-TYPE
SYNTAX TruthValue
ACCESS read-write
STATUS mandatory
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 }
ddsAllowErrorCorrection OBJECT-TYPE
SYNTAX TruthValue
ACCESS read-write
STATUS mandatory
DESCRIPTION
"This variable represents the error correction
configuration of the DDS DSU/CSU. Although not
a standard component of AT&T TR62310, some vendors
may have elected to implement this feature in their
equipment."
::= { ddsConfigEntry 3 }
Trunk MIB Working Group [Page 7]
RFC nnnn DDS MIB April 1996
ddsAllowNetworkLoops OBJECT-TYPE
SYNTAX TruthValue
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 4 }
ddsTransmitClockSource OBJECT-TYPE
SYNTAX INTEGER {
loopTiming(1),
localTiming(2),
throughTiming(3)
}
ACCESS read-write
STATUS mandatory
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 5 }
ddsAllowDteRateAdaption OBJECT-TYPE
SYNTAX TruthValue
ACCESS read-write
STATUS mandatory
DESCRIPTION
"This variable represents if rate adaption has
been enabled in the DDS DSU/CSU. This means that
the DTE interface is running at a different speed
than that of the DDS loop from the carrier. The
DSU/CSU must then have a speed configured for the
DTE interface which is different from that of the
network interface."
::= { ddsConfigEntry 6 }
ddsDteChannelSpeed OBJECT-TYPE
SYNTAX INTEGER {
bps2400(0),
bps4800(1),
bps9600(2),
Trunk MIB Working Group [Page 8]
RFC nnnn DDS MIB April 1996
bps19200(3),
bps56000(4),
bps64000(5)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"This variable indicates the speed of the DTE
interface when rate adaption has been enabled."
::= { ddsConfigEntry 7 }
ddsDteClockSource OBJECT-TYPE
SYNTAX INTEGER {
internalTiming(1),
InternalExternalTiming(2),
externalTiming(3)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"This variable indicates the configuration of the
DTE clocks. The clocks can either come from the
internal source (internal), or else they can come
from the DTE itself (external), or the DTE can get
transmit clock from the DTE and give the DTE receive
clock (internal/external)."
::= { ddsConfigEntry 8 }
-- *************************
-- the DDS Diagnostics Table
-- *************************
ddsDiagTable OBJECT-TYPE
SYNTAX SEQUENCE OF DDSDiagEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"The DDS diagnostic table contains the diagnostic element
variables for the CSU/DSU."
::= { dds 2 }
ddsDiagEntry OBJECT-TYPE
SYNTAX DDSDiagEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"An entry in the DDS diagnostic table."
INDEX { ifIndex }
::= { ddsDiagTable 1 }
Trunk MIB Working Group [Page 9]
RFC nnnn DDS MIB April 1996
DDSDiagEntry ::=
SEQUENCE {
ddsLoopbackConfig
INTEGER,
ddsSendRemoteLoopCode
TruthValue,
ddsDSULoop
INTEGER,
ddsLoopStatus
INTEGER,
ddsSendTestCode
INTEGER,
ddsInsertTestError
TruthValue,
ddsResetTestErrors
TruthValue,
ddsLocalTestErrorSeconds
Counter,
ddsRemoteTestErrorSeconds
Counter,
ddsSecondsInTest
Counter
}
ddsLoopbackConfig OBJECT-TYPE
SYNTAX INTEGER {
ddsNoLoop(1),
ddsCsuLoop(2),
ddsLocalLoop(3)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The loopback configuration for the CSU section
of the DSU/CSU. The various configurations are
as follows.
ddsNoLoop: No loopback is activated.
ddsCsuLoop: Engage the channel loopback
which means that the DDS line should
be looped back toward the network.
ddsLocalLoop: Engage the local loopback of the
DSU/CSU which means that the network
interface should be looped back toward
itself. This is useful for self-diagnostic
purposes and is not a mode which can be
engaged by the TELCO."
::= { ddsDiagEntry 1 }
Trunk MIB Working Group [Page 10]
RFC nnnn DDS MIB April 1996
ddsSendRemoteLoopCode OBJECT-TYPE
SYNTAX TruthValue
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Issue a remote DSU loop to the far end CSU/DSU."
::= { ddsDiagEntry 2 }
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 3 }
ddsLoopStatus OBJECT-TYPE
SYNTAX INTEGER {
ddsNoLoopActive(1),
ddsCsuLoopActive(2),
ddsDsuLoopActive(3),
ddsOtherLoopActive(4)
}
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This object returns the status of the loopback
condition of the DSU/CSU. The following is a
description of the various looback statuses.
ddsNoLoopActive: There is no loopback in progress.
ddsCsuLoopActive: The channel loopback is engaged
which means that the DDS line is
looped back toward the network.
ddsDsuLoopActive: The DSU section of the DSU/CSU is
looped at the R interface. This
loopback may be bidirectional but
must at the very least be a uni-
directional loop back toward the
network at the R interface.
ddsOtherLoopActive: This code is reserved for any other
type of loopback that is implemented
by the manufacturer."
Trunk MIB Working Group [Page 11]
RFC nnnn DDS MIB April 1996
::= { ddsDiagEntry 4 }
ddsSendTestCode OBJECT-TYPE
SYNTAX INTEGER {
off(1),
sendBERT2047(2),
sendAllZeroes(3)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Activate the bit error-rate tester on the CSU/DSU."
::= { ddsDiagEntry 5 }
ddsInsertTestError OBJECT-TYPE
SYNTAX TruthValue
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Inserts a single bit error in the NI data stream.
This object will only ever read FALSE."
::= { ddsDiagEntry 6 }
ddsResetTestErrors OBJECT-TYPE
SYNTAX TruthValue
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Reset the test error-second counters. This object
only ever reads as FALSE."
::= { ddsDiagEntry 7 }
ddsLocalTestErrorSeconds OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Local errored-seconds counter. This object reflects
the counter which observes the bit-error-rate tester
errors being received on the R interface of the
DSU/CSU."
::= { ddsDiagEntry 8 }
ddsRemoteTestErrorSeconds OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Remote errored-seconds counter. This object reflects
Trunk MIB Working Group [Page 12]
RFC nnnn DDS MIB April 1996
the counter which observes the bit-error-rate tester
errors being received on the network interface of the
DSU/CSU."
::= { ddsDiagEntry 9 }
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 10 }
-- ************************
-- the DDS Statistics Table
-- ************************
ddsStatisticsTable OBJECT-TYPE
SYNTAX SEQUENCE OF DDSStatsEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"The DDS alarm table contains the statistic counters for
the CSU/DSU."
::= { dds 3 }
ddsStatsEntry OBJECT-TYPE
SYNTAX DDSStatsEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"An entry in the DDS statistics table."
INDEX { ifIndex }
::= { ddsStatisticsTable 1 }
DDSStatsEntry ::=
SEQUENCE {
ddsLineStatus
INTEGER,
ddsLOSCount
Counter,
ddsOOSCount
Counter,
ddsCMICount
Counter,
ddsOOFCount
Counter,
ddsFERRCount
Trunk MIB Working Group [Page 13]
RFC nnnn DDS MIB April 1996
Counter,
ddsBPVCount
Counter
}
ddsLineStatus OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This object contains the line status of the network
interface of the DSU/CSU. It contains the alarm status
indications merged together to form a collection of
bits in a single variable. The bit-definitions are as
follows.
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 ddsDSULoop The DSU loopback is active.
1024 ddsOtherLoop Some other loopback is active."
::= { 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
SYNTAX Counter
ACCESS read-only
STATUS mandatory
Trunk MIB Working Group [Page 14]
RFC nnnn DDS MIB April 1996
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. Also, I would like to thank
Fred Baker at Cisco, Dierdre Kostick at AT&T, and James Watt at
Newbridge for their assistance in helping this document become a
standard.
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.
Trunk MIB Working Group [Page 15]
RFC nnnn DDS MIB April 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 document raises no security issues that I am aware of.
8. Author's Address
Mark A. Cotton
Eastern Research, Inc.
Trunk MIB Working Group [Page 16]
RFC nnnn DDS MIB April 1996
225 Executive Drive
Moorestown, New Jersey 08057
Phone: (609)-273-6622
EMail: mcotton@erinc.com
Trunk MIB Working Group [Page 17]
--erinc.com.jvnc.com:828560415:426705256:730267689:-925842148--
