[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/