Network Working Group M. Cotton Internet-Draft Eastern Research Incorporated April 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 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--