Received: from SAFFRON.ACC.COM by NRI.NRI.Reston.VA.US id aa15294;
          13 Jan 92 11:56 EST
Received: from sabre.bellcore.com by saffron.acc.com (4.1/SMI-4.1)
	id AA00309; Mon, 13 Jan 92 08:45:05 PST
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA05764; Mon, 13 Jan 92 11:46:05 EST
Return-Path: <tacox@sabre.bellcore.com>
Received: by ginsu4 (4.1/4.7)
	id AA01587; Mon, 13 Jan 92 11:39:30 EST
Date: Mon, 13 Jan 92 11:39:30 EST
From: Tracy Cox <tacox@sabre.bellcore.com>
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9201131639.AA01587@ginsu4>
To: trunk-mib@saffron.acc.com
Subject: Far-End tables in the DS3 MIB
Status: O

Gang,

Last year I sent out mail to some people asking
what they thought about keeping far-end information
for the DS3 Interface.

I mostly got negative responses --  We don't need
far-end tables for DS3.

I am asking the question again to the full mailing list.

The far-end tables for DS3 would be used
for C-bit Parity and SYNTRAN applications to
keep the returned far-end statistics from the C-bits.
These statistics would be for ESs, SESs, and CVs only.
There would be three tables: interval, current, and total,
appended to the end of the mib.  These tables would
be optional.
It was suggested that we have these optional table for the 
DS1 MIB to keep the returned ANSI ESF Performance Report Messages:
LESs, ESs, SESs, CVs, CSSs, and SEFSs.  This is consistent with
ANSI T1.403.

Are these tables needed for DS3?

Tracy
===========================================
Tracy A. Cox
Bellcore
NVC 1C-354
331 Newman Springs Rd.
Red Bank, NJ  07701
tacox@sabre.bellcore.com email
(908) 758-2107 vmail
(908) 758-4177 fax
===========================================










Received: from SAFFRON.ACC.COM by NRI.NRI.Reston.VA.US id aa15784;
          13 Jan 92 12:10 EST
Received: from watson.ibm.com by saffron.acc.com (4.1/SMI-4.1)
	id AA00314; Mon, 13 Jan 92 09:02:36 PST
Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 5469;
   Mon, 13 Jan 92 12:02:17 EST
Received: from YKTVMH by watson.vnet.ibm.com with "VAGENT.V1.0"
          id 8466; Mon, 13 Jan 1992 12:02:19 EST
Received: from cyst.watson.ibm.com by yktvmh.watson.ibm.com (IBM VM SMTP V2R2)
   with TCP; Mon, 13 Jan 92 12:02:17 EST
Received: from patience.watson.ibm.com by cyst.watson.ibm.com (AIX 1.3/900528)
  id AA39865; Mon, 13 Jan 92 12:02:16 -0500
Received: by patience.watson.ibm.com (AIX 1.3/900524)
          id AA11927; Mon, 13 Jan 92 12:00:57 -0500
Message-Id: <9201131700.AA11927@patience.watson.ibm.com>
To: Tracy Cox <tacox@sabre.bellcore.com>
Cc: trunk-mib@saffron.acc.com
X-External-Networks: yes
Subject: Re: Far-End tables in the DS3 MIB
In-Reply-To: Your message of Mon, 13 Jan 92 11:39:30 EST.
             <9201131639.AA01587@ginsu4>
Date: Mon, 13 Jan 92 12:00:56 -0500
From: Ed Pring <pring@watson.ibm.com>
Status: O

I don't think that far-end statistics are necessary, but I do
think that transmitted and recieved PathID strings should be
included in the DS3 MIB, and that the variables containing
transmitted PathID strings should be read/write.

- Ed










Received: from SAFFRON.ACC.COM by NRI.NRI.Reston.VA.US id aa19197;
          13 Jan 92 14:51 EST
Received: from thumper.bellcore.com by saffron.acc.com (4.1/SMI-4.1)
	id AA00432; Mon, 13 Jan 92 11:42:10 PST
Received: from jeff.bellcore.com by thumper.bellcore.com (4.1/4.7)
	id <AA22715> for trunk-mib@saffron.acc.com; Mon, 13 Jan 92 14:41:59 EST
Received: from localhost.bellcore.com by jeff.bellcore.com (4.1/4.7)
	id <AA04367> for trunk-mib@saffron.acc.com; Mon, 13 Jan 92 14:41:58 EST
Message-Id: <9201131941.AA04367@jeff.bellcore.com>
To: Tracy Cox <tacox@sabre.bellcore.com>
Cc: trunk-mib@saffron.acc.com
Subject: Re: Far-End tables in the DS3 MIB 
In-Reply-To: Your message of Mon, 13 Jan 92 11:39:30 -0500.
             <9201131639.AA01587@ginsu4> 
Date: Mon, 13 Jan 92 14:41:57 -0500
From: tob@jeff.bellcore.com
Status: O


Tracy-

....Here I put on my hat as a SMDS DS3 agent writer,
and give a knee jerk reaction :^)

	No I don't think we need them.  In fact
there's stuff in there that few people read as it
is...like the intervals tables.

.....Now I take off my SMDS DS3 agent writer hat,
and try to be a little more balanced.

	I don't think I've seen a convincingly important application,
that requires them.  But then I haven't looked very hard either.


Ted Brunner			Bellcore 
tob@thumper.bellcore.com	MRE 2P-252 
201/829-4678			445 South St.
				Morristown NJ 07960-1910 











Received: from SAFFRON.ACC.COM by NRI.NRI.Reston.VA.US id aa21519;
          13 Jan 92 16:24 EST
Received: from sabre.bellcore.com by saffron.acc.com (4.1/SMI-4.1)
	id AA02479; Mon, 13 Jan 92 13:18:28 PST
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA07335; Mon, 13 Jan 92 16:19:20 EST
Return-Path: <tacox@sabre.bellcore.com>
Received: by ginsu4 (4.1/4.7)
	id AA01756; Mon, 13 Jan 92 16:12:47 EST
Date: Mon, 13 Jan 92 16:12:47 EST
From: Tracy Cox <tacox@sabre.bellcore.com>
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9201132112.AA01756@ginsu4>
To: trunk-mib@saffron.acc.com
Subject: re - PathID
Status: O


Ed,

In response to your message:


I don't think that far-end statistics are necessary, but I do
think that transmitted and recieved PathID strings should be
included in the DS3 MIB, and that the variables containing
transmitted PathID strings should be read/write.

- Ed

Are you talking about the PathID strings contained within the LAPD
frame in the Data Link of C-Bit Parity?
If you do -- I can understand you wanting to read it, but write it also?
This information contains location information and should not be
SNMP settable.  See the Simple Book -- "do you expect the equipment
to get up and change locations?"
I don't think this information is configurable within the means
of SNMP.

Tracy










Received: from SAFFRON.ACC.COM by NRI.NRI.Reston.VA.US id aa10652;
          14 Jan 92 13:17 EST
Received: from sabre.bellcore.com by saffron.acc.com (4.1/SMI-4.1)
	id AA07011; Tue, 14 Jan 92 08:49:24 PST
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA12143; Tue, 14 Jan 92 11:50:09 EST
Return-Path: <tacox@sabre.bellcore.com>
Received: by ginsu4 (4.1/4.7)
	id AA01881; Tue, 14 Jan 92 11:43:33 EST
Date: Tue, 14 Jan 92 11:43:33 EST
From: Tracy Cox <tacox@sabre.bellcore.com>
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9201141643.AA01881@ginsu4>
To: trunk-mib@saffron.acc.com
Subject: draft of DS3 MIB
Status: O

Gang,

This is only a draft of the updated DS3
MIB.  PLease look it over.  This is only
to stir discussion -- if you have problems
with this please speak up.

Please read section 3.2 -- Changes from Version 1.0.
to see the updates.

Thanks,

Tracy







Network Working Group                                            T. Cox
Request for Comments: 1233                                    K. Tesink
Updated Version 2.0                        Bell Communications Research
                                                                Editors
                                                             March 1992


                     Definitions of Managed Objects
                       for the DS3 Interface Type
                                Version 2.0


Status of this Memo

   This memo defines objects for managing DS3 Interface objects for use
   with the SNMP protocol.  This memo is a product of the SNMP and
   Transmission MIB Working Group of the Internet Engineering Task Force
   (IETF).  This RFC specifies an IAB standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "IAB
   Official Protocol Standards" for the standardization state and status
   of this protocol.  Distribution of this memo is unlimited.

Table of Contents

   1. Abstract ..............................................    1
   2. The Network Management Framework.......................    2
   3. Objects ...............................................    2
   3.1 Format of Definitions ................................    3
   3.2 Changes from Version 1.0 .............................    3
   4. Overview ..............................................    4
   4.1 Binding between Interfaces and CSUs ..................    4
   4.2 Objectives of this MIB Module ........................    4
   4.3 DS3 Terminology ......................................    4
   5. Object Definitions ....................................    7
   5.1 The DS3 Configuration Group ..........................    7
   5.2 The DS3 Interval Group ...............................   14
   5.3 The DS3 Current Group ................................   17
   5.4 The DS3 Total Group ..................................   21
   6. Acknowledgments .......................................   24
   7. References ............................................   25
   8. Security Considerations................................   26
   9. Authors' Addresses.....................................   26

1.  Abstract

   This memo defines an experimental portion of the Management
   Information Base (MIB) for use with network management protocols in
   TCP/IP-based internets.  In particular, this memo defines MIB objects
   for representing DS3 physical interfaces.  Implementors should
   consult in addition to this memo the companion document that



SNMP & Transmission MIB Working Groups                          [Page 1]

RFC 1233                 DS3 Interface Objects                  March 1992


   describes that DS1 managed objects.

2.  The Network Management Framework

   The Internet-standard Network Management Framework consists of three
   components.  They are:

      RFC 1155 which defines the SMI, the mechanisms used for describing
      and naming objects for the purpose of management.  RFC 1212
      defines a more concise description mechanism, which is wholly
      consistent with the SMI.

      RFC 1156 which defines MIB-I, the core set of managed objects for
      the Internet suite of protocols.  RFC 1213, defines MIB-II, an
      evolution of MIB-I based on implementation experience and new
      operational requirements.

      RFC 1157 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.

3.  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) [7]
   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 [3] 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 [8], subject
   to the additional requirements imposed by the SNMP.



SNMP & Transmission MIB Working Groups                          [Page 2]

RFC 1233                 DS3 Interface Objects                  March 1992


3.1.  Format of Definitions

   Section 5 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 RFC 1212 [13].

3.2.  Changes from Version 1.0

   In order to better prepare implementors for future changes in the
   DS3 MIB, a new term "deprecated" may be used when describing an object.
   A deprecated object in the MIB is one which must be supported, but
   one which will most likely be removed from the next version of the
   DS3 MIB . -- THIS IS REALLY NOT WHAT I WANT! I WOULD LIKE TO DELETE
   THESE OBJECTS IN THIS VERSION?
   HOW DO I DO THAT -- OR CAN I?

   I would like to delete the loopback object, the yellow alarm object,
   and the red alarm object and replace the three of them with two
   different objects:  ds3NewLoopback and ds3AlarmState.
   This change is facilitated by comments on implementations.

   Also, the ds3SendCode is confusing -- the ds3SendLoopbackCode really
   does not do anything -- what is it supposed to do?

   I also added ds3IntervalOtherCVs (Current and Total also) to handle
   C-Bit Parity and SYNTRAN coding violations.
   This change is to be consistent with T1M1 standards.

   I changed the bindings between interfaces and CSUs -- PLEASE READ THAT
   SECTION.  This change is facilitated by comments on implementations.


SNMP & Transmission MIB Working Groups                          [Page 3]

RFC 1233                 DS3 Interface Objects                  March 1992
   

.  Overview

   These objects are used when the particular media being used to
   realize an interface is a DS3 interface.  At present, this applies to
   these values of the ifType variable in the Internet-standard MIB:

               ds3 (30)

   The definitions contained herein are based on the DS3 specifications
   in ANSI T1.102-1987, ANSI T1.107-1988,, ANSI T1-107a-1990, and ANSI T1.404-1989
   [9,10,10a,11].

4.1.  Binding between Interfaces and CSUs

   Each agent which resides on a host which uses DS3 interfaces is
   required to assign a small, positive integer uniquely to each interface
   located on the CSU.
   This is known as the "CSUIndex", and is used to distinguish between
   different interfaces on the
   CSUs attached to a node.  The CSUIndex is also used as the
   "key" when accessing tabular information about DS3 interfaces.
   Each CSU should be given a range of numbers in order to distinguish
   the CSUs (e.g., first CSU given 1-10, second CSU given 11-20, ...). 

   The ds3Index column of the DS3 Configuration table relates each interface
   on the CSU to the interfaces table
   in the Internet-standard MIB.

4.2.  Objectives of this MIB Module

   There are numerous things that could be included in a MIB for DS3
   signals: the management of multiplexors, CSUs, DSUs, and the like.
   The intent of this document is to facilitate the common management of
   DS3 interfaces of CSUs, both in-chassis and external via proxy.
   As such, a design
   decision was made up front to very closely align the MIB with the set
   of objects that can generally be read from CSUs that are currently
   deployed.

4.3.  DS3 Terminology

   The terminology used in this document to describe error conditions on
   a DS3 circuit as monitored by a DS3 CSU are from the ANSI T1M1.3/91-003R3
   draft standard [12].




SNMP & Transmission MIB Working Groups                          [Page 4]

RFC 1233                 DS3 Interface Objects                  March 1992


          Coding Violation (CV)
               For all DS3 applications, a coding violation is a P-bit
               Parity Error event.  A P-bit Parity Error event is the
               occurrence of a received P-bit code on the DS3 M-frame
               that is not identical to the corresponding locally-
               calculated code.  For C-Bit Parity applications, it is
               also the occurrence of a received CP-Bit parity
               violation.  For SYNTRAN applications, it is also the
               occurrence of a received CRC-9 code that is not identical
               to the corresponding locally calculated code.
               Two coding violation counters are used.  The first one
               is used by all DS3 applications
               for just the P-bit Parity Error Event.  The second CV
               counter counts the CP-Bit Parity violations for C-Bit
               Parity applications or the CRC-9 code violations for
               SYNTRAN applications.

          Bipolar Violation (BPV)
               A bipolar violation, for B3ZS-coded signals, is the
               occurrence of a received bipolar violation that is not
               part of a zero-substitution code.  For B3ZS-coded
               signals, a bipolar violation may also include other error
               patterns such as:  three or more consecutive zeros and
               incorrect polarity.

          Errored Seconds (ES)
               An ES is a second with one or more Coding Violation OR
               one or more Out of Frame events OR a detected incoming AIS.

          Severely Errored Seconds (SES)
               A SES is a second with 44 or more Coding Violations OR
               one or more Out of Frame events OR a detected incoming AIS.

          Severely Errored Framing Seconds (SEFS)
               A SEFS is a second with one or more Out of Frame events.

          Unavailable Seconds (UAS)
               UAS are calculated by counting the number of seconds that
               the CSU is in the Unavailable signal state (i.e.,
               declared a Red Alarm or a Yellow Alarm), including the
               initial 10 seconds to enter the state but not including
               the 10 seconds to exit the state.

               Note that any second that may be counted as an UAS may
               not be counted as an ES or a SES.  Since the 10 SESs that
               comprise the transition from the available to unavailable
               signal state may also be counted as ESs and SESs previous
               to entering the state, these three counters are adjusted
               so that any second counted during this transition is then
               subtracted.  The 10 seconds in the transition from
               unavailable to available may be counted as ESs.



SNMP & Transmission MIB Working Groups                          [Page 5]

RFC 1233                 DS3 Interface Objects                  March 1992


               
               A special case exists when the 10 or more second period
               crosses the 900 second statistics window boundary, as the
               foregoing description implies that the SES and UAS
               counters must be adjusted when the Unavailable Signal
               State is entered. Clearly, successive GETs of the
               affected ds3IntervalSES and ds3IntervalUAS objects will
               return differing values if the first GET occurs during
               the first few seconds of the window.  This is viewed as
               an unavoidable side-effect of selecting the presently
               defined managed objects as a basis for this memo.

          Alarm States:
               The Far End Alarm (or Yellow Alarm) is declared after detecting
               the Yellow Signal.  See ANSI T1.107a-1990 [10].
               The incoming alarms consist of the following
               incoming signal degradations:  Loss of
               Signal (LOS), a Loss of Frame (LOF)  (a persistent Out
               of Frame event), or an
               Alarm Indication Signal (AIS), for at least 2-10
               seconds.  The Alarms are cleared at the onset of 10
               consecutive seconds with no SES.  See T1M1.3/91-0003R3 [12].

          Out of Frame (OOF) event
               An OOF event is detected when any three or more errors in
               sixteen or fewer consecutive F-bits occur within a DS3
               M-frame.  An OOF event is cleared when reframe occurs.
               A Loss of Frame (LOF) event is declared when the OOF event
               is consistent for 2 to 3 seconds.  The OOF event ends when
               reframe occurs.

          Loss of Signal (LOS)
               This failure is declared upon observing 175 +/- 75
               contiguous pulse positions with no pulses of either
               positive or negative polarity.
               The LOS is terminated upon observing an average pulse density
               of at least 33% over a period of 175 +/- 75 contiguous pulse
               positions starting with the receipt of a pulse.

	  Alarm Indication Signal (AIS)
               The AIS is framed with "stuck stuffing."  This implies
               that it has a valid M-subframe alignments bits, M-frame
               alignment bits, and P bits.  The information bits are set
               to a 1010... sequence, starting with a one (1) after each
               M-subframe alignment bit, M-frame alignment bit, X bit, P bit,
               and C bit.  The C bits are all set to zero giving what is called
               "stuck stuffing."  The X bits are set to one.
               The AIS is declared after AIS is present in contiguous M-frames
               for a time equal to or greater than T, where
               0.2 ms <= T <= 100 ms.
               The AIS is terminated after AIS is absent in contiguous M-frames
               for a time equal to or greater than T.

          Circuit Identifier
               This is a character string specified by the circuit
               vendor, and is useful when communicating with the vendor
               during the troubleshooting process.


SNMP & Transmission MIB Working Groups                          [Page 6]


RFC 1233                 DS3 Interface Objects                  March 1992


5.  Object Definitions

               RFC1233-MIB DEFINITIONS ::= BEGIN

               IMPORTS
                       mgmt, experimental, Counter
                               FROM RFC1155-SMI
                       DisplayString
                               FROM RFC1158-MIB
                       OBJECT-TYPE
                               FROM RFC-1212;

               --  This MIB module uses the extended OBJECT-TYPE macro
               --  as defined in RFC 1212.

               --  this is the MIB module for the DS3 objects

               mib-2 OBJECT IDENTIFIER ::= { mgmt 1 }
               transmission OBJECT IDENTIFIER ::= { mib-2 10 }
               ds3 OBJECT IDENTIFIER ::= { transmission 30 }

               -- the DS3 Configuration group

               -- Although the objects in this group are read-only, at
               -- the agent's discretion they may be made read-write
               -- so that the management station, when appropriately
               -- authorized, may change the behavior of the CSU,
               -- e.g., to place the device into a loopback state.

               -- Implementation of this group is mandatory for all
               -- systems that attach to a DS3 Interface.

               ds3ConfigTable OBJECT-TYPE
                   SYNTAX  SEQUENCE OF DS3ConfigEntry
                   ACCESS  not-accessible
                   STATUS  mandatory
                   DESCRIPTION
                           "The DS3 Configuration table."
                  ::= { ds3 1 }

              ds3ConfigEntry OBJECT-TYPE
                  SYNTAX  DS3ConfigEntry
                  ACCESS  not-accessible
                  STATUS  mandatory
                  DESCRIPTION
                          "An entry in the DS3 Configuration table."
                 INDEX   { ds3CSUIndex }
                 ::= { ds3ConfigTable 1 }

             DS3ConfigEntry ::=
                 SEQUENCE {
                     ds3CSUIndex
                         INTEGER,
                     ds3Index
                         INTEGER,
                     ds3TimeElapsed
                         INTEGER (1..900),

SNMP & Transmission MIB Working Groups                          [Page 6]

RFC 1233                 DS3 Interface Objects                  March 1992

                     ds3ValidIntervals
                         INTEGER (0..96),
                     ds3LineType
                         INTEGER,
                     ds3ZeroCoding
                         INTEGER,
                     ds3Loopback
                         INTEGER,
                     ds3SendCode
                         INTEGER,
                     ds3YellowAlarm
                         INTEGER,
                     ds3RedAlarm
                         INTEGER,
                     ds3CircuitIdentifier
                         DisplayString (SIZE (0..255)),
                     ds3NewLoopback
                         INTEGER,
                     ds3AlarmState
                         INTEGER
             }

             ds3CSUIndex OBJECT-TYPE
                 SYNTAX  INTEGER
                 ACCESS  read-only
                 STATUS  mandatory
                 DESCRIPTION
                         "The index value which uniquely identifies the
                         CSU and its interface to which this entry
                         is applicable."
                ::= { ds3ConfigEntry 1 }

            ds3Index OBJECT-TYPE
                SYNTAX  INTEGER
                ACCESS  read-only
                STATUS  mandatory
                DESCRIPTION
                        "An index value that uniquely identifies a DS3
                        Interface.  The interface identified by a
                        particular value of this index is the same
                        interface as identified by the same value an
                        ifIndex object instance."
               ::= { ds3ConfigEntry 2 }

           ds3TimeElapsed OBJECT-TYPE
               SYNTAX  INTEGER (1..900)
               ACCESS  read-only
               STATUS  mandatory
               DESCRIPTION
                       "The number of seconds, including partial
                       seconds, that have elapsed since the beginning of
                       the current error-measurement period."
              ::= { ds3ConfigEntry 3 }


SNMP & Transmission MIB Working Groups                          [Page 8]

RFC 1233                 DS3 Interface Objects                  March 1992


          ds3ValidIntervals OBJECT-TYPE
              SYNTAX  INTEGER (0..96)
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The number of previous intervals for which valid
                      data was collected.  The value will be 96 unless
                      the CSU device was brought online within the last
                      24 hours, in which case the value will be the
                      number of complete 15 minute intervals the CSU has
                      been online."
              ::= { ds3ConfigEntry 4 }

          ds3LineType OBJECT-TYPE
              SYNTAX  INTEGER {
                          other(1),
                          ds3M23(2),
                          ds3SYNTRAN(3),
                          ds3CbitParity(4),
                          ds3ClearChannel(5)
                      }
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "This variable indicates the variety of DS3 C-bit
                      application implementing this circuit.  The type
                      of circuit affects the interpretation of the usage
                      and error statistics.  The rate of all of them is
                      44.736 Mbps.

                      The values, in sequence, describe:
                      TITLE:            SPECIFICATION:
                      ds3M23            ANSI T1.107-1988
                      ds3SYNTRAN        ANSI T1.107-1988
                      ds3C-bitParity    ANSI T1.107a-1990
                      ds3ClearChannel   ANSI T1.102-1987
                      "
              ::= { ds3ConfigEntry 5 }

          ds3ZeroCoding OBJECT-TYPE
              SYNTAX  INTEGER {
                          ds3other(1),
                          ds3B3ZS(2)
                      }
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "This variable describes the variety of Zero Code
                      Suppression used on the link, which in turn
                      affects a number of its characteristics.
                      ds3B3ZS refers to the use of specified patterns of
                      normal bits and bipolar violations which are used
                      to replace sequences of zero bits of a specified
                      length."
              ::= { ds3ConfigEntry 6 }


SNMP & Transmission MIB Working Groups                          [Page 9]

RFC 1233                 DS3 Interface Objects                  March 1992


          ds3Loopback OBJECT-TYPE
              SYNTAX  INTEGER {
                          ds3NoLoop(1),
                          ds3LocalLoopbackLocalSide(2),
                          ds3LocalLoopbackRemoteSide(3),
                          ds3RemoteLoopbackLocalSide(4),
                          ds3RemoteLoopbackRemoteSide(5)
                      }
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "This variable represents the loopback state of
                      the CSU.  Devices supporting read/write access
                      should return badValue in response to a requested
                      loopback state that the CSU does not support.  The
                      values mean:

                        ds3NoLoop
                           Not in the loopback state.  A device that is
                           not capable of performing a loopback on
                           either interface shall always return this as
                           it's value.

                        ds3LocalLoopbackLocalSide
                           Signal received from the local side of the
                           device is looped back at the local connector
                           (eg, without involving the CSU).

                        ds3LocalLoopbackRemoteSide
                           Signal received from the local side of the
                           device is looped back at the remote connector
                           (eg, through the CSU).

                        ds3RemoteLoopbackLocalSide
                           Signal received from the remote side of the
                           device is looped back at the local connector
                           (eg, through the CSU).

                        ds3RemoteLoopbackRemoteSide
                           Signal received from the remote side of the
                           device is looped back at the remote connector
                           (eg, without involving the CSU).

                      Note that M23 and ClearChannel interfaces do not
                      support the Loopback managed object."
              ::= { ds3ConfigEntry 7 }





SNMP & Transmission MIB Working Groups                          [Page 10]

RFC 1233                 DS3 Interface Objects                  March 1992


          ds3SendCode OBJECT-TYPE
              SYNTAX  INTEGER {
                          ds3SendTestMessage(1),
                          ds3SendNoCode(2),
                          ds3SendSetCode(3),
                          ds3SendLoopbackCode(4),
                          ds3SendResetCode(5)
                      }
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "This variable indicates what type of code is
                      being sent across the DS3 circuit by the CSU.  The
                      values mean:

                        ds3SendNoCode
                           sending looped or normal data

                        ds3SendSetCode
                           sending a loopback request

                        ds3SendLoopbackCode
                           sending the code to choose a specific
                           loopback -- THIS IS MEANINGLESS -- HOW DO YOU
                           CHOOSE A SPECIFIC LOOPBACK TO ACTIVATE?
                           FOR EXAMPLE ANSI T1.107a SPECIFIES ABOUT 31
                           DIFFERENT LOOPBACKS TO ACTIVATE.

                        ds3SendResetCode
                           sending a loopback termination request

                        ds3SendTestMessage
                           sending a Test pattern as defined in
                           T1.107a-1990.
                      "
              ::= { ds3ConfigEntry 8 }

          ds3YellowAlarm OBJECT-TYPE
              SYNTAX  INTEGER {
                          ds3YellowAlarm(1),
                          ds3NoYellowAlarm(2)
                       }
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                     "This variable indicates if a Yellow
                     Alarm condition exists."
              ::= { ds3ConfigEntry 9 }

          ds3RedAlarm OBJECT-TYPE
              SYNTAX  INTEGER {
                          ds3RedAlarm(1),
                          ds3NoRedAlarm(2)
                      }
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "This variable indicates if a Red Alarm
                      condition exists."
              ::= { ds3ConfigEntry 10 }


SNMP & Transmission MIB Working Groups                         [Page 11]

RFC 1233                 DS3 Interface Objects                  March 1992


          ds3CircuitIdentifier OBJECT-TYPE
              SYNTAX  DisplayString (SIZE (0..255))
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "This variable contains the transmission
                      vendor's circuit identifier, for the
                      purpose of facilitating troubleshooting."
              ::= { ds3ConfigEntry 11 }

          ds3NewLoopback OBJECT-TYPE
              SYNTAX  INTEGER {
                          ds3NoLoop(1),
                          ds3LoopThroughDevice(2),
                          ds3OutOfDevice(3),
                          ds3OtherLoop(4)
                      }
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "This variable represents the loopback state of
                      the DS3 interface.  Devices supporting read/write
                      access should return badValue in response to a
                      requested loopback state that the device does not support.
                      The values mean:

                            ds3NoLoop

                              Not in the loopback state.  A device that is
                              not capable of performing a loopback on
                              either interface shall always return this as
                              it's value.

                            ds3LoopThroughDevice

                              The loopback at one interface is looped through
                              the device.

                            ds3OutOfDevice
                               
                              The loopback at one interface does not go through
                              the device but is looped back out.

                            ds3OtherLoop
         
                              Loopbacks that are not defined here.

                      Note that M23 and ClearChannel interfaces do not
                      support the Loopback managed object."
              ::= { ds3ConfigEntry 12 }



SNMP & Transmission MIB Working Groups                         [Page 12]

RFC 1233                 DS3 Interface Objects                  March 1992


          ds3AlarmState OBJECT-TYPE
              SYNTAX  INTEGER {
                          ds3NoAlarm(1),
                          ds3YellowAlarm(2),
                          ds3AlarmIndicationSignal(3),
		          ds3OutOfFrame(4),
                          ds3LossOfSignal(5)
                      }
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                    "This variable indicates the
                    Alarm State of the interface.
                    If multiple alarms are occurring
                    simultaneously, then the highest
                    priority alarm is the one set.  From
                    highest to lowest the alarm priorities are
                    the following:  ds3LossOfSignal, ds3OutOfFrame,
                    ds3AlarmIndicationSignal, and ds3YellowAlarm."
              ::= { ds3ConfigEntry 13 }















SNMP & Transmission MIB Working Groups                         [Page 13]

RFC 1233                 DS3 Interface Objects                  March 1992


          -- the DS3 Interval group

          -- Implementation of this group is mandatory for all
          -- systems that attach to a DS3 interface.

          -- The DS3 Interval Table contains various statistics
          -- collected by each CSU over the previous 24 hours of
          -- operation.  The past 24 hours are broken into 96
          -- completed 15 minute intervals.

          ds3IntervalTable OBJECT-TYPE
              SYNTAX  SEQUENCE OF DS3IntervalEntry
              ACCESS  not-accessible
              STATUS  mandatory
              DESCRIPTION
                     "The DS3 Interval table."
              ::= { ds3 2 }

          ds3IntervalEntry OBJECT-TYPE
              SYNTAX  DS3IntervalEntry
              ACCESS  not-accessible
              STATUS  mandatory
              DESCRIPTION
                    "An entry in the DS3 Interval table."
              INDEX   { ds3IntervalIndex, ds3IntervalNumber }
              ::= { ds3IntervalTable 1 }

          DS3IntervalEntry ::=
              SEQUENCE {
                   ds3IntervalIndex
                        INTEGER,
                   ds3IntervalNumber
                        INTEGER (1..96),
                   ds3IntervalESs
                        Counter,
                   ds3IntervalSESs
                        Counter,
                   ds3IntervalSEFSs
                        Counter,
                   ds3IntervalUASs
                        Counter,
                   ds3IntervalCSSs
                        Counter,
                   ds3IntervalBPVs
                        Counter,
                   ds3IntervalCVs
                        Counter,
                   ds3IntervalOtherCVs
                        Counter
              }



SNMP & Transmission MIB Working Groups                         [Page 14]

RFC 1233                 DS3 Interface Objects                  March 1992


          ds3IntervalIndex OBJECT-TYPE
              SYNTAX  INTEGER
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The index value which uniquely identifies the
                      CSU and this interface
                      to which this entry is applicable.  The
                      interface identified by a particular value of
                      this index is the same interface as identified
                      by the same value an DS3CSUIndex object
                      instance."
              ::= { ds3IntervalEntry 1 }

         ds3IntervalNumber OBJECT-TYPE
             SYNTAX  INTEGER (1..96)
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                    "A number between 1 and 96, where 1 is the most
                    recently completed 15 minute interval and 96 is
                    the least recently completed 15 minutes
                    interval (assuming that all 96 intervals are
                    valid)."
             ::= { ds3IntervalEntry 2 }

         ds3IntervalESs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                     "The counter associated with the number of
                     Errored Seconds, as defined by T1M1.3/91, encountered
                     by a DS3 CSU in one of the previous 96,
                     individual 15 minute, intervals."
            ::= { ds3IntervalEntry 3 }

         ds3IntervalSESs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                     "The counter associated with the number of
                     Severely Errored Seconds, as defined by T1M1.3/91,
                     encountered by a DS3 CSU in one of the previous
                     96, individual 15 minute, intervals."
            ::= { ds3IntervalEntry 4 }


SNMP & Transmission MIB Working Groups                         [Page 15]

RFC 1233                 DS3 Interface Objects                  March 1992


          ds3IntervalSEFSs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                     "The counter associated with the number of
                     Severely Errored Framing Seconds, as defined by
                     T1M1.3/91, encountered by a DS3 CSU in one of the
                     previous 96, individual 15 minute, intervals."
             ::= { ds3IntervalEntry 5 }

         ds3IntervalUASs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                     "The counter associated with the number of
                     Unavailable Seconds, as defined by T1M1.3/91,
                     encountered by a DS3 CSU in one of the previous
                     96, individual 15 minute, intervals."
             ::= { ds3IntervalEntry 6 }

         ds3IntervalCSSs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  deprecated
             DESCRIPTION
                     "The counter associated with the number of
                     Controlled Slip Seconds, as defined by T1M1.3/91,
                     encountered by a DS3 CSU in one of the previous
                     96, individual 15 minute, intervals.
                     Note that SYNTRAN interfaces are the only
                     interfaces that support the Controlled Slip
                     Seconds managed object.  Accordingly, agents
                     configured with non-SYNTRAN interfaces may treat
                     this object as having an ACCESS clause value of
                     not-accessible."
             ::= { ds3IntervalEntry 7}

         ds3IntervalBPVs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                     "The counter associated with the number of Bipolar
                     Violations, as defined by T1M1.3/91, encountered by a
                     DS3 CSU in one of the previous 96, individual 15
                     minute, intervals."
             ::= { ds3IntervalEntry 8 }



SNMP & Transmission MIB Working Groups                         [Page 16]

RFC 1233                 DS3 Interface Objects                  March 1992


           ds3IntervalCVs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                     "The counter associated with the number of Coding
                     Violations from the P-bits,
                     as defined by T1M1.3/91, encountered by a
                     DS3 CSU in one of the previous 96, individual 15
                     minute, intervals."
             ::= { ds3IntervalEntry 9 }

          ds3IntervalOtherCVs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Coding
                      Violations from the C-bits,
                      as defined by T1M1.3/91, encountered by a
                      DS3 CSU in one of the previous 96, individual 15
                      minute, intervals."
              ::= { ds3IntervalEntry 10 }





























SNMP & Transmission MIB Working Groups                         [Page 17]

RFC 1233                 DS3 Interface Objects                  March 1992


          -- the DS3 Current group

          -- Implementation of this group is mandatory for all systems
          -- that attach to a DS3 Interface.

          -- The DS3 current table contains various statistics being
          -- collected for the current 15 minute interval.

          ds3CurrentTable OBJECT-TYPE
              SYNTAX  SEQUENCE OF DS3CurrentEntry
              ACCESS  not-accessible
              STATUS  mandatory
              DESCRIPTION
                      "The DS3 Current table."
              ::= { ds3 3 }

          ds3CurrentEntry OBJECT-TYPE
              SYNTAX  DS3CurrentEntry
              ACCESS  not-accessible
              STATUS  mandatory
              DESCRIPTION
                      "An entry in the DS3 Current table."
              INDEX   { ds3CurrentIndex }
              ::= { ds3CurrentTable 1 }

          DS3CurrentEntry ::=
              SEQUENCE {
                  ds3CurrentIndex
                      INTEGER,
                  ds3CurrentESs
                      Counter,
                  ds3CurrentSESs
                      Counter,
                  ds3CurrentSEFSs
                      Counter,
                  ds3CurrentUASs
                      Counter,
                  ds3CurrentCSSs
                      Counter,
                  ds3CurrentBPVs
                      Counter,
                  ds3CurrentCVs
                      Counter,
                  ds3CurrentOtherCVs
                      Counter
              }

         

SNMP & Transmission MIB Working Groups                         [Page 18]

RFC 1233                 DS3 Interface Objects                  March 1992


           ds3CurrentIndex OBJECT-TYPE
              SYNTAX  INTEGER
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The index value which uniquely identifies the CSU
                      and this interface
                      to which this entry is applicable.  The interface
                      identified by a particular value of this index is
                      the same interface as identified by the same value
                      an DS3CSUIndex object instance."
              ::= { ds3CurrentEntry 1 }

          ds3CurrentESs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Errored
                      Seconds, as defined by T1M1.3/91, encountered by a DS3
                      CSU in the current 15 minute interval."
              ::= { ds3CurrentEntry 2 }

          ds3CurrentSESs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of
                      Severely Errored Seconds, as defined by T1M1.3/91,
                      encountered by a DS3 CSU in the current 15 minute
                      interval."
              ::= { ds3CurrentEntry 3 }

          ds3CurrentSEFSs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of
                      Severely Errored Framing Seconds, as defined by
                      T1M1.3/91, encountered by a DS3 CSU in the current 15
                      minute interval."
              ::= { ds3CurrentEntry 4 }

          ds3CurrentUASs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of
                      Unavailable Seconds, as defined by T1M1.3/91,
                      encountered by a DS3 CSU in the current 15 minute
                      interval."
              ::= { ds3CurrentEntry 5 }

         

SNMP & Transmission MIB Working Groups                         [Page 19]

RFC 1233                 DS3 Interface Objects                  March 1992


          ds3CurrentCSSs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "The counter associated with the number of
                      Controlled Slip Seconds, as defined by T1M1.3/91,
                      encountered by a DS3 CSU in the current 15 minute
                      interval.
                      Note that SYNTRAN interfaces are the only
                      interfaces that support the Controlled Slip
                      Seconds managed object.  Accordingly, agents
                      configured with non-SYNTRAN interfaces may treat
                      this object as having an ACCESS clause value of
                      not-accessible."
              ::= { ds3CurrentEntry 6 }

          ds3CurrentBPVs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Bipolar
                      Violations, as defined by T1M1.3/91, encountered by a
                      DS3 CSU in the current 15 minute interval."
              ::= { ds3CurrentEntry 7}

          ds3CurrentCVs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Coding
                      Violations from the P-bits,
                      as defined by T1M1.3/91, encountered by a
                      DS3 CSU in the current 15 minute interval."
              ::= { ds3CurrentEntry 8 }
             
          ds3CurrentOtherCVs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Coding
                      Violations from the C-bits,
                      as defined by T1M1.3/91, encountered by a
                      DS3 CSU in the current 15 minute interval."
              ::= { ds3CurrentEntry 9 }





SNMP & Transmission MIB Working Groups                         [Page 20]

RFC 1233                 DS3 Interface Objects                  March 1992


          -- the DS3 Total group

          -- Implementation of this group is mandatory for all systems
          -- that attach to a DS3.

          -- The DS3 Total Table contains the cumulative sum of the
          -- various statistics for the 24 hour interval preceding the
          -- first valid interval in the DS3CurrentTable.

          ds3TotalTable OBJECT-TYPE
              SYNTAX  SEQUENCE OF DS3TotalEntry
              ACCESS  not-accessible
              STATUS  mandatory
              DESCRIPTION
                      "The DS3 Total table.  24 hour interval."
              ::= { ds3 4 }

          ds3TotalEntry OBJECT-TYPE
              SYNTAX  DS3TotalEntry
              ACCESS  not-accessible
              STATUS  mandatory
              DESCRIPTION
                      "An entry in the DS3 Total table."
              INDEX   { ds3TotalIndex }
              ::= { ds3TotalTable 1 }

          DS3TotalEntry ::=
              SEQUENCE {
                  ds3TotalIndex
                      INTEGER,
                  ds3TotalESs
                      Counter,
                  ds3TotalSESs
                      Counter,
                  ds3TotalSEFSs
                      Counter,
                  ds3TotalUASs
                      Counter,
                  ds3TotalCSSs
                      Counter,
                  ds3TotalBPVs
                      Counter,
                  ds3TotalCVs
                      Counter,
                  ds3TotalOtherCVs
                      Counter
              }

          ds3TotalIndex OBJECT-TYPE
              SYNTAX  INTEGER
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                     



SNMP & Transmission MIB Working Groups                         [Page 21]

RFC 1233                 DS3 Interface Objects                  March 1992


                      "The index value which uniquely identifies the CSU
                      and this interface
                      to which this entry is applicable.  The interface
                      identified by a particular value of this index is
                      the same interface as identified by the same value
                      an DS3CSUIndex object instance."
              ::= { ds3TotalEntry 1 }

         ds3TotalESs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                     "The counter associated with the number of Errored
                     Seconds, as defined by T1M1.3/91, encountered by a DS3
                     CSU in the previous 24 hour interval."
             ::= { ds3TotalEntry 2 }

         ds3TotalSESs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                     "The counter associated with the number of
                     Severely Errored Seconds, as defined by T1M1.3/91,
                     encountered by a DS3 CSU in the previous 24 hour
                     interval."
             ::= { ds3TotalEntry 3 }

         ds3TotalSEFSs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                     "The counter associated with the number of
                     Severely Errored Framing Seconds, as defined by
                     T1M1.3/91, encountered by a DS3 CSU in the previous 24
                     hour interval."
             ::= { ds3TotalEntry 4 }

         ds3TotalUASs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                     "The counter associated with the number of
                     Unavailable Seconds, as defined by T1M1.3/91,
                     encountered by a DS3 CSU in the previous 24 hour
                     interval."
             ::= { ds3TotalEntry 5 }

         

SNMP & Transmission MIB Working Groups                         [Page 22]

RFC 1233                 DS3 Interface Objects                  March 1992


         ds3TotalCSSs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  deprecated
             DESCRIPTION
                     "The counter associated with the number of
                     Controlled Slip Seconds, as defined by T1M1.3/91,
                     encountered by a DS3 CSU in the previous 24 hour
                     interval.
                     Note that SYNTRAN interfaces are the only
                     interfaces that support the Controlled Slip
                     Seconds managed object.  Accordingly, agents
                     configured with non-SYNTRAN interfaces may treat
                     this object as having an ACCESS clause value of
                     not-accessible."
             ::= { ds3TotalEntry 6 }

         ds3TotalBPVs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                     "The counter associated with the number of Bipolar
                     Violations, as defined by T1M1.3/91, encountered by a
                     DS3 CSU in the previous 24 hour interval."
             ::= { ds3TotalEntry 7 }

         ds3TotalCVs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                     "The counter associated with the number of Coding
                     Violations from the P-bits,
                     as defined by T1M1.3/91, encountered by a
                     DS3 CSU in the previous 24 hour interval."
             ::= { ds3TotalEntry 8 }
      
         ds3TotalOtherCVs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                     "The counter associated with the number of Coding
                     Violations from the C-bits,
                     as defined by T1M1.3/91, encountered by a
                     DS3 CSU in the previous 24 hour interval."
             ::= { ds3TotalEntry 9 }


         END




SNMP & Transmission MIB Working Groups                         [Page 23]

RFC 1233                 DS3 Interface Objects                  March 1992


6.  Acknowledgments

   This document was produced by the SNMP and the Transmission MIB
   Working Groups:

               Anne Ambler, Spider
               Karl Auerbach, Sun
               Fred Baker, ACC
               Ken Brinkerhoff
               Ron Broersma, NOSC
               Jack Brown, US Army
               Theodore Brunner, Bellcore
               Jeffrey Buffum, HP
               Jeffrey D. Case, UTK
               Chris Chiptasso, Spartacus
               Paul Ciarfella, DEC
               Bob Collet
               Tracy Cox, Bellcore
               James R. Davin, MIT-LCS
               Kurt Dobbins, Cabletron
               Nadya El-Afandi, Network Systems
               Gary Ellis, HP
               Fred Engle
               Mike Erlinger
               Richard Fox, Synoptics
               Karen Frisa, CMU
               Chris Gunner, DEC
               Ken Hibbard, Xylogics
               Ole Jacobsen, Interop
               Ken Jones
               Satish Joshi, Synoptics
               Frank Kastenholz, Racal-Interlan
               Shimshon Kaufman, Spartacus
               Jim Kinder, Fibercom
               Alex Koifman, BBN
               Christopher Kolb, PSI
               Cheryl Krupczak, NCR
               Peter Lin, Vitalink
               John Lunny, TWG
               Carl Malamud
               Keith McCloghrie, HLS
               Donna McMaster, David Systems
               Lynn Monsanto, Sun
               Dave Perkins, 3COM
               Jim Reinstedler, Ungerman Bass
               Anil Rijsinghani, DEC
               Kary Robertson
               Marshall T. Rose, PSI (chair)
               L. Michael Sabo, NCSC
               Jon Saperia, DEC
               John Seligson
               Fei Shu, NEC
               Sam Sjogren, TGV
               Mark Sleeper, Sparta


SNMP & Transmission MIB Working Groups                         [Page 24]

RFC 1233                 DS3 Interface Objects                  March 1992


               Lance Sprung
               Mike St.Johns
               Bob Stewart, Xyplex
               Emil Sturniold
               Kaj Tesink, Bellcore
               Dean Throop, Data General
               Bill Townsend, Xylogics
               Maurice Turcotte
               Kannan Varadhou
               Sudhanshu Verma, HP
               Warren Vik, Interactive Systems
               David Waitzman, BBN
               Steve Waldbusser, CMU
               Dan Wintringhan
               David Wood
               Jeff Young, Cray Research

7.  References

   [1] Cerf, V., "IAB Recommendations for the Development of Internet
       Network Management Standards", RFC 1052, NRI, April 1988.

   [2] Cerf, V., "Report of the Second Ad Hoc Network Management Review
       Group", RFC 1109, NRI, August 1989.

   [3] Rose M., and K. McCloghrie, "Structure and Identification of
       Management Information for TCP/IP-based internets", RFC 1155,
       Performance Systems International, Hughes LAN Systems, May 1990.

   [4] 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.

   [5] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
       Network Management Protocol", RFC 1157, SNMP Research,
       Performance Systems International, Performance Systems
       International, MIT Laboratory for Computer Science, May 1990.

   [6] McCloghrie K., and M. Rose, Editors, "Management Information Base
       for Network Management of TCP/IP-based internets", RFC 1213,
       Performance Systems International, March 1991.

   [7] Information processing systems - Open Systems Interconnection -
       Specification of Abstract Syntax Notation One (ASN.1),
       International Organization for Standardization, International
       Standard 8824, December 1987.

   [8] 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.

   [9] American National Standard for telecommunications - digital
       hierarchy - electrical interfaces, ANSI T1.102- 1987.

 


SNMP & Transmission MIB Working Groups                         [Page 25]

RFC 1233                 DS3 Interface Objects                  March 1992


  [10] American National Standard for telecommunications - digital
       hierarchy - formats specification, ANSI T1.107- 1988.

  [10a] ANSI T1.107a-1990.

  [11] American National Standard for telecommunications - Carrier-to-
       Customer Installation - DS3 Metallic Interface, ANSI T1.404-1989.

  [12] In-Service Digital Transmission Performance Monitoring Draft
       Standard, T1M1.3/91 - 003R3.

  [13] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions",
       RFC 1212, Performance Systems International, Hughes LAN Systems,
       March 1991.

8.  Security Considerations

   Security issues are not discussed in this memo.

9.  Authors' Addresses

   Tracy A. Cox
   Bell Communications Research
   331 Newman Springs Road
   P.O. Box 7020
   Red Bank, NJ  07701-7020

   Phone: (908) 758-2107

   EMail: tacox@sabre.bellcore.com


   Kaj Tesink
   Bell Communications Research
   331 Newman Springs Road
   P.O. Box 7020
   Red Bank, NJ  07701-7020

   Phone: (908) 758-5254

   EMail: kaj@nvuxr.cc.bellcore.com








SNMP & Transmission MIB Working Groups                         [Page 26]











Received: from SAFFRON.ACC.COM by NRI.NRI.Reston.VA.US id aa11103;
          14 Jan 92 13:38 EST
Received: from watson.ibm.com by saffron.acc.com (4.1/SMI-4.1)
	id AA07458; Tue, 14 Jan 92 10:34:14 PST
Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 4654;
   Tue, 14 Jan 92 13:34:08 EST
Received: from YKTVMH by watson.vnet.ibm.com with "VAGENT.V1.0"
          id 5720; Tue, 14 Jan 1992 13:34:09 EST
Received: from cyst.watson.ibm.com by yktvmh.watson.ibm.com (IBM VM SMTP V2R2)
   with TCP; Tue, 14 Jan 92 13:34:08 EST
Received: from patience.watson.ibm.com by cyst.watson.ibm.com (AIX 1.3/900528)
  id AA37386; Tue, 14 Jan 92 13:34:07 -0500
Received: by patience.watson.ibm.com (AIX 1.3/900524)
          id AA11999; Tue, 14 Jan 92 13:32:45 -0500
Message-Id: <9201141832.AA11999@patience.watson.ibm.com>
To: Tracy Cox <tacox@sabre.bellcore.com>
Cc: trunk-mib@saffron.acc.com
X-External-Networks: yes
Subject: Re: re - PathID
In-Reply-To: Your message of Mon, 13 Jan 92 16:12:47 EST.
             <9201132112.AA01756@ginsu4>
Date: Tue, 14 Jan 92 13:32:45 -0500
From: Ed Pring <pring@watson.ibm.com>
Status: O

Yes, I meant the C-Bit Parity PathID strings.

The information has to be configured somehow.  For the T3
equipment we use, PathID strings are loaded via the network
management interface that SNMP uses to retrieve status and
statistics.  I have added variables for the transmitted and
received PathID strings to a private device-specific MIB.

To configure the transmitted PathID strings, I can choose between:

- logging in remotely to edit a configuration file and
  then restarting the SNMP agent, or

- distributing a configuration file and then restarting
  the SNMP agent remotely,

- using SNMP 'set' operations.

The latter seems reasonable to me.  Am I missing something obvious?

Ed










Received: from SAFFRON.ACC.COM by NRI.NRI.Reston.VA.US id aa11503;
          14 Jan 92 13:58 EST
Received: from sabre.bellcore.com by saffron.acc.com (4.1/SMI-4.1)
	id AA07473; Tue, 14 Jan 92 10:54:34 PST
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA13136; Tue, 14 Jan 92 13:55:34 EST
Return-Path: <tacox@ginsu4@sabre.bellcore.com>
Received: from localhost by ginsu4 (4.1/4.7)
	id AA01923; Tue, 14 Jan 92 13:48:59 EST
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9201141848.AA01923@ginsu4>
To: Ed Pring <pring@watson.ibm.com>
Cc: trunk-mib@saffron.acc.com
Subject: Re: re - PathID 
In-Reply-To: Your message of "Tue, 14 Jan 92 13:32:45 EST."
             <9201141832.AA11999@patience.watson.ibm.com> 
Date: Tue, 14 Jan 92 13:48:57 -0500
From: tacox@ginsu4.bellcore.com
Status: O

Ed,

sorry -- I thought (wrongly so) that sysLocation was read-only.

Therefore you would like to see:

all of this added to the ds3ConfigTable as read/write --> this would
only be for C-bit Parity applications following ANSI T1.107a-1990

ds3EquipCode
  DisplayString (Size(0..255)),
ds3LocationIDCode
  DisplayString (Size(0..255)),
ds3FrameIDCode
  DisplayString (Size(0..255)),
ds3UnitCode
  DisplayString (Size(0..255)),
ds3FacilityIDCode
  DisplayString (Size(0..255)),
ds3FarEndEquipCode
  DisplayString (Size(0..255)),
ds3FarEndLocationIDCode
  DisplayString (Size(0..255)),
ds3FarEndFrameIDCode
  DisplayString (Size(0..255)),
ds3FarEndUnitCode
  DisplayString (Size(0..255)),
ds3FarEndFacilityIDCode
  DisplayString (Size(0..255))


Is this what you want?

Tracy










Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa19478;
          16 Jan 92 16:45 EST
Received: from SAFFRON.ACC.COM by NRI.NRI.Reston.VA.US id aa19474;
          16 Jan 92 16:45 EST
Received: from vnet.ibm.com by saffron.acc.com (4.1/SMI-4.1)
	id AA07236; Thu, 16 Jan 92 13:39:49 PST
Message-Id: <9201162139.AA07236@saffron.acc.com>
Received: from RALVM29 by vnet.ibm.com (IBM VM SMTP V2R2) with BSMTP id 8664;
   Thu, 16 Jan 92 16:39:53 EST
Date: Thu, 16 Jan 92 16:34:36 EST
From: "Laurence V. Marks" <lmarks@vnet.ibm.com>
To: tacox@ginsu4.bellcore.com, tob@thumper.bellcore.com, 
    trunk-mib@saffron.acc.com, pring@watson.ibm.com
Cc: GARDO@ralvm29.vnet.ibm.com, DILLON@ralvm29.vnet.ibm.com
Subject: Far-End Statistics for ds3 MIB
Status: O

Ted Brunner remarks:
>  I don't think I've seen a convincingly important application that
>  needs them {Far End Performance statistics}.  But then I haven't
>  looked very hard either.

Perhaps I can be persuasive...

First, some disclaimers:

--I've been working on ds1, not ds3.  I'm more familiar with T1.403
  and T1.408 than T1.107.
--I've been thinking more about ISDN and Frame Relay than dedicated
  point-to-point ds1.
--My job focus is more on Layer 1 error detection and reporting than
  network management.
--I have a weak background in SNMP (I've read Marshal Rose's book.), so
  my conclusions may be at cross-purposes with its general philosophy
  through ignorance.

And then some comments:

The assumption is that for point-to-point service within a single
exchane,  Performance Report Messages (PRMs) may originate at the Far
End, but for the first case below, they will originate at the ET. This
is based upon ANSI T1.403, para. 8.4.3.2, which states that:

     The carrier signal and the CI signal shall include a
     performance report sent each second using a bit-
     assigned message structure.

I believe there are some legitimate instances where maintaining Far-End
statistics serves a useful and unique purpose.  These include:

CASE 1
--When the traffic is switched to different points (in ds1, this
  corresponds to 'ISDN Primary' or 'Switched T-1')
--When customer traffic is multiplexed (dynamically or statically) to
  and from different points (e.g., Frame Relay, provisioned channelized
  T-1, aggregation of Fractional T-1s, or packet-mode ISDN)

In this cases, there is simply no other way to determine how well your
transmissions are reaching the 'cloud'.  There isn't any single far-end
partner to be queried by the SNMP manager.

Analyzing the Far-End statistics from the ET is a good way for the
customer to begin isolating a problem, providing the most diagnostic
information. Since Frame Relay service is expected to be available on
ds3, it makes sense to extend this ds1 conclusion to the ds3 MIB.

CASE 2
--When a station (even on a dedicated point-to-point link) suffers
  communications failure and is isolated from the SNMP manager

This case may be improbable--I'm not sure--but in the event that a
station's point-to-point link fails completely, an astute SNMP manager
could query its Far-End partner for Far-End statistics to see if there
were any trend before the failure.

Laurence V. Marks
lmarks@vnet.ibm.com










Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa16054;
          21 Jan 92 15:20 EST
Received: from [129.192.64.32] by NRI.NRI.Reston.VA.US id aa16050;
          21 Jan 92 15:20 EST
Received: by saffron.acc.com (4.1/SMI-4.1)
	id AA08873; Tue, 21 Jan 92 11:32:22 PST
Date: Tue, 21 Jan 92 11:32:22 PST
From: Fred Baker <fbaker@acc.com>
Message-Id: <9201211932.AA08873@saffron.acc.com>
Errors-To: fbaker@saffron.acc.com
To: trunk-mib@saffron.acc.com
Subject: Mailer Failure
Status: O

Hi:

Tracy wrote this morning to point out that the mailing list on saffron
had seen better days; it had.  I had some 'help' from a sysadmin, who
overwrote my alias file.

I have re-constructed the mailing list.  If you could glance through
the following and tell me if your address is not the way you like it
(Marshall, what was that alias?), or if I am missing somebody, I would
appreciate it.

Fred
====================================================
telnet saffron.acc.com 25
Trying 129.192.64.32 ...
Connected to saffron.acc.com.
Escape character is '^]'.
220 saffron.acc.com Sendmail 4.1/SMI-4.1 ready at Tue, 21 Jan 92 11:27:54 PST
expn trunk-mib
250-<tob@thumper.bellcore.com>
250-<tacox@sabre.bellcore.com>
250-<rpower@hondo.sw.stratus.com>
250-<pring@watson.ibm.com>
250-<preiss@ralvm6.vnet.ibm.com>
250-<piskun@nisc.psi.net>
250-<patience@watson.ibm.com>
250-<mrose@dbc.mtview.ca.us>
250-<lmarks@vnet.ibm.com>
250-<kolb@psi.com>
250-<keranen@pepper.rc.nokia.fi>
250-<kentrox!litster@uunet.uu.net>
250-<kaj@nvuxr.cc.bellcore.com>
250-<jrd@allspice.lcs.mit.edu>
250-<jamesw@newbridge.com>
250-<ietf-manager@nri.reston.va.us>
250-<harley@io.t3plus.com>
250-<groucho!jimmy@uu.psi.com>
250-<gardo@ralvm29.vnet.ibm.com>
250-Fred Baker <fbaker>
250 <dillon@ralvm29.vnet.ibm.com>
quit
221 saffron.acc.com closing connection










Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa17802;
          21 Jan 92 16:47 EST
Received: from SAFFRON.ACC.COM by NRI.NRI.Reston.VA.US id aa17789;
          21 Jan 92 16:47 EST
Received: from sabre.bellcore.com by saffron.acc.com (4.1/SMI-4.1)
	id AA09277; Tue, 21 Jan 92 13:39:38 PST
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA28335; Tue, 21 Jan 92 16:40:55 EST
Return-Path: <tacox@ginsu4@sabre.bellcore.com>
Received: from localhost by ginsu4 (4.1/4.7)
	id AA03294; Tue, 21 Jan 92 16:34:08 EST
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9201212134.AA03294@ginsu4>
To: trunk-mib@saffron.acc.com
Subject: try again
Date: Tue, 21 Jan 92 16:34:07 -0500
From: tacox@ginsu4.bellcore.com
Status: O


------- Forwarded Message

Return-Path: MAILER-DAEMON@salt.acc.com
Received: by sword.bellcore.com;id 9201211520.AA17785
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA24610; Tue, 21 Jan 92 10:19:48 EST
Return-Path: <MAILER-DAEMON@salt.acc.com@sabre.bellcore.com>
Received: from thumper.bellcore.com by ginsu4 (4.1/4.7)
	id AA03129; Tue, 21 Jan 92 10:13:02 EST
X-Station-Sent-From: ginsu4.bellcore.com
Received: from salt.acc.com by thumper.bellcore.com (4.1/4.7)
	id <AA07902> for tacox@ginsu4.bellcore.com; Tue, 21 Jan 92 10:18:23 EST
Received: from sabre.bellcore.com by salt.acc.com (5.61/1.34)
	id AA14611; Tue, 21 Jan 92 07:18:07 -0800
Date: Tue, 21 Jan 92 07:18:07 -0800
From: MAILER-DAEMON@salt.acc.com (Mail Delivery Subsystem)
Subject: Returned mail: User unknown
Message-Id: <9201211518.AA14611@salt.acc.com>
To: <tacox@ginsu4>



   ----- Transcript of session follows -----
>>> RCPT To:<trunk-mib@saffron.acc.com>
<<< 550 <trunk-mib@saffron.acc.com>... User unknown
550 <trunk-mib@saffron.acc.com>... User unknown

   ----- Unsent message follows -----
Received: from sabre.bellcore.com by salt.acc.com (5.61/1.34)
	id AA14606; Tue, 21 Jan 92 07:18:07 -0800
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA24591; Tue, 21 Jan 92 10:17:39 EST
Return-Path: <tacox@ginsu4@sabre.bellcore.com>
Received: from localhost by ginsu4 (4.1/4.7)
	id AA03123; Tue, 21 Jan 92 10:10:53 EST
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9201211510.AA03123@ginsu4>
To: pring@watson.ibm.com, trunk-mib@saffron.acc.com
Subject: 
Date: Tue, 21 Jan 92 10:10:52 -0500
From: tacox@ginsu4.bellcore.com


- ------- Forwarded Message

Subject: re- Path ID questions

Ed,

In reply to your questions:


1).- In the CSUs we use, the Equipment ID code is composed of several
  subfields, some of which are displayable ASCII and some of whichh
  are binary.  Is this part of the standard?  If so, then ds3EquipCode
  should either be an OCTET STRING (instead of a DisplayString) or it
  should be replaced with separate variables for the subfields.

- - --  In ANSI T1.107a-1990, the definition of Equipment Identification Code
is the following:  EIC (up to 10 characters) describes a specific peice
of equipment.
(A word is one octet -- ASCII character.)

A DisplayString is defined as an OCTET STRING (Size(0..255))
It is used for ASCII characters -- the ds3EquipCode should be
a DisplayString (Size(1..10)) -- you always need the ASCII null character
even if you don't use that field.  The standard does not allow for other types
of characters.

Is changing the size of the DisplayString legal?

2).- In the CSUs we use, the other ID codes all have fixed and apparently
  arbitrary lengths.  Is this part of the standard?  If so, then the
  ds3XxxIDCode variables should have those lengths (instead of SIZE(0..255)).

- - --- Yes that is true -- I should change the length of the DisplayString
to the defined lengths in the T1 standard; however again
Is changing the size of the DisplayString legal?


Tracy

- ------- End of Forwarded Message


------- End of Forwarded Message











Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa21198;
          22 Jan 92 17:33 EST
Received: from SAFFRON.ACC.COM by NRI.NRI.Reston.VA.US id aa21194;
          22 Jan 92 17:33 EST
Received: from vnet.ibm.com by saffron.acc.com (4.1/SMI-4.1)
	id AA00259; Wed, 22 Jan 92 14:22:58 PST
Message-Id: <9201222222.AA00259@saffron.acc.com>
Received: from RALVM29 by vnet.ibm.com (IBM VM SMTP V2R2) with BSMTP id 0319;
   Wed, 22 Jan 92 17:22:51 EST
Date: Wed, 22 Jan 92 14:48:06 EST
From: "Laurence V. Marks" <lmarks@vnet.ibm.com>
To: trunk-mib@saffron.acc.com
Subject: RFC1232 - ds1 MIB
Status: O

One more thing that might bear discussion at San Diego....

A quirk in the way that RFC1232 is written is that the Section 4.3
consists of definitions from an obsolete version of ANSI draft T1M1, but
Section 5 refers not to 4.3, but directly to the T1M1 document.

This seems inconsistent (aside from the fact that current documents
should be used).  Wouldn't it be more consistent to either refer in
Section to the self-contained definitions, or to delete them?

Or is it RFC practice to reproduce definitions from other bodies,
accepting the potential updating nuisance?

Larry Marks
lmarks@vnet.ibm.com










Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa11160;
          23 Jan 92 12:55 EST
Received: from SAFFRON.ACC.COM by NRI.NRI.Reston.VA.US id aa11154;
          23 Jan 92 12:55 EST
Received: from nrc.com (aztec.NRC.COM) by saffron.acc.com (4.1/SMI-4.1)
	id AA00585; Thu, 23 Jan 92 09:45:33 PST
Received: from mickey.NRC.COM by nrc.com (4.0/NRC-DDN1.2)
	id AA29012; Thu, 23 Jan 92 09:45:38 PST
Received: by mickey.NRC.COM (5.51/SMI-3.2)
	id AA16961; Thu, 23 Jan 92 09:45:28 PST
Date: Thu, 23 Jan 92 09:45:28 PST
From: Bill Versteeg <bvs@nrc.com>
Message-Id: <9201231745.AA16961@mickey.NRC.COM>
To: trunk-mib@saffron.acc.com
Subject: Looking for manager implementations
Cc: bvs@nrc.com
Status: O


I am writing a PC based proxy SNMP agent for the DS1 MIB (rfc1232)
and I am trying to get into a position to test it when I am done.

So- Does anyone know of a manager that does something T1ish with
	the DS1 MIB? Is anyone doing such a project and interested in 
	some testing in the next few months?


I have a prototype DS1 proxy agent
running  under UNIX that I have tested using text-based
query tools, but when the real product is complete, I would like to
test it against a manager that has some smarts.


Bill VerSteeg
bvs@nrc.com










Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa16356;
          23 Jan 92 16:07 EST
Received: from SAFFRON.ACC.COM by NRI.NRI.Reston.VA.US id aa16352;
          23 Jan 92 16:07 EST
Received: from salt.acc.com by saffron.acc.com (4.1/SMI-4.1)
	id AA00706; Thu, 23 Jan 92 12:38:29 PST
Received: from sabre.bellcore.com by salt.acc.com (5.61/1.34)
	id AA27753; Thu, 23 Jan 92 12:38:47 -0800
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA14312; Thu, 23 Jan 92 15:37:16 EST
Return-Path: <tacox@ginsu4@sabre.bellcore.com>
Received: from localhost by ginsu4 (4.1/4.7)
	id AA03533; Thu, 23 Jan 92 15:30:25 EST
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9201232030.AA03533@ginsu4>
To: Ed Pring <pring@watson.ibm.com>
Cc: trunk-mib@saffron.acc.com
Subject: Re: re- Path ID questions 
In-Reply-To: Your message of "Tue, 21 Jan 92 11:02:34 EST."
             <9201211602.AA10146@patience.watson.ibm.com> 
Date: Thu, 23 Jan 92 15:30:23 -0500
From: tacox@ginsu4.bellcore.com
Status: O

> 
> 
> I hate to be pedantic, but . . .
> 
> With respect to the ANSI standard:
> 
> Is the EIC defined as a variable-length field, with a maximum length
> of ten bytes, or a fixed-length field of ten bytes, with unused
> bytes filled with null bytes?  Are the contents of the bytes explicitly
> restricted to some defined character set?  Is an empty EIC allowed, and
> if so, how is it represented?

The EIC is defined as a data element that is up to 10 characters
long.  The ASCII null character shall be used to indicate
the end of the string when the full length of data element is not needed for
a given word.  The remaining bit positions of the data element may
contain ones, zeros
or any combination there of.
The standard is not explicit on what character set is used.  ( I would
think that you should use ASCII).  But if you have
an empty EIC then -- the first octet of the data element shall contain
the ASCII null character.  The remaining bit positions of the data element
may contain ones, zeros, or any combination there of.

 
> 
> With respect to SNMP representation:
> 
> If I understand RFC 1158 and RCF 1213 correctly, DisplayString is just
> a symonym for OCTET STRING, and only conveys a restriction on the
> contents of the bytes, not the length of the string.  In any case,
> I don't think ASN.1 uses null-terminated strings - it encodes the lengths
> of fields explicitly.

This is true. 

> 
> If so, then if EIC is defined as a variable-length string of ASCII
> symbols, it could validly be represented in SNMP by
> 
> 	ds3EquipCode DisplayString(0..10)

Yes.

> 
> Or, if its defined as a fixed-length string of ASCII symbols, perhaps
> with unused bytes filled with zeroes, it could validly be represented
> in SNMP by
> 
> 	ds3EquipCode DisplayString(10)
> 
> - Ed

With the null character terminating the string and the random characters
at the end, I would rather see

   ds3EquipCode DisplayString(0..10)

Tracy










Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa17231;
          23 Jan 92 16:43 EST
Received: from SAFFRON.ACC.COM by NRI.NRI.Reston.VA.US id aa17203;
          23 Jan 92 16:42 EST
Received: from sabre.bellcore.com by saffron.acc.com (4.1/SMI-4.1)
	id AA00776; Thu, 23 Jan 92 13:31:00 PST
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA14778; Thu, 23 Jan 92 16:32:19 EST
Return-Path: <tacox@sabre.bellcore.com>
Received: by ginsu4 (4.1/4.7)
	id AA03581; Thu, 23 Jan 92 16:25:29 EST
Date: Thu, 23 Jan 92 16:25:29 EST
From: Tracy Cox <tacox@sabre.bellcore.com>
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9201232125.AA03581@ginsu4>
To: trunk-mib@saffron.acc.com
Subject: re-  DS3 mib comments from Ed Pring
Status: O

Ed,

I received your comments.  Thanks.
I have a few questions:

I am confused about you point aabout ADDING
the ds3CSUIndex.  It was always there.  What I did
do to it is tried to finagle the definition of
ds3CSUIndex to correct a problem with the mib.
First, I think this mib should manage DS3 interfaces
and not devices.  So the definition of ds3CSUIndex
was changed to reflect that opinion.
Maybe I can try to clarify the text in Section 4.1.
The ds3CSUIndex was originally used to identify CSUs
and the ds3Index was used to identify interfaces on the
respective CSU -- but note how all the tables (interval,
current, and total) are indexed -- they are indexed by
the ds3CSUIndex only (I think they should have been indexed
by both ds3CSUIndex and ds3Index because you can
be gathering statistics off of all your DS1 interfaces
on one CSU).  However, to not totally deprecate the whole
mib -- I decided to change the definition of the ds3CSUIndex
to reflect the interfaces on one CSU (1--10)
interfaces on another CSU (11-20).
Therefore the ds3Index is redundant information on that CSU -
but its definition is tied to the ifIndex.

Therefore, ds3CSUIndex identifies the interfaces on one
CSU -- but you do something weird with the numbers --
meaning if you are managing CSU1 with 8 interfaces
you number them 1-8 (and the ds3Indices are numbered
1-8 also) and you are managing CSU2 with 7 interfaces
you number them 11-17 (and the ds3Indices are numbered
1-7).  are you following this?

I hope that I have clarified you first question.

About loopbacks -- now with the knowledge that I am
trying to model interfaces and not CSUs -- relook
at the NewLoopback object and see if it makes more
sense.  Maybe not!

Tracy










Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa18175;
          28 Jan 92 14:38 EST
Received: from SAFFRON.ACC.COM by NRI.NRI.Reston.VA.US id aa18159;
          28 Jan 92 14:38 EST
Received: from watson.ibm.com ([129.34.139.4]) by saffron.acc.com (4.1/SMI-4.1)
	id AA00607; Tue, 28 Jan 92 11:05:35 PST
Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 3399;
   Tue, 28 Jan 92 14:05:29 EST
Received: from YKTVMH by watson.vnet.ibm.com with "VAGENT.V1.0"
          id 1374; Tue, 28 Jan 1992 14:05:27 EST
Received: from cyst.watson.ibm.com by yktvmh.watson.ibm.com (IBM VM SMTP V2R2)
   with TCP; Tue, 28 Jan 92 14:05:26 EST
Received: from patience.watson.ibm.com by cyst.watson.ibm.com (AIX 1.3/900528)
  id AA31806; Tue, 28 Jan 92 14:05:30 -0500
Received: by patience.watson.ibm.com (AIX 1.3/900524)
          id AA14553; Tue, 28 Jan 92 14:03:48 -0500
Message-Id: <9201281903.AA14553@patience.watson.ibm.com>
To: tacox@ginsu4.bellcore.com
Cc: trunk-mib@saffron.acc.com
X-External-Networks: yes
Subject: Re: re- Path ID questions
In-Reply-To: Your message of Thu, 23 Jan 92 15:30:23 EST.
             <9201232030.AA03533@ginsu4>
Date: Tue, 28 Jan 92 14:03:47 -0500
From: Ed Pring <pring@watson.ibm.com>
Status: O

Thanks for the clarification of EIC.  It seems that our CSUs are out of
spec., so I've ordered copies of the ANSI standards, and I'll talk with
our vendor after they arrive.

What is T1M1.3/90-027R2?  Do I need a copy of it, too, and if so, how
do I get one?  ANSI disavowed any knowledge of it.

- Ed










Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa18842;
          28 Jan 92 14:56 EST
Received: from SAFFRON.ACC.COM by NRI.NRI.Reston.VA.US id aa18811;
          28 Jan 92 14:55 EST
Received: from watson.ibm.com by saffron.acc.com (4.1/SMI-4.1)
	id AA00619; Tue, 28 Jan 92 11:46:53 PST
Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 4579;
   Tue, 28 Jan 92 14:46:55 EST
Received: from YKTVMH by watson.vnet.ibm.com with "VAGENT.V1.0"
          id 1786; Tue, 28 Jan 1992 14:46:53 EST
Received: from cyst.watson.ibm.com by yktvmh.watson.ibm.com (IBM VM SMTP V2R2)
   with TCP; Tue, 28 Jan 92 14:46:52 EST
Received: from patience.watson.ibm.com by cyst.watson.ibm.com (AIX 1.3/900528)
  id AA48114; Tue, 28 Jan 92 14:46:55 -0500
Received: by patience.watson.ibm.com (AIX 1.3/900524)
          id AA15341; Tue, 28 Jan 92 14:45:13 -0500
Message-Id: <9201281945.AA15341@patience.watson.ibm.com>
To: Tracy Cox <tacox@sabre.bellcore.com>
Cc: trunk-mib@saffron.acc.com
X-External-Networks: yes
Subject: Re: re- DS3 mib comments from Ed Pring
In-Reply-To: Your message of Thu, 23 Jan 92 16:25:29 EST.
             <9201232125.AA03581@ginsu4>
Date: Tue, 28 Jan 92 14:45:13 -0500
From: Ed Pring <pring@watson.ibm.com>
Status: O

I'm still confused about ds3CSUIndex vs. ds3Index.  I thought I
understood your explanation, but the last part of your example threw
me off again.  Are you trying to accomodate CSUs which support
multiple channels on a single point-to-point link, or CSUs which
support multiple point-to-point links?  I thought you were addressing
the former, but differently than RFC1232 does.  That is:

- In RFC1232, the principal tables are instantiated by CSU, and the
  mapping of CSU channels to system interfaces is expressed in a
  separate little table at the end.

- In RFC1233, you would prefer to instantiate the principle tables by
  CSU channel, and include the mapping of CSU channels to system
  interfaces directly in the Configuration table.

Is this a fair summary of your intent?  If so, then can CSUs which
support multiple channels collect statistics separately for each
channel or do these statistics really apply to the link?  Does it make
sense to instantiate a separate ds3AlarmState for each channel, or do
this variable's values really apply to the link?

If you instead were addressing CSUs which support multiple links, then
are simpler.

In either case, though, the values of ds3Index must be unique for all
CSUs, since they map back to the interfaces table in MIB-II.  That is,
if CSU1 has 8 interfaces which happen to correspond to rows 1 through
8 in the interface table, and CSU2 has 7 interfaces, they can't
correspond to rows 1 through 7 in the interfaces table, can they?

In general, there is no requirement that indices be monotonic in SNMP;
sparse arrays are allowed.  If you really want the ds3 tables to be
oriented towards system interfaces rather than CSUs, then why not use
ds3Index directly as the table index?

- Ed










Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa21899;
          28 Jan 92 16:28 EST
Received: from SAFFRON.ACC.COM by NRI.NRI.Reston.VA.US id aa21886;
          28 Jan 92 16:28 EST
Received: from sabre.bellcore.com by saffron.acc.com (4.1/SMI-4.1)
	id AA00616; Tue, 28 Jan 92 11:41:58 PST
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA13731; Tue, 28 Jan 92 14:43:04 EST
Return-Path: <tacox@ginsu4@sabre.bellcore.com>
Received: from localhost by ginsu4 (4.1/4.7)
	id AA04084; Tue, 28 Jan 92 14:36:22 EST
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9201281936.AA04084@ginsu4>
To: Ed Pring <pring@watson.ibm.com>
Cc: trunk-mib@saffron.acc.com
Subject: Re: re- Path ID questions 
In-Reply-To: Your message of "Tue, 28 Jan 92 14:03:47 EST."
             <9201281903.AA14553@patience.watson.ibm.com> 
Date: Tue, 28 Jan 92 14:36:20 -0500
From: tacox@ginsu4.bellcore.com
Status: O

> 
> 
> Thanks for the clarification of EIC.  It seems that our CSUs are out of
> spec., so I've ordered copies of the ANSI standards, and I'll talk with
> our vendor after they arrive.
> 
> What is T1M1.3/90-027R2?  Do I need a copy of it, too, and if so, how
> do I get one?  ANSI disavowed any knowledge of it.
> 
> - Ed

The above document is a draft.  I have the new updated version -- T1M1.3/01-003R3
send me your US mail address and I will mail you a copy.

Tracy










Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa21962;
          28 Jan 92 16:30 EST
Received: from SAFFRON.ACC.COM by NRI.NRI.Reston.VA.US id aa21929;
          28 Jan 92 16:30 EST
Received: from watson.ibm.com by saffron.acc.com (4.1/SMI-4.1)
	id AA00622; Tue, 28 Jan 92 11:50:04 PST
Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 4664;
   Tue, 28 Jan 92 14:50:06 EST
Received: from YKTVMH by watson.vnet.ibm.com with "VAGENT.V1.0"
          id 1810; Tue, 28 Jan 1992 14:50:04 EST
Received: from cyst.watson.ibm.com by yktvmh.watson.ibm.com (IBM VM SMTP V2R2)
   with TCP; Tue, 28 Jan 92 14:50:03 EST
Received: from patience.watson.ibm.com by cyst.watson.ibm.com (AIX 1.3/900528)
  id AA90005; Tue, 28 Jan 92 14:50:06 -0500
Received: by patience.watson.ibm.com (AIX 1.3/900524)
          id AA04864; Tue, 28 Jan 92 14:48:24 -0500
Message-Id: <9201281948.AA04864@patience.watson.ibm.com>
To: tacox@ginsu4.bellcore.com
Cc: trunk-mib@saffron.acc.com
X-External-Networks: yes
Subject: Re: re- Path ID questions
In-Reply-To: Your message of Tue, 28 Jan 92 14:36:20 EST.
             <9201281936.AA04084@ginsu4>
Date: Tue, 28 Jan 92 14:48:23 -0500
From: Ed Pring <pring@watson.ibm.com>
Status: O

Yes, please mail me a copy of the current T1M1 draft.  My address is:

	Edward Pring
	IBM Watson Research Center
	P. O. Box 218
	Yorktown Heights, New York  10598

- Ed










Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa06879;
          29 Jan 92 8:04 EST
Received: from SAFFRON.ACC.COM by NRI.NRI.Reston.VA.US id aa06870;
          29 Jan 92 8:04 EST
Received: from vnet.ibm.com by saffron.acc.com (4.1/SMI-4.1)
	id AA01035; Wed, 29 Jan 92 04:58:41 PST
Message-Id: <9201291258.AA01035@saffron.acc.com>
Received: from RALVM6 by vnet.ibm.com (IBM VM SMTP V2R2) with BSMTP id 7627;
   Wed, 29 Jan 92 07:58:39 EST
Date: Wed, 29 Jan 92 07:55:13 EST
From: "Jose J. Hoard  <HOARD@RALVM6.VNET.IBM.COM>" <HOARD@ralvm6.vnet.ibm.com>
To: trunk-mib@saffron.acc.com
Status: O

Would you please add my name to the DS1 and DS3 trunk Mib distribution
list.  Thank you, Jose.











Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa07608;
          30 Jan 92 8:26 EST
Received: from SAFFRON.ACC.COM by NRI.NRI.Reston.VA.US id aa07604;
          30 Jan 92 8:26 EST
Received: from vnet.ibm.com by saffron.acc.com (4.1/SMI-4.1)
	id AA03208; Thu, 30 Jan 92 03:43:40 PST
Message-Id: <9201301143.AA03208@saffron.acc.com>
Received: from RALVM29 by vnet.ibm.com (IBM VM SMTP V2R2) with BSMTP id 2954;
   Wed, 29 Jan 92 15:17:04 EST
Date: Wed, 29 Jan 92 15:11:51 EST
From: Russell Gardo <GARDO@ralvm29.vnet.ibm.com>
To: trunk-mib@saffron.acc.com
Subject: RFC1232 Question
Status: O

According to RFC 1232 (page 5) since D4 does not implement CRC-6 in
its multiframe structure, the definition of Errored second is amended
to include BIPOLAR VIOLATIONS.  The definition in the ASN.1
"DESCRIPTION" text (eg, page 14 & 15) of RFC1232 states that the
Errored Second counter conforms to the T1M1 definition.

A contradiction lies in the fact that T1M1 includes single framing
bit errors in its definition of Errored second parameter for D4.  It
does not include BIPOLAR VIOLATIONS.

The T1M1 approach seems more logical since the intent of the
parameter is to measure the quality of the framing bit patterns
whereas bipolar violations are a line quality measure.

Which definition should be used when supporting this MIB???
Any opinions???










Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa20161;
          31 Jan 92 13:54 EST
Received: from SAFFRON.ACC.COM by NRI.NRI.Reston.VA.US id aa20155;
          31 Jan 92 13:54 EST
Received: from sabre.bellcore.com ([128.96.90.1]) by saffron.acc.com (4.1/SMI-4.1)
	id AA02413; Fri, 31 Jan 92 10:51:15 PST
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA09252; Fri, 31 Jan 92 13:52:29 EST
Return-Path: <tacox@sabre.bellcore.com>
Received: by ginsu4 (4.1/4.7)
	id AA04414; Fri, 31 Jan 92 13:45:41 EST
Date: Fri, 31 Jan 92 13:45:41 EST
From: Tracy Cox <tacox@sabre.bellcore.com>
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9201311845.AA04414@ginsu4>
To: trunk-mib@saffron.acc.com
Subject: reply - ED's DS3 comments
Status: O

Ed,

To answer your questions -- my explanations are marked with a -->



I'm still confused about ds3CSUIndex vs. ds3Index.  I thought I
understood your explanation, but the last part of your example threw
me off again.  Are you trying to accomodate CSUs which support
multiple channels on a single point-to-point link, or CSUs which
support multiple point-to-point links? 

--> I am trying to support CSUs which support multiple DS3 interfaces --
forget the idea of a channel (channels to be imply DS0s or 8-bit blocks
of data -- like in the ds1FracTable)



I thought you were addressing
the former, but differently than RFC1232 does.

-->  like I said before, I am trying to support the latter, in the DS3 MIB,
we do not have the notion of a fractional table or channels -- we have
only one DS3 pipe per interface.  One CSU may have multiple DS3 pipes/interfaces.



That is:

- In RFC1232, the principal tables are instantiated by CSU, and the
  mapping of CSU channels to system interfaces is expressed in a
  separate little table at the end.

-->  I am confused by that last statement.  You can use the DS1 MIB
just like I have written the DS3 MIB without using the factional table.



- In RFC1233, you would prefer to instantiate the principle tables by
  CSU channel, and include the mapping of CSU channels to system
  interfaces directly in the Configuration table.


-->  Yes, because I want to model one CSU with multiple DS3 interfaces.
A DS3 interface to the telephone network may be based on C-bit parity,
while the DS3 interface to a private network may be based on M23.
The same can be true (an probably more of a reality) for the DS1 case --
public network interface is ANSI ESF and the private interface is D4 or
something else.



Is this a fair summary of your intent?  If so, then can CSUs which
support multiple channels collect statistics separately for each
channel or do these statistics really apply to the link? 
Does it make
sense to instantiate a separate ds3AlarmState for each channel, or do
this variable's values really apply to the link?

-->  again forget channels and think links (or interfaces)


If you instead were addressing CSUs which support multiple links, then
are simpler.
In either case, though, the values of ds3Index must be unique for all
CSUs, since they map back to the interfaces table in MIB-II.  That is,
if CSU1 has 8 interfaces which happen to correspond to rows 1 through
8 in the interface table, and CSU2 has 7 interfaces, they can't
correspond to rows 1 through 7 in the interfaces table, can they?


-->  agreed, the ds3Index must be unique in the interfaces table.
Then CSU1 can have ifIndices 1-8 and CSU2 can have ifIndices 9-15.
And CSU1s ds3CSUIndices can be numbered 1-8 which is equal to the ds3Indices
and the CSU2s ds3CSUIndices are numbered 11-17 and their ds3Indices are
numbered 9-15.  I know there is a better way -- see below.

In general, there is no requirement that indices be monotonic in SNMP;
sparse arrays are allowed.  If you really want the ds3 tables to be
oriented towards system interfaces rather than CSUs, then why not use
ds3Index directly as the table index?


--> that is what I want to do,  However, do I need to deprecate the whole
table to change how it is indexed????!!!  I want to index all tables
by at least ds3CSUIndex and ds3Index.  We have talked about this many times
and I still see now way to do it easily -- or am I missing something.



- Ed
-->  Tracy











Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa24914;
          2 Feb 92 0:53 EST
Received: from SAFFRON.ACC.COM by NRI.NRI.Reston.VA.US id aa24910;
          2 Feb 92 0:53 EST
Received: from watson.ibm.com by saffron.acc.com (4.1/SMI-4.1)
	id AA06192; Sat, 1 Feb 92 21:49:31 PST
Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 6709;
   Sun, 02 Feb 92 00:49:36 EST
Received: from YKTVMH by watson.vnet.ibm.com with "VAGENT.V1.0"
          id 5874; Sun, 2 Feb 1992 00:49:48 EST
Received: from cyst.watson.ibm.com by yktvmh.watson.ibm.com (IBM VM SMTP V2R2)
   with TCP; Sun, 02 Feb 92 00:49:47 EST
Received: from patience.watson.ibm.com by cyst.watson.ibm.com (AIX 1.3/900528)
  id AA82747; Sun, 2 Feb 92 00:49:37 -0500
Received: by patience.watson.ibm.com (AIX 1.3/900524)
          id AA09712; Sun, 2 Feb 92 00:47:49 -0500
Message-Id: <9202020547.AA09712@patience.watson.ibm.com>
To: Tracy Cox <tacox@sabre.bellcore.com>
Cc: trunk-mib@saffron.acc.com
X-External-Networks: yes
Subject: Re: reply - ED's DS3 comments
In-Reply-To: Your message of Fri, 31 Jan 92 13:45:41 EST.
             <9201311845.AA04414@ginsu4>
Date: Sun, 02 Feb 92 00:47:49 -0500
From: Ed Pring <pring@watson.ibm.com>
Status: O

OK, now I think I understand the situation you're trying to address,
and why the current ds3 MIB definitions are a problem.  To make sure,
let me define some vocabulary and then give an example.

Its confusing to me to use the word "interface" for both host system
communications connections (the things listed by the netstat command
and in the MIB-II "interfaces" table) and for CSU serial link
connections (the things that T3 cables plug into).  Since MIB-II
has already defined "interfaces", let me call the T3 connections to
a CSU "ports" for now.  If there is a more widely accepted term,
I'll use that instead.

Suppose that we have a system with two CSUs, each of which supports
two ports, plus an ethernet adapter.  If you interpret the definitions
in the current ds3 MIB literally, then you might get values like this:

   description       ifIndex    ds3CSUIndex ds3Index
   --------------    -------    --------------------
   loopback             1
   CSU #1 port #1       2            1          2
   CSU #1 port #2       3            1          3
   ethernet             4
   CSU #2 port #1       5            2          5
   CSU #2 port #2       6            2          6

The problem is that since ds3CSUIndex is used as a table index, its
values must be unique.

If I understand your intent correctly, then I'll suggest that what
you'd really like to do is change the table index from ds3CSUIndex to
ds3Index, leaving the current definitions just as they are, and then
add a new variable for the "port" number.  Then you might have
something like this:

   description       ifIndex    ds3Index ds3CSUIndex ds3CSUPort
   --------------    -------    -------------------------------
   loopback             1
   CSU #1 port #1       2           2         1          1
   CSU #1 port #2       3           3         1          2
   ethernet             4
   CSU #2 port #1       5           5         2          1
   CSU #2 port #2       6           6         2          2

Since ds3CSUIndex and ds3CSUPort need not be unique values can be
assigned that are meaningful for the CSUs.  For example, CSUs often
have a serial number stamped on them that is software-readable; this
might be a good choice for ds3CSUIndex.  And the connectors on the
back of a CSU which supports multiple T3 links are usually labelled
"0-3" or "1-4"; these numbers might be a good choice for ds3CSUPort.

If this seems reasonable to you, then the remaining question is: What
bureaucratic process is required to change the index of a table?

And after that, is ds3NewLoopback any better than ds3Loopback?

Ed











Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa18110;
          14 Feb 92 13:24 EST
Received: from SAFFRON.ACC.COM by NRI.NRI.Reston.VA.US id aa18101;
          14 Feb 92 13:24 EST
Received: by saffron.acc.com (4.1/SMI-4.1)
	id AA05364; Fri, 14 Feb 92 10:10:46 PST
Date: Fri, 14 Feb 92 10:10:46 PST
From: Fred Baker <fbaker@acc.com>
Message-Id: <9202141810.AA05364@saffron.acc.com>
To: trunk-mib@saffron.acc.com
Subject: Re: RFC1232 - ds1 MIB
Status: O

Tracy writes to Larry (and I agree)

> One more thing that might bear discussion at San Diego....

> A quirk in the way that RFC1232 is written is that the Section 4.3
> consists of definitions from an obsolete version of ANSI draft T1M1,
> but Section 5 refers not to 4.3, but directly to the T1M1 document.

> This seems inconsistent (aside from the fact that current documents
> should be used).  Wouldn't it be more consistent to either refer in
> Section to the self-contained definitions, or to delete them?

> Or is it RFC practice to reproduce definitions from other bodies,
> accepting the potential updating nuisance?

> Larry Marks

> lmarks@vnet.ibm.com


Larry,

Section 4.3 of both MIBs will be updated to be consistent with the
latest version of the T1M1 document.  I would prefer to include the
definitions in the MIB -- so that people don't have to get the T1M1
document if they don't want to.

Tracy










Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa20695;
          18 Feb 92 14:28 EST
Received: from SAFFRON.ACC.COM by NRI.NRI.Reston.VA.US id aa20681;
          18 Feb 92 14:28 EST
Received: by saffron.acc.com (4.1/SMI-4.1)
	id AA01461; Tue, 18 Feb 92 10:28:27 PST
Return-Path: <fbaker>
Received: by saffron.acc.com (4.1/SMI-4.1)
	id AA01457; Tue, 18 Feb 92 10:28:25 PST
Date: Tue, 18 Feb 92 10:28:25 PST
From: Fred Baker <fbaker@acc.com>
Message-Id: <9202181828.AA01457@saffron.acc.com>
To: trunk-mib@acc.com
Subject: Network Change
Status: O


I am told that there have been some recent problems with the trunk-mib
mailing list.  I have to say that I am not sure what's causing it; I
don't know of any problems with saffron, and the setup of the list is
not unusual.

However, our access to the internet is in a state of flux at the
moment, and that may be contributing.  We are moving from sunny
downtown Santa Barbara to a new building over near UCSB, and in the
process upgrading from a 9.6 link to 56 KBPS access ("hooray!"). In
the process, our servers have been going through some modifications,
and I suspect that there have been some temporary outages.

Announcement:  there will be a real for sure outage starting Wednesday
Afternoon and lasting until Friday Morning.  We are *supposed* to be
live on Friday, but there is this guy named Murphy...

My suggestion:  consider Saffron unreachable from Wednesday morning
through the weekend.  We'll see if the problems go away after that, and
address them if they don't.

Fred










Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa24634;
          19 Feb 92 17:32 EST
Received: from SAFFRON.ACC.COM by NRI.NRI.Reston.VA.US id aa24630;
          19 Feb 92 17:32 EST
Received: by saffron.acc.com (4.1/SMI-4.1)
	id AA09950; Wed, 19 Feb 92 14:27:31 PST
Date: Wed, 19 Feb 92 14:27:31 PST
From: Fred Baker <fbaker@acc.com>
Message-Id: <9202192227.AA09950@saffron.acc.com>
To: trunk-mib@saffron.acc.com
Subject: ignore: test
Status: O

please ignore










Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa26580;
          19 Feb 92 18:32 EST
Received: from FENNEL.ACC.COM by NRI.NRI.Reston.VA.US id aa26570;
          19 Feb 92 18:32 EST
Received: from watson.ibm.com by fennel.acc.com (4.1/SMI-4.1)
	id AA04208; Wed, 19 Feb 92 15:21:50 PST
Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 4229;
   Wed, 19 Feb 92 18:21:40 EST
Received: from YKTVMH by watson.vnet.ibm.com with "VAGENT.V1.0"
          id 2209; Wed, 19 Feb 1992 18:21:49 EST
Received: from cyst.watson.ibm.com by yktvmh.watson.ibm.com (IBM VM SMTP V2R2)
   with TCP; Wed, 19 Feb 92 18:21:45 EST
Received: from patience.watson.ibm.com by cyst.watson.ibm.com (AIX 1.3/900528)
  id AA16533; Wed, 19 Feb 92 18:08:57 -0500
Received: by patience.watson.ibm.com (AIX 1.3/900524)
          id AA11024; Wed, 19 Feb 92 18:06:45 -0500
Message-Id: <9202192306.AA11024@patience.watson.ibm.com>
To: trunk-mib@acc.com, fbaker@acc.com
X-External-Networks: yes
Date: Wed, 19 Feb 92 18:06:45 -0500
From: Ed Pring <pring@watson.ibm.com>
Status: O

test message to trunk-mib@acc.com - please ignore










Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa27290;
          19 Feb 92 18:52 EST
Received: from FENNEL.ACC.COM by NRI.NRI.Reston.VA.US id aa27286;
          19 Feb 92 18:52 EST
Received: from saffron.acc.com by fennel.acc.com (4.1/SMI-4.1)
	id AA04246; Wed, 19 Feb 92 15:44:27 PST
Received: by saffron.acc.com (4.1/SMI-4.1)
	id AA10736; Wed, 19 Feb 92 15:44:05 PST
Date: Wed, 19 Feb 92 15:44:05 PST
From: Fred Baker <fbaker@acc.com>
Message-Id: <9202192344.AA10736@saffron.acc.com>
To: trunk-mib@fennel.acc.com
Subject: list moved
Status: O

Many thanks to Ed Pring.  It appears that he and I may have gotten to the
bottom of the mailing list problems; it appears that the issue is deep
in the bowels of 'sendmail' and 'when is the root the root'.  Our
root file server is not saffron, it is fennel, and that seems to have
gotten significantly in the way a couple of weeks ago.

My apologies.

Please trunk-mib@acc.com from now on.

Fred










Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa27421;
          19 Feb 92 18:59 EST
Received: from FENNEL.ACC.COM by NRI.NRI.Reston.VA.US id aa27417;
          19 Feb 92 18:59 EST
Received: from watson.ibm.com by fennel.acc.com (4.1/SMI-4.1)
	id AB04249; Wed, 19 Feb 92 15:45:36 PST
Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 4464;
   Wed, 19 Feb 92 18:34:42 EST
Received: from YKTVMH by watson.vnet.ibm.com with "VAGENT.V1.0"
          id 2353; Wed, 19 Feb 1992 18:34:51 EST
Received: from cyst.watson.ibm.com by yktvmh.watson.ibm.com (IBM VM SMTP V2R2)
   with TCP; Wed, 19 Feb 92 18:34:50 EST
Received: from patience.watson.ibm.com by cyst.watson.ibm.com (AIX 1.3/900528)
  id AA31700; Wed, 19 Feb 92 18:34:44 -0500
Received: by patience.watson.ibm.com (AIX 1.3/900524)
          id AA16535; Wed, 19 Feb 92 18:32:32 -0500
Message-Id: <9202192332.AA16535@patience.watson.ibm.com>
To: trunk-mib@acc.com
X-External-Networks: yes
Date: Wed, 19 Feb 92 18:32:31 -0500
From: Ed Pring <pring@watson.ibm.com>
Status: O

test message - please ignore










Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa28209;
          19 Feb 92 19:29 EST
Received: from FENNEL.ACC.COM by NRI.NRI.Reston.VA.US id aa28203;
          19 Feb 92 19:28 EST
Received: from watson.ibm.com by fennel.acc.com (4.1/SMI-4.1)
	id AA05101; Wed, 19 Feb 92 16:24:45 PST
Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 5324;
   Wed, 19 Feb 92 19:23:05 EST
Received: from YKTVMH by watson.vnet.ibm.com with "VAGENT.V1.0"
          id 2492; Wed, 19 Feb 1992 19:23:15 EST
Received: from cyst.watson.ibm.com by yktvmh.watson.ibm.com (IBM VM SMTP V2R2)
   with TCP; Wed, 19 Feb 92 19:23:13 EST
Received: from patience.watson.ibm.com by cyst.watson.ibm.com (AIX 1.3/900528)
  id AA23875; Wed, 19 Feb 92 19:23:07 -0500
Received: by patience.watson.ibm.com (AIX 1.3/900524)
          id AA18821; Wed, 19 Feb 92 19:20:54 -0500
Message-Id: <9202200020.AA18821@patience.watson.ibm.com>
To: trunk-mib@acc.com
X-External-Networks: yes
Date: Wed, 19 Feb 92 19:20:54 -0500
From: Ed Pring <pring@watson.ibm.com>
Status: O

Let's see if the trunk-mib mailing list is really working again...

- Ed










Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa20494;
          20 Feb 92 9:01 EST
Received: from FENNEL.ACC.COM by NRI.NRI.Reston.VA.US id aa20483;
          20 Feb 92 9:01 EST
Received: from watson.ibm.com by fennel.acc.com (4.1/SMI-4.1)
	id AA12019; Thu, 20 Feb 92 05:57:19 PST
Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 0789;
   Thu, 20 Feb 92 08:57:08 EST
Received: from YKTVMH by watson.vnet.ibm.com with "VAGENT.V1.0"
          id 3897; Thu, 20 Feb 1992 08:57:17 EST
Received: from cyst.watson.ibm.com by yktvmh.watson.ibm.com (IBM VM SMTP V2R2)
   with TCP; Thu, 20 Feb 92 08:57:16 EST
Received: from patience.watson.ibm.com by cyst.watson.ibm.com (AIX 1.3/900528)
  id AA33587; Thu, 20 Feb 92 08:57:08 -0500
Received: by patience.watson.ibm.com (AIX 1.3/900524)
          id AA09215; Thu, 20 Feb 92 08:54:57 -0500
Message-Id: <9202201354.AA09215@patience.watson.ibm.com>
To: trunk-mib@acc.com
X-External-Networks: yes
Date: Thu, 20 Feb 92 08:54:57 -0500
From: Ed Pring <pring@watson.ibm.com>
Status: O

Yet another test message - please ignore this one too.










Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa22068;
          20 Feb 92 9:32 EST
Received: from FENNEL.ACC.COM by NRI.NRI.Reston.VA.US id aa22062;
          20 Feb 92 9:32 EST
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA12088; Thu, 20 Feb 92 06:28:03 PST
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA08703; Thu, 20 Feb 92 09:28:39 EST
Return-Path: <tacox@sabre.bellcore.com>
Received: by ginsu4 (4.1/4.7)
	id AA00502; Thu, 20 Feb 92 09:27:09 EST
Date: Thu, 20 Feb 92 09:27:09 EST
From: Tracy Cox <tacox@sabre.bellcore.com>
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9202201427.AA00502@ginsu4>
To: trunk-mib@acc.com
Subject: try again
Status: O

Ed, 

If you receive this mail message, please
call me something is really messed
up with sabre.bellcore.com.

Thanks.

Tracy
===========================================
Tracy A. Cox
Bellcore
NVC 1C-354
331 Newman Springs Rd.
Red Bank, NJ  07701
tacox@sabre.bellcore.com email
(908) 758-2107 vmail
(908) 758-4177 fax
===========================================
To: "Russell Gardo" <GARDO@ralvm29.vnet.ibm.com>
Cc: trunk-mib@saffron.acc.com
Subject: Re: RFC1232 Question 
In-Reply-To: Your message of "Wed, 29 Jan 92 15:11:51 EST."
             <9201301143.AA03208@saffron.acc.com> 
Date: Fri, 14 Feb 92 11:21:14 -0500
From: tacox@ginsu4

> 
> 
> According to RFC 1232 (page 5) since D4 does not implement CRC-6 in
> its multiframe structure, the definition of Errored second is amended
> to include BIPOLAR VIOLATIONS.  The definition in the ASN.1
> "DESCRIPTION" text (eg, page 14 & 15) of RFC1232 states that the
> Errored Second counter conforms to the T1M1 definition.
> 
> A contradiction lies in the fact that T1M1 includes single framing
> bit errors in its definition of Errored second parameter for D4.  It
> does not include BIPOLAR VIOLATIONS.
> 
> The T1M1 approach seems more logical since the intent of the
> parameter is to measure the quality of the framing bit patterns
> whereas bipolar violations are a line quality measure.
> 
> Which definition should be used when supporting this MIB???
> Any opinions???


Russel,

T1M1.3/91-003R3 says:

An Errored Seconds:  In the case of DS1 ESF, this parameter is a count
of one-second intervals containing one or more CRC-6 errors, or
one or more CS (controlled slip) events, or one or more
SEF (severely errored framing) events.  In the case of DS1 SF,
this parameter is a count of one-second intervals containing
one or more FE (frame bit error) events, one ore SEF events,
or one ore more CS events. 

So the RFC1232 will be updated to include the definition above which
comes from T1M1.

Tracy











Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa22271;
          20 Feb 92 9:37 EST
Received: from FENNEL.ACC.COM by NRI.NRI.Reston.VA.US id aa22267;
          20 Feb 92 9:37 EST
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA12110; Thu, 20 Feb 92 06:33:29 PST
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA08812; Thu, 20 Feb 92 09:34:05 EST
Return-Path: <tacox@sabre.bellcore.com>
Received: by ginsu4 (4.1/4.7)
	id AA00517; Thu, 20 Feb 92 09:32:36 EST
Date: Thu, 20 Feb 92 09:32:36 EST
From: Tracy Cox <tacox@sabre.bellcore.com>
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9202201432.AA00517@ginsu4>
To: trunk-mib@acc.com
Subject: another one that bounced
Status: O

Ed,

oops forget about the two -- you should have
only received one message.

Tracy


To: "Laurence V. Marks" <lmarks@vnet.ibm.com>
Cc: trunk-mib@saffron.acc.com
Subject: Re: RFC1232 - ds1 MIB 
In-Reply-To: Your message of "Wed, 22 Jan 92 14:48:06 EST."
             <9201222222.AA00259@saffron.acc.com> 
Date: Fri, 14 Feb 92 09:56:16 -0500
From: tacox@ginsu4

> 
> 
> One more thing that might bear discussion at San Diego....
> 
> A quirk in the way that RFC1232 is written is that the Section 4.3
> consists of definitions from an obsolete version of ANSI draft T1M1, but
> Section 5 refers not to 4.3, but directly to the T1M1 document.
> 
> This seems inconsistent (aside from the fact that current documents
> should be used).  Wouldn't it be more consistent to either refer in
> Section to the self-contained definitions, or to delete them?
> 
> Or is it RFC practice to reproduce definitions from other bodies,
> accepting the potential updating nuisance?
> 
> Larry Marks
> lmarks@vnet.ibm.com


Larry,

Section 4.3 of both MIBs will be updated to be consistent with the
latest version of the T1M1 document.
I would prefer to include the definitions in the MIB -- so that people
don't have to get the T1M1 document if they don't want to.


Tracy










Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa22319;
          20 Feb 92 9:39 EST
Received: from FENNEL.ACC.COM by NRI.NRI.Reston.VA.US id aa22311;
          20 Feb 92 9:39 EST
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA12113; Thu, 20 Feb 92 06:34:27 PST
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA08829; Thu, 20 Feb 92 09:34:55 EST
Return-Path: <tacox@sabre.bellcore.com>
Received: by ginsu4 (4.1/4.7)
	id AA00520; Thu, 20 Feb 92 09:33:26 EST
Date: Thu, 20 Feb 92 09:33:26 EST
From: Tracy Cox <tacox@sabre.bellcore.com>
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9202201433.AA00520@ginsu4>
To: trunk-mib@acc.com
Subject: and again .....
Status: O

Subject: reply on comments, long message



Ed,

In reply to your message below:

=====================================================================
Date: Sun, 02 Feb 92 00:47:49 -0500
From: Ed Pring <pring@watson.ibm.com>

OK, now I think I understand the situation you're trying to address,
and why the current ds3 MIB definitions are a problem.  To make sure,
let me define some vocabulary and then give an example.

Its confusing to me to use the word "interface" for both host system
communications connections (the things listed by the netstat command
and in the MIB-II "interfaces" table) and for CSU serial link
connections (the things that T3 cables plug into).  Since MIB-II
has already defined "interfaces", let me call the T3 connections to
a CSU "ports" for now.  If there is a more widely accepted term,
I'll use that instead.

Suppose that we have a system with two CSUs, each of which supports
two ports, plus an ethernet adapter.  If you interpret the definitions
in the current ds3 MIB literally, then you might get values like this:

   description       ifIndex    ds3CSUIndex ds3Index
   --------------    -------    --------------------
   loopback             1
   CSU #1 port #1       2            1          2
   CSU #1 port #2       3            1          3
   ethernet             4
   CSU #2 port #1       5            2          5
   CSU #2 port #2       6            2          6

The problem is that since ds3CSUIndex is used as a table index, its
values must be unique.

If I understand your intent correctly, then I'll suggest that what
you'd really like to do is change the table index from ds3CSUIndex to
ds3Index, leaving the current definitions just as they are, and then
add a new variable for the "port" number.  Then you might have
something like this:

   description       ifIndex    ds3Index ds3CSUIndex ds3CSUPort
   --------------    -------    -------------------------------
   loopback             1
   CSU #1 port #1       2           2         1          1
   CSU #1 port #2       3           3         1          2
   ethernet             4
   CSU #2 port #1       5           5         2          1
   CSU #2 port #2       6           6         2          2

Since ds3CSUIndex and ds3CSUPort need not be unique values can be
assigned that are meaningful for the CSUs.  For example, CSUs often
have a serial number stamped on them that is software-readable; this
might be a good choice for ds3CSUIndex.  And the connectors on the
back of a CSU which supports multiple T3 links are usually labelled
"0-3" or "1-4"; these numbers might be a good choice for ds3CSUPort.

If this seems reasonable to you, then the remaining question is: What
bureaucratic process is required to change the index of a table?

And after that, is ds3NewLoopback any better than ds3Loopback?

Ed
=================================================================

Yes, I would like to change the INDEX of each table to
inclue either just ds3Index or both ds3CSUIndex and ds3Index;
thus leaving the description the same.

However, did you see my message to Colm Bergin:

==================================================
To: cbergin%dalitc@digi.lonestar.org, tacox@ginsu4, thumper!tob,
        trunk-mib@saffron.acc.com
Subject: DS3 and DS1 RFCs



Colm Bergin,

Ted Brunner from Bellcore cc'ed me on his mail
message to you about using the DS1/DS3 MIB
to manage a multiplexor or a digital cross-connect.
You were concerned that the MIBs were used only
to manage a CSU.

I am of the opinion that the DS1 MIB can be used
to manage a DS1 interface -- on any device.
To further manage a mux -- you may need other objects,
but the DS1 MIB is the minimum subset of things you need
to manage a device that has a DS1 interface.

I am trying to change the mibs to suit that need.


I would suggest you sign up to the
trunk-mib@saffron.acc.com mailing list to hear
the discussions on the DS1 and DS3 mibs.

To do that send your email info to
trunk-mib-request@saffron.acc.com

We at Bellcore are doing exactly what I described above
for our Switching System that supports SMDS.

For example, our switch has DS3 and DS1 interfaces.
On top of that interface runs the SMDS Interface Protocol
or SIP.  We support in our switch the DS1 and DS3 MIBs --
depending on the interface; and the SIP MIB --  see
draft-ietf-snmp-smdssipmib-06.txt (or 07) in internet-drafts.


So therefore, I see no reason that you could not use the
DS1 MIB to manage a portion of your mux or digital cross connect
system.

Included is your original mail message and Ted's response for
others to follow this arguement.

Thanks.

Tracy

===========================================
Tracy A. Cox
Bellcore
NVC 1C-354
331 Newman Springs Rd.
Red Bank, NJ  07701
tacox@sabre.bellcore.com email
(908) 758-2107 vmail
(908) 758-4177 fax
===========================================
Subject: Help on T1 MIB
Date: Thu, 06 Feb 92 14:22:59 -0500
From: tob@jeff.bellcore.com



Colm Bergin-
	"The T1 mib" is rfc1232, and so when you receive it you
will have what we've got, so far.  It concentrates on error
statistics associated with the transmission facility 
(eg. errored seconds, severly errored seconds, errored framing seconds)
kept on a 15minute time base.  There are also alarm states
(red and yellow) and some minimum amount of descriptive stuff
about the line (eg whether is ANSI-ESF or G704-CRC or ...)
	Now, as you have observed for the DS3 mib, this is kept by CSUs,
and you want to manage a multiplexor and a digital cross connect.
For that, this mib will not help you. 
	There is a mailing list for folks interested
in T1 and DS3 management (trunk-mib@saffron.acc.com) 
The request to join is probably (trunk-mib-request@saffron.acc.com)
Try there.
	The silver lining here is that you may be interested
in talking with other vendors to develop a mib for your line of
equipment.  This list is a good place to start looking for others.
Since I haven't really done such a thing myself,
I'm not qualified to suggest a game plan.  But if you want to 
pursue this, I'd be interested in talking, because I have an
interest in cross-connects in a different context - ATM switches.


Ted Brunner			Bellcore 
tob@thumper.bellcore.com	MRE 2P-252
201/829-4678			445 South St.
				Morristown NJ 07960-1910


------enclosed message---------

Dave,

I just recently received the reference list you posted to the SNMP mailing
list.  I was hoping to find mention of work on a MIB relating to the
management of T-1 multiplexors and digital cross connects, but in my
ignorance, I couldn't identify such a document.  I checked the DS-3
interface description, but it relates only to CSU's (I'm waiting to
receive RFC-1232 on DS-1 interfaces).

Do you know if the IETF is addressing management of such WAN devices?

Thanks for any information,

Colm Bergin
Software Engineer
Integrated Telecom Corp.
Internet: cbergin%dalitc@digi.lonestar.org


----- End Included Message -----

==========================================================

What I would prefer to do is change the ds3CSUIndex to
ds3EquipIndex (same for DS1 also).
ds3EquipIndex is just an identifier of a piece of equipment
the one or more DS3 Interfaces.

Therefore, the DS1 MIB and the DS3 MIB would be used
to monitor any type of DS1/3 interface.

I think the ds3NewLoopback is more generic
for managing just an interface.

ds3SendCode still needs work.

Let me stop here and let you digest all of this.
What do you think?  Are you following this long
message?

Tracy










Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa08063;
          21 Feb 92 9:17 EST
Received: from FENNEL.ACC.COM by NRI.NRI.Reston.VA.US id aa08059;
          21 Feb 92 9:17 EST
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA27045; Fri, 21 Feb 92 06:11:33 PST
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA17670; Fri, 21 Feb 92 09:12:04 EST
Return-Path: <tacox@sabre.bellcore.com>
Received: by ginsu4 (4.1/4.7)
	id AA00699; Fri, 21 Feb 92 09:10:38 EST
Date: Fri, 21 Feb 92 09:10:38 EST
From: Tracy Cox <tacox@sabre.bellcore.com>
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9202211410.AA00699@ginsu4>
To: trunk-mib@acc.com, tacox@ginsu4.bellcore.com
Subject: re -  Ed's DS3 MIB comments
Status: O

Ed,

to answer your mail message
(as an aside -- sabre.bellcore.com is finally
fixed and working properly)

See --> for my responses.

Tracy

======================================================
From: Ed Pring <pring@watson.ibm.com>



Yes, I follow all that.  I have a couple of comments . . .

About table indexing:

I don't think its necessary to index the tables by both
ds3Index and ds3CSUIndex/ds3EquipIndex.  If you use ds3Index,
that should be sufficient, since its assured of uniqueness.
And, using a single index avoids the conceptual difficulties
of making ds3IntervalTable a 4-dimensional table.

If you use just ds3Index, then "Index" should be removed from
ds3CSUIndex/ds3EquipIndex.

-->  yes, I agree.



Its not clear to me why you want to rename ds3CSUxxx to
ds3EquipXxx.  I know that some companies are working on
integrated adapter cards with onboard CSUs; does this exceed
the definition of a "communications/channel service unit",
or did you have something else in mind?  In any case, if
ds3CSUxxx/ds3EquipXxx is not used for table indexing, perhaps it
could be defined to allow a value of zero in situations where
there is no identifiable (meaning external?) "service unit".

--> what I had in mind is having the DS3 MIB manage other things
--> rather than just CSUs -- for example, DS3 multiplexers and
--> cross connects -- obviously this mib is not sufficient to manage
--> the whole box, but rather just the DS3 interface portion of it.
--> All devices that have a DS3 interface must have a core set of
--> managed objects -- these objects would thus appear in the DS3 MIB.
--> If a CSU needs more objects, then it appears in another mib, if a
--> mux needs more objects, then it appears in another mib, ....
--> This is why I would like to change the name and direction of the mib.
--> Is this a too radical of a change?  Are we "allowed" to change
--> the mib this much at this stage?  Marshall, Chuck?


About ds3NewLoopback:

I'm still not comfortable with the definition of this variable,
even in light of the shift of focus in the MIB from CSUs to
interfaces.  It seems ambiguous to me, in terms of where the
loopback is occuring, and in which direction(s) its occuring.

It seems to me there are at least three distinct pieces of
information about loopbacks that could be externalized:

- where along the chain of devices from the local system to
  the remote system the loop occurs, if at all.  I can think of
  at least a dozen generic points that could be identified and
  named.  However, to accurately report some of them, a system
  would probably need out-of-band communications with a carrier's
  network management system.


--> yes, I agree this is the hard part -- the loopback object just states
--> what interface is looping-back the signal -- it can loopback the signal
--> out of the device or back through the device.
--> I am struggling with how to identify where the loopback is coming from
--> and what type of loopback it is (e.g., line loopback or payload loopback)
--> in a very generic non-CSU sense.

- whether or not signals from the local system are being looped
  back to the local system at the loopback point.

- whether or not signals from the remote system are being looped
  back to the remote system at the loopback point.

Before persuing this in any detail, I want to ask whether the
generic ds3 MIB should even attempt to provide any of this
information.  Its been my experience that each vendor's hardware
provides much information about its configuration, status, and
performance that is not expressable within the ds3 MIB.  Details
of loopback status may fall into this category.

--> you may have a point.  I am not sure, but I am having
--> difficulty with the sendCode -- in that it can be sending
--> many different loopback activation messages
--> to many different devices.

I have defined private enterprise-specific MIBs for the hardware
we use.  Each of these private MIBs includes a loopback variable
that is tailored to the loopback modes the hardware provides.
Perhaps the ds3 MIB define a simple looped/notlooped variable
and leave the details to a private MIB.



--> you may have a point.


Ed

--> Tracy










Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa08462;
          21 Feb 92 9:30 EST
Received: from FENNEL.ACC.COM by NRI.NRI.Reston.VA.US id aa08449;
          21 Feb 92 9:30 EST
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA27053; Fri, 21 Feb 92 06:19:18 PST
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA17705; Fri, 21 Feb 92 09:17:43 EST
Return-Path: <tacox@ginsu4@sabre.bellcore.com>
Received: from localhost by ginsu4 (4.1/4.7)
	id AA00712; Fri, 21 Feb 92 09:16:17 EST
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9202211416.AA00712@ginsu4>
To: "Laurence V. Marks" <lmarks@vnet.ibm.com>
Cc: trunk-mib@acc.com, GARDO@ralvm29.vnet.ibm.com, 
    DILLON@ralvm29.vnet.ibm.com, tacox@ginsu4.bellcore.com
Subject: Re: Clarification 
In-Reply-To: Your message of "Tue, 18 Feb 92 14:54:18 EST."
             <9202182036.AA04317@thumper.bellcore.com> 
Date: Fri, 21 Feb 92 09:16:16 -0500
From: tacox@ginsu4.bellcore.com
Status: O

Larry,

I prefer alternative 2, 

2) Alternative: Section 4.3 reproduces T1M1; Section 5 points to 4.3
>    Advantage:    Implementer doesn't need the T1M1 standard.
>                  Internet controls when and how migration happens
>                  for T1M1 changes.
>    Disadvantage: RFC could diverge from T1M1 dependent on T1M1 stability.

but is there a precedant?
For example, what does the Ethernet MIB do with respect to
IEEE 802.3 documents -- or is this too much of a touchy subject?

Tracy
> 
> 
> A missing "5" obscured the meaning of my original note a bit.  It was
> supposed to read:
> 
> > This seems inconsistent (aside from the fact that current documents
> > should be used).  Wouldn't it be more consistent to either refer in
> > Section 5 to the self-contained definitions, or to delete them?
>           -
> 
> It does make sense to update the Sections 4.3, but unless the Sections 5
> are changed to point to 4.3, the same inconsistency will recur as soon
> as the T1M1 working group meets again and changes things.  That seems
> likely, considering that the T1M1 standard is only a draft.
> 
> As I see it, the alternatives are:
> 1) Current way: Section 4.3 reproduces T1M1; Section 5 points directly
>    to T1M1.
>    Advantage:    Implementer doesn't need the T1M1 standard (until it
>                  changes)
>    Disadvantage: Document sections inconsistent when T1M1 changes.
>                  Document stability dependent on T1M1 stability.
> 
> 2) Alternative: Section 4.3 reproduces T1M1; Section 5 points to 4.3
>    Advantage:    Implementer doesn't need the T1M1 standard.
>                  Internet controls when and how migration happens
>                  for T1M1 changes.
>    Disadvantage: RFC could diverge from T1M1 dependent on T1M1 stability.
> 
> 3) Alternative: Section 4.3 empty; Section 5 points directly to T1M1.
>    Advantage:    Document never inconsistent.
>    Disadvantage: Implementer needs the T1M1 standard.
>                  No Internet control or migration management when T1M1
>                  changes.
> 
> I don't want to beat this to death.  If wiser heads conclude that the
> current practice is sufficient, I'm willing to go along.
> 
> Larry Marks
> ----------------------------------------------------------------
> 
> 
> Received: from sabre.bellcore.com by vnet.ibm.com (IBM VM SMTP V2R2) with TCP;
>    Fri, 14 Feb 92 10:01:55 EST
> Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
> 	id AA03582; Fri, 14 Feb 92 10:02:38 EST
> Return-Path: <tacox@ginsu4@sabre.bellcore.com>
> Received: from localhost by ginsu4 (4.1/4.7)
> 	id AA06484; Fri, 14 Feb 92 09:56:17 EST
> X-Station-Sent-From: ginsu4.bellcore.com
> Message-Id: <9202141456.AA06484@ginsu4>
> To: "Laurence V. Marks" <lmarks@vnet.ibm.com>
> Cc: trunk-mib@saffron.acc.com
> Subject: Re: RFC1232 - ds1 MIB
> In-Reply-To: Your message of "Wed, 22 Jan 92 14:48:06 EST."
>              <9201222222.AA00259@saffron.acc.com>
> Date: Fri, 14 Feb 92 09:56:16 -0500
> From: tacox@ginsu4.bellcore.com
> 
> >
> >
> > One more thing that might bear discussion at San Diego....
> >
> > A quirk in the way that RFC1232 is written is that the Section 4.3
> > consists of definitions from an obsolete version of ANSI draft T1M1, but
> > Section 5 refers not to 4.3, but directly to the T1M1 document.
> >
> > This seems inconsistent (aside from the fact that current documents
> > should be used).  Wouldn't it be more consistent to either refer in
> > Section to the self-contained definitions, or to delete them?
> >
> > Or is it RFC practice to reproduce definitions from other bodies,
> > accepting the potential updating nuisance?
> >
> > Larry Marks
> > lmarks@vnet.ibm.com
> 
> 
> Larry,
> 
> Section 4.3 of both MIBs will be updated to be consistent with the
> latest version of the T1M1 document.
> I would prefer to include the definitions in the MIB -- so that people
> don't have to get the T1M1 document if they don't want to.
> 
> 
> Tracy










Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa28091;
          21 Feb 92 18:20 EST
Received: from FENNEL.ACC.COM by NRI.NRI.Reston.VA.US id aa28086;
          21 Feb 92 18:20 EST
Received: from watson.ibm.com by fennel.acc.com (4.1/SMI-4.1)
	id AA27715; Fri, 21 Feb 92 15:14:44 PST
Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 6294;
   Fri, 21 Feb 92 18:14:31 EST
Received: from YKTVMH by watson.vnet.ibm.com with "VAGENT.V1.0"
          id 6378; Fri, 21 Feb 1992 18:14:35 EST
Received: from cyst.watson.ibm.com by yktvmh.watson.ibm.com (IBM VM SMTP V2R2)
   with TCP; Fri, 21 Feb 92 18:14:34 EST
Received: from patience.watson.ibm.com by cyst.watson.ibm.com (AIX 1.3/900528)
  id AA16423; Fri, 21 Feb 92 18:14:27 -0500
Received: by patience.watson.ibm.com (AIX 1.3/900524)
          id AA12880; Fri, 21 Feb 92 18:12:12 -0500
Message-Id: <9202212312.AA12880@patience.watson.ibm.com>
To: Tracy Cox <tacox@sabre.bellcore.com>
Cc: trunk-mib@acc.com, tacox@ginsu4.bellcore.com
X-External-Networks: yes
Subject: Re: re - Ed's DS3 MIB comments
In-Reply-To: Your message of Fri, 21 Feb 92 09:10:38 EST.
             <9202211410.AA00699@ginsu4>
Date: Fri, 21 Feb 92 18:12:11 -0500
From: Ed Pring <pring@watson.ibm.com>
Status: O

Now I think I see your problem:  you're thinking of extending the
the ds3 MIB to manage T3 links that may not correspond to any system
interface (in the MIB-II sense of "interface") and therefore may not
have any valid ifIndex/ds3Index value.

So you want to change the table indexing scheme to something that
isn't necessarily tied to the MIB-II interfaces table.  Is it
reasonable to expect agents which represent multiple multiplexors or
cross-connectors?  If so, two indexes may be necessary, and the
interval table will have to go to four dimensions.

I suppose that does qualify as radical.  It doesn't bother me, though.
Do you have any feeling for how widely implemented the current MIB is?
Before deciding whether to change the existing MIB or deprecate it and
define a new one, it would be helpful to know how many existing
products will be affected, and how their manufacturers feel about it.

Personally, I think the loopback and sendcode variables in the ds3
MIB should be kept simple and generic.   If you start trying to
identify all the types of loopbacks and all the places they can occur
and all the codes they send, you'll probably never finish.

- Ed










Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa10971;
          24 Feb 92 13:46 EST
Received: from FENNEL.ACC.COM by NRI.NRI.Reston.VA.US id aa10883;
          24 Feb 92 13:45 EST
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA18858; Mon, 24 Feb 92 10:17:55 PST
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA05035; Mon, 24 Feb 92 13:17:32 EST
Return-Path: <tacox@sabre.bellcore.com>
Received: by ginsu4 (4.1/4.7)
	id AA01115; Mon, 24 Feb 92 13:16:16 EST
Date: Mon, 24 Feb 92 13:16:16 EST
From: Tracy Cox <tacox@sabre.bellcore.com>
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9202241816.AA01115@ginsu4>
To: trunk-mib@acc.com
Subject: new RFC 1233
Status: O

Gang,

Here is an updated version of RFC1233.
I have included far end tables and some
new configuration information.

I have left the table indexing alone --
but have changed the wording in Section 4.3
to reflect how I would like to see the ds3CSUIndex
be changed.  Alot of messages have gone back and forth
on this issue between Ed Pring and myself.  Does anyone
have an opinion on how to "fix" the problem of
managing a CSU vs. managing a DS3 interface?

The deprecated objects are the loopback, red alarm, and
yellow alarm -- new objects have been introduced to model
a loopback and alarm information.  Only one new counter
has been added to all the performance tables -- ds3IntervalOtherCVs --
to handle the other CV count you receive from C-bit Parity and SYNTRAN
applications.  Also, the CSSs counter was removed since you don't count
that for DS3.

If you have any questions, please ask.  I would like to discuss
these issues at the Trunk MIB WG meeting on Monday the 16th.
I will be on vacation March 2-6 --> If you send me mail before
then I will try to answer it before I leave --> otherwise I will
handle it when I come back on the 9th.

Tracy

==========================================================





Network Working Group                                            T. Cox
Request for Comments: 1233                                    K. Tesink
Updated Version 2.0                        Bell Communications Research
                                                                Editors
                                                             March 1992


                     Definitions of Managed Objects
                       for the DS3 Interface Type
                                Version 2.0


Status of this Memo

   This memo defines objects for managing DS3 Interface objects for use
   with the SNMP protocol.  This memo is a product of the SNMP and
   Transmission MIB Working Group of the Internet Engineering Task Force
   (IETF).  This RFC specifies an IAB standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "IAB
   Official Protocol Standards" for the standardization state and status
   of this protocol.  Distribution of this memo is unlimited.

Table of Contents

   1. Abstract ..............................................    1
   2. The Network Management Framework.......................    2
   3. Objects ...............................................    2
   3.1 Format of Definitions ................................    3
   3.2 Changes from Version 1.0 .............................    3
   4. Overview ..............................................    3
   4.1 Binding between Interfaces and CSUs ..................    4
   4.2 Objectives of this MIB Module ........................    4
   4.3 DS3 Terminology ......................................    4
   5. Object Definitions ....................................    7
   5.1 The DS3 Configuration Group ..........................    7
   5.2 The DS3 Interval Group ...............................   17
   5.3 The DS3 Current Group ................................   21
   5.4 The DS3 Total Group ..................................   24
   5.5 The DS3 Far End Interval Group .......................   27
   5.6 The DS3 Far End Current Group ........................   30
   5.7 The DS3 Far End Total Group ..........................   32
   6. Acknowledgments .......................................   34
   7. References ............................................   35
   8. Security Considerations................................   36
   9. Authors' Addresses.....................................   36

1.  Abstract

   This memo defines an experimental portion of the Management
   Information Base (MIB) for use with network management protocols in
   TCP/IP-based internets.  In particular, this memo defines MIB objects
   for representing DS3 physical interfaces.  Implementors should
   consult in addition to this memo the companion document that



SNMP & Transmission MIB Working Groups                          [Page 1]

RFC 1233                 DS3 Interface Objects                  March 1992


   describes that DS1 managed objects.

2.  The Network Management Framework

   The Internet-standard Network Management Framework consists of three
   components.  They are:

      RFC 1155 which defines the SMI, the mechanisms used for describing
      and naming objects for the purpose of management.  RFC 1212
      defines a more concise description mechanism, which is wholly
      consistent with the SMI.

      RFC 1156 which defines MIB-I, the core set of managed objects for
      the Internet suite of protocols.  RFC 1213, defines MIB-II, an
      evolution of MIB-I based on implementation experience and new
      operational requirements.

      RFC 1157 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.

3.  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) [7]
   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 [3] 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 [8], subject
   to the additional requirements imposed by the SNMP.



SNMP & Transmission MIB Working Groups                          [Page 2]

RFC 1233                 DS3 Interface Objects                  March 1992


3.1.  Format of Definitions

   Section 5 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 RFC 1212 [13].

3.2.  Changes from Version 1.0

   In order to better prepare implementors for future changes in the
   DS3 MIB, a new term "deprecated" may be used when describing an object.
   A deprecated object in the MIB is one which must be supported, but
   one which will most likely be removed from the next version of the
   DS3 MIB . -- THIS IS REALLY NOT WHAT I WANT! I WOULD LIKE TO DELETE
   THESE OBJECTS IN THIS VERSION?
   HOW DO I DO THAT -- OR CAN I?

   I would like to delete the loopback object, the yellow alarm object,
   and the red alarm object and replace the three of them with two
   different objects:  ds3NewLoopback and ds3AlarmState.
   This change is facilitated by comments on implementations.

   Also, the ds3SendCode is confusing -- the ds3SendLoopbackCode really
   does not do anything -- what is it supposed to do?

   I also added ds3IntervalOtherCVs (Current and Total also) to handle
   C-Bit Parity and SYNTRAN coding violations.
   This change is to be consistent with T1M1 standards.

   I changed the bindings between interfaces and CSUs -- PLEASE READ THAT
   SECTION.  This change is facilitated by comments on implementations.



4.  Overview

   These objects are used when the particular media being used to
   realize an interface is a DS3 interface.  At present, this applies to
   these values of the ifType variable in the Internet-standard MIB:

               ds3 (30)

   The definitions contained herein are based on the DS3 specifications
   in ANSI T1.102-1987, ANSI T1.107-1988,, ANSI T1-107a-1990, and ANSI T1.404-1989
   [9,10,10a,11].


SNMP & Transmission MIB Working Groups                          [Page 3]

RFC 1233                 DS3 Interface Objects                  March 1992
   

4.1.  Binding between Interfaces and CSUs

   Each agent which resides on a host which uses DS3 interfaces is
   required to assign a small, positive integer uniquely to each interface
   located on the CSU.
   This is known as the "CSUIndex", and is used to distinguish between
   different interfaces on the
   CSUs attached to a node.  The CSUIndex is also used as the
   "key" when accessing tabular information about DS3 interfaces.
   Each CSU should be given a range of numbers in order to distinguish
   the DS3 interfaces on the CSUs to a particular
   CSU (e.g., first CSU given 1-10, second CSU given 11-20, ...). 

   The ds3Index column of the DS3 Configuration table relates each interface
   on the CSU to the interfaces table
   in the Internet-standard MIB.

4.2.  Objectives of this MIB Module

   There are numerous things that could be included in a MIB for DS3
   signals: the management of multiplexors, CSUs, DSUs, and the like.
   The intent of this document is to facilitate the common management of
   DS3 interfaces of CSUs, both in-chassis and external via proxy.
   As such, a design
   decision was made up front to very closely align the MIB with the set
   of objects that can generally be read from CSUs that are currently
   deployed.

4.3.  DS3 Terminology

   The terminology used in this document to describe error conditions on
   a DS3 circuit as monitored by a DS3 CSU are from the ANSI T1M1.3/91-003R3
   draft standard [12].

          Bipolar Violation (BPV)
               A bipolar violation, for B3ZS-coded signals, is the
               occurrence of a received bipolar violation that is not
               part of a zero-substitution code.  For B3ZS-coded
               signals, a bipolar violation may also include other error
               patterns such as:  three or more consecutive zeros and
               incorrect polarity.


SNMP & Transmission MIB Working Groups                          [Page 4]

RFC 1233                 DS3 Interface Objects                  March 1992


          Coding Violation (CV)
               For all DS3 applications, a coding violation is a P-bit
               Parity Error event.  A P-bit Parity Error event is the
               occurrence of a received P-bit code on the DS3 M-frame
               that is not identical to the corresponding locally-
               calculated code.  For C-Bit Parity applications, it is
               also the occurrence of a received CP-Bit parity
               violation.  For SYNTRAN applications, it is also the
               occurrence of a received CRC-9 code that is not identical
               to the corresponding locally calculated code.
               Two coding violation counters are used.  The first one
               is used by all DS3 applications
               for just the P-bit Parity Error Event.  The second CV
               counter counts the CP-Bit Parity violations for C-Bit
               Parity applications or the CRC-9 code violations for
               SYNTRAN applications.

          Errored Seconds (ES)
               An ES is a second with one or more Coding Violation OR
               one or more Out of Frame events OR a detected incoming AIS.

          Severely Errored Seconds (SES)
               A SES is a second with 44 or more Coding Violations OR
               one or more Out of Frame events OR a detected incoming AIS.

          Severely Errored Framing Seconds (SEFS)
               A SEFS is a second with one or more Out of Frame events.

          Unavailable Seconds (UAS)
               UAS are calculated by counting the number of seconds that
               the CSU is in the Unavailable signal state (i.e.,
               declared a Red Alarm or a Yellow Alarm), including the
               initial 10 seconds to enter the state but not including
               the 10 seconds to exit the state.

               Note that any second that may be counted as an UAS may
               not be counted as an ES or a SES.  Since the 10 SESs that
               comprise the transition from the available to unavailable
               signal state may also be counted as ESs and SESs previous
               to entering the state, these three counters are adjusted
               so that any second counted during this transition is then
               subtracted.  The 10 seconds in the transition from
               unavailable to available may be counted as ESs.
            
               A special case exists when the 10 or more second period
               crosses the 900 second statistics window boundary, as the
               foregoing description implies that the SES and UAS
               counters must be adjusted when the Unavailable Signal
               State is entered. Clearly, successive GETs of the
               affected ds3IntervalSES and ds3IntervalUAS objects will
               return differing values if the first GET occurs during
               the first few seconds of the window.  This is viewed as
               an unavoidable side-effect of selecting the presently
               defined managed objects as a basis for this memo.


SNMP & Transmission MIB Working Groups                          [Page 5]

RFC 1233                 DS3 Interface Objects                  March 1992


          Alarm States:
               The Far End Alarm (or Yellow Alarm) is declared after detecting
               the Yellow Signal.  See ANSI T1.107a-1990 [10].
               The incoming alarms consist of the following
               incoming signal degradations:  Loss of
               Signal (LOS), a Loss of Frame (LOF)  (a persistent Out
               of Frame event), or an
               Alarm Indication Signal (AIS), for at least 2-10
               seconds.  The Alarms are cleared at the onset of 10
               consecutive seconds with no SES.  See T1M1.3/91-0003R3 [12].
               The Alarm State object identifies only the highest priority
               alarm.  The priorities of the alarms from highest to lowest
               are LOS, LOF, AIS, and Yellow Alarm.

          Out of Frame (OOF) event
               An OOF event is detected when any three or more errors in
               sixteen or fewer consecutive F-bits occur within a DS3
               M-frame.  An OOF event is cleared when reframe occurs.
               A Loss of Frame (LOF) event is declared when the OOF event
               is consistent for 2 to 3 seconds.  The OOF event ends when
               reframe occurs.

          Loss of Signal (LOS)
               This failure is declared upon observing 175 +/- 75
               contiguous pulse positions with no pulses of either
               positive or negative polarity.
               The LOS is terminated upon observing an average pulse density
               of at least 33% over a period of 175 +/- 75 contiguous pulse
               positions starting with the receipt of a pulse.

	  Alarm Indication Signal (AIS)
               The AIS is framed with "stuck stuffing."  This implies
               that it has a valid M-subframe alignments bits, M-frame
               alignment bits, and P bits.  The information bits are set
               to a 1010... sequence, starting with a one (1) after each
               M-subframe alignment bit, M-frame alignment bit, X bit, P bit,
               and C bit.  The C bits are all set to zero giving what is called
               "stuck stuffing."  The X bits are set to one.
               The AIS is declared after AIS is present in contiguous M-frames
               for a time equal to or greater than T, where
               0.2 ms <= T <= 100 ms.
               The AIS is terminated after AIS is absent in contiguous M-frames
               for a time equal to or greater than T.

          Circuit Identifier
               This is a character string specified by the circuit
               vendor, and is useful when communicating with the vendor
               during the troubleshooting process.


SNMP & Transmission MIB Working Groups                          [Page 6]


RFC 1233                 DS3 Interface Objects                  March 1992


5.  Object Definitions

               RFC1233-MIB DEFINITIONS ::= BEGIN

               IMPORTS
                       mgmt, experimental, Counter
                               FROM RFC1155-SMI
                       DisplayString
                               FROM RFC1158-MIB
                       OBJECT-TYPE
                               FROM RFC-1212;

               --  This MIB module uses the extended OBJECT-TYPE macro
               --  as defined in RFC 1212.

               --  this is the MIB module for the DS3 objects

               mib-2 OBJECT IDENTIFIER ::= { mgmt 1 }
               transmission OBJECT IDENTIFIER ::= { mib-2 10 }
               ds3 OBJECT IDENTIFIER ::= { transmission 30 }

               -- the DS3 Configuration group

               -- Although the objects in this group are read-only, at
               -- the agent's discretion they may be made read-write
               -- so that the management station, when appropriately
               -- authorized, may change the behavior of the CSU,
               -- e.g., to place the device into a loopback state.

               -- Implementation of this group is mandatory for all
               -- systems that attach to a DS3 Interface.

               ds3ConfigTable OBJECT-TYPE
                   SYNTAX  SEQUENCE OF DS3ConfigEntry
                   ACCESS  not-accessible
                   STATUS  mandatory
                   DESCRIPTION
                           "The DS3 Configuration table."
                  ::= { ds3 1 }

              ds3ConfigEntry OBJECT-TYPE
                  SYNTAX  DS3ConfigEntry
                  ACCESS  not-accessible
                  STATUS  mandatory
                  DESCRIPTION
                          "An entry in the DS3 Configuration table."
                 INDEX   { ds3CSUIndex }
                 ::= { ds3ConfigTable 1 }

             DS3ConfigEntry ::=
                 SEQUENCE {
                     ds3CSUIndex
                         INTEGER,
                     ds3Index
                         INTEGER,
                     ds3TimeElapsed
                         INTEGER,

SNMP & Transmission MIB Working Groups                          [Page 7]

RFC 1233                 DS3 Interface Objects                  March 1992

                     ds3ValidIntervals
                         INTEGER,
                     ds3LineType
                         INTEGER,
                     ds3ZeroCoding
                         INTEGER,
                     ds3Loopback
                         INTEGER,
                     ds3SendCode
                         INTEGER,
                     ds3YellowAlarm
                         INTEGER,
                     ds3RedAlarm
                         INTEGER,
                     ds3CircuitIdentifier
                         DisplayString,
                     ds3NewLoopback
                         INTEGER,
                     ds3AlarmState
                         INTEGER,
                     ds3EquipCode
                         DisplayString,
                     ds3LocationIDCode
                         DisplayString,
                     ds3FrameIDCode
                         DisplayString,
                     ds3UnitCode
                         DisplayString,
                     ds3FacilityIDCode
                         DisplayString,
                     ds3FarEndEquipCode
                         DisplayString,
                     ds3FarEndLocationIDCode
                         DisplayString,
                     ds3FarEndFrameIDCode
                         DisplayString,
                     ds3FarEndUnitCode
                         DisplayString,
                     ds3FarEndFacilityIDCode
                         DisplayString
             }





SNMP & Transmission MIB Working Groups                          [Page 8]

RFC 1233                 DS3 Interface Objects                  March 1992



             ds3CSUIndex OBJECT-TYPE
                 SYNTAX  INTEGER (1..65535)
                 ACCESS  read-only
                 STATUS  mandatory
                 DESCRIPTION
                         "The index value which uniquely identifies the
                         CSU and its interface to which this entry
                         is applicable."
                ::= { ds3ConfigEntry 1 }

            ds3Index OBJECT-TYPE
                SYNTAX  INTEGER (1..65535)
                ACCESS  read-only
                STATUS  mandatory
                DESCRIPTION
                        "An index value that uniquely identifies a DS3
                        Interface.  The interface identified by a
                        particular value of this index is the same
                        interface as identified by the same value an
                        ifIndex object instance."
               ::= { ds3ConfigEntry 2 }

           ds3TimeElapsed OBJECT-TYPE
               SYNTAX  INTEGER (1..900)
               ACCESS  read-only
               STATUS  mandatory
               DESCRIPTION
                       "The number of seconds, including partial
                       seconds, that have elapsed since the beginning of
                       the current error-measurement period."
              ::= { ds3ConfigEntry 3 }

          ds3ValidIntervals OBJECT-TYPE
              SYNTAX  INTEGER (0..96)
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The number of previous intervals for which valid
                      data was collected.  The value will be 96 unless
                      the CSU device was brought online within the last
                      24 hours, in which case the value will be the
                      number of complete 15 minute intervals the CSU has
                      been online."
              ::= { ds3ConfigEntry 4 }


SNMP & Transmission MIB Working Groups                          [Page 9]

RFC 1233                 DS3 Interface Objects                  March 1992


          ds3LineType OBJECT-TYPE
              SYNTAX  INTEGER {
                          other(1),
                          ds3M23(2),
                          ds3SYNTRAN(3),
                          ds3CbitParity(4),
                          ds3ClearChannel(5)
                      }
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "This variable indicates the variety of DS3 C-bit
                      application implementing this circuit.  The type
                      of circuit affects the interpretation of the usage
                      and error statistics.  The rate of all of them is
                      44.736 Mbps.

                      The values, in sequence, describe:
                      TITLE:            SPECIFICATION:
                      ds3M23            ANSI T1.107-1988
                      ds3SYNTRAN        ANSI T1.107-1988
                      ds3C-bitParity    ANSI T1.107a-1990
                      ds3ClearChannel   ANSI T1.102-1987
                      "
              ::= { ds3ConfigEntry 5 }

          ds3ZeroCoding OBJECT-TYPE
              SYNTAX  INTEGER {
                          ds3Other(1),
                          ds3B3ZS(2)
                      }
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "This variable describes the variety of Zero Code
                      Suppression used on the link, which in turn
                      affects a number of its characteristics.
                      ds3B3ZS refers to the use of specified patterns of
                      normal bits and bipolar violations which are used
                      to replace sequences of zero bits of a specified
                      length."
              ::= { ds3ConfigEntry 6 }


SNMP & Transmission MIB Working Groups                          [Page 10]

RFC 1233                 DS3 Interface Objects                  March 1992


          ds3Loopback OBJECT-TYPE
              SYNTAX  INTEGER {
                          ds3NoLoop(1),
                          ds3LocalLoopbackLocalSide(2),
                          ds3LocalLoopbackRemoteSide(3),
                          ds3RemoteLoopbackLocalSide(4),
                          ds3RemoteLoopbackRemoteSide(5)
                      }
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "This variable represents the loopback state of
                      the CSU.  Devices supporting read/write access
                      should return badValue in response to a requested
                      loopback state that the CSU does not support.  The
                      values mean:

                        ds3NoLoop
                           Not in the loopback state.  A device that is
                           not capable of performing a loopback on
                           either interface shall always return this as
                           it's value.

                        ds3LocalLoopbackLocalSide
                           Signal received from the local side of the
                           device is looped back at the local connector
                           (eg, without involving the CSU).

                        ds3LocalLoopbackRemoteSide
                           Signal received from the local side of the
                           device is looped back at the remote connector
                           (eg, through the CSU).

                        ds3RemoteLoopbackLocalSide
                           Signal received from the remote side of the
                           device is looped back at the local connector
                           (eg, through the CSU).

                        ds3RemoteLoopbackRemoteSide
                           Signal received from the remote side of the
                           device is looped back at the remote connector
                           (eg, without involving the CSU).

                      Note that M23 and ClearChannel interfaces do not
                      support the Loopback managed object."
              ::= { ds3ConfigEntry 7 }





SNMP & Transmission MIB Working Groups                          [Page 11]

RFC 1233                 DS3 Interface Objects                  March 1992


          ds3SendCode OBJECT-TYPE
              SYNTAX  INTEGER {
                          ds3SendTestMessage(1),
                          ds3SendNoCode(2),
                          ds3SendSetCode(3),
                          ds3SendLoopbackCode(4),
                          ds3SendResetCode(5)
                      }
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "This variable indicates what type of code is
                      being sent across the DS3 circuit by the CSU.  The
                      values mean:

                        ds3SendNoCode
                           sending looped or normal data

                        ds3SendSetCode
                           sending a loopback request

                        ds3SendLoopbackCode
                           sending the code to choose a specific
                           loopback -- THIS IS MEANINGLESS -- HOW DO YOU
                           CHOOSE A SPECIFIC LOOPBACK TO ACTIVATE?
                           FOR EXAMPLE ANSI T1.107a SPECIFIES ABOUT 31
                           DIFFERENT LOOPBACKS TO ACTIVATE.

                        ds3SendResetCode
                           sending a loopback termination request

                        ds3SendTestMessage
                           sending a Test pattern as defined in
                           T1.107a-1990.
                      "
              ::= { ds3ConfigEntry 8 }

          ds3YellowAlarm OBJECT-TYPE
              SYNTAX  INTEGER {
                          ds3YellowAlarm(1),
                          ds3NoYellowAlarm(2)
                       }
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                     "This variable indicates if a Yellow
                     Alarm condition exists."
              ::= { ds3ConfigEntry 9 }


SNMP & Transmission MIB Working Groups                         [Page 12]

RFC 1233                 DS3 Interface Objects                  March 1992


          ds3RedAlarm OBJECT-TYPE
              SYNTAX  INTEGER {
                          ds3RedAlarm(1),
                          ds3NoRedAlarm(2)
                      }
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "This variable indicates if a Red Alarm
                      condition exists."
              ::= { ds3ConfigEntry 10 }

          ds3CircuitIdentifier OBJECT-TYPE
              SYNTAX  DisplayString (SIZE (0..255))
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "This variable contains the transmission
                      vendor's circuit identifier, for the
                      purpose of facilitating troubleshooting."
              ::= { ds3ConfigEntry 11 }

          ds3NewLoopback OBJECT-TYPE
              SYNTAX  INTEGER {
                          ds3NoLoop(1),
                          ds3LoopThroughDevice(2),
                          ds3OutOfDevice(3),
                          ds3OtherLoop(4)
                      }
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "This variable represents the loopback state of
                      the DS3 interface.  Devices supporting read/write
                      access should return badValue in response to a
                      requested loopback state that the device does not support.
                      The values mean:

                            ds3NoLoop

                              Not in the loopback state.  A device that is
                              not capable of performing a loopback on
                              either interface shall always return this as
                              it's value.

                            ds3LoopThroughDevice

                              The loopback at one interface is looped through
                              the device.

                            ds3OutOfDevice
                               
                              The loopback at one interface does not go through
                              the device but is looped back out.

                            ds3OtherLoop
         
                              Loopbacks that are not defined here.


SNMP & Transmission MIB Working Groups                         [Page 13]

RFC 1233                 DS3 Interface Objects                  March 1992


                      Note that M23 and ClearChannel interfaces do not
                      support the Loopback managed object."
              ::= { ds3ConfigEntry 12 }

          ds3AlarmState OBJECT-TYPE
              SYNTAX  INTEGER {
                          ds3NoAlarm(1),
                          ds3YellowAlarm(2),
                          ds3AlarmIndicationSignal(3),
		          ds3OutOfFrame(4),
                          ds3LossOfSignal(5)
                      }
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                    "This variable indicates the
                    Alarm State of the interface.
                    If multiple alarms are occurring
                    simultaneously, then the highest
                    priority alarm is the one set.  From
                    highest to lowest the alarm priorities are
                    the following:  ds3LossOfSignal, ds3OutOfFrame,
                    ds3AlarmIndicationSignal, and ds3YellowAlarm."
              ::= { ds3ConfigEntry 13 }

          ds3EquipCode OBJECT-TYPE
              SYNTAX  DisplayString (SIZE (0..10))
              ACCESS  read-write
              STATUS  mandatory
              DESCRIPTION
                    "This is the Equipment Identification code
                    that describes the specific piece of equipment.
                    In C-bit parity applications, it is up to 10 ASCII
                    characters long and is sent within the Path
                    Identification Message."
              ::= { ds3ConfigEntry 14 }

          ds3LocationIDCode OBJECT-TYPE
              SYNTAX  DisplayString (SIZE (0..11))
              ACCESS  read-write
              STATUS  mandatory
              DESCRIPTION
                    "This is the Location Identification code
                    that describes the specific location of the equipment.
                    In C-bit parity applications, it is up to 11 ASCII
                    characters long and is sent within the Path
                    Identification Message."
              ::= { ds3ConfigEntry 15 }


SNMP & Transmission MIB Working Groups                         [Page 14]

RFC 1233                 DS3 Interface Objects                  March 1992


          ds3FrameIDCode OBJECT-TYPE
              SYNTAX  DisplayString (SIZE (0..10))
              ACCESS  read-write
              STATUS  mandatory
              DESCRIPTION
                    "This is the Frame Identification code
                    that identifies where the equipment is located
                    within a building at a given location.
                    In C-bit parity applications, it is up to 10 ASCII
                    characters long and is sent within the Path
                    Identification Message."
              ::= { ds3ConfigEntry 16 }

          ds3UnitCode OBJECT-TYPE
              SYNTAX  DisplayString (SIZE (0..6))
              ACCESS  read-write
              STATUS  mandatory
              DESCRIPTION
                    "This is the code
                    that identifies the equipment location within a bay.
                    In C-bit parity applications, it is up to 6 ASCII
                    characters long and is sent within the Path
                    Identification Message."
              ::= { ds3ConfigEntry 17 }

          ds3FacilityIDCode OBJECT-TYPE
              SYNTAX  DisplayString (SIZE (0..38))
              ACCESS  read-write
              STATUS  mandatory
              DESCRIPTION
                    "This code identifies a specific DS3 path.
                    In C-bit parity applications, it is up to 38 ASCII
                    characters long and is sent within the Path
                    Identification Message."
              ::= { ds3ConfigEntry 18 }

          ds3FarEndEquipCode OBJECT-TYPE
              SYNTAX  DisplayString (SIZE (0..10))
              ACCESS  read-write
              STATUS  mandatory
              DESCRIPTION
                    "This is the Far End Equipment Identification code
                    that describes the specific piece of equipment.
                    This code is only used in C-bit parity applications.
                    devices should return noSuchName when this object is
                    requested in a GET-Request and the next lexicographical
                    object in a GET-NEXT-Request.
                    It is sent within the Path
                    Identification Message."
              ::= { ds3ConfigEntry 19 }


SNMP & Transmission MIB Working Groups                         [Page 15]

RFC 1233                 DS3 Interface Objects                  March 1992


          ds3FarEndLocationIDCode OBJECT-TYPE
              SYNTAX  DisplayString (SIZE (0..11))
              ACCESS  read-write
              STATUS  mandatory
              DESCRIPTION
                    "This is the Far End Location Identification code
                    that describes the specific location of the equipment.
                    This code is only used in C-bit parity applications.
                    Devices should return noSuchName when this object is
                    requested in a GET-Request and the next lexicographical
                    object in a GET-NEXT-Request.
                    It is sent within the Path
                    Identification Message."
              ::= { ds3ConfigEntry 20 }

          ds3FarEndFrameIDCode OBJECT-TYPE
              SYNTAX  DisplayString (SIZE (0..10))
              ACCESS  read-write
              STATUS  mandatory
              DESCRIPTION
                    "This is the Far End Frame Identification code
                    that identifies where the equipment is located
                    within a building at a given location.
                    This code is only used in C-bit parity applications.
                    Devices should return noSuchName when this object is
                    requested in a GET-Request and the next lexicographical
                    object in a GET-NEXT-Request.
                    It is sent within the Path
                    Identification Message."
              ::= { ds3ConfigEntry 21 }

          ds3FarEndUnitCode OBJECT-TYPE
              SYNTAX  DisplayString (SIZE (0..6))
              ACCESS  read-write
              STATUS  mandatory
              DESCRIPTION
                    "This is the Far End code
                    that identifies the equipment location within a bay.
                    This code is only used in C-bit parity applications.
                    Devices should return noSuchName when this object is
                    requested in a GET-Request and the next lexicographical
                    object in a GET-NEXT-Request.
                    It is sent within the Path
                    Identification Message."
              ::= { ds3ConfigEntry 22 }

          ds3FarEndFacilityIDCode OBJECT-TYPE
              SYNTAX  DisplayString (SIZE (0..38))
              ACCESS  read-write
              STATUS  mandatory
              DESCRIPTION
                    "This code identifies a specific Far End DS3 path.
                    This code is only used in C-bit parity applications.
                    Devices should return noSuchName when this object is
                    requested in a GET-Request and the next lexicographical
                    object in a GET-NEXT-Request.
                    It is sent within the Path
                    Identification Message."
              ::= { ds3ConfigEntry 23 }

SNMP & Transmission MIB Working Groups                         [Page 16]

RFC 1233                 DS3 Interface Objects                  March 1992


          -- the DS3 Interval group

          -- Implementation of this group is mandatory for all
          -- systems that attach to a DS3 interface.

          -- The DS3 Interval Table contains various statistics
          -- collected by each CSU over the previous 24 hours of
          -- operation.  The past 24 hours are broken into 96
          -- completed 15 minute intervals.

          ds3IntervalTable OBJECT-TYPE
              SYNTAX  SEQUENCE OF DS3IntervalEntry
              ACCESS  not-accessible
              STATUS  mandatory
              DESCRIPTION
                     "The DS3 Interval table."
              ::= { ds3 2 }

          ds3IntervalEntry OBJECT-TYPE
              SYNTAX  DS3IntervalEntry
              ACCESS  not-accessible
              STATUS  mandatory
              DESCRIPTION
                    "An entry in the DS3 Interval table."
              INDEX   { ds3IntervalIndex, ds3IntervalNumber }
              ::= { ds3IntervalTable 1 }

          DS3IntervalEntry ::=
              SEQUENCE {
                   ds3IntervalIndex
                        INTEGER,
                   ds3IntervalNumber
                        INTEGER,
                   ds3IntervalESs
                        Counter,
                   ds3IntervalSESs
                        Counter,
                   ds3IntervalSEFSs
                        Counter,
                   ds3IntervalUASs
                        Counter,
                   ds3IntervalCSSs
                        Counter,
                   ds3IntervalBPVs
                        Counter,
                   ds3IntervalCVs
                        Counter,
                   ds3IntervalOtherCVs
                        Counter
              }



SNMP & Transmission MIB Working Groups                         [Page 17]

RFC 1233                 DS3 Interface Objects                  March 1992


          ds3IntervalIndex OBJECT-TYPE
              SYNTAX  INTEGER (1..65535)
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The index value which uniquely identifies the
                      CSU and this interface
                      to which this entry is applicable.  The
                      interface identified by a particular value of
                      this index is the same interface as identified
                      by the same value an DS3CSUIndex object
                      instance."
              ::= { ds3IntervalEntry 1 }

         ds3IntervalNumber OBJECT-TYPE
             SYNTAX  INTEGER (1..96)
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                    "A number between 1 and 96, where 1 is the most
                    recently completed 15 minute interval and 96 is
                    the least recently completed 15 minutes
                    interval (assuming that all 96 intervals are
                    valid)."
             ::= { ds3IntervalEntry 2 }

         ds3IntervalESs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                     "The counter associated with the number of
                     Errored Seconds, see Section 4.3, encountered
                     by a DS3 CSU in one of the previous 96,
                     individual 15 minute, intervals."
            ::= { ds3IntervalEntry 3 }

         ds3IntervalSESs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                     "The counter associated with the number of
                     Severely Errored Seconds, see Section 4.3,
                     encountered by a DS3 CSU in one of the previous
                     96, individual 15 minute, intervals."
            ::= { ds3IntervalEntry 4 }


SNMP & Transmission MIB Working Groups                         [Page 18]

RFC 1233                 DS3 Interface Objects                  March 1992


          ds3IntervalSEFSs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                     "The counter associated with the number of
                     Severely Errored Framing Seconds, see Section 4.3,
                     encountered by a DS3 CSU in one of the
                     previous 96, individual 15 minute, intervals."
             ::= { ds3IntervalEntry 5 }

         ds3IntervalUASs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                     "The counter associated with the number of
                     Unavailable Seconds, see Section 4.3,
                     encountered by a DS3 CSU in one of the previous
                     96, individual 15 minute, intervals."
             ::= { ds3IntervalEntry 6 }

         ds3IntervalCSSs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  deprecated
             DESCRIPTION
                     "The counter associated with the number of
                     Controlled Slip Seconds, see Section 4.3,
                     encountered by a DS3 CSU in one of the previous
                     96, individual 15 minute, intervals.
                     Note that SYNTRAN interfaces are the only
                     interfaces that support the Controlled Slip
                     Seconds managed object.  Accordingly, agents
                     configured with non-SYNTRAN interfaces may treat
                     this object as having an ACCESS clause value of
                     not-accessible."
             ::= { ds3IntervalEntry 7}

         ds3IntervalBPVs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                     "The counter associated with the number of Bipolar
                     Violations, see Section 4.3, encountered by a
                     DS3 CSU in one of the previous 96, individual 15
                     minute, intervals."
             ::= { ds3IntervalEntry 8 }



SNMP & Transmission MIB Working Groups                         [Page 19]

RFC 1233                 DS3 Interface Objects                  March 1992


           ds3IntervalCVs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                     "The counter associated with the number of Coding
                     Violations from the P-bits,
                     see Section 4.3, encountered by a
                     DS3 CSU in one of the previous 96, individual 15
                     minute, intervals."
             ::= { ds3IntervalEntry 9 }

          ds3IntervalOtherCVs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Coding
                      Violations from the C-bits,
                      see Section 4.3, encountered by a
                      DS3 CSU in one of the previous 96, individual 15
                      minute, intervals."
              ::= { ds3IntervalEntry 10 }





























SNMP & Transmission MIB Working Groups                         [Page 20]

RFC 1233                 DS3 Interface Objects                  March 1992


          -- the DS3 Current group

          -- Implementation of this group is mandatory for all systems
          -- that attach to a DS3 Interface.

          -- The DS3 current table contains various statistics being
          -- collected for the current 15 minute interval.

          ds3CurrentTable OBJECT-TYPE
              SYNTAX  SEQUENCE OF DS3CurrentEntry
              ACCESS  not-accessible
              STATUS  mandatory
              DESCRIPTION
                      "The DS3 Current table."
              ::= { ds3 3 }

          ds3CurrentEntry OBJECT-TYPE
              SYNTAX  DS3CurrentEntry
              ACCESS  not-accessible
              STATUS  mandatory
              DESCRIPTION
                      "An entry in the DS3 Current table."
              INDEX   { ds3CurrentIndex }
              ::= { ds3CurrentTable 1 }

          DS3CurrentEntry ::=
              SEQUENCE {
                  ds3CurrentIndex
                      INTEGER,
                  ds3CurrentESs
                      Counter,
                  ds3CurrentSESs
                      Counter,
                  ds3CurrentSEFSs
                      Counter,
                  ds3CurrentUASs
                      Counter,
                  ds3CurrentCSSs
                      Counter,
                  ds3CurrentBPVs
                      Counter,
                  ds3CurrentCVs
                      Counter,
                  ds3CurrentOtherCVs
                      Counter
              }

         

SNMP & Transmission MIB Working Groups                         [Page 21]

RFC 1233                 DS3 Interface Objects                  March 1992


           ds3CurrentIndex OBJECT-TYPE
              SYNTAX  INTEGER (1..65535)
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The index value which uniquely identifies the CSU
                      and this interface
                      to which this entry is applicable.  The interface
                      identified by a particular value of this index is
                      the same interface as identified by the same value
                      an DS3CSUIndex object instance."
              ::= { ds3CurrentEntry 1 }

          ds3CurrentESs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Errored
                      Seconds, see Section 4.3, encountered by a DS3
                      CSU in the current 15 minute interval."
              ::= { ds3CurrentEntry 2 }

          ds3CurrentSESs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of
                      Severely Errored Seconds, see Section 4.3,
                      encountered by a DS3 CSU in the current 15 minute
                      interval."
              ::= { ds3CurrentEntry 3 }

          ds3CurrentSEFSs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of
                      Severely Errored Framing Seconds, see Section 4.3,
                      encountered by a DS3 CSU in the current 15
                      minute interval."
              ::= { ds3CurrentEntry 4 }

          ds3CurrentUASs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of
                      Unavailable Seconds, see Section 4.3,
                      encountered by a DS3 CSU in the current 15 minute
                      interval."
              ::= { ds3CurrentEntry 5 }

         

SNMP & Transmission MIB Working Groups                         [Page 22]

RFC 1233                 DS3 Interface Objects                  March 1992


          ds3CurrentCSSs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "The counter associated with the number of
                      Controlled Slip Seconds, see Section 4.3,
                      encountered by a DS3 CSU in the current 15 minute
                      interval.
                      Note that SYNTRAN interfaces are the only
                      interfaces that support the Controlled Slip
                      Seconds managed object.  Accordingly, agents
                      configured with non-SYNTRAN interfaces may treat
                      this object as having an ACCESS clause value of
                      not-accessible."
              ::= { ds3CurrentEntry 6 }

          ds3CurrentBPVs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Bipolar
                      Violations, see Section 4.3, encountered by a
                      DS3 CSU in the current 15 minute interval."
              ::= { ds3CurrentEntry 7}

          ds3CurrentCVs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Coding
                      Violations from the P-bits,
                      see Section 4.3, encountered by a
                      DS3 CSU in the current 15 minute interval."
              ::= { ds3CurrentEntry 8 }
             
          ds3CurrentOtherCVs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Coding
                      Violations from the C-bits,
                      see Section 4.3, encountered by a
                      DS3 CSU in the current 15 minute interval."
              ::= { ds3CurrentEntry 9 }





SNMP & Transmission MIB Working Groups                         [Page 23]

RFC 1233                 DS3 Interface Objects                  March 1992


          -- the DS3 Total group

          -- Implementation of this group is mandatory for all systems
          -- that attach to a DS3.

          -- The DS3 Total Table contains the cumulative sum of the
          -- various statistics for the 24 hour interval preceding the
          -- first valid interval in the DS3CurrentTable.

          ds3TotalTable OBJECT-TYPE
              SYNTAX  SEQUENCE OF DS3TotalEntry
              ACCESS  not-accessible
              STATUS  mandatory
              DESCRIPTION
                      "The DS3 Total table.  24 hour interval."
              ::= { ds3 4 }

          ds3TotalEntry OBJECT-TYPE
              SYNTAX  DS3TotalEntry
              ACCESS  not-accessible
              STATUS  mandatory
              DESCRIPTION
                      "An entry in the DS3 Total table."
              INDEX   { ds3TotalIndex }
              ::= { ds3TotalTable 1 }

          DS3TotalEntry ::=
              SEQUENCE {
                  ds3TotalIndex
                      INTEGER,
                  ds3TotalESs
                      Counter,
                  ds3TotalSESs
                      Counter,
                  ds3TotalSEFSs
                      Counter,
                  ds3TotalUASs
                      Counter,
                  ds3TotalCSSs
                      Counter,
                  ds3TotalBPVs
                      Counter,
                  ds3TotalCVs
                      Counter,
                  ds3TotalOtherCVs
                      Counter
              }

          ds3TotalIndex OBJECT-TYPE
              SYNTAX  INTEGER (1..65535)
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                     



SNMP & Transmission MIB Working Groups                         [Page 24]

RFC 1233                 DS3 Interface Objects                  March 1992


                      "The index value which uniquely identifies the CSU
                      and this interface
                      to which this entry is applicable.  The interface
                      identified by a particular value of this index is
                      the same interface as identified by the same value
                      an DS3CSUIndex object instance."
              ::= { ds3TotalEntry 1 }

         ds3TotalESs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                     "The counter associated with the number of Errored
                     Seconds, see Section 4.3, encountered by a DS3
                     CSU in the previous 24 hour interval."
             ::= { ds3TotalEntry 2 }

         ds3TotalSESs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                     "The counter associated with the number of
                     Severely Errored Seconds, see Section 4.3,
                     encountered by a DS3 CSU in the previous 24 hour
                     interval."
             ::= { ds3TotalEntry 3 }

         ds3TotalSEFSs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                     "The counter associated with the number of
                     Severely Errored Framing Seconds, see Section 4.3,
                     encountered by a DS3 CSU in the previous 24
                     hour interval."
             ::= { ds3TotalEntry 4 }

         ds3TotalUASs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                     "The counter associated with the number of
                     Unavailable Seconds, see Section 4.3,
                     encountered by a DS3 CSU in the previous 24 hour
                     interval."
             ::= { ds3TotalEntry 5 }

         

SNMP & Transmission MIB Working Groups                         [Page 25]

RFC 1233                 DS3 Interface Objects                  March 1992


         ds3TotalCSSs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  deprecated
             DESCRIPTION
                     "The counter associated with the number of
                     Controlled Slip Seconds, see Section 4.3,
                     encountered by a DS3 CSU in the previous 24 hour
                     interval.
                     Note that SYNTRAN interfaces are the only
                     interfaces that support the Controlled Slip
                     Seconds managed object.  Accordingly, agents
                     configured with non-SYNTRAN interfaces may treat
                     this object as having an ACCESS clause value of
                     not-accessible."
             ::= { ds3TotalEntry 6 }

         ds3TotalBPVs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                     "The counter associated with the number of Bipolar
                     Violations, see Section 4.3, encountered by a
                     DS3 CSU in the previous 24 hour interval."
             ::= { ds3TotalEntry 7 }

         ds3TotalCVs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                     "The counter associated with the number of Coding
                     Violations from the P-bits,
                     see Section 4.3, encountered by a
                     DS3 CSU in the previous 24 hour interval."
             ::= { ds3TotalEntry 8 }
      
         ds3TotalOtherCVs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                     "The counter associated with the number of Coding
                     Violations from the C-bits,
                     see Section 4.3, encountered by a
                     DS3 CSU in the previous 24 hour interval."
             ::= { ds3TotalEntry 9 }





SNMP & Transmission MIB Working Groups                         [Page 26]

RFC 1233                 DS3 Interface Objects                  March 1992


          -- the DS3 Far End group
          -- the DS3 Far End Interval group

          -- Implementation of this group is optional for all
          -- systems that attach to a DS3 interface.
          -- Only C-bit Parity Applications and SYNTRAN applications
          -- can provide this information.

          -- The DS3 Far End Interval Table contains various statistics
          -- collected by each CSU over the previous 24 hours of
          -- operation.  The past 24 hours are broken into 96
          -- completed 15 minute intervals.

          ds3FarEndIntervalTable OBJECT-TYPE
              SYNTAX  SEQUENCE OF DS3FarEndIntervalEntry
              ACCESS  not-accessible
              STATUS  optional
              DESCRIPTION
                     "The DS3 Far End Interval table."
              ::= { ds3 5 }

          ds3FarEndIntervalEntry OBJECT-TYPE
              SYNTAX  DS3FarEndIntervalEntry
              ACCESS  not-accessible
              STATUS  optional
              DESCRIPTION
                    "An entry in the DS3 Far
                    End Interval table."
              INDEX   { ds3FarEndIntervalIndex, ds3FarEndIntervalNumber }
              ::= { ds3FarEndIntervalTable 1 }

          DS3FarEndIntervalEntry ::=
              SEQUENCE {
                   ds3FarEndIntervalIndex
                        INTEGER,
                   ds3FarEndIntervalNumber
                        INTEGER,
                   ds3FarEndIntervalESs
                        Counter,
                   ds3FarEndIntervalSESs
                        Counter,
                   ds3FarEndIntervalOtherCVs
                        Counter
              }



SNMP & Transmission MIB Working Groups                         [Page 27]

RFC 1233                 DS3 Interface Objects                  March 1992


          ds3FarEndIntervalIndex OBJECT-TYPE
              SYNTAX  INTEGER (1..65535)
              ACCESS  read-only
              STATUS  optional
              DESCRIPTION
                      "The index value which uniquely identifies the
                      CSU and this interface
                      to which this entry is applicable.  The
                      interface identified by a particular value of
                      this index is the same interface as identified
                      by the same value an DS3CSUIndex object
                      instance."
              ::= { ds3FarEndIntervalEntry 1 }

         ds3FarEndIntervalNumber OBJECT-TYPE
             SYNTAX  INTEGER (1..96)
             ACCESS  read-only
             STATUS  optional
             DESCRIPTION
                    "A number between 1 and 96, where 1 is the most
                    recently completed 15 minute interval and 96 is
                    the least recently completed 15 minutes
                    interval (assuming that all 96 intervals are
                    valid)."
             ::= { ds3FarEndIntervalEntry 2 }

         ds3FarEndIntervalESs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  optional
             DESCRIPTION
                     "The counter associated with the number of
                     Far End Errored Seconds,
                     see Section 4.3, encountered
                     by a DS3 CSU in one of the previous 96,
                     individual 15 minute, intervals."
            ::= { ds3FarEndIntervalEntry 3 }

         ds3FarEndIntervalSESs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  optional
             DESCRIPTION
                     "The counter associated with the number of
                     Far End
                     Severely Errored Seconds, see Section 4.3,
                     encountered by a DS3 CSU in one of the previous
                     96, individual 15 minute, intervals."
            ::= { ds3FarEndIntervalEntry 4 }


SNMP & Transmission MIB Working Groups                         [Page 28]

RFC 1233                 DS3 Interface Objects                  March 1992



          ds3FarEndIntervalOtherCVs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  optional
              DESCRIPTION
                      "The counter associated with the number of
                      Far End Coding
                      Violations from the C-bits reported via
                      the FEBE bits,
                      see Section 4.3, encountered by a
                      DS3 CSU in one of the previous 96, individual 15
                      minute, intervals."
              ::= { ds3FarEndIntervalEntry 5 }





























SNMP & Transmission MIB Working Groups                         [Page 29]

RFC 1233                 DS3 Interface Objects                  March 1992


          -- the DS3 Far End Current group

          -- Implementation of this group is optional for all systems
          -- that attach to a DS3 Interface.
          -- Only C-bit Parity Applications and SYNTRAN applications
          -- can provide this information.

          -- The DS3 Far End Current table contains various statistics being
          -- collected for the current 15 minute interval.

          ds3FarEndCurrentTable OBJECT-TYPE
              SYNTAX  SEQUENCE OF DS3FarEndCurrentEntry
              ACCESS  not-accessible
              STATUS  optional
              DESCRIPTION
                      "The DS3 Far End Current table."
              ::= { ds3 6 }

          ds3FarEndCurrentEntry OBJECT-TYPE
              SYNTAX  DS3FarEndCurrentEntry
              ACCESS  not-accessible
              STATUS  optional
              DESCRIPTION
                      "An entry in the DS3 Far End Current table."
              INDEX   { ds3FarEndCurrentIndex }
              ::= { ds3FarEndCurrentTable 1 }

          DS3FarEndCurrentEntry ::=
              SEQUENCE {
                  ds3FarEndCurrentIndex
                      INTEGER,
                  ds3FarEndCurrentESs
                      Counter,
                  ds3FarEndCurrentSESs
                      Counter,
                  ds3FarEndCurrentOtherCVs
                      Counter
              }

         

SNMP & Transmission MIB Working Groups                         [Page 30]

RFC 1233                 DS3 Interface Objects                  March 1992


           ds3FarEndCurrentIndex OBJECT-TYPE
              SYNTAX  INTEGER (1..65535)
              ACCESS  read-only
              STATUS  optional
              DESCRIPTION
                      "The index value which uniquely identifies the CSU
                      and this interface
                      to which this entry is applicable.  The interface
                      identified by a particular value of this index is
                      the same interface as identified by the same value
                      an DS3CSUIndex object instance."
              ::= { ds3FarEndCurrentEntry 1 }

          ds3FarEndCurrentESs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  optional
              DESCRIPTION
                      "The counter associated with the number of Far
                      End Errored
                      Seconds, see Section 4.3, encountered by a DS3
                      CSU in the current 15 minute interval."
              ::= { ds3FarEndCurrentEntry 2 }

          ds3FarEndCurrentSESs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  optional
              DESCRIPTION
                      "The counter associated with the number of
                      Far End
                      Severely Errored Seconds, see Section 4.3,
                      encountered by a DS3 CSU in the current 15 minute
                      interval."
              ::= { ds3FarEndCurrentEntry 3 }

          ds3FarEndCurrentOtherCVs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  optional
              DESCRIPTION
                      "The counter associated with the number of 
                      Far End Coding
                      Violations from the C-bits reported via
                      the FEBE bits,
                      see Section 4.3, encountered by a
                      DS3 CSU in the current 15 minute interval."
              ::= { ds3FarEndCurrentEntry 4 }





SNMP & Transmission MIB Working Groups                         [Page 31]

RFC 1233                 DS3 Interface Objects                  March 1992


          -- the DS3 Far End Total group

          -- Implementation of this group is optional for all systems
          -- that attach to a DS3.
          -- Only C-bit Parity Applications and SYNTRAN applications
          -- can provide this information.

          -- The DS3 Far End Total Table contains the cumulative sum of the
          -- various statistics for the 24 hour interval preceding the
          -- first valid interval in the DS3FarEndCurrentTable.

          ds3FarEndTotalTable OBJECT-TYPE
              SYNTAX  SEQUENCE OF DS3FarEndTotalEntry
              ACCESS  not-accessible
              STATUS  optional
              DESCRIPTION
                      "The DS3 Far End Total table.  24 hour interval."
              ::= { ds3 7 }

          ds3FarEndTotalEntry OBJECT-TYPE
              SYNTAX  DS3FarEndTotalEntry
              ACCESS  not-accessible
              STATUS  optional
              DESCRIPTION
                      "An entry in the DS3 Far End Total table."
              INDEX   { ds3FarEndTotalIndex }
              ::= { ds3FarEndTotalTable 1 }

          DS3FarEndTotalEntry ::=
              SEQUENCE {
                  ds3FarEndTotalIndex
                      INTEGER,
                  ds3FarEndTotalESs
                      Counter,
                  ds3FarEndTotalSESs
                      Counter,
                  ds3FarEndTotalOtherCVs
                      Counter
              }

          ds3FarEndTotalIndex OBJECT-TYPE
              SYNTAX  INTEGER (1..65535)
              ACCESS  read-only
              STATUS  optional
              DESCRIPTION
                     



SNMP & Transmission MIB Working Groups                         [Page 32]

RFC 1233                 DS3 Interface Objects                  March 1992


                      "The index value which uniquely identifies the CSU
                      and this interface
                      to which this entry is applicable.  The interface
                      identified by a particular value of this index is
                      the same interface as identified by the same value
                      an DS3CSUIndex object instance."
              ::= { ds3FarEndTotalEntry 1 }

         ds3FarEndTotalESs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  optional
             DESCRIPTION
                     "The counter associated with the number of Far
                     End Errored
                     Seconds, see Section 4.3, encountered by a DS3
                     CSU in the previous 24 hour interval."
             ::= { ds3FarEndTotalEntry 2 }

         ds3FarEndTotalSESs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  optional
             DESCRIPTION
                     "The counter associated with the number of
		     Far End
                     Severely Errored Seconds, see Section 4.3,
                     encountered by a DS3 CSU in the previous 24 hour
                     interval."
             ::= { ds3FarEndTotalEntry 3 }

         ds3FarEndTotalOtherCVs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  optional
             DESCRIPTION
                     "The counter associated with the number of
                     Far End Coding
                     Violations from the C-bits reported via the
                     FEBE bits,
                     see Section 4.3, encountered by a
                     DS3 CSU in the previous 24 hour interval."
             ::= { ds3FarEndTotalEntry 4 }

END


SNMP & Transmission MIB Working Groups                         [Page 33]

RFC 1233                 DS3 Interface Objects                  March 1992


6.  Acknowledgments

   This document was produced by the SNMP and the Transmission MIB
   Working Groups:

               Anne Ambler, Spider
               Karl Auerbach, Sun
               Fred Baker, ACC
               Ken Brinkerhoff
               Ron Broersma, NOSC
               Jack Brown, US Army
               Theodore Brunner, Bellcore
               Jeffrey Buffum, HP
               Jeffrey D. Case, UTK
               Chris Chiptasso, Spartacus
               Paul Ciarfella, DEC
               Bob Collet
               Tracy Cox, Bellcore
               James R. Davin, MIT-LCS
               Kurt Dobbins, Cabletron
               Nadya El-Afandi, Network Systems
               Gary Ellis, HP
               Fred Engle
               Mike Erlinger
               Richard Fox, Synoptics
               Karen Frisa, CMU
               Chris Gunner, DEC
               Ken Hibbard, Xylogics
               Ole Jacobsen, Interop
               Ken Jones
               Satish Joshi, Synoptics
               Frank Kastenholz, Racal-Interlan
               Shimshon Kaufman, Spartacus
               Jim Kinder, Fibercom
               Alex Koifman, BBN
               Christopher Kolb, PSI
               Cheryl Krupczak, NCR
               Peter Lin, Vitalink
               John Lunny, TWG
               Carl Malamud
               Keith McCloghrie, HLS
               Donna McMaster, David Systems
               Lynn Monsanto, Sun
               Dave Perkins, 3COM
               Jim Reinstedler, Ungerman Bass
               Anil Rijsinghani, DEC
               Kary Robertson
               Marshall T. Rose, PSI (chair)
               L. Michael Sabo, NCSC
               Jon Saperia, DEC
               John Seligson
               Fei Shu, NEC
               Sam Sjogren, TGV
               Mark Sleeper, Sparta


SNMP & Transmission MIB Working Groups                         [Page 34]

RFC 1233                 DS3 Interface Objects                  March 1992


               Lance Sprung
               Mike St.Johns
               Bob Stewart, Xyplex
               Emil Sturniold
               Kaj Tesink, Bellcore
               Dean Throop, Data General
               Bill Townsend, Xylogics
               Maurice Turcotte
               Kannan Varadhou
               Sudhanshu Verma, HP
               Warren Vik, Interactive Systems
               David Waitzman, BBN
               Steve Waldbusser, CMU
               Dan Wintringhan
               David Wood
               Jeff Young, Cray Research

7.  References

   [1] Cerf, V., "IAB Recommendations for the Development of Internet
       Network Management Standards", RFC 1052, NRI, April 1988.

   [2] Cerf, V., "Report of the Second Ad Hoc Network Management Review
       Group", RFC 1109, NRI, August 1989.

   [3] Rose M., and K. McCloghrie, "Structure and Identification of
       Management Information for TCP/IP-based internets", RFC 1155,
       Performance Systems International, Hughes LAN Systems, May 1990.

   [4] 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.

   [5] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
       Network Management Protocol", RFC 1157, SNMP Research,
       Performance Systems International, Performance Systems
       International, MIT Laboratory for Computer Science, May 1990.

   [6] McCloghrie K., and M. Rose, Editors, "Management Information Base
       for Network Management of TCP/IP-based internets", RFC 1213,
       Performance Systems International, March 1991.

   [7] Information processing systems - Open Systems Interconnection -
       Specification of Abstract Syntax Notation One (ASN.1),
       International Organization for Standardization, International
       Standard 8824, December 1987.

   [8] 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.

   [9] American National Standard for telecommunications - digital
       hierarchy - electrical interfaces, ANSI T1.102- 1987.

 


SNMP & Transmission MIB Working Groups                         [Page 35]

RFC 1233                 DS3 Interface Objects                  March 1992


  [10] American National Standard for telecommunications - digital
       hierarchy - formats specification, ANSI T1.107- 1988.

  [10a] ANSI T1.107a-1990.

  [11] American National Standard for telecommunications - Carrier-to-
       Customer Installation - DS3 Metallic Interface, ANSI T1.404-1989.

  [12] In-Service Digital Transmission Performance Monitoring Draft
       Standard, T1M1.3/91 - 003R3.

  [13] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions",
       RFC 1212, Performance Systems International, Hughes LAN Systems,
       March 1991.

8.  Security Considerations

   Security issues are not discussed in this memo.

9.  Authors' Addresses

   Tracy A. Cox
   Bell Communications Research
   331 Newman Springs Road
   P.O. Box 7020
   Red Bank, NJ  07701-7020

   Phone: (908) 758-2107

   EMail: tacox@sabre.bellcore.com


   Kaj Tesink
   Bell Communications Research
   331 Newman Springs Road
   P.O. Box 7020
   Red Bank, NJ  07701-7020

   Phone: (908) 758-5254

   EMail: kaj@nvuxr.cc.bellcore.com








SNMP & Transmission MIB Working Groups                         [Page 36]











Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa21264;
          24 Feb 92 17:07 EST
Received: from FENNEL.ACC.COM by NRI.NRI.Reston.VA.US id aa21258;
          24 Feb 92 17:07 EST
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA19236; Mon, 24 Feb 92 13:57:07 PST
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA07346; Mon, 24 Feb 92 16:57:23 EST
Return-Path: <tacox@ginsu4@sabre.bellcore.com>
Received: from localhost by ginsu4 (4.1/4.7)
	id AA01245; Mon, 24 Feb 92 16:56:09 EST
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9202242156.AA01245@ginsu4>
To: Fred Baker <fbaker@acc.com>
Cc: jrd@allspice.lcs.mit.edu, tacox@sabre.bellcore.com, trunk-mib@acc.com
Subject: Re: [Ed Pring: Re: re - Ed's DS3 MIB comments] 
In-Reply-To: Your message of "Mon, 24 Feb 92 12:14:22 PST."
             <9202242014.AA00517@saffron.acc.com> 
Date: Mon, 24 Feb 92 16:56:07 -0500
From: tacox@ginsu4.bellcore.com
Status: O

Let`s not blame Ed here.  It is mostly my fault and lack of knowledge
of what the ifTable is managing/modeling.  If I had my druthers, I would
like the DS3/1 MIBs to manage DS3 interfaces and not devices.  There has
been alot of mail going back and forth on "can the DS3 MIB be used to
manage a DS3 multiplexer? It says it is only for
CSUs."  I think the answer is yes -- you can use most
if not all of the mib to manage the DS3 interface/port portion of a DS3
mux -- you may need other "stuff" to manage the muxing portions of it.
But the DS3 MIB really has defined the core set of managed objects to
manage ANY DS3 interface -- we just need to change some of the indexing a bit.
(which seems to be changing too much.)

I do not want to change the charter of the WG and would like to keep
the MIB stable and stay within the guidelines
of the IETF -- look at the DS3 MIB that I have posted to the WG --
have I overstepped that line?

Tracy










Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa24123;
          24 Feb 92 18:16 EST
Received: from FENNEL.ACC.COM by NRI.NRI.Reston.VA.US id aa24119;
          24 Feb 92 18:16 EST
Received: from PTT.LCS.MIT.EDU (ALLSPICE.LCS.MIT.EDU) by fennel.acc.com (4.1/SMI-4.1)
	id AA19603; Mon, 24 Feb 92 15:06:15 PST
Received: from ALLSPICE.LCS.MIT.EDU by PTT.LCS.MIT.EDU via TCP with SMTP
	id AA02101; Mon, 24 Feb 92 18:06:11 EST
Message-Id: <9202242306.AA02101@PTT.LCS.MIT.EDU>
From: "James R. (Chuck) Davin" <jrd@ptt.lcs.mit.edu>
To: tacox@ginsu4.bellcore.com
Cc: Fred Baker <fbaker@acc.com>, jrd@ptt.lcs.mit.edu, 
    tacox@sabre.bellcore.com, trunk-mib@acc.com
Subject: Re: [Ed Pring: Re: re - Ed's DS3 MIB comments] 
In-Reply-To: Your message of Mon, 24 Feb 92 16:56:07 -0500.
             <9202242156.AA01245@ginsu4> 
Date: Mon, 24 Feb 92 18:06:10 -0500
Sender: jrd@ptt.lcs.mit.edu
Status: O


Tracy,

I just got some personal mail from Fred on this subject that cleared
up much of my confusion about the trunk mib(s). But I'm not sure that
what he said agrees with what you are saying.

So email has once again proven its value as a tool for asynchronous
miscommunication :-). Perhaps time will better synchronize everyone's
ideas about what the situation is.

I'll lock onto the right framing pattern eventually.

Chuck













Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa00327;
          24 Feb 92 21:45 EST
Received: from FENNEL.ACC.COM by NRI.NRI.Reston.VA.US id aa00323;
          24 Feb 92 21:45 EST
Received: from watson.ibm.com by fennel.acc.com (4.1/SMI-4.1)
	id AB19995; Mon, 24 Feb 92 18:38:08 PST
Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 6484;
   Mon, 24 Feb 92 21:38:00 EST
Received: from YKTVMH by watson.vnet.ibm.com with "VAGENT.V1.0"
          id 6554; Mon, 24 Feb 1992 21:38:05 EST
Received: from cyst.watson.ibm.com by yktvmh.watson.ibm.com (IBM VM SMTP V2R2)
   with TCP; Mon, 24 Feb 92 21:38:04 EST
Received: from patience.watson.ibm.com by cyst.watson.ibm.com (AIX 1.3/900528)
  id AA13209; Mon, 24 Feb 92 21:37:58 -0500
Received: by patience.watson.ibm.com (AIX 1.3/900524)
          id AA07705; Mon, 24 Feb 92 21:35:38 -0500
Message-Id: <9202250235.AA07705@patience.watson.ibm.com>
To: tacox@ginsu4.bellcore.com
Cc: Fred Baker <fbaker@acc.com>, jrd@allspice.lcs.mit.edu, 
    tacox@sabre.bellcore.com, trunk-mib@acc.com
X-External-Networks: yes
Subject: Re: [Ed Pring: Re: re - Ed's DS3 MIB comments]
In-Reply-To: Your message of Mon, 24 Feb 92 16:56:07 EST.
             <9202242156.AA01245@ginsu4>
Date: Mon, 24 Feb 92 21:35:37 -0500
From: Ed Pring <pring@watson.ibm.com>
Status: OR

If I've stirred things up unnecessarily, its because I'm rather ignorant
of how multiplexors work, and it took several iterations of explanation
for me to understand what Tracy is trying to do.

At the risk of confusing matters further, let me summarize the issues
involved in table indexing, as I understand them now:

- The names and descriptions of the table indexing variables imply that
  the MIB can only be used for managing CSUs.  However, the tables form a
  significant subset of the management information for multiplexors and
  other more sophisticated devices.  Its therefore desirable to rename
  these variables and change their descriptions to emphasise that the
  tables represent an individual T3 link, rather than a CSU, so they can
  clearly be used to manage devices other than CSUs.

- Devices that handle multiple T3 links will need to provide multiple
  sets of tables, and agents will need to represent multiple devices.  Its
  therefore desirable to have two levels of indexing for the tables, rather
  than the current one.

- The T3 links represented by an agent may or may not correspond to some
  system interface in the MIB-II "interfaces" MIB.  Its desirable to allow
  the corresponding ifIndex value to be used as a table index for T3 links
  that do correspond to a "system interface" while allowing other, more
  meaningful values to be used as table indexes for T3 links that do not.

Ed










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa01119;
          4 Mar 92 9:34 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa09310;
          4 Mar 92 9:35 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa09288; 4 Mar 92 9:35 EST
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA28189; Wed, 4 Mar 92 06:29:31 PST
Return-Path: <kaj@nvuxr.cc.bellcore.com@sabre.bellcore.com>
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA12347; Wed, 4 Mar 92 09:29:21 EST
Received: by sword.bellcore.com;id 9203041429.AA15724
Message-Id: <9203041429.AA15724@sword.bellcore.com>
Date: Wed, 4 Mar 92 09:29:22 EST
To: Ed Pring <pring@watson.ibm.com>
From: kaj@nvuxr.cc.bellcore.com
Subject: Re: new RFC 1233/1232
Cc: trunk-mib@acc.com

ed sez:

>OK so far.  Now, if you had two such multiple-line CSUs to
>manage, and the facilities data link for the second one was
>connected to IP interface #3, then the ds1 interfaces in the
>second box would be assigned ds1CSUIndex values of 9, 10, ... 15,
>and all would have ifIndex values of 3, right?
>
given my message yesterday i would say:
>>again, assuming the proxy scenario. why is ifIndex=1??
>>the above suggested that ifIndex=1 is the LAN i/f.
>>my interpretation (proxy scenario) is that the 4kbps
>>line either is irrelevant in the context of ifIndex (ifType etc
>>do not describe the correct info for the 4kbps line anyway),
>>OR, you would use the ifIndex of CSU1 and CSU2 (ifIndex=2 and 3
>>in fred's example).
in fact, i think that by using the current ds1 mib you cannot
really "see" on which link the 4kbps link resides. but that is ok!


>That does minimize disruption to the existing MIB, but are
>you happy with this essentially undefined mapping between
>ds1CSUIndex and ds1 interfaces?  It certainly allows enough
>flexibility to handle new and complex configurations, but it
>doesn't provide enough structure for a management application
>to figure out the configuration without additional information
>that isn't available in this MIB.
>
>- Ed

yes the mapping is somewhat undefined, and the burden is on the
management station and the manager to figure out whats going on.
i think i suggested using ifDescr to provide more info,
e.g., whether you talk equipmentSide or networkSide.
it may not be ideal but it can work.

kaj
0------------0--------------0-------------0-------------0-----------0
Kaj Tesink                            vmail (908) 758-5254
pmail Bellcore                      faxmail (908) 758-4196
      331 Newman Springs Rd.          email kaj@nvuxr.cc.bellcore.com
      Red Bank, NJ 07701











Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa03074;
          4 Mar 92 17:17 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa27239;
          4 Mar 92 17:18 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa27235; 4 Mar 92 17:18 EST
Received: from tbird.cc.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA29330; Wed, 4 Mar 92 14:13:29 PST
Received: by tbird.cc.bellcore.com id AA11441
  (5.65c/IDA-1.4.4 for acc.com!trunk-mib); Wed, 4 Mar 1992 17:13:48 -0500
Message-Id: <199203042213.AA11441@tbird.cc.bellcore.com>
From: "t.r.farese" <trf@nvuxl.cc.bellcore.com>
To: trunk-mib@acc.com
Cc: trf@tbird.cc.bellcore.com
Date:  4 Mar 1992  17:07 EST
Subject: Question related to MIB Implementations

To implementors of T1 Equipment:

I would appreciate your insights to questions in my mind after
reading the SNMP DS1 & DS3 MIBs (RFCs 1232 & 1233):

My first question is regarding CSU implementation:

Each MIB supports a "Total Table" in which the objects are
defined as containing a rolling count of events for the most
recent 24 hour period.
If there are fewer than 96 intervals, (i.e., the CSU was
either initialized or reset within the past 24 hours), what
value is returned in response to a GET for any of these "Total"
counter objects---the sum of the intervals available to date OR
an indication that the count is not available (or something else
& what)?

My second question is regarding an SNMP proxy implementation:

If the proxy has been initialized or reset within the past 24
hours BUT the CSU has not been reset (i.e., the CSU has counts
for intervals that preceed the proxy's sysUpTime = 0), what
should the reply be to a GET for a count that the CSU may have
but the interval occurred before the point in time that the
proxy was reset---the value that the CSU has OR an indication
that the count is not available (or something else & what)?

Any insight to these issues will be greatly appreciated.

Thom Farese
Bellcore NVC 1C443
(908) 758-2242
cc.bellcore.com!trf










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa03185;
          4 Mar 92 17:35 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa28153;
          4 Mar 92 17:35 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa28148; 4 Mar 92 17:35 EST
Received: from saffron.acc.com by fennel.acc.com (4.1/SMI-4.1)
	id AA29396; Wed, 4 Mar 92 14:30:03 PST
Received: by saffron.acc.com (4.1/SMI-4.1)
	id AA21843; Wed, 4 Mar 92 14:29:14 PST
Date: Wed, 4 Mar 92 14:29:14 PST
From: Fred Baker <fbaker@acc.com>
Message-Id: <9203042229.AA21843@saffron.acc.com>
To: trf@nvuxl.cc.bellcore.com
Subject: Re:  Question related to MIB Implementations
Cc: trunk-mib@acc.com

>> If there are fewer than 96 intervals, (i.e., the CSU was either
>> initialized or reset within the past 24 hours), what value is returned
>> in response to a GET for any of these "Total" counter objects---the
>> sum of the intervals available to date OR an indication that the
>> count is not available (or something else & what)?

the sum of the intervals available to date

>> ...what should the reply be to a GET for a count that the CSU may
>> have but the interval occurred before the point in time that the proxy
>> was reset...

there is an object which tells how many 'interval' buckets contain
valid data.  The other ones would, presumably, return INVALID data.










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa00733;
          5 Mar 92 10:36 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa11678;
          5 Mar 92 10:36 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa11672; 5 Mar 92 10:36 EST
Received: from watson.ibm.com by fennel.acc.com (4.1/SMI-4.1)
	id AA16107; Thu, 5 Mar 92 07:30:10 PST
Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 1959;
   Thu, 05 Mar 92 10:30:06 EST
Received: from YKTVMH by watson.vnet.ibm.com with "VAGENT.V1.0"
          id 9497; Thu, 5 Mar 1992 10:30:05 EST
Received: from cyst.watson.ibm.com by yktvmh.watson.ibm.com (IBM VM SMTP V2R2)
   with TCP; Thu, 05 Mar 92 10:30:03 EST
Received: from patience.watson.ibm.com by cyst.watson.ibm.com (AIX 1.3/900528)
  id AA19974; Thu, 5 Mar 92 10:29:58 -0500
Received: by patience.watson.ibm.com (AIX 1.3/900524)
          id AA12796; Thu, 5 Mar 92 10:27:27 -0500
Message-Id: <9203051527.AA12796@patience.watson.ibm.com>
To: kaj@nvuxr.cc.bellcore.com
Cc: trunk-mib@acc.com
X-External-Networks: yes
Subject: Re: new RFC 1233/1232
In-Reply-To: Your message of Wed, 04 Mar 92 09:29:22 EST.
             <9203041429.AA15724@sword.bellcore.com>
Date: Thu, 05 Mar 92 10:27:27 -0500
From: Ed Pring <pring@watson.ibm.com>

Just playing Devil's Advocate ...

As I understand it, one of the goals in extending the MIB (even
if the extension results only in a re-interpretation of the existing
definition) is to accomodate systems such as multiplexors which
manage T1 links but aren't actually connected to them.

Links which aren't actually connected to the system running the
agent won't have an entry in the "interfaces" MIB table, so they
won't have an ifDescr instance to convey additional information,
will they?

For such links, the existing ds1CSUIndex can still be used to
index all of the ds1 MIB's tables, using arbitrary but unique
values.  I suppose that ds1Index should be zero for such links.

Perhaps a ds1Descr variable could be added to the configuration
table.  An agent could use it to provide additional information
about the interface, such as the CSU's serial number, the multiplexor
port number, whether the interface is on the host or equipment side,
or whatever else seems useful.

- Ed










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id ab01024;
          5 Mar 92 12:10 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa15658;
          5 Mar 92 12:10 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa15654; 5 Mar 92 12:10 EST
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA16229; Thu, 5 Mar 92 09:02:56 PST
Return-Path: <kaj@nvuxr.cc.bellcore.com@sabre.bellcore.com>
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA22602; Thu, 5 Mar 92 12:02:42 EST
Received: by sword.bellcore.com;id 9203051702.AA07342
Message-Id: <9203051702.AA07342@sword.bellcore.com>
Date: Thu, 5 Mar 92 12:02:48 EST
To: Ed Pring <pring@watson.ibm.com>
From: kaj@nvuxr.cc.bellcore.com
Subject: Re: new RFC 1233/1232
Cc: trunk-mib@acc.com

Ed sez:
>Just playing Devil's Advocate ...
>
>As I understand it, one of the goals in extending the MIB (even
>if the extension results only in a re-interpretation of the existing
>definition) is to accomodate systems such as multiplexors which
>manage T1 links but aren't actually connected to them.
>
>Links which aren't actually connected to the system running the
>agent won't have an entry in the "interfaces" MIB table, so they
>won't have an ifDescr instance to convey additional information,
>will they?

yes this is of course true; i take a penalty for on the
fly thinking/talking. nevertheless, one can still use it
to point out the implemented convention for ds1CSUIndex,
as in my last example the value of ifDescr could be:
   "DS1 interface, YourProduct,
   ds1CSUIndex=oddValue means equipment Side, and
   ds1CSUOndex=evenValue means network side"
or any other implemented convention as per fred's message.
it's better than nothing, and it works.
(the ifDescr is limited to 255 characters).
>
>For such links, the existing ds1CSUIndex can still be used to
>index all of the ds1 MIB's tables, using arbitrary but unique
>values.  I suppose that ds1Index should be zero for such links.

my interpretation (being a ds1 equipment ignorant) is this:
what we try to achieve is: when router proxies for csu, then
while router/csu from an snmp perspective is one system
(and the ifIndices apply to the i/f's coming OUT), how can you
still say something useful about the INTERNAL i/f's, i.e., the
links between router and csu?

for the common case in fred's example, we have a happy correlation
between links going into the csu, and links going out, i.e., 1:1.
i would therefore implement:
	ifIndex		ds1Index	       ds1CSUIndex
		2      	Equipment Side		1
		2      	Network Side  		2
		3       Equipment Side		3
		3      	Network Side	  	4
rather than:
	ifIndex		ds1Index	       ds1CSUIndex
		0      	Equipment Side		1
		2      	Network Side  		2
		0       Equipment Side		3
		3      	Network Side	  	4
since the ds1Index=ifIndex=0 for both cases sort of 
leaves you in doubt about what i/f you
talk about, and the ifIndex=2,3 describes the situation well,
assuming that the ds1CSUIndex convention is understood.
you can also say that using the same ifIndex value for
the Internal link and the External link suggests that they
are correlated.

of course this only applies to a proxy case; managing the csu
directly would result in ifIndex=ds1Index=ds1CSUIndex, and the
problem would not apply.

>
>Perhaps a ds1Descr variable could be added to the configuration
>table.  An agent could use it to provide additional information
>about the interface, such as the CSU's serial number, the multiplexor
>port number, whether the interface is on the host or equipment side,
>or whatever else seems useful.
>
>- Ed
would be nice, but not absolutely needed i think.

kaj
0------------0--------------0-------------0-------------0-----------0
Kaj Tesink                            vmail (908) 758-5254
pmail Bellcore                      faxmail (908) 758-4196
      331 Newman Springs Rd.          email kaj@nvuxr.cc.bellcore.com
      Red Bank, NJ 07701











Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa01128;
          5 Mar 92 12:35 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa16701;
          5 Mar 92 12:36 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa16692; 5 Mar 92 12:35 EST
Received: from watson.ibm.com by fennel.acc.com (4.1/SMI-4.1)
	id AA16337; Thu, 5 Mar 92 09:31:33 PST
Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 5044;
   Thu, 05 Mar 92 12:31:27 EST
Received: from YKTVMH by watson.vnet.ibm.com with "VAGENT.V1.0"
          id 0734; Thu, 5 Mar 1992 12:31:30 EST
Received: from cyst.watson.ibm.com by yktvmh.watson.ibm.com (IBM VM SMTP V2R2)
   with TCP; Thu, 05 Mar 92 12:31:29 EST
Received: from patience.watson.ibm.com by cyst.watson.ibm.com (AIX 1.3/900528)
  id AA16026; Thu, 5 Mar 92 12:31:19 -0500
Received: by patience.watson.ibm.com (AIX 1.3/900524)
          id AA12797; Thu, 5 Mar 92 12:28:47 -0500
Message-Id: <9203051728.AA12797@patience.watson.ibm.com>
To: kaj@nvuxr.cc.bellcore.com
Cc: trunk-mib@acc.com
X-External-Networks: yes
Subject: Re: new RFC 1233/1232
In-Reply-To: Your message of Thu, 05 Mar 92 12:02:48 EST.
             <9203051702.AA07342@sword.bellcore.com>
Date: Thu, 05 Mar 92 12:28:46 -0500
From: Ed Pring <pring@watson.ibm.com>

What about a configuration such as this?

		      +---------------+
		      |               |
		      |               +--------------------
		      |               |
		      |               +--------------------
	   T3 link    |  T3-to-T1     |
	--------------+ multiplexor   +--------------------
		      |               |  .
		      |               |  . lots of T1 links
		      |               |  .
		      |               +--------------------
		      |               |
		      +-+-------------+
			|
			|management data link
			|
			| (to lots of multiplexors)
			| | | |     |
			| | | | ... |
			| | | |     |
		      +-+-+-+-+-----+-+
		      |               |
		      | some system   |
		      | supporting a  |
		      | SNMP agent    |
		      |               |
		      +------+--------+
			     |
			     |
			     |    Local Area Network
	---------------------+---------------------------

In my experience, the "management data links" of CSUs are usually
RS-232 cables connected to serial ports on the host system, and don't
appear in the SNMP "interfaces" table at all.

In this case, ds1CSUIndex and ds3CSUIndex can still have arbitrary but
unique values, but I can't think of any sensible value for ds1Index or
ds3Index, and I think something like ds1Descr and ds3Descr are
necessary.

- Ed










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa01420;
          5 Mar 92 14:34 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa21541;
          5 Mar 92 14:35 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa21526; 5 Mar 92 14:35 EST
Received: from saffron.acc.com by fennel.acc.com (4.1/SMI-4.1)
	id AA16399; Thu, 5 Mar 92 09:52:16 PST
Received: by saffron.acc.com (4.1/SMI-4.1)
	id AA22065; Thu, 5 Mar 92 09:48:52 PST
Date: Thu, 5 Mar 92 09:48:52 PST
From: Fred Baker <fbaker@acc.com>
Message-Id: <9203051748.AA22065@saffron.acc.com>
To: kaj@nvuxr.cc.bellcore.com, pring@watson.ibm.com
Subject: Re: new RFC 1233/1232
Cc: trunk-mib@acc.com

>> for the common case in fred's example, we have a happy correlation
>> between links going into the csu, and links going out, i.e., 1:1.
>> i would therefore implement:
>> 	ifIndex		ds1Index	       ds1CSUIndex
>> 		2      	Equipment Side		1
>> 		2      	Network Side  		2
>> 		3       Equipment Side		3
>> 		3      	Network Side	  	4
>> rather than:
>> 	ifIndex		ds1Index	       ds1CSUIndex
>> 		0      	Equipment Side		1
>> 		2      	Network Side  		2
>> 		0       Equipment Side		3
>> 		3      	Network Side	  	4

Absolutely - ifIndex is in 1..ifNumber, never 0

Fred










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa01478;
          5 Mar 92 14:42 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa21755;
          5 Mar 92 14:42 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa21751; 5 Mar 92 14:42 EST
Received: from saffron.acc.com by fennel.acc.com (4.1/SMI-4.1)
	id AA16406; Thu, 5 Mar 92 09:55:55 PST
Received: by saffron.acc.com (4.1/SMI-4.1)
	id AA22070; Thu, 5 Mar 92 09:52:32 PST
Date: Thu, 5 Mar 92 09:52:32 PST
From: Fred Baker <fbaker@acc.com>
Message-Id: <9203051752.AA22070@saffron.acc.com>
To: kaj@nvuxr.cc.bellcore.com, pring@watson.ibm.com
Subject: Re: new RFC 1233/1232
Cc: trunk-mib@acc.com

>> In my experience, the "management data links" of CSUs are usually
>> RS-232 cables connected to serial ports on the host system, and don't
>> appear in the SNMP "interfaces" table at all.

That's a real good example of a traditional proxy system.  I have been
told by the gurus that you would respond "as though you are the system
you are proxying for" - from an SNMP perspective, the PC running the
agent *becomes* the multiplexor.

So the proxy's interface table would now include all of the interfaces
of all the systems it proxys for and numbers them accordingly.

Fred










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa02201;
          5 Mar 92 17:40 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa28412;
          5 Mar 92 17:41 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa28408; 5 Mar 92 17:41 EST
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA17385; Thu, 5 Mar 92 14:29:18 PST
Return-Path: <kaj@nvuxr.cc.bellcore.com@sabre.bellcore.com>
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA25963; Thu, 5 Mar 92 17:28:45 EST
Received: by sword.bellcore.com;id 9203052228.AA16188
Message-Id: <9203052228.AA16188@sword.bellcore.com>
Date: Thu, 5 Mar 92 17:28:19 EST
To: Ed Pring <pring@watson.ibm.com>
From: kaj@nvuxr.cc.bellcore.com
Subject: Re: new RFC 1233/1232
Cc: trunk-mib@acc.com

>What about a configuration such as this?

aha, the more intersting cases that you guys were talking about.
(again, i'm an ignorant in this field).

...mmmmmhhh...



>
>		             +---------------+
>		             |               |
>		             |               +--------------------
>		             |               |
>		             |               +--------------------
>	   T3 link    |  T3-to-T1     |
>	--------------+ multiplexor   +--------------------
>		             |               |  .
>		             |               |  . lots of T1 links
>		             |               |  .
>		             |               +--------------------
>		             |               |
>		             +-+-------------+
>	              		|
>	              		|management data link
>	              		|
>	              		| (to lots of multiplexors)
>		              	| | | |     |
>		              	| | | | ... |
>	              		| | | |     |
>		             +-+-+-+-+-----+-+
>		             |               |
>		             | some system   |
>		             | supporting a  |
>		             | SNMP agent    |
>		             |               |
>		             +------+--------+
>			                   |
>			                   |
>			                   |    Local Area Network
>	---------------------+---------------------------
>
>In my experience, the "management data links" of CSUs are usually
>RS-232 cables connected to serial ports on the host system, and don't
>appear in the SNMP "interfaces" table at all.

yes, thats exactly right; the config that you show is a classic
proxy situation where the agent has no part in the actual
t1 and t3 traffic. this is unlike the situation i described
earlier, where a router acted as proxy of the csu, and the t1
connected thru the csu to the router.
given that the proxy above proxies for the "lots of multiplexors",
all those muxes look like a single combined system from an snmp
perspective. your ifTable runs thru the interfaces of the
total number of muxes, and 
ifIndex=ifds1CSUIndex=ds1Index=ifds3CSUIndex=ds3Index
>
>In this case, ds1CSUIndex and ds3CSUIndex can still have arbitrary but
>unique values, but I can't think of any sensible value for ds1Index or
>ds3Index, and I think something like ds1Descr and ds3Descr are
>necessary.
>
>- Ed

your example - i assume 2 t3-to-t1 muxes (A and B), each with
1 t3 i/f, and 2 t1 i/f's (to keep it simple)

ifIndex(=all those other things)   ifType   ifDescr
1                                  ds3      "myMux A"
2                                  ds1      "myMux A"
3                                  ds1      "myMux A"
4                                  ds3      "myMux B"
5                                  ds1      "myMux B"
6                                  ds1      "myMux B"

kaj
0------------0--------------0-------------0-------------0-----------0
Kaj Tesink                            vmail (908) 758-5254
pmail Bellcore                      faxmail (908) 758-4196
      331 Newman Springs Rd.          email kaj@nvuxr.cc.bellcore.com
      Red Bank, NJ 07701











Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa02296;
          5 Mar 92 18:02 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa29177;
          5 Mar 92 18:02 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa29171; 5 Mar 92 18:02 EST
Received: from watson.ibm.com by fennel.acc.com (4.1/SMI-4.1)
	id AA17495; Thu, 5 Mar 92 14:56:53 PST
Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 2394;
   Thu, 05 Mar 92 17:56:44 EST
Received: from YKTVMH by watson.vnet.ibm.com with "VAGENT.V1.0"
          id 3870; Thu, 5 Mar 1992 17:56:48 EST
Received: from cyst.watson.ibm.com by yktvmh.watson.ibm.com (IBM VM SMTP V2R2)
   with TCP; Thu, 05 Mar 92 17:56:27 EST
Received: from patience.watson.ibm.com by cyst.watson.ibm.com (AIX 1.3/900528)
  id AA13019; Thu, 5 Mar 92 17:56:22 -0500
Received: by patience.watson.ibm.com (AIX 1.3/900524)
          id AA18903; Thu, 5 Mar 92 17:53:43 -0500
Message-Id: <9203052253.AA18903@patience.watson.ibm.com>
To: kaj@nvuxr.cc.bellcore.com
Cc: trunk-mib@acc.com
X-External-Networks: yes
Subject: Re: new RFC 1233/1232
In-Reply-To: Your message of Thu, 05 Mar 92 17:28:19 EST.
             <9203052228.AA16188@sword.bellcore.com>
Date: Thu, 05 Mar 92 17:53:43 -0500
From: Ed Pring <pring@watson.ibm.com>

Indeed.  I think that your suggestion stretches the definition
if an interface in RFC1213 a little, but I'm not uncomfortable
with it, and it does minimize the changes to RFC1232 and RFC1233
to the narrative and the DESCRIPTION clauses.

Of course, ds1CSUindex will no longer be an appropriate name.
Is it reasonable to suggest renaming an object?

- Ed










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa02350;
          5 Mar 92 19:03 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa00897;
          5 Mar 92 19:04 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa00888; 5 Mar 92 19:03 EST
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA17624; Thu, 5 Mar 92 15:59:00 PST
Return-Path: <kaj@nvuxr.cc.bellcore.com@sabre.bellcore.com>
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA26753; Thu, 5 Mar 92 18:58:45 EST
Received: by sword.bellcore.com;id 9203052359.AA17197
Message-Id: <9203052359.AA17197@sword.bellcore.com>
Date: Thu, 5 Mar 92 18:59:17 EST
To: Ed Pring <pring@watson.ibm.com>
From: kaj@nvuxr.cc.bellcore.com
Subject: Re: new RFC 1233/1232
Cc: trunk-mib@acc.com

>Indeed.  I think that your suggestion stretches the definition
>if an interface in RFC1213 a little, but I'm not uncomfortable
>with it, and it does minimize the changes to RFC1232 and RFC1233
>to the narrative and the DESCRIPTION clauses.

yep; "clarify" the ds1CSUIndex/ds3CSUIndex descriptions.
>
>Of course, ds1CSUindex will no longer be an appropriate name.
>Is it reasonable to suggest renaming an object?
>
>- Ed
i'm not sure, possibly not, in order not to inconvenience
folks who have implemented/typed in that character string.
a name change may upset those folks and may therefore be considered
undesirable. fred, any words of wisdom?

kaj
0------------0--------------0-------------0-------------0-----------0
Kaj Tesink                            vmail (908) 758-5254
pmail Bellcore                      faxmail (908) 758-4196
      331 Newman Springs Rd.          email kaj@nvuxr.cc.bellcore.com
      Red Bank, NJ 07701











Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa02374;
          5 Mar 92 19:16 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa01213;
          5 Mar 92 19:17 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa01209; 5 Mar 92 19:17 EST
Received: from nrc.com ([129.216.200.51]) by fennel.acc.com (4.1/SMI-4.1)
	id AA17684; Thu, 5 Mar 92 16:13:44 PST
Received: by nrc.com (4.0/NRC-DDN1.2)
	id AA20851; Thu, 5 Mar 92 16:10:54 PST
Date: Thu, 5 Mar 92 16:10:54 PST
From: Bill Versteeg <bvs@nrc.com>
Message-Id: <9203060010.AA20851@nrc.com>
To: kaj@nvuxr.cc.bellcore.com, pring@watson.ibm.com
Subject: Re: new RFC 1233/1232
Cc: trunk-mib@acc.com






>given that the proxy above proxies for the "lots of multiplexors",
>all those muxes look like a single combined system from an snmp
>perspective. 



Actually, this is a bit of a simplification. The proxy may see fit
to lump together N multiplexors into one system. 

Take the case of 6 racks of 10 CSUs each. Depending on the
implementation of the proxy agent, this may  be one
large system, 6 medium systems, or (heaven help us) 60
systems.

Your simplification does not effect your train of thought, but
there is an important distinction in the bigger picture. The mapping
from "interfaces" into reality is allways the weakest part
of an SNMP implementation.



Bill VerSteeg











Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa02398;
          5 Mar 92 19:37 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa01978;
          5 Mar 92 19:38 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa01974; 5 Mar 92 19:38 EST
Received: from saffron.acc.com by fennel.acc.com (4.1/SMI-4.1)
	id AA17723; Thu, 5 Mar 92 16:35:44 PST
Received: by saffron.acc.com (4.1/SMI-4.1)
	id AA22885; Thu, 5 Mar 92 16:35:04 PST
Date: Thu, 5 Mar 92 16:35:04 PST
From: Fred Baker <fbaker@acc.com>
Message-Id: <9203060035.AA22885@saffron.acc.com>
To: kaj@nvuxr.cc.bellcore.com
Subject: Re: new RFC 1233/1232
Cc: trunk-mib@acc.com

>> i'm not sure, possibly not, in order not to inconvenience folks
>> who have implemented/typed in that character string.  a name change
>> may upset those folks and may therefore be considered undesirable.
>> fred, any words of wisdom?

I have put a question in to the Area Director for Network Management
as to what is permissible in this area and what is not.

Fred










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa03547;
          6 Mar 92 16:55 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa26038;
          6 Mar 92 16:55 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa26031; 6 Mar 92 16:55 EST
Received: from watson.ibm.com by fennel.acc.com (4.1/SMI-4.1)
	id AA02674; Fri, 6 Mar 92 13:36:43 PST
Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 9494;
   Fri, 06 Mar 92 16:36:37 EST
Received: from YKTVMH by watson.vnet.ibm.com with "VAGENT.V1.0"
          id 1071; Fri, 6 Mar 1992 16:36:40 EST
Received: from cyst.watson.ibm.com by yktvmh.watson.ibm.com (IBM VM SMTP V2R2)
   with TCP; Fri, 06 Mar 92 16:36:39 EST
Received: from patience.watson.ibm.com by cyst.watson.ibm.com (AIX 1.3/900528)
  id AA20649; Fri, 6 Mar 92 16:36:36 -0500
Received: by patience.watson.ibm.com (AIX 1.3/900524)
          id AA19840; Fri, 6 Mar 92 16:33:59 -0500
Message-Id: <9203062133.AA19840@patience.watson.ibm.com>
To: Tracy Cox <tacox@sabre.bellcore.com>
Cc: trunk-mib@acc.com
X-External-Networks: yes
Subject: Re: new RFC 1233
In-Reply-To: Your message of Mon, 24 Feb 92 13:16:16 EST.
             <9202241816.AA01115@ginsu4>
Date: Fri, 06 Mar 92 16:33:59 -0500
From: Ed Pring <pring@watson.ibm.com>

The ds3 interval, current, and total tables have only one column
for Errored Seconds.  Would you consider adding Errored Second Types
A & B, according to T1M1.3/91 sections 7.3.1.2.1 and 7.3.1.2.2?

- Ed










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa01526;
          9 Mar 92 13:40 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa10315;
          9 Mar 92 13:41 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa10219;
          9 Mar 92 13:41 EST
Received: from sabre.bellcore.com by NRI.Reston.VA.US id aa10212;
          9 Mar 92 13:39 EST
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA25068; Mon, 9 Mar 92 13:39:52 EST
Return-Path: <tacox@sabre.bellcore.com>
Received: by ginsu4 (4.1/4.7)
	id AA03268; Mon, 9 Mar 92 13:39:29 EST
Date: Mon, 9 Mar 92 13:39:29 EST
From: Tracy Cox <tacox@sabre.bellcore.com>
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9203091839.AA03268@ginsu4>
To: iplpdn@nri.reston.va.us, snmp@nisc.psi.net, trunk-mib@acc.com
Subject: New SMDS Subscription MIB

Gang,

There is version 2 of the enterprise-specific
Bellcore MIB on SMDS Subscription posted
on venera.isi.edu.

An overview of the SMDS MIBs is described below;


          These objects are used in the context of a SNMP-based network
          management service that can be provided by networks supporting
          SMDS. This service is called SMDS Customer Network Management
          (CNM) Service and is defined in TA-TSV-001062. The
          service comprises access via a virtual SMDS information store
          to managed objects for the purpose of management operations by
          SMDS customers. The managed objects are maintained by the
          network supporting SMDS. Access is subject to appropriate
          authorization as defined in TA-TSV-001062. The SMDS
          information store consists of several MIB modules:

                    MIB II  for general management of TCP/IP-based
                                 Internets (System and Interface Groups only),
                    SIP MIB for the management of the SMDS Interface
                                 Protocol (SIP) RFC 1304,
                    DS1 MIB for the management of DS1 based transmission
                                 media RFC 1232 (as amended by RFC 1239),
                    DS3 MIB for the management of DS3 based transmission
                                 media RFC 1233 (as amended by RFC 1239),
                    Subscription MIB (this document) for the management of SMDS
                                 subscription parameters.

          The SMDS Customer Network Management Service is defined in
          Bellcore requirements documents TA-TSV-001062.  SMDS
          and its access protocol are defined in other Bellcore
          Requirements; TR-TSV-000772, TR-TSV-000773, and TR-TSV-001060

          In order to obtain Bellcore TA-TSV-001062 or other SMDS
          information, contact the Bellcore SMDS Hotline:

                       (908) 758-2032 (vmail)
                       smds@sabre.bellcore.com (email)

          Other Bellcore Technical Advisories can be obtained by writing
          to:

                       Bellcore
                       Information Exchange Management
                       445 South Street - Room 2J-125
                       P. O. Box 1910
                       Morristown, NJ 07960-1910
                       (201) 829-4785

          The other MIB modules that are part of the SNMP-based SMDS
          Customer Network Management Service as defined in TA-TSV-
          001062 are posted as RFCs.


If you have any questions, you can ask me.

Tracy
===========================================
Tracy A. Cox
Bellcore
NVC 1C-354
331 Newman Springs Rd.
Red Bank, NJ  07701
tacox@sabre.bellcore.com email
(908) 758-2107 vmail
(908) 758-4177 fax
===========================================










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa01532;
          9 Mar 92 13:48 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa10515;
          9 Mar 92 13:49 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa10511; 9 Mar 92 13:49 EST
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA18403; Mon, 9 Mar 92 10:44:07 PST
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA25068; Mon, 9 Mar 92 13:39:52 EST
Return-Path: <tacox@sabre.bellcore.com>
Received: by ginsu4 (4.1/4.7)
	id AA03268; Mon, 9 Mar 92 13:39:29 EST
Date: Mon, 9 Mar 92 13:39:29 EST
From: Tracy Cox <tacox@sabre.bellcore.com>
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9203091839.AA03268@ginsu4>
To: iplpdn@nri.reston.va.us, snmp@nisc.psi.net, trunk-mib@acc.com
Subject: New SMDS Subscription MIB

Gang,

There is version 2 of the enterprise-specific
Bellcore MIB on SMDS Subscription posted
on venera.isi.edu.

An overview of the SMDS MIBs is described below;


          These objects are used in the context of a SNMP-based network
          management service that can be provided by networks supporting
          SMDS. This service is called SMDS Customer Network Management
          (CNM) Service and is defined in TA-TSV-001062. The
          service comprises access via a virtual SMDS information store
          to managed objects for the purpose of management operations by
          SMDS customers. The managed objects are maintained by the
          network supporting SMDS. Access is subject to appropriate
          authorization as defined in TA-TSV-001062. The SMDS
          information store consists of several MIB modules:

                    MIB II  for general management of TCP/IP-based
                                 Internets (System and Interface Groups only),
                    SIP MIB for the management of the SMDS Interface
                                 Protocol (SIP) RFC 1304,
                    DS1 MIB for the management of DS1 based transmission
                                 media RFC 1232 (as amended by RFC 1239),
                    DS3 MIB for the management of DS3 based transmission
                                 media RFC 1233 (as amended by RFC 1239),
                    Subscription MIB (this document) for the management of SMDS
                                 subscription parameters.

          The SMDS Customer Network Management Service is defined in
          Bellcore requirements documents TA-TSV-001062.  SMDS
          and its access protocol are defined in other Bellcore
          Requirements; TR-TSV-000772, TR-TSV-000773, and TR-TSV-001060

          In order to obtain Bellcore TA-TSV-001062 or other SMDS
          information, contact the Bellcore SMDS Hotline:

                       (908) 758-2032 (vmail)
                       smds@sabre.bellcore.com (email)

          Other Bellcore Technical Advisories can be obtained by writing
          to:

                       Bellcore
                       Information Exchange Management
                       445 South Street - Room 2J-125
                       P. O. Box 1910
                       Morristown, NJ 07960-1910
                       (201) 829-4785

          The other MIB modules that are part of the SNMP-based SMDS
          Customer Network Management Service as defined in TA-TSV-
          001062 are posted as RFCs.


If you have any questions, you can ask me.

Tracy
===========================================
Tracy A. Cox
Bellcore
NVC 1C-354
331 Newman Springs Rd.
Red Bank, NJ  07701
tacox@sabre.bellcore.com email
(908) 758-2107 vmail
(908) 758-4177 fax
===========================================










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa01545;
          9 Mar 92 14:00 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa10953;
          9 Mar 92 14:01 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa10948; 9 Mar 92 14:01 EST
Received: from saffron.acc.com by fennel.acc.com (4.1/SMI-4.1)
	id AA18449; Mon, 9 Mar 92 10:57:54 PST
Received: by saffron.acc.com (4.1/SMI-4.1)
	id AA24641; Mon, 9 Mar 92 10:56:54 PST
Date: Mon, 9 Mar 92 10:56:54 PST
From: Fred Baker <fbaker@acc.com>
Message-Id: <9203091856.AA24641@saffron.acc.com>
To: kaj@nvuxr.cc.bellcore.com, pring@watson.ibm.com
Subject: Re: new RFC 1233/1232
Cc: trunk-mib@acc.com

>> Of course, ds1CSUindex will no longer be an appropriate name.
>> Is it reasonable to suggest renaming an object?

There are some definite "can dos" and some definite "can't dos" built
into ASN.1.  I went to the high priest and asked him to ask the oracle;
we can only hope she wasn't smoking anything at the time he asked :^).

What is your proposal for a new name?

Fred

>> From: "James R. (Chuck) Davin" <jrd@THYME.LCS.MIT.EDU>
>> To: fbaker@acc.com
>> Subject: OBJECT DESCRIPTORs
>> Date: Sun, 08 Mar 92 01:49:13 -0500

>> Fred,

>> A couple of days back, you sent mail asking for an opinion on whether
>> one can change the OBJECT DESCRIPTORs associated with MIB objects
>> without deprecating those objects and defining new ones.

>> So far, a majority of those directorate dentists surveyed hold the
>> view that, as a practical matter, changing OBJECT DESCRIPTORs is
>> probably ok. One pointed out that, while it is hard to find a legal
>> argument against it, changing OBJECT DESCRIPTORs may in fact break
>> some real world applications out there.

>> The advice I will offer you in this matter is that, while there may be
>> some interoperability risk, no directorate dudes who so far responded
>> voiced any adamant opposition to changing of OBJECT DESCRIPTORs as
>> MIBs are revised.

>> Probably enough to go on,
>> Chuck












Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa01594;
          9 Mar 92 14:21 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa11758;
          9 Mar 92 14:22 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa11754; 9 Mar 92 14:22 EST
Received: from watson.ibm.com by fennel.acc.com (4.1/SMI-4.1)
	id AA18549; Mon, 9 Mar 92 11:18:24 PST
Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 3054;
   Mon, 09 Mar 92 14:18:17 EST
Received: from YKTVMH by watson.vnet.ibm.com with "VAGENT.V1.0"
          id 8316; Mon, 9 Mar 1992 14:18:17 EST
Received: from cyst.watson.ibm.com by yktvmh.watson.ibm.com (IBM VM SMTP V2R2)
   with TCP; Mon, 09 Mar 92 14:18:16 EST
Received: from patience.watson.ibm.com by cyst.watson.ibm.com (AIX 1.3/900528)
  id AA14169; Mon, 9 Mar 92 14:18:15 -0500
Received: by patience.watson.ibm.com (AIX 1.3/900524)
          id AA07752; Mon, 9 Mar 92 14:15:35 -0500
Message-Id: <9203091915.AA07752@patience.watson.ibm.com>
To: Fred Baker <fbaker@acc.com>
Cc: kaj@nvuxr.cc.bellcore.com, trunk-mib@acc.com
X-External-Networks: yes
Subject: Re: new RFC 1233/1232
In-Reply-To: Your message of Mon, 09 Mar 92 10:56:54 PST.
             <9203091856.AA24641@saffron.acc.com>
Date: Mon, 09 Mar 92 14:15:34 -0500
From: Ed Pring <pring@watson.ibm.com>

Well, since Tracy originally suggested changing the emphasis in the
MIB from CSUs to interfaces, perhaps I should let her suggest a new
name.  But since you ask ...

It seems to me that from the perspective of simple, meaningful names,
the ideal change would be

	ds1CSUIndex  ------> ds1Index
	ds1Index     ------> ds1ifIndex

so that "ds1Index" becomes the unique integer assigned to each ds1
interface, used to index all of the tables in the MIB, and "ds1ifIndex"
is the value of ifIndex from the entry in the MIB-II interfaces table
that corresponds to the ds1 interface.

However, it might be undesirable to reuse the name "ds1Index".

- Ed










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa01606;
          9 Mar 92 14:43 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa12607;
          9 Mar 92 14:43 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa12599; 9 Mar 92 14:43 EST
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA18638; Mon, 9 Mar 92 11:38:59 PST
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA25693; Mon, 9 Mar 92 14:38:37 EST
Return-Path: <tacox@sabre.bellcore.com>
Received: by ginsu4 (4.1/4.7)
	id AA03369; Mon, 9 Mar 92 14:38:15 EST
Date: Mon, 9 Mar 92 14:38:15 EST
From: Tracy Cox <tacox@sabre.bellcore.com>
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9203091938.AA03369@ginsu4>
To: trunk-mib@acc.com
Subject: starting to reply to email

Ed et al,

I'm back -- spring skiing in Utah was
great -- the only problem is the tons
of email to answer and a slightly burnt
face from too much sun on the slopes.

An easy message to respond to:

Date: Fri, 06 Mar 92 16:33:59 -0500
From: Ed Pring <pring@watson.ibm.com>

The ds3 interval, current, and total tables have only one column
for Errored Seconds.  Would you consider adding Errored Second Types
A & B, according to T1M1.3/91 sections 7.3.1.2.1 and 7.3.1.2.2?

- Ed


Couldn't you figure this information out (ES type A, and ES
type B) by polling every
second on the CVs count if you found this information
necessary?

Tracy













Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa01618;
          9 Mar 92 14:53 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa12995;
          9 Mar 92 14:53 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa12991; 9 Mar 92 14:53 EST
Received: from saffron.acc.com by fennel.acc.com (4.1/SMI-4.1)
	id AA18672; Mon, 9 Mar 92 11:49:51 PST
Received: by saffron.acc.com (4.1/SMI-4.1)
	id AA24808; Mon, 9 Mar 92 11:48:08 PST
Date: Mon, 9 Mar 92 11:48:08 PST
From: Fred Baker <fbaker@acc.com>
Message-Id: <9203091948.AA24808@saffron.acc.com>
To: tacox@sabre.bellcore.com
Subject: Re:  starting to reply to email
Cc: trunk-mib@acc.com



>> Couldn't you figure this information out (ES type A, and ES type B) by
>> polling every second on the CVs count if you found this information
>> necessary?

Polling every second?  across the Internet?

Fred










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa01624;
          9 Mar 92 15:02 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa13291;
          9 Mar 92 15:03 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa13285; 9 Mar 92 15:02 EST
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA18694; Mon, 9 Mar 92 11:58:42 PST
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA25849; Mon, 9 Mar 92 14:58:18 EST
Return-Path: <tacox@ginsu4@sabre.bellcore.com>
Received: from localhost by ginsu4 (4.1/4.7)
	id AA03383; Mon, 9 Mar 92 14:57:56 EST
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9203091957.AA03383@ginsu4>
To: Fred Baker <fbaker@acc.com>
Cc: tacox@sabre.bellcore.com, trunk-mib@acc.com, dave@ginsu4.bellcore.com
Subject: Re: starting to reply to email 
In-Reply-To: Your message of "Mon, 09 Mar 92 11:48:08 PST."
             <9203091948.AA24808@saffron.acc.com> 
Date: Mon, 09 Mar 92 14:57:54 -0500
From: tacox@ginsu4.bellcore.com

Well, then is it really necessary to know how many CVs and only
CVs occurred in a one second interval?

The ES counter counts the number of seconds that had at least
one CV, a SEF event, or an AIS.

ES A counts the number of seconds that had one and only one CV.

ES B counts the number of seconds that had more than 1 but less
than x CVs. 

SES count the number of seconds that had more than or equal to x CVs,
or an SEF event, or an AIS.

A SES is also an ES, but not an ES A or ES B.
An ES A is also an ES.
An ES B is also an ES.

x=319 for DS1
x=44 for DS3

Do CSUs/T1 muxes
 really count these things?  And what would you do with this
information?


Dave -- don't you love this?!



Tracy










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa01630;
          9 Mar 92 15:05 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa13396;
          9 Mar 92 15:05 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa13391; 9 Mar 92 15:05 EST
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA18711; Mon, 9 Mar 92 12:02:13 PST
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA25882; Mon, 9 Mar 92 15:01:47 EST
Return-Path: <tacox@sabre.bellcore.com>
Received: by ginsu4 (4.1/4.7)
	id AA03390; Mon, 9 Mar 92 15:01:25 EST
Date: Mon, 9 Mar 92 15:01:25 EST
From: Tracy Cox <tacox@sabre.bellcore.com>
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9203092001.AA03390@ginsu4>
To: trunk-mib@acc.com
Subject: new names

Ed,

I like your suggestion.

But have one suggestion, if and
only if ds1Index 
should not be reused.
===================================



Well, since Tracy originally suggested changing the emphasis in the
MIB from CSUs to interfaces, perhaps I should let her suggest a new
name.  But since you ask ...

It seems to me that from the perspective of simple, meaningful names,
the ideal change would be

	ds1CSUIndex  ------> ds1Index
	ds1Index     ------> ds1ifIndex

so that "ds1Index" becomes the unique integer assigned to each ds1
interface, used to index all of the tables in the MIB, and "ds1ifIndex"
is the value of ifIndex from the entry in the MIB-II interfaces table
that corresponds to the ds1 interface.

However, it might be undesirable to reuse the name "ds1Index".

- Ed



--> maybe ds1CSUIndex -----> ds1LineIndex

--> Tracy










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa01648;
          9 Mar 92 15:26 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa14144;
          9 Mar 92 15:27 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa14140; 9 Mar 92 15:27 EST
Received: from saffron.acc.com by fennel.acc.com (4.1/SMI-4.1)
	id AA18741; Mon, 9 Mar 92 12:23:03 PST
Received: by saffron.acc.com (4.1/SMI-4.1)
	id AA25136; Mon, 9 Mar 92 12:16:23 PST
Date: Mon, 9 Mar 92 12:16:23 PST
From: Fred Baker <fbaker@acc.com>
Message-Id: <9203092016.AA25136@saffron.acc.com>
To: tacox@ginsu4.bellcore.com
Subject: Re: starting to reply to email
Cc: dave@ginsu4.bellcore.com, trunk-mib@acc.com

>> Well, then is it really necessary to know how many CVs and only
>> CVs occurred in a one second interval?

>> Do CSUs/T1 muxes really count these things?  And what would you do
>> with this information?

I am not arguing pro or con on the information requested, I'm choking
on the concept of polling once a second.

Fred










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa01709;
          9 Mar 92 16:57 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa17149;
          9 Mar 92 16:58 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa17145; 9 Mar 92 16:58 EST
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA19141; Mon, 9 Mar 92 13:51:53 PST
Return-Path: <kaj@nvuxr.cc.bellcore.com@sabre.bellcore.com>
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA26781; Mon, 9 Mar 92 16:51:28 EST
Received: by sword.bellcore.com;id 9203092151.AA04456
Message-Id: <9203092151.AA04456@sword.bellcore.com>
Date: Mon, 9 Mar 92 16:51:52 EST
To: Tracy Cox <tacox@nvuxr.cc.bellcore.com>
From: kaj@nvuxr.cc.bellcore.com
Subject: Re: new names
Cc: trunk-mib@acc.com

>But have one suggestion, if and
>only if ds1Index 
>should not be reused.
>===================================

old names should rather not be used for new purposes;
thats just asking for screwups with "old" stations.
keep the changes to a minimum, e.g.,

>--> ds1CSUIndex -----> ds1LineIndex
>--> ds1Index    -----> unchanged (or ds1ifIndex only if really needed)
>
kaj
0------------0--------------0-------------0-------------0-----------0
Kaj Tesink                            vmail (908) 758-5254
pmail Bellcore                      faxmail (908) 758-4196
      331 Newman Springs Rd.          email kaj@nvuxr.cc.bellcore.com
      Red Bank, NJ 07701











Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa01890;
          9 Mar 92 21:19 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa25509;
          9 Mar 92 21:20 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa25503; 9 Mar 92 21:20 EST
Received: from nrc.com ([129.216.200.51]) by fennel.acc.com (4.1/SMI-4.1)
	id AA19738; Mon, 9 Mar 92 18:15:35 PST
Received: by nrc.com (4.0/NRC-DDN1.2)
	id AA23980; Mon, 9 Mar 92 18:10:18 PST
Date: Mon, 9 Mar 92 18:10:18 PST
From: Bill Versteeg <bvs@nrc.com>
Message-Id: <9203100210.AA23980@nrc.com>
To: fbaker@acc.com, tacox@ginsu4.bellcore.com
Subject: Re: starting to reply to email
Cc: dave@ginsu4.bellcore.com, trunk-mib@acc.com

I have been keeping my mouth shut on this
list in deference to the T1 folks, but polling for variables once a second
is not workable in SNMP based systems for a number of reasons. 

The latency of requests can easily exceed one second. There is no time correlation between one request and another (if you want to do
time correlation, you have to get sysuptime in every query. Even this
is problematic). There are network bandwidth considerations. Consider
a low bandwidth management path (like modems or a 2400 baud in-band signal)
and large networks.


There must be a better way......



Bill VerSteeg










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa01896;
          9 Mar 92 21:25 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa25610;
          9 Mar 92 21:26 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa25606; 9 Mar 92 21:26 EST
Received: from watson.ibm.com by fennel.acc.com (4.1/SMI-4.1)
	id AB19752; Mon, 9 Mar 92 18:22:11 PST
Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 1364;
   Mon, 09 Mar 92 21:22:00 EST
Received: from YKTVMH by watson.vnet.ibm.com with "VAGENT.V1.0"
          id 0474; Mon, 9 Mar 1992 21:22:01 EST
Received: from cyst.watson.ibm.com by yktvmh.watson.ibm.com (IBM VM SMTP V2R2)
   with TCP; Mon, 09 Mar 92 21:21:59 EST
Received: from patience.watson.ibm.com by cyst.watson.ibm.com (AIX 1.3/900528)
  id AA29667; Mon, 9 Mar 92 21:21:59 -0500
Received: by patience.watson.ibm.com (AIX 1.3/900524)
          id AA12154; Mon, 9 Mar 92 21:19:20 -0500
Message-Id: <9203100219.AA12154@patience.watson.ibm.com>
To: tacox@ginsu4.bellcore.com
Cc: Fred Baker <fbaker@acc.com>, tacox@sabre.bellcore.com, trunk-mib@acc.com, 
    dave@ginsu4.bellcore.com
X-External-Networks: yes
Subject: Re: starting to reply to email
In-Reply-To: Your message of Mon, 09 Mar 92 14:57:54 EST.
             <9203091957.AA03383@ginsu4>
Date: Mon, 09 Mar 92 21:19:19 -0500
From: Ed Pring <pring@watson.ibm.com>

Actually, I have no idea what someone would do with ES-A and ES-B,
or why they are important enough to have been added to T1M1.3/91.

However, our circuit vendor considers them important enough to have
asked our CSU vendor to collect them, and they considered the request
important enough to have implemented, and I need a place in some MIB
to instantiate them.

I could put them in a private MIB, of course, but it seems like a
natural opportunity to use "optional" status in the ds3 MIB (a rather
underused choice, from all the MIBs I've worked with).

- Ed










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa01908;
          9 Mar 92 21:28 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa25660;
          9 Mar 92 21:28 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa25655; 9 Mar 92 21:28 EST
Received: from watson.ibm.com by fennel.acc.com (4.1/SMI-4.1)
	id AA19756; Mon, 9 Mar 92 18:23:30 PST
Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 1389;
   Mon, 09 Mar 92 21:23:24 EST
Received: from YKTVMH by watson.vnet.ibm.com with "VAGENT.V1.0"
          id 0482; Mon, 9 Mar 1992 21:23:26 EST
Received: from cyst.watson.ibm.com by yktvmh.watson.ibm.com (IBM VM SMTP V2R2)
   with TCP; Mon, 09 Mar 92 21:23:25 EST
Received: from patience.watson.ibm.com by cyst.watson.ibm.com (AIX 1.3/900528)
  id AA22121; Mon, 9 Mar 92 21:23:24 -0500
Received: by patience.watson.ibm.com (AIX 1.3/900524)
          id AA15748; Mon, 9 Mar 92 21:20:45 -0500
Message-Id: <9203100220.AA15748@patience.watson.ibm.com>
To: Tracy Cox <tacox@sabre.bellcore.com>
Cc: trunk-mib@acc.com
X-External-Networks: yes
Subject: Re: new names
In-Reply-To: Your message of Mon, 09 Mar 92 15:01:25 EST.
             <9203092001.AA03390@ginsu4>
Date: Mon, 09 Mar 92 21:20:45 -0500
From: Ed Pring <pring@watson.ibm.com>

Or, dare I suggest

	ds1CSUIndex ----> ds1ifIndex
        ds1Index -------> ds1Index

?

- Ed










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa24101;
          10 Mar 92 9:08 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa00609;
          10 Mar 92 9:09 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa00603; 10 Mar 92 9:09 EST
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA06219; Tue, 10 Mar 92 06:04:32 PST
Return-Path: <kaj@nvuxr.cc.bellcore.com@sabre.bellcore.com>
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA00865; Tue, 10 Mar 92 09:03:51 EST
Received: by sword.bellcore.com;id 9203101404.AA11024
Message-Id: <9203101404.AA11024@sword.bellcore.com>
Date: Tue, 10 Mar 92 09:04:08 EST
To: Ed Pring <pring@watson.ibm.com>
From: kaj@nvuxr.cc.bellcore.com
Subject: Re: new names
Cc: trunk-mib@acc.com

tracy says:
>But have one suggestion, if and
>only if ds1Index 
>should not be reused.
>===================================

ed says:
>Or, dare I suggest
>
>	ds1CSUIndex ----> ds1ifIndex
>        ds1Index -------> ds1Index


old names should rather not be used for new purposes;
thats just asking for screwups with "old" stations.
i like ed's suggestion to keep ds1Index unchanged
(keep the changes to a minimum). i would not change
ds1CSUIndex into ds1IfIndex, since it suggests
that it is ifIndex, which is not always the case.
on that one i like tracy's better.; so...

>--> ds1CSUIndex -----> ds1LineIndex
>--> ds1Index    -----> unchanged (or ds1ifIndex only if really needed)

mm?


0------------0--------------0-------------0-------------0-----------0
Kaj Tesink                            vmail (908) 758-5254
pmail Bellcore                      faxmail (908) 758-4196
      331 Newman Springs Rd.          email kaj@nvuxr.cc.bellcore.com
      Red Bank, NJ 07701











Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa24108;
          10 Mar 92 9:10 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa00869;
          10 Mar 92 9:11 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa00844; 10 Mar 92 9:11 EST
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA06222; Tue, 10 Mar 92 06:04:43 PST
Return-Path: <kaj@nvuxr.cc.bellcore.com@sabre.bellcore.com>
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA00879; Tue, 10 Mar 92 09:04:14 EST
Received: by sword.bellcore.com;id 9203101404.AA11036
Message-Id: <9203101404.AA11036@sword.bellcore.com>
Date: Tue, 10 Mar 92 09:04:22 EST
To: Ed Pring <pring@watson.ibm.com>
From: kaj@nvuxr.cc.bellcore.com
Subject: Re: starting to reply to email
Cc: trunk-mib@acc.com

>Actually, I have no idea what someone would do with ES-A and ES-B,
>or why they are important enough to have been added to T1M1.3/91.
>
>However, our circuit vendor considers them important enough to have
>asked our CSU vendor to collect them, and they considered the request
>important enough to have implemented, and I need a place in some MIB
>to instantiate them.
>
>I could put them in a private MIB, of course, but it seems like a
>natural opportunity to use "optional" status in the ds3 MIB (a rather
>underused choice, from all the MIBs I've worked with).
>
the reason that 'optional' is underused (i donot even know any
instance of its use) is that the snmp philosophy follows
largely the idea of 'smallest common denominator', i.e,
only encode in (at least standard) mibs that what everybody does.
the penalty if you dont is that soon it would be raining
pet-objects, and the resulting mib would loose in credibility
and implementability/interoperability. sofar, pet-objects usually ended
up in private mib modules which of course is always appropriate as you
point out.

in the case of ES-A and ES-B, if nobody knows why they're there
(standard committees are very good in "compromising"...)
my suggestion is to hold off on it wrt the mib until we do know.
0------------0--------------0-------------0-------------0-----------0
Kaj Tesink                            vmail (908) 758-5254
pmail Bellcore                      faxmail (908) 758-4196
      331 Newman Springs Rd.          email kaj@nvuxr.cc.bellcore.com
      Red Bank, NJ 07701











Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa24126;
          10 Mar 92 9:21 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa02440;
          10 Mar 92 9:22 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa02421; 10 Mar 92 9:21 EST
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA06203; Tue, 10 Mar 92 05:54:34 PST
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA00743; Tue, 10 Mar 92 08:54:09 EST
Return-Path: <tacox@ginsu4@sabre.bellcore.com>
Received: from localhost by ginsu4 (4.1/4.7)
	id AA03618; Tue, 10 Mar 92 08:53:48 EST
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9203101353.AA03618@ginsu4>
To: Ed Pring <pring@watson.ibm.com>
Cc: trunk-mib@acc.com
Subject: Re: new names 
In-Reply-To: Your message of "Mon, 09 Mar 92 21:20:45 EST."
             <9203100220.AA15748@patience.watson.ibm.com> 
Date: Tue, 10 Mar 92 08:53:47 -0500
From: tacox@ginsu4.bellcore.com

> 
> 
> Or, dare I suggest
> 
> 	ds1CSUIndex ----> ds1ifIndex
>         ds1Index -------> ds1Index
> 
> ?
> 
> - Ed


Sounds good to me.
Everyone else agree?

Tracy










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa24132;
          10 Mar 92 9:22 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa02542;
          10 Mar 92 9:23 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa02523; 10 Mar 92 9:23 EST
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA06188; Tue, 10 Mar 92 05:50:13 PST
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA00695; Tue, 10 Mar 92 08:49:49 EST
Return-Path: <tacox@ginsu4@sabre.bellcore.com>
Received: from localhost by ginsu4 (4.1/4.7)
	id AA03595; Tue, 10 Mar 92 08:49:29 EST
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9203101349.AA03595@ginsu4>
To: Bill Versteeg <bvs@nrc.com>
Cc: fbaker@acc.com, dave@ginsu4.bellcore.com, trunk-mib@acc.com
Subject: Re: starting to reply to email 
In-Reply-To: Your message of "Mon, 09 Mar 92 18:10:18 PST."
             <9203100210.AA23980@nrc.com> 
Date: Tue, 10 Mar 92 08:49:28 -0500
From: tacox@ginsu4.bellcore.com

Okay Guys -- I was kidding about polling every second.

The point of my second message about all the errorred second
counts - type A, B, and Severely -- was that -- don't
we already count enough things!!!!  What is a NMS going
to do with all this information?!

If you really want it -- it is absolutely NO problem to add
it, but let's think about it before we do. 

Do we need those two additional errorred second counts?

Tracy










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa24138;
          10 Mar 92 9:22 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa02601;
          10 Mar 92 9:23 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa02585; 10 Mar 92 9:23 EST
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA06194; Tue, 10 Mar 92 05:53:08 PST
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA00732; Tue, 10 Mar 92 08:52:44 EST
Return-Path: <tacox@ginsu4@sabre.bellcore.com>
Received: from localhost by ginsu4 (4.1/4.7)
	id AA03607; Tue, 10 Mar 92 08:52:25 EST
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9203101352.AA03607@ginsu4>
To: Ed Pring <pring@watson.ibm.com>
Cc: Fred Baker <fbaker@acc.com>, trunk-mib@acc.com
Subject: Re: starting to reply to email 
In-Reply-To: Your message of "Mon, 09 Mar 92 21:19:19 EST."
             <9203100219.AA12154@patience.watson.ibm.com> 
Date: Tue, 10 Mar 92 08:52:24 -0500
From: tacox@ginsu4.bellcore.com

> 
> 
> Actually, I have no idea what someone would do with ES-A and ES-B,
> or why they are important enough to have been added to T1M1.3/91.
> 
> However, our circuit vendor considers them important enough to have
> asked our CSU vendor to collect them, and they considered the request
> important enough to have implemented, and I need a place in some MIB
> to instantiate them.
> 
> I could put them in a private MIB, of course, but it seems like a
> natural opportunity to use "optional" status in the ds3 MIB (a rather
> underused choice, from all the MIBs I've worked with).
> 
> - Ed


Okay -- we can add them, but we can not add optional objects
in a table that is mandatory.  We have to create an optional
table for those two optional counts.
SNMP gurus -- is this correct?

Tracy










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa24186;
          10 Mar 92 9:42 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa04134;
          10 Mar 92 9:43 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa04123; 10 Mar 92 9:43 EST
Received: from watson.ibm.com by fennel.acc.com (4.1/SMI-4.1)
	id AB06251; Tue, 10 Mar 92 06:35:21 PST
Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 6229;
   Tue, 10 Mar 92 09:35:14 EST
Received: from YKTVMH by watson.vnet.ibm.com with "VAGENT.V1.0"
          id 1725; Tue, 10 Mar 1992 09:35:15 EST
Received: from cyst.watson.ibm.com by yktvmh.watson.ibm.com (IBM VM SMTP V2R2)
   with TCP; Tue, 10 Mar 92 09:35:14 EST
Received: from patience.watson.ibm.com by cyst.watson.ibm.com (AIX 1.3/900528)
  id AA30961; Tue, 10 Mar 92 09:35:12 -0500
Received: by patience.watson.ibm.com (AIX 1.3/900524)
          id AA08051; Tue, 10 Mar 92 09:35:11 -0500
Message-Id: <9203101435.AA08051@patience.watson.ibm.com>
To: tacox@ginsu4.bellcore.com
Cc: Fred Baker <fbaker@acc.com>, trunk-mib@acc.com
X-External-Networks: yes
Subject: Re: starting to reply to email
In-Reply-To: Your message of Tue, 10 Mar 92 08:52:24 EST.
             <9203101352.AA03607@ginsu4>
Date: Tue, 10 Mar 92 09:35:11 -0500
From: Ed Pring <pring@watson.ibm.com>

I don't think ES-A and ES-B are worth three new tables.  I'd
prefer just to add two new columns to the existing tables.

I'm not sure I understand Kaj's comments about 'optional' status.
I've never seen an instance of its use either, but I have seen
agents which implement a subset of a MIB.  When instrumentation
doesn't exist for some objects, the implementor doesn't have any
other choice.

I do understand the design objective of defining minimal MIBs.
However, some of the more recent MIBs that have appeared in RFC
form seem to have strayed from this objective.  Philosophically,
I don't think its wrong to reserve space in a MIB for information
that may not be available in all implementations.

- Ed










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa24188;
          10 Mar 92 9:42 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa04133;
          10 Mar 92 9:43 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa04117; 10 Mar 92 9:43 EST
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA06256; Tue, 10 Mar 92 06:35:48 PST
Return-Path: <kaj@nvuxr.cc.bellcore.com@sabre.bellcore.com>
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA01194; Tue, 10 Mar 92 09:35:24 EST
Received: by sword.bellcore.com;id 9203101435.AA12027
Message-Id: <9203101435.AA12027@sword.bellcore.com>
Date: Tue, 10 Mar 92 09:35:14 EST
To: tacox@ginsu4.bellcore.com
From: kaj@nvuxr.cc.bellcore.com
Subject: Re: starting to reply to email
Cc: trunk-mib@acc.com

>
>Okay -- we can add them, but we can not add optional objects
>in a table that is mandatory.  We have to create an optional
>table for those two optional counts.
>SNMP gurus -- is this correct?
>
i think so, but see my previous mail
0------------0--------------0-------------0-------------0-----------0
Kaj Tesink                            vmail (908) 758-5254
pmail Bellcore                      faxmail (908) 758-4196
      331 Newman Springs Rd.          email kaj@nvuxr.cc.bellcore.com
      Red Bank, NJ 07701











Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa24210;
          10 Mar 92 9:56 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa05114;
          10 Mar 92 9:56 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa05107; 10 Mar 92 9:56 EST
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA06267; Tue, 10 Mar 92 06:52:42 PST
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA01447; Tue, 10 Mar 92 09:52:17 EST
Return-Path: <tacox@ginsu4@sabre.bellcore.com>
Received: from localhost by ginsu4 (4.1/4.7)
	id AA03685; Tue, 10 Mar 92 09:51:58 EST
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9203101451.AA03685@ginsu4>
To: Ed Pring <pring@watson.ibm.com>
Cc: Fred Baker <fbaker@acc.com>, trunk-mib@acc.com
Subject: Re: starting to reply to email 
In-Reply-To: Your message of "Tue, 10 Mar 92 09:35:11 EST."
             <9203101435.AA08051@patience.watson.ibm.com> 
Date: Tue, 10 Mar 92 09:51:56 -0500
From: tacox@ginsu4.bellcore.com


Ed,

The point is -- I do not think you can add optional objects
into a mandatory table.


>I don't think ES-A and ES-B are worth three new tables.  I'd
>prefer just to add two new columns to the existing tables.

We will be forced to add them into three new optional tables --
or to make them mandatory -- aren't they optional in T1M1.3?

There are also SEF/AIS Seconds and AIS Seconds defined in T1M1.
I was trying to include a reasonable subset of all these peformance
counts.  should we bite the bullet and include them all?  Or is a
subset of these counts reasonable, and other products may include
more counters in a product-specific mib?

Tracy










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa24216;
          10 Mar 92 9:59 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa05321;
          10 Mar 92 10:00 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa05308;
          10 Mar 92 10:00 EST
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA06272; Tue, 10 Mar 92 06:53:46 PST
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA01458; Tue, 10 Mar 92 09:53:22 EST
Return-Path: <tacox@ginsu4@sabre.bellcore.com>
Received: from localhost by ginsu4 (4.1/4.7)
	id AA03692; Tue, 10 Mar 92 09:53:03 EST
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9203101453.AA03692@ginsu4>
To: kaj@nvuxr.cc.bellcore.com
Cc: Ed Pring <pring@watson.ibm.com>, trunk-mib@acc.com
Subject: Re: new names 
In-Reply-To: Your message of "Tue, 10 Mar 92 09:04:08 EST."
             <9203101404.AA11024@sword.bellcore.com> 
Date: Tue, 10 Mar 92 09:53:02 -0500
From: tacox@ginsu4.bellcore.com

>--> ds1CSUIndex -----> ds1LineIndex
>--> ds1Index    -----> unchanged (or ds1ifIndex only if really needed)

What does everyone think of this -- sounds good to me.
Tracy










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa24349;
          10 Mar 92 11:02 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa07836;
          10 Mar 92 11:03 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa07828;
          10 Mar 92 11:03 EST
Received: from thumper.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA06343; Tue, 10 Mar 92 07:59:28 PST
Received: from jeff.bellcore.com by thumper.bellcore.com (4.1/4.7)
	id <AA13644> for trunk-mib@acc.com; Tue, 10 Mar 92 10:59:26 EST
Received: from localhost.bellcore.com by jeff.bellcore.com (4.1/4.7)
	id <AA02129> for trunk-mib@acc.com; Tue, 10 Mar 92 10:59:24 EST
Message-Id: <9203101559.AA02129@jeff.bellcore.com>
To: kaj@nvuxr.cc.bellcore.com
Cc: Ed Pring <pring@watson.ibm.com>, trunk-mib@acc.com
Subject: Re: new names 
In-Reply-To: Your message of Tue, 10 Mar 92 09:04:08 -0500.
             <9203101404.AA11024@sword.bellcore.com> 
Date: Tue, 10 Mar 92 10:59:23 -0500
From: tob@jeff.bellcore.com



>old names should rather not be used for new purposes;
>thats just asking for screwups with "old" stations.
>i like ed's suggestion to keep ds1Index unchanged
>(keep the changes to a minimum). i would not change
>ds1CSUIndex into ds1IfIndex, since it suggests
>that it is ifIndex, which is not always the case.
>on that one i like tracy's better.; so...
>
>>--> ds1CSUIndex -----> ds1LineIndex
>>--> ds1Index    -----> unchanged (or ds1ifIndex only if really needed)

I agree

Ted Brunner			Bellcore 
tob@thumper.bellcore.com	MRE 2P-252 
201/829-4678			445 South St.
				Morristown NJ 07960-1910 











Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa24391;
          10 Mar 92 11:25 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa08666;
          10 Mar 92 11:26 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa08661;
          10 Mar 92 11:26 EST
Received: from interlan.interlan.com ([130.204.8.1]) by fennel.acc.com (4.1/SMI-4.1)
	id AA06402; Tue, 10 Mar 92 08:21:20 PST
Received: by interlan.interlan.com (5.65/1.35)
	id AA26887; Tue, 10 Mar 92 11:20:43 -0500
Date: Tue, 10 Mar 92 11:20:43 -0500
From: Moe Turcotte <dnmrt@interlan.interlan.com>
Message-Id: <9203101620.AA26887@interlan.interlan.com>
To: pring@watson.ibm.com, tacox@ginsu4.bellcore.com
Subject: Re: starting to reply to email
Cc: fbaker@acc.com, trunk-mib@acc.com

From pring@watson.ibm.com Tue Mar 10 09:44:12 1992
Received: from FENNEL.ACC.COM by interlan.interlan.com (5.65/1.35)
	id AA24338; Tue, 10 Mar 92 09:44:02 -0500
Received: from watson.ibm.com by fennel.acc.com (4.1/SMI-4.1)
	id AB06251; Tue, 10 Mar 92 06:35:21 PST
Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 6229;
   Tue, 10 Mar 92 09:35:14 EST
Received: from YKTVMH by watson.vnet.ibm.com with "VAGENT.V1.0"
          id 1725; Tue, 10 Mar 1992 09:35:15 EST
Received: from cyst.watson.ibm.com by yktvmh.watson.ibm.com (IBM VM SMTP V2R2)
   with TCP; Tue, 10 Mar 92 09:35:14 EST
Received: from patience.watson.ibm.com by cyst.watson.ibm.com (AIX 1.3/900528)
  id AA30961; Tue, 10 Mar 92 09:35:12 -0500
Received: by patience.watson.ibm.com (AIX 1.3/900524)
          id AA08051; Tue, 10 Mar 92 09:35:11 -0500
Message-Id: <9203101435.AA08051@patience.watson.ibm.com>
To: tacox@ginsu4.bellcore.com
Cc: fbaker@acc.com (Fred Baker), trunk-mib@acc.com
X-External-Networks: yes
Subject: Re: starting to reply to email
In-Reply-To: Your message of Tue, 10 Mar 92 08:52:24 EST.
             <9203101352.AA03607@ginsu4>
Date: Tue, 10 Mar 92 09:35:11 -0500
From: Ed Pring <pring@watson.ibm.com>
Status: R

I don't think ES-A and ES-B are worth three new tables.  I'd
prefer just to add two new columns to the existing tables.

I'm not sure I understand Kaj's comments about 'optional' status.
I've never seen an instance of its use either, but I have seen
agents which implement a subset of a MIB.  When instrumentation
doesn't exist for some objects, the implementor doesn't have any
other choice.

I do understand the design objective of defining minimal MIBs.
However, some of the more recent MIBs that have appeared in RFC
form seem to have strayed from this objective.  Philosophically,
I don't think its wrong to reserve space in a MIB for information
that may not be available in all implementations.

- Ed


This issue of mandatory variables that are zero if not supported by the
implementation has been a real problem in other groups, notably the
Ethernet MIB. The word from the SNMP digerati was that allowing an
agent to return a zero value, where zero has a meaning like "none of
these errors occurred", when in fact some errors occurred is a very
bad thing to do. Noting that the ability of the hardware to support
certain variables could be determined from another variable, was not
good enough to overcome the objections.

Of course, you can make the variables mandatory, adn then the issue is
whether avendor can in good conscience make the claim that it supports
the MIB, when it always returns zero for some variables. There has
been a precedence for this sort of foolishness.

From a purely SNMP point-of-view, I would say that if there is
any doubt of the implementability of a variable, it must be demonstrated
to be very useful before including it in a MIB, and that vendors that
wish to comply with the MIB should find a way to implement it. 

If you decide to include the variable(s) and want to make it(them) optional,
palce them in a new table that is optional. The problem here then is that
a vendor cannot pick and choose from the new table. It's all or nothing.

Let me sufface this with the point that I have not implemented this MIB
and have no plans to do so. I am an SNMP person.


Maurice R. Turcotte

dnmrt@interlan.com











Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa24451;
          10 Mar 92 11:38 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa09164;
          10 Mar 92 11:38 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa09160;
          10 Mar 92 11:38 EST
Received: from saffron.acc.com by fennel.acc.com (4.1/SMI-4.1)
	id AA06434; Tue, 10 Mar 92 08:34:10 PST
Received: by saffron.acc.com (4.1/SMI-4.1)
	id AA28749; Tue, 10 Mar 92 08:32:22 PST
Date: Tue, 10 Mar 92 08:32:22 PST
From: Fred Baker <fbaker@acc.com>
Message-Id: <9203101632.AA28749@saffron.acc.com>
To: pring@watson.ibm.com
Subject: Re: starting to reply to email
Cc: dave@ginsu4.bellcore.com, tacox@ginsu4.bellcore.com, trunk-mib@acc.com

>> Actually, I have no idea what someone would do with ES-A and ES-B,
>> or why they are important enough to have been added to T1M1.3/91.

>> However, our circuit vendor considers them important enough to have
>> asked our CSU vendor to collect them, and they considered the request
>> important enough to have implemented, and I need a place in some MIB
>> to instantiate them.

Maybe you could put the question to them, so we can get an answer from
"the Horse's Mouth", as it were?

>> I could put them in a private MIB, of course, but it seems like a
>> natural opportunity to use "optional" status in the ds3 MIB (a rather
>> underused choice, from all the MIBs I've worked with).

The level of optionality in SNMP is the Group; one need not implement a
group, but if one does, one is to implement all the variables in it.
This is for the purpose of making a guarantee to the NMS.  The NMS
would like to know the minimum set of variables that it can access, and
build an application that will manage all devices implementing a given
MIB.  If the devices subset, then the NMS has to understand differences
between devices, and becomes far more complex.

The general feeling in the SNMP community (and I've had it preached to
me often enough that I think I can fairly state it) is that variables
should not be designed in except for very good reasons.  The following
guidelines are recommended for use in variable selection (I'm quoting
from RFC 1286, which also implements a MIB borrowed from a different
organization):


   To be consistent with IAB directives and good engineering practice,
   an explicit attempt was made to keep this MIB as simple as possible.
   This was accomplished by applying the following criteria to objects
   proposed for inclusion:
 
      (1)  Start with a small set of essential objects and add only
           as further objects are needed.
 
      (2)  Require objects be essential for either fault or
           configuration management.
 
      (3)  Consider evidence of current use and/or utility.
 
      (4)  Limit the total of objects.
 
      (5)  Exclude objects which are simply derivable from others in
           this or other MIBs.
 
      (6)  Avoid causing critical sections to be heavily
           instrumented.  The guideline that was followed is one
           counter per critical section per layer.
 

It seems that this debate is in the realms of bullets 2, 3, and 6.  If
I am seeing high Errored Second Rates, and perhaps SESs, it seems to me
that knowing the number of them more accurately isn't going to help fix
the link; I need to find some cross-talking wires or a broken
connection somewhere; I'm not going to avoid a service call.

And, frankly, the fact that someone else has a reason to know a certain
datum is not a reason for me to know it; if we are going to include it
in the MIB, *I* would like to hear the rationale.  That's not to set
myself up as a judge of some sort, but if it is so very important, it
seems that SOMEONE should be able to state the cause.

Fred










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa24457;
          10 Mar 92 11:40 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa09266;
          10 Mar 92 11:41 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa09252;
          10 Mar 92 11:41 EST
Received: from saffron.acc.com by fennel.acc.com (4.1/SMI-4.1)
	id AA06444; Tue, 10 Mar 92 08:37:25 PST
Received: by saffron.acc.com (4.1/SMI-4.1)
	id AA28753; Tue, 10 Mar 92 08:35:30 PST
Date: Tue, 10 Mar 92 08:35:30 PST
From: Fred Baker <fbaker@acc.com>
Message-Id: <9203101635.AA28753@saffron.acc.com>
To: kaj@nvuxr.cc.bellcore.com, tacox@ginsu4.bellcore.com
Subject: Re: new names
Cc: pring@watson.ibm.com, trunk-mib@acc.com

>> >--> ds1CSUIndex -----> ds1LineIndex
>> >--> ds1Index    -----> unchanged 
>> 
>> What does everyone think of this -- sounds good to me.

I think that balloon flies

Fred










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa24475;
          10 Mar 92 11:51 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa09708;
          10 Mar 92 11:52 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa09701;
          10 Mar 92 11:51 EST
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA06470; Tue, 10 Mar 92 08:47:43 PST
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA02768; Tue, 10 Mar 92 11:47:16 EST
Return-Path: <tacox@ginsu4@sabre.bellcore.com>
Received: from localhost by ginsu4 (4.1/4.7)
	id AA03772; Tue, 10 Mar 92 11:46:58 EST
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9203101646.AA03772@ginsu4>
To: Fred Baker <fbaker@acc.com>
Cc: kaj@nvuxr.cc.bellcore.com, pring@watson.ibm.com, trunk-mib@acc.com
Subject: Re: new names 
In-Reply-To: Your message of "Tue, 10 Mar 92 08:35:30 PST."
             <9203101635.AA28753@saffron.acc.com> 
Date: Tue, 10 Mar 92 11:46:56 -0500
From: tacox@ginsu4.bellcore.com

Therefore, we are removing any mention of CSUs from the MIB
and only talking about DS1 (or DS3) Lines -- Right?

Tracy










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa24650;
          10 Mar 92 15:09 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa18025;
          10 Mar 92 15:10 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa18019;
          10 Mar 92 15:10 EST
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA07010; Tue, 10 Mar 92 12:01:56 PST
Return-Path: <dave@sword.bellcore.com@sabre.bellcore.com>
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA04889; Tue, 10 Mar 92 15:01:18 EST
Received: by sword.bellcore.com;id 9203102001.AA23012
Message-Id: <9203102001.AA23012@sword.bellcore.com>
Date: Tue, 10 Mar 92 15:01:26 EST
From: Dave Piscitello <dave@sword.bellcore.com>
To: fbaker@acc.com, tacox@ginsu4.bellcore.com
Subject: Re: starting to reply to email
Cc: dave@ginsu4.bellcore.com, trunk-mib@acc.com

re: choking on the concept of polling once a second

	since our service objectives in SMDS SNMP agent don't come
	close to promising data currency at the granularity of 1 
	second, I'm not sure choking describes the discomfort
	accurately:-)










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa04186;
          11 Mar 92 10:32 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa10250;
          11 Mar 92 10:33 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa10244;
          11 Mar 92 10:33 EST
Received: from watson.ibm.com by fennel.acc.com (4.1/SMI-4.1)
	id AA25246; Wed, 11 Mar 92 07:29:03 PST
Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 7009;
   Wed, 11 Mar 92 10:28:57 EST
Received: from YKTVMH by watson.vnet.ibm.com with "VAGENT.V1.0"
          id 8649; Wed, 11 Mar 1992 10:28:56 EST
Received: from cyst.watson.ibm.com by yktvmh.watson.ibm.com (IBM VM SMTP V2R2)
   with TCP; Wed, 11 Mar 92 10:28:55 EST
Received: from patience.watson.ibm.com by cyst.watson.ibm.com (AIX 1.3/900528)
  id AA29798; Wed, 11 Mar 92 10:28:53 -0500
Received: by patience.watson.ibm.com (AIX 1.3/900524)
          id AA09029; Wed, 11 Mar 92 10:28:51 -0500
Message-Id: <9203111528.AA09029@patience.watson.ibm.com>
To: Fred Baker <fbaker@acc.com>
Cc: dave@ginsu4.bellcore.com, tacox@ginsu4.bellcore.com, trunk-mib@acc.com
X-External-Networks: yes
Subject: Re: starting to reply to email
In-Reply-To: Your message of Tue, 10 Mar 92 08:32:22 PST.
             <9203101632.AA28749@saffron.acc.com>
Date: Wed, 11 Mar 92 10:28:50 -0500
From: Ed Pring <pring@watson.ibm.com>

That's a very reasonable request.  I've asked our circuit
vendor to provide some input to this discussion.

- Ed










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa04216;
          11 Mar 92 10:55 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa11241;
          11 Mar 92 10:56 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa11234;
          11 Mar 92 10:56 EST
Received: from watson.ibm.com by fennel.acc.com (4.1/SMI-4.1)
	id AB25289; Wed, 11 Mar 92 07:52:28 PST
Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 7059;
   Wed, 11 Mar 92 10:29:45 EST
Received: from YKTVMH by watson.vnet.ibm.com with "VAGENT.V1.0"
          id 8661; Wed, 11 Mar 1992 10:29:44 EST
Received: from cyst.watson.ibm.com by yktvmh.watson.ibm.com (IBM VM SMTP V2R2)
   with TCP; Wed, 11 Mar 92 10:29:42 EST
Received: from patience.watson.ibm.com by cyst.watson.ibm.com (AIX 1.3/900528)
  id AA29545; Wed, 11 Mar 92 10:29:39 -0500
Received: by patience.watson.ibm.com (AIX 1.3/900524)
          id AA09807; Wed, 11 Mar 92 10:29:37 -0500
Message-Id: <9203111529.AA09807@patience.watson.ibm.com>
To: tacox@ginsu4.bellcore.com
Cc: Fred Baker <fbaker@acc.com>, kaj@nvuxr.cc.bellcore.com, 
    trunk-mib@acc.com
X-External-Networks: yes
Subject: Re: new names
In-Reply-To: Your message of Tue, 10 Mar 92 11:46:56 EST.
             <9203101646.AA03772@ginsu4>
Date: Wed, 11 Mar 92 10:29:36 -0500
From: Ed Pring <pring@watson.ibm.com>

I think "lines" for "CSUs" is a reasonable trade.

- Ed










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa04524;
          11 Mar 92 16:18 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa25689;
          11 Mar 92 16:19 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa25679;
          11 Mar 92 16:19 EST
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA26157; Wed, 11 Mar 92 12:56:30 PST
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA14855; Wed, 11 Mar 92 15:55:09 EST
Return-Path: <tacox@sabre.bellcore.com>
Received: by ginsu4 (4.1/4.7)
	id AA04516; Wed, 11 Mar 92 15:54:55 EST
Date: Wed, 11 Mar 92 15:54:55 EST
From: Tracy Cox <tacox@sabre.bellcore.com>
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9203112054.AA04516@ginsu4>
To: trunk-mib@acc.com
Subject: RFC1233 -- proposed draft

Gang,

This draft of RFC1233 will be discussed
at the trunk-mib working group.  Please
review and come to the meeting with your
feedback.  Thanks.

Especially review:

-- ds1LineIndex text
-- new configuration information
-- new far end counters
-- new alarmState object
-- loopback stuff
-- deprecation of objects done correctly?
-- optional tables done correctly?


Tracy
==========================================






Network Working Group                                            T. Cox
Request for Comments: 1233                                    K. Tesink
Updated Version 2.0                        Bell Communications Research
                                                                Editors
                                                             March 1992


                     Definitions of Managed Objects
                       for the DS3 Interface Type
                                Version 2.0


Status of this Memo

   This memo defines objects for managing DS3 Interface objects for use
   with the SNMP protocol.  This memo is a product of the SNMP and
   Transmission MIB Working Group of the Internet Engineering Task Force
   (IETF).  This RFC specifies an IAB standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "IAB
   Official Protocol Standards" for the standardization state and status
   of this protocol.  Distribution of this memo is unlimited.

Table of Contents

   1. Abstract ..............................................    1
   2. The Network Management Framework.......................    2
   3. Objects ...............................................    2
   3.1 Format of Definitions ................................    3
   3.2 Changes from Version 1.0 .............................    3
   4. Overview ..............................................    3
   4.1 Binding between ifIndex and DS1 Interfaces ...........    4
   4.2 Objectives of this MIB Module ........................    4
   4.3 DS3 Terminology ......................................    4
   5. Object Definitions ....................................    7
   5.1 The DS3 Configuration Group ..........................    7
   5.2 The DS3 Interval Group ...............................   16
   5.3 The DS3 Current Group ................................   20
   5.4 The DS3 Total Group ..................................   23
   5.5 The DS3 Far End Configuration Group ..................   26
   5.6 The DS3 Far End Interval Group .......................   29
   5.7 The DS3 Far End Current Group ........................   32
   5.8 The DS3 Far End Total Group ..........................   34
   6. Acknowledgments .......................................   36
   7. References ............................................   37
   8. Security Considerations................................   38
   9. Authors' Addresses.....................................   38

1.  Abstract

   This memo defines an experimental portion of the Management
   Information Base (MIB) for use with network management protocols in
   TCP/IP-based internets.  In particular, this memo defines MIB objects
   for representing DS3 physical interfaces.  Implementors should
   consult in addition to this memo the companion document that



SNMP & Transmission MIB Working Groups                          [Page 1]

RFC 1233                 DS3 Interface Objects                  March 1992


   describes that DS1 managed objects.

2.  The Network Management Framework

   The Internet-standard Network Management Framework consists of three
   components.  They are:

      RFC 1155 which defines the SMI, the mechanisms used for describing
      and naming objects for the purpose of management.  RFC 1212
      defines a more concise description mechanism, which is wholly
      consistent with the SMI.

      RFC 1156 which defines MIB-I, the core set of managed objects for
      the Internet suite of protocols.  RFC 1213, defines MIB-II, an
      evolution of MIB-I based on implementation experience and new
      operational requirements.

      RFC 1157 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.

3.  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) [7]
   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 [3] 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 [8], subject
   to the additional requirements imposed by the SNMP.



SNMP & Transmission MIB Working Groups                          [Page 2]

RFC 1233                 DS3 Interface Objects                  March 1992


3.1.  Format of Definitions

   Section 5 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 RFC 1212 [13].

3.2.  Changes from Version 1.0

   In order to better prepare implementors for future changes in the
   DS3 MIB, a new term "deprecated" may be used when describing an object.
   A deprecated object in the MIB is one which must be supported, but
   one which will most likely be removed from the next version of the
   DS3 MIB . -- THIS IS REALLY NOT WHAT I WANT! I WOULD LIKE TO DELETE
   THESE OBJECTS IN THIS VERSION?
   HOW DO I DO THAT -- OR CAN I?

   I would like to delete the loopback object, the yellow alarm object,
   and the red alarm object and replace the three of them with two
   different objects:  ds3NewLoopback and ds3AlarmState.
   This change is facilitated by comments on implementations.

   Also, the ds3SendCode is confusing -- the ds3SendLoopbackCode really
   does not do anything -- what is it supposed to do?

   I also added ds3IntervalOtherCVs (Current and Total also) to handle
   C-Bit Parity and SYNTRAN coding violations.
   This change is to be consistent with T1M1 standards.

   I changed the bindings between ifIndexes and ds1 interfaces -- PLEASE READ THAT
   SECTION.  This change is facilitated by comments on implementations.



4.  Overview

   These objects are used when the particular media being used to
   realize an interface is a DS3 interface.  At present, this applies to
   these values of the ifType variable in the Internet-standard MIB:

               ds3 (30)

   The definitions contained herein are based on the DS3 specifications
   in ANSI T1.102-1987, ANSI T1.107-1988,, ANSI T1-107a-1990, and ANSI T1.404-1989
   [9,10,10a,11].


SNMP & Transmission MIB Working Groups                          [Page 3]

RFC 1233                 DS3 Interface Objects                  March 1992
   

4.1.  Binding between ifIndex and DS1 Interfaces

   Each agent which resides on a host which uses DS3 interfaces is
   required to assign a small, positive integer uniquely to each DS3 
   interface located on the device.
   This is known as the "LineIndex", and is used to distinguish between
   different interfaces on the
   devices attached to a node.  The LineIndex is also used as the
   "key" when accessing tabular information about DS3 interfaces.

   The ds3Index column of the DS3 Configuration table relates each ifIndex
   on the device to the interfaces table
   in the Internet-standard MIB.

4.2.  Objectives of this MIB Module

   There are numerous things that could be included in a MIB for DS3
   signals: the management of multiplexors, CSUs, DSUs, and the like.
   The intent of this document is to facilitate the common management of
   DS3 interfaces of devices, both in-chassis and external via proxy.
   As such, a design
   decision was made up front to very closely align the MIB with the set
   of objects that can generally be read from DS3 devices that are currently
   deployed.

4.3.  DS3 Terminology

   The terminology used in this document to describe error conditions on
   a DS3 circuit as monitored by a DS3 device are from the ANSI T1M1.3/91-003R3
   draft standard [12].

          Bipolar Violation (BPV)
               A bipolar violation, for B3ZS-coded signals, is the
               occurrence of a received bipolar violation that is not
               part of a zero-substitution code.  For B3ZS-coded
               signals, a bipolar violation may also include other error
               patterns such as:  three or more consecutive zeros and
               incorrect polarity.


SNMP & Transmission MIB Working Groups                          [Page 4]

RFC 1233                 DS3 Interface Objects                  March 1992


          Coding Violation (CV)
               For all DS3 applications, a coding violation is a P-bit
               Parity Error event.  A P-bit Parity Error event is the
               occurrence of a received P-bit code on the DS3 M-frame
               that is not identical to the corresponding locally-
               calculated code.  For C-Bit Parity applications, it is
               also the occurrence of a received CP-Bit parity
               violation.  For SYNTRAN applications, it is also the
               occurrence of a received CRC-9 code that is not identical
               to the corresponding locally calculated code.
               Two coding violation counters are used.  The first one
               is used by all DS3 applications
               for just the P-bit Parity Error Event.  The second CV
               counter counts the CP-Bit Parity violations for C-Bit
               Parity applications or the CRC-9 code violations for
               SYNTRAN applications.

          Errored Seconds (ES)
               An ES is a second with one or more Coding Violation OR
               one or more Out of Frame events OR a detected incoming AIS.

          Severely Errored Seconds (SES)
               A SES is a second with 44 or more Coding Violations OR
               one or more Out of Frame events OR a detected incoming AIS.

          Severely Errored Framing Seconds (SEFS)
               A SEFS is a second with one or more Out of Frame events.

          Unavailable Seconds (UAS)
               UAS are calculated by counting the number of seconds that
               the device is in the Unavailable signal state (i.e.,
               declared a Red Alarm or a Yellow Alarm), including the
               initial 10 seconds to enter the state but not including
               the 10 seconds to exit the state.

               Note that any second that may be counted as an UAS may
               not be counted as an ES or a SES.  Since the 10 SESs that
               comprise the transition from the available to unavailable
               signal state may also be counted as ESs and SESs previous
               to entering the state, these three counters are adjusted
               so that any second counted during this transition is then
               subtracted.  The 10 seconds in the transition from
               unavailable to available may be counted as ESs.
            
               A special case exists when the 10 or more second period
               crosses the 900 second statistics window boundary, as the
               foregoing description implies that the SES and UAS
               counters must be adjusted when the Unavailable Signal
               State is entered. Clearly, successive GETs of the
               affected ds3IntervalSES and ds3IntervalUAS objects will
               return differing values if the first GET occurs during
               the first few seconds of the window.  This is viewed as
               an unavoidable side-effect of selecting the presently
               defined managed objects as a basis for this memo.


SNMP & Transmission MIB Working Groups                          [Page 5]

RFC 1233                 DS3 Interface Objects                  March 1992


          Alarm States:
               The Far End Alarm (or Yellow Alarm) is declared after detecting
               the Yellow Signal.  See ANSI T1.107a-1990 [10].
               The incoming alarms consist of the following
               incoming signal degradations:  Loss of
               Signal (LOS), a Loss of Frame (LOF)  (a persistent Out
               of Frame event), or an
               Alarm Indication Signal (AIS), for at least 2-10
               seconds.  The Alarms are cleared at the onset of 10
               consecutive seconds with no SES.  See T1M1.3/91-0003R3 [12].
               The Alarm State object identifies only the highest priority
               alarm.  The priorities of the alarms from highest to lowest
               are LOS, LOF, AIS, and Yellow Alarm.

          Out of Frame (OOF) event
               An OOF event is detected when any three or more errors in
               sixteen or fewer consecutive F-bits occur within a DS3
               M-frame.  An OOF event is cleared when reframe occurs.
               A Loss of Frame (LOF) event is declared when the OOF event
               is consistent for 2 to 3 seconds.  The OOF event ends when
               reframe occurs.

          Loss of Signal (LOS)
               This failure is declared upon observing 175 +/- 75
               contiguous pulse positions with no pulses of either
               positive or negative polarity.
               The LOS is terminated upon observing an average pulse density
               of at least 33% over a period of 175 +/- 75 contiguous pulse
               positions starting with the receipt of a pulse.

	  Alarm Indication Signal (AIS)
               The AIS is framed with "stuck stuffing."  This implies
               that it has a valid M-subframe alignments bits, M-frame
               alignment bits, and P bits.  The information bits are set
               to a 1010... sequence, starting with a one (1) after each
               M-subframe alignment bit, M-frame alignment bit, X bit, P bit,
               and C bit.  The C bits are all set to zero giving what is called
               "stuck stuffing."  The X bits are set to one.
               The AIS is declared after AIS is present in contiguous M-frames
               for a time equal to or greater than T, where
               0.2 ms <= T <= 100 ms.
               The AIS is terminated after AIS is absent in contiguous M-frames
               for a time equal to or greater than T.

          Circuit Identifier
               This is a character string specified by the circuit
               vendor, and is useful when communicating with the vendor
               during the troubleshooting process.


SNMP & Transmission MIB Working Groups                          [Page 6]


RFC 1233                 DS3 Interface Objects                  March 1992


5.  Object Definitions

               RFC1233-MIB DEFINITIONS ::= BEGIN

               IMPORTS
                       mgmt, experimental, Counter
                               FROM RFC1155-SMI
                       DisplayString
                               FROM RFC1158-MIB
                       OBJECT-TYPE
                               FROM RFC-1212;

               --  This MIB module uses the extended OBJECT-TYPE macro
               --  as defined in RFC 1212.

               --  this is the MIB module for the DS3 objects

               mib-2 OBJECT IDENTIFIER ::= { mgmt 1 }
               transmission OBJECT IDENTIFIER ::= { mib-2 10 }
               ds3 OBJECT IDENTIFIER ::= { transmission 30 }

               -- the DS3 Configuration group

               -- Although the objects in this group are read-only, at
               -- the agent's discretion they may be made read-write
               -- so that the management station, when appropriately
               -- authorized, may change the behavior of the device,
               -- e.g., to place the device into a loopback state.

               -- Implementation of this group is mandatory for all
               -- systems that attach to a DS3 Interface.

               ds3ConfigTable OBJECT-TYPE
                   SYNTAX  SEQUENCE OF DS3ConfigEntry
                   ACCESS  not-accessible
                   STATUS  mandatory
                   DESCRIPTION
                           "The DS3 Configuration table."
                  ::= { ds3 1 }

              ds3ConfigEntry OBJECT-TYPE
                  SYNTAX  DS3ConfigEntry
                  ACCESS  not-accessible
                  STATUS  mandatory
                  DESCRIPTION
                          "An entry in the DS3 Configuration table."
                 INDEX   { ds3LineIndex }
                 ::= { ds3ConfigTable 1 }

             DS3ConfigEntry ::=
                 SEQUENCE {
                     ds3LineIndex
                         INTEGER,
                     ds3Index
                         INTEGER,
                     ds3TimeElapsed
                         INTEGER,

SNMP & Transmission MIB Working Groups                          [Page 7]

RFC 1233                 DS3 Interface Objects                  March 1992

                     ds3ValidIntervals
                         INTEGER,
                     ds3LineType
                         INTEGER,
                     ds3ZeroCoding
                         INTEGER,
                     ds3Loopback
                         INTEGER,
                     ds3SendCode
                         INTEGER,
                     ds3YellowAlarm
                         INTEGER,
                     ds3RedAlarm
                         INTEGER,
                     ds3CircuitIdentifier
                         DisplayString,
                     ds3NewLoopback
                         INTEGER,
                     ds3AlarmState
                         INTEGER,
                     ds3EquipCode
                         DisplayString,
                     ds3LocationIDCode
                         DisplayString,
                     ds3FrameIDCode
                         DisplayString,
                     ds3UnitCode
                         DisplayString,
                     ds3FacilityIDCode
                         DisplayString
             }























SNMP & Transmission MIB Working Groups                          [Page 8]

RFC 1233                 DS3 Interface Objects                  March 1992



             ds3LineIndex OBJECT-TYPE
                 SYNTAX  INTEGER (1..65535)
                 ACCESS  read-only
                 STATUS  mandatory
                 DESCRIPTION
                         "The index value which uniquely identifies the
                         DS3 interface to which this entry
                         is applicable."
                ::= { ds3ConfigEntry 1 }

            ds3Index OBJECT-TYPE
                SYNTAX  INTEGER (1..65535)
                ACCESS  read-only
                STATUS  mandatory
                DESCRIPTION
                        "An index value that uniquely identifies a DS3
                        (ifIndex) Interface.  The interface identified by a
                        particular value of this index is the same
                        interface as identified by the same value an
                        ifIndex object instance."
               ::= { ds3ConfigEntry 2 }

           ds3TimeElapsed OBJECT-TYPE
               SYNTAX  INTEGER (1..900)
               ACCESS  read-only
               STATUS  mandatory
               DESCRIPTION
                       "The number of seconds, including partial
                       seconds, that have elapsed since the beginning of
                       the current error-measurement period."
              ::= { ds3ConfigEntry 3 }

          ds3ValidIntervals OBJECT-TYPE
              SYNTAX  INTEGER (0..96)
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The number of previous intervals for which valid
                      data was collected.  The value will be 96 unless
                      the device was brought online within the last
                      24 hours, in which case the value will be the
                      number of complete 15 minute intervals the device has
                      been online."
              ::= { ds3ConfigEntry 4 }


SNMP & Transmission MIB Working Groups                          [Page 9]

RFC 1233                 DS3 Interface Objects                  March 1992


          ds3LineType OBJECT-TYPE
              SYNTAX  INTEGER {
                          other(1),
                          ds3M23(2),
                          ds3SYNTRAN(3),
                          ds3CbitParity(4),
                          ds3ClearChannel(5)
                      }
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "This variable indicates the variety of DS3 C-bit
                      application implementing this circuit.  The type
                      of circuit affects the interpretation of the usage
                      and error statistics.  The rate of all of them is
                      44.736 Mbps.

                      The values, in sequence, describe:
                      TITLE:            SPECIFICATION:
                      ds3M23            ANSI T1.107-1988
                      ds3SYNTRAN        ANSI T1.107-1988
                      ds3C-bitParity    ANSI T1.107a-1990
                      ds3ClearChannel   ANSI T1.102-1987
                      "
              ::= { ds3ConfigEntry 5 }

          ds3ZeroCoding OBJECT-TYPE
              SYNTAX  INTEGER {
                          ds3Other(1),
                          ds3B3ZS(2)
                      }
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "This variable describes the variety of Zero Code
                      Suppression used on the link, which in turn
                      affects a number of its characteristics.
                      ds3B3ZS refers to the use of specified patterns of
                      normal bits and bipolar violations which are used
                      to replace sequences of zero bits of a specified
                      length."
              ::= { ds3ConfigEntry 6 }


SNMP & Transmission MIB Working Groups                          [Page 10]

RFC 1233                 DS3 Interface Objects                  March 1992


          ds3Loopback OBJECT-TYPE
              SYNTAX  INTEGER {
                          ds3NoLoop(1),
                          ds3LocalLoopbackLocalSide(2),
                          ds3LocalLoopbackRemoteSide(3),
                          ds3RemoteLoopbackLocalSide(4),
                          ds3RemoteLoopbackRemoteSide(5)
                      }
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "This variable represents the loopback state of
                      the device.  Devices supporting read/write access
                      should return badValue in response to a requested
                      loopback state that the device does not support.  The
                      values mean:

                        ds3NoLoop
                           Not in the loopback state.  A device that is
                           not capable of performing a loopback on
                           either interface shall always return this as
                           it's value.

                        ds3LocalLoopbackLocalSide
                           Signal received from the local side of the
                           device is looped back at the local connector
                           (eg, without involving the device).

                        ds3LocalLoopbackRemoteSide
                           Signal received from the local side of the
                           device is looped back at the remote connector
                           (eg, through the device).

                        ds3RemoteLoopbackLocalSide
                           Signal received from the remote side of the
                           device is looped back at the local connector
                           (eg, through the device).

                        ds3RemoteLoopbackRemoteSide
                           Signal received from the remote side of the
                           device is looped back at the remote connector
                           (eg, without involving the device).

                      Note that M23 and ClearChannel interfaces do not
                      support the Loopback managed object."
              ::= { ds3ConfigEntry 7 }





SNMP & Transmission MIB Working Groups                          [Page 11]

RFC 1233                 DS3 Interface Objects                  March 1992


          ds3SendCode OBJECT-TYPE
              SYNTAX  INTEGER {
                          ds3SendTestMessage(1),
                          ds3SendNoCode(2),
                          ds3SendSetCode(3),
                          ds3SendLoopbackCode(4),
                          ds3SendResetCode(5)
                      }
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "This variable indicates what type of code is
                      being sent across the DS3 circuit by the device.  The
                      values mean:

                        ds3SendNoCode
                           sending looped or normal data

                        ds3SendSetCode
                           sending a loopback request

                        ds3SendLoopbackCode
                           sending the code to choose a specific
                           loopback -- THIS IS MEANINGLESS -- HOW DO YOU
                           CHOOSE A SPECIFIC LOOPBACK TO ACTIVATE?
                           FOR EXAMPLE ANSI T1.107a SPECIFIES ABOUT 31
                           DIFFERENT LOOPBACKS TO ACTIVATE.

                        ds3SendResetCode
                           sending a loopback termination request

                        ds3SendTestMessage
                           sending a Test pattern as defined in
                           T1.107a-1990.
                      "
              ::= { ds3ConfigEntry 8 }

          ds3YellowAlarm OBJECT-TYPE
              SYNTAX  INTEGER {
                          ds3YellowAlarm(1),
                          ds3NoYellowAlarm(2)
                       }
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                     "This variable indicates if a Yellow
                     Alarm condition exists."
              ::= { ds3ConfigEntry 9 }


SNMP & Transmission MIB Working Groups                         [Page 12]

RFC 1233                 DS3 Interface Objects                  March 1992


          ds3RedAlarm OBJECT-TYPE
              SYNTAX  INTEGER {
                          ds3RedAlarm(1),
                          ds3NoRedAlarm(2)
                      }
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "This variable indicates if a Red Alarm
                      condition exists."
              ::= { ds3ConfigEntry 10 }

          ds3CircuitIdentifier OBJECT-TYPE
              SYNTAX  DisplayString (SIZE (0..255))
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "This variable contains the transmission
                      vendor's circuit identifier, for the
                      purpose of facilitating troubleshooting."
              ::= { ds3ConfigEntry 11 }

          ds3NewLoopback OBJECT-TYPE
              SYNTAX  INTEGER {
                          ds3NoLoop(1),
                          ds3LoopThroughDevice(2),
                          ds3OutOfDevice(3),
                          ds3OtherLoop(4)
                      }
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "This variable represents the loopback state of
                      the DS3 interface.  Devices supporting read/write
                      access should return badValue in response to a
                      requested loopback state that the device does not support.
                      The values mean:

                            ds3NoLoop

                              Not in the loopback state.  A device that is
                              not capable of performing a loopback on
                              either interface shall always return this as
                              it's value.

                            ds3LoopThroughDevice

                              The loopback at one interface is looped through
                              the device.

                            ds3OutOfDevice
                               
                              The loopback at one interface does not go through
                              the device but is looped back out.

                            ds3OtherLoop
         
                              Loopbacks that are not defined here.


SNMP & Transmission MIB Working Groups                         [Page 13]

RFC 1233                 DS3 Interface Objects                  March 1992


                      Note that M23 and ClearChannel interfaces do not
                      support the Loopback managed object."
              ::= { ds3ConfigEntry 12 }

          ds3AlarmState OBJECT-TYPE
              SYNTAX  INTEGER {
                          ds3NoAlarm(1),
                          ds3YellowAlarm(2),
                          ds3AlarmIndicationSignal(3),
                          ds3OutOfFrame(4),
                          ds3LossOfSignal(5)
                      }
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                    "This variable indicates the
                    Alarm State of the interface.
                    If multiple alarms are occurring
                    simultaneously, then the highest
                    priority alarm is the one set.  From
                    highest to lowest the alarm priorities are
                    the following:  ds3LossOfSignal, ds3OutOfFrame,
                    ds3AlarmIndicationSignal, and ds3YellowAlarm."
              ::= { ds3ConfigEntry 13 }

          ds3EquipCode OBJECT-TYPE
              SYNTAX  DisplayString (SIZE (0..10))
              ACCESS  read-write
              STATUS  mandatory
              DESCRIPTION
                    "This is the Equipment Identification code
                    that describes the specific piece of equipment.
                    In C-bit parity applications, it is up to 10 ASCII
                    characters long and is sent within the Path
                    Identification Message."
              ::= { ds3ConfigEntry 14 }

          ds3LocationIDCode OBJECT-TYPE
              SYNTAX  DisplayString (SIZE (0..11))
              ACCESS  read-write
              STATUS  mandatory
              DESCRIPTION
                    "This is the Location Identification code
                    that describes the specific location of the equipment.
                    In C-bit parity applications, it is up to 11 ASCII
                    characters long and is sent within the Path
                    Identification Message."
              ::= { ds3ConfigEntry 15 }


SNMP & Transmission MIB Working Groups                         [Page 14]

RFC 1233                 DS3 Interface Objects                  March 1992


          ds3FrameIDCode OBJECT-TYPE
              SYNTAX  DisplayString (SIZE (0..10))
              ACCESS  read-write
              STATUS  mandatory
              DESCRIPTION
                    "This is the Frame Identification code
                    that identifies where the equipment is located
                    within a building at a given location.
                    In C-bit parity applications, it is up to 10 ASCII
                    characters long and is sent within the Path
                    Identification Message."
              ::= { ds3ConfigEntry 16 }

          ds3UnitCode OBJECT-TYPE
              SYNTAX  DisplayString (SIZE (0..6))
              ACCESS  read-write
              STATUS  mandatory
              DESCRIPTION
                    "This is the code
                    that identifies the equipment location within a bay.
                    In C-bit parity applications, it is up to 6 ASCII
                    characters long and is sent within the Path
                    Identification Message."
              ::= { ds3ConfigEntry 17 }

          ds3FacilityIDCode OBJECT-TYPE
              SYNTAX  DisplayString (SIZE (0..38))
              ACCESS  read-write
              STATUS  mandatory
              DESCRIPTION
                    "This code identifies a specific DS3 path.
                    In C-bit parity applications, it is up to 38 ASCII
                    characters long and is sent within the Path
                    Identification Message."
              ::= { ds3ConfigEntry 18 }
















SNMP & Transmission MIB Working Groups                         [Page 15]

RFC 1233                 DS3 Interface Objects                  March 1992



          -- the DS3 Interval group

          -- Implementation of this group is mandatory for all
          -- systems that attach to a DS3 interface.

          -- The DS3 Interval Table contains various statistics
          -- collected by each device over the previous 24 hours of
          -- operation.  The past 24 hours are broken into 96
          -- completed 15 minute intervals.

          ds3IntervalTable OBJECT-TYPE
              SYNTAX  SEQUENCE OF DS3IntervalEntry
              ACCESS  not-accessible
              STATUS  mandatory
              DESCRIPTION
                     "The DS3 Interval table."
              ::= { ds3 2 }

          ds3IntervalEntry OBJECT-TYPE
              SYNTAX  DS3IntervalEntry
              ACCESS  not-accessible
              STATUS  mandatory
              DESCRIPTION
                    "An entry in the DS3 Interval table."
              INDEX   { ds3IntervalIndex, ds3IntervalNumber }
              ::= { ds3IntervalTable 1 }

          DS3IntervalEntry ::=
              SEQUENCE {
                   ds3IntervalIndex
                        INTEGER,
                   ds3IntervalNumber
                        INTEGER,
                   ds3IntervalESs
                        Counter,
                   ds3IntervalSESs
                        Counter,
                   ds3IntervalSEFSs
                        Counter,
                   ds3IntervalUASs
                        Counter,
                   ds3IntervalCSSs
                        Counter,
                   ds3IntervalBPVs
                        Counter,
                   ds3IntervalCVs
                        Counter,
                   ds3IntervalOtherCVs
                        Counter
              }



SNMP & Transmission MIB Working Groups                         [Page 16]

RFC 1233                 DS3 Interface Objects                  March 1992


          ds3IntervalIndex OBJECT-TYPE
              SYNTAX  INTEGER (1..65535)
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The index value which uniquely identifies the
                      DS3 interface
                      to which this entry is applicable.  The
                      interface identified by a particular value of
                      this index is the same interface as identified
                      by the same value an DS3LineIndex object
                      instance."
              ::= { ds3IntervalEntry 1 }

         ds3IntervalNumber OBJECT-TYPE
             SYNTAX  INTEGER (1..96)
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                    "A number between 1 and 96, where 1 is the most
                    recently completed 15 minute interval and 96 is
                    the least recently completed 15 minutes
                    interval (assuming that all 96 intervals are
                    valid)."
             ::= { ds3IntervalEntry 2 }

         ds3IntervalESs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                     "The counter associated with the number of
                     Errored Seconds, see Section 4.3, encountered
                     by a DS3 device in one of the previous 96,
                     individual 15 minute, intervals."
            ::= { ds3IntervalEntry 3 }

         ds3IntervalSESs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                     "The counter associated with the number of
                     Severely Errored Seconds, see Section 4.3,
                     encountered by a DS3 device in one of the previous
                     96, individual 15 minute, intervals."
            ::= { ds3IntervalEntry 4 }


SNMP & Transmission MIB Working Groups                         [Page 17]

RFC 1233                 DS3 Interface Objects                  March 1992


          ds3IntervalSEFSs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                     "The counter associated with the number of
                     Severely Errored Framing Seconds, see Section 4.3,
                     encountered by a DS3 device in one of the
                     previous 96, individual 15 minute, intervals."
             ::= { ds3IntervalEntry 5 }

         ds3IntervalUASs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                     "The counter associated with the number of
                     Unavailable Seconds, see Section 4.3,
                     encountered by a DS3 device in one of the previous
                     96, individual 15 minute, intervals."
             ::= { ds3IntervalEntry 6 }

         ds3IntervalCSSs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  deprecated
             DESCRIPTION
                     "The counter associated with the number of
                     Controlled Slip Seconds, see Section 4.3,
                     encountered by a DS3 device in one of the previous
                     96, individual 15 minute, intervals.
                     Note that SYNTRAN interfaces are the only
                     interfaces that support the Controlled Slip
                     Seconds managed object.  Accordingly, agents
                     configured with non-SYNTRAN interfaces may treat
                     this object as having an ACCESS clause value of
                     not-accessible."
             ::= { ds3IntervalEntry 7}

         ds3IntervalBPVs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                     "The counter associated with the number of Bipolar
                     Violations, see Section 4.3, encountered by a
                     DS3 device in one of the previous 96, individual 15
                     minute, intervals."
             ::= { ds3IntervalEntry 8 }



SNMP & Transmission MIB Working Groups                         [Page 18]

RFC 1233                 DS3 Interface Objects                  March 1992


           ds3IntervalCVs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                     "The counter associated with the number of Coding
                     Violations from the P-bits,
                     see Section 4.3, encountered by a
                     DS3 device in one of the previous 96, individual 15
                     minute, intervals."
             ::= { ds3IntervalEntry 9 }

          ds3IntervalOtherCVs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Coding
                      Violations from the C-bits,
                      see Section 4.3, encountered by a
                      DS3 device in one of the previous 96, individual 15
                      minute, intervals."
              ::= { ds3IntervalEntry 10 }





























SNMP & Transmission MIB Working Groups                         [Page 19]

RFC 1233                 DS3 Interface Objects                  March 1992


          -- the DS3 Current group

          -- Implementation of this group is mandatory for all systems
          -- that attach to a DS3 Interface.

          -- The DS3 current table contains various statistics being
          -- collected for the current 15 minute interval.

          ds3CurrentTable OBJECT-TYPE
              SYNTAX  SEQUENCE OF DS3CurrentEntry
              ACCESS  not-accessible
              STATUS  mandatory
              DESCRIPTION
                      "The DS3 Current table."
              ::= { ds3 3 }

          ds3CurrentEntry OBJECT-TYPE
              SYNTAX  DS3CurrentEntry
              ACCESS  not-accessible
              STATUS  mandatory
              DESCRIPTION
                      "An entry in the DS3 Current table."
              INDEX   { ds3CurrentIndex }
              ::= { ds3CurrentTable 1 }

          DS3CurrentEntry ::=
              SEQUENCE {
                  ds3CurrentIndex
                      INTEGER,
                  ds3CurrentESs
                      Counter,
                  ds3CurrentSESs
                      Counter,
                  ds3CurrentSEFSs
                      Counter,
                  ds3CurrentUASs
                      Counter,
                  ds3CurrentCSSs
                      Counter,
                  ds3CurrentBPVs
                      Counter,
                  ds3CurrentCVs
                      Counter,
                  ds3CurrentOtherCVs
                      Counter
              }

         

SNMP & Transmission MIB Working Groups                         [Page 20]

RFC 1233                 DS3 Interface Objects                  March 1992


           ds3CurrentIndex OBJECT-TYPE
              SYNTAX  INTEGER (1..65535)
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The index value which uniquely identifies the
                      DS3 interface
                      to which this entry is applicable.  The interface
                      identified by a particular value of this index is
                      the same interface as identified by the same value
                      an DS3LineIndex object instance."
              ::= { ds3CurrentEntry 1 }

          ds3CurrentESs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Errored
                      Seconds, see Section 4.3, encountered by a DS3
                      device in the current 15 minute interval."
              ::= { ds3CurrentEntry 2 }

          ds3CurrentSESs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of
                      Severely Errored Seconds, see Section 4.3,
                      encountered by a DS3 device in the current 15 minute
                      interval."
              ::= { ds3CurrentEntry 3 }

          ds3CurrentSEFSs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of
                      Severely Errored Framing Seconds, see Section 4.3,
                      encountered by a DS3 device in the current 15
                      minute interval."
              ::= { ds3CurrentEntry 4 }

          ds3CurrentUASs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of
                      Unavailable Seconds, see Section 4.3,
                      encountered by a DS3 device in the current 15 minute
                      interval."
              ::= { ds3CurrentEntry 5 }

         

SNMP & Transmission MIB Working Groups                         [Page 21]

RFC 1233                 DS3 Interface Objects                  March 1992


          ds3CurrentCSSs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "The counter associated with the number of
                      Controlled Slip Seconds, see Section 4.3,
                      encountered by a DS3 device in the current 15 minute
                      interval.
                      Note that SYNTRAN interfaces are the only
                      interfaces that support the Controlled Slip
                      Seconds managed object.  Accordingly, agents
                      configured with non-SYNTRAN interfaces may treat
                      this object as having an ACCESS clause value of
                      not-accessible."
              ::= { ds3CurrentEntry 6 }

          ds3CurrentBPVs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Bipolar
                      Violations, see Section 4.3, encountered by a
                      DS3 device in the current 15 minute interval."
              ::= { ds3CurrentEntry 7}

          ds3CurrentCVs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Coding
                      Violations from the P-bits,
                      see Section 4.3, encountered by a
                      DS3 device in the current 15 minute interval."
              ::= { ds3CurrentEntry 8 }
             
          ds3CurrentOtherCVs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Coding
                      Violations from the C-bits,
                      see Section 4.3, encountered by a
                      DS3 device in the current 15 minute interval."
              ::= { ds3CurrentEntry 9 }





SNMP & Transmission MIB Working Groups                         [Page 22]

RFC 1233                 DS3 Interface Objects                  March 1992


          -- the DS3 Total group

          -- Implementation of this group is mandatory for all systems
          -- that attach to a DS3.

          -- The DS3 Total Table contains the cumulative sum of the
          -- various statistics for the 24 hour interval preceding the
          -- first valid interval in the DS3CurrentTable.

          ds3TotalTable OBJECT-TYPE
              SYNTAX  SEQUENCE OF DS3TotalEntry
              ACCESS  not-accessible
              STATUS  mandatory
              DESCRIPTION
                      "The DS3 Total table.  24 hour interval."
              ::= { ds3 4 }

          ds3TotalEntry OBJECT-TYPE
              SYNTAX  DS3TotalEntry
              ACCESS  not-accessible
              STATUS  mandatory
              DESCRIPTION
                      "An entry in the DS3 Total table."
              INDEX   { ds3TotalIndex }
              ::= { ds3TotalTable 1 }

          DS3TotalEntry ::=
              SEQUENCE {
                  ds3TotalIndex
                      INTEGER,
                  ds3TotalESs
                      Counter,
                  ds3TotalSESs
                      Counter,
                  ds3TotalSEFSs
                      Counter,
                  ds3TotalUASs
                      Counter,
                  ds3TotalCSSs
                      Counter,
                  ds3TotalBPVs
                      Counter,
                  ds3TotalCVs
                      Counter,
                  ds3TotalOtherCVs
                      Counter
              }

          ds3TotalIndex OBJECT-TYPE
              SYNTAX  INTEGER (1..65535)
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                     



SNMP & Transmission MIB Working Groups                         [Page 23]

RFC 1233                 DS3 Interface Objects                  March 1992


                      "The index value which uniquely identifies the
                      DS3 interface
                      to which this entry is applicable.  The interface
                      identified by a particular value of this index is
                      the same interface as identified by the same value
                      an DS3LineIndex object instance."
              ::= { ds3TotalEntry 1 }

         ds3TotalESs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                     "The counter associated with the number of Errored
                     Seconds, see Section 4.3, encountered by a DS3
                     device in the previous 24 hour interval."
             ::= { ds3TotalEntry 2 }

         ds3TotalSESs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                     "The counter associated with the number of
                     Severely Errored Seconds, see Section 4.3,
                     encountered by a DS3 device in the previous 24 hour
                     interval."
             ::= { ds3TotalEntry 3 }

         ds3TotalSEFSs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                     "The counter associated with the number of
                     Severely Errored Framing Seconds, see Section 4.3,
                     encountered by a DS3 device in the previous 24
                     hour interval."
             ::= { ds3TotalEntry 4 }

         ds3TotalUASs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                     "The counter associated with the number of
                     Unavailable Seconds, see Section 4.3,
                     encountered by a DS3 device in the previous 24 hour
                     interval."
             ::= { ds3TotalEntry 5 }

         

SNMP & Transmission MIB Working Groups                         [Page 24]

RFC 1233                 DS3 Interface Objects                  March 1992


         ds3TotalCSSs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  deprecated
             DESCRIPTION
                     "The counter associated with the number of
                     Controlled Slip Seconds, see Section 4.3,
                     encountered by a DS3 device in the previous 24 hour
                     interval.
                     Note that SYNTRAN interfaces are the only
                     interfaces that support the Controlled Slip
                     Seconds managed object.  Accordingly, agents
                     configured with non-SYNTRAN interfaces may treat
                     this object as having an ACCESS clause value of
                     not-accessible."
             ::= { ds3TotalEntry 6 }

         ds3TotalBPVs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                     "The counter associated with the number of Bipolar
                     Violations, see Section 4.3, encountered by a
                     DS3 device in the previous 24 hour interval."
             ::= { ds3TotalEntry 7 }

         ds3TotalCVs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                     "The counter associated with the number of Coding
                     Violations from the P-bits,
                     see Section 4.3, encountered by a
                     DS3 device in the previous 24 hour interval."
             ::= { ds3TotalEntry 8 }
      
         ds3TotalOtherCVs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                     "The counter associated with the number of Coding
                     Violations from the C-bits,
                     see Section 4.3, encountered by a
                     DS3 device in the previous 24 hour interval."
             ::= { ds3TotalEntry 9 }





SNMP & Transmission MIB Working Groups                         [Page 25]

RFC 1233                 DS3 Interface Objects                  March 1992


          -- the DS3 Far End group
          -- the DS3 Far End Configuration group

          -- Although the objects in this group are read-only, at
          -- the agent's discretion they may be made read-write
          -- so that the management station, when appropriately
          -- authorized, may change the behavior of the device,

          -- Implementation of this group is optional for all
          -- systems that attach to a DS3 Interface.

             ds3FarEndConfigTable OBJECT-TYPE
                  SYNTAX  SEQUENCE OF DS3FarEndConfigEntry
                  ACCESS  not-accessible
                  STATUS  optional
                  DESCRIPTION
                          "The DS3 Far End Configuration table."
                 ::= { ds3 5 }

             ds3FarEndConfigEntry OBJECT-TYPE
                 SYNTAX  DS3FarEndConfigEntry
                 ACCESS  not-accessible
                 STATUS  optional
                 DESCRIPTION
                         "An entry in the DS3 Far End Configuration table."
                 INDEX   { ds3FarEndLineIndex }
                 ::= { ds3FarEndConfigTable 1 }

             DS3FarEndConfigEntry ::=
                 SEQUENCE {
                     ds3FarEndLineIndex
                         INTEGER,
                     ds3FarEndEquipCode
                         DisplayString,
                     ds3FarEndLocationIDCode
                         DisplayString,
                     ds3FarEndFrameIDCode
                         DisplayString,
                     ds3FarEndUnitCode
                         DisplayString,
                     ds3FarEndFacilityIDCode
                         DisplayString
             }

          ds3FarEndLineIndex OBJECT-TYPE
                 SYNTAX  INTEGER (1..65535)
                 ACCESS  read-only
                 STATUS  optional
                 DESCRIPTION
                      "The index value which uniquely identifies the
                      DS3 interface
                      to which this entry is applicable.  The
                      interface identified by a particular value of
                      this index is the same interface as identified
                      by the same value an DS3LineIndex object
                      instance."
                ::= { ds3FarEndConfigEntry 1 }


SNMP & Transmission MIB Working Groups                         [Page 26]

RFC 1233                 DS3 Interface Objects                  March 1992


          ds3FarEndEquipCode OBJECT-TYPE
              SYNTAX  DisplayString (SIZE (0..10))
              ACCESS  read-write
              STATUS  optional
              DESCRIPTION
                    "This is the Far End Equipment Identification code
                    that describes the specific piece of equipment.
                    This code is only used in C-bit parity applications.
                    devices should return noSuchName when this object is
                    requested in a GET-Request and the next lexicographical
                    object in a GET-NEXT-Request.
                    It is sent within the Path
                    Identification Message."
              ::= { ds3FarEndConfigEntry 2 }

          ds3FarEndLocationIDCode OBJECT-TYPE
              SYNTAX  DisplayString (SIZE (0..11))
              ACCESS  read-write
              STATUS  optional
              DESCRIPTION
                    "This is the Far End Location Identification code
                    that describes the specific location of the equipment.
                    This code is only used in C-bit parity applications.
                    Devices should return noSuchName when this object is
                    requested in a GET-Request and the next lexicographical
                    object in a GET-NEXT-Request.
                    It is sent within the Path
                    Identification Message."
              ::= { ds3FarEndConfigEntry 3 }

          ds3FarEndFrameIDCode OBJECT-TYPE
              SYNTAX  DisplayString (SIZE (0..10))
              ACCESS  read-write
              STATUS  optional
              DESCRIPTION
                    "This is the Far End Frame Identification code
                    that identifies where the equipment is located
                    within a building at a given location.
                    This code is only used in C-bit parity applications.
                    Devices should return noSuchName when this object is
                    requested in a GET-Request and the next lexicographical
                    object in a GET-NEXT-Request.
                    It is sent within the Path
                    Identification Message."
              ::= { ds3FarEndConfigEntry 4 }

          ds3FarEndUnitCode OBJECT-TYPE
              SYNTAX  DisplayString (SIZE (0..6))
              ACCESS  read-write
              STATUS  optional
              DESCRIPTION
                    "This is the Far End code
                    that identifies the equipment location within a bay.
                    This code is only used in C-bit parity applications.
                    Devices should return noSuchName when this object is
                    requested in a GET-Request and the next lexicographical
                    object in a GET-NEXT-Request.
                    It is sent within the Path
                    Identification Message."
              ::= { ds3FarEndConfigEntry 5 }


SNMP & Transmission MIB Working Groups                         [Page 27]

RFC 1233                 DS3 Interface Objects                  March 1992



          ds3FarEndFacilityIDCode OBJECT-TYPE
              SYNTAX  DisplayString (SIZE (0..38))
              ACCESS  read-write
              STATUS  optional
              DESCRIPTION
                    "This code identifies a specific Far End DS3 path.
                    This code is only used in C-bit parity applications.
                    Devices should return noSuchName when this object is
                    requested in a GET-Request and the next lexicographical
                    object in a GET-NEXT-Request.
                    It is sent within the Path
                    Identification Message."
              ::= { ds3FarEndConfigEntry 6 }



































SNMP & Transmission MIB Working Groups                         [Page 28]

RFC 1233                 DS3 Interface Objects                  March 1992



          -- the DS3 Far End Interval group

          -- Implementation of this group is optional for all
          -- systems that attach to a DS3 interface.
          -- Only C-bit Parity Applications and SYNTRAN applications
          -- can provide this information.

          -- The DS3 Far End Interval Table contains various statistics
          -- collected by each device over the previous 24 hours of
          -- operation.  The past 24 hours are broken into 96
          -- completed 15 minute intervals.

          ds3FarEndIntervalTable OBJECT-TYPE
              SYNTAX  SEQUENCE OF DS3FarEndIntervalEntry
              ACCESS  not-accessible
              STATUS  optional
              DESCRIPTION
                     "The DS3 Far End Interval table."
              ::= { ds3 6 }

          ds3FarEndIntervalEntry OBJECT-TYPE
              SYNTAX  DS3FarEndIntervalEntry
              ACCESS  not-accessible
              STATUS  optional
              DESCRIPTION
                    "An entry in the DS3 Far
                    End Interval table."
              INDEX   { ds3FarEndIntervalIndex, ds3FarEndIntervalNumber }
              ::= { ds3FarEndIntervalTable 1 }

          DS3FarEndIntervalEntry ::=
              SEQUENCE {
                   ds3FarEndIntervalIndex
                        INTEGER,
                   ds3FarEndIntervalNumber
                        INTEGER,
                   ds3FarEndIntervalESs
                        Counter,
                   ds3FarEndIntervalSESs
                        Counter,
                   ds3FarEndIntervalOtherCVs
                        Counter
              }



SNMP & Transmission MIB Working Groups                         [Page 29]

RFC 1233                 DS3 Interface Objects                  March 1992


          ds3FarEndIntervalIndex OBJECT-TYPE
              SYNTAX  INTEGER (1..65535)
              ACCESS  read-only
              STATUS  optional
              DESCRIPTION
                      "The index value which uniquely identifies the
                      DS3 interface
                      to which this entry is applicable.  The
                      interface identified by a particular value of
                      this index is the same interface as identified
                      by the same value an DS3LineIndex object
                      instance."
              ::= { ds3FarEndIntervalEntry 1 }

         ds3FarEndIntervalNumber OBJECT-TYPE
             SYNTAX  INTEGER (1..96)
             ACCESS  read-only
             STATUS  optional
             DESCRIPTION
                    "A number between 1 and 96, where 1 is the most
                    recently completed 15 minute interval and 96 is
                    the least recently completed 15 minutes
                    interval (assuming that all 96 intervals are
                    valid)."
             ::= { ds3FarEndIntervalEntry 2 }

         ds3FarEndIntervalESs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  optional
             DESCRIPTION
                     "The counter associated with the number of
                     Far End Errored Seconds,
                     see Section 4.3, encountered
                     by a DS3 device in one of the previous 96,
                     individual 15 minute, intervals."
            ::= { ds3FarEndIntervalEntry 3 }

         ds3FarEndIntervalSESs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  optional
             DESCRIPTION
                     "The counter associated with the number of
                     Far End
                     Severely Errored Seconds, see Section 4.3,
                     encountered by a DS3 device in one of the previous
                     96, individual 15 minute, intervals."
            ::= { ds3FarEndIntervalEntry 4 }


SNMP & Transmission MIB Working Groups                         [Page 30]

RFC 1233                 DS3 Interface Objects                  March 1992



          ds3FarEndIntervalOtherCVs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  optional
              DESCRIPTION
                      "The counter associated with the number of
                      Far End Coding
                      Violations from the C-bits reported via
                      the FEBE bits,
                      see Section 4.3, encountered by a
                      DS3 device in one of the previous 96, individual 15
                      minute, intervals."
              ::= { ds3FarEndIntervalEntry 5 }





























SNMP & Transmission MIB Working Groups                         [Page 31]

RFC 1233                 DS3 Interface Objects                  March 1992


          -- the DS3 Far End Current group

          -- Implementation of this group is optional for all systems
          -- that attach to a DS3 Interface.
          -- Only C-bit Parity Applications and SYNTRAN applications
          -- can provide this information.

          -- The DS3 Far End Current table contains various statistics being
          -- collected for the current 15 minute interval.

          ds3FarEndCurrentTable OBJECT-TYPE
              SYNTAX  SEQUENCE OF DS3FarEndCurrentEntry
              ACCESS  not-accessible
              STATUS  optional
              DESCRIPTION
                      "The DS3 Far End Current table."
              ::= { ds3 7 }

          ds3FarEndCurrentEntry OBJECT-TYPE
              SYNTAX  DS3FarEndCurrentEntry
              ACCESS  not-accessible
              STATUS  optional
              DESCRIPTION
                      "An entry in the DS3 Far End Current table."
              INDEX   { ds3FarEndCurrentIndex }
              ::= { ds3FarEndCurrentTable 1 }

          DS3FarEndCurrentEntry ::=
              SEQUENCE {
                  ds3FarEndCurrentIndex
                      INTEGER,
                  ds3FarEndCurrentESs
                      Counter,
                  ds3FarEndCurrentSESs
                      Counter,
                  ds3FarEndCurrentOtherCVs
                      Counter
              }

         

SNMP & Transmission MIB Working Groups                         [Page 32]

RFC 1233                 DS3 Interface Objects                  March 1992


           ds3FarEndCurrentIndex OBJECT-TYPE
              SYNTAX  INTEGER (1..65535)
              ACCESS  read-only
              STATUS  optional
              DESCRIPTION
                      "The index value which uniquely identifies the
                      DS3 interface
                      to which this entry is applicable.  The interface
                      identified by a particular value of this index is
                      the same interface as identified by the same value
                      an DS3LineIndex object instance."
              ::= { ds3FarEndCurrentEntry 1 }

          ds3FarEndCurrentESs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  optional
              DESCRIPTION
                      "The counter associated with the number of Far
                      End Errored
                      Seconds, see Section 4.3, encountered by a DS3
                      device in the current 15 minute interval."
              ::= { ds3FarEndCurrentEntry 2 }

          ds3FarEndCurrentSESs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  optional
              DESCRIPTION
                      "The counter associated with the number of
                      Far End
                      Severely Errored Seconds, see Section 4.3,
                      encountered by a DS3 device in the current 15 minute
                      interval."
              ::= { ds3FarEndCurrentEntry 3 }

          ds3FarEndCurrentOtherCVs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  optional
              DESCRIPTION
                      "The counter associated with the number of 
                      Far End Coding
                      Violations from the C-bits reported via
                      the FEBE bits,
                      see Section 4.3, encountered by a
                      DS3 device in the current 15 minute interval."
              ::= { ds3FarEndCurrentEntry 4 }





SNMP & Transmission MIB Working Groups                         [Page 33]

RFC 1233                 DS3 Interface Objects                  March 1992


          -- the DS3 Far End Total group

          -- Implementation of this group is optional for all systems
          -- that attach to a DS3.
          -- Only C-bit Parity Applications and SYNTRAN applications
          -- can provide this information.

          -- The DS3 Far End Total Table contains the cumulative sum of the
          -- various statistics for the 24 hour interval preceding the
          -- first valid interval in the DS3FarEndCurrentTable.

          ds3FarEndTotalTable OBJECT-TYPE
              SYNTAX  SEQUENCE OF DS3FarEndTotalEntry
              ACCESS  not-accessible
              STATUS  optional
              DESCRIPTION
                      "The DS3 Far End Total table.  24 hour interval."
              ::= { ds3 8 }

          ds3FarEndTotalEntry OBJECT-TYPE
              SYNTAX  DS3FarEndTotalEntry
              ACCESS  not-accessible
              STATUS  optional
              DESCRIPTION
                      "An entry in the DS3 Far End Total table."
              INDEX   { ds3FarEndTotalIndex }
              ::= { ds3FarEndTotalTable 1 }

          DS3FarEndTotalEntry ::=
              SEQUENCE {
                  ds3FarEndTotalIndex
                      INTEGER,
                  ds3FarEndTotalESs
                      Counter,
                  ds3FarEndTotalSESs
                      Counter,
                  ds3FarEndTotalOtherCVs
                      Counter
              }

          ds3FarEndTotalIndex OBJECT-TYPE
              SYNTAX  INTEGER (1..65535)
              ACCESS  read-only
              STATUS  optional
              DESCRIPTION
                     



SNMP & Transmission MIB Working Groups                         [Page 34]

RFC 1233                 DS3 Interface Objects                  March 1992


                      "The index value which uniquely identifies the
                      DS3 interface
                      to which this entry is applicable.  The interface
                      identified by a particular value of this index is
                      the same interface as identified by the same value
                      an DS3LineIndex object instance."
              ::= { ds3FarEndTotalEntry 1 }

         ds3FarEndTotalESs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  optional
             DESCRIPTION
                     "The counter associated with the number of Far
                     End Errored
                     Seconds, see Section 4.3, encountered by a DS3
                     device in the previous 24 hour interval."
             ::= { ds3FarEndTotalEntry 2 }

         ds3FarEndTotalSESs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  optional
             DESCRIPTION
                     "The counter associated with the number of
		     Far End
                     Severely Errored Seconds, see Section 4.3,
                     encountered by a DS3 device in the previous 24 hour
                     interval."
             ::= { ds3FarEndTotalEntry 3 }

         ds3FarEndTotalOtherCVs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  optional
             DESCRIPTION
                     "The counter associated with the number of
                     Far End Coding
                     Violations from the C-bits reported via the
                     FEBE bits,
                     see Section 4.3, encountered by a
                     DS3 device in the previous 24 hour interval."
             ::= { ds3FarEndTotalEntry 4 }

END


SNMP & Transmission MIB Working Groups                         [Page 35]

RFC 1233                 DS3 Interface Objects                  March 1992


6.  Acknowledgments

   This document was produced by the SNMP and the Transmission MIB
   Working Groups:

               Anne Ambler, Spider
               Karl Auerbach, Sun
               Fred Baker, ACC
               Ken Brinkerhoff
               Ron Broersma, NOSC
               Jack Brown, US Army
               Theodore Brunner, Bellcore
               Jeffrey Buffum, HP
               Jeffrey D. Case, UTK
               Chris Chiptasso, Spartacus
               Paul Ciarfella, DEC
               Bob Collet
               Tracy Cox, Bellcore
               James R. Davin, MIT-LCS
               Kurt Dobbins, Cabletron
               Nadya El-Afandi, Network Systems
               Gary Ellis, HP
               Fred Engle
               Mike Erlinger
               Richard Fox, Synoptics
               Karen Frisa, CMU
               Chris Gunner, DEC
               Ken Hibbard, Xylogics
               Ole Jacobsen, Interop
               Ken Jones
               Satish Joshi, Synoptics
               Frank Kastenholz, Racal-Interlan
               Shimshon Kaufman, Spartacus
               Jim Kinder, Fibercom
               Alex Koifman, BBN
               Christopher Kolb, PSI
               Cheryl Krupczak, NCR
               Peter Lin, Vitalink
               John Lunny, TWG
               Carl Malamud
               Keith McCloghrie, HLS
               Donna McMaster, David Systems
               Lynn Monsanto, Sun
               Dave Perkins, 3COM
               Jim Reinstedler, Ungerman Bass
               Anil Rijsinghani, DEC
               Kary Robertson
               Marshall T. Rose, PSI (chair)
               L. Michael Sabo, NCSC
               Jon Saperia, DEC
               John Seligson
               Fei Shu, NEC
               Sam Sjogren, TGV
               Mark Sleeper, Sparta


SNMP & Transmission MIB Working Groups                         [Page 36]

RFC 1233                 DS3 Interface Objects                  March 1992


               Lance Sprung
               Mike St.Johns
               Bob Stewart, Xyplex
               Emil Sturniold
               Kaj Tesink, Bellcore
               Dean Throop, Data General
               Bill Townsend, Xylogics
               Maurice Turcotte
               Kannan Varadhou
               Sudhanshu Verma, HP
               Warren Vik, Interactive Systems
               David Waitzman, BBN
               Steve Waldbusser, CMU
               Dan Wintringhan
               David Wood
               Jeff Young, Cray Research

7.  References

   [1] Cerf, V., "IAB Recommendations for the Development of Internet
       Network Management Standards", RFC 1052, NRI, April 1988.

   [2] Cerf, V., "Report of the Second Ad Hoc Network Management Review
       Group", RFC 1109, NRI, August 1989.

   [3] Rose M., and K. McCloghrie, "Structure and Identification of
       Management Information for TCP/IP-based internets", RFC 1155,
       Performance Systems International, Hughes LAN Systems, May 1990.

   [4] 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.

   [5] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
       Network Management Protocol", RFC 1157, SNMP Research,
       Performance Systems International, Performance Systems
       International, MIT Laboratory for Computer Science, May 1990.

   [6] McCloghrie K., and M. Rose, Editors, "Management Information Base
       for Network Management of TCP/IP-based internets", RFC 1213,
       Performance Systems International, March 1991.

   [7] Information processing systems - Open Systems Interconnection -
       Specification of Abstract Syntax Notation One (ASN.1),
       International Organization for Standardization, International
       Standard 8824, December 1987.

   [8] 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.

   [9] American National Standard for telecommunications - digital
       hierarchy - electrical interfaces, ANSI T1.102- 1987.

 


SNMP & Transmission MIB Working Groups                         [Page 37]

RFC 1233                 DS3 Interface Objects                  March 1992


  [10] American National Standard for telecommunications - digital
       hierarchy - formats specification, ANSI T1.107- 1988.

  [10a] ANSI T1.107a-1990.

  [11] American National Standard for telecommunications - Carrier-to-
       Customer Installation - DS3 Metallic Interface, ANSI T1.404-1989.

  [12] In-Service Digital Transmission Performance Monitoring Draft
       Standard, T1M1.3/91 - 003R3.

  [13] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions",
       RFC 1212, Performance Systems International, Hughes LAN Systems,
       March 1991.

8.  Security Considerations

   Security issues are not discussed in this memo.

9.  Authors' Addresses

   Tracy A. Cox
   Bell Communications Research
   331 Newman Springs Road
   P.O. Box 7020
   Red Bank, NJ  07701-7020

   Phone: (908) 758-2107

   EMail: tacox@sabre.bellcore.com


   Kaj Tesink
   Bell Communications Research
   331 Newman Springs Road
   P.O. Box 7020
   Red Bank, NJ  07701-7020

   Phone: (908) 758-5254

   EMail: kaj@nvuxr.cc.bellcore.com








SNMP & Transmission MIB Working Groups                         [Page 38]











Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa00782;
          12 Mar 92 15:05 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa20920;
          12 Mar 92 15:06 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa20916;
          12 Mar 92 15:06 EST
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA15569; Thu, 12 Mar 92 12:00:23 PST
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA26666; Thu, 12 Mar 92 14:59:41 EST
Return-Path: <tacox@ginsu4@sabre.bellcore.com>
Received: from localhost by ginsu4 (4.1/4.7)
	id AA04689; Thu, 12 Mar 92 14:59:29 EST
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9203121959.AA04689@ginsu4>
To: trunk-mib@acc.com, ietf@isi.edu
Subject: agenda for trunk-mib wg meeting 
In-Reply-To: Your message of "Thu, 12 Mar 92 14:14:15 EST."
             <9203121914.AA04674@ginsu4> 
Date: Thu, 12 Mar 92 14:59:28 -0500
From: tacox@ginsu4.bellcore.com

Gang,

This is the agenda for trunk-mib working group
to be held on Monday March 16th from 4-6.

The trunk-mib working group will meet to 
discuss RFC1232 (DS1 MIB) and RFC1233
(DS3 MIB).

Mailing List

o       General Discussion: trunk-mib@acc.com

o       To subscriber: trunk-mib-request@acc.com

o       Archive: saffron.acc.com

Trunk-MIB Working Group
Chairs


Fred Baker
fbaker@acc.com
Tracy A. Cox
tacox@sabre.bellcore.com


Trunk-MIB Working Group
Agenda
-->     Get feedback on implementation experience
-->	Review RFC1232 and RFC1233 comments
-	Review ds1LineIndex and ds1Index email discussions
-	Review the need for farEndTables
-	Review the need for added configuration information in DS3 MIB
-	Review new objects: ds1NewLoopback and ds1AlarmState
(same for both DS1 and DS3)

Trunk-MIB Working Group
Feedback Received:

	Add Far End Information -- as optional tables
	Add more alarm information -- ds1AlarmState
	Consistency with standards -- updated Terminology section
	Can't "CSU" MIB be used to manage other DS1 interfaces?

Other Changes:

-	Removal of CSSs from RFC1233
-	Additional otherCVs count in RFC1233










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa01202;
          12 Mar 92 22:59 EST
Received: from venera.isi.edu by NRI.Reston.VA.US id aa07045;
          12 Mar 92 22:59 EST
Received: by venera.isi.edu (5.65c/5.65+local-3)
	id <AA18719>; Thu, 12 Mar 1992 12:00:27 -0800
Received: from sabre.bellcore.com by venera.isi.edu (5.65c/5.65+local-3)
	id <AA18709>; Thu, 12 Mar 1992 12:00:21 -0800
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA26666; Thu, 12 Mar 92 14:59:41 EST
Return-Path: <tacox@ginsu4@sabre.bellcore.com>
Received: from localhost by ginsu4 (4.1/4.7)
	id AA04689; Thu, 12 Mar 92 14:59:29 EST
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9203121959.AA04689@ginsu4>
To: trunk-mib@acc.com, ietf@isi.edu
Subject: agenda for trunk-mib wg meeting 
In-Reply-To: Your message of "Thu, 12 Mar 92 14:14:15 EST."
             <9203121914.AA04674@ginsu4> 
Date: Thu, 12 Mar 92 14:59:28 -0500
From: tacox@ginsu4.bellcore.com

Gang,

This is the agenda for trunk-mib working group
to be held on Monday March 16th from 4-6.

The trunk-mib working group will meet to 
discuss RFC1232 (DS1 MIB) and RFC1233
(DS3 MIB).

Mailing List

o       General Discussion: trunk-mib@acc.com

o       To subscriber: trunk-mib-request@acc.com

o       Archive: saffron.acc.com

Trunk-MIB Working Group
Chairs


Fred Baker
fbaker@acc.com
Tracy A. Cox
tacox@sabre.bellcore.com


Trunk-MIB Working Group
Agenda
-->     Get feedback on implementation experience
-->	Review RFC1232 and RFC1233 comments
-	Review ds1LineIndex and ds1Index email discussions
-	Review the need for farEndTables
-	Review the need for added configuration information in DS3 MIB
-	Review new objects: ds1NewLoopback and ds1AlarmState
(same for both DS1 and DS3)

Trunk-MIB Working Group
Feedback Received:

	Add Far End Information -- as optional tables
	Add more alarm information -- ds1AlarmState
	Consistency with standards -- updated Terminology section
	Can't "CSU" MIB be used to manage other DS1 interfaces?

Other Changes:

-	Removal of CSSs from RFC1233
-	Additional otherCVs count in RFC1233










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa00624;
          13 Mar 92 13:18 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa28162;
          13 Mar 92 13:19 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa28158;
          13 Mar 92 13:19 EST
Received: from mace.LCS.MIT.EDU by fennel.acc.com (4.1/SMI-4.1)
	id AA16117; Fri, 13 Mar 92 10:12:54 PST
Received: from MACE.LCS.MIT.EDU by mace.LCS.MIT.EDU via TCP with SMTP
	id AA00556; Fri, 13 Mar 92 13:12:40 EST
Message-Id: <9203131812.AA00556@mace.LCS.MIT.EDU>
From: "James R. (Chuck) Davin" <jrd@thyme.lcs.mit.edu>
To: tacox@ginsu4.bellcore.com
Cc: trunk-mib@acc.com
Subject: Re: agenda for trunk-mib wg meeting 
In-Reply-To: Your message of Thu, 12 Mar 92 14:59:28 -0500.
             <9203121959.AA04689@ginsu4> 
Date: Fri, 13 Mar 92 13:12:38 -0500
Sender: jrd@mace.lcs.mit.edu


Tracy, Fred,

I hope to attend the trunk-mib mtg. Could I ask how the chairs would
feel about two additional agenda items?

(1) Documentation of operational experience/alignment concerns that
motivates each potential additional object.

(2) The potential use of this MIB to manage "modem farms" and
associated interactions with existing management stations.

I realize you have a full plate already, but these may even be
interesting.

Chuck










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa00642;
          13 Mar 92 13:42 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa29457;
          13 Mar 92 13:43 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa29452;
          13 Mar 92 13:43 EST
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA16186; Fri, 13 Mar 92 10:36:12 PST
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA04537; Fri, 13 Mar 92 13:35:37 EST
Return-Path: <tacox@ginsu4@sabre.bellcore.com>
Received: from localhost by ginsu4 (4.1/4.7)
	id AA04952; Fri, 13 Mar 92 13:35:29 EST
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9203131835.AA04952@ginsu4>
To: "James R. (Chuck) Davin" <jrd@thyme.lcs.mit.edu>
Cc: trunk-mib@acc.com
Subject: Re: agenda for trunk-mib wg meeting 
In-Reply-To: Your message of "Fri, 13 Mar 92 13:12:38 EST."
             <9203131812.AA00556@mace.LCS.MIT.EDU> 
Date: Fri, 13 Mar 92 13:35:27 -0500
From: tacox@ginsu4.bellcore.com

> 
> 
> 
> Tracy, Fred,
> 
> I hope to attend the trunk-mib mtg. Could I ask how the chairs would
> feel about two additional agenda items?
> 
> (1) Documentation of operational experience/alignment concerns that
> motivates each potential additional object.
> 
> (2) The potential use of this MIB to manage "modem farms" and
> associated interactions with existing management stations.
> 
> I realize you have a full plate already, but these may even be
> interesting.
> 
> Chuck


We will put them on the agenda.

Tracy










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa00648;
          13 Mar 92 13:47 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa29622;
          13 Mar 92 13:48 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa29618;
          13 Mar 92 13:48 EST
Received: from saffron.acc.com by fennel.acc.com (4.1/SMI-4.1)
	id AA16203; Fri, 13 Mar 92 10:41:50 PST
Received: by saffron.acc.com (4.1/SMI-4.1)
	id AA00660; Fri, 13 Mar 92 10:40:01 PST
Date: Fri, 13 Mar 92 10:40:01 PST
From: Fred Baker <fbaker@acc.com>
Message-Id: <9203131840.AA00660@saffron.acc.com>
To: jrd@thyme.lcs.mit.edu
Subject: Re: agenda for trunk-mib wg meeting
Cc: tacox@ginsu4.bellcore.com, trunk-mib@acc.com

>> I hope to attend the trunk-mib mtg. Could I ask how the chairs would
>> feel about two additional agenda items?

>> (1) Documentation of operational experience/alignment concerns that
>> motivates each potential additional object.

>> (2) The potential use of this MIB to manage "modem farms" and
>> associated interactions with existing management stations.

>> I realize you have a full plate already, but these may even be
>> interesting.

I have no particular problem with this, especially (2), which is
extremely obvious to the physical layer folks and distinctly foreign to
folks from about any layer above.

However, I find myself wondering if (1) is exactly the way to go?  I
know that this is the model followed in MIB-2, where the changes and
experience are detailed pretty explicitly.  I wonder, though, if it
would not be better to describe the utility of the objects in the
configuration table and the 'current' table, and then describe the
utility of the various tables - noting that the objects in them were
each at some point part of the 'current' table at a device.

Fred










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa01014;
          16 Mar 92 10:53 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa00538;
          16 Mar 92 10:54 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa00532;
          16 Mar 92 10:54 EST
Received: from tbird.cc.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA20534; Mon, 16 Mar 92 07:48:16 PST
Received: by tbird.cc.bellcore.com id AA17874
  (5.65c/IDA-1.4.4 for acc.com!trunk-mib); Mon, 16 Mar 1992 10:49:03 -0500
Message-Id: <199203161549.AA17874@tbird.cc.bellcore.com>
From: "t.r.farese" <trf@nvuxl.cc.bellcore.com>
To: trunk-mib@acc.com
Date: 16 Mar 1992  10:44 EST
Subject: Please subscribe me to this list

Thanks,
Thomas Farese
cc.bellcore.com!trf










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa00607;
          19 Mar 92 11:57 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa15712;
          19 Mar 92 11:59 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa15708;
          19 Mar 92 11:59 EST
Received: from vnet.ibm.com by fennel.acc.com (4.1/SMI-4.1)
	id AA24850; Thu, 19 Mar 92 08:53:08 PST
Message-Id: <9203191653.AA24850@fennel.acc.com>
Received: from RALVM29 by vnet.ibm.com (IBM VM SMTP V2R2) with BSMTP id 6154;
   Thu, 19 Mar 92 11:51:55 EST
Date: Thu, 19 Mar 92 11:50:57 EST
From: Russell Gardo <GARDO@ralvm29.vnet.ibm.com>
To: trunk-mib@acc.com
Subject: Removal from mailing list

Please remove me from this mailing list.  Thanks!










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa00643;
          19 Mar 92 12:52 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa17259;
          19 Mar 92 12:54 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa17250;
          19 Mar 92 12:54 EST
Received: from vnet.ibm.com by fennel.acc.com (4.1/SMI-4.1)
	id AA25026; Thu, 19 Mar 92 09:49:07 PST
Message-Id: <9203191749.AA25026@fennel.acc.com>
Received: from RALVM6 by vnet.ibm.com (IBM VM SMTP V2R2) with BSMTP id 6991;
   Thu, 19 Mar 92 12:48:30 EST
Date: Thu, 19 Mar 92 12:49:33 EST
From: Kirk Preiss <PREISS@ralvm6.vnet.ibm.com>
To: trunk-mib@acc.com
Subject: Removal from the mailing list

Please remove me from the mailing list. Thanks.

Kirk (preiss@ralvm6.vnet.ibm.com)











Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa00698;
          19 Mar 92 15:04 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa22001;
          19 Mar 92 15:06 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa21996;
          19 Mar 92 15:06 EST
Received: from vnet.ibm.com by fennel.acc.com (4.1/SMI-4.1)
	id AA25780; Thu, 19 Mar 92 12:03:00 PST
Message-Id: <9203192003.AA25780@fennel.acc.com>
Received: from RALVM29 by vnet.ibm.com (IBM VM SMTP V2R2) with BSMTP id 9015;
   Thu, 19 Mar 92 15:02:23 EST
Date: Thu, 19 Mar 92 15:01:09 EST
From: Russell Gardo <GARDO@ralvm29.vnet.ibm.com>
To: trunk-mib@acc.com
Subject: Mailing List Removal Request

Please remove me from this mailing list.  Thanks!
.










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa01572;
          23 Mar 92 13:02 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa07240;
          23 Mar 92 13:04 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa07230;
          23 Mar 92 13:04 EST
Received: from mace.LCS.MIT.EDU by fennel.acc.com (4.1/SMI-4.1)
	id AA02386; Mon, 23 Mar 92 09:54:51 PST
Received: from MACE.LCS.MIT.EDU by mace.LCS.MIT.EDU via TCP with SMTP
	id AA07847; Mon, 23 Mar 92 12:54:47 EST
Message-Id: <9203231754.AA07847@mace.LCS.MIT.EDU>
From: "James R. (Chuck) Davin" <jrd@thyme.lcs.mit.edu>
To: trunk-mib@acc.com
Subject: Numbering dsX entries
Date: Mon, 23 Mar 92 12:54:45 -0500
Sender: jrd@mace.lcs.mit.edu


Fred,

In the working group meeting at San Diego, I raised a concern that the
proposed numbering of the dsX entries in the various tables of the DS*
MIBs did not preserve the MIB 2 convention that, for any entry in the
ifTable, one could find the corresponding media-specific information
by using the ifIndex value directly as an index into the relevant
media-specific table.

During the meeting (probably for want of food :-)), we failed to
formulate any solution to this problem. The next day (after more
food), a possible solution occured to me. I told you. You asked me to
post it to the list for further deliberation.

Summary of problem:

We want to preserve the property of the SNMP framework by which
media-specific info relating to a MIB 2 interface can be retreived
using the ifIndex value as an indicator into the relevant media
specific table. In the case of DS* media interfaces, we also want to
represent (by entries in the same media specific table) DS* media that
have no association with locally attached network interfaces in the
MIB 2 sense (e.g., a PC with an ether interface exporting MIB
information about a detached set of modems in another room). We want
to solve this problem in general so that an agent may export MIB
information about DS* interfaces associated with attached network
interfaces, DS* interfaces not associated with attached network
interfaces, or any combination.

Summary of solution:

Require that any DS* media interfaces for which the index is less than
or equal to ifNum are associated with attached network interfaces in
the traditional MIB 2 way (ifIndex == dsXLineIndex). For these
"attached" DS* media, ifIndex == dsxLineIndex == dsXIndex.

Any DS* media interfaces for which the index is greater than ifNum
(dsXLineIndex > ifNum) may or may not be associated with an attached
network interface.  In these cases, a value of dsXIndex > ifNum
signifies no association (i.e., the relevant DS* media is not
associated with any attached network interface: it is a random modem
that is not used by the local system to communicate with anybody).
Otherwise, the value of dsXIndex identifies the associated attached
network interface (dsXIndex == ifIndex). We only allow this latter
convention ((dsXLineIndex > ifNum) && (dsXIndex == ifIndex)) in cases
where there may be more than one DS* media associated with a
particular attached network interface. (Does this case ever arise in
reality?)

Proposed Text:

(1) Alter the DESCRIPTION clause of the dsXLineIndex object to be:

The index value that uniquely identifies the DS* interface to which
this entry is applicable.  If the value of an instance of the
dsXLineIndex object is less than or equal to the value of the relevant
instance of the ifNum object, then the DS* media interface identified
by that value of the dsXLineIndex object instance is associated with
the MIB 2 generic interface identified by the corresponding value of
the ifIndex object defined in MIB 2.  For any other value of a
dsXLineIndex object instance, any association between the DS* media
interface identified by that value and a MIB 2 generic interface is
independently represented by the corresponding instance of the
dsXIndex object.

(2) Alter the DESCRIPTION clause for the dsXIndex object to be:

The value of an instance of the dsXIndex object uniquely identifies a
MIB 2 generic interface with which the DS* media interface associated
with said object instance is associated.  A value greater than the
value of the relevant ifNum object instance signifies that the
relevant DS* media interface is not associated with any locally
represented MIB 2 generic interface. No instance of this object will
assume a value less than or equal to the relevant instance of the
ifNum object in the absence of some instance of the dsXLineIndex
object having that same value. For those instances of the dsXIndex
object for which the corresponding instance of the dsXLineIndex obejct
is less than or equal to the relevant instance of the ifNum object,
the value is always that of the corresponding dsXLineIndex object
instance.

Food for thought,
Chuck















Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa01588;
          23 Mar 92 13:19 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa08166;
          23 Mar 92 13:20 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa08161;
          23 Mar 92 13:20 EST
Received: from mace.LCS.MIT.EDU by fennel.acc.com (4.1/SMI-4.1)
	id AA02505; Mon, 23 Mar 92 10:14:48 PST
Received: from MACE.LCS.MIT.EDU by mace.LCS.MIT.EDU via TCP with SMTP
	id AA07879; Mon, 23 Mar 92 13:14:46 EST
Message-Id: <9203231814.AA07879@mace.LCS.MIT.EDU>
From: "James R. (Chuck) Davin" <jrd@thyme.lcs.mit.edu>
To: trunk-mib@acc.com
Subject: Something completely different
Date: Mon, 23 Mar 92 13:14:45 -0500
Sender: jrd@mace.lcs.mit.edu


The OBJECT DESCRIPTORS dsXLineIndex and dsXIndex seem counterintuitive
to me when considered in the larger context of MIB 2 and interfaces
and so forth. This is just a personal reaction. Would the names
dsXIndex and dsXIfIndex (respectively) be more appealing or helpful?

I have raised this point in a SEPARATE note because it is a SEPARATE
question from the issue of entry numbering raised in my previous note.
I also think it could be DISASTROUSLY CONFUSING to attempt to discuss
this SEPARATE issue in conjunction with the other one.

So, please do not even read this note, until discussion on the other
question is concluded :-).

Separately,
Chuck












Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa01615;
          23 Mar 92 13:37 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa09090;
          23 Mar 92 13:39 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa09080;
          23 Mar 92 13:39 EST
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA02569; Mon, 23 Mar 92 10:33:42 PST
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA26807; Mon, 23 Mar 92 13:29:14 EST
Return-Path: <tacox@ginsu4@sabre.bellcore.com>
Received: from localhost by ginsu4 (4.1/4.7)
	id AA05875; Mon, 23 Mar 92 13:33:01 EST
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9203231833.AA05875@ginsu4>
To: jrd@thyme.lcs.mit.edu
Cc: trunk-mib@acc.com
Subject: Re: Something completely different 
In-Reply-To: Your message of "Mon, 23 Mar 92 13:14:45 EST."
             <9203231814.AA07879@mace.LCS.MIT.EDU> 
Date: Mon, 23 Mar 92 13:32:59 -0500
From: tacox@ginsu4.bellcore.com

> 
> 
> 
> The OBJECT DESCRIPTORS dsXLineIndex and dsXIndex seem counterintuitive
> to me when considered in the larger context of MIB 2 and interfaces
> and so forth. This is just a personal reaction. Would the names
> dsXIndex and dsXIfIndex (respectively) be more appealing or helpful?
> 
> I have raised this point in a SEPARATE note because it is a SEPARATE
> question from the issue of entry numbering raised in my previous note.
> I also think it could be DISASTROUSLY CONFUSING to attempt to discuss
> this SEPARATE issue in conjunction with the other one.
> 
> So, please do not even read this note, until discussion on the other
> question is concluded :-).
> 
> Separately,
> Chuck
> 
> 
Chuck,

We did discuss this prior to the meeting in San Diego via email.
The consensus of the group was to minimize the changes:

Therefore, we agreed on

ds1CSUIndex = ds1LineIndex
ds1Index = ds1Index

What you suggested:

ds1CSUIndex = ds1Index
ds1Index = ds1IfIndex

the group thought that the new name for the ds1CSUIndex may be
confusing -- (it is the name of the old "other" object).
However, I like the name ds1IfIndex, because it draws attention
to the fact that it is associated with ifIndex from the interfaces
table from MIB II.

What about:

ds1CSUIndex = ds1LineIndex
ds1Index = ds1IfIndex

It does not minimize the changes, but it may eradicate some
confusion?

What does the group think about this suggestion?

Tracy










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa01686;
          23 Mar 92 14:31 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa11802;
          23 Mar 92 14:33 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa11795;
          23 Mar 92 14:33 EST
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA02676; Mon, 23 Mar 92 11:28:21 PST
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA27277; Mon, 23 Mar 92 14:23:41 EST
Return-Path: <tacox@sabre.bellcore.com>
Received: by ginsu4 (4.1/4.7)
	id AA05904; Mon, 23 Mar 92 14:27:30 EST
Date: Mon, 23 Mar 92 14:27:30 EST
From: Tracy Cox <tacox@sabre.bellcore.com>
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9203231927.AA05904@ginsu4>
To: atm@bbn.com, trunk-mib@acc.com, snmp@nisc.psi.net, jnc@lcs.mit.edu
Subject: SONET MIB

I am sending this mail out to the appropriate IETF
groups to gauge the interest in a SONET MIB Working
Group or BOF.  Kaj Tesink and I have written a
SONET MIB, and we want to know who is interested
in attending a meeting at the next IETF
(July 1992 in Boston, MA) to discuss it?

Tracy

===========================================
Tracy A. Cox
Bellcore
NVC 1C-354
331 Newman Springs Rd.
Red Bank, NJ  07701
tacox@sabre.bellcore.com email
(908) 758-2107 vmail
(908) 758-4177 fax
===========================================












Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa01698;
          23 Mar 92 14:45 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa12480;
          23 Mar 92 14:47 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa12469;
          23 Mar 92 14:47 EST
Received: from saffron.acc.com by fennel.acc.com (4.1/SMI-4.1)
	id AA02708; Mon, 23 Mar 92 11:39:37 PST
Received: by saffron.acc.com (4.1/SMI-4.1)
	id AA03620; Mon, 23 Mar 92 11:38:53 PST
Date: Mon, 23 Mar 92 11:38:53 PST
From: Fred Baker <fbaker@acc.com>
Message-Id: <9203231938.AA03620@saffron.acc.com>
To: jrd@thyme.lcs.mit.edu
Subject: Re:  Numbering dsX entries
Cc: trunk-mib@fennel.acc.com


Chuck:

Thanks for documenting that.  Every time I draw pictures for you, you
make a face, but I'm not sure how else to illustrate my dilemma.  I
have a couple of pictures I would like you to consider and make
recommendations on, as in, exactly what values should ds1Index and
ds1LineIndex have?

First, I have an ISDN Primary Rate <DS1 or E1> interface.  Attached to
B channels of it, I have:

        a LAPB Interface
        a PPP Interface
        a Frame Relay Interface
        an X.25 attachment using MLP across three B channels
        an SNA connection
        a number of remain channels drop-and-inserted to a PABX

        | SNA   |                                               |
        | Path  |                       IP                      |
        | Cntrl |                                               |
        +--+ +--+-+  +--+-+  +--+--+  +-+--------+  +-----------+-------+
        |       |       |       |       |                       | Q.931 |
        | Q.921 | PPP   | LAPB  | FFR   |       X.25 Packet     |       |
        | LAPD  |       |       |       +--------+  +-----------+--+ +--+
        |       |       |       |       |       MLP             | Q.921 |
        |       |       |       |       |                       | LAPD  |
        +--+ +--+-+  +--+-+  +--+--+  +-+-+  +--+-+  +--+--+  +-+--+ +--+
        |       |       |       |       |       |       |       |       |
        |   B   |   B   |   B   |   B   |   B   |   B   |   B   |   D   |
        |Channel|Channel|Channel|Channel|Channel|Channel|Channel|Channel|

This is the software architecture;  By the way, since this is ISDN, B
channels come and go quite a bit.  It's not obvious that the B channels
I am using in the morning will be used the same way all day, or that at
any given time I have *any* B channels getting me to IP.  It could well
be that an ISDN call is placed to the unit at the time that an SNMP GET
is being sent to the unit.

The hardware architecture looks like this:

                +---------------------------------------+
                |               Software                |
                |               Picture                 |
                |               Above                   |
                |           ---------------             |
                |           B channel Demux             |
                |           ---------------             |
                |                   V                   |
                |               +---+---+               |
                |       +-------|Drop/  |-------+       |
                |       |       |Insert |       |       |
                +---=======-------------------=======---+
                    | DS1 |                   | DS1 |
                    -------                   -------
                    to PABX                   to CSU

Now, as I read the title of the MIB, I am not trying to instrument
something related to IP, especially something that may only be related
to IP when I am looking at it.  I am trying to instrument the physical
DS1 interface, located a few miles below.

I assume that (as you have explained patiently to me that physical
interfaces that do not get you to IP have no corresponding ifEntry or
ifIndex) ds1LineIndex > ifNumber on the one going to the PABX.  There
are four <or more> IP interfaces associated with the DS1 going to the
CSU.  Which of those values should I use?

                ds1LineIndex    ds1Index
                ------------    --------
        to PABX    ifNumber+1   ifNumber+1
        to CSU     IP ifIndex   IP ifIndex   <== which one? does it matter?

Second picture:  The software model is the same, with the exception
that the router is using an RS-232 interface to proxy for the CSU.
Note that there exist CSU developments that place the SNMP agent inside
the CSU itself, but in terms of today's deployed CSUs, proxy is the only
way an external CSU can be managed via SNMP.

                +---------------------------------------+
                |               Software                |
                |               Picture                 |
                |               Above                   |
                |           ---------------             |
                |           B channel Demux             |
                |           ---------------             |
                |                   V                   |
                |               +---+---+               |
            +===+       +-------|Drop/  |-------+       |
            |   |       |       |Insert |       |       |
            |   +---=======-------------------=======---+
            |       | DS1 |                   | DS1 |
            |       -------                   -------
            |       to PABX                      ||
            |                                    ||DS1 Cable per
            |                                    ||Bell Specifications
            |RS-232                              ||
            |                                 -------
            |                                 | DS1 |
            |   +-----------------------------=======---+
            |   |                               |       |
            |   |                               |Circuit|
            +===+               CSU             |Path   |
                |                               |Through|
                |                               |CSU    |
                |                               |       |
                +-----------------------------=======---+
                                              | DS1 |
                                              -------
                                              to Network

In this picture, there are 4 DS1 interfaces.  The one which contains
the most useful information for network debugging purposes is the
network interface of the CSU.  I proposed that whatever the value of
ds1Index was in the previous picture should be the same value on EACH
of the three DS1 interfaces on the right side of this picture, although
ds1LineIndex > ifNumber for both of the interfaces on the CSU.

                ds1LineIndex    ds1Index
                ------------    --------
        to PABX    ifNumber+1   ifNumber+1
        to CSU     IP ifIndex   IP ifIndex
        CSU Equip  ifNumber+2   IP ifIndex
        CSU Net    ifNumber+3   IP ifIndex

You made a face and indicated that we needed to talk more.  Could you
comment?  What values would you like to see?

By the way, if we assme that the CSU has more than two DS1 interfaces,
that it is a dual or fractional CSU, could you comment on how I know,
inside the proxy system, which pair of DS1 interfaces is carrying my IP
traffic?

In the third picture, I draw what I think is *now* not a product (the
previous two are items you can purchase in the marketplace), but which
several folks on the list are in the process of developing.
Specifically, the question was raised whether Bill Versteeg was doing
the right thing in his implementation.

                +---------------+
                |               |
             +--+               +--+
             |D |               |D |
             |S |- - - - - - - -|S |
             |1 |               |1 |
             +--+               +--+
                |               |
                |               |
             +--+               +--+
             |D |               |D |
             |S |- - - - - - - -|S |
             |1 |               |1 |
             +--+               +--+
                |               |
                |               |
             +--+               +--+
             |D |               |D |
             |S |- - - - - - - -|S |
             |1 |               |1 |
             +--+               +--+
                |SNMP Agent     |
                |access via:    |
                |  - PPP link on facilities data link
                |  - PPP/SLIP link on RS-232
                |  - PPP on one ISDN channel
                |  - etc
                +---------------+

Given the definition of ifNumber (from RFC 1213):

3.5.  The Interfaces Group

   The definition of the ifNumber object was incorrect, as it required
   all interfaces to support IP.  (For example, devices without IP, such
   as MAC-layer bridges, could not be managed if this definition was
   strictly followed.)  The description of the ifNumber object is
   changed accordingly.
---
          ifNumber OBJECT-TYPE
              SYNTAX  INTEGER
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The number of network interfaces (regardless of
                      their current state) present on this system."
              ::= { interfaces 1 }

You seem to feel that the word "network" in this context refers to the
Network Layer - how one gets to IP.  I note that, at least according to
the bodies that define them, bridging is *not* a network layer
protocol, and the X.25 packet *is*.  And if one can accept that
"interface" may refer you to something that can't get you to IP, the
physical interpretation of "interface" makes an awful lot of sense in a
CSU.

But, I can accept your interpretation, if you will clarify some
issues.  Specifically, it seems to me that the most useful use of
ds1Index in this context is to indicate which interfaces are paired
together:

                        ds1LineIndex    ds1Index
                        ------------    --------
        top-left        ifNumber+1      ifNumber+1
        top-right       ifNumber+2      ifNumber+1
        center-left     ifNumber+3      ifNumber+3
        center-right    ifNumber+4      ifNumber+3
        bottom-left     ifNumber+5      ifNumber+5
        bottom-right    ifNumber+6      ifNumber+5

This is not possible if ds1Index is contrained to 1..ifNumber.  Now,
Bill has taken the approach that the interfaces on the device are
easily enumerated: ifNumber=6, and set ds1LineIndex==ds1Index for
each.  Taking the way I view ifIndex - which  you and I disagree on, a
disagreement of longstanding - he's absolutely correct, but ds1Index
provides no useful information.

                        ds1LineIndex    ds1Index
                        ------------    --------
        top-left        1               1
        top-right       2               2
        center-left     3               3
        center-right    4               4
        bottom-left     5               5
        bottom-right    6               6

When you and I spoke the other day, you felt that the following was
the one true religion:

        ifNumber=1      ds1LineIndex    ds1Index
                        ------------    --------
        top-left        2               1
        top-right       3               1
        center-left     4               1
        center-right    5               1
        bottom-left     6               1
        bottom-right    7               1

Could you explain the rationale behind your preference?

Chuck, I think you should understand that ds*Index is *your variable*.
It is not in T1M1, and is providing no particular utility to the folks
who are trying to use the MIB.  I am bending over backward to give you
what you want in this, but you have to provide clear unambiguous
wording, and a very clear and unassailable defence of that selection,
so that I don't have to spend the rest of my life answering the
questions "what is this variable for? have I got it right?" The argument
"TRADITION" doesn't stand up.

Fred










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa02367;
          23 Mar 92 18:02 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa21209;
          23 Mar 92 18:03 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa21205;
          23 Mar 92 18:03 EST
Received: from mace.LCS.MIT.EDU by fennel.acc.com (4.1/SMI-4.1)
	id AA03267; Mon, 23 Mar 92 14:56:15 PST
Received: from MACE.LCS.MIT.EDU by mace.LCS.MIT.EDU via TCP with SMTP
	id AA08223; Mon, 23 Mar 92 17:56:08 EST
Message-Id: <9203232256.AA08223@mace.LCS.MIT.EDU>
From: "James R. (Chuck) Davin" <jrd@thyme.lcs.mit.edu>
To: Fred Baker <fbaker@acc.com>
Cc: trunk-mib@fennel.acc.com
Subject: Re: Numbering dsX entries 
In-Reply-To: Your message of Mon, 23 Mar 92 11:38:53 -0800.
             <9203231938.AA03620@saffron.acc.com> 
Date: Mon, 23 Mar 92 17:56:03 -0500
Sender: jrd@mace.lcs.mit.edu


Fred,

Thanks for your reply. I'm working at home just now, and I'm having
trouble perusing your pictures 20 lines at a time. I will print your
note later and take a shot at answering the nuts-and-bolts questions
of the "what number goes here" genre. My sense is that those answers
are pretty straightforward, once I get to a bigger screen :-).

There is a larger question raised by your note though. My proposal was
trying to solve the (fairly simple) problem of numbering dsX table
entries so that they can represent info about both attached network
interfaces and unattached DS* media (e.g., random modems) in a way
that is consistent with the other transmission MIBs.

Your reply raises a more complicated issue, which, for historical
reasons, has come to be known informally as "the Wellfleet problem."
This is the problem of representing protocol-user-protocol-service
relations among protocol entities. E.g., when a single DS1 channel is
demuxed into several DS0s, and these are used independently by an IP
protocol entity, how are these relationships represented in the MIB?
E.g., perhaps more bizarrely, when multiple DS0s are ganged together
to simulate a single DS1 channel, how are these relationships
represented in the MIB? The range of hideous combinations is limited
only by the human imagination ...  dum, dum, dum, dum, ... yes, you
have entered the twilight zone.

Some observations:

(1) The scope of this problem transcends the DS* media work. It is a
very general problem.

(2) There are actual products out there that manifest these
relationships. It is a very real problem.

(3) This problem has been recognized and discussed in IETF WGs since
1988 or before. It is a very known problem.

(4) Solutions to this general problem have been proposed to the
community on at least three separate occasions, but the response in
each case (to my personal disappointment) has been less than lukewarm.
It is a very recalcitrant problem.

(5) MIB 2 agents and managers are now widely deployed and the basis of
daily operation in production networks. It is an operationally
sensitive problem.

I believe that we can solve the numbering problem and thereby use the
DS* MIBs to manage both attached network interfaces and random modems.
I believe that this particular, fairly simple problem can be solved in
a way that is consistent with MIB 2, other transmission MIBs and
existing NMSs. My particular proposal may not be the right answer, but
the problem doesn't seem too awfully hard.

Of the harder, general problem of relations among protocol entities,
it is not clear that the community is well-served by its being
addressed in the context of individual media MIB efforts (e.g., trunk
MIB, X.25 MIB, ether MIB).

If you are suggesting that the time is now right to (re)consider this
problem in a general context, then perhaps it is time to (re)evaluate
the constituency and likely operational impact of such work. I, for
one, would welcome a tidal wave of support in this direction, but, so
far, my feet have been hardly damp.

In short, I read your note as comprising two problems: one easy (to
which I offered an easy answer in my previous note) and one hard (on
which I have commented above). My proposal was premised on the belief
that it makes little sense to break the conventions of MIB 2 and the
other transmission MIBs in order to get a partial solution to a very
general, hard problem that really wants a general solution anyway.

Regards,
Chuck
















Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa02391;
          23 Mar 92 18:25 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa21816;
          23 Mar 92 18:27 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa21812;
          23 Mar 92 18:27 EST
Received: from saffron.acc.com by fennel.acc.com (4.1/SMI-4.1)
	id AA03337; Mon, 23 Mar 92 15:21:22 PST
Received: by saffron.acc.com (4.1/SMI-4.1)
	id AA03851; Mon, 23 Mar 92 15:20:50 PST
Date: Mon, 23 Mar 92 15:20:50 PST
From: Fred Baker <fbaker@acc.com>
Message-Id: <9203232320.AA03851@saffron.acc.com>
To: jrd@thyme.lcs.mit.edu
Subject: Re: Numbering dsX entries
Cc: trunk-mib@fennel.acc.com


Chuck:

I think I can understand why this problem is called "the Wellfleet
Problem"; Wellfleet has made doing "telephony" things with DS1 a key
product offering since day one.  I guess what I've been trying to say
is that that problem is *very relevant* to DS1; If a succinct statement
of "the Wellfleet Problem" is that enumeration of network layer
interfaces and enumeration of hardware interfaces doesn't work out the
same, I have a largish crowd of people who are of the opinion that the
MIB doesn't work real well if the enumeration isn't fixed in a way that
makes sense to a non-IP person.

>> We only allow this latter convention ((dsXLineIndex > ifNum) &&
>> (dsXIndex == ifIndex)) in cases where there may be more than one DS*
>> media associated with a particular attached network interface. (Does
>> this case ever arise in reality?)

I think that this case decscribes the case where a router has a DS1
interface attached to a CSU, and is offering a proxy on behalf of the CSU.
I have some specific questions re: this case in the second picture.

Concerning your two description proposals, I think I'll see if I can find
a way to say it in fewer words.  I will specifically avoid two words
in them:

		SNMP-speak			DS1-speak

"interface"	the way one gets to IP		a 15 pin D connector
"network"	IP				telco

Looking forward to your reply re: my pictures.

Fred










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa02570;
          24 Mar 92 0:13 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa00612;
          24 Mar 92 0:15 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa00608; 24 Mar 92 0:15 EST
Received: from nrc.com (aztec.NRC.COM) by fennel.acc.com (4.1/SMI-4.1)
	id AA03955; Mon, 23 Mar 92 21:10:39 PST
Received: by nrc.com (4.0/NRC-DDN1.2)
	id AA14153; Mon, 23 Mar 92 20:18:30 PST
Date: Mon, 23 Mar 92 20:18:30 PST
From: Bill Versteeg <bvs@nrc.com>
Message-Id: <9203240418.AA14153@nrc.com>
To: trunk-mib@acc.com
Subject: DSx entries and the MIB2 interface table
Cc: bvs@nrc.com


My name seems to have been thrown into the ring as a supporter
of the "one cable == one entry in the interface table "
camp. While this happens to be the way I implemented rfc1232,
I have no religious problem with using DS1LineIndex as the table
index of importance. When I implemented this MIB, I brought
my own set of SNMP baggage with me. This baggage included
the somewhat quaint notions of interfaces as seen in routers, MAC 
bridges and terminal servers.

Whichever way we go, lets be sure that the rfc is unambiguous.
Sometimes the mapping of interfaces is left up to the
implementor, which I think is the biggest interoperability
problem in SNMP today.

Taking one step back from the nitty-gritty of the exact
case studies, the question becomes a trade-off between
the following contradictory facts.

	There is not much in the MIB2 interface table 
	that is of interest to someone managing DSx devices.
	Packet counts, errors, queue lengths, etc
	are just not kept.

	The average SNMP consumer wants to see at least
	as many entries in his interface table as cables in the back
	of the device he is modelling using SNMP.
	This is his model, and he is accustomed to it.


Bill VerSteeg











Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id ab01103;
          24 Mar 92 12:30 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa14878;
          24 Mar 92 12:32 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa14872;
          24 Mar 92 12:32 EST
Received: from saffron.acc.com by fennel.acc.com (4.1/SMI-4.1)
	id AA12206; Tue, 24 Mar 92 09:09:47 PST
Received: by saffron.acc.com (4.1/SMI-4.1)
	id AA04012; Tue, 24 Mar 92 09:08:54 PST
Date: Tue, 24 Mar 92 09:08:54 PST
From: Fred Baker <fbaker@acc.com>
Message-Id: <9203241708.AA04012@saffron.acc.com>
To: bvs@nrc.com
Subject: Re:  DSx entries and the MIB2 interface table
Cc: trunk-mib@acc.com

Bill:

I'm sorry if I implied that you were of one persuasion or another.
Last week, the question was raised in so many words "this is what Bill
did, was he right?" I repeated the question.

I am willing to have network layer interfaces be associated with B
channels, that's OK.  What I am concerned about is that there is no
necessary correlation between identifiable connectors and IP network
layer interfaces *at all*.  Frankly, if it was anyone else, I would be
saying "Out of scope.  IP's not in the physical layer."

Fred










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa02414;
          24 Mar 92 23:27 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa05622;
          24 Mar 92 23:29 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa05616;
          24 Mar 92 23:29 EST
Received: from nrc.com (aztec.NRC.COM) by fennel.acc.com (4.1/SMI-4.1)
	id AA13828; Tue, 24 Mar 92 20:23:22 PST
Received: by nrc.com (4.0/NRC-DDN1.2)
	id AA24682; Tue, 24 Mar 92 19:31:17 PST
Date: Tue, 24 Mar 92 19:31:17 PST
From: Bill Versteeg <bvs@nrc.com>
Message-Id: <9203250331.AA24682@nrc.com>
To: trunk-mib@acc.com
Subject: sparse vs dense interface tables
Cc: bvs@nrc.com


In our discussions of interface tables,
I noticed that everyone has been assuming dense tables
(i.e the interfaces are numbered 1,2,3,4,5,6...
and not 1,6,89,102,13445).

This does not present a problem for me, as this is
the way I usually number interfaces. However,
this is not the case in some MIB2 compliant implementations.
In reading through some of the proposals for mapping
CSUs (or DSx entities, depending on one's reference point)
onto interfaces, some of the schemes seem to want to
see dense tables. For instance, the phrase
"if CSuifIndex > nuber of interfaces" breaks down
if the interface table is sparse.

Or am I dreaming again????

Bill VerSteeg










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa00702;
          25 Mar 92 9:18 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa11546;
          25 Mar 92 9:20 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa11541; 25 Mar 92 9:20 EST
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA21997; Wed, 25 Mar 92 06:15:37 PST
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA12969; Wed, 25 Mar 92 09:11:02 EST
Return-Path: <tacox@sabre.bellcore.com>
Received: by ginsu4 (4.1/4.7)
	id AA00619; Wed, 25 Mar 92 09:11:51 EST
Date: Wed, 25 Mar 92 09:11:51 EST
From: Tracy Cox <tacox@sabre.bellcore.com>
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9203251411.AA00619@ginsu4>
To: trunk-mib@acc.com
Subject: minutes and draft

Gang,

At the IETF meeting we agreed to remove
the suggested added configuration information
from the DS3 MIB, because it was felt
that this is just the information that
the NMS should have in its database.

If we remove the information, then there
is not Far End Configuration Information.

This is not a problem; I just want to point
it out to everyone to see if they agree.

Ed?

Tracy











Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa00888;
          25 Mar 92 10:33 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa14157;
          25 Mar 92 10:35 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa14153;
          25 Mar 92 10:35 EST
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA22094; Wed, 25 Mar 92 07:30:19 PST
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA13785; Wed, 25 Mar 92 10:25:46 EST
Return-Path: <tacox@ginsu4@sabre.bellcore.com>
Received: from localhost by ginsu4 (4.1/4.7)
	id AA00674; Wed, 25 Mar 92 10:26:34 EST
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9203251526.AA00674@ginsu4>
To: Fred Baker <fbaker@acc.com>
Cc: trunk-mib@acc.com
Subject: Re: Question re: my pictures 
In-Reply-To: Your message of "Mon, 23 Mar 92 15:22:43 PST."
             <9203232322.AA03855@saffron.acc.com> 
Date: Wed, 25 Mar 92 10:26:33 -0500
From: tacox@ginsu4.bellcore.com

> 
> 
> 
> Are you as confused about having a compass needle pointing to IP
> as I am?
> 
> fred


I am trying to understand your pictures.

I understood your second mail message about the case
where a Router has a LAN interface (ifIndex = 1)
and a DS1 interface (ifIndex = 2 and DS1LineIndex = 1 or should
it be equal to 2)
with a CSU whose information is proxied for.

The CSU has ifIndex = 2 and DS1LineIndex = 3
for one interface and ifIndex = 2 and DS1LineIndex = 4
for the other DS1 interface as per Chuck's definition.

I think that this is a very likely case.

Your other pictures -- I am trying to figure out.

Tracy










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id ab01074;
          25 Mar 92 11:54 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa17140;
          25 Mar 92 11:56 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa17135;
          25 Mar 92 11:56 EST
Received: from saffron.acc.com by fennel.acc.com (4.1/SMI-4.1)
	id AA22273; Wed, 25 Mar 92 08:49:48 PST
Received: by saffron.acc.com (4.1/SMI-4.1)
	id AA04422; Wed, 25 Mar 92 08:47:54 PST
Date: Wed, 25 Mar 92 08:47:54 PST
From: Fred Baker <fbaker@acc.com>
Message-Id: <9203251647.AA04422@saffron.acc.com>
To: tacox@sabre.bellcore.com, trunk-mib@acc.com
Subject: Re:  minutes and draft

Can the far end configuration information be obtained via the
facilities data link, like the statistics can?  Information that can be
obtained in this manner might be worthwhile to preserve.

Fred










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa01146;
          25 Mar 92 12:03 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa17416;
          25 Mar 92 12:05 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa17412;
          25 Mar 92 12:05 EST
Received: from saffron.acc.com by fennel.acc.com (4.1/SMI-4.1)
	id AA22291; Wed, 25 Mar 92 08:59:35 PST
Received: by saffron.acc.com (4.1/SMI-4.1)
	id AA04434; Wed, 25 Mar 92 08:59:05 PST
Date: Wed, 25 Mar 92 08:59:05 PST
From: Fred Baker <fbaker@acc.com>
Message-Id: <9203251659.AA04434@saffron.acc.com>
To: bvs@nrc.com
Subject: Re:  sparse vs dense interface tables
Cc: trunk-mib@acc.com


>> In our discussions of interface tables, I noticed that everyone has
>> been assuming dense tables (i.e the interfaces are numbered
>> 1,2,3,4,5,6...  and not 1,6,89,102,13445).

>> This does not present a problem for me, as this is the way I usually
>> number interfaces. However, this is not the case in some MIB2 compliant
>> implementations.  In reading through some of the proposals for mapping
>> CSUs (or DSx entities, depending on one's reference point) onto
>> interfaces, some of the schemes seem to want to see dense tables. For
>> instance, the phrase "if CSuifIndex > nuber of interfaces" breaks down
>> if the interface table is sparse.

Bill:

Actually, I think the current discussion is assuming sparse tables.

If I am building a device with, say, two T1s and an Ethernet, I won't
associate a set of ds1 tables with the Ethernet.  If I have an
alternate connector, for a drop-and-insert or a through path, it is
supposed to have (in the latest proposals) ds1LineIndex > ifNumber.  If
the Ethernet has ifIndex == 3, then the ds1 interface numbers would be
1,2,4,5, or perhaps something even more disparate.

I am not assuming dense numbering for ds1LineIndex.  I *don't* assume
that ifNumber is the number of interfaces, although that's what the
spec says and what I implement; I assume that 1 <= ifIndex <= ifNumber.

Fred










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa01651;
          25 Mar 92 15:21 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa25162;
          25 Mar 92 15:23 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa25142;
          25 Mar 92 15:23 EST
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA22825; Wed, 25 Mar 92 12:13:44 PST
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA17185; Wed, 25 Mar 92 15:09:00 EST
Return-Path: <tacox@ginsu4@sabre.bellcore.com>
Received: from localhost by ginsu4 (4.1/4.7)
	id AA01028; Wed, 25 Mar 92 15:09:49 EST
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9203252009.AA01028@ginsu4>
To: trunk-mib@acc.com
Subject: new loopback object and configuration information
Date: Wed, 25 Mar 92 15:09:48 -0500
From: tacox@ginsu4.bellcore.com


Gang,

Because the far-end configuration information is received over
the line from the far-end, I will add it to the Far End Optional Group
as a Far End Configuration Group.

Here is the text from the draft of the internet-draft on the new Loopback object
and lineStatus object.


 ds3NewLoopback OBJECT-TYPE
                        SYNTAX  INTEGER {
                                    ds3NoLoop(1),
                                    ds3MgrLoop(2),
                                    ds3MgrLineLoop(3),
                                    ds3NetPayloadLoop(4),
                                    ds3NetLineLoop(5),
                                    ds3OtherLoop(6)
                                }
                        ACCESS  read-only
                        STATUS  mandatory
                        DESCRIPTION
                                "This variable represents the loopback state of
                                the DS3 interface.  Agents supporting read/write
                                access should return badValue in response to a
                                requested loopback state that the interface does
                                not support.
                                The values mean:

                                      ds3NoLoop

                                        Not in the loopback state.  A device that is
                                        not capable of performing a loopback on
                                        the interface shall always return this as
                                        it's value.
                                     ds3MgrLoop

                                        The loopback at one interface
is looped through
                                        the device; this loopback was
initiated by the network
                                        manager of the device.

                                      ds3MgrLineLoop

                                        The DS3 Line loopback at one
                                        interface does not go through
                                        the device but is looped back
out; this loopback is
                                        initiated by the network
manager of the device.

                                      ds3NetPayloadLoop

                                        The DS3 Payload loopback at one
                                        interface does not go through
                                        the device but is looped back
out; this loopback is
                                        initiated by the public network.

                                      ds3NetLineLoop

                                        The DS3 Line loopback at one
                                        interface does not go through
                                        the device but is looped back
out; this loopback is
                                        initiated by the public network.
                                     ds3OtherLoop

                                        Loopbacks that are not defined here.

                                Note that M23 and ClearChannel interfaces do not
                                support the Loopback managed object."
                        ::= { ds3ConfigEntry 12 }

                    ds3LineStatus OBJECT-TYPE
                        SYNTAX  INTEGER {
                                    ds3NoAlarm(1),
                                    ds3FarEndAlarm(2),
                                    ds3AlarmIndicationSignal(3),
                                    ds3OutOfFrame(4),
                                    ds3LossOfSignal(5),
                                    ds3LoopbackState(6)
                                }
                        ACCESS  read-only
                        STATUS  mandatory
                        DESCRIPTION
                              "This variable indicates the
                              Line Status of the interface.
                              It contains loopback state information
                              and alarm state information.
                              If multiple alarm states are occurring
                              simultaneously, then the highest
                              priority alarm state is the one set.  From
                              highest to lowest the alarm state priorities are
                              the following:  ds3LossOfSignal, ds3OutOfFrame,
                              ds3AlarmIndicationSignal, and ds3FarEndAlarm."
                        ::= { ds3ConfigEntry 13 }


What do y`all think?  Is this what we agreed to?


See below message. Dan Park from Kentrox is suggesting new words for the
loopback object. 

 He also does not like the loopbackState in the LineStatus object,
but it does provide for one stop shopping.  I also found an email message that IBM
sent me requesting that we add the loopbackState to the LineStatus
object.  I suggest we
keep it in there.

Also, I drew a picture at the IETF meeting in which a loopback request
came across a line (DS1 or other), into the box to the remote interface,
back through the device, and out across the same line as before.  We called
this a MgrLoop at the meeting.  See about ds3NewLoopback object.

  Is this a valid loopback?  Does this loopback
go across DS1 lines and through CSUs and back across the same DS1 line?
I have been told that the remote interface will send out AIS on the line.
The incoming signal (should signal a RemoteAlarm) will be dropped on the floor.
The LineStatus should reflect ds*RemoteAlarm and not loopback.
How should this loopback be reflected in the MIB and for what interface (remote
interface or interface that is between the loopback requester and the
looping device -
non-remote interface)?

Dan suggested that we drop this loopback type -- since it is usually
used for DSUs/CSUs
and not CSUs -- he also suggested that the non-remote interface should reflect the
loopback that goes through the device and back out on this interface.

Suggestions, comments?

Tracy

------- Forwarded Message

Return-Path: kentrox!ktxs1!park@uunet.uu.net
Received: by sword.bellcore.com;id 9203251817.AA17394
Return-Path: <kentrox!ktxs1!park@uunet.UU.NET@sabre.bellcore.com>
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA15850; Wed, 25 Mar 92 13:12:34 EST
Received: from relay2.UU.NET by thumper.bellcore.com (4.1/4.7)
	id <AA18699> for tacox@sabre.bellcore.com; Wed, 25 Mar 92 13:17:01 EST
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA00834; Wed, 25 Mar 92 13:15:49 -0500
Received: from kentrox.UUCP by uunet.uu.net with UUCP/RMAIL
	(queueing-rmail) id 131425.6161; Wed, 25 Mar 1992 13:14:25 EST
Received: from ktxs1.ktxnet by ktxnet (4.1/SMI-4.1)
	id AA08129; Wed, 25 Mar 92 09:57:32 PST
Received: by ktxs1.ktxnet (4.1/SMI-4.1)
	id AA03813; Wed, 25 Mar 92 09:58:48 PST
Date: Wed, 25 Mar 92 09:58:48 PST
From: kentrox!ktxs1!park@uunet.uu.net (Dan Park)
Message-Id: <9203251758.AA03813@ktxs1.ktxnet>
To: uunet!sabre.bellcore.com!tacox@uunet.uu.net
Subject: Re: DS3 MIB



Tracy,

Suggestions on the DS3 MIB:

   Change ds3NewLoopback to ds3LoopbackConfig
	Just a thought. I don`t like "New" very much.

   I have several other suggestions which I have included in the following
   modified text of the ds3LoopbackConfig object:

   ds3LoopbackConfig OBJECT-TYPE
          SYNTAX  INTEGER {
                      ds3NoLoop(1),
                      ds3MgrPayloadLoop(2),
                      ds3MgrLineLoop(3),
                      ds3NetPayloadLoop(4),
                      ds3NetLineLoop(5),
                      ds3OtherLoop(6)
                  }
          ACCESS  read-only
          STATUS  mandatory
          DESCRIPTION
                  "This variable represents the loopback configuration of
                  the DS3 interface.  Agents supporting read/write
                  access should return badValue in response to a
                  requested loopback state that the interface does not support.
                  The values mean:

                        ds3NoLoop

                          Not in the loopback state.  A device that is
                          not capable of performing a loopback on
                          the interface shall always return this as
                          it's value.

                        ds3MgrPayloadLoop

                          The received signal at this interface is looped through
                          the device; this loopback is initiated by a
                          manager of the device. Typically the received signal
                          is looped back for retransmission after it has
                          passed through the device's framing function.

                        ds3MgrLineLoop

                          The received signal at this interface does not
                          go through the device (minimum penetration) but
                          is looped back out; this loopback is initiated
                          by a manager of the device.

                        ds3NetPayloadLoop

                          The received signal at this interface is looped through
                          the device; this loopback is initiated by the
                          far end equipment. Typically the received signal
                          is looped back for retransmission after it has
                          passed through the device's framing function.

                        ds3NetLineLoop

                          The received signal at this interface does not
                          go through the device (minimum penetration) but
                          is looped back out; this loopback is initiated
                          by the far end equipment.

                        ds3OtherLoop

                          Loopbacks that are not defined here.

                  Note that M23 and ClearChannel interfaces do not
                  support the Loopback managed object."
          ::= { ds3ConfigEntry 12 }

     
   In the object ds3LineStatus, do you need the value ds3LoopbackState(6)?  This
   information can be retrieved by polling the object ds3NewLoopback
(ds3LoopbackConfig).

Call me or e-mail if you have any questions or comments.

Dan

------- End of Forwarded Message











Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa01657;
          25 Mar 92 15:36 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa25693;
          25 Mar 92 15:38 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa25687;
          25 Mar 92 15:38 EST
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA22851; Wed, 25 Mar 92 12:31:53 PST
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA17355; Wed, 25 Mar 92 15:27:18 EST
Return-Path: <tacox@sabre.bellcore.com>
Received: by ginsu4 (4.1/4.7)
	id AA01057; Wed, 25 Mar 92 15:28:08 EST
Date: Wed, 25 Mar 92 15:28:08 EST
From: Tracy Cox <tacox@sabre.bellcore.com>
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9203252028.AA01057@ginsu4>
To: trunk-mib@acc.com
Subject: Minutes from IETF Meeting

The minutes of the Trunk-MIB Working Group

IETF Meeting 3/16/92
San Diego, CA

Mailing List

o	General Discussion: trunk-mib@acc.com

o	To subscriber: trunk-mib-request@acc.com

o	Archive: saffron.acc.com

Chairs

Fred Baker:  fbaker@acc.com

Tracy A. Cox:  tacox@sabre.bellcore.com


Description and Charter

This working group will consider revisions to the DS1 and DS3 MIBs
(currently published as Proposed Stds in RFC 1232 and RFC 1233) in
preparation for their consideration as Draft Standards.  Consistent
with the IETF standards process, the working group is chartered to
consider only those changes to the DS1 and DS3 MIBs that are based on
implementation experience or on the need to align with relevant ANSI
T1M1 standards. In this context, the working group will thoroughly
document the implementation or alignment rationale for each considered
change.  All changes made by the working group will be consistent with
the existing SNMP framework and standards --- in particular, those
provisions of RFC 1155 regarding addition and deprecation of objects in
standard SNMP MIBs.  This working group will be a short-lived activity,
involving a single meeting, and will conclude its business no later
than June 1992.


Goals and Milestones

o       Jan 1992: Distribute draft of proposed revisions to DS1 and DS3
	MIBs together with documentation of supporting implementation
	experience
o       Mar 1992: A one-time only working group meeting as part of IETF
	meeting to review and discuss documents and formulate recommendation
	to IESG
o	Apr 1992: Deposit final document text as Internet Drafts for final
        review by WG membership and consideration by IESG

Agenda

o	Get feedback on implementation experience
o	Review RFC1232 and RFC1233 comments
-	Review ds1LineIndex and ds1Index email discussions
-	Review the need for farEndTables
-	Review the need for added configuration information
-	Review new objects: ds1Loopback and ds1AlarmState
-	Removal of CSSs from RFC1233
-	Additional otherCVs count in RFC1233

Feedback

o	Add Far End Information -- as optional tables
o	Add more alarm information -- ds1AlarmState
o	Consistency with standards -- updated Terminology section
o	Can't "CSU" MIB be used to manage other DS1 interfaces?


Implementation experience was received on RFC1232 and RFC1233.  Vendors
wanted the definitions of the counters to be consistent with T1M1
standards.  The working group agreed that the definitions should be
updated.  However, if the documents should conflict, vendors should
follow the definitions in the Internet DS1 and DS3 MIBs.  Text was
added to the internet-drafts to reflect this consensus.

Next, the need for far end information was discussed.  Vendors
requested that the far end information received from the DS1 and DS3
signal be collected in the MIBs.  The working group agreed that this
information should be added as an optional group.  The working group
agreed to structure the MIBs into two groups, the:

--  DS* Near End Group which is mandatory and
--  DS* Far End Group which is optional.

The Near End Group contains Configuration, Interval, Current, and Total
tables.  The Far End Group contains Configuration, Interval, Current, and Total
tables.

The working group also reviewed the request from a vendor that more
configuration information be added to the Configuration Table.  The
working group agreed that this information is important; however, it
should not be contained on the SNMP agent on the device.  The Network
Management Station should have this information in its database.
Therefore, the configuration information will not be added to the
MIBs.  This is only true for the Near End Group.
Since, the configuration information from the Far End is received
from the incoming signal, the Far End Configuration Table
does contain this information.
Therefore, the Far End Group does contain configuration
information. Only the circuitID object is contained
in the Near End Configuration
Table.

Based on vendor requests and consistency with T1M1 standard, some
objects were deprecated, and new objects were added.  This is true for
both DS1 and DS3 MIBs.

--  ds*Loopback has been deprecated.

--  A new object has been added called ds*NewLoopback,
    which better describes the loopback capabilities of
    a DS* interface on a device.

--  ds*YellowAlarm has been deprecated.

--  ds*RedAlarm has been deprecated.

--  A new object has been added called ds*LineStatus.
    This object better describes the status (e.g., alarm state and
    loopback state) of a DS* interface.

--  Only the ds3IntervalCSSs, ds3CurrentCSSs, and ds3TotalCSSs have
    been deprecated, because these counts are not collected on DS3
    interfaces.  They are retained in the DS1 MIB.

--  Additional objects and status are necessary to fully support E1;
    NewBridge will supply details, to be edited into the DS1 MIB.

The internet draft will reflect these changes.

Also, vendors requested that the DS1 and DS3 MIBs be used to manage
other devices other than CSUs.  Therefore, the MIBs are updated to
reflect this request.  The MIB manages DS1/DS3 interfaces.

The following objects have been changed to reflect this request:

--  ds*CSUIndex has been renamed ds*LineIndex.  This object
    is the identifier of a DS* Interface on a device.  If there is at
    least one ifEntry directly associated with the DS* interface (eg,
    if the DS* interface is used to communicate with the Network
    Layer), it should have the same value as ifIndex.  Otherwise, its
    value should exceed ifNumber.

--  ds*Index has been renamed ds*IfIndex.  This value for this
    object is equal to the value of ifIndex from the Interfaces
    table of MIB II (RFC 1213).  The utility of this object
    is under discussion.

The fractional table was deprecated from the DS1 MIB, because no one
implemented it or wanted it.

Since the changes to RFC1232 and RFC1233 were on the borderline of
being "too much", the group agreed to cycle at the Proposed Standard
status.  This implies that the Working Group will have a longer life
cycle than intended, probably on the order of a year.

New internet drafts reflecting these changes will be sent to
the trunk-mib mailing list and posted in the internet-drafts
directories; when consensus is acheived on the mailing list, they will
be forwarded to the IESG.










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa01752;
          25 Mar 92 17:33 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa00285;
          25 Mar 92 17:35 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa00260;
          25 Mar 92 17:35 EST
Received: from nrc.com (aztec.NRC.COM) by fennel.acc.com (4.1/SMI-4.1)
	id AA23189; Wed, 25 Mar 92 14:27:13 PST
Received: by nrc.com (4.0/NRC-DDN1.2)
	id AA03729; Wed, 25 Mar 92 13:35:05 PST
Date: Wed, 25 Mar 92 13:35:05 PST
From: Bill Versteeg <bvs@nrc.com>
Message-Id: <9203252135.AA03729@nrc.com>
To: trunk-mib@acc.com
Subject: sparse MIB2 interface table
Cc: bvs@nrc.com



Upon further review, I realize that my
previous objection to making ds1LineIndex>
ifNumber is not a valid objection.

Briefly, sparse MIB2 interface tables are illegal.
So, I can see no ambiguity in the current recommendation.


Bill VerSteeg


P.S. I was confused on the issue of sparse
MIB2 interface tables because I recently saw
a sparse MIB2 interface table in the field.
rfc1213 clearly bans this. In fact it has
been illegal since rfc1066. 










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa01843;
          26 Mar 92 16:12 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa04769;
          26 Mar 92 16:14 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa04765;
          26 Mar 92 16:14 EST
Received: from relay1.UU.NET by fennel.acc.com (4.1/SMI-4.1)
	id AA04111; Thu, 26 Mar 92 12:44:44 PST
Errors-To: fbaker@uunet.UU.NET, ellen@uunet.UU.NET
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA00559; Thu, 26 Mar 92 15:44:36 -0500
Received: from kentrox.UUCP by uunet.uu.net with UUCP/RMAIL
	(queueing-rmail) id 154351.8386; Thu, 26 Mar 1992 15:43:51 EST
Received: from ktxs1.ktxnet by ktxnet (4.1/SMI-4.1)
	id AA16682; Thu, 26 Mar 92 11:43:48 PST
Received: by ktxs1.ktxnet (4.1/SMI-4.1)
	id AA04218; Thu, 26 Mar 92 11:45:12 PST
Date: Thu, 26 Mar 92 11:45:12 PST
From: Dan Park <kentrox!ktxs1!park@uunet.uu.net>
Message-Id: <9203261945.AA04218@ktxs1.ktxnet>
To: uunet!acc.com!trunk-mib@uunet.uu.net
Subject: DS1/DS3 Loopback object

The main point of the changes I have suggested for the loopback object
in the DS3 MIB is that the this object should reflect loopback
information for the DS3 port only. The object should not reference any
state information about the internals of a CSU or DSU - specifically
what kind of loopback capability is at the other end of the box.  The
other end of the box could be a serial port, a processor bus, another
DS3 port, etc.

That said, I think there are only two types of loopbacks for a DS1/DS3
interface.
    Lineloopback:
	This is a minimum penetration loopback.  The received signal is
	turned around after the receive circuitry, passed through the
	regenerator and transmitted back towards the source.  Received
	bipolar violations are returned to the sender as bipolar
	violations.

	This type of loopback is generally used to test cabling and
	connectors.

    PayloadLoopback:
	This type of loopback brings the received signal further into
	the device.  The received signal is turned around after the
	framing function.  Received bipolar violations are cleaned up
	and the transmitted signal is retimed and reframed before it is
	transmitted back to the source.

	This type of loopback is generally used to test the operation
	of the DSU/CSU.

    These loopbacks can be set by a manager (SNMP, front panel, craft
    interface) or by codes sent from the device at the far end of the
    DS1/DS3 line.

In the CSU world, the words "Payload Loopback" are generally used to
mean loopback towards the network (the side with lightning
protection).  I don't see why we shouldn't use the same words for a
loopback towards terminal equipment (router, PBX, etc).

With a DSU, loopbacks on the serial port (V.35, HSSI, EIA530, etc.)
should be controlled/monitored with a MIB object that is specific for
the serial port.  What happens on the network side of the DSU when the
serial interface is put into loopback is probably specific to DSU
vendors (I don't know what others do).

A Kentrox DSU will send AIS when the serial port loopback has maximum
penetration - the serial data is looped back at the network interface.
Kentrox calls this loopback "local loopback".  The Kentrox DSU will
send a framed, empty data stream towards the network when the serial port
is in a minimum penetration loopback - the serial data is looped back
at the serial interface.  Kentrox calls this loopback "Dataterminal
loopback".

I hope this has made things a little more clear.

Dan Park
ADC Kentrox











Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa00387;
          27 Mar 92 11:07 EST
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa13856;
          27 Mar 92 11:09 EST
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa13850;
          27 Mar 92 11:09 EST
Received: from saffron.acc.com by fennel.acc.com (4.1/SMI-4.1)
	id AA13141; Fri, 27 Mar 92 07:58:02 PST
Received: from nbkanata.newbridge.com (NEWBRIDGE.COM) by saffron.acc.com (4.1/SMI-4.1)
	id AA02001; Fri, 27 Mar 92 07:57:30 PST
Received: from Newbridge.com ([138.120.100.14]) by nbkanata.newbridge.com (4.1/SMI-4.1)
	id AA08987; Fri, 27 Mar 92 10:58:37 EST
Received: from nbntwk. by Newbridge.com (4.0/SMI-4.0)
	id AA06347; Fri, 27 Mar 92 10:56:53 EST
Received: from mailux.UUCP by nbntwk. (4.0/SMI-4.0)
	id AA03446; Fri, 27 Mar 92 10:56:14 EST
Received: from MAILCENTRE1 (QM 2.5a) by mailux  (UMCP\QM 2.0.1)
 id AA01496; Thu, 26 Mar 1992 20:30:17 EST    
Message-Id: <00412.2784486617.1496@mailux >
Organization: Newbridge Networks 600 March Road, Kanata Ontario, K2K2E6
X-Charset: MACINTOSH
X-Umcp-To: Dan Park
X-Umcp-Cc: DS1/DS3 MIB List IETF
From: James Watt <James_Watt@mailux.newbridge.com>
To: DS1/DS3 MIB List IETF <trunk-mib@acc.com>
Date: Thu, 26 Mar 1992 18:57:38 EST    
Subject: Re: DS1/DS3 Loopback object 

        Reply to:   RE>DS1/DS3 Loopback object
Dan:
  Perhaps instead of NetLineLoop and NetPayloadLoop we could say
NetReqLineLoop and NetReqPayloadLoop.  These essentially correspond to the
two network-requestable loopbacks defined in documents such as PUB 62411
both in spirit and in name.
  There are of course many other loopbacks a box might implement.   If the
box is a CSU/DSU there is a whole other set that apply to the non-network
side of the box.  Even if it isn't there are an awful lot of loops that you
can do on a single DS1 port.  Similarly, the "mgr requested" payload loop
may use a different path that the "network requested" payload loop.
 
  Note that if an agent ever receives a set to ds*NewLoopback with a value
of either 'ds*NetPayloadLoop' or 'ds*NetLineLoop', it must return badValue
-- this should probably get added to the text.  If the DS1 interface
integral to the box is at the DSX level and the agent is not proxing for an
external CSU, these values should never be reported.
  Also, if the agent is currently reporting a value of "ds*NetReq*Loop", it
probably should reject any sets to that object -- undoing network loopbacks
without being told is somewhat antisocial...  Again this wouldn't apply for
boxes that don't support the CSU functionality.

 Presumably for a DS1->DS1 CSU, there would be two instances of the ds1
tables, one for CSU side and one for the DSX side.  For a DSU/CSU, there
would presumably be one instance of the ds1 tables (for the DS1 side).  Note
that the beh For the X.21/V.35/V.24/etc side, we either need new object
types _or_ creative uses of the interface extensions test object.

If you're wondering why anyone would care about network loops being reported
in a loopback object:
  1) Consider a router with a built in CSU _or_ proxying for a CSU
  2) Now your carrier sends a loopback request code to the CSU which
promptly loops the line
  3) The keepalives on the interface discover there is no longer and an to
end path and the interface(s)
       carried over the ds1 are taken down
  3) An NMS receives a trap saying that ifOperStatus.<i> is "down"
  4) The NMS discovers that interface <i> is carried over ds1 <l>
  5) The NMS reads ds1LineStatus.<l> and finds out that the status is "in
loopback"
  6) The NMS reads ds1NewLoopback.<l> and gets the value NetReqLineLoop (for
example) and thus
      discovers that there is a network loopback in place
 
Comments ?

-james
____________________________________________________________________________
James W. Watt,     jamesw@newbridge.com                  Ph:  (613) 591-3600
Newbridge Networks 600 March Rd Kanata ON Canada K2K 2E6 FAX: (613) 591-3680
____________________________________________________________________________
Date: Thu, 26 Mar 92 11:45:12 PST
From: nbntwk!uunet.UU.NET!kentrox!ktxs1!park (Dan Park)
Message-Id: <9203261945.AA04218@ktxs1.ktxnet>
To: uunet.UU.NET!uunet!acc.com!trunk-mib
Subject: DS1/DS3 Loopback object

The main point of the changes I have suggested for the loopback object
in the DS3 MIB is that the this object should reflect loopback
information for the DS3 port only. The object should not reference any
state information about the internals of a CSU or DSU - specifically
what kind of loopback capability is at the other end of the box.  The
other end of the box could be a serial port, a processor bus, another
DS3 port, etc.

That said, I think there are only two types of loopbacks for a DS1/DS3
interface.
    Lineloopback:
	This is a minimum penetration loopback.  The received signal is
	turned around after the receive circuitry, passed through the
	regenerator and transmitted back towards the source.  Received
	bipolar violations are returned to the sender as bipolar
	violations.

	This type of loopback is generally used to test cabling and
	connectors.

    PayloadLoopback:
	This type of loopback brings the received signal further into
	the device.  The received signal is turned around after the
	framing function.  Received bipolar violations are cleaned up
	and the transmitted signal is retimed and reframed before it is
	transmitted back to the source.

	This type of loopback is generally used to test the operation
	of the DSU/CSU.

    These loopbacks can be set by a manager (SNMP, front panel, craft
    interface) or by codes sent from the device at the far end of the
    DS1/DS3 line.

In the CSU world, the words "Payload Loopback" are generally used to
mean loopback towards the network (the side with lightning
protection).  I don't see why we shouldn't use the same words for a
loopback towards terminal equipment (router, PBX, etc).

With a DSU, loopbacks on the serial port (V.35, HSSI, EIA530, etc.)
should be controlled/monitored with a MIB object that is specific for
the serial port.  What happens on the network side of the DSU when the
serial interface is put into loopback is probably specific to DSU
vendors (I don't know what others do).

A Kentrox DSU will send AIS when the serial port loopback has maximum
penetration - the serial data is looped back at the network interface.
Kentrox calls this loopback "local loopback".  The Kentrox DSU will
send a framed, empty data stream towards the network when the serial port
is in a minimum penetration loopback - the serial data is looped back
at the serial interface.  Kentrox calls this loopback "Dataterminal
loopback".

I hope this has made things a little more clear.

Dan Park
ADC Kentrox













Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa01496;
          8 Apr 92 12:48 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa17857;
          8 Apr 92 12:51 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa17853; 8 Apr 92 12:51 EDT
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA23323; Wed, 8 Apr 92 09:44:31 PDT
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA03295; Wed, 8 Apr 92 12:39:14 EDT
Return-Path: <tacox@sabre.bellcore.com>
Received: by ginsu4 (4.1/4.7)
	id AA02598; Wed, 8 Apr 92 12:40:51 EDT
Date: Wed, 8 Apr 92 12:40:51 EDT
From: Tracy Cox <tacox@sabre.bellcore.com>
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9204081640.AA02598@ginsu4>
To: trunk-mib@acc.com
Subject: DS3 MIB and T1M1

Gang,

I received a call from a Bob Beebe, from
Verilink.  He was concerned that the DS1/3
MIBs were diverging from T1M1.3 document.
I told him that we cannot wait around
for T1M1 to decide on how to count an
errored seconds and that we went with
a snap-shot of a draft version.  He
was sympathetic to our problem, but
asked if we can change one more time.

Anyway -- I received the latest version
of the T1M1 document, and he promises
this one is the last -- I told him that he is
lucky that he caught us in the middle
of updating the MIBs and this is it.

So I will look over the T1M1 document
and update the definitions as necessary -- 
I will pass on the necessary info. to
Fred as well.

I hope to post the MIB by the end of the week
for all of you to look over.

Okey-dokey?

Tracy











Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa01718;
          8 Apr 92 14:02 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa22391;
          8 Apr 92 14:05 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa22385; 8 Apr 92 14:05 EDT
Received: from vnet.ibm.com by fennel.acc.com (4.1/SMI-4.1)
	id AA23440; Wed, 8 Apr 92 10:36:00 PDT
Message-Id: <9204081736.AA23440@fennel.acc.com>
Received: from RALVM29 by vnet.ibm.com (IBM VM SMTP V2R2) with BSMTP id 1404;
   Wed, 08 Apr 92 13:35:29 EST
Date: Wed, 8 Apr 92 13:36:34 EDT
From: "Laurence V. Marks" <lmarks@vnet.ibm.com>
To: fbaker@acc.com, kolb@psi.com, harley@io.t3plus.com, 
    kaj@nvuxr.cc.bellcore.com, kentrox!litster@uunet.uu.net, 
    rpower@hondo.sw.stratus.com, tacox@ginsu4.bellcore.com, 
    tob@thumper.bellcore.com, trunk-mib@acc.com, pring@watson.ibm.com
Subject: One more time

I wrote Tracy a few weeks ago expressing a similar concern about
perpetuating differences between T1M1 and RFC1232.  I am relieved to
see convergence.

Realize (as I'm sure my colleague from Verilink does) that the defects
one must detect and count here are not things you do with software
IF-THEN statements, that are easily updated, and where it is easy to
maintain two distinct statistics--one for the MIB, and one for PRM
reporting using ANSI T1.403, T1.408, or the ds3 equivalent.

Rather, these things are done in silicon; costly and time consuming to
update.  Once back-level implementations get into the field, they are
nearly impossible to eliminate.  (Look at the footnotes in T1.403 which
mainly relate to early implementations.)  The cost of silicon chips is
related to the amount of logic circuitry they contain.  The cost of
hardware that correctly maintains MIB statistics would be unnecessarily
high if the MIB were to to diverge form T1M1.

Furthermore, a divergent MIB is an invitation to developers to produce
inconsistent implementations, either through error, or by attempts to
use PRM-statistic logic for two purposes.  I can't remember where, but I
recently read an analysis (from Clearpoint) on how inconsistent the
Ethernet MIB implementations were.

My preference is for convergence, at least at this juncture.

Laurence V. Marks










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa01751;
          8 Apr 92 14:27 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa23322;
          8 Apr 92 14:30 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa23300; 8 Apr 92 14:30 EDT
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA23508; Wed, 8 Apr 92 10:51:31 PDT
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA03672; Wed, 8 Apr 92 13:45:46 EDT
Return-Path: <tacox@sabre.bellcore.com>
Received: by ginsu4 (4.1/4.7)
	id AA02673; Wed, 8 Apr 92 13:47:23 EDT
Date: Wed, 8 Apr 92 13:47:23 EDT
From: Tracy Cox <tacox@sabre.bellcore.com>
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9204081747.AA02673@ginsu4>
To: trunk-mib@acc.com
Subject: DS3 MIB

Gang,

This is the draft of the DS3 MIB.

The definitions have been updated to
reflect T1M1.3/92-005.

The effected counters are:
BPVs -- just wording changes
SEFSs -- added AIS defects to def.
UAS -- clarified going into unavailability
       and coming out; also clarified
       what to count during those time
       periods
OOF -- claried definition of an OOF and
       a LOF

All other counters were consistent --
remember this MIB does not and will not
count everying that T1M1.3 counts; it is
only a subset.  The subset though
is consistent with T1M1.3 definitions.

Please, look over the ds3LoopbackConfig
object, the ds3LineStatus object and
the far end tables -- since they have
changed the most. 

I am in favor of keeping ds1IfIndex.

Thanks.

Tracy

============================================





          Internet Draft           DS3 Objects                April 1992


                          Definitions of Managed Objects
                            for the DS3 Interface Type

                                    April 1992


                             Trunk MIB Working Group

                              Tracy A. Cox (editor)
                               Kaj Tesink (editor)
                           Bell Communications Research
                             331 Newman Springs Road
                               Red Bank, NJ  07701

                             tacox@sabre.bellcore.com
                            kaj@nvuxr.cc.bellcore.com




          1.  Status of this Memo

          This draft document will be submitted to the RFC editor as an
          experimental extension to the SNMP MIB.  Distribution of this
          memo is unlimited.  Please send comments to the editors.

          2.  Abstract

          This memo defines an experimental 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 DS3 objects.  This document is a
          companion document with Experimental Definitions of Managed
          Objects for the DS1 Interface Type.

          This memo does not specify a standard for the Internet
          community.













          T. A. Cox and K. Tesink (editors)                     [Page 1]





          Internet Draft           DS3 Objects                April 1992


          3.  The Network Management Framework

          The Internet-standard Network Management Framework consists of three
          components.  They are:

                RFC 1155 which defines the SMI, the mechanisms used for describing
                and naming objects for the purpose of management.  RFC 1212
                defines a more concise description mechanism, which is wholly
                consistent with the SMI.

                RFC 1156 which defines MIB-I, the core set of managed objects for
                the Internet suite of protocols.  RFC 1213, defines MIB-II, an
                evolution of MIB-I based on implementation experience and new
                operational requirements.

                RFC 1157 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.






























          T. A. Cox and K. Tesink (editors)                     [Page 2]





          Internet Draft           DS3 Objects                April 1992


          4.  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) [7] 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 [3]
          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 [8], subject to the additional requirements
          imposed by the SNMP.

          4.1.  Format of Definitions

          Section 6 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 RFC1212 [13].

          4.2.  Changes from RFC1233

          The changes from RFC1233 are the following:

          --  This MIB module contains two groups:
               DS3 Near End Group which is mandatory and
               DS3 Far End Group which is optional.

          --  The Far End Group is a new group and contains
              configuration information and statistics





          T. A. Cox and K. Tesink (editors)                     [Page 3]





          Internet Draft           DS3 Objects                April 1992


              that are collected from the far end DS3 interface.

          --  ds3CSUIndex has been renamed ds3LineIndex.  This object
              is the identifier of a DS3 Interface on a device.

          --  ds3Index has been renamed ds3IfIndex.  This value for this
              object is equal to the value of ifIndex from the Interfaces
              table of MIB II (RFC 1213).

          --  ds3Loopback has been deprecated.

          --  A new object has been added called ds3LoopbackConfig,
              which better describes the loopback capabilities of
              a DS3 interface on a device.

          --  ds3YellowAlarm has been deprecated.

          --  ds3RedAlarm has been deprecated.

          --  A new object has been added called ds3LineStatus.
              This object better describes the status (e.g.,
              alarm state and loopback state) of a
              DS3 interface.

          --  ds3IntervalCSSs, ds3CurrentCSSs, and ds3TotalCSSs have
              been deprecated.
























          T. A. Cox and K. Tesink (editors)                     [Page 4]





          Internet Draft           DS3 Objects                April 1992


          5.  Overview

          These objects are used when the particular media being used to
          realize an interface is a DS3 interface.  At present, this
          applies to these values of the ifType variable in the
          Internet-standard MIB:

               ds3 (30)

          The definitions contained herein are based on the DS3
          specifications in ANSI T1.102-1987, ANSI T1.107-1988, ANSI
          T1.107a-1990, and ANSI T1.404-1989 [9,10,10a,11].

          5.1.  Binding between ifIndex and DS3 Interfaces

          Each agent which resides on a host which uses DS3 interfaces
          is required to assign a small, non-negative integer uniquely
          to each DS3 Interface.  This is known as the "LineIndex", and
          is used to distinguish between different DS3 interfaces
          attached to a node.  The LineIndex is also used as the `key'
          when accessing tabular information about DS3 interfaces.

          The ds3IfIndex column of the DS3 Configuration table relates
          each DS3 interface to its corresponding interface (ifIndex) in
          the Internet-standard MIB.

          5.2.  Objectives of this MIB Module

          There are numerous things that could be included in a MIB for
          DS3 signals: the management of multiplexors, CSUs, DSUs, and
          the like.  The intent of this document is to facilitate the
          common management of all devices with DS3 interfaces, both
          in-chassis and external via proxy.  As such, a design decision
          was made up front to very closely align the MIB with the set
          of objects that can generally be read from DS3 devices that
          are currently deployed.

          5.3.  DS3 Terminology

          The terminology used in this document to describe error
          conditions on a DS3 interface as monitored by a DS3 device are
          from the ANSI T1M1.3/92-005 draft standard [12].  If the
          definition in this document does not match the definition in
          the ANSI T1M1.3/92-005 draft document, the implementer should
          follow the definition described in this document.





          T. A. Cox and K. Tesink (editors)                     [Page 5]





          Internet Draft           DS3 Objects                April 1992


                    Bipolar Violation (BPV)
                         A bipolar violation, for B3ZS-coded signals, is the
                         occurrence of a pulse of the same polarity as the previous
                         pulse without being part of the zero substitution code,
                         B3ZS.  For B3ZS-coded
                         signals, a bipolar violation may also include other error
                         patterns such as:  three or more consecutive zeros and
                         incorrect polarity.

                    Coding Violation (CV)
                         For all DS3 applications, a coding violation is a P-bit
                         Parity Error event.  A P-bit Parity Error event is the
                         occurrence of a received P-bit code on the DS3 M-frame
                         that is not identical to the corresponding locally-
                         calculated code.

                    Errored Seconds (ES)
                         An ES is a second with one or more Coding Violation OR
                         one or more Out of Frame events OR a detected incoming AIS.

                    Severely Errored Seconds (SES)
                         A SES is a second with 44 or more Coding Violations OR
                         one or more Out of Frame events OR a detected incoming AIS.

                    Severely Errored Framing Seconds (SEFS)
                         A SEFS is a second with one or more Out of Frame events
                         OR a detected incoming AIS.

                    Unavailable Seconds (UAS)
                         UAS are calculated by counting the number of seconds that
                         the interface is unavailable.  The DS3 interface is said
                         to be unavailable from the onset of 10 contiguous SESs, or
                         the onset of the condition leading to a failure (see Alarm
                         States).  If the condition leading to the failure was
                         immediately preceded by one or more contiguous SESs, then
                         the DS3 interface unavailability starts from the onset of these
                         SESs.  Once unavailable, and if no failure is present, the DS3
                         interface becomes available at the onset of 10 contiguous seconds
                         with no SESs.  Once unavailable, and if a failure is present,
                         the DS3 interface becomes available at the onset of 10 contiguous
                         seconds with no SESs, if the failure clearing time is less than
                         or equal to 10 seconds.  If the failure clearing time is more than
                         10 seconds, the DS3 interface becomes available at the onset of 10
                         contiguous seconds with no SESs, or the onset period leading to the
                         successful clearing condition, whichever occurs later.





          T. A. Cox and K. Tesink (editors)                     [Page 6]





          Internet Draft           DS3 Objects                April 1992


                         With respect to the DS3 error counts, all counters are incremented
                         while the DS3 interface is deemed available.  While the interface is
                         deemed unavailable, the only count that is incremented is UASs.

                         A special case exists when the 10 or more second period
                         crosses the 900 second statistics window boundary, as the
                         foregoing description implies that the SES and UAS
                         counters must be adjusted when the Unavailable Signal
                         State is entered. Clearly, successive GETs of the
                         affected ds3IntervalSES and ds3IntervalUAS objects will
                         return differing values if the first GET occurs during
                         the first few seconds of the window.  This is viewed as
                         an unavoidable side-effect of selecting the presently
                         defined managed objects as a basis for this memo.

                    Alarm States:
                         The Far End Alarm (or Yellow Alarm) is declared after detecting
                         the Yellow Signal.  See ANSI T1.107a-1990 [10].

                         The incoming alarm states consist of the following
                         incoming signal degradations:  Loss of
                         Signal (LOS), a Loss of Frame (LOF)  (a persistent Out
                         of Frame event), or an
                         Alarm Indication Signal (AIS), for at least 2-10
                         seconds.  The Alarm States are cleared at the onset of 10
                         consecutive seconds with no SESs.
                         The Alarm State object identifies only the highest priority
                         alarm.  The priorities of the alarm states from highest to lowest
                         are LOS, LOF, AIS, and Far End Alarm.

                    Out of Frame (OOF) event
                         An OOF event is detected when any three or more errors in
                         sixteen or fewer consecutive F-bits occur within a DS3
                         M-frame.  An OOF event is cleared when reframe occurs.
                         A Loss of Frame (LOF) event is declared when the OOF event
                         is consistent for 2 to 10 seconds.  The OOF event ends when
                         reframe occurs.  The LOF event is cleared when the OOF defect
                         is absent for 10 to 20 seconds.

                    Loss of Signal (LOS)
                         This failure is declared upon observing 175 +/- 75
                         contiguous pulse positions with no pulses of either
                         positive or negative polarity.
                         The LOS is terminated upon observing an average pulse density
                         of at least 33% over a period of 175 +/- 75 contiguous pulse





          T. A. Cox and K. Tesink (editors)                     [Page 7]





          Internet Draft           DS3 Objects                April 1992


                         positions starting with the receipt of a pulse.

                    Alarm Indication Signal (AIS)
                         The AIS is framed with "stuck stuffing."  This implies
                         that it has a valid M-subframe alignments bits, M-frame
                         alignment bits, and P bits.  The information bits are set
                         to a 1010... sequence, starting with a one (1) after each
                         M-subframe alignment bit, M-frame alignment bit, X bit, P bit,
                         and C bit.  The C bits are all set to zero giving what is called
                         "stuck stuffing."  The X bits are set to one.
                         The AIS is declared after AIS is present in contiguous M-frames
                         for a time equal to or greater than T, where
                         0.2 ms <= T <= 100 ms.
                         The AIS is terminated after AIS is absent in contiguous M-frames
                         for a time equal to or greater than T.

                    Circuit Identifier
                         This is a character string specified by the circuit
                         vendor, and is useful when communicating with the vendor
                         during the troubleshooting process.






























          T. A. Cox and K. Tesink (editors)                     [Page 8]





          Internet Draft           DS3 Objects                April 1992


          6.  Object Definitions

               RFCxxxx-MIB DEFINITIONS ::= BEGIN

               IMPORTS
                       mgmt, experimental, Counter
                               FROM RFC1155-SMI
                       DisplayString
                               FROM RFC1158-MIB
                       OBJECT-TYPE
                               FROM RFC-1212;

               --  This MIB module uses the extended OBJECT-TYPE macro as
               --  defined in RFC 1212.

               --  this is the MIB module for the DS3 objects

                              mib-2 OBJECT IDENTIFIER ::= { mgmt 1 }
                              transmission OBJECT IDENTIFIER ::= { mib-2 10 }
                              ds3 OBJECT IDENTIFIER ::= { transmission 30 }






























          T. A. Cox and K. Tesink (editors)                     [Page 9]





          Internet Draft           DS3 Objects                April 1992


               -- The DS3 Near End Group

               -- Implementation of this group is mandatory for all systems
               -- that attach to a DS3 Interface.

               -- The DS3 Near End Group consists of four groups:
               --    DS3 Configuration Group
               --    DS3 Interval Group
               --    DS3 Current Group
               --    DS3 Total Group

               -- the DS3 Configuration group

               -- Although the objects in this group are read-only, at the
               -- agent's discretion they may be made read-write so that the
               -- management station, when appropriately authorized, may
               -- change the behavior of the interface, e.g., to place the interface
               -- into a loopback state.

               ds3ConfigTable OBJECT-TYPE
                   SYNTAX  SEQUENCE OF DS3ConfigEntry
                   ACCESS  not-accessible
                   STATUS  mandatory
                   DESCRIPTION
                           "The DS3 Configuration table."
                  ::= { ds3 1 }

              ds3ConfigEntry OBJECT-TYPE
                  SYNTAX  DS3ConfigEntry
                  ACCESS  not-accessible
                  STATUS  mandatory
                  DESCRIPTION
                          "An entry in the DS3 Configuration table."
                 INDEX   { ds3LineIndex }
                 ::= { ds3ConfigTable 1 }

             DS3ConfigEntry ::=
                 SEQUENCE {
                     ds3LineIndex
                         INTEGER,
                     ds3IfIndex
                         INTEGER,
                     ds3TimeElapsed
                         INTEGER,
                     ds3ValidIntervals





          T. A. Cox and K. Tesink (editors)                    [Page 10]





          Internet Draft           DS3 Objects                April 1992


                         INTEGER,
                     ds3LineType
                         INTEGER,
                     ds3ZeroCoding
                         INTEGER,
                     ds3Loopback
                         INTEGER,
                     ds3SendCode
                         INTEGER,
                     ds3YellowAlarm
                         INTEGER,
                     ds3RedAlarm
                         INTEGER,
                     ds3CircuitIdentifier
                         DisplayString,
                     ds3LoopbackConfig
                         INTEGER,
                     ds3LineStatus
                         INTEGER
             }

             ds3LineIndex OBJECT-TYPE
                 SYNTAX  INTEGER (1..65535)
                 ACCESS  read-only
                 STATUS  mandatory
                 DESCRIPTION
                         "This object is the identifier of a DS3
                         Interface on a device.  If there is at least
                         one ifEntry directly associated with the DS3
                         interface (e.g., if the DS3 interface is used
                         to communicate with the Network Layer), it
                         should have the same value as ifIndex.
                         Otherwise, its value should exceed ifNumber."
                ::= { ds3ConfigEntry 1 }

            ds3IfIndex OBJECT-TYPE
                SYNTAX  INTEGER (1..65535)
                ACCESS  read-only
                STATUS  mandatory
                DESCRIPTION
                        "This value for this object is equal to the
                        value of ifIndex from the Interfaces table of
                        MIB II (RFC 1213)."
               ::= { ds3ConfigEntry 2 }






          T. A. Cox and K. Tesink (editors)                    [Page 11]





          Internet Draft           DS3 Objects                April 1992


           ds3TimeElapsed OBJECT-TYPE
               SYNTAX  INTEGER (1..900)
               ACCESS  read-only
               STATUS  mandatory
               DESCRIPTION
                       "The number of seconds, including partial
                       seconds, that have elapsed since the beginning of
                       the current error-measurement period."
              ::= { ds3ConfigEntry 3 }

          ds3ValidIntervals OBJECT-TYPE
              SYNTAX  INTEGER (0..96)
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The number of previous intervals for which valid
                      data was collected.  The value will be 96 unless
                      the interface was brought online within the last
                      24 hours, in which case the value will be the
                      number of complete 15 minute intervals the
                      interface has been online."
              ::= { ds3ConfigEntry 4 }

          ds3LineType OBJECT-TYPE
              SYNTAX  INTEGER {
                          other(1),
                          ds3M23(2),
                          ds3SYNTRAN(3),
                          ds3CbitParity(4),
                          ds3ClearChannel(5)
                      }
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "This variable indicates the variety of DS3 C-bit
                      application implementing this interface.  The type
                      of interface affects the interpretation of the
                      usage and error statistics.  The rate of all of
                      them is 44.736 Mbps.

                      The values, in sequence, describe:
                      TITLE:            SPECIFICATION:
                      ds3M23            ANSI T1.107-1988 [10]
                      ds3SYNTRAN        ANSI T1.107-1988 [10]
                      ds3C-bit Parity   ANSI T1.107a-1989 [10a]





          T. A. Cox and K. Tesink (editors)                    [Page 12]





          Internet Draft           DS3 Objects                April 1992


                      ds3Clear Channel  ANSI T1.102-1987 [9]
                      "
              ::= { ds3ConfigEntry 5 }

          ds3ZeroCoding OBJECT-TYPE
              SYNTAX  INTEGER {
                          ds3other(1),
                          ds3B3ZS(2)
                      }
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "This variable describes the variety of Zero Code
                      Suppression used on this interface, which in turn
                      affects a number of its characteristics.

                      DS3B3ZS refer to the use of specified patterns of
                      normal bits and bipolar violations which are used
                      to replace sequences of zero bits of a specified
                      length."
              ::= { ds3ConfigEntry 6 }

              ds3Loopback OBJECT-TYPE
                        SYNTAX  INTEGER {
                                    ds3NoLoop(1),
                                    ds3LocalLoopbackLocalSide(2),
                                    ds3LocalLoopbackRemoteSide(3),
                                    ds3RemoteLoopbackLocalSide(4),
                                    ds3RemoteLoopbackRemoteSide(5)
                                }
                        ACCESS  read-only
                        STATUS  deprecated
                        DESCRIPTION
                                "This variable represents the loopback state of
                                the device.  Agents supporting read/write access
                                should return badValue in response to a requested
                                loopback state that the device does not support.  The
                                values mean:

                                  ds3NoLoop
                                     Not in the loopback state.  A device that is
                                     not capable of performing a loopback on
                                     either interface shall always return this as
                                     it's value.






          T. A. Cox and K. Tesink (editors)                    [Page 13]





          Internet Draft           DS3 Objects                April 1992


                                  ds3LocalLoopbackLocalSide
                                     Signal received from the local side of the
                                     device is looped back at the local connector
                                     (eg, without involving the device).

                                  ds3LocalLoopbackRemoteSide
                                     Signal received from the local side of the
                                     device is looped back at the remote connector
                                     (eg, through the device).

                                  ds3RemoteLoopbackLocalSide
                                     Signal received from the remote side of the
                                     device is looped back at the local connector
                                     (eg, through the device).

                                  ds3RemoteLoopbackRemoteSide
                                     Signal received from the remote side of the
                                     device is looped back at the remote connector
                                     (eg, without involving the device).

                                Note that M23 and ClearChannel interfaces do not
                                support the Loopback managed object."
                        ::= { ds3ConfigEntry 7 }

                ds3SendCode OBJECT-TYPE
                        SYNTAX  INTEGER {
                                    ds3SendTestMessage(1),
                                    ds3SendNoCode(2),
                                    ds3SendSetCode(3),
                                    ds3SendLoopbackCode(4),
                                    ds3SendResetCode(5)
                                }
                        ACCESS  read-only
                        STATUS  mandatory
                        DESCRIPTION
                                "This variable indicates what type of code is
                                being sent across the DS3 interface by the device.  The
                                values mean:

                                  ds3SendNoCode
                                     sending looped or normal data

                                  ds3SendSetCode
                                     sending a loopback request






          T. A. Cox and K. Tesink (editors)                    [Page 14]





          Internet Draft           DS3 Objects                April 1992


                                  ds3SendLoopbackCode
                                     sending a loopback test code/pattern

                                  ds3SendResetCode
                                     sending a loopback termination request

                                  ds3SendTestMessage
                                     sending a Test pattern as defined in
                                     T1.107a-1990."
                        ::= { ds3ConfigEntry 8 }

          ds3YellowAlarm OBJECT-TYPE
              SYNTAX  INTEGER {
                          ds3YellowAlarm(1),
                          ds3NoYellowAlarm(2)
                      }
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "This variable indicates if a Yellow Alarm
                      condition exists."
              ::= { ds3ConfigEntry 9 }

          ds3RedAlarm OBJECT-TYPE
              SYNTAX  INTEGER {
                          ds3RedAlarm(1),
                          ds3NoRedAlarm(2)
                      }
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "This variable indicates if a Red Alarm condition
                      exists."
              ::= { ds3ConfigEntry 10 }

          ds3CircuitIdentifier OBJECT-TYPE
              SYNTAX  DisplayString (SIZE (0..255))
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "This variable contains the transmission vendor's
                      circuit identifier, for the purpose of
                      facilitating troubleshooting."
              ::= { ds3ConfigEntry 11 }






          T. A. Cox and K. Tesink (editors)                    [Page 15]





          Internet Draft           DS3 Objects                April 1992


                      ds3LoopbackConfig OBJECT-TYPE
                                SYNTAX  INTEGER {
                                            ds3NoLoop(1),
                                            ds3MgrPayloadLoop(2),
                                            ds3MgrLineLoop(3),
                                            ds3NetReqPayloadLoop(4),
                                            ds3NetReqLineLoop(5),
                                            ds3OtherLoop(6)
                                        }
                                ACCESS  read-only
                                STATUS  mandatory
                                DESCRIPTION
                                        "This variable represents the loopback configuration of
                                        the DS3 interface.  Agents supporting read/write
                                        access should return badValue in response to a
                                        requested loopback state that the interface does not support.
                                        The values mean:

                                              ds3NoLoop

                                                Not in the loopback state.  A device that is
                                                not capable of performing a loopback on
                                                the interface shall always return this as
                                                it's value.


                                              ds3MgrPayloadLoop

                                                The received signal at this interface is looped through
                                                the device; this loopback is initiated by a
                                                manager of the device. Typically the received signal
                                                is looped back for retransmission after it has
                                                passed through the device's framing function.

                                              ds3MgrLineLoop

                                                The received signal at this interface does not
                                                go through the device (minimum penetration) but
                                                is looped back out; this loopback is initiated
                                                by a manager of the device.

                                              ds3NetReqPayloadLoop

                                                The received signal at this interface is looped through
                                                the device; this loopback is initiated/requested by the





          T. A. Cox and K. Tesink (editors)                    [Page 16]





          Internet Draft           DS3 Objects                April 1992


                                                far end equipment. Typically the received signal
                                                is looped back for retransmission after it has
                                                passed through the device's framing function.

                                              ds3NetReqLineLoop

                                                The received signal at this interface does not
                                                go through the device (minimum penetration) but
                                                is looped back out; this loopback is initiated/requested
                                                by the far end equipment.

                                              ds3OtherLoop

                                                Loopbacks that are not defined here.

                                        Note that M23 and ClearChannel interfaces do not
                                        support the Loopback managed object."
                                ::= { ds3ConfigEntry 12 }

                    ds3LineStatus OBJECT-TYPE
                        SYNTAX  INTEGER {
                                    ds3NoAlarm(1),
                                    ds3FarEndAlarm(2),
                                    ds3AlarmIndicationSignal(3),
                                    ds3LossOfFrame(4),
                                    ds3LossOfSignal(5),
                                    ds3LoopbackState(6)
                                }
                        ACCESS  read-only
                        STATUS  mandatory
                        DESCRIPTION
                              "This variable indicates the
                              Line Status of the interface.
                              It contains loopback state information
                              and alarm state information.
                              If multiple alarm states are occurring
                              simultaneously, then the highest
                              priority alarm state is the one set.  From
                              highest to lowest the alarm state priorities are
                              the following:  ds3LossOfSignal, ds3LossOfFrame,
                              ds3AlarmIndicationSignal, and ds3FarEndAlarm."
                        ::= { ds3ConfigEntry 13 }








          T. A. Cox and K. Tesink (editors)                    [Page 17]





          Internet Draft           DS3 Objects                April 1992


          -- the DS3 Interval group

          -- The DS3 Interval Table contains various statistics
          -- collected by each DS3 Interface over the previous 24 hours of
          -- operation.  The past 24 hours are broken into 96 completed
          -- 15 minute intervals.

          ds3IntervalTable OBJECT-TYPE
              SYNTAX  SEQUENCE OF DS3IntervalEntry
              ACCESS  not-accessible
              STATUS  mandatory
              DESCRIPTION
                      "The DS3 Interval table."
              ::= { ds3 2 }

          ds3IntervalEntry OBJECT-TYPE
              SYNTAX  DS3IntervalEntry
              ACCESS  not-accessible
              STATUS  mandatory
              DESCRIPTION
                      "An entry in the DS3 Interval table."
              INDEX   { ds3IntervalIndex, ds3IntervalNumber }
              ::= { ds3IntervalTable 1 }

          DS3IntervalEntry ::=
              SEQUENCE {
                  ds3IntervalIndex
                      INTEGER,
                  ds3IntervalNumber
                      INTEGER,
                  ds3IntervalESs
                      Counter,
                  ds3IntervalSESs
                      Counter,
                  ds3IntervalSEFSs
                      Counter,
                  ds3IntervalUASs
                      Counter,
                  ds3IntervalCSSs
                      Counter,
                  ds3IntervalBPVs
                      Counter,
                  ds3IntervalCVs
                      Counter
              }





          T. A. Cox and K. Tesink (editors)                    [Page 18]





          Internet Draft           DS3 Objects                April 1992


          ds3IntervalIndex OBJECT-TYPE
              SYNTAX  INTEGER (1..65535)
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The index value which uniquely identifies the DS3
                      interface to which this entry is applicable.  The
                      interface identified by a particular value of this
                      index is the same interface as identified by the
                      same value an DS3LineIndex object instance."
              ::= { ds3IntervalEntry 1 }

          ds3IntervalNumber OBJECT-TYPE
              SYNTAX  INTEGER (0..96)
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "A number between 1 and 96, where 1 is the most
                      recently completed 15 minute interval and 96 is
                      the least recently completed 15 minutes interval
                      (assuming that all 96 intervals are valid)."
              ::= { ds3IntervalEntry 2 }

          ds3IntervalESs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Errored
                      Seconds, encountered by a DS3 interface in one of
                      the previous 96, individual 15 minute, intervals."
              ::= { ds3IntervalEntry 3 }

          ds3IntervalSESs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of
                      Severely Errored Seconds, encountered by a DS3
                      interface in one of the previous 96, individual 15
                      minute, intervals."
              ::= { ds3IntervalEntry 4 }

          ds3IntervalSEFSs OBJECT-TYPE





          T. A. Cox and K. Tesink (editors)                    [Page 19]





          Internet Draft           DS3 Objects                April 1992


              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of
                      Severely Errored Framing Seconds, encountered by a
                      DS3 interface in one of the previous 96,
                      individual 15 minute, intervals."
              ::= { ds3IntervalEntry 5 }

          ds3IntervalUASs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of
                      Unavailable Seconds, encountered by a DS3
                      interface in one of the previous 96, individual 15
                      minute, intervals."
              ::= { ds3IntervalEntry 6 }

          ds3IntervalCSSs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "The counter associated with the number of
                      Controlled Slip Seconds, encountered by a DS3
                      interface in one of the previous 96, individual 15
                      minute, intervals.  Note that SYNTRAN interfaces
                      are the only interfaces that support the
                      Controlled Slip Seconds managed object.
                      Accordingly, agents configured with non-SYNTRAN
                      interfaces may treat this object as having an
                      ACCESS clause value of not-accessible."
              ::= { ds3IntervalEntry 7 }

          ds3IntervalBPVs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Bipolar
                      Violations, encountered by a DS3 interface in one
                      of the previous 96, individual 15 minute,





          T. A. Cox and K. Tesink (editors)                    [Page 20]





          Internet Draft           DS3 Objects                April 1992


                      intervals."
              ::= { ds3IntervalEntry 8 }

          ds3IntervalCVs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Coding
                      Violations, encountered by a DS3 interface in one
                      of the previous 96, individual 15 minute,
                      intervals."
              ::= { ds3IntervalEntry 9 }





































          T. A. Cox and K. Tesink (editors)                    [Page 21]





          Internet Draft           DS3 Objects                April 1992


          -- the DS3 Current group

          -- The DS3 current table contains various statistics being
          -- collected for the current 15 minute interval.

          ds3CurrentTable OBJECT-TYPE
              SYNTAX  SEQUENCE OF DS3CurrentEntry
              ACCESS  not-accessible
              STATUS  mandatory
              DESCRIPTION
                      "The DS3 Current table."
              ::= { ds3 3 }

          ds3CurrentEntry OBJECT-TYPE
              SYNTAX  DS3CurrentEntry
              ACCESS  not-accessible
              STATUS  mandatory
              DESCRIPTION
                      "An entry in the DS3 Current table."
              INDEX   { ds3CurrentIndex }
              ::= { ds3CurrentTable 1 }

          DS3CurrentEntry ::=
              SEQUENCE {
                  ds3CurrentIndex
                      INTEGER,
                  ds3CurrentESs
                      Counter,
                  ds3CurrentSESs
                      Counter,
                  ds3CurrentSEFSs
                      Counter,
                  ds3CurrentUASs
                      Counter,
                  ds3CurrentCSSs
                      Counter,
                  ds3CurrentBPVs
                      Counter,
                  ds3CurrentCVs
                      Counter
              }

          ds3CurrentIndex OBJECT-TYPE
              SYNTAX  INTEGER (1..65535)
              ACCESS  read-only





          T. A. Cox and K. Tesink (editors)                    [Page 22]





          Internet Draft           DS3 Objects                April 1992


              STATUS  mandatory
              DESCRIPTION
                      "The index value which uniquely identifies the DS3
                      interface to which this entry is applicable.  The
                      interface identified by a particular value of this
                      index is the same interface as identified by the
                      same value an DS3LineIndex object instance."
              ::= { ds3CurrentEntry 1 }

          ds3CurrentESs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Errored
                      Seconds, encountered by a DS3 interface in the
                      current 15 minute interval."
              ::= { ds3CurrentEntry 2 }

          ds3CurrentSESs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of
                      Severely Errored Seconds, encountered by a DS3
                      interface in the current 15 minute interval."
              ::= { ds3CurrentEntry 3 }

          ds3CurrentSEFSs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of
                      Severely Errored Framing Seconds, encountered by a
                      DS3 interface in the current 15 minute interval."
              ::= { ds3CurrentEntry 4 }

          ds3CurrentUASs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of





          T. A. Cox and K. Tesink (editors)                    [Page 23]





          Internet Draft           DS3 Objects                April 1992


                      Unavailable Seconds, encountered by a DS3
                      interface in the current 15 minute interval."
              ::= { ds3CurrentEntry 5 }

          ds3CurrentCSSs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "The counter associated with the number of
                      Controlled Slip Seconds, encountered by a DS3
                      interface in the current 15 minute interval.  Note
                      that SYNTRAN interfaces are the only interfaces
                      that support the Controlled Slip Seconds managed
                      object.  Accordingly, agents configured with non-
                      SYNTRAN interfaces may treat this object as having
                      an ACCESS clause value of not-accessible."
              ::= { ds3CurrentEntry 6 }

          ds3CurrentBPVs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Bipolar
                      Violations, encountered by a DS3 interface in the
                      current 15 minute interval."
              ::= { ds3CurrentEntry 7 }

          ds3CurrentCVs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Coding
                      Violations, encountered by a DS3 interface in the
                      current 15 minute interval."
              ::= { ds3CurrentEntry 8 }












          T. A. Cox and K. Tesink (editors)                    [Page 24]





          Internet Draft           DS3 Objects                April 1992


          -- the DS3 Total group

          -- The DS3 Total Table contains the cumulative sum of the
          -- various statistics for the 24 hour interval preceding the
          -- first valid interval in the DS3CurrentTable.

          ds3TotalTable OBJECT-TYPE
              SYNTAX  SEQUENCE OF DS3TotalEntry
              ACCESS  not-accessible
              STATUS  mandatory
              DESCRIPTION
                      "The DS3 Total table.  24 hour interval."
              ::= { ds3 4 }

          ds3TotalEntry OBJECT-TYPE
              SYNTAX  DS3TotalEntry
              ACCESS  not-accessible
              STATUS  mandatory
              DESCRIPTION
                      "An entry in the DS3 Total table."
              INDEX   { ds3TotalIndex }
              ::= { ds3TotalTable 1 }

          DS3TotalEntry ::=
              SEQUENCE {
                  ds3TotalIndex
                      INTEGER,
                  ds3TotalESs
                      Counter,
                  ds3TotalSESs
                      Counter,
                  ds3TotalSEFSs
                      Counter,
                  ds3TotalUASs
                      Counter,
                  ds3TotalCSSs
                      Counter,
                  ds3TotalBPVs
                      Counter,
                  ds3TotalCVs
                      Counter
              }

          ds3TotalIndex OBJECT-TYPE
              SYNTAX  INTEGER (1..65535)





          T. A. Cox and K. Tesink (editors)                    [Page 25]





          Internet Draft           DS3 Objects                April 1992


              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The index value which uniquely identifies the DS3
                      interface to which this entry is applicable.  The
                      interface identified by a particular value of this
                      index is the same interface as identified by the
                      same value an DS3LineIndex object instance."
              ::= { ds3TotalEntry 1 }

          ds3TotalESs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Errored
                      Seconds, encountered by a DS3 interface in the
                      previous 24 hour interval"
              ::= { ds3TotalEntry 2 }

          ds3TotalSESs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of
                      Severely Errored Seconds, encountered by a DS3
                      interface in the previous 24 hour interval."
              ::= { ds3TotalEntry 3 }

          ds3TotalSEFSs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of
                      Severely Errored Framing Seconds, encountered by a
                      DS3 interface in the previous 24 hour interval."
              ::= { ds3TotalEntry 4 }

          ds3TotalUASs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION





          T. A. Cox and K. Tesink (editors)                    [Page 26]





          Internet Draft           DS3 Objects                April 1992


                      "The counter associated with the number of
                      Unavailable Seconds, encountered by a DS3
                      interface in the previous 24 hour interval."
              ::= { ds3TotalEntry 5 }

          ds3TotalCSSs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "The counter associated with the number of
                      Controlled Slip Seconds, encountered by a DS3
                      interface in the previous 24 hour interval.  Note
                      that SYNTRAN interfaces are the only interfaces
                      that support the Controlled Slip Seconds managed
                      object.  Accordingly, agents configured with non-
                      SYNTRAN interfaces may treat this object as having
                      an ACCESS clause value of not-accessible."
              ::= { ds3TotalEntry 6 }

          ds3TotalBPVs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Bipolar
                      Violations, encountered by a DS3 interface in the
                      previous 24 hour interval."
              ::= { ds3TotalEntry 7 }

          ds3TotalCVs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Coding
                      Violations, encountered by a DS3 interface in the
                      previous 24 hour interval."
              ::= { ds3TotalEntry 8 }











          T. A. Cox and K. Tesink (editors)                    [Page 27]





          Internet Draft           DS3 Objects                April 1992


          -- The DS3 Far End Group

          -- Implementation of this group is optional for all systems
          -- that attach to a DS3 Interface.

          -- The DS3 Far End Group consists of four groups:
          --   DS3 Far End Configuration Group
          --   DS3 Far End Interval Group
          --   DS3 Far End Current Group
          --   DS3 Far End Total Group


          -- Only C-bit Parity applications
          -- can provide this information.

          -- The DS3 Far End Configuration Table contains
          -- configuration information
          -- reported in the C-bits from the remote end.

                       ds3FarEndConfigTable OBJECT-TYPE
                            SYNTAX  SEQUENCE OF DS3FarEndConfigEntry
                            ACCESS  not-accessible
                            STATUS  optional
                            DESCRIPTION
                                    "The DS3 Far End Configuration table."
                           ::= { ds3 5 }

                       ds3FarEndConfigEntry OBJECT-TYPE
                           SYNTAX  DS3FarEndConfigEntry
                           ACCESS  not-accessible
                           STATUS  optional
                           DESCRIPTION
                                   "An entry in the DS3 Far End Configuration table."
                           INDEX   { ds3FarEndLineIndex }
                           ::= { ds3FarEndConfigTable 1 }

                       DS3FarEndConfigEntry ::=
                           SEQUENCE {
                               ds3FarEndLineIndex
                                   INTEGER,
                               ds3FarEndEquipCode
                                   DisplayString,
                               ds3FarEndLocationIDCode
                                   DisplayString,
                               ds3FarEndFrameIDCode





          T. A. Cox and K. Tesink (editors)                    [Page 28]





          Internet Draft           DS3 Objects                April 1992


                                   DisplayString,
                               ds3FarEndUnitCode
                                   DisplayString,
                               ds3FarEndFacilityIDCode
                                   DisplayString
                       }

                    ds3FarEndLineIndex OBJECT-TYPE
                           SYNTAX  INTEGER (1..65535)
                           ACCESS  read-only
                           STATUS  optional
                           DESCRIPTION
                                "The index value which uniquely identifies the
                                DS3 interface
                                to which this entry is applicable.  The
                                interface identified by a particular value of
                                this index is the same interface as identified
                                by the same value an DS3LineIndex object
                                instance."
                          ::= { ds3FarEndConfigEntry 1 }

                    ds3FarEndEquipCode OBJECT-TYPE
                        SYNTAX  DisplayString (SIZE (0..10))
                        ACCESS  read-write
                        STATUS  optional
                        DESCRIPTION
                              "This is the Far End Equipment Identification code
                              that describes the specific piece of equipment.
                              This code is only used in C-bit parity applications.
                              devices should return noSuchName when this object is
                              requested in a GET-Request and the next lexicographical
                              object in a GET-NEXT-Request.
                              It is sent within the Path
                              Identification Message."
                        ::= { ds3FarEndConfigEntry 2 }

                    ds3FarEndLocationIDCode OBJECT-TYPE
                        SYNTAX  DisplayString (SIZE (0..11))
                        ACCESS  read-write
                        STATUS  optional
                        DESCRIPTION
                              "This is the Far End Location Identification code
                              that describes the specific location of the equipment.
                              This code is only used in C-bit parity applications.
                              Devices should return noSuchName when this object is





          T. A. Cox and K. Tesink (editors)                    [Page 29]





          Internet Draft           DS3 Objects                April 1992


                              requested in a GET-Request and the next lexicographical
                              object in a GET-NEXT-Request.
                              It is sent within the Path
                              Identification Message."
                        ::= { ds3FarEndConfigEntry 3 }

                    ds3FarEndFrameIDCode OBJECT-TYPE
                        SYNTAX  DisplayString (SIZE (0..10))
                        ACCESS  read-write
                        STATUS  optional
                        DESCRIPTION
                              "This is the Far End Frame Identification code
                              that identifies where the equipment is located
                              within a building at a given location.
                              This code is only used in C-bit parity applications.
                              Devices should return noSuchName when this object is
                              requested in a GET-Request and the next lexicographical
                              object in a GET-NEXT-Request.
                              It is sent within the Path
                              Identification Message."
                        ::= { ds3FarEndConfigEntry 4 }

                    ds3FarEndUnitCode OBJECT-TYPE
                        SYNTAX  DisplayString (SIZE (0..6))
                        ACCESS  read-write
                        STATUS  optional
                        DESCRIPTION
                              "This is the Far End code
                              that identifies the equipment location within a bay.
                              This code is only used in C-bit parity applications.
                              Devices should return noSuchName when this object is
                              requested in a GET-Request and the next lexicographical
                              object in a GET-NEXT-Request.
                              It is sent within the Path
                              Identification Message."
                        ::= { ds3FarEndConfigEntry 5 }

                    ds3FarEndFacilityIDCode OBJECT-TYPE
                        SYNTAX  DisplayString (SIZE (0..38))
                        ACCESS  read-write
                        STATUS  optional
                        DESCRIPTION
                              "This code identifies a specific Far End DS3 path.
                              This code is only used in C-bit parity applications.
                              Devices should return noSuchName when this object is





          T. A. Cox and K. Tesink (editors)                    [Page 30]





          Internet Draft           DS3 Objects                April 1992


                              requested in a GET-Request and the next lexicographical
                              object in a GET-NEXT-Request.
                              It is sent within the Path
                              Identification Message."
                        ::= { ds3FarEndConfigEntry 6 }













































          T. A. Cox and K. Tesink (editors)                    [Page 31]





          Internet Draft           DS3 Objects                April 1992


          -- Only C-bit Parity Applications and SYNTRAN applications
          -- can provide this information.

          -- The DS3 Far End Interval Table contains various statistics
          -- collected by each DS3 interface over the previous 24 hours of
          -- operation.  The past 24 hours are broken into 96
          -- completed 15 minute intervals.

                    ds3FarEndIntervalTable OBJECT-TYPE
                        SYNTAX  SEQUENCE OF DS3FarEndIntervalEntry
                        ACCESS  not-accessible
                        STATUS  mandatory
                        DESCRIPTION
                               "The DS3 Far End Interval table."
                        ::= { ds3 6 }

                    ds3FarEndIntervalEntry OBJECT-TYPE
                        SYNTAX  DS3FarEndIntervalEntry
                        ACCESS  not-accessible
                        STATUS  mandatory
                        DESCRIPTION
                              "An entry in the DS3 Far
                              End Interval table."
                        INDEX   { ds3FarEndIntervalIndex, ds3FarEndIntervalNumber }
                        ::= { ds3FarEndIntervalTable 1 }

                    DS3FarEndIntervalEntry ::=
                        SEQUENCE {
                             ds3FarEndIntervalIndex
                                  INTEGER,
                             ds3FarEndIntervalNumber
                                  INTEGER,
                             ds3FarEndIntervalESs
                                  Counter,
                             ds3FarEndIntervalSESs
                                  Counter,
                             ds3FarEndIntervalCVs
                                  Counter
                        }

                    ds3FarEndIntervalIndex OBJECT-TYPE
                        SYNTAX  INTEGER (1..65535)
                        ACCESS  read-only
                        STATUS  mandatory
                        DESCRIPTION





          T. A. Cox and K. Tesink (editors)                    [Page 32]





          Internet Draft           DS3 Objects                April 1992


                                "The index value which uniquely identifies the
                                DS3 interface
                                to which this entry is applicable.  The
                                interface identified by a particular value of
                                this index is the same interface as identified
                                by the same value an DS3LineIndex object
                                instance."
                        ::= { ds3FarEndIntervalEntry 1 }

                   ds3FarEndIntervalNumber OBJECT-TYPE
                       SYNTAX  INTEGER (1..96)
                       ACCESS  read-only
                       STATUS  mandatory
                       DESCRIPTION
                              "A number between 1 and 96, where 1 is the most
                              recently completed 15 minute interval and 96 is
                              the least recently completed 15 minutes
                              interval (assuming that all 96 intervals are
                              valid)."
                       ::= { ds3FarEndIntervalEntry 2 }

                   ds3FarEndIntervalESs OBJECT-TYPE
                       SYNTAX  Counter
                       ACCESS  read-only
                       STATUS  mandatory
                       DESCRIPTION
                               "The counter associated with the number of
                               Far End Errored Seconds encountered
                               by a DS3 interface in one of the previous 96,
                               individual 15 minute, intervals."
                      ::= { ds3FarEndIntervalEntry 3 }

                   ds3FarEndIntervalSESs OBJECT-TYPE
                       SYNTAX  Counter
                       ACCESS  read-only
                       STATUS  mandatory
                       DESCRIPTION
                               "The counter associated with the number of
                               Far End Severely Errored Seconds
                               encountered by a DS3 interface in one of the previous
                               96, individual 15 minute, intervals."
                      ::= { ds3FarEndIntervalEntry 4 }

                    ds3FarEndIntervalCVs OBJECT-TYPE
                        SYNTAX  Counter





          T. A. Cox and K. Tesink (editors)                    [Page 33]





          Internet Draft           DS3 Objects                April 1992


                        ACCESS  read-only
                        STATUS  mandatory
                        DESCRIPTION
                                "The counter associated with the number of
                                Far End Coding Violations reported via
                                the far end block error count
                                encountered by a
                                DS3 interface in one of the previous 96, individual 15
                                minute, intervals."
                        ::= { ds3FarEndIntervalEntry 5 }








































          T. A. Cox and K. Tesink (editors)                    [Page 34]





          Internet Draft           DS3 Objects                April 1992


          -- Only C-bit Parity Applications and SYNTRAN applications
          -- can provide this information.

          -- The DS3 Far End Current table contains various statistics being
          -- collected for the current 15 minute interval.

                    ds3FarEndCurrentTable OBJECT-TYPE
                        SYNTAX  SEQUENCE OF DS3FarEndCurrentEntry
                        ACCESS  not-accessible
                        STATUS  mandatory
                        DESCRIPTION
                                "The DS3 Far End Current table."
                        ::= { ds3 7 }

                    ds3FarEndCurrentEntry OBJECT-TYPE
                        SYNTAX  DS3FarEndCurrentEntry
                        ACCESS  not-accessible
                        STATUS  mandatory
                        DESCRIPTION
                                "An entry in the DS3 Far End Current table."
                        INDEX   { ds3FarEndCurrentIndex }
                        ::= { ds3FarEndCurrentTable 1 }

                    DS3FarEndCurrentEntry ::=
                        SEQUENCE {
                            ds3FarEndCurrentIndex
                                INTEGER,
                            ds3FarEndCurrentESs
                                Counter,
                            ds3FarEndCurrentSESs
                                Counter,
                            ds3FarEndCurrentCVs
                                Counter
                        }

                     ds3FarEndCurrentIndex OBJECT-TYPE
                        SYNTAX  INTEGER (1..65535)
                        ACCESS  read-only
                        STATUS  mandatory
                        DESCRIPTION
                                "The index value which uniquely identifies the
                                DS3 interface
                                to which this entry is applicable.  The interface
                                identified by a particular value of this index is
                                the same interface as identified by the same value





          T. A. Cox and K. Tesink (editors)                    [Page 35]





          Internet Draft           DS3 Objects                April 1992


                                an DS3LineIndex object instance."
                        ::= { ds3FarEndCurrentEntry 1 }

                    ds3FarEndCurrentESs OBJECT-TYPE
                        SYNTAX  Counter
                        ACCESS  read-only
                        STATUS  mandatory
                        DESCRIPTION
                                "The counter associated with the number of Far
                                Far End Errored Seconds encountered by a DS3
                                interface in the current 15 minute interval."
                        ::= { ds3FarEndCurrentEntry 2 }

                    ds3FarEndCurrentSESs OBJECT-TYPE
                        SYNTAX  Counter
                        ACCESS  read-only
                        STATUS  mandatory
                        DESCRIPTION
                                "The counter associated with the number of
                                Far End Severely Errored Seconds
                                encountered by a DS3 interface in the current 15 minute
                                interval."
                        ::= { ds3FarEndCurrentEntry 3 }

                    ds3FarEndCurrentCVs OBJECT-TYPE
                        SYNTAX  Counter
                        ACCESS  read-only
                        STATUS  mandatory
                        DESCRIPTION
                                "The counter associated with the number of
                                Far End Coding Violations reported via
                                the far end block error count
                                encountered by a
                                DS3 interface in the current 15 minute interval."
                        ::= { ds3FarEndCurrentEntry 4 }















          T. A. Cox and K. Tesink (editors)                    [Page 36]





          Internet Draft           DS3 Objects                April 1992


          -- Only C-bit Parity Applications and SYNTRAN applications
          -- can provide this information.

          -- The DS3 Far End Total Table contains the cumulative sum of the
          -- various statistics for the 24 hour interval preceding the
          -- first valid interval in the DS3FarEndCurrentTable.

                    ds3FarEndTotalTable OBJECT-TYPE
                        SYNTAX  SEQUENCE OF DS3FarEndTotalEntry
                        ACCESS  not-accessible
                        STATUS  mandatory
                        DESCRIPTION
                                "The DS3 Far End Total table.  24 hour interval."
                        ::= { ds3 8 }

                    ds3FarEndTotalEntry OBJECT-TYPE
                        SYNTAX  DS3FarEndTotalEntry
                        ACCESS  not-accessible
                        STATUS  mandatory
                        DESCRIPTION
                                "An entry in the DS3 Far End Total table."
                        INDEX   { ds3FarEndTotalIndex }
                        ::= { ds3FarEndTotalTable 1 }

                    DS3FarEndTotalEntry ::=
                        SEQUENCE {
                            ds3FarEndTotalIndex
                                INTEGER,
                            ds3FarEndTotalESs
                                Counter,
                            ds3FarEndTotalSESs
                                Counter,
                            ds3FarEndTotalCVs
                                Counter
                        }

                    ds3FarEndTotalIndex OBJECT-TYPE
                        SYNTAX  INTEGER (1..65535)
                        ACCESS  read-only
                        STATUS  mandatory
                        DESCRIPTION
                                "The index value which uniquely identifies the
                                DS3 interface
                                to which this entry is applicable.  The interface
                                identified by a particular value of this index is





          T. A. Cox and K. Tesink (editors)                    [Page 37]





          Internet Draft           DS3 Objects                April 1992


                                the same interface as identified by the same value
                                an DS3LineIndex object instance."
                        ::= { ds3FarEndTotalEntry 1 }

                   ds3FarEndTotalESs OBJECT-TYPE
                       SYNTAX  Counter
                       ACCESS  read-only
                       STATUS  mandatory
                       DESCRIPTION
                               "The counter associated with the number of Far
                               End Errored Seconds encountered by a DS3
                               interface in the previous 24 hour interval."
                       ::= { ds3FarEndTotalEntry 2 }

                   ds3FarEndTotalSESs OBJECT-TYPE
                       SYNTAX  Counter
                       ACCESS  read-only
                       STATUS  mandatory
                       DESCRIPTION
                               "The counter associated with the number of
                               Far End Severely Errored Seconds
                               encountered by a DS3 interface in the previous 24 hour
                               interval."
                       ::= { ds3FarEndTotalEntry 3 }

                   ds3FarEndTotalCVs OBJECT-TYPE
                       SYNTAX  Counter
                       ACCESS  read-only
                       STATUS  mandatory
                       DESCRIPTION
                               "The counter associated with the number of
                               Far End Coding Violations reported via the
                               far end block error count
                               encountered by a
                               DS3 interface in the previous 24 hour interval."
                       ::= { ds3FarEndTotalEntry 4 }



          END










          T. A. Cox and K. Tesink (editors)                    [Page 38]





          Internet Draft           DS3 Objects                April 1992


          7.  Acknowledgments

          This document was produced by the SNMP and the Trunk MIB
          Working Groups:

                              Anne Ambler, Spider
                              Karl Auerbach, Sun
                              Fred Baker, ACC
                              Ken Brinkerhoff
                              Ron Broersma, NOSC
                              Jack Brown, US Army
                              Theodore Brunner, Bellcore
                              Jeffrey Buffum, HP
                              Jeffrey D. Case, UTK
                              Chris Chiptasso, Spartacus
                              Paul Ciarfella, DEC
                              Bob Collet
                              Tracy Cox, Bellcore
                              James R. Davin, MIT-LCS
                              Kurt Dobbins, Cabletron
                              Nadya El-Afandi, Network Systems
                              Gary Ellis, HP
                              Fred Engle
                              Mike Erlinger
                              Richard Fox, Synoptics
                              Karen Frisa, CMU
                              Chris Gunner, DEC
                              Ken Hibbard, Xylogics
                              Ole Jacobsen, Interop
                              Ken Jones
                              Satish Joshi, Synoptics
                              Frank Kastenholz, Racal-Interlan
                              Shimshon Kaufman, Spartacus
                              Jim Kinder, Fibercom
                              Alex Koifman, BBN
                              Christopher Kolb, PSI
                              Cheryl Krupczak, NCR
                              Peter Lin, Vitalink
                              John Lunny, TWG
                              Carl Malamud
                              Keith McCloghrie, HLS
                              Donna McMaster, David Systems
                              Lynn Monsanto, Sun
                              Dave Perkins, 3COM
                              Jim Reinstedler, Ungerman Bass





          T. A. Cox and K. Tesink (editors)                    [Page 39]





          Internet Draft           DS3 Objects                April 1992


                              Anil Rijsinghani, DEC
                              Kary Robertson
                              Marshall T. Rose, PSI (chair)
                              L. Michael Sabo, NCSC
                              Jon Saperia, DEC
                              John Seligson
                              Fei Shu, NEC
                              Sam Sjogren, TGV
                              Mark Sleeper, Sparta
                              Lance Sprung
                              Mike St.Johns
                              Bob Stewart, Xyplex
                              Emil Sturniold
                              Kaj Tesink, Bellcore
                              Dean Throop, Data General
                              Bill Townsend, Xylogics
                              Maurice Turcotte
                              Kannan Varadhou
                              Sudhanshu Verma, HP
                              Warren Vik, Interactive Systems
                              David Waitzman, BBN
                              Steve Waldbusser, CMU
                              Dan Wintringhan
                              David Wood
                              Jeff Young, Cray Research

























          T. A. Cox and K. Tesink (editors)                    [Page 40]





          Internet Draft           DS3 Objects                April 1992


          8.  References

             [1] Cerf, V., "IAB Recommendations for the Development of Internet
                 Network Management Standards", RFC 1052, NRI, April 1988.

             [2] Cerf, V., "Report of the Second Ad Hoc Network Management Review
                 Group", RFC 1109, NRI, August 1989.

             [3] Rose M., and K. McCloghrie, "Structure and Identification of
                 Management Information for TCP/IP-based internets", RFC 1155,
                 Performance Systems International, Hughes LAN Systems, May 1990.

             [4] 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.

             [5] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
                 Network Management Protocol", RFC 1157, SNMP Research,
                 Performance Systems International, Performance Systems
                 International, MIT Laboratory for Computer Science, May 1990.

             [6] McCloghrie K., and M. Rose, Editors, "Management Information Base
                 for Network Management of TCP/IP-based internets", RFC 1213,
                 Performance Systems International, March 1991.

             [7] Information processing systems - Open Systems Interconnection -
                 Specification of Abstract Syntax Notation One (ASN.1),
                 International Organization for Standardization, International
                 Standard 8824, December 1987.

             [8] 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.

             [9] American National Standard for telecommunications - digital
                 hierarchy - electrical interfaces, ANSI T1.102- 1987.

            [10] American National Standard for telecommunications - digital
                 hierarchy - formats specification, ANSI T1.107- 1988.

            [10a] ANSI T1.107a-1990.

            [11] American National Standard for telecommunications - Carrier-to-
                 Customer Installation - DS3 Metallic Interface, ANSI T1.404-1989.





          T. A. Cox and K. Tesink (editors)                    [Page 41]





          Internet Draft           DS3 Objects                April 1992


            [12] In-Service Digital Transmission Performance Monitoring Draft
                 Standard, T1M1.3/92-005.

            [13] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions",
                 RFC 1212, Performance Systems International, Hughes LAN Systems,
                 March 1991.












































          T. A. Cox and K. Tesink (editors)                    [Page 42]





          Internet Draft           DS3 Objects                April 1992


          9.  Security Considerations

          Security issues are not discussed in this memo.


          10.  Authors' Addresses

             Tracy A. Cox
             Bell Communications Research
             331 Newman Springs Road
             P.O. Box 7020
             Red Bank, NJ  07701-7020

             Phone: (908) 758-2107

             EMail: tacox@sabre.bellcore.com


             Kaj Tesink
             Bell Communications Research
             331 Newman Springs Road
             P.O. Box 7020
             Red Bank, NJ  07701-7020

             Phone: (908) 758-5254

             EMail: kaj@nvuxr.cc.bellcore.com























          T. A. Cox and K. Tesink (editors)                    [Page 43]





          Internet Draft           DS3 Objects                April 1992


          Table of Contents


          1 Status of this Memo ...................................    1
          2 Abstract ..............................................    1
          3 The Network Management Framework ......................    2
          4 Objects ...............................................    3
          4.1 Format of Definitions ...............................    3
          4.2 Changes from RFC1233 ................................    3
          5 Overview ..............................................    5
          5.1 Binding between ifIndex and DS3 Interfaces ..........    5
          5.2 Objectives of this MIB Module .......................    5
          5.3 DS3 Terminology .....................................    5
          6 Object Definitions ....................................    9
          6.1 The DS3 Near End Group ..............................   10
          6.1.1 The DS3 Configuration Group .......................   10
          6.1.2 The DS3 Interval Group ............................   18
          6.1.3 The DS3 Current Group .............................   22
          6.1.4 The DS3 Total Group ...............................   25
          6.2 The DS3 Far End Group ...............................   28
          6.2.1 The DS3 Far End Configuration Group ...............   28
          6.2.2 The DS3 Far End Interval Group ....................   32
          6.2.3 The DS3 Far End Current Group .....................   35
          6.2.4 The DS3 Far End Total Group .......................   37
          7 Acknowledgments .......................................   39
          8 References ............................................   41
          9 Security Considerations ...............................   43
          10 Authors' Addresses ...................................   43






















          T. A. Cox and K. Tesink (editors)                    [Page 44]











Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa01763;
          8 Apr 92 14:42 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa23804;
          8 Apr 92 14:45 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa23799; 8 Apr 92 14:45 EDT
Received: from saffron.acc.com by fennel.acc.com (4.1/SMI-4.1)
	id AA23731; Wed, 8 Apr 92 11:18:45 PDT
Received: by saffron.acc.com (4.1/SMI-4.1)
	id AA00563; Wed, 8 Apr 92 11:18:14 PDT
Date: Wed, 8 Apr 92 11:18:14 PDT
From: Fred Baker <fbaker@acc.com>
Message-Id: <9204081818.AA00563@saffron.acc.com>
To: lmarks@vnet.ibm.com
Subject: Re:  One more time
Cc: trunk-mib@acc.com

>> My preference is for convergence, at least at this juncture.

I don't think convergence is at issue; remember, we started out from
AT&T and ANSI documents a few years ago, and one point the DESCRIPTION
clauses all said "... as defined by AT&T 54016".  The concern is
*divergence*.  I'm more than willing to converge, again, now.  Is T1M1
willing to stop diverging?

I have the same problem in another venue; the Bridge MIB.  IEEE 802.5
wants us to track them, has wanted us to track them for a couple of
years, and is still changing things.

Please don't assume that we want to make life hard.  We want to make
effort finite.

Fred










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa02194;
          8 Apr 92 16:17 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa27408;
          8 Apr 92 16:20 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa27404; 8 Apr 92 16:20 EDT
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA24162; Wed, 8 Apr 92 12:53:04 PDT
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA04550; Wed, 8 Apr 92 15:47:50 EDT
Return-Path: <tacox@ginsu4@sabre.bellcore.com>
Received: from localhost by ginsu4 (4.1/4.7)
	id AA02735; Wed, 8 Apr 92 15:49:27 EDT
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9204081949.AA02735@ginsu4>
To: trunk-mib@acc.com
Subject: try again
Date: Wed, 08 Apr 92 15:49:26 -0400
From: tacox@ginsu4.bellcore.com


------- Forwarded Message

Return-Path: tacox@ginsu4
Received: by sword.bellcore.com;id 9204081951.AA25388
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA04524; Wed, 8 Apr 92 15:46:12 EDT
Return-Path: <tacox@ginsu4@sabre.bellcore.com>
Received: from localhost by ginsu4 (4.1/4.7)
	id AA02727; Wed, 8 Apr 92 15:47:47 EDT
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9204081947.AA02727@ginsu4>
To: tacox@ginsu4
Subject: send failed on enclosed draft
Date: Wed, 08 Apr 92 15:47:45 -0400
From: tacox@ginsu4



post: problem initializing server; [BHST] tcp/smtp: unknown service

Message not delivered to anyone.

- ------- Unsent Draft

To: fbaker@acc.com (Fred Baker)
cc: lmarks@vnet.ibm.com, trunk-mib@acc.com
Subject: Re: One more time 

I have a question about the totalTable.

Someone pointed out to me that the AT&T pub and the T1M1 document
don't like rolling 24 hr total counters -- they prefer day counters --
where a day is 24 hrs but starts and stops at 12:00am.

Does anyone have any idea what the current specs say on this and
what is actually implemented?

Tracy

- ------- End of Unsent Draft

------- End of Forwarded Message











Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa00560;
          9 Apr 92 9:00 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa08411;
          9 Apr 92 9:03 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa08407; 9 Apr 92 9:03 EDT
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA04540; Thu, 9 Apr 92 05:58:40 PDT
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA08715; Thu, 9 Apr 92 08:53:23 EDT
Return-Path: <tacox@ginsu4@sabre.bellcore.com>
Received: from localhost by ginsu4 (4.1/4.7)
	id AA02805; Thu, 9 Apr 92 08:55:03 EDT
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9204091255.AA02805@ginsu4>
To: Fred Baker <fbaker@acc.com>
Cc: NGOLDING%RALVMG@ralvm29.vnet.ibm.com, lmarks@vnet.ibm.com, 
    trunk-mib@acc.com
Subject: Re: 24 hour accumulations 
In-Reply-To: Your message of "Wed, 08 Apr 92 14:14:45 PDT."
             <9204082114.AA00638@saffron.acc.com> 
Date: Thu, 09 Apr 92 08:55:02 -0400
From: tacox@ginsu4.bellcore.com

Why don't we nuke the totals table all together and
leave it up to implementers/private-MIBs to decide
how to do 24-hr accumulation.  We still provide 96 15-minute
registers of all the counters.

Tracy










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa01267;
          9 Apr 92 11:34 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa14911;
          9 Apr 92 11:37 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa14905; 9 Apr 92 11:37 EDT
Received: from saffron.acc.com by fennel.acc.com (4.1/SMI-4.1)
	id AA04682; Thu, 9 Apr 92 08:31:12 PDT
Received: by saffron.acc.com (4.1/SMI-4.1)
	id AA00843; Thu, 9 Apr 92 08:29:22 PDT
Date: Thu, 9 Apr 92 08:29:22 PDT
From: Fred Baker <fbaker@acc.com>
Message-Id: <9204091529.AA00843@saffron.acc.com>
To: tacox@ginsu4.bellcore.com
Subject: Re: 24 hour accumulations
Cc: NGOLDING%RALVMG@ralvm29.vnet.ibm.com, lmarks@vnet.ibm.com, 
    trunk-mib@acc.com


I guess I'd like to hear a consensus - other opinions?

Fred










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa01898;
          9 Apr 92 13:26 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa19630;
          9 Apr 92 13:29 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa19626; 9 Apr 92 13:29 EDT
Received: from relay1.UU.NET by fennel.acc.com (4.1/SMI-4.1)
	id AA05162; Thu, 9 Apr 92 10:23:21 PDT
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA03044; Thu, 9 Apr 92 13:23:15 -0400
Received: from kentrox.UUCP by uunet.uu.net with UUCP/RMAIL
	(queueing-rmail) id 132259.15250; Thu, 9 Apr 1992 13:22:59 EDT
Received: from ktxs8.ktxnet by ktxnet (4.1/SMI-4.1)
	id AA22373; Thu, 9 Apr 92 10:00:15 PDT
Received: from ktxs1.ktxnet by ktxs8.ktxnet (4.1/SMI-4.1)
	id AA08133; Thu, 9 Apr 92 10:00:14 PDT
Date: Thu, 9 Apr 92 10:00:13 PDT
From: Dan Park <kentrox!ktxs8!park@uunet.uu.net>
Message-Id: <9204091700.AA08133@ktxs8.ktxnet>
To: uunet!acc.com!trunk-mib@uunet.uu.net
Subject: Re: 24 hour accumulations

I don't know how this matches up with AT&T or T1M1 documents, but
Kentrox DataSMART CSUs and DSUs accumulate the last 96 complete
15 minute intervals into the "Cur 24-hour" total line of their
performance reports.

If you use a time of day, should the counters clear at 00:00 GMT or
00:00 local time?  How accurate must your clock be?

Dan Park
ADC Kentrox










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa02609;
          9 Apr 92 15:09 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa24543;
          9 Apr 92 15:12 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa24539; 9 Apr 92 15:12 EDT
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA05958; Thu, 9 Apr 92 12:07:47 PDT
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA11529; Thu, 9 Apr 92 15:02:27 EDT
Return-Path: <tacox@ginsu4@sabre.bellcore.com>
Received: from localhost by ginsu4 (4.1/4.7)
	id AA02997; Thu, 9 Apr 92 15:04:08 EDT
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9204091904.AA02997@ginsu4>
To: Dan Park <kentrox!ktxs8!park@uunet.uu.net>
Cc: trunk-mib@acc.com
Subject: Re: 24 hour accumulations 
In-Reply-To: Your message of "Thu, 09 Apr 92 10:00:13 PDT."
             <9204091700.AA08133@ktxs8.ktxnet> 
Date: Thu, 09 Apr 92 15:04:06 -0400
From: tacox@ginsu4.bellcore.com

> 
> 
> I don't know how this matches up with AT&T or T1M1 documents, but
> Kentrox DataSMART CSUs and DSUs accumulate the last 96 complete
> 15 minute intervals into the "Cur 24-hour" total line of their
> performance reports.
> 
> If you use a time of day, should the counters clear at 00:00 GMT or
> 00:00 local time?  How accurate must your clock be?
> 
> Dan Park
> ADC Kentrox


Dan,

That is the way that the DS3/1 MIB is defined today.

But diverges from other standards documents.

Tracy










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa02772;
          9 Apr 92 15:33 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa25473;
          9 Apr 92 15:36 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa25469; 9 Apr 92 15:36 EDT
Received: from nbkanata.Newbridge.COM (NEWBRIDGE.COM) by fennel.acc.com (4.1/SMI-4.1)
	id AA06142; Thu, 9 Apr 92 12:31:09 PDT
Received: from Newbridge.COM ([138.120.100.14]) by nbkanata.Newbridge.COM (4.1/SMI-4.1)
	id AA03416; Thu, 9 Apr 92 15:31:07 EDT
Received: from nbntwk. by Newbridge.COM (4.0/SMI-4.0)
	id AA21623; Thu, 9 Apr 92 15:30:58 EDT
Received: from mailux.UUCP by nbntwk. (4.0/SMI-4.0)
	id AA02753; Thu, 9 Apr 92 15:30:22 EDT
Received: from MAILCENTRE1 (QM 2.5a) by mailux  (UMCP\QM 2.0.1)
 id AA00038; Thu, 9 Apr 1992 15:32:07 EST    
Message-Id: <00412.2785678327.38@mailux >
Organization: Newbridge Networks 600 March Road, Kanata Ontario, K2K2E6
X-Charset: MACINTOSH
X-Umcp-To: tacox
X-Umcp-Cc: DS1/DS3 MIB List IETF
From: James Watt <James_Watt@mailux.newbridge.com>
To: DS1/DS3 MIB List IETF <trunk-mib@acc.com>
Date: Thu, 9 Apr 1992 15:28:44 EST    
Subject: Re: >24 hour accumulations 

Date	4/9/92
Subject	RE>>24 hour accumulations
From	James Watt
To	tacox
CC	DS1/DS3 MIB List IETF

        Reply to:   RE>>24 hour accumulations
Tracy:
   Newbridge products do exactly what Dan described below.  I looked in TRs
62411 and 54016 _and_ T1.403 and couldn't find any mention of day
boundaries.  However, I do recall seeing something about it in one of the
(many) volumes of OSSGR...  

-james

--------------------------------------

> 
> 
> I don't know how this matches up with AT&T or T1M1 documents, but
> Kentrox DataSMART CSUs and DSUs accumulate the last 96 complete
> 15 minute intervals into the "Cur 24-hour" total line of their
> performance reports.
> 
> If you use a time of day, should the counters clear at 00:00 GMT or
> 00:00 local time?  How accurate must your clock be?
> 
> Dan Park
> ADC Kentrox


Dan,

That is the way that the DS3/1 MIB is defined today.

But diverges from other standards documents.

Tracy












Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa02833;
          9 Apr 92 15:50 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa26158;
          9 Apr 92 15:53 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa26154; 9 Apr 92 15:53 EDT
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA06222; Thu, 9 Apr 92 12:46:50 PDT
Return-Path: <kaj@nvuxr.cc.bellcore.com@sabre.bellcore.com>
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA11783; Thu, 9 Apr 92 15:41:31 EDT
Received: by sword.bellcore.com;id 9204091945.AA16563
Message-Id: <9204091945.AA16563@sword.bellcore.com>
Date: Thu, 9 Apr 92 15:45:36 EDT
To: Fred Baker <fbaker@acc.com>
From: kaj@nvuxr.cc.bellcore.com
Subject: Re: 24 hour accumulations
Cc: NGOLDING%RALVMG@ralvm29.vnet.ibm.com, lmarks@vnet.ibm.com, 
    trunk-mib@acc.com

>I guess I'd like to hear a consensus - other opinions?
>
>Fred

I agree with tracy of course
my rationale is however the traditional snmp axiom
that a parameter shall not be mibbed when it can be derived from
other mibbed parameters.
very true in this case, and saves quite a bit. note also that when using
the
DSx mibs by NMS or by proxy it is unlikely that you would retrieve the
total table; calculating it locally may be more efficient.

kaj
0------------0--------------0-------------0-------------0-----------0
Kaj Tesink                            vmail (908) 758-5254
pmail Bellcore                      faxmail (908) 758-4196
      331 Newman Springs Rd.          email kaj@nvuxr.cc.bellcore.com
      Red Bank, NJ 07701











Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa03075;
          9 Apr 92 16:27 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa28063;
          9 Apr 92 16:30 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa28059; 9 Apr 92 16:30 EDT
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA06439; Thu, 9 Apr 92 13:22:42 PDT
Return-Path: <kaj@nvuxr.cc.bellcore.com@sabre.bellcore.com>
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA12027; Thu, 9 Apr 92 16:17:23 EDT
Received: by sword.bellcore.com;id 9204092020.AA17561
Message-Id: <9204092020.AA17561@sword.bellcore.com>
Date: Thu, 9 Apr 92 16:20:27 EDT
To: Fred Baker <fbaker@acc.com>
From: kaj@nvuxr.cc.bellcore.com
Subject: Re: 24 hour accumulations
Cc: lmarks@vnet.ibm.com, trunk-mib@acc.com

>I guess I'd like to hear a consensus - other opinions?
>
>Fred

I agree with tracy of course
my rationale is however the traditional snmp axiom
that a parameter shall not be mibbed when it can be derived from
other mibbed parameters.
very true in this case, and saves quite a bit. note also that when using
the
DSx mibs by NMS or by proxy it is unlikely that you would retrieve the
total table; calculating it locally may be more efficient.

kaj
0------------0--------------0-------------0-------------0-----------0
Kaj Tesink                            vmail (908) 758-5254
pmail Bellcore                      faxmail (908) 758-4196
      331 Newman Springs Rd.          email kaj@nvuxr.cc.bellcore.com
      Red Bank, NJ 07701













Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa03752;
          9 Apr 92 18:41 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa04079;
          9 Apr 92 18:44 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa04069; 9 Apr 92 18:44 EDT
Received: from vnet.ibm.com by fennel.acc.com (4.1/SMI-4.1)
	id AA07266; Thu, 9 Apr 92 15:37:03 PDT
Message-Id: <9204092237.AA07266@fennel.acc.com>
Received: from RALVM29 by vnet.ibm.com (IBM VM SMTP V2R2) with BSMTP id 0838;
   Thu, 09 Apr 92 18:36:10 EST
Date: Thu, 9 Apr 92 18:37:33 EDT
From: "Laurence V. Marks" <lmarks@vnet.ibm.com>
To: trunk-mib@acc.com
Subject: 24 hour tables, consensus

Consensus comment:
I could go along with deleting the table, for the reason Kaj
expressed, namely that it's derivable.

Some trivia:
1) Our T1M1 representative read the pertinant section (9.1.2, page 35)
   of the latest draft of T1M1.3 to me over the phone.  It still calls
   for clearing the accumulators once every 24 hours, but lets the
   time be arbitrary--something like e.g., 0000 hours.

2) AT&T TR 54016 calls for sliding window, or rolling, or re-sum at
   every interval, or however you care to describe it.  However, the
   same TRstates that AT&T's intent is to migrate away from 54016 to
   ANSI T1.403.  That means there will no longer be any AT&T-defined
   parameter storage requirements.

Larry Marks










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa01349;
          10 Apr 92 11:07 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa14689;
          10 Apr 92 11:10 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa14683;
          10 Apr 92 11:10 EDT
Received: from phaedrus.psi.com by fennel.acc.com (4.1/SMI-4.1)
	id AA05130; Fri, 10 Apr 92 08:01:40 PDT
Received: from localhost by phaedrus.psi.com (5.61/2.1-PSI/PSINet)
	id AA00619; Fri, 10 Apr 92 11:01:27 -0400
Message-Id: <9204101501.AA00619@phaedrus.psi.com>
To: tacox@ginsu4.bellcore.com
Cc: Dan Park <kentrox!ktxs8!park@uunet.uu.net>, trunk-mib@acc.com, 
    kolb@phaedrus.psi.com
Subject: Re: 24 hour accumulations 
In-Reply-To: Your message of "Thu, 09 Apr 92 15:04:06 EDT."
             <9204091904.AA02997@ginsu4> 
Date: Fri, 10 Apr 92 11:01:25 -0400
From: kolb@phaedrus.psi.com


> > From: kentrox!ktxs8!park@uunet.uu.net (Dan Park)
> From: tacox@ginsu4.bellcore.com

> > I don't know how this matches up with AT&T or T1M1 documents, but
> > Kentrox DataSMART CSUs and DSUs accumulate the last 96 complete
> > 15 minute intervals into the "Cur 24-hour" total line of their
> > performance reports.

> That is the way that the DS3/1 MIB is defined today.

 it was originally added as an optimization.  many csus support the concept
 of "24 hour total" registers, and so this was added to the mib so that a
 manager could exploit this feature.  for those csus that do not support it,
 it is easy enough for the agent to fake it by summing the most recent 96
 interval registers.

 one might argue that one of the philosophies of mib writers in the past was
 to not support derivable variables in mibs.  that makes sense when you can
 derive one value from a few other values.  it doesn't hold up so well when
 one has to derive that value from 96 other values, or one has to derive N
 values from N*96 values.

 another philosophy is that one endeavors to make the agent as simple as
 possible.  simplicity has a cost however.  the cost of supporting the
 table in the agent is probably nominal.  the cost of not supporting it
 is that the manager now needs to get the values of N*96 variables to
 compute N values, increasing the load on the agent, manager, and network.
 the implementation cost to the manager is probably not nominal.

 having each *agent* (not csu) vendor implement this table in their own
 portion of the mib (the private enterprises mib) would only serve to
 tease.  sure you can get the totals quickly, but you can't get them in
 a standard way, you have to know each vendor's private mib, and private
 mibs are not guaranteed not to change from release to release.  the bottom
 line is that the table would only get exploited by managers written by the
 same vendor as the agent.

> But diverges from other standards documents.

 are 24 hour totals important?  relevant?  of any value?  well that's 
 another question.  i don't have an answer.  they seem to be supported
 in alot of csus, so somebody must think they're important...  :^)

 chris










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa02956;
          10 Apr 92 15:08 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa26146;
          10 Apr 92 15:11 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa26142;
          10 Apr 92 15:11 EDT
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA12072; Fri, 10 Apr 92 12:05:24 PDT
Return-Path: <kaj@nvuxr.cc.bellcore.com@sabre.bellcore.com>
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA17325; Fri, 10 Apr 92 14:59:56 EDT
Received: by sword.bellcore.com;id 9204101904.AA02267
Message-Id: <9204101904.AA02267@sword.bellcore.com>
Date: Fri, 10 Apr 92 15:04:32 EDT
To: kolb@phaedrus.psi.com
From: kaj@nvuxr.cc.bellcore.com
Subject: Re: 24 hour accumulations
Cc: trunk-mib@acc.com, kentrox!ktxs8!park@uunet.uu.net


>
> one might argue that one of the philosophies of mib writers in the past was
> to not support derivable variables in mibs.  that makes sense when you can
> derive one value from a few other values.  it doesn't hold up so well when
> one has to derive that value from 96 other values, or one has to derive N
> values from N*96 values.
>
thats a good point, but i cant resist asking: how often do you need
this anyway? if this is relatively rare then it is quite ok to have
some overhead.
>
> are 24 hour totals important?  relevant?  of any value?  well that's 
> another question.  i don't have an answer.  they seem to be supported
> in alot of csus, so somebody must think they're important...  :^)
>
i dont know either; it may be one of those historic cases of "it has always
been there"...

kaj
0------------0--------------0-------------0-------------0-----------0
Kaj Tesink                            vmail (908) 758-5254
pmail Bellcore                      faxmail (908) 758-4196
      331 Newman Springs Rd.          email kaj@nvuxr.cc.bellcore.com
      Red Bank, NJ 07701











Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa01556;
          13 Apr 92 9:05 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa28357;
          13 Apr 92 9:09 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa28353; 13 Apr 92 9:09 EDT
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA04810; Mon, 13 Apr 92 06:03:36 PDT
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA25920; Mon, 13 Apr 92 08:58:08 EDT
Return-Path: <tacox@sabre.bellcore.com>
Received: by ginsu4 (4.1/4.7)
	id AA03246; Mon, 13 Apr 92 09:00:00 EDT
Date: Mon, 13 Apr 92 09:00:00 EDT
From: Tracy Cox <tacox@sabre.bellcore.com>
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9204131300.AA03246@ginsu4>
To: trunk-mib@acc.com
Subject: 24 hour accumulation

Gang,

My take on this arguement is that existing
CSU products implement counters
as a rolling 24 hour window.

Standards have defined resetting the 24 hour
registers every 24 hours -- could be equated
to a one day register (current day or previous day).

If we keep the totalTables as defined and as implemented,
they will be defined differently then the standards have defined
them.
This is no big deal in my book.

I say keep the definition as a sliding 24 hour window --
this is what is implemented and works.


Tracy












Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa02640;
          13 Apr 92 11:31 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa04370;
          13 Apr 92 11:35 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa04354;
          13 Apr 92 11:35 EDT
Received: from nrc.com (aztec.NRC.COM) by fennel.acc.com (4.1/SMI-4.1)
	id AA04884; Mon, 13 Apr 92 08:24:17 PDT
Received: by nrc.com (4.0/NRC-DDN1.2)
	id AA07523; Mon, 13 Apr 92 07:55:12 PDT
Date: Mon, 13 Apr 92 07:55:12 PDT
From: Bill Versteeg <bvs@nrc.com>
Message-Id: <9204131455.AA07523@nrc.com>
To: trunk-mib@acc.com
Subject: 24 hour counters




On the subject of resetting 24 hour counters at midnight-

How closely do the clocks of the manager and the agent need to be synched?
How does one get the WHOLE day's counts if the second that the grand total
	is calculated, it is zeroed for the next day's count?
I can visualize low-end products that do not maintain time of day. How
	do we initialize and maintain time of day on a device that
	has no battery backed clock on-board? Run NNTP???? I hope not.


Lets not open ourselves up to this black hole. Just say no.


bvs











Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa03297;
          13 Apr 92 13:02 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa08504;
          13 Apr 92 13:06 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa08498;
          13 Apr 92 13:06 EDT
Received: from phaedrus.psi.com by fennel.acc.com (4.1/SMI-4.1)
	id AA05114; Mon, 13 Apr 92 09:57:52 PDT
Received: from localhost by phaedrus.psi.com (5.61/2.1-PSI/PSINet)
	id AA00945; Mon, 13 Apr 92 12:57:46 -0400
Message-Id: <9204131657.AA00945@phaedrus.psi.com>
To: kaj@nvuxr.cc.bellcore.com
Cc: trunk-mib@acc.com, kentrox!ktxs8!park@uunet.uu.net
Subject: Re: 24 hour accumulations 
In-Reply-To: Your message of "Fri, 10 Apr 92 15:04:32 EDT."
             <9204101904.AA02267@sword.bellcore.com> 
Date: Mon, 13 Apr 92 12:57:43 -0400
From: kolb@phaedrus.psi.com


> From: kaj@nvuxr.cc.bellcore.com

> > one might argue that one of the philosophies of mib writers in the past was
> > to not support derivable variables in mibs.  that makes sense when you can
> > derive one value from a few other values.  it doesn't hold up so well when
> > one has to derive that value from 96 other values, or one has to derive N
> > values from N*96 values.

> thats a good point, but i cant resist asking: how often do you need
> this anyway? if this is relatively rare then it is quite ok to have
> some overhead.

 it depends on the answer to the next question...  if the 24 hour total
 is meaningful, then probably alot.  otherwise, probably not much if ever.

> > are 24 hour totals important?  relevant?  of any value?  well that's 
> > another question.  i don't have an answer.  they seem to be supported
> > in alot of csus, so somebody must think they're important...  :^)

> i dont know either; it may be one of those historic cases of "it has always
> been there"...

> kaj

 chris










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa05265;
          13 Apr 92 19:51 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa25191;
          13 Apr 92 19:55 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa25172;
          13 Apr 92 19:55 EDT
Received: from nbkanata.Newbridge.COM (NEWBRIDGE.COM) by fennel.acc.com (4.1/SMI-4.1)
	id AA05695; Mon, 13 Apr 92 16:46:25 PDT
Received: from Newbridge.COM ([138.120.100.14]) by nbkanata.Newbridge.COM (4.1/SMI-4.1)
	id AA14779; Mon, 13 Apr 92 19:46:27 EDT
Received: from nbntwk. by Newbridge.COM (4.0/SMI-4.0)
	id AA25667; Mon, 13 Apr 92 19:46:08 EDT
Received: from mailux.UUCP by nbntwk. (4.0/SMI-4.0)
	id AA05464; Mon, 13 Apr 92 19:45:36 EDT
Received: from MAILCENTRE1 (QM 2.5a) by mailux  (UMCP\QM 2.0.1)
 id AA00072; Mon, 13 Apr 1992 19:47:36 EST    
Message-Id: <00412.2786039256.72@mailux >
Organization: Newbridge Networks 600 March Road, Kanata Ontario, K2K2E6
X-Charset: MACINTOSH
X-Umcp-To: DS1/DS3 MIB List IETF, kolb
From: James Watt <James_Watt@mailux.newbridge.com>
To: DS1/DS3 MIB List IETF <trunk-mib@acc.com>
Date: Mon, 13 Apr 1992 19:43:28 EST    
Subject: Re: >24 hour accumulations 

Date	4/13/92
Subject	RE>>24 hour accumulations
From	James Watt
To	DS1/DS3 MIB List IETF, kolb

        Reply to:   RE>>24 hour accumulations
  I think people are interested in the 24 hour totals because some of the
carriers service descriptions talk about  service objectives in such a
period, e.g. "The quality of the circuit will meet or exceed 95% error free
seconds in any consecutive 24 hour time period." (from the Jan 83 issue of
(then) PUB 41451).

  Similarly, the Dec 1990 issue of TR 62411 contains a triplet of tables
(3.1, 3.2 and 3.3) all entitled "ACCUNET T1.5 PERFORMANCE: XXX" where XXX is
one of end-to-end, inter-office and access.  These tables list target
(maximum) values for ES's per "day", %EFS per day and SES per day as well as
%availability "per quarter" and "per year".

  I didn't bother to check the ASDS spec (TR 62421) but I seem to remember
it containing similar information.

  Given such promises, it would be eminently reasonable for one's NMS to
check the totals every fifteen minutes and if it ever sees anything worse,
raise a trouble ticket and forward it to the appropriate carrier. 

-james

ES = Errored Second
EFS = Error Free Second
SES = Severly Errored Second
--------------------------------------
Date: 4/13/92 13:20
To: James Watt
From: kolb
Received: from nbntwk by mailux  (UMCP\QM 2.0.1)
 id AA2786016028; Mon, 13 Apr 1992 13:20:28 EST    
From phaedrus.psi.com!kolb  Mon Apr 13 12:57:27 1992 remote from nbntwk
Received: from Newbridge.COM (thor) by nbntwk. (4.0/SMI-4.0)
	id AA05088; Mon, 13 Apr 92 12:57:27 EDT
Received: from nbkanata.Newbridge.COM (nbkanata-gw) by Newbridge.COM
(4.0/SMI-4.0)
	id AA22655; Mon, 13 Apr 92 12:57:59 EDT
Received: from fennel.acc.com by nbkanata.Newbridge.COM (4.1/SMI-4.1)
	id AA11993; Mon, 13 Apr 92 12:58:09 EDT
Received: from phaedrus.psi.com by fennel.acc.com (4.1/SMI-4.1)
	id AA05114; Mon, 13 Apr 92 09:57:52 PDT
Received: from localhost by phaedrus.psi.com (5.61/2.1-PSI/PSINet)
	id AA00945; Mon, 13 Apr 92 12:57:46 -0400
Message-Id: <9204131657.AA00945@phaedrus.psi.com>
To: nvuxr.cc.bellcore.com!kaj
Cc: acc.com!trunk-mib, uunet.uu.net!kentrox!ktxs8!park
Subject: Re: 24 hour accumulations 
In-Reply-To: Your message of "Fri, 10 Apr 92 15:04:32 EDT."
             <9204101904.AA02267@sword.bellcore.com> 
Date: Mon, 13 Apr 92 12:57:43 -0400
From: nbntwk!phaedrus.psi.com!kolb


> From: kaj@nvuxr.cc.bellcore.com

> > one might argue that one of the philosophies of mib writers in the past
was
> > to not support derivable variables in mibs.  that makes sense when you
can
> > derive one value from a few other values.  it doesn't hold up so well
when
> > one has to derive that value from 96 other values, or one has to derive
N
> > values from N*96 values.

> thats a good point, but i cant resist asking: how often do you need
> this anyway? if this is relatively rare then it is quite ok to have
> some overhead.

 it depends on the answer to the next question...  if the 24 hour total
 is meaningful, then probably alot.  otherwise, probably not much if ever.

> > are 24 hour totals important?  relevant?  of any value?  well that's 
> > another question.  i don't have an answer.  they seem to be supported
> > in alot of csus, so somebody must think they're important...  :^)

> i dont know either; it may be one of those historic cases of "it has
always
> been there"...

> kaj

 chris












Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa04409;
          15 Apr 92 14:41 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa20440;
          15 Apr 92 14:44 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa20436;
          15 Apr 92 14:44 EDT
Received: from mace.LCS.MIT.EDU by fennel.acc.com (4.1/SMI-4.1)
	id AA12805; Wed, 15 Apr 92 11:38:36 PDT
Received: from MACE.LCS.MIT.EDU by mace.LCS.MIT.EDU via TCP with SMTP
	id AA03942; Wed, 15 Apr 92 14:38:19 EDT
Message-Id: <9204151838.AA03942@mace.LCS.MIT.EDU>
From: "James R. (Chuck) Davin" <jrd@thyme.lcs.mit.edu>
To: Tracy Cox <tacox@sabre.bellcore.com>
Cc: trunk-mib@acc.com
Subject: Re: 24 hour accumulation 
In-Reply-To: Your message of Mon, 13 Apr 92 09:00:00 -0400.
             <9204131300.AA03246@ginsu4> 
Date: Wed, 15 Apr 92 14:38:16 -0400
Sender: jrd@mace.lcs.mit.edu


Syntactic nit: somebody may have mentioned this, but if these
"counters" are sliding rather than monotonically increasing, INTEGER
may be a more appropriate syntax than Counter.

>> Date: Mon, 13 Apr 92 09:00:00 EDT
>> From: tacox@sabre.bellcore.com (Tracy Cox)
>> X-Station-Sent-From: ginsu4.bellcore.com
>> To: trunk-mib@acc.com
>> Subject: 24 hour accumulation
>> 
>> Gang,
>> 
>> My take on this arguement is that existing
>> CSU products implement counters
>> as a rolling 24 hour window.
>> 
>> Standards have defined resetting the 24 hour
>> registers every 24 hours -- could be equated
>> to a one day register (current day or previous day).
>> 
>> If we keep the totalTables as defined and as implemented,
>> they will be defined differently then the standards have defined
>> them.
>> This is no big deal in my book.
>> 
>> I say keep the definition as a sliding 24 hour window --
>> this is what is implemented and works.
>> 
>> 
>> Tracy
>> 
>> 











Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa04511;
          15 Apr 92 14:52 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa20799;
          15 Apr 92 14:55 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa20795;
          15 Apr 92 14:55 EDT
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA13000; Wed, 15 Apr 92 11:45:34 PDT
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA14888; Wed, 15 Apr 92 14:39:53 EDT
Return-Path: <tacox@ginsu4@sabre.bellcore.com>
Received: from localhost by ginsu4 (4.1/4.7)
	id AA03820; Wed, 15 Apr 92 14:41:51 EDT
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9204151841.AA03820@ginsu4>
To: "James R. (Chuck) Davin" <jrd@thyme.lcs.mit.edu>
Cc: Tracy Cox <tacox@sabre.bellcore.com>, trunk-mib@acc.com
Subject: Re: 24 hour accumulation 
In-Reply-To: Your message of "Wed, 15 Apr 92 14:38:16 EDT."
             <9204151838.AA03942@mace.LCS.MIT.EDU> 
Date: Wed, 15 Apr 92 14:41:50 -0400
From: tacox@ginsu4.bellcore.com

> 
> 
> 
> Syntactic nit: somebody may have mentioned this, but if these
> "counters" are sliding rather than monotonically increasing, INTEGER
> may be a more appropriate syntax than Counter.

you are correct -- do we need to deprecate the table
to make this SYNTAX change?

Tracy


> 
> >> Date: Mon, 13 Apr 92 09:00:00 EDT
> >> From: tacox@sabre.bellcore.com (Tracy Cox)
> >> X-Station-Sent-From: ginsu4.bellcore.com
> >> To: trunk-mib@acc.com
> >> Subject: 24 hour accumulation
> >> 
> >> Gang,
> >> 
> >> My take on this arguement is that existing
> >> CSU products implement counters
> >> as a rolling 24 hour window.
> >> 
> >> Standards have defined resetting the 24 hour
> >> registers every 24 hours -- could be equated
> >> to a one day register (current day or previous day).
> >> 
> >> If we keep the totalTables as defined and as implemented,
> >> they will be defined differently then the standards have defined
> >> them.
> >> This is no big deal in my book.
> >> 
> >> I say keep the definition as a sliding 24 hour window --
> >> this is what is implemented and works.
> >> 
> >> 
> >> Tracy
> >> 
> >> 
> 











Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa04772;
          15 Apr 92 15:10 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa21548;
          15 Apr 92 15:13 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa21544;
          15 Apr 92 15:13 EDT
Received: from saffron.acc.com by fennel.acc.com (4.1/SMI-4.1)
	id AA13672; Wed, 15 Apr 92 12:08:13 PDT
Received: by saffron.acc.com (4.1/SMI-4.1)
	id AA00401; Wed, 15 Apr 92 12:06:02 PDT
Date: Wed, 15 Apr 92 12:06:02 PDT
From: Fred Baker <fbaker@acc.com>
Message-Id: <9204151906.AA00401@saffron.acc.com>
To: tacox@ginsu4.bellcore.com
Subject: Re: 24 hour accumulation
Cc: jrd@thyme.lcs.mit.edu, trunk-mib@acc.com


yes, I think we would need to deprecate the table

This is getting gooey.

Fred










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa05902;
          15 Apr 92 17:25 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa26793;
          15 Apr 92 17:29 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa26782;
          15 Apr 92 17:29 EDT
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA16676; Wed, 15 Apr 92 14:23:11 PDT
Return-Path: <kaj@nvuxr.cc.bellcore.com@sabre.bellcore.com>
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA15942; Wed, 15 Apr 92 17:17:36 EDT
Received: by sword.bellcore.com;id 9204152122.AA09397
Message-Id: <9204152122.AA09397@sword.bellcore.com>
Date: Wed, 15 Apr 92 17:22:46 EDT
To: trunk-mib@acc.com
From: kaj@nvuxr.cc.bellcore.com
Subject: Re: 24 hour accumulation
Cc: kaj@nvuxr.cc.bellcore.com, tacox@sabre.bellcore.com

chuck writes:
Syntactic nit: somebody may have mentioned this, but if these
"counters" are sliding rather than monotonically increasing, INTEGER
may be a more appropriate syntax than Counter.

tracy asks
you are correct -- do we need to deprecate the table
to make this SYNTAX change?

fred sez
yes, I think we would need to deprecate the table


chuck gets the price for spotting sloppy asn.1 notation.
now what do we do. deprecation is indeed the formal way to go.
it does produce a mess though; one deprecated table, and a virtually
identical new one.
may i be so bold to ask whether anybody would be bothered by
just changing the "Counter"s into "INTEGER"s? after all, a Counter IS
an INTEGER, with the additional semantics that its value only goes up.
it does not have any coding implications as far as i can see.
my bet is that the semantics in our case have not had any implementation
consequences, since after all, the meaning of the table has been a
sliding window all the time.
so cant we treat it as an editorial in this case? rather than as a
deprecation?

saves the editors work, and the readers a headache wondering whether
they should implement both tables.

kaj
0------------0--------------0-------------0-------------0-----------0
Kaj Tesink                            vmail (908) 758-5254
pmail Bellcore                      faxmail (908) 758-4196
      331 Newman Springs Rd.          email kaj@nvuxr.cc.bellcore.com
      Red Bank, NJ 07701











Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa05908;
          15 Apr 92 17:28 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa26881;
          15 Apr 92 17:31 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa26877;
          15 Apr 92 17:31 EDT
Received: from mace.LCS.MIT.EDU by fennel.acc.com (4.1/SMI-4.1)
	id AA16682; Wed, 15 Apr 92 14:26:38 PDT
Received: from MACE.LCS.MIT.EDU by mace.LCS.MIT.EDU via TCP with SMTP
	id AA05479; Wed, 15 Apr 92 17:24:23 EDT
Message-Id: <9204152124.AA05479@mace.LCS.MIT.EDU>
From: "James R. (Chuck) Davin" <jrd@thyme.lcs.mit.edu>
To: tacox@ginsu4.bellcore.com
Cc: "James R. (Chuck) Davin" <jrd@thyme.lcs.mit.edu>, 
    Tracy Cox <tacox@sabre.bellcore.com>, trunk-mib@acc.com
Subject: Re: 24 hour accumulation 
In-Reply-To: Your message of Wed, 15 Apr 92 14:41:50 -0400.
             <9204151841.AA03820@ginsu4> 
Date: Wed, 15 Apr 92 17:24:21 -0400
Sender: jrd@mace.lcs.mit.edu


Oh, sugar! Why is life so complicated? Yes, technically, deprecation
is needed for a syntactic change. I guess this additional fun issue is
also lurking in the question of whether one wants to "slide" or count
montonically.

>> X-Station-Sent-From: ginsu4.bellcore.com
>> To: "James R. (Chuck) Davin" <jrd@thyme.lcs.mit.edu>
>> Cc: tacox@sabre.bellcore.com (Tracy Cox), trunk-mib@acc.com
>> Subject: Re: 24 hour accumulation 
>> Date: Wed, 15 Apr 92 14:41:50 -0400
>> From: tacox@ginsu4.bellcore.com
>> 
>> > 
>> > 
>> > 
>> > Syntactic nit: somebody may have mentioned this, but if these
>> > "counters" are sliding rather than monotonically increasing, INTEGER
>> > may be a more appropriate syntax than Counter.
>> 
>> you are correct -- do we need to deprecate the table
>> to make this SYNTAX change?
>> 
>> Tracy
>> 
>> 
>> > 
>> > >> Date: Mon, 13 Apr 92 09:00:00 EDT
>> > >> From: tacox@sabre.bellcore.com (Tracy Cox)
>> > >> X-Station-Sent-From: ginsu4.bellcore.com
>> > >> To: trunk-mib@acc.com
>> > >> Subject: 24 hour accumulation
>> > >> 
>> > >> Gang,
>> > >> 
>> > >> My take on this arguement is that existing
>> > >> CSU products implement counters
>> > >> as a rolling 24 hour window.
>> > >> 
>> > >> Standards have defined resetting the 24 hour
>> > >> registers every 24 hours -- could be equated
>> > >> to a one day register (current day or previous day).
>> > >> 
>> > >> If we keep the totalTables as defined and as implemented,
>> > >> they will be defined differently then the standards have defined
>> > >> them.
>> > >> This is no big deal in my book.
>> > >> 
>> > >> I say keep the definition as a sliding 24 hour window --
>> > >> this is what is implemented and works.
>> > >> 
>> > >> 
>> > >> Tracy
>> > >> 
>> > >> 
>> > 
>> 











Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa05940;
          15 Apr 92 17:45 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa27360;
          15 Apr 92 17:49 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa27356;
          15 Apr 92 17:49 EDT
Received: from saffron.acc.com by fennel.acc.com (4.1/SMI-4.1)
	id AA16715; Wed, 15 Apr 92 14:43:23 PDT
Received: by saffron.acc.com (4.1/SMI-4.1)
	id AA00444; Wed, 15 Apr 92 14:42:49 PDT
Date: Wed, 15 Apr 92 14:42:49 PDT
From: Fred Baker <fbaker@acc.com>
Message-Id: <9204152142.AA00444@saffron.acc.com>
To: jrd@thyme.lcs.mit.edu
Subject: Re: 24 hour accumulation
Cc: trunk-mib@fennel.acc.com


Chuck:

Since we're looping at proposed, what if we simply "left out" the
deprecated ASN.1 names?  as in, use a new ASN.1 name for the totals
table in INTEGER or Gauge form, and leave the other <incorrect> one in
the other RFC?

Seems like that preserves the editors wits (Kaj's point) and doesn't
propagate confusion over the tables

Fred










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa03225;
          16 Apr 92 14:31 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa19913;
          16 Apr 92 14:35 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa19900;
          16 Apr 92 14:35 EDT
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA10543; Thu, 16 Apr 92 11:19:04 PDT
Return-Path: <kaj@nvuxr.cc.bellcore.com@sabre.bellcore.com>
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA20788; Thu, 16 Apr 92 14:13:27 EDT
Received: by sword.bellcore.com;id 9204161818.AA18945
Message-Id: <9204161818.AA18945@sword.bellcore.com>
Date: Thu, 16 Apr 92 14:18:40 EDT
To: Fred Baker <fbaker@acc.com>
From: kaj@nvuxr.cc.bellcore.com
Subject: Re: 24 hour accumulation
Cc: trunk-mib@fennel.acc.com

>Since we're looping at proposed, what if we simply "left out" the
>deprecated ASN.1 names?  as in, use a new ASN.1 name for the totals
>table in INTEGER or Gauge form, and leave the other <incorrect> one in
>the other RFC?
>
>Seems like that preserves the editors wits (Kaj's point) and doesn't
>propagate confusion over the tables
>
Since some folks have implemented this, this would mean at best
that they would have to change their OIDs (trivial) and at worst
that some incompatible systems would be around (old&new).
Also, leaving it out has the problem that some nitwit in the future may
think it a good idea to use that "skipped" OID, which would violate
some holy rules.

My preference is that we just change Counter for INTEGER since
in this case it does not matter, and it would avoid any change in old
systems.
PS Note the MOSY description in the Simple Book:
  
  typedef int integer

where typedef is integer, counter, guage, timeticks

kaj
0------------0--------------0-------------0-------------0-----------0
Kaj Tesink                            vmail (908) 758-5254
pmail Bellcore                      faxmail (908) 758-4196
      331 Newman Springs Rd.          email kaj@nvuxr.cc.bellcore.com
      Red Bank, NJ 07701











Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa03296;
          16 Apr 92 14:44 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa20777;
          16 Apr 92 14:48 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa20767;
          16 Apr 92 14:48 EDT
Received: from saffron.acc.com by fennel.acc.com (4.1/SMI-4.1)
	id AA11743; Thu, 16 Apr 92 11:41:18 PDT
Received: by saffron.acc.com (4.1/SMI-4.1)
	id AA00606; Thu, 16 Apr 92 11:40:43 PDT
Date: Thu, 16 Apr 92 11:40:43 PDT
From: Fred Baker <fbaker@acc.com>
Message-Id: <9204161840.AA00606@saffron.acc.com>
To: kaj@nvuxr.cc.bellcore.com
Subject: Re: 24 hour accumulation
Cc: trunk-mib@fennel.acc.com


Kaj:

There is a difference worth noting.  While MOSY's internal
representation of a Counter in "integer", the ASN.1 format of a Counter
differs from that of an INTEGER, as does the ASN.1 description of a
Gauge or a TimeTick.

Therefore, backward compatibility is not enhanced by simply changing
the format.  If anything compatibility is enhanced by changing the
format and the OID, as the old format will still be coupled to the old
OID.

Fred










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa03936;
          16 Apr 92 15:58 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa25594;
          16 Apr 92 16:01 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa25590;
          16 Apr 92 16:01 EDT
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA13723; Thu, 16 Apr 92 12:52:34 PDT
Return-Path: <kaj@nvuxr.cc.bellcore.com@sabre.bellcore.com>
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA21442; Thu, 16 Apr 92 15:46:52 EDT
Received: by sword.bellcore.com;id 9204161952.AA21021
Message-Id: <9204161952.AA21021@sword.bellcore.com>
Date: Thu, 16 Apr 92 15:52:02 EDT
To: Fred Baker <fbaker@acc.com>
From: kaj@nvuxr.cc.bellcore.com
Subject: Re: 24 hour accumulation
Cc: trunk-mib@fennel.acc.com

>There is a difference worth noting.  While MOSY's internal
>representation of a Counter in "integer", the ASN.1 format of a Counter
>differs from that of an INTEGER, as does the ASN.1 description of a
>Gauge or a TimeTick.
>
yes this is true. so back to deprecation?
0------------0--------------0-------------0-------------0-----------0
Kaj Tesink                            vmail (908) 758-5254
pmail Bellcore                      faxmail (908) 758-4196
      331 Newman Springs Rd.          email kaj@nvuxr.cc.bellcore.com
      Red Bank, NJ 07701











Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa03961;
          16 Apr 92 16:08 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa26131;
          16 Apr 92 16:11 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa26124;
          16 Apr 92 16:11 EDT
Received: from inet-gw-1.pa.dec.com by fennel.acc.com (4.1/SMI-4.1)
	id AA13742; Thu, 16 Apr 92 13:02:14 PDT
Received: by inet-gw-1.pa.dec.com; id AA09430; Thu, 16 Apr 92 13:01:59 -0700
Received: by adaptive (/\==/\ Smail3.1.22.1 #22.4)id <m0lbcdm-0000LrC@adaptive>; Thu, 16 Apr 92 13:01 PDT
Message-Id: <m0lbcdm-0000LrC@adaptive>
Date: Thu, 16 Apr 92 13:01 PDT
From: Jim Frimmel <jim@adaptive.com>
To: trunk-mib@acc.com
Subject: 24 hour counters

A reset counters operation to a CSU/DSU causes the the current counter
values to be sent, then cleared as an "atomic" operation. This
is so that no performance data is lost. The polling of the remote unit
is done around midnight but there can be a discrepancy of as much
as 15 minutes.

Although I write T1/T3 software, including performance monitoring,
my understanding of the management of carrier WAN's is limited to 
my conversations with others. I think this is right, though.

Is there a "atomic read and clear" concept in SNMP? 

    -jf-










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa03994;
          16 Apr 92 16:18 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa26795;
          16 Apr 92 16:22 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa26791;
          16 Apr 92 16:22 EDT
Received: from inet-gw-1.pa.dec.com by fennel.acc.com (4.1/SMI-4.1)
	id AA13772; Thu, 16 Apr 92 13:11:14 PDT
Received: by inet-gw-1.pa.dec.com; id AA09879; Thu, 16 Apr 92 13:11:03 -0700
Received: by adaptive (/\==/\ Smail3.1.22.1 #22.4)id <m0lbcmX-0000LrC@adaptive>; Thu, 16 Apr 92 13:10 PDT
Message-Id: <m0lbcmX-0000LrC@adaptive>
Date: Thu, 16 Apr 92 13:10 PDT
From: Jim Frimmel <jim@adaptive.com>
To: trunk-mib@acc.com
Subject: Re: 24 hour accumulations

> > are 24 hour totals important?  relevant?  of any value?  well that's
> > another question.  i don't have an answer.  they seem to be supported
> > in alot of csus, so somebody must think they're important...  :^)

> i dont know either; it may be one of those historic cases of "it has always
> been there"...

Like many other things created in Bell System, there is an evolutionary
explanation to this. The main influences are:

     1. To limit the bandwidth required to gather statistics
     2. To allow statistics to accumulated and be read after outages
     3. To allow the 24-hour period to synchronize by external poll,
        possibly from another time zone.

The biggest single reason to support this standard way of collecting
PM data is so that you have something meaningful to discuss with 
carriers, since they more or less adhere to this scheme internally.

    -jf-










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa04000;
          16 Apr 92 16:22 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa26954;
          16 Apr 92 16:25 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa26948;
          16 Apr 92 16:25 EDT
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA13848; Thu, 16 Apr 92 13:13:31 PDT
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA21600; Thu, 16 Apr 92 16:07:54 EDT
Return-Path: <tacox@ginsu4@sabre.bellcore.com>
Received: from localhost by ginsu4 (4.1/4.7)
	id AA04283; Thu, 16 Apr 92 16:09:56 EDT
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9204162009.AA04283@ginsu4>
To: Fred Baker <fbaker@acc.com>
Cc: kaj@nvuxr.cc.bellcore.com, trunk-mib@acc.com
Subject: Re: 24 hour accumulation 
In-Reply-To: Your message of "Thu, 16 Apr 92 11:40:43 PDT."
             <9204161840.AA00606@saffron.acc.com> 
Date: Thu, 16 Apr 92 16:09:54 -0400
From: tacox@ginsu4.bellcore.com



Okay -- I am deprecating the old ds3TotalTable -- creating
a new one called ds3IntTotalTable for DS3 Integer Total Table.

I am sliding the OIDs by one

ds3IntTotalTable = 5
ds3FarEndConfigTable = 6 and so on.

Should I rename ds3FarEndTotalTable to ds3FarEndIntTotalTable?

Tracy










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa04171;
          16 Apr 92 16:56 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa29080;
          16 Apr 92 17:00 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa29074;
          16 Apr 92 17:00 EDT
Received: from saffron.acc.com by fennel.acc.com (4.1/SMI-4.1)
	id AA14017; Thu, 16 Apr 92 13:51:37 PDT
Received: by saffron.acc.com (4.1/SMI-4.1)
	id AA00650; Thu, 16 Apr 92 13:50:57 PDT
Date: Thu, 16 Apr 92 13:50:57 PDT
From: Fred Baker <fbaker@acc.com>
Message-Id: <9204162050.AA00650@saffron.acc.com>
To: jim@adaptive.com
Subject: Re:  24 hour counters
Cc: trunk-mib@acc.com

>> Is there a "atomic read and clear" concept in SNMP? 

Clearing counters is verboten in SNMP

Fred










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa05882;
          20 Apr 92 15:28 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa08101;
          20 Apr 92 15:32 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa08085;
          20 Apr 92 15:32 EDT
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA07713; Mon, 20 Apr 92 12:13:12 PDT
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA09056; Mon, 20 Apr 92 15:06:54 EDT
Return-Path: <tacox@sabre.bellcore.com>
Received: by ginsu4 (4.1/4.7)
	id AA04624; Mon, 20 Apr 92 15:09:09 EDT
Date: Mon, 20 Apr 92 15:09:09 EDT
From: Tracy Cox <tacox@sabre.bellcore.com>
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9204201909.AA04624@ginsu4>
To: trunk-mib@acc.com
Subject: new mib with TotalTable changes

Gang,

Please review and provide me with your comments.

Tracy





          Internet Draft           DS3 Objects                April 1992


                          Definitions of Managed Objects
                            for the DS3 Interface Type

                                    April 1992


                             Trunk MIB Working Group

                              Tracy A. Cox (editor)
                               Kaj Tesink (editor)
                           Bell Communications Research
                             331 Newman Springs Road
                               Red Bank, NJ  07701

                             tacox@sabre.bellcore.com
                            kaj@nvuxr.cc.bellcore.com




          1.  Status of this Memo

          This draft document will be submitted to the RFC editor as an
          experimental extension to the SNMP MIB.  Distribution of this
          memo is unlimited.  Please send comments to the editors.

          2.  Abstract

          This memo defines an experimental 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 DS3 objects.  This document is a
          companion document with Experimental Definitions of Managed
          Objects for the DS1 Interface Type.

          This memo does not specify a standard for the Internet
          community.













          T. A. Cox and K. Tesink (editors)                     [Page 1]





          Internet Draft           DS3 Objects                April 1992


          3.  The Network Management Framework

          The Internet-standard Network Management Framework consists of three
          components.  They are:

                RFC 1155 which defines the SMI, the mechanisms used for describing
                and naming objects for the purpose of management.  RFC 1212
                defines a more concise description mechanism, which is wholly
                consistent with the SMI.

                RFC 1156 which defines MIB-I, the core set of managed objects for
                the Internet suite of protocols.  RFC 1213, defines MIB-II, an
                evolution of MIB-I based on implementation experience and new
                operational requirements.

                RFC 1157 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.






























          T. A. Cox and K. Tesink (editors)                     [Page 2]





          Internet Draft           DS3 Objects                April 1992


          4.  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) [7] 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 [3]
          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 [8], subject to the additional requirements
          imposed by the SNMP.

          4.1.  Format of Definitions

          Section 6 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 RFC1212 [13].

          4.2.  Changes from RFC1233

          The changes from RFC1233 are the following:

          --  This MIB module contains two groups:
               DS3 Near End Group which is mandatory and
               DS3 Far End Group which is optional.

          --  The Far End Group is a new group and contains
              configuration information and statistics





          T. A. Cox and K. Tesink (editors)                     [Page 3]





          Internet Draft           DS3 Objects                April 1992


              that are collected from the far end DS3 interface.

          --  ds3CSUIndex has been renamed ds3LineIndex.  This object
              is the identifier of a DS3 Interface on a device.

          --  ds3Index has been renamed ds3IfIndex.  This value for this
              object is equal to the value of ifIndex from the Interfaces
              table of MIB II (RFC 1213).

          --  ds3Loopback has been deprecated.

          --  A new object has been added called ds3LoopbackConfig,
              which better describes the loopback capabilities of
              a DS3 interface on a device.

          --  ds3YellowAlarm has been deprecated.

          --  ds3RedAlarm has been deprecated.

          --  A new object has been added called ds3LineStatus.
              This object better describes the status (e.g.,
              alarm state and loopback state) of a
              DS3 interface.

          --  ds3IntervalCSSs, ds3CurrentCSSs, and ds3TotalCSSs have
              been deprecated.

          --  The ds3TotalTable has been deprecated and replaced with
              another ds3IntTotalTable, whose objects have a SYNTAX of
              INTEGER.




















          T. A. Cox and K. Tesink (editors)                     [Page 4]





          Internet Draft           DS3 Objects                April 1992


          5.  Overview

          These objects are used when the particular media being used to
          realize an interface is a DS3 interface.  At present, this
          applies to these values of the ifType variable in the
          Internet-standard MIB:

               ds3 (30)

          The definitions contained herein are based on the DS3
          specifications in ANSI T1.102-1987, ANSI T1.107-1988, ANSI
          T1.107a-1990, and ANSI T1.404-1989 [9,10,10a,11].

          5.1.  Binding between ifIndex and DS3 Interfaces

          Each agent which resides on a host which uses DS3 interfaces
          is required to assign a small, non-negative integer uniquely
          to each DS3 Interface.  This is known as the "LineIndex", and
          is used to distinguish between different DS3 interfaces
          attached to a node.  The LineIndex is also used as the `key'
          when accessing tabular information about DS3 interfaces.

          The ds3IfIndex column of the DS3 Configuration table relates
          each DS3 interface to its corresponding interface (ifIndex) in
          the Internet-standard MIB.

          5.2.  Objectives of this MIB Module

          There are numerous things that could be included in a MIB for
          DS3 signals: the management of multiplexors, CSUs, DSUs, and
          the like.  The intent of this document is to facilitate the
          common management of all devices with DS3 interfaces, both
          in-chassis and external via proxy.  As such, a design decision
          was made up front to very closely align the MIB with the set
          of objects that can generally be read from DS3 devices that
          are currently deployed.

          5.3.  DS3 Terminology

          The terminology used in this document to describe error
          conditions on a DS3 interface as monitored by a DS3 device are
          from the ANSI T1M1.3/92-005 draft standard [12].  If the
          definition in this document does not match the definition in
          the ANSI T1M1.3/92-005 draft document, the implementer should
          follow the definition described in this document.





          T. A. Cox and K. Tesink (editors)                     [Page 5]





          Internet Draft           DS3 Objects                April 1992


                    Bipolar Violation (BPV)
                         A bipolar violation, for B3ZS-coded signals, is the
                         occurrence of a pulse of the same polarity as the previous
                         pulse without being part of the zero substitution code,
                         B3ZS.  For B3ZS-coded
                         signals, a bipolar violation may also include other error
                         patterns such as:  three or more consecutive zeros and
                         incorrect polarity.

                    Coding Violation (CV)
                         For all DS3 applications, a coding violation is a P-bit
                         Parity Error event.  A P-bit Parity Error event is the
                         occurrence of a received P-bit code on the DS3 M-frame
                         that is not identical to the corresponding locally-
                         calculated code.

                    Errored Seconds (ES)
                         An ES is a second with one or more Coding Violation OR
                         one or more Out of Frame events OR a detected incoming AIS.

                    Severely Errored Seconds (SES)
                         A SES is a second with 44 or more Coding Violations OR
                         one or more Out of Frame events OR a detected incoming AIS.

                    Severely Errored Framing Seconds (SEFS)
                         A SEFS is a second with one or more Out of Frame events
                         OR a detected incoming AIS.

                    Unavailable Seconds (UAS)
                         UAS are calculated by counting the number of seconds that
                         the interface is unavailable.  The DS3 interface is said
                         to be unavailable from the onset of 10 contiguous SESs, or
                         the onset of the condition leading to a failure (see Alarm
                         States).  If the condition leading to the failure was
                         immediately preceded by one or more contiguous SESs, then
                         the DS3 interface unavailability starts from the onset of these
                         SESs.  Once unavailable, and if no failure is present, the DS3
                         interface becomes available at the onset of 10 contiguous seconds
                         with no SESs.  Once unavailable, and if a failure is present,
                         the DS3 interface becomes available at the onset of 10 contiguous
                         seconds with no SESs, if the failure clearing time is less than
                         or equal to 10 seconds.  If the failure clearing time is more than
                         10 seconds, the DS3 interface becomes available at the onset of 10
                         contiguous seconds with no SESs, or the onset period leading to the
                         successful clearing condition, whichever occurs later.





          T. A. Cox and K. Tesink (editors)                     [Page 6]





          Internet Draft           DS3 Objects                April 1992


                         With respect to the DS3 error counts, all counters are incremented
                         while the DS3 interface is deemed available.  While the interface is
                         deemed unavailable, the only count that is incremented is UASs.

                         A special case exists when the 10 or more second period
                         crosses the 900 second statistics window boundary, as the
                         foregoing description implies that the SES and UAS
                         counters must be adjusted when the Unavailable Signal
                         State is entered. Clearly, successive GETs of the
                         affected ds3IntervalSES and ds3IntervalUAS objects will
                         return differing values if the first GET occurs during
                         the first few seconds of the window.  This is viewed as
                         an unavoidable side-effect of selecting the presently
                         defined managed objects as a basis for this memo.

                    Alarm States:
                         The Far End Alarm (or Yellow Alarm) is declared after detecting
                         the Yellow Signal.  See ANSI T1.107a-1990 [10].

                         The incoming alarm states consist of the following
                         incoming signal degradations:  Loss of
                         Signal (LOS), a Loss of Frame (LOF)  (a persistent Out
                         of Frame event), or an
                         Alarm Indication Signal (AIS), for at least 2-10
                         seconds.  The Alarm States are cleared at the onset of 10
                         consecutive seconds with no SESs.
                         The Alarm State object identifies only the highest priority
                         alarm.  The priorities of the alarm states from highest to lowest
                         are LOS, LOF, AIS, and Far End Alarm.

                    Out of Frame (OOF) event
                         An OOF event is detected when any three or more errors in
                         sixteen or fewer consecutive F-bits occur within a DS3
                         M-frame.  An OOF event is cleared when reframe occurs.
                         A Loss of Frame (LOF) event is declared when the OOF event
                         is consistent for 2 to 10 seconds.  The OOF event ends when
                         reframe occurs.  The LOF event is cleared when the OOF defect
                         is absent for 10 to 20 seconds.

                    Loss of Signal (LOS)
                         This failure is declared upon observing 175 +/- 75
                         contiguous pulse positions with no pulses of either
                         positive or negative polarity.
                         The LOS is terminated upon observing an average pulse density
                         of at least 33% over a period of 175 +/- 75 contiguous pulse





          T. A. Cox and K. Tesink (editors)                     [Page 7]





          Internet Draft           DS3 Objects                April 1992


                         positions starting with the receipt of a pulse.

                    Alarm Indication Signal (AIS)
                         The AIS is framed with "stuck stuffing."  This implies
                         that it has a valid M-subframe alignments bits, M-frame
                         alignment bits, and P bits.  The information bits are set
                         to a 1010... sequence, starting with a one (1) after each
                         M-subframe alignment bit, M-frame alignment bit, X bit, P bit,
                         and C bit.  The C bits are all set to zero giving what is called
                         "stuck stuffing."  The X bits are set to one.
                         The AIS is declared after AIS is present in contiguous M-frames
                         for a time equal to or greater than T, where
                         0.2 ms <= T <= 100 ms.
                         The AIS is terminated after AIS is absent in contiguous M-frames
                         for a time equal to or greater than T.

                    Circuit Identifier
                         This is a character string specified by the circuit
                         vendor, and is useful when communicating with the vendor
                         during the troubleshooting process.






























          T. A. Cox and K. Tesink (editors)                     [Page 8]





          Internet Draft           DS3 Objects                April 1992


          6.  Object Definitions

               RFCxxxx-MIB DEFINITIONS ::= BEGIN

               IMPORTS
                       mgmt, experimental, Counter
                               FROM RFC1155-SMI
                       DisplayString
                               FROM RFC1158-MIB
                       OBJECT-TYPE
                               FROM RFC-1212;

               --  This MIB module uses the extended OBJECT-TYPE macro as
               --  defined in RFC 1212.

               --  this is the MIB module for the DS3 objects

                              mib-2 OBJECT IDENTIFIER ::= { mgmt 1 }
                              transmission OBJECT IDENTIFIER ::= { mib-2 10 }
                              ds3 OBJECT IDENTIFIER ::= { transmission 30 }






























          T. A. Cox and K. Tesink (editors)                     [Page 9]





          Internet Draft           DS3 Objects                April 1992


               -- The DS3 Near End Group

               -- Implementation of this group is mandatory for all systems
               -- that attach to a DS3 Interface.

               -- The DS3 Near End Group consists of four groups:
               --    DS3 Configuration Group
               --    DS3 Interval Group
               --    DS3 Current Group
               --    DS3 Integer Total Group

               -- the DS3 Configuration group

               -- Although the objects in this group are read-only, at the
               -- agent's discretion they may be made read-write so that the
               -- management station, when appropriately authorized, may
               -- change the behavior of the interface, e.g., to place the interface
               -- into a loopback state.

               ds3ConfigTable OBJECT-TYPE
                   SYNTAX  SEQUENCE OF DS3ConfigEntry
                   ACCESS  not-accessible
                   STATUS  mandatory
                   DESCRIPTION
                           "The DS3 Configuration table."
                  ::= { ds3 1 }

              ds3ConfigEntry OBJECT-TYPE
                  SYNTAX  DS3ConfigEntry
                  ACCESS  not-accessible
                  STATUS  mandatory
                  DESCRIPTION
                          "An entry in the DS3 Configuration table."
                 INDEX   { ds3LineIndex }
                 ::= { ds3ConfigTable 1 }

             DS3ConfigEntry ::=
                 SEQUENCE {
                     ds3LineIndex
                         INTEGER,
                     ds3IfIndex
                         INTEGER,
                     ds3TimeElapsed
                         INTEGER,
                     ds3ValidIntervals





          T. A. Cox and K. Tesink (editors)                    [Page 10]





          Internet Draft           DS3 Objects                April 1992


                         INTEGER,
                     ds3LineType
                         INTEGER,
                     ds3ZeroCoding
                         INTEGER,
                     ds3Loopback
                         INTEGER,
                     ds3SendCode
                         INTEGER,
                     ds3YellowAlarm
                         INTEGER,
                     ds3RedAlarm
                         INTEGER,
                     ds3CircuitIdentifier
                         DisplayString,
                     ds3LoopbackConfig
                         INTEGER,
                     ds3LineStatus
                         INTEGER
             }

             ds3LineIndex OBJECT-TYPE
                 SYNTAX  INTEGER (1..65535)
                 ACCESS  read-only
                 STATUS  mandatory
                 DESCRIPTION
                         "This object is the identifier of a DS3
                         Interface on a device.  If there is at least
                         one ifEntry directly associated with the DS3
                         interface (e.g., if the DS3 interface is used
                         to communicate with the Network Layer), it
                         should have the same value as ifIndex.
                         Otherwise, its value should exceed ifNumber."
                ::= { ds3ConfigEntry 1 }

            ds3IfIndex OBJECT-TYPE
                SYNTAX  INTEGER (1..65535)
                ACCESS  read-only
                STATUS  mandatory
                DESCRIPTION
                        "This value for this object is equal to the
                        value of ifIndex from the Interfaces table of
                        MIB II (RFC 1213)."
               ::= { ds3ConfigEntry 2 }






          T. A. Cox and K. Tesink (editors)                    [Page 11]





          Internet Draft           DS3 Objects                April 1992


           ds3TimeElapsed OBJECT-TYPE
               SYNTAX  INTEGER (1..900)
               ACCESS  read-only
               STATUS  mandatory
               DESCRIPTION
                       "The number of seconds, including partial
                       seconds, that have elapsed since the beginning of
                       the current error-measurement period."
              ::= { ds3ConfigEntry 3 }

          ds3ValidIntervals OBJECT-TYPE
              SYNTAX  INTEGER (0..96)
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The number of previous intervals for which valid
                      data was collected.  The value will be 96 unless
                      the interface was brought online within the last
                      24 hours, in which case the value will be the
                      number of complete 15 minute intervals the
                      interface has been online."
              ::= { ds3ConfigEntry 4 }

          ds3LineType OBJECT-TYPE
              SYNTAX  INTEGER {
                          other(1),
                          ds3M23(2),
                          ds3SYNTRAN(3),
                          ds3CbitParity(4),
                          ds3ClearChannel(5)
                      }
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "This variable indicates the variety of DS3 C-bit
                      application implementing this interface.  The type
                      of interface affects the interpretation of the
                      usage and error statistics.  The rate of all of
                      them is 44.736 Mbps.

                      The values, in sequence, describe:
                      TITLE:            SPECIFICATION:
                      ds3M23            ANSI T1.107-1988 [10]
                      ds3SYNTRAN        ANSI T1.107-1988 [10]
                      ds3C-bit Parity   ANSI T1.107a-1989 [10a]





          T. A. Cox and K. Tesink (editors)                    [Page 12]





          Internet Draft           DS3 Objects                April 1992


                      ds3Clear Channel  ANSI T1.102-1987 [9]
                      "
              ::= { ds3ConfigEntry 5 }

          ds3ZeroCoding OBJECT-TYPE
              SYNTAX  INTEGER {
                          ds3other(1),
                          ds3B3ZS(2)
                      }
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "This variable describes the variety of Zero Code
                      Suppression used on this interface, which in turn
                      affects a number of its characteristics.

                      DS3B3ZS refer to the use of specified patterns of
                      normal bits and bipolar violations which are used
                      to replace sequences of zero bits of a specified
                      length."
              ::= { ds3ConfigEntry 6 }

              ds3Loopback OBJECT-TYPE
                        SYNTAX  INTEGER {
                                    ds3NoLoop(1),
                                    ds3LocalLoopbackLocalSide(2),
                                    ds3LocalLoopbackRemoteSide(3),
                                    ds3RemoteLoopbackLocalSide(4),
                                    ds3RemoteLoopbackRemoteSide(5)
                                }
                        ACCESS  read-only
                        STATUS  deprecated
                        DESCRIPTION
                                "This variable represents the loopback state of
                                the device.  Agents supporting read/write access
                                should return badValue in response to a requested
                                loopback state that the device does not support.  The
                                values mean:

                                  ds3NoLoop
                                     Not in the loopback state.  A device that is
                                     not capable of performing a loopback on
                                     either interface shall always return this as
                                     it's value.






          T. A. Cox and K. Tesink (editors)                    [Page 13]





          Internet Draft           DS3 Objects                April 1992


                                  ds3LocalLoopbackLocalSide
                                     Signal received from the local side of the
                                     device is looped back at the local connector
                                     (eg, without involving the device).

                                  ds3LocalLoopbackRemoteSide
                                     Signal received from the local side of the
                                     device is looped back at the remote connector
                                     (eg, through the device).

                                  ds3RemoteLoopbackLocalSide
                                     Signal received from the remote side of the
                                     device is looped back at the local connector
                                     (eg, through the device).

                                  ds3RemoteLoopbackRemoteSide
                                     Signal received from the remote side of the
                                     device is looped back at the remote connector
                                     (eg, without involving the device).

                                Note that M23 and ClearChannel interfaces do not
                                support the Loopback managed object."
                        ::= { ds3ConfigEntry 7 }

                ds3SendCode OBJECT-TYPE
                        SYNTAX  INTEGER {
                                    ds3SendTestMessage(1),
                                    ds3SendNoCode(2),
                                    ds3SendSetCode(3),
                                    ds3SendLoopbackCode(4),
                                    ds3SendResetCode(5)
                                }
                        ACCESS  read-only
                        STATUS  mandatory
                        DESCRIPTION
                                "This variable indicates what type of code is
                                being sent across the DS3 interface by the device.  The
                                values mean:

                                  ds3SendNoCode
                                     sending looped or normal data

                                  ds3SendSetCode
                                     sending a loopback request






          T. A. Cox and K. Tesink (editors)                    [Page 14]





          Internet Draft           DS3 Objects                April 1992


                                  ds3SendLoopbackCode
                                     sending a loopback test code/pattern

                                  ds3SendResetCode
                                     sending a loopback termination request

                                  ds3SendTestMessage
                                     sending a Test pattern as defined in
                                     T1.107a-1990."
                        ::= { ds3ConfigEntry 8 }

          ds3YellowAlarm OBJECT-TYPE
              SYNTAX  INTEGER {
                          ds3YellowAlarm(1),
                          ds3NoYellowAlarm(2)
                      }
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "This variable indicates if a Yellow Alarm
                      condition exists."
              ::= { ds3ConfigEntry 9 }

          ds3RedAlarm OBJECT-TYPE
              SYNTAX  INTEGER {
                          ds3RedAlarm(1),
                          ds3NoRedAlarm(2)
                      }
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "This variable indicates if a Red Alarm condition
                      exists."
              ::= { ds3ConfigEntry 10 }

          ds3CircuitIdentifier OBJECT-TYPE
              SYNTAX  DisplayString (SIZE (0..255))
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "This variable contains the transmission vendor's
                      circuit identifier, for the purpose of
                      facilitating troubleshooting."
              ::= { ds3ConfigEntry 11 }






          T. A. Cox and K. Tesink (editors)                    [Page 15]





          Internet Draft           DS3 Objects                April 1992


                      ds3LoopbackConfig OBJECT-TYPE
                                SYNTAX  INTEGER {
                                            ds3NoLoop(1),
                                            ds3MgrPayloadLoop(2),
                                            ds3MgrLineLoop(3),
                                            ds3NetReqPayloadLoop(4),
                                            ds3NetReqLineLoop(5),
                                            ds3OtherLoop(6)
                                        }
                                ACCESS  read-only
                                STATUS  mandatory
                                DESCRIPTION
                                        "This variable represents the loopback configuration of
                                        the DS3 interface.  Agents supporting read/write
                                        access should return badValue in response to a
                                        requested loopback state that the interface does not support.
                                        The values mean:

                                              ds3NoLoop

                                                Not in the loopback state.  A device that is
                                                not capable of performing a loopback on
                                                the interface shall always return this as
                                                it's value.


                                              ds3MgrPayloadLoop

                                                The received signal at this interface is looped through
                                                the device; this loopback is initiated by a
                                                manager of the device. Typically the received signal
                                                is looped back for retransmission after it has
                                                passed through the device's framing function.

                                              ds3MgrLineLoop

                                                The received signal at this interface does not
                                                go through the device (minimum penetration) but
                                                is looped back out; this loopback is initiated
                                                by a manager of the device.

                                              ds3NetReqPayloadLoop

                                                The received signal at this interface is looped through
                                                the device; this loopback is initiated/requested by the





          T. A. Cox and K. Tesink (editors)                    [Page 16]





          Internet Draft           DS3 Objects                April 1992


                                                far end equipment. Typically the received signal
                                                is looped back for retransmission after it has
                                                passed through the device's framing function.

                                              ds3NetReqLineLoop

                                                The received signal at this interface does not
                                                go through the device (minimum penetration) but
                                                is looped back out; this loopback is initiated/requested
                                                by the far end equipment.

                                              ds3OtherLoop

                                                Loopbacks that are not defined here.

                                        Note that M23 and ClearChannel interfaces do not
                                        support the Loopback managed object."
                                ::= { ds3ConfigEntry 12 }

                    ds3LineStatus OBJECT-TYPE
                        SYNTAX  INTEGER {
                                    ds3NoAlarm(1),
                                    ds3FarEndAlarm(2),
                                    ds3AlarmIndicationSignal(3),
                                    ds3LossOfFrame(4),
                                    ds3LossOfSignal(5),
                                    ds3LoopbackState(6)
                                }
                        ACCESS  read-only
                        STATUS  mandatory
                        DESCRIPTION
                              "This variable indicates the
                              Line Status of the interface.
                              It contains loopback state information
                              and alarm state information.
                              If multiple alarm states are occurring
                              simultaneously, then the highest
                              priority alarm state is the one set.  From
                              highest to lowest the alarm state priorities are
                              the following:  ds3LossOfSignal, ds3LossOfFrame,
                              ds3AlarmIndicationSignal, and ds3FarEndAlarm."
                        ::= { ds3ConfigEntry 13 }








          T. A. Cox and K. Tesink (editors)                    [Page 17]





          Internet Draft           DS3 Objects                April 1992


          -- the DS3 Interval group

          -- The DS3 Interval Table contains various statistics
          -- collected by each DS3 Interface over the previous 24 hours of
          -- operation.  The past 24 hours are broken into 96 completed
          -- 15 minute intervals.

          ds3IntervalTable OBJECT-TYPE
              SYNTAX  SEQUENCE OF DS3IntervalEntry
              ACCESS  not-accessible
              STATUS  mandatory
              DESCRIPTION
                      "The DS3 Interval table."
              ::= { ds3 2 }

          ds3IntervalEntry OBJECT-TYPE
              SYNTAX  DS3IntervalEntry
              ACCESS  not-accessible
              STATUS  mandatory
              DESCRIPTION
                      "An entry in the DS3 Interval table."
              INDEX   { ds3IntervalIndex, ds3IntervalNumber }
              ::= { ds3IntervalTable 1 }

          DS3IntervalEntry ::=
              SEQUENCE {
                  ds3IntervalIndex
                      INTEGER,
                  ds3IntervalNumber
                      INTEGER,
                  ds3IntervalESs
                      Counter,
                  ds3IntervalSESs
                      Counter,
                  ds3IntervalSEFSs
                      Counter,
                  ds3IntervalUASs
                      Counter,
                  ds3IntervalCSSs
                      Counter,
                  ds3IntervalBPVs
                      Counter,
                  ds3IntervalCVs
                      Counter
              }





          T. A. Cox and K. Tesink (editors)                    [Page 18]





          Internet Draft           DS3 Objects                April 1992


          ds3IntervalIndex OBJECT-TYPE
              SYNTAX  INTEGER (1..65535)
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The index value which uniquely identifies the DS3
                      interface to which this entry is applicable.  The
                      interface identified by a particular value of this
                      index is the same interface as identified by the
                      same value an DS3LineIndex object instance."
              ::= { ds3IntervalEntry 1 }

          ds3IntervalNumber OBJECT-TYPE
              SYNTAX  INTEGER (0..96)
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "A number between 1 and 96, where 1 is the most
                      recently completed 15 minute interval and 96 is
                      the least recently completed 15 minutes interval
                      (assuming that all 96 intervals are valid)."
              ::= { ds3IntervalEntry 2 }

          ds3IntervalESs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Errored
                      Seconds, encountered by a DS3 interface in one of
                      the previous 96, individual 15 minute, intervals."
              ::= { ds3IntervalEntry 3 }

          ds3IntervalSESs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of
                      Severely Errored Seconds, encountered by a DS3
                      interface in one of the previous 96, individual 15
                      minute, intervals."
              ::= { ds3IntervalEntry 4 }

          ds3IntervalSEFSs OBJECT-TYPE





          T. A. Cox and K. Tesink (editors)                    [Page 19]





          Internet Draft           DS3 Objects                April 1992


              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of
                      Severely Errored Framing Seconds, encountered by a
                      DS3 interface in one of the previous 96,
                      individual 15 minute, intervals."
              ::= { ds3IntervalEntry 5 }

          ds3IntervalUASs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of
                      Unavailable Seconds, encountered by a DS3
                      interface in one of the previous 96, individual 15
                      minute, intervals."
              ::= { ds3IntervalEntry 6 }

          ds3IntervalCSSs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "The counter associated with the number of
                      Controlled Slip Seconds, encountered by a DS3
                      interface in one of the previous 96, individual 15
                      minute, intervals.  Note that SYNTRAN interfaces
                      are the only interfaces that support the
                      Controlled Slip Seconds managed object.
                      Accordingly, agents configured with non-SYNTRAN
                      interfaces may treat this object as having an
                      ACCESS clause value of not-accessible."
              ::= { ds3IntervalEntry 7 }

          ds3IntervalBPVs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Bipolar
                      Violations, encountered by a DS3 interface in one
                      of the previous 96, individual 15 minute,





          T. A. Cox and K. Tesink (editors)                    [Page 20]





          Internet Draft           DS3 Objects                April 1992


                      intervals."
              ::= { ds3IntervalEntry 8 }

          ds3IntervalCVs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Coding
                      Violations, encountered by a DS3 interface in one
                      of the previous 96, individual 15 minute,
                      intervals."
              ::= { ds3IntervalEntry 9 }





































          T. A. Cox and K. Tesink (editors)                    [Page 21]





          Internet Draft           DS3 Objects                April 1992


          -- the DS3 Current group

          -- The DS3 current table contains various statistics being
          -- collected for the current 15 minute interval.

          ds3CurrentTable OBJECT-TYPE
              SYNTAX  SEQUENCE OF DS3CurrentEntry
              ACCESS  not-accessible
              STATUS  mandatory
              DESCRIPTION
                      "The DS3 Current table."
              ::= { ds3 3 }

          ds3CurrentEntry OBJECT-TYPE
              SYNTAX  DS3CurrentEntry
              ACCESS  not-accessible
              STATUS  mandatory
              DESCRIPTION
                      "An entry in the DS3 Current table."
              INDEX   { ds3CurrentIndex }
              ::= { ds3CurrentTable 1 }

          DS3CurrentEntry ::=
              SEQUENCE {
                  ds3CurrentIndex
                      INTEGER,
                  ds3CurrentESs
                      Counter,
                  ds3CurrentSESs
                      Counter,
                  ds3CurrentSEFSs
                      Counter,
                  ds3CurrentUASs
                      Counter,
                  ds3CurrentCSSs
                      Counter,
                  ds3CurrentBPVs
                      Counter,
                  ds3CurrentCVs
                      Counter
              }

          ds3CurrentIndex OBJECT-TYPE
              SYNTAX  INTEGER (1..65535)
              ACCESS  read-only





          T. A. Cox and K. Tesink (editors)                    [Page 22]





          Internet Draft           DS3 Objects                April 1992


              STATUS  mandatory
              DESCRIPTION
                      "The index value which uniquely identifies the DS3
                      interface to which this entry is applicable.  The
                      interface identified by a particular value of this
                      index is the same interface as identified by the
                      same value an DS3LineIndex object instance."
              ::= { ds3CurrentEntry 1 }

          ds3CurrentESs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Errored
                      Seconds, encountered by a DS3 interface in the
                      current 15 minute interval."
              ::= { ds3CurrentEntry 2 }

          ds3CurrentSESs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of
                      Severely Errored Seconds, encountered by a DS3
                      interface in the current 15 minute interval."
              ::= { ds3CurrentEntry 3 }

          ds3CurrentSEFSs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of
                      Severely Errored Framing Seconds, encountered by a
                      DS3 interface in the current 15 minute interval."
              ::= { ds3CurrentEntry 4 }

          ds3CurrentUASs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of





          T. A. Cox and K. Tesink (editors)                    [Page 23]





          Internet Draft           DS3 Objects                April 1992


                      Unavailable Seconds, encountered by a DS3
                      interface in the current 15 minute interval."
              ::= { ds3CurrentEntry 5 }

          ds3CurrentCSSs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "The counter associated with the number of
                      Controlled Slip Seconds, encountered by a DS3
                      interface in the current 15 minute interval.  Note
                      that SYNTRAN interfaces are the only interfaces
                      that support the Controlled Slip Seconds managed
                      object.  Accordingly, agents configured with non-
                      SYNTRAN interfaces may treat this object as having
                      an ACCESS clause value of not-accessible."
              ::= { ds3CurrentEntry 6 }

          ds3CurrentBPVs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Bipolar
                      Violations, encountered by a DS3 interface in the
                      current 15 minute interval."
              ::= { ds3CurrentEntry 7 }

          ds3CurrentCVs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Coding
                      Violations, encountered by a DS3 interface in the
                      current 15 minute interval."
              ::= { ds3CurrentEntry 8 }












          T. A. Cox and K. Tesink (editors)                    [Page 24]





          Internet Draft           DS3 Objects                April 1992


          -- the DS3 Total group

          -- The DS3 Total Table contains the cumulative sum of the
          -- various statistics for the 24 hour interval preceding the
          -- first valid interval in the DS3CurrentTable.

          ds3TotalTable OBJECT-TYPE
              SYNTAX  SEQUENCE OF DS3TotalEntry
              ACCESS  not-accessible
              STATUS  deprecated
              DESCRIPTION
                      "The DS3 Total table.  24 hour interval."
              ::= { ds3 4 }

          ds3TotalEntry OBJECT-TYPE
              SYNTAX  DS3TotalEntry
              ACCESS  not-accessible
              STATUS  deprecated
              DESCRIPTION
                      "An entry in the DS3 Total table."
              INDEX   { ds3TotalIndex }
              ::= { ds3TotalTable 1 }

          DS3TotalEntry ::=
              SEQUENCE {
                  ds3TotalIndex
                      INTEGER,
                  ds3TotalESs
                      Counter,
                  ds3TotalSESs
                      Counter,
                  ds3TotalSEFSs
                      Counter,
                  ds3TotalUASs
                      Counter,
                  ds3TotalCSSs
                      Counter,
                  ds3TotalBPVs
                      Counter,
                  ds3TotalCVs
                      Counter
              }

          ds3TotalIndex OBJECT-TYPE
              SYNTAX  INTEGER (1..65535)





          T. A. Cox and K. Tesink (editors)                    [Page 25]





          Internet Draft           DS3 Objects                April 1992


              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "The index value which uniquely identifies the DS3
                      interface to which this entry is applicable.  The
                      interface identified by a particular value of this
                      index is the same interface as identified by the
                      same value an DS3LineIndex object instance."
              ::= { ds3TotalEntry 1 }

          ds3TotalESs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "The counter associated with the number of Errored
                      Seconds, encountered by a DS3 interface in the
                      previous 24 hour interval"
              ::= { ds3TotalEntry 2 }

          ds3TotalSESs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "The counter associated with the number of
                      Severely Errored Seconds, encountered by a DS3
                      interface in the previous 24 hour interval."
              ::= { ds3TotalEntry 3 }

          ds3TotalSEFSs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "The counter associated with the number of
                      Severely Errored Framing Seconds, encountered by a
                      DS3 interface in the previous 24 hour interval."
              ::= { ds3TotalEntry 4 }

          ds3TotalUASs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION





          T. A. Cox and K. Tesink (editors)                    [Page 26]





          Internet Draft           DS3 Objects                April 1992


                      "The counter associated with the number of
                      Unavailable Seconds, encountered by a DS3
                      interface in the previous 24 hour interval."
              ::= { ds3TotalEntry 5 }

          ds3TotalCSSs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "The counter associated with the number of
                      Controlled Slip Seconds, encountered by a DS3
                      interface in the previous 24 hour interval.  Note
                      that SYNTRAN interfaces are the only interfaces
                      that support the Controlled Slip Seconds managed
                      object.  Accordingly, agents configured with non-
                      SYNTRAN interfaces may treat this object as having
                      an ACCESS clause value of not-accessible."
              ::= { ds3TotalEntry 6 }

          ds3TotalBPVs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "The counter associated with the number of Bipolar
                      Violations, encountered by a DS3 interface in the
                      previous 24 hour interval."
              ::= { ds3TotalEntry 7 }

          ds3TotalCVs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "The counter associated with the number of Coding
                      Violations, encountered by a DS3 interface in the
                      previous 24 hour interval."
              ::= { ds3TotalEntry 8 }











          T. A. Cox and K. Tesink (editors)                    [Page 27]





          Internet Draft           DS3 Objects                April 1992


          -- the DS3 Integer Total group

          -- The DS3 Integer Total Table contains the cumulative sum of the
          -- various statistics for the 24 hour interval preceding the
          -- first valid interval in the DS3CurrentTable.

          ds3IntTotalTable OBJECT-TYPE
              SYNTAX  SEQUENCE OF DS3IntTotalEntry
              ACCESS  not-accessible
              STATUS  mandatory
              DESCRIPTION
                      "The DS3 Integer Total table.  24 hour interval."
              ::= { ds3 5 }

          ds3IntTotalEntry OBJECT-TYPE
              SYNTAX  DS3IntTotalEntry
              ACCESS  not-accessible
              STATUS  mandatory
              DESCRIPTION
                      "An entry in the DS3 Integer Total table."
              INDEX   { ds3IntTotalIndex }
              ::= { ds3IntTotalTable 1 }

          DS3IntTotalEntry ::=
              SEQUENCE {
                  ds3IntTotalIndex
                      INTEGER,
                  ds3IntTotalESs
                      INTEGER,
                  ds3IntTotalSESs
                      INTEGER,
                  ds3IntTotalSEFSs
                      INTEGER,
                  ds3IntTotalUASs
                      INTEGER,
                  ds3IntTotalCSSs
                      INTEGER,
                  ds3IntTotalBPVs
                      INTEGER,
                  ds3IntTotalCVs
                      INTEGER
              }

          ds3IntTotalIndex OBJECT-TYPE
              SYNTAX  INTEGER (1..65535)





          T. A. Cox and K. Tesink (editors)                    [Page 28]





          Internet Draft           DS3 Objects                April 1992


              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The index value which uniquely identifies the DS3
                      interface to which this entry is applicable.  The
                      interface identified by a particular value of this
                      index is the same interface as identified by the
                      same value an DS3LineIndex object instance."
              ::= { ds3IntTotalEntry 1 }

          ds3IntTotalESs OBJECT-TYPE
              SYNTAX  INTEGER (1..4294967295)
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Errored
                      Seconds, encountered by a DS3 interface in the
                      previous 24 hour interval"
              ::= { ds3IntTotalEntry 2 }

          ds3IntTotalSESs OBJECT-TYPE
              SYNTAX  INTEGER (1..4294967295)
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of
                      Severely Errored Seconds, encountered by a DS3
                      interface in the previous 24 hour interval."
              ::= { ds3IntTotalEntry 3 }

          ds3IntTotalSEFSs OBJECT-TYPE
              SYNTAX  INTEGER (1..4294967295)
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of
                      Severely Errored Framing Seconds, encountered by a
                      DS3 interface in the previous 24 hour interval."
              ::= { ds3IntTotalEntry 4 }

          ds3IntTotalUASs OBJECT-TYPE
              SYNTAX  INTEGER (1..4294967295)
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION





          T. A. Cox and K. Tesink (editors)                    [Page 29]





          Internet Draft           DS3 Objects                April 1992


                      "The counter associated with the number of
                      Unavailable Seconds, encountered by a DS3
                      interface in the previous 24 hour interval."
              ::= { ds3IntTotalEntry 5 }

          ds3IntTotalCSSs OBJECT-TYPE
              SYNTAX  INTEGER (1..4294967295)
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of
                      Controlled Slip Seconds, encountered by a DS3
                      interface in the previous 24 hour interval.  Note
                      that SYNTRAN interfaces are the only interfaces
                      that support the Controlled Slip Seconds managed
                      object.  Accordingly, agents configured with non-
                      SYNTRAN interfaces may treat this object as having
                      an ACCESS clause value of not-accessible."
              ::= { ds3IntTotalEntry 6 }

          ds3IntTotalBPVs OBJECT-TYPE
              SYNTAX  INTEGER (1..4294967295)
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Bipolar
                      Violations, encountered by a DS3 interface in the
                      previous 24 hour interval."
              ::= { ds3IntTotalEntry 7 }

          ds3IntTotalCVs OBJECT-TYPE
              SYNTAX  INTEGER (1..4294967295)
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Coding
                      Violations, encountered by a DS3 interface in the
                      previous 24 hour interval."
              ::= { ds3IntTotalEntry 8 }











          T. A. Cox and K. Tesink (editors)                    [Page 30]





          Internet Draft           DS3 Objects                April 1992


          -- The DS3 Far End Group

          -- Implementation of this group is optional for all systems
          -- that attach to a DS3 Interface.

          -- The DS3 Far End Group consists of four groups:
          --   DS3 Far End Configuration Group
          --   DS3 Far End Interval Group
          --   DS3 Far End Current Group
          --   DS3 Far End Integer Total Group


          -- Only C-bit Parity applications
          -- can provide this information.

          -- The DS3 Far End Configuration Table contains
          -- configuration information
          -- reported in the C-bits from the remote end.

                       ds3FarEndConfigTable OBJECT-TYPE
                            SYNTAX  SEQUENCE OF DS3FarEndConfigEntry
                            ACCESS  not-accessible
                            STATUS  optional
                            DESCRIPTION
                                    "The DS3 Far End Configuration table."
                           ::= { ds3 6 }

                       ds3FarEndConfigEntry OBJECT-TYPE
                           SYNTAX  DS3FarEndConfigEntry
                           ACCESS  not-accessible
                           STATUS  optional
                           DESCRIPTION
                                   "An entry in the DS3 Far End Configuration table."
                           INDEX   { ds3FarEndLineIndex }
                           ::= { ds3FarEndConfigTable 1 }

                       DS3FarEndConfigEntry ::=
                           SEQUENCE {
                               ds3FarEndLineIndex
                                   INTEGER,
                               ds3FarEndEquipCode
                                   DisplayString,
                               ds3FarEndLocationIDCode
                                   DisplayString,
                               ds3FarEndFrameIDCode





          T. A. Cox and K. Tesink (editors)                    [Page 31]





          Internet Draft           DS3 Objects                April 1992


                                   DisplayString,
                               ds3FarEndUnitCode
                                   DisplayString,
                               ds3FarEndFacilityIDCode
                                   DisplayString
                       }

                    ds3FarEndLineIndex OBJECT-TYPE
                           SYNTAX  INTEGER (1..65535)
                           ACCESS  read-only
                           STATUS  optional
                           DESCRIPTION
                                "The index value which uniquely identifies the
                                DS3 interface
                                to which this entry is applicable.  The
                                interface identified by a particular value of
                                this index is the same interface as identified
                                by the same value an DS3LineIndex object
                                instance."
                          ::= { ds3FarEndConfigEntry 1 }

                    ds3FarEndEquipCode OBJECT-TYPE
                        SYNTAX  DisplayString (SIZE (0..10))
                        ACCESS  read-write
                        STATUS  optional
                        DESCRIPTION
                              "This is the Far End Equipment Identification code
                              that describes the specific piece of equipment.
                              This code is only used in C-bit parity applications.
                              devices should return noSuchName when this object is
                              requested in a GET-Request and the next lexicographical
                              object in a GET-NEXT-Request.
                              It is sent within the Path
                              Identification Message."
                        ::= { ds3FarEndConfigEntry 2 }

                    ds3FarEndLocationIDCode OBJECT-TYPE
                        SYNTAX  DisplayString (SIZE (0..11))
                        ACCESS  read-write
                        STATUS  optional
                        DESCRIPTION
                              "This is the Far End Location Identification code
                              that describes the specific location of the equipment.
                              This code is only used in C-bit parity applications.
                              Devices should return noSuchName when this object is





          T. A. Cox and K. Tesink (editors)                    [Page 32]





          Internet Draft           DS3 Objects                April 1992


                              requested in a GET-Request and the next lexicographical
                              object in a GET-NEXT-Request.
                              It is sent within the Path
                              Identification Message."
                        ::= { ds3FarEndConfigEntry 3 }

                    ds3FarEndFrameIDCode OBJECT-TYPE
                        SYNTAX  DisplayString (SIZE (0..10))
                        ACCESS  read-write
                        STATUS  optional
                        DESCRIPTION
                              "This is the Far End Frame Identification code
                              that identifies where the equipment is located
                              within a building at a given location.
                              This code is only used in C-bit parity applications.
                              Devices should return noSuchName when this object is
                              requested in a GET-Request and the next lexicographical
                              object in a GET-NEXT-Request.
                              It is sent within the Path
                              Identification Message."
                        ::= { ds3FarEndConfigEntry 4 }

                    ds3FarEndUnitCode OBJECT-TYPE
                        SYNTAX  DisplayString (SIZE (0..6))
                        ACCESS  read-write
                        STATUS  optional
                        DESCRIPTION
                              "This is the Far End code
                              that identifies the equipment location within a bay.
                              This code is only used in C-bit parity applications.
                              Devices should return noSuchName when this object is
                              requested in a GET-Request and the next lexicographical
                              object in a GET-NEXT-Request.
                              It is sent within the Path
                              Identification Message."
                        ::= { ds3FarEndConfigEntry 5 }

                    ds3FarEndFacilityIDCode OBJECT-TYPE
                        SYNTAX  DisplayString (SIZE (0..38))
                        ACCESS  read-write
                        STATUS  optional
                        DESCRIPTION
                              "This code identifies a specific Far End DS3 path.
                              This code is only used in C-bit parity applications.
                              Devices should return noSuchName when this object is





          T. A. Cox and K. Tesink (editors)                    [Page 33]





          Internet Draft           DS3 Objects                April 1992


                              requested in a GET-Request and the next lexicographical
                              object in a GET-NEXT-Request.
                              It is sent within the Path
                              Identification Message."
                        ::= { ds3FarEndConfigEntry 6 }













































          T. A. Cox and K. Tesink (editors)                    [Page 34]





          Internet Draft           DS3 Objects                April 1992


          -- Only C-bit Parity Applications and SYNTRAN applications
          -- can provide this information.

          -- The DS3 Far End Interval Table contains various statistics
          -- collected by each DS3 interface over the previous 24 hours of
          -- operation.  The past 24 hours are broken into 96
          -- completed 15 minute intervals.

                    ds3FarEndIntervalTable OBJECT-TYPE
                        SYNTAX  SEQUENCE OF DS3FarEndIntervalEntry
                        ACCESS  not-accessible
                        STATUS  mandatory
                        DESCRIPTION
                               "The DS3 Far End Interval table."
                        ::= { ds3 7 }

                    ds3FarEndIntervalEntry OBJECT-TYPE
                        SYNTAX  DS3FarEndIntervalEntry
                        ACCESS  not-accessible
                        STATUS  mandatory
                        DESCRIPTION
                              "An entry in the DS3 Far
                              End Interval table."
                        INDEX   { ds3FarEndIntervalIndex, ds3FarEndIntervalNumber }
                        ::= { ds3FarEndIntervalTable 1 }

                    DS3FarEndIntervalEntry ::=
                        SEQUENCE {
                             ds3FarEndIntervalIndex
                                  INTEGER,
                             ds3FarEndIntervalNumber
                                  INTEGER,
                             ds3FarEndIntervalESs
                                  Counter,
                             ds3FarEndIntervalSESs
                                  Counter,
                             ds3FarEndIntervalCVs
                                  Counter
                        }

                    ds3FarEndIntervalIndex OBJECT-TYPE
                        SYNTAX  INTEGER (1..65535)
                        ACCESS  read-only
                        STATUS  mandatory
                        DESCRIPTION





          T. A. Cox and K. Tesink (editors)                    [Page 35]





          Internet Draft           DS3 Objects                April 1992


                                "The index value which uniquely identifies the
                                DS3 interface
                                to which this entry is applicable.  The
                                interface identified by a particular value of
                                this index is the same interface as identified
                                by the same value an DS3LineIndex object
                                instance."
                        ::= { ds3FarEndIntervalEntry 1 }

                   ds3FarEndIntervalNumber OBJECT-TYPE
                       SYNTAX  INTEGER (1..96)
                       ACCESS  read-only
                       STATUS  mandatory
                       DESCRIPTION
                              "A number between 1 and 96, where 1 is the most
                              recently completed 15 minute interval and 96 is
                              the least recently completed 15 minutes
                              interval (assuming that all 96 intervals are
                              valid)."
                       ::= { ds3FarEndIntervalEntry 2 }

                   ds3FarEndIntervalESs OBJECT-TYPE
                       SYNTAX  Counter
                       ACCESS  read-only
                       STATUS  mandatory
                       DESCRIPTION
                               "The counter associated with the number of
                               Far End Errored Seconds encountered
                               by a DS3 interface in one of the previous 96,
                               individual 15 minute, intervals."
                      ::= { ds3FarEndIntervalEntry 3 }

                   ds3FarEndIntervalSESs OBJECT-TYPE
                       SYNTAX  Counter
                       ACCESS  read-only
                       STATUS  mandatory
                       DESCRIPTION
                               "The counter associated with the number of
                               Far End Severely Errored Seconds
                               encountered by a DS3 interface in one of the previous
                               96, individual 15 minute, intervals."
                      ::= { ds3FarEndIntervalEntry 4 }

                    ds3FarEndIntervalCVs OBJECT-TYPE
                        SYNTAX  Counter





          T. A. Cox and K. Tesink (editors)                    [Page 36]





          Internet Draft           DS3 Objects                April 1992


                        ACCESS  read-only
                        STATUS  mandatory
                        DESCRIPTION
                                "The counter associated with the number of
                                Far End Coding Violations reported via
                                the far end block error count
                                encountered by a
                                DS3 interface in one of the previous 96, individual 15
                                minute, intervals."
                        ::= { ds3FarEndIntervalEntry 5 }








































          T. A. Cox and K. Tesink (editors)                    [Page 37]





          Internet Draft           DS3 Objects                April 1992


          -- Only C-bit Parity Applications and SYNTRAN applications
          -- can provide this information.

          -- The DS3 Far End Current table contains various statistics being
          -- collected for the current 15 minute interval.

                    ds3FarEndCurrentTable OBJECT-TYPE
                        SYNTAX  SEQUENCE OF DS3FarEndCurrentEntry
                        ACCESS  not-accessible
                        STATUS  mandatory
                        DESCRIPTION
                                "The DS3 Far End Current table."
                        ::= { ds3 8 }

                    ds3FarEndCurrentEntry OBJECT-TYPE
                        SYNTAX  DS3FarEndCurrentEntry
                        ACCESS  not-accessible
                        STATUS  mandatory
                        DESCRIPTION
                                "An entry in the DS3 Far End Current table."
                        INDEX   { ds3FarEndCurrentIndex }
                        ::= { ds3FarEndCurrentTable 1 }

                    DS3FarEndCurrentEntry ::=
                        SEQUENCE {
                            ds3FarEndCurrentIndex
                                INTEGER,
                            ds3FarEndCurrentESs
                                Counter,
                            ds3FarEndCurrentSESs
                                Counter,
                            ds3FarEndCurrentCVs
                                Counter
                        }

                     ds3FarEndCurrentIndex OBJECT-TYPE
                        SYNTAX  INTEGER (1..65535)
                        ACCESS  read-only
                        STATUS  mandatory
                        DESCRIPTION
                                "The index value which uniquely identifies the
                                DS3 interface
                                to which this entry is applicable.  The interface
                                identified by a particular value of this index is
                                the same interface as identified by the same value





          T. A. Cox and K. Tesink (editors)                    [Page 38]





          Internet Draft           DS3 Objects                April 1992


                                an DS3LineIndex object instance."
                        ::= { ds3FarEndCurrentEntry 1 }

                    ds3FarEndCurrentESs OBJECT-TYPE
                        SYNTAX  Counter
                        ACCESS  read-only
                        STATUS  mandatory
                        DESCRIPTION
                                "The counter associated with the number of Far
                                Far End Errored Seconds encountered by a DS3
                                interface in the current 15 minute interval."
                        ::= { ds3FarEndCurrentEntry 2 }

                    ds3FarEndCurrentSESs OBJECT-TYPE
                        SYNTAX  Counter
                        ACCESS  read-only
                        STATUS  mandatory
                        DESCRIPTION
                                "The counter associated with the number of
                                Far End Severely Errored Seconds
                                encountered by a DS3 interface in the current 15 minute
                                interval."
                        ::= { ds3FarEndCurrentEntry 3 }

                    ds3FarEndCurrentCVs OBJECT-TYPE
                        SYNTAX  Counter
                        ACCESS  read-only
                        STATUS  mandatory
                        DESCRIPTION
                                "The counter associated with the number of
                                Far End Coding Violations reported via
                                the far end block error count
                                encountered by a
                                DS3 interface in the current 15 minute interval."
                        ::= { ds3FarEndCurrentEntry 4 }















          T. A. Cox and K. Tesink (editors)                    [Page 39]





          Internet Draft           DS3 Objects                April 1992


          -- Only C-bit Parity Applications and SYNTRAN applications
          -- can provide this information.

          -- The DS3 Far End Integer Total Table contains the cumulative sum of the
          -- various statistics for the 24 hour interval preceding the
          -- first valid interval in the DS3FarEndCurrentTable.

                    ds3FarEndIntTotalTable OBJECT-TYPE
                        SYNTAX  SEQUENCE OF DS3FarEndIntTotalEntry
                        ACCESS  not-accessible
                        STATUS  mandatory
                        DESCRIPTION
                                "The DS3 Far End Integer Total table.  24 hour interval."
                        ::= { ds3 9 }

                    ds3FarEndIntTotalEntry OBJECT-TYPE
                        SYNTAX  DS3FarEndIntTotalEntry
                        ACCESS  not-accessible
                        STATUS  mandatory
                        DESCRIPTION
                                "An entry in the DS3 Far End Integer Total table."
                        INDEX   { ds3FarEndIntTotalIndex }
                        ::= { ds3FarEndIntTotalTable 1 }

                    DS3FarEndIntTotalEntry ::=
                        SEQUENCE {
                            ds3FarEndIntTotalIndex
                                INTEGER,
                            ds3FarEndIntTotalESs
                                INTEGER,
                            ds3FarEndIntTotalSESs
                                INTEGER,
                            ds3FarEndIntTotalCVs
                                INTEGER
                        }

                    ds3FarEndIntTotalIndex OBJECT-TYPE
                        SYNTAX  INTEGER (1..65535)
                        ACCESS  read-only
                        STATUS  mandatory
                        DESCRIPTION
                                "The index value which uniquely identifies the
                                DS3 interface
                                to which this entry is applicable.  The interface
                                identified by a particular value of this index is





          T. A. Cox and K. Tesink (editors)                    [Page 40]





          Internet Draft           DS3 Objects                April 1992


                                the same interface as identified by the same value
                                an DS3LineIndex object instance."
                        ::= { ds3FarEndIntTotalEntry 1 }

                   ds3FarEndIntTotalESs OBJECT-TYPE
                       SYNTAX  INTEGER (1..4294967295)
                       ACCESS  read-only
                       STATUS  mandatory
                       DESCRIPTION
                               "The counter associated with the number of Far
                               End Errored Seconds encountered by a DS3
                               interface in the previous 24 hour interval."
                       ::= { ds3FarEndIntTotalEntry 2 }

                   ds3FarEndIntTotalSESs OBJECT-TYPE
                       SYNTAX  INTEGER (1..4294967295)
                       ACCESS  read-only
                       STATUS  mandatory
                       DESCRIPTION
                               "The counter associated with the number of
                               Far End Severely Errored Seconds
                               encountered by a DS3 interface in the previous 24 hour
                               interval."
                       ::= { ds3FarEndIntTotalEntry 3 }

                   ds3FarEndIntTotalCVs OBJECT-TYPE
                       SYNTAX  INTEGER (1..4294967295)
                       ACCESS  read-only
                       STATUS  mandatory
                       DESCRIPTION
                               "The counter associated with the number of
                               Far End Coding Violations reported via the
                               far end block error count
                               encountered by a
                               DS3 interface in the previous 24 hour interval."
                       ::= { ds3FarEndIntTotalEntry 4 }



          END










          T. A. Cox and K. Tesink (editors)                    [Page 41]





          Internet Draft           DS3 Objects                April 1992


          7.  Acknowledgments

          This document was produced by the SNMP and the Trunk MIB
          Working Groups:

                              Anne Ambler, Spider
                              Karl Auerbach, Sun
                              Fred Baker, ACC
                              Ken Brinkerhoff
                              Ron Broersma, NOSC
                              Jack Brown, US Army
                              Theodore Brunner, Bellcore
                              Jeffrey Buffum, HP
                              Jeffrey D. Case, UTK
                              Chris Chiptasso, Spartacus
                              Paul Ciarfella, DEC
                              Bob Collet
                              Tracy Cox, Bellcore
                              James R. Davin, MIT-LCS
                              Kurt Dobbins, Cabletron
                              Nadya El-Afandi, Network Systems
                              Gary Ellis, HP
                              Fred Engle
                              Mike Erlinger
                              Richard Fox, Synoptics
                              Karen Frisa, CMU
                              Chris Gunner, DEC
                              Ken Hibbard, Xylogics
                              Ole Jacobsen, Interop
                              Ken Jones
                              Satish Joshi, Synoptics
                              Frank Kastenholz, Racal-Interlan
                              Shimshon Kaufman, Spartacus
                              Jim Kinder, Fibercom
                              Alex Koifman, BBN
                              Christopher Kolb, PSI
                              Cheryl Krupczak, NCR
                              Peter Lin, Vitalink
                              John Lunny, TWG
                              Carl Malamud
                              Keith McCloghrie, HLS
                              Donna McMaster, David Systems
                              Lynn Monsanto, Sun
                              Dave Perkins, 3COM
                              Jim Reinstedler, Ungerman Bass





          T. A. Cox and K. Tesink (editors)                    [Page 42]





          Internet Draft           DS3 Objects                April 1992


                              Anil Rijsinghani, DEC
                              Kary Robertson
                              Marshall T. Rose, PSI (chair)
                              L. Michael Sabo, NCSC
                              Jon Saperia, DEC
                              John Seligson
                              Fei Shu, NEC
                              Sam Sjogren, TGV
                              Mark Sleeper, Sparta
                              Lance Sprung
                              Mike St.Johns
                              Bob Stewart, Xyplex
                              Emil Sturniold
                              Kaj Tesink, Bellcore
                              Dean Throop, Data General
                              Bill Townsend, Xylogics
                              Maurice Turcotte
                              Kannan Varadhou
                              Sudhanshu Verma, HP
                              Warren Vik, Interactive Systems
                              David Waitzman, BBN
                              Steve Waldbusser, CMU
                              Dan Wintringhan
                              David Wood
                              Jeff Young, Cray Research

























          T. A. Cox and K. Tesink (editors)                    [Page 43]





          Internet Draft           DS3 Objects                April 1992


          8.  References

             [1] Cerf, V., "IAB Recommendations for the Development of Internet
                 Network Management Standards", RFC 1052, NRI, April 1988.

             [2] Cerf, V., "Report of the Second Ad Hoc Network Management Review
                 Group", RFC 1109, NRI, August 1989.

             [3] Rose M., and K. McCloghrie, "Structure and Identification of
                 Management Information for TCP/IP-based internets", RFC 1155,
                 Performance Systems International, Hughes LAN Systems, May 1990.

             [4] 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.

             [5] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
                 Network Management Protocol", RFC 1157, SNMP Research,
                 Performance Systems International, Performance Systems
                 International, MIT Laboratory for Computer Science, May 1990.

             [6] McCloghrie K., and M. Rose, Editors, "Management Information Base
                 for Network Management of TCP/IP-based internets", RFC 1213,
                 Performance Systems International, March 1991.

             [7] Information processing systems - Open Systems Interconnection -
                 Specification of Abstract Syntax Notation One (ASN.1),
                 International Organization for Standardization, International
                 Standard 8824, December 1987.

             [8] 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.

             [9] American National Standard for telecommunications - digital
                 hierarchy - electrical interfaces, ANSI T1.102- 1987.

            [10] American National Standard for telecommunications - digital
                 hierarchy - formats specification, ANSI T1.107- 1988.

            [10a] ANSI T1.107a-1990.

            [11] American National Standard for telecommunications - Carrier-to-
                 Customer Installation - DS3 Metallic Interface, ANSI T1.404-1989.





          T. A. Cox and K. Tesink (editors)                    [Page 44]





          Internet Draft           DS3 Objects                April 1992


            [12] In-Service Digital Transmission Performance Monitoring Draft
                 Standard, T1M1.3/92-005.

            [13] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions",
                 RFC 1212, Performance Systems International, Hughes LAN Systems,
                 March 1991.












































          T. A. Cox and K. Tesink (editors)                    [Page 45]





          Internet Draft           DS3 Objects                April 1992


          9.  Security Considerations

          Security issues are not discussed in this memo.


          10.  Authors' Addresses

             Tracy A. Cox
             Bell Communications Research
             331 Newman Springs Road
             P.O. Box 7020
             Red Bank, NJ  07701-7020

             Phone: (908) 758-2107

             EMail: tacox@sabre.bellcore.com


             Kaj Tesink
             Bell Communications Research
             331 Newman Springs Road
             P.O. Box 7020
             Red Bank, NJ  07701-7020

             Phone: (908) 758-5254

             EMail: kaj@nvuxr.cc.bellcore.com























          T. A. Cox and K. Tesink (editors)                    [Page 46]





          Internet Draft           DS3 Objects                April 1992


          Table of Contents


          1 Status of this Memo ...................................    1
          2 Abstract ..............................................    1
          3 The Network Management Framework ......................    2
          4 Objects ...............................................    3
          4.1 Format of Definitions ...............................    3
          4.2 Changes from RFC1233 ................................    3
          5 Overview ..............................................    5
          5.1 Binding between ifIndex and DS3 Interfaces ..........    5
          5.2 Objectives of this MIB Module .......................    5
          5.3 DS3 Terminology .....................................    5
          6 Object Definitions ....................................    9
          6.1 The DS3 Near End Group ..............................   10
          6.1.1 The DS3 Configuration Group .......................   10
          6.1.2 The DS3 Interval Group ............................   18
          6.1.3 The DS3 Current Group .............................   22
          6.1.4 The DS3 Total Group ...............................   25
          6.1.5 The DS3 Integer Total Group .......................   28
          6.2 The DS3 Far End Group ...............................   31
          6.2.1 The DS3 Far End Configuration Group ...............   31
          6.2.2 The DS3 Far End Interval Group ....................   35
          6.2.3 The DS3 Far End Current Group .....................   38
          6.2.4 The DS3 Far End Integer Total Group ...............   40
          7 Acknowledgments .......................................   42
          8 References ............................................   44
          9 Security Considerations ...............................   46
          10 Authors' Addresses ...................................   46





















          T. A. Cox and K. Tesink (editors)                    [Page 47]











Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa02822;
          27 Apr 92 12:10 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa05041;
          27 Apr 92 12:14 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa05036;
          27 Apr 92 12:14 EDT
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA26731; Mon, 27 Apr 92 09:08:47 PDT
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA14315; Mon, 27 Apr 92 12:02:38 EDT
Return-Path: <tacox@sabre.bellcore.com>
Received: by ginsu4 (4.1/4.7)
	id AA05664; Mon, 27 Apr 92 12:05:15 EDT
Date: Mon, 27 Apr 92 12:05:15 EDT
From: Tracy Cox <tacox@sabre.bellcore.com>
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9204271605.AA05664@ginsu4>
To: trunk-mib@acc.com
Subject: integers

Gang,

Should the objects in the Interval table
be INTEGERs instead of Counters?  Every
15-minutes there will be a new value for the
object and it may be more or less than the previous
value.  Also, during the 15 minute interval, the vale
will not change.

It means deprecating the IntervalTable also.

What do you think?

Tracy










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa02981;
          27 Apr 92 12:42 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa06682;
          27 Apr 92 12:46 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa06673;
          27 Apr 92 12:46 EDT
Received: from saffron.acc.com by fennel.acc.com (4.1/SMI-4.1)
	id AA28123; Mon, 27 Apr 92 09:37:46 PDT
Received: by saffron.acc.com (4.1/SMI-4.1)
	id AA28845; Mon, 27 Apr 92 09:35:53 PDT
Date: Mon, 27 Apr 92 09:35:53 PDT
From: Fred Baker <fbaker@acc.com>
Message-Id: <9204271635.AA28845@saffron.acc.com>
To: tacox@sabre.bellcore.com
Subject: Re:  integers
Cc: trunk-mib@acc.com

>> Should the objects in the Interval table be INTEGERs instead of
>> Counters?  Every 15-minutes there will be a new value for the
>> object and it may be more or less than the previous value.  Also,
>> during the 15 minute interval, the value will not change.

>> It means deprecating the IntervalTable also.

You're probably right, Tracy.

I have a question.  What we've got left undeprecated is the
configuration table.  Should we scrap the old and start over?  Is that
what we already said?

(was I dumb when I signed up to do my first MIB, or what?)

Fred











Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa03000;
          27 Apr 92 12:44 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa06794;
          27 Apr 92 12:49 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa06790;
          27 Apr 92 12:49 EDT
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA28349; Mon, 27 Apr 92 09:42:24 PDT
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA14649; Mon, 27 Apr 92 12:35:58 EDT
Return-Path: <tacox@ginsu4@sabre.bellcore.com>
Received: from localhost by ginsu4 (4.1/4.7)
	id AA05700; Mon, 27 Apr 92 12:38:35 EDT
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9204271638.AA05700@ginsu4>
To: Fred Baker <fbaker@acc.com>
Cc: trunk-mib@acc.com
Subject: Re: integers 
In-Reply-To: Your message of "Mon, 27 Apr 92 09:35:53 PDT."
             <9204271635.AA28845@saffron.acc.com> 
Date: Mon, 27 Apr 92 12:38:33 -0400
From: tacox@ginsu4.bellcore.com

> 
> 
> >> Should the objects in the Interval table be INTEGERs instead of
> >> Counters?  Every 15-minutes there will be a new value for the
> >> object and it may be more or less than the previous value.  Also,
> >> during the 15 minute interval, the value will not change.
> 
> >> It means deprecating the IntervalTable also.
> 
> You're probably right, Tracy.
> 
> I have a question.  What we've got left undeprecated is the
> configuration table.  Should we scrap the old and start over?  Is that
> what we already said?
> 
> (was I dumb when I signed up to do my first MIB, or what?)
> 
> Fred
> 

What does it mean to start over?  What OID value would we get
for DS1 and DS3?

Chuck -- how do we proceed with dignity?

The only table left untouched is the CurrentTable -- the ConfigTable
has objects in it that have been deprecated.  The Interval and
Total table will be totally deprecated and replaced.

(was I dumb when I signed up to do my first MIB, or what?)
 -- me too!!  You can say alot for on the job training.

Tracy











Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa04250;
          27 Apr 92 19:34 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa29734;
          27 Apr 92 19:38 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa29728;
          27 Apr 92 19:38 EDT
Received: from mace.LCS.MIT.EDU by fennel.acc.com (4.1/SMI-4.1)
	id AA11787; Mon, 27 Apr 92 16:28:46 PDT
Received: from MACE.LCS.MIT.EDU by mace.LCS.MIT.EDU via TCP with SMTP
	id AA06230; Mon, 27 Apr 92 19:28:33 EDT
Message-Id: <9204272328.AA06230@mace.LCS.MIT.EDU>
From: "James R. (Chuck) Davin" <jrd@thyme.lcs.mit.edu>
To: tacox@ginsu4.bellcore.com
Cc: Fred Baker <fbaker@acc.com>, trunk-mib@acc.com
Subject: Re: integers 
In-Reply-To: Your message of Mon, 27 Apr 92 12:38:33 -0400.
             <9204271638.AA05700@ginsu4> 
Date: Mon, 27 Apr 92 19:28:30 -0400
Sender: jrd@mace.lcs.mit.edu


Isn't there a McCartney song about this? I just remember lots of black
and white film of John and Yoko.

"Starting over" probably doesn't obviate the need to deprecate the
objects that would be tossed aside. In that respect, I'm not sure what
"starting over" means.

Maybe it just means we would conclude that tinkering the trunk MIBs
wasn't something that could be done quickly on the way to Draft stage.
If that is the judgement, then perhaps some reconsideration of our
overall strategy is needed.

>> X-Station-Sent-From: ginsu4.bellcore.com
>> To: fbaker@acc.com (Fred Baker)
>> Cc: trunk-mib@acc.com
>> Subject: Re: integers 
>> Date: Mon, 27 Apr 92 12:38:33 -0400
>> From: tacox@ginsu4.bellcore.com
>> 
>> > 
>> > 
>> > >> Should the objects in the Interval table be INTEGERs instead of
>> > >> Counters?  Every 15-minutes there will be a new value for the
>> > >> object and it may be more or less than the previous value.  Also,
>> > >> during the 15 minute interval, the value will not change.
>> > 
>> > >> It means deprecating the IntervalTable also.
>> > 
>> > You're probably right, Tracy.
>> > 
>> > I have a question.  What we've got left undeprecated is the
>> > configuration table.  Should we scrap the old and start over?  Is that
>> > what we already said?
>> > 
>> > (was I dumb when I signed up to do my first MIB, or what?)
>> > 
>> > Fred
>> > 
>> 
>> What does it mean to start over?  What OID value would we get
>> for DS1 and DS3?
>> 
>> Chuck -- how do we proceed with dignity?
>> 
>> The only table left untouched is the CurrentTable -- the ConfigTable
>> has objects in it that have been deprecated.  The Interval and
>> Total table will be totally deprecated and replaced.
>> 
>> (was I dumb when I signed up to do my first MIB, or what?)
>>  -- me too!!  You can say alot for on the job training.
>> 
>> Tracy
>> 











Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa01628;
          28 Apr 92 11:45 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa23878;
          28 Apr 92 11:50 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa23872;
          28 Apr 92 11:50 EDT
Received: from saffron.acc.com by fennel.acc.com (4.1/SMI-4.1)
	id AA06793; Tue, 28 Apr 92 08:39:48 PDT
Received: by saffron.acc.com (4.1/SMI-4.1)
	id AA00961; Tue, 28 Apr 92 08:37:56 PDT
Date: Tue, 28 Apr 92 08:37:56 PDT
From: Fred Baker <fbaker@acc.com>
Message-Id: <9204281537.AA00961@saffron.acc.com>
To: tacox@ginsu4.bellcore.com
Subject: Re: integers
Cc: trunk-mib@acc.com

No, but a Gauge can.  A guage is a reading that can change at will,
like looking at a thermometer.  Would that work?

Fred










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa01779;
          28 Apr 92 12:15 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa25738;
          28 Apr 92 12:20 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa25710;
          28 Apr 92 12:20 EDT
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA08645; Tue, 28 Apr 92 09:15:48 PDT
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA22420; Tue, 28 Apr 92 12:09:36 EDT
Return-Path: <tacox@sabre.bellcore.com>
Received: by ginsu4 (4.1/4.7)
	id AA06187; Tue, 28 Apr 92 12:12:17 EDT
Date: Tue, 28 Apr 92 12:12:17 EDT
From: Tracy Cox <tacox@sabre.bellcore.com>
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9204281612.AA06187@ginsu4>
To: trunk-mib@acc.com
Subject: gauge



So, is the SYNTAX for the IntTotalTable
and IntIntervalTable a gauge -- so
that it can start at 0 and go up to 2^32 - 1?

An integer can not start at zero -- so says the Simple Book.

However, we have defined ds*ValidIntervals as INTEGER (0..96).
Is this wrong?

The objects in the Interval Table and Total Table will change
value every 15-minutes and may have the value of zero.
So the SYNTAX should be a gauge.

Tracy










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa01808;
          28 Apr 92 12:45 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa27158;
          28 Apr 92 12:50 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa27154;
          28 Apr 92 12:50 EDT
Received: from saffron.acc.com by fennel.acc.com (4.1/SMI-4.1)
	id AA09953; Tue, 28 Apr 92 09:44:44 PDT
Received: by saffron.acc.com (4.1/SMI-4.1)
	id AA04281; Tue, 28 Apr 92 09:42:49 PDT
Date: Tue, 28 Apr 92 09:42:49 PDT
From: Fred Baker <fbaker@acc.com>
Message-Id: <9204281642.AA04281@saffron.acc.com>
To: tacox@sabre.bellcore.com, trunk-mib@acc.com
Subject: Re:  gauge

>> So, is the SYNTAX for the IntTotalTable and IntIntervalTable a gauge --
>> so that it can start at 0 and go up to 2^32 - 1?

That's my suggestion.

>> An integer can not start at zero -- so says the Simple Book.

Well, you and I were both there, and Marshall was presiding, when Jeff
Case and I discussed this at Boulder, a year ago December.  The WG
decided it was legal and right then; what's changed?

>> However, we have defined ds*ValidIntervals as INTEGER (0..96).  Is this
>> wrong?

What would be *wrong* would be if it was an ENUMERATED integer and one
of the values was zero.  I remain of the opinion that personal hot
buttons about the value zero has more to do with that than technical
correctness - there is no "correctness" reason for the stricture - but
*that* is what RFC 1155 (or is it 1157?) says is incorrect.

>> The objects in the Interval Table and Total Table will change value
>> every 15-minutes and may have the value of zero.  So the SYNTAX should
>> be a gauge.

Yes, I think so.

Fred










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa02316;
          30 Apr 92 12:18 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa23172;
          30 Apr 92 12:23 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa23150;
          30 Apr 92 12:23 EDT
Received: from saffron.acc.com by fennel.acc.com (4.1/SMI-4.1)
	id AA13997; Thu, 30 Apr 92 09:14:41 PDT
Received: by saffron.acc.com (4.1/SMI-4.1)
	id AA15149; Thu, 30 Apr 92 09:14:11 PDT
Date: Thu, 30 Apr 92 09:14:11 PDT
From: Fred Baker <fbaker@acc.com>
Message-Id: <9204301614.AA15149@saffron.acc.com>
To: trunk-mib@fennel.acc.com
Subject: Boston IETF, July 13-17, 1992


Hi:

A precedural note:

Megan just dropped a note to the wgchairs list about her plans to start
scheduling the Boston IETF.  One possibility (just that, at this point)
is that meeting rooms may be available on Sunday July 12 to offload the
week.

If so, is there interest in trying to have a meeting on Sunday?

Fred










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa01569;
          4 May 92 9:11 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa20036;
          4 May 92 9:16 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa19990; 4 May 92 9:15 EDT
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA05983; Mon, 4 May 92 05:54:01 PDT
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA24599; Mon, 4 May 92 08:46:54 EDT
Return-Path: <tacox@sabre.bellcore.com>
Received: by ginsu4 (4.1/4.7)
	id AA06847; Mon, 4 May 92 08:49:51 EDT
Date: Mon, 4 May 92 08:49:51 EDT
From: Tracy Cox <tacox@sabre.bellcore.com>
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9205041249.AA06847@ginsu4>
To: trunk-mib@acc.com
Subject: DS3 MIB

Gang,

PLEASE LOOK OVER THIS MIB.

I would like to post it in the internet-drafts
directory SOON and MUCH before the
July meeting so that we can discuss it
then.

I will schedule one session at the July meeting
to discuss all the changes that have occurred in the
DS1/3 MIB since March.

What do people think about Fred's suggestion about
Sunday night?

If I hear nothing back from the group by Thursday the 14th --
I am going to assume that the MIB is okay and send it off to
the internet-drafts directory.

Tracy





          Internet Draft           DS3 Objects                  May 1992


                          Definitions of Managed Objects
                            for the DS3 Interface Type

                                     May 1992


                             Trunk MIB Working Group

                              Tracy A. Cox (editor)
                               Kaj Tesink (editor)
                           Bell Communications Research
                             331 Newman Springs Road
                               Red Bank, NJ  07701

                             tacox@sabre.bellcore.com
                            kaj@nvuxr.cc.bellcore.com




          1.  Status of this Memo

          This draft document will be submitted to the RFC editor as an
          experimental extension to the SNMP MIB.  Distribution of this
          memo is unlimited.  Please send comments to the editors.

          2.  Abstract

          This memo defines an experimental 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 DS3 objects.  This document is a
          companion document with Experimental Definitions of Managed
          Objects for the DS1 Interface Type.

          This memo does not specify a standard for the Internet
          community.













          T. A. Cox and K. Tesink (editors)                     [Page 1]





          Internet Draft           DS3 Objects                  May 1992


          3.  The Network Management Framework

          The Internet-standard Network Management Framework consists of three
          components.  They are:

                RFC 1155 which defines the SMI, the mechanisms used for describing
                and naming objects for the purpose of management.  RFC 1212
                defines a more concise description mechanism, which is wholly
                consistent with the SMI.

                RFC 1156 which defines MIB-I, the core set of managed objects for
                the Internet suite of protocols.  RFC 1213, defines MIB-II, an
                evolution of MIB-I based on implementation experience and new
                operational requirements.

                RFC 1157 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.






























          T. A. Cox and K. Tesink (editors)                     [Page 2]





          Internet Draft           DS3 Objects                  May 1992


          4.  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) [7] 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 [3]
          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 [8], subject to the additional requirements
          imposed by the SNMP.

          4.1.  Format of Definitions

          Section 6 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 RFC1212 [13].

          4.2.  Changes from RFC1233

          The changes from RFC1233 are the following:

          --  This MIB module contains two groups:
               DS3 Near End Group which is mandatory and
               DS3 Far End Group which is optional.

          --  The Far End Group is a new group and contains
              configuration information and statistics





          T. A. Cox and K. Tesink (editors)                     [Page 3]





          Internet Draft           DS3 Objects                  May 1992


              that are collected from the far end DS3 interface.

          --  ds3CSUIndex has been renamed ds3LineIndex.  This object
              is the identifier of a DS3 Interface on a device.

          --  ds3Index has been renamed ds3IfIndex.  This value for this
              object is equal to the value of ifIndex from the Interfaces
              table of MIB II (RFC 1213).

          --  ds3Loopback has been deprecated.

          --  A new object has been added called ds3LoopbackConfig,
              which better describes the loopback capabilities of
              a DS3 interface on a device.

          --  ds3YellowAlarm has been deprecated.

          --  ds3RedAlarm has been deprecated.

          --  A new object has been added called ds3LineStatus.
              This object better describes the status (e.g.,
              alarm state and loopback state) of a
              DS3 interface.

          --  ds3IntervalCSSs, ds3CurrentCSSs, and ds3TotalCSSs have
              been deprecated.

          --  The ds3IntervalTable and the ds3TotalTable have been deprecated and replaced with
              two other tables, ds3GgIntervalTable
              and ds3GgTotalTable, respectively, whose objects have a SYNTAX of
              Gauge.



















          T. A. Cox and K. Tesink (editors)                     [Page 4]





          Internet Draft           DS3 Objects                  May 1992


          5.  Overview

          These objects are used when the particular media being used to
          realize an interface is a DS3 interface.  At present, this
          applies to these values of the ifType variable in the
          Internet-standard MIB:

               ds3 (30)

          The definitions contained herein are based on the DS3
          specifications in ANSI T1.102-1987, ANSI T1.107-1988, ANSI
          T1.107a-1990, and ANSI T1.404-1989 [9,10,10a,11].

          5.1.  Binding between ifIndex and DS3 Interfaces

          Each agent which resides on a host which uses DS3 interfaces
          is required to assign a small, non-negative integer uniquely
          to each DS3 Interface.  This is known as the "LineIndex", and
          is used to distinguish between different DS3 interfaces
          attached to a node.  The LineIndex is also used as the `key'
          when accessing tabular information about DS3 interfaces.  If
          there is at least one ifEntry directly associated with the DS3
          interface (e.g., if the DS3 interface is used to communicate
          with the Network Layer), it should have the same value as
          ifIndex.  Otherwise, its value should exceed ifNumber.

          The ds3IfIndex column of the DS3 Configuration table relates
          each DS3 interface to its corresponding interface (ifIndex) in
          the Internet-standard MIB (MIB-II RFC1213).

          5.2.  Objectives of this MIB Module

          There are numerous things that could be included in a MIB for
          DS3 signals: the management of multiplexors, CSUs, DSUs, and
          the like.  The intent of this document is to facilitate the
          common management of all devices with DS3 interfaces, both
          in-chassis and external via proxy.  As such, a design decision
          was made up front to very closely align the MIB with the set
          of objects that can generally be read from DS3 devices that
          are currently deployed.

          5.3.  DS3 Terminology

          The terminology used in this document to describe error
          conditions on a DS3 interface as monitored by a DS3 device are





          T. A. Cox and K. Tesink (editors)                     [Page 5]





          Internet Draft           DS3 Objects                  May 1992


          based on the definitions from the ANSI T1M1.3/92-005 draft
          standard [12].  If the definition in this document does not
          match the definition in the ANSI T1M1.3/92-005 draft document,
          the implementer should follow the definition described in this
          document.

                    Bipolar Violation (BPV)
                         A bipolar violation, for B3ZS-coded signals, is the
                         occurrence of a pulse of the same polarity as the previous
                         pulse without being part of the zero substitution code,
                         B3ZS.  For B3ZS-coded
                         signals, a bipolar violation may also include other error
                         patterns such as:  three or more consecutive zeros and
                         incorrect polarity.

                    Coding Violation (CV)
                         For all DS3 applications, a coding violation is a P-bit
                         Parity Error event.  A P-bit Parity Error event is the
                         occurrence of a received P-bit code on the DS3 M-frame
                         that is not identical to the corresponding locally-
                         calculated code.

                    Errored Seconds (ES)
                         An ES is a second with one or more Coding Violation OR
                         one or more Out of Frame events OR a detected incoming AIS.

                    Severely Errored Seconds (SES)
                         A SES is a second with 44 or more Coding Violations OR
                         one or more Out of Frame events OR a detected incoming AIS.

                    Severely Errored Framing Seconds (SEFS)
                         A SEFS is a second with one or more Out of Frame events
                         OR a detected incoming AIS.

                    Unavailable Seconds (UAS)
                         UAS are calculated by counting the number of seconds that
                         the interface is unavailable.  The DS3 interface is said
                         to be unavailable from the onset of 10 contiguous SESs, or
                         the onset of the condition leading to a failure (see Alarm
                         States).  If the condition leading to the failure was
                         immediately preceded by one or more contiguous SESs, then
                         the DS3 interface unavailability starts from the onset of these
                         SESs.  Once unavailable, and if no failure is present, the DS3
                         interface becomes available at the onset of 10 contiguous seconds
                         with no SESs.  Once unavailable, and if a failure is present,





          T. A. Cox and K. Tesink (editors)                     [Page 6]





          Internet Draft           DS3 Objects                  May 1992


                         the DS3 interface becomes available at the onset of 10 contiguous
                         seconds with no SESs, if the failure clearing time is less than
                         or equal to 10 seconds.  If the failure clearing time is more than
                         10 seconds, the DS3 interface becomes available at the onset of 10
                         contiguous seconds with no SESs, or the onset period leading to the
                         successful clearing condition, whichever occurs later.
                         With respect to the DS3 error counts, all counters are incremented
                         while the DS3 interface is deemed available.  While the interface is
                         deemed unavailable, the only count that is incremented is UASs.

                         A special case exists when the 10 or more second period
                         crosses the 900 second statistics window boundary, as the
                         foregoing description implies that the SES and UAS
                         counters must be adjusted when the Unavailable Signal
                         State is entered. Clearly, successive GETs of the
                         affected ds3IntervalSES and ds3IntervalUAS objects will
                         return differing values if the first GET occurs during
                         the first few seconds of the window.  This is viewed as
                         an unavoidable side-effect of selecting the presently
                         defined managed objects as a basis for this memo.

                    Alarm States:
                         The Far End Alarm (or Yellow Alarm) is declared after detecting
                         the Yellow Alarm-Signal.  See ANSI T1.107a-1990 [10].

                         Also, the incoming alarm state is declared when a failure condition
                         persists for at least 2-10 seconds.  The failure conditions are
                         the following:  Loss of
                         Signal (LOS), a Loss of Frame (LOF) (a persistent Out
                         of Frame event), or an
                         Alarm Indication Signal (AIS).
                         The Alarm State is cleared at the onset of 10
                         consecutive seconds with no SESs.
                         The Alarm State object identifies only the highest priority
                         failure condition.  The priority of the failure conditions from highest to lowest
                         is LOS, LOF, AIS, and Far End Alarm.

                    Out of Frame (OOF) event
                         An OOF event is detected when any three or more errors in
                         sixteen or fewer consecutive F-bits occur within a DS3
                         M-frame.  An OOF event is cleared when reframe occurs.
                         A Loss of Frame (LOF) failure condition is declared when the OOF event
                         is consistent for 2 to 10 seconds.  The OOF event ends when
                         reframe occurs.  The LOF failure condition is cleared when the OOF defect
                         is absent for 10 to 20 seconds.





          T. A. Cox and K. Tesink (editors)                     [Page 7]





          Internet Draft           DS3 Objects                  May 1992


                    Loss of Signal (LOS)
                         The LOS event is declared upon observing 175 +/- 75
                         contiguous pulse positions with no pulses of either
                         positive or negative polarity.
                         The LOS is terminated upon observing an average pulse density
                         of at least 33% over a period of 175 +/- 75 contiguous pulse
                         positions starting with the receipt of a pulse.

                    Alarm Indication Signal (AIS)
                         The AIS is framed with "stuck stuffing."  This implies
                         that it has a valid M-subframe alignments bits, M-frame
                         alignment bits, and P bits.  The information bits are set
                         to a 1010... sequence, starting with a one (1) after each
                         M-subframe alignment bit, M-frame alignment bit, X bit, P bit,
                         and C bit.  The C bits are all set to zero giving what is called
                         "stuck stuffing."  The X bits are set to one.
                         The AIS is declared after AIS is present in contiguous M-frames
                         for a time equal to or greater than T, where
                         0.2 ms <= T <= 100 ms.
                         The AIS is terminated after AIS is absent in contiguous M-frames
                         for a time equal to or greater than T.

                    Circuit Identifier
                         This is a character string specified by the circuit
                         vendor, and is useful when communicating with the vendor
                         during the troubleshooting process.
























          T. A. Cox and K. Tesink (editors)                     [Page 8]





          Internet Draft           DS3 Objects                  May 1992


          6.  Object Definitions

               RFCxxxx-MIB DEFINITIONS ::= BEGIN

               IMPORTS
                       mgmt, experimental, Counter, Gauge
                               FROM RFC1155-SMI
                       DisplayString
                               FROM RFC1158-MIB
                       OBJECT-TYPE
                               FROM RFC-1212;

               --  This MIB module uses the extended OBJECT-TYPE macro as
               --  defined in RFC 1212.

               --  this is the MIB module for the DS3 objects

                              mib-2 OBJECT IDENTIFIER ::= { mgmt 1 }
                              transmission OBJECT IDENTIFIER ::= { mib-2 10 }
                              ds3 OBJECT IDENTIFIER ::= { transmission 30 }






























          T. A. Cox and K. Tesink (editors)                     [Page 9]





          Internet Draft           DS3 Objects                  May 1992


               -- The DS3 Near End Group

               -- Implementation of this group is mandatory for all systems
               -- that attach to a DS3 Interface.

               -- The DS3 Near End Group consists of four tables:
               --    DS3 Configuration
               --    DS3 Current
               --    DS3 Gauge Interval
               --    DS3 Gauge Total

               -- the DS3 Configuration

               -- Although the objects in this table are read-only, at the
               -- agent's discretion they may be made read-write so that the
               -- management station, when appropriately authorized, may
               -- change the behavior of the interface, e.g., to place the interface
               -- into a loopback state.

               ds3ConfigTable OBJECT-TYPE
                   SYNTAX  SEQUENCE OF DS3ConfigEntry
                   ACCESS  not-accessible
                   STATUS  mandatory
                   DESCRIPTION
                           "The DS3 Configuration table."
                  ::= { ds3 1 }

              ds3ConfigEntry OBJECT-TYPE
                  SYNTAX  DS3ConfigEntry
                  ACCESS  not-accessible
                  STATUS  mandatory
                  DESCRIPTION
                          "An entry in the DS3 Configuration table."
                 INDEX   { ds3LineIndex }
                 ::= { ds3ConfigTable 1 }

             DS3ConfigEntry ::=
                 SEQUENCE {
                     ds3LineIndex
                         INTEGER,
                     ds3IfIndex
                         INTEGER,
                     ds3TimeElapsed
                         INTEGER,
                     ds3ValidIntervals





          T. A. Cox and K. Tesink (editors)                    [Page 10]





          Internet Draft           DS3 Objects                  May 1992


                         INTEGER,
                     ds3LineType
                         INTEGER,
                     ds3ZeroCoding
                         INTEGER,
                     ds3Loopback
                         INTEGER,
                     ds3SendCode
                         INTEGER,
                     ds3YellowAlarm
                         INTEGER,
                     ds3RedAlarm
                         INTEGER,
                     ds3CircuitIdentifier
                         DisplayString,
                     ds3LoopbackConfig
                         INTEGER,
                     ds3LineStatus
                         INTEGER
             }

             ds3LineIndex OBJECT-TYPE
                 SYNTAX  INTEGER (1..65535)
                 ACCESS  read-only
                 STATUS  mandatory
                 DESCRIPTION
                         "This object is the identifier of a DS3
                         Interface on a device.  If there is at least
                         one ifEntry directly associated with the DS3
                         interface (e.g., if the DS3 interface is used
                         to communicate with the Network Layer), it
                         should have the same value as ifIndex.
                         Otherwise, its value should exceed ifNumber."
                ::= { ds3ConfigEntry 1 }

            ds3IfIndex OBJECT-TYPE
                SYNTAX  INTEGER (1..65535)
                ACCESS  read-only
                STATUS  mandatory
                DESCRIPTION
                        "This value for this object is equal to the
                        value of ifIndex from the Interfaces table of
                        MIB II (RFC 1213)."
               ::= { ds3ConfigEntry 2 }






          T. A. Cox and K. Tesink (editors)                    [Page 11]





          Internet Draft           DS3 Objects                  May 1992


           ds3TimeElapsed OBJECT-TYPE
               SYNTAX  INTEGER (1..900)
               ACCESS  read-only
               STATUS  mandatory
               DESCRIPTION
                       "The number of seconds, including partial
                       seconds, that have elapsed since the beginning of
                       the current error-measurement period."
              ::= { ds3ConfigEntry 3 }

          ds3ValidIntervals OBJECT-TYPE
              SYNTAX  INTEGER (0..96)
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The number of previous intervals for which valid
                      data was collected.  The value will be 96 unless
                      the interface was brought online within the last
                      24 hours, in which case the value will be the
                      number of complete 15 minute intervals the
                      interface has been online."
              ::= { ds3ConfigEntry 4 }

          ds3LineType OBJECT-TYPE
              SYNTAX  INTEGER {
                          other(1),
                          ds3M23(2),
                          ds3SYNTRAN(3),
                          ds3CbitParity(4),
                          ds3ClearChannel(5)
                      }
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "This variable indicates the variety of DS3 C-bit
                      application implementing this interface.  The type
                      of interface affects the interpretation of the
                      usage and error statistics.  The rate of all of
                      them is 44.736 Mbps.

                      The values, in sequence, describe:
                      TITLE:            SPECIFICATION:
                      ds3M23            ANSI T1.107-1988 [10]
                      ds3SYNTRAN        ANSI T1.107-1988 [10]
                      ds3C-bit Parity   ANSI T1.107a-1989 [10a]





          T. A. Cox and K. Tesink (editors)                    [Page 12]





          Internet Draft           DS3 Objects                  May 1992


                      ds3Clear Channel  ANSI T1.102-1987 [9]
                      "
              ::= { ds3ConfigEntry 5 }

          ds3ZeroCoding OBJECT-TYPE
              SYNTAX  INTEGER {
                          ds3other(1),
                          ds3B3ZS(2)
                      }
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "This variable describes the variety of Zero Code
                      Suppression used on this interface, which in turn
                      affects a number of its characteristics.

                      DS3B3ZS refer to the use of specified patterns of
                      normal bits and bipolar violations which are used
                      to replace sequences of zero bits of a specified
                      length."
              ::= { ds3ConfigEntry 6 }

              ds3Loopback OBJECT-TYPE
                        SYNTAX  INTEGER {
                                    ds3NoLoop(1),
                                    ds3LocalLoopbackLocalSide(2),
                                    ds3LocalLoopbackRemoteSide(3),
                                    ds3RemoteLoopbackLocalSide(4),
                                    ds3RemoteLoopbackRemoteSide(5)
                                }
                        ACCESS  read-only
                        STATUS  deprecated
                        DESCRIPTION
                                "This variable represents the loopback state of
                                the device.  Agents supporting read/write access
                                should return badValue in response to a requested
                                loopback state that the device does not support.  The
                                values mean:

                                  ds3NoLoop
                                     Not in the loopback state.  A device that is
                                     not capable of performing a loopback on
                                     either interface shall always return this as
                                     it's value.






          T. A. Cox and K. Tesink (editors)                    [Page 13]





          Internet Draft           DS3 Objects                  May 1992


                                  ds3LocalLoopbackLocalSide
                                     Signal received from the local side of the
                                     device is looped back at the local connector
                                     (eg, without involving the device).

                                  ds3LocalLoopbackRemoteSide
                                     Signal received from the local side of the
                                     device is looped back at the remote connector
                                     (eg, through the device).

                                  ds3RemoteLoopbackLocalSide
                                     Signal received from the remote side of the
                                     device is looped back at the local connector
                                     (eg, through the device).

                                  ds3RemoteLoopbackRemoteSide
                                     Signal received from the remote side of the
                                     device is looped back at the remote connector
                                     (eg, without involving the device).

                                Note that M23 and ClearChannel interfaces do not
                                support the Loopback managed object."
                        ::= { ds3ConfigEntry 7 }

                ds3SendCode OBJECT-TYPE
                        SYNTAX  INTEGER {
                                    ds3SendTestMessage(1),
                                    ds3SendNoCode(2),
                                    ds3SendSetCode(3),
                                    ds3SendLoopbackCode(4),
                                    ds3SendResetCode(5)
                                }
                        ACCESS  read-only
                        STATUS  mandatory
                        DESCRIPTION
                                "This variable indicates what type of code is
                                being sent across the DS3 interface by the device.  The
                                values mean:

                                  ds3SendNoCode
                                     sending looped or normal data

                                  ds3SendSetCode
                                     sending a loopback request






          T. A. Cox and K. Tesink (editors)                    [Page 14]





          Internet Draft           DS3 Objects                  May 1992


                                  ds3SendLoopbackCode
                                     sending a loopback test code/pattern

                                  ds3SendResetCode
                                     sending a loopback termination request

                                  ds3SendTestMessage
                                     sending a Test pattern as defined in
                                     T1.107a-1990."
                        ::= { ds3ConfigEntry 8 }

          ds3YellowAlarm OBJECT-TYPE
              SYNTAX  INTEGER {
                          ds3YellowAlarm(1),
                          ds3NoYellowAlarm(2)
                      }
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "This variable indicates if a Yellow Alarm
                      condition exists."
              ::= { ds3ConfigEntry 9 }

          ds3RedAlarm OBJECT-TYPE
              SYNTAX  INTEGER {
                          ds3RedAlarm(1),
                          ds3NoRedAlarm(2)
                      }
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "This variable indicates if a Red Alarm condition
                      exists."
              ::= { ds3ConfigEntry 10 }

          ds3CircuitIdentifier OBJECT-TYPE
              SYNTAX  DisplayString (SIZE (0..255))
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "This variable contains the transmission vendor's
                      circuit identifier, for the purpose of
                      facilitating troubleshooting."
              ::= { ds3ConfigEntry 11 }






          T. A. Cox and K. Tesink (editors)                    [Page 15]





          Internet Draft           DS3 Objects                  May 1992


                 ds3LoopbackConfig OBJECT-TYPE
                           SYNTAX  INTEGER {
                                       ds3NoLoop(1),
                                       ds3MgrPayloadLoop(2),
                                       ds3MgrLineLoop(3),
                                       ds3NetReqPayloadLoop(4),
                                       ds3NetReqLineLoop(5),
                                       ds3OtherLoop(6)
                                   }
                           ACCESS  read-only
                           STATUS  mandatory
                           DESCRIPTION
                                   "This variable represents the loopback configuration of
                                   the DS3 interface.  Agents supporting read/write
                                   access should return badValue in response to a
                                   requested loopback state that the interface does not support.
                                   The values mean:

                                         ds3NoLoop

                                           Not in the loopback state.  A device that is
                                           not capable of performing a loopback on
                                           the interface shall always return this as
                                           it's value.


                                         ds3MgrPayloadLoop

                                           The received signal at this interface is looped through
                                           the device; this loopback is initiated by a
                                           manager of the device. Typically the received signal
                                           is looped back for retransmission after it has
                                           passed through the device's framing function.

                                         ds3MgrLineLoop

                                           The received signal at this interface does not
                                           go through the device (minimum penetration) but
                                           is looped back out; this loopback is initiated
                                           by a manager of the device.

                                         ds3NetReqPayloadLoop

                                           The received signal at this interface is looped through
                                           the device; this loopback is initiated/requested by the





          T. A. Cox and K. Tesink (editors)                    [Page 16]





          Internet Draft           DS3 Objects                  May 1992


                                           far end equipment. Typically the received signal
                                           is looped back for retransmission after it has
                                           passed through the device's framing function.

                                         ds3NetReqLineLoop

                                           The received signal at this interface does not
                                           go through the device (minimum penetration) but
                                           is looped back out; this loopback is initiated/requested
                                           by the far end equipment.

                                         ds3OtherLoop

                                           Loopbacks that are not defined here.

                                   Note that M23 and ClearChannel interfaces do not
                                   support the Loopback managed object."
                           ::= { ds3ConfigEntry 12 }

                    ds3LineStatus OBJECT-TYPE
                        SYNTAX  INTEGER {
                                    ds3NoAlarm(1),
                                    ds3FarEndAlarm(2),
                                    ds3AlarmIndicationSignal(3),
                                    ds3LossOfFrame(4),
                                    ds3LossOfSignal(5),
                                    ds3LoopbackState(6)
                                }
                        ACCESS  read-only
                        STATUS  mandatory
                        DESCRIPTION
                              "This variable indicates the
                              Line Status of the interface.
                              It contains loopback state information
                              and alarm state information.
                              If multiple alarm states are occurring
                              simultaneously, then the highest
                              priority alarm state is the one set.  From
                              highest to lowest the alarm state priorities are
                              the following:  ds3LossOfSignal, ds3LossOfFrame,
                              ds3AlarmIndicationSignal, and ds3FarEndAlarm."
                        ::= { ds3ConfigEntry 13 }








          T. A. Cox and K. Tesink (editors)                    [Page 17]





          Internet Draft           DS3 Objects                  May 1992


          -- the DS3 Interval

          -- The DS3 Interval Table contains various statistics
          -- collected by each DS3 Interface over the previous 24 hours of
          -- operation.  The past 24 hours are broken into 96 completed
          -- 15 minute intervals.
          -- This table has been deprecated and replaced by ds3GgIntervalTable.

          ds3IntervalTable OBJECT-TYPE
              SYNTAX  SEQUENCE OF DS3IntervalEntry
              ACCESS  not-accessible
              STATUS  deprecated
              DESCRIPTION
                      "The DS3 Interval table."
              ::= { ds3 2 }

          ds3IntervalEntry OBJECT-TYPE
              SYNTAX  DS3IntervalEntry
              ACCESS  not-accessible
              STATUS  deprecated
              DESCRIPTION
                      "An entry in the DS3 Interval table."
              INDEX   { ds3IntervalIndex, ds3IntervalNumber }
              ::= { ds3IntervalTable 1 }

          DS3IntervalEntry ::=
              SEQUENCE {
                  ds3IntervalIndex
                      INTEGER,
                  ds3IntervalNumber
                      INTEGER,
                  ds3IntervalESs
                      Counter,
                  ds3IntervalSESs
                      Counter,
                  ds3IntervalSEFSs
                      Counter,
                  ds3IntervalUASs
                      Counter,
                  ds3IntervalCSSs
                      Counter,
                  ds3IntervalBPVs
                      Counter,
                  ds3IntervalCVs
                      Counter





          T. A. Cox and K. Tesink (editors)                    [Page 18]





          Internet Draft           DS3 Objects                  May 1992


              }

          ds3IntervalIndex OBJECT-TYPE
              SYNTAX  INTEGER (1..65535)
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "The index value which uniquely identifies the DS3
                      interface to which this entry is applicable.  The
                      interface identified by a particular value of this
                      index is the same interface as identified by the
                      same value an DS3LineIndex object instance."
              ::= { ds3IntervalEntry 1 }

          ds3IntervalNumber OBJECT-TYPE
              SYNTAX  INTEGER (1..96)
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "A number between 1 and 96, where 1 is the most
                      recently completed 15 minute interval and 96 is
                      the least recently completed 15 minutes interval
                      (assuming that all 96 intervals are valid)."
              ::= { ds3IntervalEntry 2 }

          ds3IntervalESs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "The counter associated with the number of Errored
                      Seconds, encountered by a DS3 interface in one of
                      the previous 96, individual 15 minute, intervals."
              ::= { ds3IntervalEntry 3 }

          ds3IntervalSESs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "The counter associated with the number of
                      Severely Errored Seconds, encountered by a DS3
                      interface in one of the previous 96, individual 15
                      minute, intervals."
              ::= { ds3IntervalEntry 4 }





          T. A. Cox and K. Tesink (editors)                    [Page 19]





          Internet Draft           DS3 Objects                  May 1992


          ds3IntervalSEFSs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "The counter associated with the number of
                      Severely Errored Framing Seconds, encountered by a
                      DS3 interface in one of the previous 96,
                      individual 15 minute, intervals."
              ::= { ds3IntervalEntry 5 }

          ds3IntervalUASs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "The counter associated with the number of
                      Unavailable Seconds, encountered by a DS3
                      interface in one of the previous 96, individual 15
                      minute, intervals."
              ::= { ds3IntervalEntry 6 }

          ds3IntervalCSSs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "The counter associated with the number of
                      Controlled Slip Seconds, encountered by a DS3
                      interface in one of the previous 96, individual 15
                      minute, intervals.  Note that SYNTRAN interfaces
                      are the only interfaces that support the
                      Controlled Slip Seconds managed object.
                      Accordingly, agents configured with non-SYNTRAN
                      interfaces may treat this object as having an
                      ACCESS clause value of not-accessible."
              ::= { ds3IntervalEntry 7 }

          ds3IntervalBPVs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "The counter associated with the number of Bipolar
                      Violations, encountered by a DS3 interface in one





          T. A. Cox and K. Tesink (editors)                    [Page 20]





          Internet Draft           DS3 Objects                  May 1992


                      of the previous 96, individual 15 minute,
                      intervals."
              ::= { ds3IntervalEntry 8 }

          ds3IntervalCVs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "The counter associated with the number of Coding
                      Violations, encountered by a DS3 interface in one
                      of the previous 96, individual 15 minute,
                      intervals."
              ::= { ds3IntervalEntry 9 }




































          T. A. Cox and K. Tesink (editors)                    [Page 21]





          Internet Draft           DS3 Objects                  May 1992


          -- the DS3 Current

          -- The DS3 current table contains various statistics being
          -- collected for the current 15 minute interval.

          ds3CurrentTable OBJECT-TYPE
              SYNTAX  SEQUENCE OF DS3CurrentEntry
              ACCESS  not-accessible
              STATUS  mandatory
              DESCRIPTION
                      "The DS3 Current table."
              ::= { ds3 3 }

          ds3CurrentEntry OBJECT-TYPE
              SYNTAX  DS3CurrentEntry
              ACCESS  not-accessible
              STATUS  mandatory
              DESCRIPTION
                      "An entry in the DS3 Current table."
              INDEX   { ds3CurrentIndex }
              ::= { ds3CurrentTable 1 }

          DS3CurrentEntry ::=
              SEQUENCE {
                  ds3CurrentIndex
                      INTEGER,
                  ds3CurrentESs
                      Counter,
                  ds3CurrentSESs
                      Counter,
                  ds3CurrentSEFSs
                      Counter,
                  ds3CurrentUASs
                      Counter,
                  ds3CurrentCSSs
                      Counter,
                  ds3CurrentBPVs
                      Counter,
                  ds3CurrentCVs
                      Counter
              }

          ds3CurrentIndex OBJECT-TYPE
              SYNTAX  INTEGER (1..65535)
              ACCESS  read-only





          T. A. Cox and K. Tesink (editors)                    [Page 22]





          Internet Draft           DS3 Objects                  May 1992


              STATUS  mandatory
              DESCRIPTION
                      "The index value which uniquely identifies the DS3
                      interface to which this entry is applicable.  The
                      interface identified by a particular value of this
                      index is the same interface as identified by the
                      same value an DS3LineIndex object instance."
              ::= { ds3CurrentEntry 1 }

          ds3CurrentESs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Errored
                      Seconds, encountered by a DS3 interface in the
                      current 15 minute interval."
              ::= { ds3CurrentEntry 2 }

          ds3CurrentSESs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of
                      Severely Errored Seconds, encountered by a DS3
                      interface in the current 15 minute interval."
              ::= { ds3CurrentEntry 3 }

          ds3CurrentSEFSs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of
                      Severely Errored Framing Seconds, encountered by a
                      DS3 interface in the current 15 minute interval."
              ::= { ds3CurrentEntry 4 }

          ds3CurrentUASs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of





          T. A. Cox and K. Tesink (editors)                    [Page 23]





          Internet Draft           DS3 Objects                  May 1992


                      Unavailable Seconds, encountered by a DS3
                      interface in the current 15 minute interval."
              ::= { ds3CurrentEntry 5 }

          ds3CurrentCSSs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "The counter associated with the number of
                      Controlled Slip Seconds, encountered by a DS3
                      interface in the current 15 minute interval.  Note
                      that SYNTRAN interfaces are the only interfaces
                      that support the Controlled Slip Seconds managed
                      object.  Accordingly, agents configured with non-
                      SYNTRAN interfaces may treat this object as having
                      an ACCESS clause value of not-accessible."
              ::= { ds3CurrentEntry 6 }

          ds3CurrentBPVs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Bipolar
                      Violations, encountered by a DS3 interface in the
                      current 15 minute interval."
              ::= { ds3CurrentEntry 7 }

          ds3CurrentCVs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Coding
                      Violations, encountered by a DS3 interface in the
                      current 15 minute interval."
              ::= { ds3CurrentEntry 8 }












          T. A. Cox and K. Tesink (editors)                    [Page 24]





          Internet Draft           DS3 Objects                  May 1992


          -- the DS3 Total

          -- The DS3 Total Table contains the cumulative sum of the
          -- various statistics for the 24 hour interval preceding the
          -- first valid interval in the DS3CurrentTable.
          -- This table has been deprecated and replaced by ds3GgTotalTable.

          ds3TotalTable OBJECT-TYPE
              SYNTAX  SEQUENCE OF DS3TotalEntry
              ACCESS  not-accessible
              STATUS  deprecated
              DESCRIPTION
                      "The DS3 Total table.  24 hour interval."
              ::= { ds3 4 }

          ds3TotalEntry OBJECT-TYPE
              SYNTAX  DS3TotalEntry
              ACCESS  not-accessible
              STATUS  deprecated
              DESCRIPTION
                      "An entry in the DS3 Total table."
              INDEX   { ds3TotalIndex }
              ::= { ds3TotalTable 1 }

          DS3TotalEntry ::=
              SEQUENCE {
                  ds3TotalIndex
                      INTEGER,
                  ds3TotalESs
                      Counter,
                  ds3TotalSESs
                      Counter,
                  ds3TotalSEFSs
                      Counter,
                  ds3TotalUASs
                      Counter,
                  ds3TotalCSSs
                      Counter,
                  ds3TotalBPVs
                      Counter,
                  ds3TotalCVs
                      Counter
              }

          ds3TotalIndex OBJECT-TYPE





          T. A. Cox and K. Tesink (editors)                    [Page 25]





          Internet Draft           DS3 Objects                  May 1992


              SYNTAX  INTEGER (1..65535)
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "The index value which uniquely identifies the DS3
                      interface to which this entry is applicable.  The
                      interface identified by a particular value of this
                      index is the same interface as identified by the
                      same value an DS3LineIndex object instance."
              ::= { ds3TotalEntry 1 }

          ds3TotalESs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "The counter associated with the number of Errored
                      Seconds, encountered by a DS3 interface in the
                      previous 24 hour interval"
              ::= { ds3TotalEntry 2 }

          ds3TotalSESs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "The counter associated with the number of
                      Severely Errored Seconds, encountered by a DS3
                      interface in the previous 24 hour interval."
              ::= { ds3TotalEntry 3 }

          ds3TotalSEFSs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "The counter associated with the number of
                      Severely Errored Framing Seconds, encountered by a
                      DS3 interface in the previous 24 hour interval."
              ::= { ds3TotalEntry 4 }

          ds3TotalUASs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  deprecated





          T. A. Cox and K. Tesink (editors)                    [Page 26]





          Internet Draft           DS3 Objects                  May 1992


              DESCRIPTION
                      "The counter associated with the number of
                      Unavailable Seconds, encountered by a DS3
                      interface in the previous 24 hour interval."
              ::= { ds3TotalEntry 5 }

          ds3TotalCSSs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "The counter associated with the number of
                      Controlled Slip Seconds, encountered by a DS3
                      interface in the previous 24 hour interval.  Note
                      that SYNTRAN interfaces are the only interfaces
                      that support the Controlled Slip Seconds managed
                      object.  Accordingly, agents configured with non-
                      SYNTRAN interfaces may treat this object as having
                      an ACCESS clause value of not-accessible."
              ::= { ds3TotalEntry 6 }

          ds3TotalBPVs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "The counter associated with the number of Bipolar
                      Violations, encountered by a DS3 interface in the
                      previous 24 hour interval."
              ::= { ds3TotalEntry 7 }

          ds3TotalCVs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "The counter associated with the number of Coding
                      Violations, encountered by a DS3 interface in the
                      previous 24 hour interval."
              ::= { ds3TotalEntry 8 }










          T. A. Cox and K. Tesink (editors)                    [Page 27]





          Internet Draft           DS3 Objects                  May 1992


          -- the DS3 Gauge Interval

          -- The DS3 Gauge Interval Table contains various statistics
          -- collected by each DS3 Interface over the previous 24 hours of
          -- operation.  The past 24 hours are broken into 96 completed
          -- 15 minute intervals.

          ds3GgIntervalTable OBJECT-TYPE
              SYNTAX  SEQUENCE OF DS3GgIntervalEntry
              ACCESS  not-accessible
              STATUS  mandatory
              DESCRIPTION
                      "The DS3 Gauge Interval table."
              ::= { ds3 5 }

          ds3GgIntervalEntry OBJECT-TYPE
              SYNTAX  DS3GgIntervalEntry
              ACCESS  not-accessible
              STATUS  mandatory
              DESCRIPTION
                      "An entry in the DS3 Gauge Interval table."
              INDEX   { ds3GgIntervalIndex, ds3GgIntervalNumber }
              ::= { ds3GgIntervalTable 1 }

          DS3GgIntervalEntry ::=
              SEQUENCE {
                  ds3GgIntervalIndex
                      INTEGER,
                  ds3GgIntervalNumber
                      INTEGER,
                  ds3GgIntervalESs
                      Gauge,
                  ds3GgIntervalSESs
                      Gauge,
                  ds3GgIntervalSEFSs
                      Gauge,
                  ds3GgIntervalUASs
                      Gauge,
                  ds3GgIntervalCSSs
                      Gauge,
                  ds3GgIntervalBPVs
                      Gauge,
                  ds3GgIntervalCVs
                      Gauge
              }





          T. A. Cox and K. Tesink (editors)                    [Page 28]





          Internet Draft           DS3 Objects                  May 1992


          ds3GgIntervalIndex OBJECT-TYPE
              SYNTAX  INTEGER (1..65535)
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The index value which uniquely identifies the DS3
                      interface to which this entry is applicable.  The
                      interface identified by a particular value of this
                      index is the same interface as identified by the
                      same value an DS3LineIndex object instance."
              ::= { ds3GgIntervalEntry 1 }

          ds3GgIntervalNumber OBJECT-TYPE
              SYNTAX  INTEGER (1..96)
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "A number between 1 and 96, where 1 is the most
                      recently completed 15 minute interval and 96 is
                      the least recently completed 15 minutes interval
                      (assuming that all 96 intervals are valid)."
              ::= { ds3GgIntervalEntry 2 }

          ds3GgIntervalESs OBJECT-TYPE
              SYNTAX  Gauge (0..4294967295)
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Errored
                      Seconds, encountered by a DS3 interface in one of
                      the previous 96, individual 15 minute, intervals."
              ::= { ds3GgIntervalEntry 3 }

          ds3GgIntervalSESs OBJECT-TYPE
              SYNTAX  Gauge (0..4294967295)
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of
                      Severely Errored Seconds, encountered by a DS3
                      interface in one of the previous 96, individual 15
                      minute, intervals."
              ::= { ds3GgIntervalEntry 4 }

          ds3GgIntervalSEFSs OBJECT-TYPE





          T. A. Cox and K. Tesink (editors)                    [Page 29]





          Internet Draft           DS3 Objects                  May 1992


              SYNTAX  Gauge (0..4294967295)
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of
                      Severely Errored Framing Seconds, encountered by a
                      DS3 interface in one of the previous 96,
                      individual 15 minute, intervals."
              ::= { ds3GgIntervalEntry 5 }

          ds3GgIntervalUASs OBJECT-TYPE
              SYNTAX  Gauge (0..4294967295)
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of
                      Unavailable Seconds, encountered by a DS3
                      interface in one of the previous 96, individual 15
                      minute, intervals."
              ::= { ds3GgIntervalEntry 6 }

          ds3GgIntervalCSSs OBJECT-TYPE
              SYNTAX  Gauge (0..4294967295)
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of
                      Controlled Slip Seconds, encountered by a DS3
                      interface in one of the previous 96, individual 15
                      minute, intervals.  Note that SYNTRAN interfaces
                      are the only interfaces that support the
                      Controlled Slip Seconds managed object.
                      Accordingly, agents configured with non-SYNTRAN
                      interfaces may treat this object as having an
                      ACCESS clause value of not-accessible."
              ::= { ds3GgIntervalEntry 7 }

          ds3GgIntervalBPVs OBJECT-TYPE
              SYNTAX  Gauge (0..4294967295)
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Bipolar
                      Violations, encountered by a DS3 interface in one
                      of the previous 96, individual 15 minute,





          T. A. Cox and K. Tesink (editors)                    [Page 30]





          Internet Draft           DS3 Objects                  May 1992


                      intervals."
              ::= { ds3GgIntervalEntry 8 }

          ds3GgIntervalCVs OBJECT-TYPE
              SYNTAX  Gauge (0..4294967295)
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Coding
                      Violations, encountered by a DS3 interface in one
                      of the previous 96, individual 15 minute,
                      intervals."
              ::= { ds3GgIntervalEntry 9 }





































          T. A. Cox and K. Tesink (editors)                    [Page 31]





          Internet Draft           DS3 Objects                  May 1992


          -- the DS3 Gauge Total

          -- The DS3 Gauge Total Table contains the cumulative sum of the
          -- various statistics for the 24 hour interval preceding the
          -- first valid interval in the DS3CurrentTable.

          ds3GgTotalTable OBJECT-TYPE
              SYNTAX  SEQUENCE OF DS3GgTotalEntry
              ACCESS  not-accessible
              STATUS  mandatory
              DESCRIPTION
                      "The DS3 Gauge Total table.  24 hour interval."
              ::= { ds3 6 }

          ds3GgTotalEntry OBJECT-TYPE
              SYNTAX  DS3GgTotalEntry
              ACCESS  not-accessible
              STATUS  mandatory
              DESCRIPTION
                      "An entry in the DS3 Gauge Total table."
              INDEX   { ds3GgTotalIndex }
              ::= { ds3GgTotalTable 1 }

          DS3GgTotalEntry ::=
              SEQUENCE {
                  ds3GgTotalIndex
                      INTEGER,
                  ds3GgTotalESs
                      Gauge,
                  ds3GgTotalSESs
                      Gauge,
                  ds3GgTotalSEFSs
                      Gauge,
                  ds3GgTotalUASs
                      Gauge,
                  ds3GgTotalCSSs
                      Gauge,
                  ds3GgTotalBPVs
                      Gauge,
                  ds3GgTotalCVs
                      Gauge
              }

          ds3GgTotalIndex OBJECT-TYPE
              SYNTAX  INTEGER (1..65535)





          T. A. Cox and K. Tesink (editors)                    [Page 32]





          Internet Draft           DS3 Objects                  May 1992


              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The index value which uniquely identifies the DS3
                      interface to which this entry is applicable.  The
                      interface identified by a particular value of this
                      index is the same interface as identified by the
                      same value an DS3LineIndex object instance."
              ::= { ds3GgTotalEntry 1 }

          ds3GgTotalESs OBJECT-TYPE
              SYNTAX  Gauge (0..4294967295)
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Errored
                      Seconds, encountered by a DS3 interface in the
                      previous 24 hour interval"
              ::= { ds3GgTotalEntry 2 }

          ds3GgTotalSESs OBJECT-TYPE
              SYNTAX  Gauge (0..4294967295)
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of
                      Severely Errored Seconds, encountered by a DS3
                      interface in the previous 24 hour interval."
              ::= { ds3GgTotalEntry 3 }

          ds3GgTotalSEFSs OBJECT-TYPE
              SYNTAX  Gauge (0..4294967295)
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of
                      Severely Errored Framing Seconds, encountered by a
                      DS3 interface in the previous 24 hour interval."
              ::= { ds3GgTotalEntry 4 }

          ds3GgTotalUASs OBJECT-TYPE
              SYNTAX  Gauge (0..4294967295)
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION





          T. A. Cox and K. Tesink (editors)                    [Page 33]





          Internet Draft           DS3 Objects                  May 1992


                      "The counter associated with the number of
                      Unavailable Seconds, encountered by a DS3
                      interface in the previous 24 hour interval."
              ::= { ds3GgTotalEntry 5 }

          ds3GgTotalCSSs OBJECT-TYPE
              SYNTAX  Gauge (0..4294967295)
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of
                      Controlled Slip Seconds, encountered by a DS3
                      interface in the previous 24 hour interval.  Note
                      that SYNTRAN interfaces are the only interfaces
                      that support the Controlled Slip Seconds managed
                      object.  Accordingly, agents configured with non-
                      SYNTRAN interfaces may treat this object as having
                      an ACCESS clause value of not-accessible."
              ::= { ds3GgTotalEntry 6 }

          ds3GgTotalBPVs OBJECT-TYPE
              SYNTAX  Gauge (0..4294967295)
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Bipolar
                      Violations, encountered by a DS3 interface in the
                      previous 24 hour interval."
              ::= { ds3GgTotalEntry 7 }

          ds3GgTotalCVs OBJECT-TYPE
              SYNTAX  Gauge (0..4294967295)
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Coding
                      Violations, encountered by a DS3 interface in the
                      previous 24 hour interval."
              ::= { ds3GgTotalEntry 8 }











          T. A. Cox and K. Tesink (editors)                    [Page 34]





          Internet Draft           DS3 Objects                  May 1992


          -- The DS3 Far End Group

          -- Implementation of this group is optional for all systems
          -- that attach to a DS3 Interface.

          -- The DS3 Far End Group consists of four tables:
          --   DS3 Far End Configuration
          --   DS3 Far End Current
          --   DS3 Far End Gauge Interval
          --   DS3 Far End Gauge Total


          -- The DS3 Far End Configuration
          -- Only C-bit Parity applications
          -- can provide this information.

          -- The DS3 Far End Configuration Table contains
          -- configuration information
          -- reported in the C-bits from the remote end.

                       ds3FarEndConfigTable OBJECT-TYPE
                            SYNTAX  SEQUENCE OF DS3FarEndConfigEntry
                            ACCESS  not-accessible
                            STATUS  optional
                            DESCRIPTION
                                    "The DS3 Far End Configuration table."
                           ::= { ds3 7 }

                       ds3FarEndConfigEntry OBJECT-TYPE
                           SYNTAX  DS3FarEndConfigEntry
                           ACCESS  not-accessible
                           STATUS  optional
                           DESCRIPTION
                                   "An entry in the DS3 Far End Configuration table."
                           INDEX   { ds3FarEndLineIndex }
                           ::= { ds3FarEndConfigTable 1 }

                       DS3FarEndConfigEntry ::=
                           SEQUENCE {
                               ds3FarEndLineIndex
                                   INTEGER,
                               ds3FarEndEquipCode
                                   DisplayString,
                               ds3FarEndLocationIDCode
                                   DisplayString,





          T. A. Cox and K. Tesink (editors)                    [Page 35]





          Internet Draft           DS3 Objects                  May 1992


                               ds3FarEndFrameIDCode
                                   DisplayString,
                               ds3FarEndUnitCode
                                   DisplayString,
                               ds3FarEndFacilityIDCode
                                   DisplayString
                       }

                    ds3FarEndLineIndex OBJECT-TYPE
                           SYNTAX  INTEGER (1..65535)
                           ACCESS  read-only
                           STATUS  optional
                           DESCRIPTION
                                "The index value which uniquely identifies the
                                DS3 interface
                                to which this entry is applicable.  The
                                interface identified by a particular value of
                                this index is the same interface as identified
                                by the same value an DS3LineIndex object
                                instance."
                          ::= { ds3FarEndConfigEntry 1 }

                    ds3FarEndEquipCode OBJECT-TYPE
                        SYNTAX  DisplayString (SIZE (0..10))
                        ACCESS  read-write
                        STATUS  optional
                        DESCRIPTION
                              "This is the Far End Equipment Identification code
                              that describes the specific piece of equipment.
                              It is sent within the Path
                              Identification Message."
                        ::= { ds3FarEndConfigEntry 2 }

                    ds3FarEndLocationIDCode OBJECT-TYPE
                        SYNTAX  DisplayString (SIZE (0..11))
                        ACCESS  read-write
                        STATUS  optional
                        DESCRIPTION
                              "This is the Far End Location Identification code
                              that describes the specific location of the equipment.
                              It is sent within the Path
                              Identification Message."
                        ::= { ds3FarEndConfigEntry 3 }

                    ds3FarEndFrameIDCode OBJECT-TYPE





          T. A. Cox and K. Tesink (editors)                    [Page 36]





          Internet Draft           DS3 Objects                  May 1992


                        SYNTAX  DisplayString (SIZE (0..10))
                        ACCESS  read-write
                        STATUS  optional
                        DESCRIPTION
                              "This is the Far End Frame Identification code
                              that identifies where the equipment is located
                              within a building at a given location.
                              It is sent within the Path
                              Identification Message."
                        ::= { ds3FarEndConfigEntry 4 }

                    ds3FarEndUnitCode OBJECT-TYPE
                        SYNTAX  DisplayString (SIZE (0..6))
                        ACCESS  read-write
                        STATUS  optional
                        DESCRIPTION
                              "This is the Far End code
                              that identifies the equipment location within a bay.
                              It is sent within the Path
                              Identification Message."
                        ::= { ds3FarEndConfigEntry 5 }

                    ds3FarEndFacilityIDCode OBJECT-TYPE
                        SYNTAX  DisplayString (SIZE (0..38))
                        ACCESS  read-write
                        STATUS  optional
                        DESCRIPTION
                              "This code identifies a specific Far End DS3 path.
                              It is sent within the Path
                              Identification Message."
                        ::= { ds3FarEndConfigEntry 6 }



















          T. A. Cox and K. Tesink (editors)                    [Page 37]





          Internet Draft           DS3 Objects                  May 1992


          -- The DS3 Far End Current

          -- Only C-bit Parity Applications and SYNTRAN applications
          -- can provide this information.

          -- The DS3 Far End Current table contains various statistics being
          -- collected for the current 15 minute interval.
          -- The statistics are collected from the far end block error code
          -- within the C-bits.  The definitions are the same as described for
          -- the near-end information.

                    ds3FarEndCurrentTable OBJECT-TYPE
                        SYNTAX  SEQUENCE OF DS3FarEndCurrentEntry
                        ACCESS  not-accessible
                        STATUS  mandatory
                        DESCRIPTION
                                "The DS3 Far End Current table."
                        ::= { ds3 8 }

                    ds3FarEndCurrentEntry OBJECT-TYPE
                        SYNTAX  DS3FarEndCurrentEntry
                        ACCESS  not-accessible
                        STATUS  mandatory
                        DESCRIPTION
                                "An entry in the DS3 Far End Current table."
                        INDEX   { ds3FarEndCurrentIndex }
                        ::= { ds3FarEndCurrentTable 1 }

                    DS3FarEndCurrentEntry ::=
                        SEQUENCE {
                            ds3FarEndCurrentIndex
                                INTEGER,
                            ds3FarEndCurrentESs
                                Counter,
                            ds3FarEndCurrentSESs
                                Counter,
                            ds3FarEndCurrentCVs
                                Counter
                        }

                     ds3FarEndCurrentIndex OBJECT-TYPE
                        SYNTAX  INTEGER (1..65535)
                        ACCESS  read-only
                        STATUS  mandatory
                        DESCRIPTION





          T. A. Cox and K. Tesink (editors)                    [Page 38]





          Internet Draft           DS3 Objects                  May 1992


                                "The index value which uniquely identifies the
                                DS3 interface
                                to which this entry is applicable.  The interface
                                identified by a particular value of this index is
                                the same interface as identified by the same value
                                an DS3LineIndex object instance."
                        ::= { ds3FarEndCurrentEntry 1 }

                    ds3FarEndCurrentESs OBJECT-TYPE
                        SYNTAX  Counter
                        ACCESS  read-only
                        STATUS  mandatory
                        DESCRIPTION
                                "The counter associated with the number of Far
                                Far End Errored Seconds encountered by a DS3
                                interface in the current 15 minute interval."
                        ::= { ds3FarEndCurrentEntry 2 }

                    ds3FarEndCurrentSESs OBJECT-TYPE
                        SYNTAX  Counter
                        ACCESS  read-only
                        STATUS  mandatory
                        DESCRIPTION
                                "The counter associated with the number of
                                Far End Severely Errored Seconds
                                encountered by a DS3 interface in the current 15 minute
                                interval."
                        ::= { ds3FarEndCurrentEntry 3 }

                    ds3FarEndCurrentCVs OBJECT-TYPE
                        SYNTAX  Counter
                        ACCESS  read-only
                        STATUS  mandatory
                        DESCRIPTION
                                "The counter associated with the number of
                                Far End Coding Violations reported via
                                the far end block error count
                                encountered by a
                                DS3 interface in the current 15 minute interval."
                        ::= { ds3FarEndCurrentEntry 4 }










          T. A. Cox and K. Tesink (editors)                    [Page 39]





          Internet Draft           DS3 Objects                  May 1992


          -- The DS3 Far End Gauge Interval

          -- Only C-bit Parity Applications and SYNTRAN applications
          -- can provide this information.

          -- The DS3 Far End Gauge Interval Table contains various statistics
          -- collected by each DS3 interface over the previous 24 hours of
          -- operation.  The past 24 hours are broken into 96
          -- completed 15 minute intervals.

                    ds3FarEndGgIntervalTable OBJECT-TYPE
                        SYNTAX  SEQUENCE OF DS3FarEndGgIntervalEntry
                        ACCESS  not-accessible
                        STATUS  mandatory
                        DESCRIPTION
                               "The DS3 Far End Gauge Interval table."
                        ::= { ds3 9 }

                    ds3FarEndGgIntervalEntry OBJECT-TYPE
                        SYNTAX  DS3FarEndGgIntervalEntry
                        ACCESS  not-accessible
                        STATUS  mandatory
                        DESCRIPTION
                              "An entry in the DS3 Far
                              End Gauge Interval table."
                        INDEX   { ds3FarEndGgIntervalIndex, ds3FarEndGgIntervalNumber }
                        ::= { ds3FarEndGgIntervalTable 1 }

                    DS3FarEndGgIntervalEntry ::=
                        SEQUENCE {
                             ds3FarEndGgIntervalIndex
                                  INTEGER,
                             ds3FarEndGgIntervalNumber
                                  INTEGER,
                             ds3FarEndGgIntervalESs
                                  Gauge,
                             ds3FarEndGgIntervalSESs
                                  Gauge,
                             ds3FarEndGgIntervalCVs
                                  Gauge
                        }

                    ds3FarEndGgIntervalIndex OBJECT-TYPE
                        SYNTAX  INTEGER (1..65535)
                        ACCESS  read-only





          T. A. Cox and K. Tesink (editors)                    [Page 40]





          Internet Draft           DS3 Objects                  May 1992


                        STATUS  mandatory
                        DESCRIPTION
                                "The index value which uniquely identifies the
                                DS3 interface
                                to which this entry is applicable.  The
                                interface identified by a particular value of
                                this index is the same interface as identified
                                by the same value an DS3LineIndex object
                                instance."
                        ::= { ds3FarEndGgIntervalEntry 1 }

                   ds3FarEndGgIntervalNumber OBJECT-TYPE
                       SYNTAX  INTEGER (1..96)
                       ACCESS  read-only
                       STATUS  mandatory
                       DESCRIPTION
                              "A number between 1 and 96, where 1 is the most
                              recently completed 15 minute interval and 96 is
                              the least recently completed 15 minutes
                              interval (assuming that all 96 intervals are
                              valid)."
                       ::= { ds3FarEndGgIntervalEntry 2 }

                   ds3FarEndGgIntervalESs OBJECT-TYPE
                       SYNTAX  Gauge (0..4294967295)
                       ACCESS  read-only
                       STATUS  mandatory
                       DESCRIPTION
                               "The counter associated with the number of
                               Far End Errored Seconds encountered
                               by a DS3 interface in one of the previous 96,
                               individual 15 minute, intervals."
                      ::= { ds3FarEndGgIntervalEntry 3 }

                   ds3FarEndGgIntervalSESs OBJECT-TYPE
                       SYNTAX  Gauge (0..4294967295)
                       ACCESS  read-only
                       STATUS  mandatory
                       DESCRIPTION
                               "The counter associated with the number of
                               Far End Severely Errored Seconds
                               encountered by a DS3 interface in one of the previous
                               96, individual 15 minute, intervals."
                      ::= { ds3FarEndGgIntervalEntry 4 }






          T. A. Cox and K. Tesink (editors)                    [Page 41]





          Internet Draft           DS3 Objects                  May 1992


                    ds3FarEndGgIntervalCVs OBJECT-TYPE
                        SYNTAX  Gauge (0..4294967295)
                        ACCESS  read-only
                        STATUS  mandatory
                        DESCRIPTION
                                "The counter associated with the number of
                                Far End Coding Violations reported via
                                the far end block error count
                                encountered by a
                                DS3 interface in one of the previous 96, individual 15
                                minute, intervals."
                        ::= { ds3FarEndGgIntervalEntry 5 }






































          T. A. Cox and K. Tesink (editors)                    [Page 42]





          Internet Draft           DS3 Objects                  May 1992


          -- The DS3 Far End Gauge Total

          -- Only C-bit Parity Applications and SYNTRAN applications
          -- can provide this information.

          -- The DS3 Far End Gauge Total Table contains the cumulative sum of the
          -- various statistics for the 24 hour interval preceding the
          -- first valid interval in the DS3FarEndCurrentTable.

                    ds3FarEndGgTotalTable OBJECT-TYPE
                        SYNTAX  SEQUENCE OF DS3FarEndGgTotalEntry
                        ACCESS  not-accessible
                        STATUS  mandatory
                        DESCRIPTION
                                "The DS3 Far End Gauge Total table.  24 hour interval."
                        ::= { ds3 10 }

                    ds3FarEndGgTotalEntry OBJECT-TYPE
                        SYNTAX  DS3FarEndGgTotalEntry
                        ACCESS  not-accessible
                        STATUS  mandatory
                        DESCRIPTION
                                "An entry in the DS3 Far End Gauge Total table."
                        INDEX   { ds3FarEndGgTotalIndex }
                        ::= { ds3FarEndGgTotalTable 1 }

                    DS3FarEndGgTotalEntry ::=
                        SEQUENCE {
                            ds3FarEndGgTotalIndex
                                INTEGER,
                            ds3FarEndGgTotalESs
                                Gauge,
                            ds3FarEndGgTotalSESs
                                Gauge,
                            ds3FarEndGgTotalCVs
                                Gauge
                        }

                    ds3FarEndGgTotalIndex OBJECT-TYPE
                        SYNTAX  INTEGER (1..65535)
                        ACCESS  read-only
                        STATUS  mandatory
                        DESCRIPTION
                                "The index value which uniquely identifies the
                                DS3 interface





          T. A. Cox and K. Tesink (editors)                    [Page 43]





          Internet Draft           DS3 Objects                  May 1992


                                to which this entry is applicable.  The interface
                                identified by a particular value of this index is
                                the same interface as identified by the same value
                                an DS3LineIndex object instance."
                        ::= { ds3FarEndGgTotalEntry 1 }

                   ds3FarEndGgTotalESs OBJECT-TYPE
                       SYNTAX  Gauge (0..4294967295)
                       ACCESS  read-only
                       STATUS  mandatory
                       DESCRIPTION
                               "The counter associated with the number of Far
                               End Errored Seconds encountered by a DS3
                               interface in the previous 24 hour interval."
                       ::= { ds3FarEndGgTotalEntry 2 }

                   ds3FarEndGgTotalSESs OBJECT-TYPE
                       SYNTAX  Gauge (0..4294967295)
                       ACCESS  read-only
                       STATUS  mandatory
                       DESCRIPTION
                               "The counter associated with the number of
                               Far End Severely Errored Seconds
                               encountered by a DS3 interface in the previous 24 hour
                               interval."
                       ::= { ds3FarEndGgTotalEntry 3 }

                   ds3FarEndGgTotalCVs OBJECT-TYPE
                       SYNTAX  Gauge (0..4294967295)
                       ACCESS  read-only
                       STATUS  mandatory
                       DESCRIPTION
                               "The counter associated with the number of
                               Far End Coding Violations reported via the
                               far end block error count
                               encountered by a
                               DS3 interface in the previous 24 hour interval."
                       ::= { ds3FarEndGgTotalEntry 4 }



          END








          T. A. Cox and K. Tesink (editors)                    [Page 44]





          Internet Draft           DS3 Objects                  May 1992


          7.  Acknowledgments

          This document was produced by the SNMP and the Trunk MIB
          Working Groups:

                              Anne Ambler, Spider
                              Karl Auerbach, Sun
                              Fred Baker, ACC
                              Ken Brinkerhoff
                              Ron Broersma, NOSC
                              Jack Brown, US Army
                              Theodore Brunner, Bellcore
                              Jeffrey Buffum, HP
                              Jeffrey D. Case, UTK
                              Chris Chiptasso, Spartacus
                              Paul Ciarfella, DEC
                              Bob Collet
                              Tracy Cox, Bellcore
                              James R. Davin, MIT-LCS
                              Kurt Dobbins, Cabletron
                              Nadya El-Afandi, Network Systems
                              Gary Ellis, HP
                              Fred Engle
                              Mike Erlinger
                              Richard Fox, Synoptics
                              Karen Frisa, CMU
                              Chris Gunner, DEC
                              Ken Hibbard, Xylogics
                              Ole Jacobsen, Interop
                              Ken Jones
                              Satish Joshi, Synoptics
                              Frank Kastenholz, Racal-Interlan
                              Shimshon Kaufman, Spartacus
                              Jim Kinder, Fibercom
                              Alex Koifman, BBN
                              Christopher Kolb, PSI
                              Cheryl Krupczak, NCR
                              Peter Lin, Vitalink
                              John Lunny, TWG
                              Carl Malamud
                              Keith McCloghrie, HLS
                              Donna McMaster, David Systems
                              Lynn Monsanto, Sun
                              Dave Perkins, 3COM
                              Jim Reinstedler, Ungerman Bass





          T. A. Cox and K. Tesink (editors)                    [Page 45]





          Internet Draft           DS3 Objects                  May 1992


                              Anil Rijsinghani, DEC
                              Kary Robertson
                              Marshall T. Rose, PSI (chair)
                              L. Michael Sabo, NCSC
                              Jon Saperia, DEC
                              John Seligson
                              Fei Shu, NEC
                              Sam Sjogren, TGV
                              Mark Sleeper, Sparta
                              Lance Sprung
                              Mike St.Johns
                              Bob Stewart, Xyplex
                              Emil Sturniold
                              Kaj Tesink, Bellcore
                              Dean Throop, Data General
                              Bill Townsend, Xylogics
                              Maurice Turcotte
                              Kannan Varadhou
                              Sudhanshu Verma, HP
                              Warren Vik, Interactive Systems
                              David Waitzman, BBN
                              Steve Waldbusser, CMU
                              Dan Wintringhan
                              David Wood
                              Jeff Young, Cray Research

























          T. A. Cox and K. Tesink (editors)                    [Page 46]





          Internet Draft           DS3 Objects                  May 1992


          8.  References

             [1] Cerf, V., "IAB Recommendations for the Development of Internet
                 Network Management Standards", RFC 1052, NRI, April 1988.

             [2] Cerf, V., "Report of the Second Ad Hoc Network Management Review
                 Group", RFC 1109, NRI, August 1989.

             [3] Rose M., and K. McCloghrie, "Structure and Identification of
                 Management Information for TCP/IP-based internets", RFC 1155,
                 Performance Systems International, Hughes LAN Systems, May 1990.

             [4] 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.

             [5] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
                 Network Management Protocol", RFC 1157, SNMP Research,
                 Performance Systems International, Performance Systems
                 International, MIT Laboratory for Computer Science, May 1990.

             [6] McCloghrie K., and M. Rose, Editors, "Management Information Base
                 for Network Management of TCP/IP-based internets", RFC 1213,
                 Performance Systems International, March 1991.

             [7] Information processing systems - Open Systems Interconnection -
                 Specification of Abstract Syntax Notation One (ASN.1),
                 International Organization for Standardization, International
                 Standard 8824, December 1987.

             [8] 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.

             [9] American National Standard for telecommunications - digital
                 hierarchy - electrical interfaces, ANSI T1.102- 1987.

            [10] American National Standard for telecommunications - digital
                 hierarchy - formats specification, ANSI T1.107- 1988.

            [10a] ANSI T1.107a-1990.

            [11] American National Standard for telecommunications - Carrier-to-
                 Customer Installation - DS3 Metallic Interface, ANSI T1.404-1989.





          T. A. Cox and K. Tesink (editors)                    [Page 47]





          Internet Draft           DS3 Objects                  May 1992


            [12] In-Service Digital Transmission Performance Monitoring Draft
                 Standard, T1M1.3/92-005.

            [13] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions",
                 RFC 1212, Performance Systems International, Hughes LAN Systems,
                 March 1991.












































          T. A. Cox and K. Tesink (editors)                    [Page 48]





          Internet Draft           DS3 Objects                  May 1992


          9.  Security Considerations

          Security issues are not discussed in this memo.


          10.  Authors' Addresses

             Tracy A. Cox
             Bell Communications Research
             331 Newman Springs Road
             P.O. Box 7020
             Red Bank, NJ  07701-7020

             Phone: (908) 758-2107

             EMail: tacox@sabre.bellcore.com


             Kaj Tesink
             Bell Communications Research
             331 Newman Springs Road
             P.O. Box 7020
             Red Bank, NJ  07701-7020

             Phone: (908) 758-5254

             EMail: kaj@nvuxr.cc.bellcore.com























          T. A. Cox and K. Tesink (editors)                    [Page 49]





          Internet Draft           DS3 Objects                  May 1992


          Table of Contents


          1 Status of this Memo ...................................    1
          2 Abstract ..............................................    1
          3 The Network Management Framework ......................    2
          4 Objects ...............................................    3
          4.1 Format of Definitions ...............................    3
          4.2 Changes from RFC1233 ................................    3
          5 Overview ..............................................    5
          5.1 Binding between ifIndex and DS3 Interfaces ..........    5
          5.2 Objectives of this MIB Module .......................    5
          5.3 DS3 Terminology .....................................    5
          6 Object Definitions ....................................    9
          6.1 The DS3 Near End Group ..............................   10
          6.1.1 The DS3 Configuration .............................   10
          6.1.2 The DS3 Interval ..................................   18
          6.1.3 The DS3 Current ...................................   22
          6.1.4 The DS3 Total .....................................   25
          6.1.5 The DS3 Gauge Interval ............................   28
          6.1.6 The DS3 Gauge Total ...............................   32
          6.2 The DS3 Far End Group ...............................   35
          6.2.1 The DS3 Far End Configuration .....................   35
          6.2.2 The DS3 Far End Current ...........................   38
          6.2.3 The DS3 Far End Gauge Interval ....................   40
          6.2.4 The DS3 Far End Gauge Total .......................   43
          7 Acknowledgments .......................................   45
          8 References ............................................   47
          9 Security Considerations ...............................   49
          10 Authors' Addresses ...................................   49




















          T. A. Cox and K. Tesink (editors)                    [Page 50]











Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa04200;
          5 May 92 20:29 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa20234;
          5 May 92 20:35 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa20220; 5 May 92 20:34 EDT
Received: from mace.LCS.MIT.EDU by fennel.acc.com (4.1/SMI-4.1)
	id AA11334; Tue, 5 May 92 17:20:56 PDT
Received: from MACE.LCS.MIT.EDU by mace.LCS.MIT.EDU via TCP with SMTP
	id AA01672; Tue, 5 May 92 20:20:38 EDT
Message-Id: <9205060020.AA01672@mace.LCS.MIT.EDU>
From: "James R. (Chuck) Davin" <jrd@thyme.lcs.mit.edu>
To: Tracy Cox <tacox@sabre.bellcore.com>
Cc: trunk-mib@acc.com
Subject: Re: DS3 MIB 
In-Reply-To: Your message of Mon, 04 May 92 08:49:51 -0400.
             <9205041249.AA06847@ginsu4> 
Date: Tue, 05 May 92 20:20:35 -0400
Sender: jrd@mace.lcs.mit.edu


Tracy and Kaj,

Attached are some comments on the DS3 MIB. I actually formulated these
comments while reading the previous draft (April 92) --- not the
latest one. But I have hastily revised the references to refer to your
latest text (May 92). Thus, while I haven't yet read the newest text
in great detail, I have been through it enough to align my old
comments with the new text.

Regards,
Chuck


General Comments:

1. Section 5.2 claims that the MIB is designed to facilitate common
management of both "in-chassis and external" devices. This distinction
(between "in-chassis" and "external") is not particularly fundamental,
nor is it clearly a distinction that ought to be modelled in the MIB.
On one hand, queries of a DS3 MIB object are satisfied locally
"in-chassis," and, on the other hand, such queries may be satisfied by
a proxy interaction (via SNMP or some proprietary protocol) with the
"external" device. But by the transparency principle on which proxy
operations are premised, this distinction should be invisible to a
manager.

Perhaps a more interesting distinction (perhaps more deserving of
representation in the MIB design) is the distinction between DS3
DSU/CSU devices that are "used" by the managed system and those which
are not.  One case is exemplified by normal managed systems to which
DS3 lines have been attached; the other case is exemplified by a PC
Clone attached to an Ethernet that retrofits SNMP management into some
collection of CSU/DSUs that have nothing whatever to do with that PC.
A hybrid case involves both "attached" and "unattached" DS3
interfaces.

Is the MIB supposed to support the first case? The second case? The
hybrid case? Although support for the second case (and the hybrid
case) benefits implementors seeking to retrofit management into
existing systems, it is not clear that it is at all sensible in a more
global context. Does it ever make sense to manage disembodied DS3
devices that have no discernible association with any upper layer
function? It would be nice to have a clear statement of which of these
three cases the MIB is designed to support (perhaps in section 5.1).

If the hybrid case is not being addressed, then it is not clear that
there is a need for the ds3IfIndex object.

Specific Comments:

1. Page 5:

          5.1.  Binding between ifIndex and DS3 Interfaces

          Each agent which resides on a host which uses DS3 interfaces
          is required to assign a small, non-negative integer uniquely
          to each DS3 Interface.

Agents do not always reside on "hosts."

What does it mean that a host "uses DS3 interfaces"? Consider the case
of an agent that exports DS3-related MIB variables that instrument
DSU/CSU devices that do not support any of the communications to or
from the system on which that agent resides. In this case, the
relevant "host" would not be "using" a DS3 interface. Does this
circumstance obviate the need for unique values of ds3LineIndex?

	  This is known as the "LineIndex", and

	  This integer is known as the "LineIndex" and

          is used to distinguish between different DS3 interfaces
          attached to a node.

Some of them may not be "attached to the node" at all.

	  The LineIndex is also used as the `key'
          when accessing tabular information about DS3 interfaces.  If
          there is at least one ifEntry directly associated with the DS3
          interface (e.g., if the DS3 interface is used to communicate
          with the Network Layer), it should have the same value as
          ifIndex.  Otherwise, its value should exceed ifNumber.

The referent of the pronouns "it" and "its" in the above sentence is
not clear.

While there is nothing intrinsically wrong with the clause "If there
is at least one ifEntry directly associated with the DS3 interface,"
it is not clear when there would ever be more than one ifEntry
directly associated with a DS3 interface (without mediation by some
multiplexor function).

          The ds3IfIndex column of the DS3 Configuration table relates
          each DS3 interface to its corresponding interface (ifIndex) in
          the Internet-standard MIB (MIB-II RFC1213).

Do you want to say here that the nature of this relationship is that
the value of an instance of the ds3IfIndex object is the same as the
corresponding instance of the ifIndex object?

2. Page 9:


                              mib-2 OBJECT IDENTIFIER ::= { mgmt 1 }
                              transmission OBJECT IDENTIFIER ::= { mib-2 10 }
                              ds3 OBJECT IDENTIFIER ::= { transmission 30 }


The first two of these definitions are defined elsewhere and should be
imported; they should not be redefined in this document.

3. Page 11:

            ds3LineIndex OBJECT-TYPE
                 SYNTAX  INTEGER (1..65535)
                 ACCESS  read-only
                 STATUS  mandatory
                 DESCRIPTION
                         "This object is the identifier of a DS3
                         Interface on a device.  If there is at least
                         one ifEntry directly associated with the DS3
                         interface (e.g., if the DS3 interface is used
                         to communicate with the Network Layer), it
                         should have the same value as ifIndex.
                         Otherwise, its value should exceed ifNumber."
                ::= { ds3ConfigEntry 1 }


The use of "device" in the first sentence could be clarifed. Does
"device" mean "the system on which the managed agent resides"? But
this definition does not cover case (2) in the general comments above.
Is the ds3LineIndex object a numbering of all the DS3 interfaces for
which a particular managed agent may be responsible?

If there is more than one ifEntry directly associated with a
particular DS3 interface (not sure how that happens, but . .), then
the relevant ds3LineIndex instance cannot be equal to all of the
relevant (distinct) instances of ifIndex. How is this paradox
resolved?


4. Page 17:

                 ds3LoopbackConfig OBJECT-TYPE
                           SYNTAX  INTEGER {
                                       ds3NoLoop(1),
                                       ds3MgrPayloadLoop(2),
                                       ds3MgrLineLoop(3),
                                       ds3NetReqPayloadLoop(4),
                                       ds3NetReqLineLoop(5),
                                       ds3OtherLoop(6)
                                   }
                           ACCESS  read-only
                           STATUS  mandatory
                           DESCRIPTION
                                   "This variable represents the loopback configuration of
                                   the DS3 interface.  Agents supporting read/write
                                   access should return badValue in response to a
                                   requested loopback state that the interface does not support.
                                   The values mean:

                                         ds3NoLoop

			[ text omitted ]
                                         ds3OtherLoop

                                           Loopbacks that are not defined here.

                                   Note that M23 and ClearChannel interfaces do not
                                   support the Loopback managed object."
                           ::= { ds3ConfigEntry 12 }

The last sentence in the description is odd. If, implementation of
certain MIB objects is not required under certain conditions, then
these objects should be relegated to distinct MIB groups, and the
conformance status of those groups should be stated.

If the last sentence is rather intended to mean that M23 and
ClearChannel interfaces are not instrumented by this MIB, perhaps this
point could be made in more general terms earlier in the document.

This odd phrasing is also present in the ds3Loopback object, but this
has now been deprecated.


5. Page 17:
                    ds3LineStatus OBJECT-TYPE
                        SYNTAX  INTEGER {
                                    ds3NoAlarm(1),
                                    ds3FarEndAlarm(2),
                                    ds3AlarmIndicationSignal(3),
                                    ds3LossOfFrame(4),
                                    ds3LossOfSignal(5),
                                    ds3LoopbackState(6)
                                }
                        ACCESS  read-only
                        STATUS  mandatory
                        DESCRIPTION
                              "This variable indicates the
                              Line Status of the interface.
                              It contains loopback state information
                              and alarm state information.
                              If multiple alarm states are occurring
                              simultaneously, then the highest
                              priority alarm state is the one set.  From
                              highest to lowest the alarm state priorities are
                              the following:  ds3LossOfSignal, ds3LossOfFrame,
                              ds3AlarmIndicationSignal, and ds3FarEndAlarm."
                        ::= { ds3ConfigEntry 13 }


Is it implicit in this definition that, when the line status of an
interface is ds2LoopbackState, no alarm states can be (need be?)
represented?

6. Page 29:

          ds3GgIntervalNumber OBJECT-TYPE
              SYNTAX  INTEGER (1..96)
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "A number between 1 and 96, where 1 is the most
                      recently completed 15 minute interval and 96 is
                      the least recently completed 15 minutes interval
                      (assuming that all 96 intervals are valid)."
              ::= { ds3GgIntervalEntry 2 }

The definition of this object suggests that every 15 minutes, at least
conceptually, all of the object instances in the ds3GgIntervalTable
are destroyed and replaced by newly instantiated object instances that
reflect the updated histories of the relevant interfaces. This
gratuitous, conceptual purging and rebirth are necessary to perserve
the property that a SNMP MIB object instance does not change its
semantics during its lifetime.

This same strategy was used in the now deprecated ds3IntervalTable. I
guess it is nominally kosher, but it is a bit unusual. Perhaps
additional text in the description or in some comments would keep the
unwary from misunderstandings of SNMP MIB objects that might arise
from this definition.

7. Page 30:

          ds3GgIntervalCSSs OBJECT-TYPE
              SYNTAX  Gauge (0..4294967295)
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of
                      Controlled Slip Seconds, encountered by a DS3
                      interface in one of the previous 96, individual 15
                      minute, intervals.  Note that SYNTRAN interfaces
                      are the only interfaces that support the
                      Controlled Slip Seconds managed object.
                      Accordingly, agents configured with non-SYNTRAN
                      interfaces may treat this object as having an
                      ACCESS clause value of not-accessible."
              ::= { ds3GgIntervalEntry 7 }

The last sentence is wrong. This object should be in another group if
it is not required of all implementations. Ditto for ds3GgTotalCSSs on
page 34.

8. Pages 35 and following:

Although the DS3 Far End group is Optional, it is not clear that the
STATUS for the objects within that group ought to be optional.
Conventional practice has been to label the objects within an Optional
group as "mandatory," on the premise that, if an implementor
implements the Optional group, he must implement all the objects in
that group.

Need to check on this.

9. Page 40:

          -- The DS3 Far End Gauge Interval

          -- Only C-bit Parity Applications and SYNTRAN applications
          -- can provide this information.

          -- The DS3 Far End Gauge Interval Table contains various statistics
          -- collected by each DS3 interface over the previous 24 hours of
          -- operation.  The past 24 hours are broken into 96
          -- completed 15 minute intervals.

Presumably this table will only ever be implemented systems having
C-bit Parity and SYNTRAN applications. But it is part of a much larger
Optional MIB group that may apply to a broader range of systems.

If the four tables in the Far End group can only be implemented by
certain classes of systems, then the groupings should reflect that.

If only certain kinds of systems can implement this table, is this
table also mandatory for that class of systems?
















Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa02140;
          6 May 92 10:11 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa19009;
          6 May 92 10:16 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa19005; 6 May 92 10:16 EDT
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA07488; Wed, 6 May 92 07:09:11 PDT
Return-Path: <kaj@sabre.bellcore.com@sabre.bellcore.com>
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA13788; Wed, 6 May 92 10:05:11 EDT
Received: by sword.bellcore.com;id 9205061407.AA07985
Message-Id: <9205061407.AA07985@sword.bellcore.com>
Date: Wed, 6 May 92 10:07:58 EDT
To: "James R. (Chuck) Davin" <jrd@thyme.lcs.mit.edu>
From: kaj@sabre.bellcore.com
Subject: Re: DS3 MIB
Cc: trunk-mib@acc.com, tacox@sabre.bellcore.com

wow, and all that just when i was having coffee&bagel.
allright, here my 1 penny
>
>General Comments:
>
>1. Section 5.2 claims that the MIB is designed to facilitate common
>management of both "in-chassis and external" devices. This distinction
>(between "in-chassis" and "external") is not particularly fundamental,
>nor is it clearly a distinction that ought to be modelled in the MIB.
>On one hand, queries of a DS3 MIB object are satisfied locally
>"in-chassis," and, on the other hand, such queries may be satisfied by
>a proxy interaction (via SNMP or some proprietary protocol) with the
>"external" device. But by the transparency principle on which proxy
>operations are premised, this distinction should be invisible to a
>manager.

the way i read it  is just a clarification that no case is excluded.
but if it is confusing we better take that part out. so it would read:

"The intent of this document is to facilitate the
 common management of all devices with DS3 interfaces."

There is a difference in the agent and proxy agent scenario though
that we need to describe (e.g., in 5.1).
>
>Perhaps a more interesting distinction (perhaps more deserving of
>representation in the MIB design) is the distinction between DS3
>DSU/CSU devices that are "used" by the managed system and those which
>are not.  One case is exemplified by normal managed systems to which
>DS3 lines have been attached; the other case is exemplified by a PC
>Clone attached to an Ethernet that retrofits SNMP management into some
>collection of CSU/DSUs that have nothing whatever to do with that PC.
>A hybrid case involves both "attached" and "unattached" DS3
>interfaces.
>
>Is the MIB supposed to support the first case? The second case? The
>hybrid case? Although support for the second case (and the hybrid
>case) benefits implementors seeking to retrofit management into
>existing systems, it is not clear that it is at all sensible in a more
>global context. Does it ever make sense to manage disembodied DS3
>devices that have no discernible association with any upper layer
>function? It would be nice to have a clear statement of which of these
>three cases the MIB is designed to support (perhaps in section 5.1).
>
>If the hybrid case is not being addressed, then it is not clear that
>there is a need for the ds3IfIndex object.

mmhh; not sure i get the scenario. but i do think we need some better
language to explain the difference between ifIndex, ds3IfIndex, and
ds3LineIndex,
explaining the scenarios that they represent. i'll dig up some old
mail on this subject for some improvement of 5.1.
>
>Specific Comments:
>
>1. Page 5:
>
>          5.1.  Binding between ifIndex and DS3 Interfaces
>
>          Each agent which resides on a host which uses DS3 interfaces
>          is required to assign a small, non-negative integer uniquely
>          to each DS3 Interface.
>
>Agents do not always reside on "hosts."

agreed. would
"Each agent which manages DS3 interfaces..."
be better?
>
>What does it mean that a host "uses DS3 interfaces"? Consider the case
>of an agent that exports DS3-related MIB variables that instrument
>DSU/CSU devices that do not support any of the communications to or
>from the system on which that agent resides. In this case, the
>relevant "host" would not be "using" a DS3 interface. Does this
>circumstance obviate the need for unique values of ds3LineIndex?
>
>	  This is known as the "LineIndex", and
>
>	  This integer is known as the "LineIndex" and
>
>          is used to distinguish between different DS3 interfaces
>          attached to a node.
>
>Some of them may not be "attached to the node" at all.
>
>	  The LineIndex is also used as the `key'
>          when accessing tabular information about DS3 interfaces.  If
>          there is at least one ifEntry directly associated with the DS3
>          interface (e.g., if the DS3 interface is used to communicate
>          with the Network Layer), it should have the same value as
>          ifIndex.  Otherwise, its value should exceed ifNumber.
>
>The referent of the pronouns "it" and "its" in the above sentence is
>not clear.
>
>While there is nothing intrinsically wrong with the clause "If there
>is at least one ifEntry directly associated with the DS3 interface,"
>it is not clear when there would ever be more than one ifEntry
>directly associated with a DS3 interface (without mediation by some
>multiplexor function).
>

what about
"	  The LineIndex (ds3LineIndex) is also used as the `key'
          when accessing tabular information about DS3 interfaces.  If
          there is an ifEntry directly associated with the DS3
          interface (e.g., if the DS3 interface is used to communicate
          with the Network Layer), ds3LineIndex should have the same value
as
          ifIndex.  Otherwise, the maximum value of ds3LineIndex
          should exceed ifNumber."

btw personally i'm still puzzled about the network layer sentence.

>          The ds3IfIndex column of the DS3 Configuration table relates
>          each DS3 interface to its corresponding interface (ifIndex) in
>          the Internet-standard MIB (MIB-II RFC1213).
>
>Do you want to say here that the nature of this relationship is that
>the value of an instance of the ds3IfIndex object is the same as the
>corresponding instance of the ifIndex object?

yes
>
>2. Page 9:
>
>
>                              mib-2 OBJECT IDENTIFIER ::= { mgmt 1 }
>                              transmission OBJECT IDENTIFIER ::= { mib-2 10 }
>                              ds3 OBJECT IDENTIFIER ::= { transmission 30 }
>
>
>The first two of these definitions are defined elsewhere and should be
>imported; they should not be redefined in this document.

agreed
>
>3. Page 11:
>
>            ds3LineIndex OBJECT-TYPE
>                 SYNTAX  INTEGER (1..65535)
>                 ACCESS  read-only
>                 STATUS  mandatory
>                 DESCRIPTION
>                         "This object is the identifier of a DS3
>                         Interface on a device.  If there is at least
>                         one ifEntry directly associated with the DS3
>                         interface (e.g., if the DS3 interface is used
>                         to communicate with the Network Layer), it
>                         should have the same value as ifIndex.
>                         Otherwise, its value should exceed ifNumber."
>                ::= { ds3ConfigEntry 1 }
>
>
>The use of "device" in the first sentence could be clarifed. Does
>"device" mean "the system on which the managed agent resides"? But
>this definition does not cover case (2) in the general comments above.
>Is the ds3LineIndex object a numbering of all the DS3 interfaces for
>which a particular managed agent may be responsible?

same improvements as above. also "device"-->"managed device"?
>
>If there is more than one ifEntry directly associated with a
>particular DS3 interface (not sure how that happens, but . .), then
>the relevant ds3LineIndex instance cannot be equal to all of the
>relevant (distinct) instances of ifIndex. How is this paradox
>resolved?

i my understanding of the mail a couple months ago, the situation
was that in the agent scenario ifIndex=ds3IfIndex=ds3LineIndex.
in the proxy scenario you have ifIndex=ds3IfIndex but you
may haver multiple instances of ds3LineIndex for each ds3IfIndex.
yes, we need better language. thats also why i proposed above to
clean up 5.1.
>
>
>4. Page 17:
>
>                 ds3LoopbackConfig OBJECT-TYPE
>                           SYNTAX  INTEGER {
>                                       ds3NoLoop(1),
>                                       ds3MgrPayloadLoop(2),
>                                       ds3MgrLineLoop(3),
>                                       ds3NetReqPayloadLoop(4),
>                                       ds3NetReqLineLoop(5),
>                                       ds3OtherLoop(6)
>                                   }
>                           ACCESS  read-only
>                           STATUS  mandatory
>                           DESCRIPTION
>                                   "This variable represents the loopback configuration of
>                                   the DS3 interface.  Agents supporting read/write
>                                   access should return badValue in response to a
>                                   requested loopback state that the interface does not support.
>                                   The values mean:
>
>                                         ds3NoLoop
>
>			[ text omitted ]
>                                         ds3OtherLoop
>
>                                           Loopbacks that are not defined here.
>
>                                   Note that M23 and ClearChannel interfaces do not
>                                   support the Loopback managed object."
>                           ::= { ds3ConfigEntry 12 }
>
>The last sentence in the description is odd. If, implementation of
>certain MIB objects is not required under certain conditions, then
>these objects should be relegated to distinct MIB groups, and the
>conformance status of those groups should be stated.
>
>If the last sentence is rather intended to mean that M23 and
>ClearChannel interfaces are not instrumented by this MIB, perhaps this
>point could be made in more general terms earlier in the document.
>
>This odd phrasing is also present in the ds3Loopback object, but this
>has now been deprecated.

but isnt this case covered by the value ds3NoLoop? or do you propose
to introduce a value loopbackNotSupported?
>
>
>5. Page 17:
>                    ds3LineStatus OBJECT-TYPE
>                        SYNTAX  INTEGER {
>                                    ds3NoAlarm(1),
>                                    ds3FarEndAlarm(2),
>                                    ds3AlarmIndicationSignal(3),
>                                    ds3LossOfFrame(4),
>                                    ds3LossOfSignal(5),
>                                    ds3LoopbackState(6)
>                                }
>                        ACCESS  read-only
>                        STATUS  mandatory
>                        DESCRIPTION
>                              "This variable indicates the
>                              Line Status of the interface.
>                              It contains loopback state information
>                              and alarm state information.
>                              If multiple alarm states are occurring
>                              simultaneously, then the highest
>                              priority alarm state is the one set.  From
>                              highest to lowest the alarm state priorities are
>                              the following:  ds3LossOfSignal, ds3LossOfFrame,
>                              ds3AlarmIndicationSignal, and ds3FarEndAlarm."
>                        ::= { ds3ConfigEntry 13 }
>
>
>Is it implicit in this definition that, when the line status of an
>interface is ds2LoopbackState, no alarm states can be (need be?)
>represented?

mmmmhhh?? tracy?

>
>6. Page 29:
>
>          ds3GgIntervalNumber OBJECT-TYPE
>              SYNTAX  INTEGER (1..96)
>              ACCESS  read-only
>              STATUS  mandatory
>              DESCRIPTION
>                      "A number between 1 and 96, where 1 is the most
>                      recently completed 15 minute interval and 96 is
>                      the least recently completed 15 minutes interval
>                      (assuming that all 96 intervals are valid)."
>              ::= { ds3GgIntervalEntry 2 }
>
>The definition of this object suggests that every 15 minutes, at least
>conceptually, all of the object instances in the ds3GgIntervalTable
>are destroyed and replaced by newly instantiated object instances that
>reflect the updated histories of the relevant interfaces. This
>gratuitous, conceptual purging and rebirth are necessary to perserve
>the property that a SNMP MIB object instance does not change its
>semantics during its lifetime.
>
>This same strategy was used in the now deprecated ds3IntervalTable. I
>guess it is nominally kosher, but it is a bit unusual. Perhaps
>additional text in the description or in some comments would keep the
>unwary from misunderstandings of SNMP MIB objects that might arise
>from this definition.

well, a logical result of sliding windows i guess. any particular
improvement in mind?
>
>7. Page 30:
>
>          ds3GgIntervalCSSs OBJECT-TYPE
>              SYNTAX  Gauge (0..4294967295)
>              ACCESS  read-only
>              STATUS  mandatory
>              DESCRIPTION
>                      "The counter associated with the number of
>                      Controlled Slip Seconds, encountered by a DS3
>                      interface in one of the previous 96, individual 15
>                      minute, intervals.  Note that SYNTRAN interfaces
>                      are the only interfaces that support the
>                      Controlled Slip Seconds managed object.
>                      Accordingly, agents configured with non-SYNTRAN
>                      interfaces may treat this object as having an
>                      ACCESS clause value of not-accessible."
>              ::= { ds3GgIntervalEntry 7 }
>
>The last sentence is wrong. This object should be in another group if
>it is not required of all implementations. Ditto for ds3GgTotalCSSs on
>page 34.

i agree it is wrong. but isnt it the case that for this case the value
of CSSs  is simply zero. we could have snetences saying that.
>
>8. Pages 35 and following:
>
>Although the DS3 Far End group is Optional, it is not clear that the
>STATUS for the objects within that group ought to be optional.
>Conventional practice has been to label the objects within an Optional
>group as "mandatory," on the premise that, if an implementor
>implements the Optional group, he must implement all the objects in
>that group.
>
>Need to check on this.

yes, i think you're right.
>
>9. Page 40:
>
>          -- The DS3 Far End Gauge Interval
>
>          -- Only C-bit Parity Applications and SYNTRAN applications
>          -- can provide this information.
>
>          -- The DS3 Far End Gauge Interval Table contains various statistics
>          -- collected by each DS3 interface over the previous 24 hours of
>          -- operation.  The past 24 hours are broken into 96
>          -- completed 15 minute intervals.
>
>Presumably this table will only ever be implemented systems having
>C-bit Parity and SYNTRAN applications. But it is part of a much larger
>Optional MIB group that may apply to a broader range of systems.
>
>If the four tables in the Far End group can only be implemented by
>certain classes of systems, then the groupings should reflect that.
>
>If only certain kinds of systems can implement this table, is this
>table also mandatory for that class of systems?

well, isnt the situation as it is described:

- it's your option to implement the far end group.
- if you implement the far end group you only implement
  the DS3 Far End Gauge Interval if you're
  C-bit Parity Applications or SYNTRAN
  

?

will look for the improvements of 5.1.
0------------0--------------0-------------0-------------0-----------0
Kaj Tesink                            vmail (908) 758-5254
pmail Bellcore                      faxmail (908) 758-4196
      331 Newman Springs Rd.          email kaj@nvuxr.cc.bellcore.com
      Red Bank, NJ 07701











Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa03663;
          6 May 92 14:55 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa06867;
          6 May 92 15:00 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa06858; 6 May 92 15:00 EDT
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA10227; Wed, 6 May 92 11:54:36 PDT
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA01421; Wed, 6 May 92 14:56:51 EDT
Return-Path: <tacox@sabre.bellcore.com>
Received: by ginsu4 (4.1/4.7)
	id AA07652; Wed, 6 May 92 14:51:07 EDT
Date: Wed, 6 May 92 14:51:07 EDT
From: Tracy Cox <tacox@sabre.bellcore.com>
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9205061851.AA07652@ginsu4>
To: trunk-mib@acc.com
Subject: counters in DS3 MIB

Gang,

I am updating the MIB based on Chuck's comments.

Kaj and I are coming up with words/pictures on the
ds3IfIndex vs. ds3LineIndex issue.

--> I will IMPORT mib-2 and transmission from RFC1213.

--> I have updated/corrected the text in ds3LoopbackConfig
description clause.  For M23 and ClearChannel applications,
they will always return ds3NoLoop.

--> I have add the following text to the ds3LineStatus object:

                    If the value for the ds3LineStatus object is equal
                    to the ds3LoopbackState and a
                    failure occurs, then the ds3LineStatus object value shall
                    identify the highest priority alarm.  (The loopback is thus
                    terminated until it is restarted.

--> ds3GgIntervalCSSs and ds3GgTotalCSSs should be deleted from the MIB, since
they are deprecated in the old tables -- there is no need to carry them forth
in a new table.

--> I added the following words to the beginning of the Far End Group:

-- Implementation of this group is optional for all systems
-- that attach to a DS3 Interface.
-- However, only C-bit Parity and SYNTRAN applications
-- have the capability (option) of providing this information.

--> The counters in the DS3 MIB (ds3CurrentTable)
are defined over a fixed length interval.
At the end of the interval they are reset to
zero and begin to count again.

This is the proposed text that I have added to the beginning
of the Current Table.

-- The DS3 current table contains various statistics being
-- collected for the current 15 minute interval.
-- Each 15 minute interval is measured in
-- seconds and is clocked by ds3TimeElapsed.
-- At the end of a 15 minute interval (ds3TimeElapsed = 900),
-- all the counters are reset
-- to zero and begin to count again.

This is the proposed text that I have added to the beginnuing
of the Gauge Interval Table.

-- The DS3 Gauge Interval Table contains various statistics
-- collected by each DS3 Interface over the previous 24 hours of
-- operation.  The past 24 hours are broken into 96 completed
-- 15 minute intervals.  Each 15 minute interval is measured in
-- seconds and is clocked by ds3TimeElapsed.

-- For example, at the end of a 15 minute interval (ds3TimeElapsed = 900),
-- ds3CurrentCVs.m becomes ds3GgIntervalCVs.m.1,
-- ds3GgIntervalCVs.m.n becomes ds3GgIntervalCVs.m.n+1 (for n 1 to 95), and
-- ds3GgIntervalCVs.m.96 is erased.

This is the prosposed at the beginning of the Gauge Total Table.

-- The DS3 Gauge Total Table contains the cumulative sum of the
-- various statistics for the 24 hour interval preceding the
-- first valid 15 minute interval in the DS3CurrentTable.
-- Each 15 minute interval is measured in
-- seconds and is clocked by ds3TimeElapsed.

-- The values of the objects in the
-- ds3GgTotalTable is the sum of the values of the objects of
-- the 96 15 minute intervals in
-- the ds3GgIntervalTable.

Tracy










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa04444;
          7 May 92 15:24 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa07565;
          7 May 92 15:29 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa07560; 7 May 92 15:29 EDT
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA21993; Thu, 7 May 92 12:20:40 PDT
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA10100; Thu, 7 May 92 15:22:56 EDT
Return-Path: <tacox@sabre.bellcore.com>
Received: by ginsu4 (4.1/4.7)
	id AA07899; Thu, 7 May 92 15:17:11 EDT
Date: Thu, 7 May 92 15:17:11 EDT
From: Tracy Cox <tacox@sabre.bellcore.com>
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9205071917.AA07899@ginsu4>
To: trunk-mib@acc.com
Subject: LineStatus with loopback

Gang,

I received feedback on the new wording for this object:

(see especially the words for the LoopbackState).

          ds3LineStatus OBJECT-TYPE
              SYNTAX  INTEGER {
                          ds3NoAlarm(1),
                          ds3FarEndAlarm(2),
                          ds3AlarmIndicationSignal(3),
                          ds3LossOfFrame(4),
                          ds3LossOfSignal(5),
                          ds3LoopbackState(6)
                      }
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                    "This variable indicates the
                    Line Status of the interface.
                    It contains loopback state information
                    and alarm state information.
                    If multiple alarm states are occurring
                    simultaneously, then the highest
                    priority alarm state is the one set.  From
                    highest to lowest the alarm state priorities are
                    the following:  ds3LossOfSignal, ds3LossOfFrame,
                    ds3AlarmIndicationSignal, and ds3FarEndAlarm.  If
                    the value for the ds3LineStatus object is equal
                    to the ds3LoopbackState and a
                    failure occurs, then the ds3LineStatus object value shall
                    identify the highest priority alarm.  (The loopback is thus
                    terminated until it is restarted.)"
              ::= { ds3ConfigEntry 13 }

When a failure is detected during a DS3 loopback, is the loopback terminated?
One vendor says no.  The loopback continues until it is deactivated.  

Therefore, is the ds3LoopbackState the highest priority LineState?  If this happens
then the NMS will not know when and if an incoming failure is detected during the loopback.
Is this an issue?  Remember that the loopback state is also reflected in the ds3LoopbackConfig
object. The ds3LineStatus object just provided one stop shopping for what the interface was doing.

It was suggested to remove the ds3LoopbackState from the the ds3LineStatus. (I agree)  The loopback
information is covered in another object, therefore, the NMS will know when failures occur
during the times when the DS3 interface is undergoing a loopback by polling two objects; one
object for alarm information and one object for loopback information.


Tracy










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id ab07163;
          11 May 92 11:33 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa25627;
          11 May 92 11:39 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa25620;
          11 May 92 11:39 EDT
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA05892; Mon, 11 May 92 08:29:52 PDT
Return-Path: <kaj@sabre.bellcore.com@sabre.bellcore.com>
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA07737; Mon, 11 May 92 11:32:02 EDT
Received: by sword.bellcore.com;id 9205090151.AA06515
Message-Id: <9205090151.AA06515@sword.bellcore.com>
Date: Fri, 8 May 92 21:51:18 EDT
To: trunk-mib@acc.com
From: kaj@sabre.bellcore.com
Subject: example of DS1 i/f bindings
Cc: kaj@sabre.bellcore.com, dmt@nvuxe.cc.bellcore.com

trunk-mib'ers,

here is the promised example of case of different bindings
between the ds1 indices and DS1 interfaces.
my suggestion is that we put it in the corresponding
explanatory text preceeding the actual mibs. if you like this,
a similar example can be made for the ds3 mib.

the example reflects our email of a couple months ago, with 
slight editorial changes.

any comments?

kaj
==========================


  Binding between ds1IfIndex, ds1LineIndex, and DS1 Interfaces


Different physical configurations for the support of SNMP
with DS1 equipment exist. To accommodate these scenarios,
two different indices for DS1 interfaces are introduced in this MIB.
These indices are ds1IfIndex and ds3LineIndex.

External interface scenario: the SNMP Agent represents all managed
DS1 lines as external interfaces (for example, an Agent residing on
the device supporting DS1 interfaces directly):

For this scenario, all interfaces are assigned an integer value
equal to ifIndex, and the following applies:

   ifIndex=ds1IfIndex=ds1LineIndex for all interfaces.

The ds1IfIndex column of the DS1 Configuration table relates
each DS1 interface to its corresponding interface (ifIndex) in
the Internet-standard MIB (MIB-II RFC1213).

External&Internal interface scenario: the SNMP Agents resides on
an host external from the device supporting DS1 interfaces (e.g.,
a router). The Agent represents both the host and the DS1 device.
The index ds1LineIndex is used to not only represent the
DS1 interfaces external from the host/DS1-device combination,
but also the DS1 interfaces connecting the host and the DS1 device.
The index ds1IfIndex only represents interfaces external to the
host/DS1-device combination.

Example:

A shelf full of CSUs connected to a Router. An SNMP Agent residing
on the router proxies for itself and the shelf. The router has also an
Ethernet interface:

|     +-----+	              	+-----------------------------+
|     |     |	              	|			                         	|
|E    |     |      1.536 BPS	|ds1 D4		Line#A	     	ds1 ESF	|
|t    |  R  |----------------+ - - - - - - - - - - - - - - +------>net
|h    |     |	              	|			                         	|
|e    |  O  |      1.536 BPS	|ds1 D4		Line#B	     	ds1 ESF	|
|r    |     |----------------+ - - - - - - - - - - - - - - +------>
|n    |  U  |	              	|			                         	|       
|e    |     |      1.536 BPS	|ds1 D4		Line#C	     	ds1 ESF	|
|t----|  T  |----------------+ - - - - - - - - - - - - - - +------>
|     |     |	              	|			                         	|
|     |  E  |      1.536 BPS	|ds1 D4		Line#D	     	ds1 ESF	|
|     |     |----------------+ - - - - - - - - - - - - - - +------>
|     |  R  |	              	|			                         	|
|     |     |        4 KBPS (not explicitly managed)		    	|
|     |     |----------------+        		                	 	|
|     |     |	              	|			                         	|
|     +-----+			             +-----------------------------+

The assignment of the index values could for example be:

	ifIndex	(= ds1IfIndex)	      ds1LineIndex
		1	     	NA                  NA (Ethernet)
		2      Line#A	Router Side	     	1
		2      Line#A	Network Side  	  	2
		3      Line#B Router Side       3
		3      Line#B	Network Side	    	4
		4      Line#C	Router Side	     	5
		4      Line#C	Network Side     	6
		5      Line#D Router Side	      7
		5      Line#D	Network Side	    	8

If the CSU shelf is managed by itself by a local SNMP Agent, 
the situation would be:

	ifIndex	(= ds1IfIndex)	      ds1LineIndex
		1      Line#A	RouterSide	      	1
		2      Line#A	Network Side   	 	2
		3      Line#B RouterSide	      	3
		4      Line#B	Network Side	    	4
		5      Line#C	Router Side    	  5
		6      Line#C	Network Side    		6
		7      Line#D Router Side	     	7
		8      Line#D	Network Side	    	8

0------------0--------------0-------------0-------------0-----------0
Kaj Tesink                            vmail (908) 758-5254
pmail Bellcore                      faxmail (908) 758-4196
      331 Newman Springs Rd.          email kaj@nvuxr.cc.bellcore.com
      Red Bank, NJ 07701











Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa25757;
          12 May 92 17:27 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa06023;
          12 May 92 17:33 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa06018;
          12 May 92 17:33 EDT
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA01622; Tue, 12 May 92 14:24:40 PDT
Return-Path: <kaj@sabre.bellcore.com@sabre.bellcore.com>
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA01232; Tue, 12 May 92 17:26:51 EDT
Received: by sword.bellcore.com;id 9205122128.AA02697
Message-Id: <9205122128.AA02697@sword.bellcore.com>
Date: Tue, 12 May 92 17:28:20 EDT
To: trunk-mib@acc.com
From: kaj@sabre.bellcore.com
Subject: T1/E1 and T3/E3

trunkers,

anybody out there who knows to what extent the ds1 and ds3
mibs really apply to E1 and E3 lines? i know the ds1 mib
claims commonality for T1 and E1 in section 4. how much?
and can we make a similar claim for E3/T3?

kaj
0------------0--------------0-------------0-------------0-----------0
Kaj Tesink                            vmail (908) 758-5254
pmail Bellcore                      faxmail (908) 758-4196
      331 Newman Springs Rd.          email kaj@nvuxr.cc.bellcore.com
      Red Bank, NJ 07701











Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa00653;
          14 May 92 9:01 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa03884;
          14 May 92 9:06 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa03880; 14 May 92 9:06 EDT
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA20189; Thu, 14 May 92 06:02:44 PDT
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA14465; Thu, 14 May 92 09:05:03 EDT
Return-Path: <tacox@ginsu4@sabre.bellcore.com>
Received: from localhost by ginsu4 (4.1/4.7)
	id AA12921; Thu, 14 May 92 08:59:16 EDT
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9205141259.AA12921@ginsu4>
To: Fred Baker <fbaker@acc.com>
Cc: trunk-mib@fennel.acc.com
Subject: Re: Boston IETF, July 13-17, 1992 
In-Reply-To: Your message of "Thu, 30 Apr 92 09:14:11 PDT."
             <9204301614.AA15149@saffron.acc.com> 
Date: Thu, 14 May 92 08:59:14 -0400
From: tacox@ginsu4.bellcore.com

> 
> 
> 
> Hi:
> 
> A precedural note:
> 
> Megan just dropped a note to the wgchairs list about her plans to start
> scheduling the Boston IETF.  One possibility (just that, at this point)
> is that meeting rooms may be available on Sunday July 12 to offload the
> week.
> 
> If so, is there interest in trying to have a meeting on Sunday?
> 
> Fred


who will be attending the next IETF and the trunk-mib wg?
Has anyone looked over the DS3 MIB?
Is everyone too busy before InteropEast?

I am going to wait until after interop to post the DS3 MIB in
the internet-drafts directory.  I will extend the review date of the DS3
MIB until June 7.

Tracy










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa00406;
          19 May 92 8:24 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa02201;
          19 May 92 8:30 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa02183; 19 May 92 8:30 EDT
Received: from relay.hp.com by fennel.acc.com (4.1/SMI-4.1)
	id AA27997; Tue, 19 May 92 00:36:21 PDT
Received: from hpbele01.brussels.hp.com by relay.hp.com with SMTP
	(16.6/15.5+IOS 3.13) id AA26922; Tue, 19 May 92 00:36:14 -0700
Received: by hpbele01.brussels.hp.com
	(16.6/15.5+IOS 3.22+OM) id AA23467; Tue, 19 May 92 09:31:10 +0200
From: #Emmanuel Ceulemans <ec@hpbele01.brussels.hp.com>
Message-Id: <9205190731.AA23467@hpbele01.brussels.hp.com>
Subject: Modem management and SNMP
To: trunk-mib@acc.com
Date: Tue, 19 May 92 9:31:08 METDST
Mailer: Elm [revision: 66.25]

I am investigating management solutions for modems using SNMP, therefore looking for all stuff related to modem MIBS, suppliers providing SNMP on their modems, Modem RFC status etc ...

Thank you for your help

Emmanuel Ceulemans
Hewlett Packard Belgium










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa01137;
          24 May 92 19:42 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa22739;
          24 May 92 19:49 EDT
Received: from [129.192.64.25] by NRI.Reston.VA.US id aa22725;
          24 May 92 19:49 EDT
Received: from nbkanata.Newbridge.COM (NEWBRIDGE.COM) by fennel.acc.com (4.1/SMI-4.1)
	id AA17958; Sun, 24 May 92 16:39:23 PDT
Received: from Newbridge.COM ([138.120.100.14]) by nbkanata.Newbridge.COM (4.1/SMI-4.1)
	id AA08038; Sun, 24 May 92 19:40:15 EDT
Received: from nbntwk. by Newbridge.COM (4.0/SMI-4.0)
	id AA25357; Sun, 24 May 92 19:38:19 EDT
Received: from mailux.UUCP by nbntwk. (4.0/SMI-4.0)
	id AA09158; Sun, 24 May 92 19:37:48 EDT
Received: from MAILCENTRE1 (QM 2.5.1) by mailux  (UMCP\QM 2.0.1)
 id AA00607; Sun, 24 May 1992 19:43:11 EST    
Message-Id: <00412.2789581391.607@mailux >
Organization: Newbridge Networks 600 March Road, Kanata Ontario, K2K2E6
X-Charset: MACINTOSH
X-Umcp-To: Tracy Cox
X-Umcp-Cc: Jonathan Bosloy, DS1/DS3 MIB List IETF
From: James Watt <James_Watt@newbridge.com>
To: DS1/DS3 MIB List IETF <trunk-mib@acc.com>
Date: Sun, 24 May 1992 19:33:55 EST    
Subject: Re: LineStatus with loopback 

Date	5/24/92
Subject	RE>LineStatus with loopback
From	James Watt
To	Tracy Cox
CC	Jonathan Bosloy, DS1/DS3 MIB List IETF

        Reply to:   RE>LineStatus with loopback
Tracy:
  We encountered this when building a management system for our products. 
The solution was to make (our equivalent of ) LineStatus  a bit-vector with
one bit per condition (like TOSType in the OSPF MIB).  Then loopback is just
another bit.  

The reasoning behind why this was the solution was something like:
a) sometimes you only want to know whether the interface is "in-service" or
"out-of-service".  Then just read the object and check for zero or non-zero.
 This avoids reading a second object to determine one piece of information
b) sometimes you want to know "why" the interface is "out-of-service".  Then
read the object and try to figure out what the bits mean
c) sometimes you want to add new conditions (yes, really !!).  Then just add
more bits and don't worry about breaking any priority encoding
d) it lets the clients (with their MBs of RAM and GBs of disk :->) worry
about the relationship between the various bits, instead of the agents

-james











Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa04767;
          2 Jun 92 20:48 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa11968;
          2 Jun 92 20:56 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa11961; 2 Jun 92 20:56 EDT
Received: from nbkanata.Newbridge.COM (NEWBRIDGE.COM) by fennel.acc.com (4.1/SMI-4.1)
	id AA09792; Tue, 2 Jun 92 17:50:48 PDT
Received: from Newbridge.COM ([138.120.100.14]) by nbkanata.Newbridge.COM (4.1/SMI-4.1)
	id AA13989; Tue, 2 Jun 92 20:51:51 EDT
Received: from nbntwk. by Newbridge.COM (4.0/SMI-4.0)
	id AA25169; Tue, 2 Jun 92 20:49:37 EDT
Received: from mailux.UUCP by nbntwk. (4.0/SMI-4.0)
	id AA00608; Tue, 2 Jun 92 20:49:12 EDT
Received: from MAILCENTRE1 (QM 2.5.1) by mailux  (UMCP\QM 2.0.1)
 id AA00754; Tue, 2 Jun 1992 20:54:43 EST    
Message-Id: <00412.2790363283.754@mailux >
Organization: Newbridge Networks 600 March Road, Kanata Ontario, K2K2E6
X-Charset: MACINTOSH
X-Umcp-To: Fred Baker, Tracy Cox
X-Umcp-Cc: DS1/DS3 MIB List IETF
From: James Watt <James_Watt@newbridge.com>
To: DS1/DS3 MIB List IETF <trunk-mib@acc.com>
Date: Tue, 2 Jun 1992 20:45:15 EST    
Subject: G.821 

Date	6/2/92
Subject	G.821
From	James Watt
To	Fred Baker, Tracy  Cox
CC	DS1/DS3 MIB List IETF

 Subject:                                                     Time:20:31
 G.821                                                        Date:6/2/92
Fred/Tracy:
  In the G.7XX world, they have a performance monitoring standard G.821
(yes, it has successors, numbered G.82X in the usual tradition, but I'll
ignore them for now...). 
  CCITT Recommendation G.821 details perforamnce objectives for 64 kbits/s
circuit-switched connections used for voice traffic or as "Bearer Channels"
for data-type services.  Most of terminology matches that of PUB 54016 with
one notable exception.  This is the concept of _degraded minutes_, defined
by G.821 to be a minute for which the BER exceeds 1E-6 but does not exceed
1E-3.
  To make the performance calculations described in G.821, one needs:
a) Total Seconds (in the evaluation period)
b) Unavailable Seconds (in the evaluation period) -- using the 54016 defn of
UASs
c) Errored Seconds (in the evaluation period) - using the 54016 defn of ESs
d) Severely Errored Seconds  (in the evaluation period) - using the 54016
defn of SESs
e) Degraded Minutes (in the evaluation period) (*) and

* - Degraded Minutes are determined by collection all of the available
seconds, minus the SESs into 60 second groups and counting 60 second group
as degraded if the cumulative errors in the 60 second group (aka minute)
exceed 1E-6

To make sense of this, you also need Available Seconds but that is just
Total Seconds - Unavailable Seconds.

As G.821 suggests that an evaluation period on the order of one month in
length is useful -- 32 bit counters should be fine.

Is there any reason why we should or shouldn't support G.821 as well as
T1M1.3 draft whatever ?

____________________________________________________________________________
James W. Watt,     jamesw@newbridge.com                  Ph:  (613) 591-3600
Newbridge Networks 600 March Rd Kanata ON Canada K2K 2E6 FAX: (613) 591-3680











Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa00920;
          3 Jun 92 8:44 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa08481;
          3 Jun 92 8:52 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa08466; 3 Jun 92 8:52 EDT
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA24908; Wed, 3 Jun 92 05:48:51 PDT
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA27463; Wed, 3 Jun 92 08:52:08 EDT
Return-Path: <tacox@ginsu4@sabre.bellcore.com>
Received: from localhost by ginsu4 (4.1/4.7)
	id AA15691; Wed, 3 Jun 92 08:45:28 EDT
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9206031245.AA15691@ginsu4>
To: James Watt <James_Watt@newbridge.com>
Cc: trunk-mib@acc.com
Subject: Re: G.821 
In-Reply-To: Your message of "Tue, 02 Jun 92 20:45:15 EST."
             <00412.2790363283.754@mailux > 
Date: Wed, 03 Jun 92 08:45:27 -0400
From: tacox@ginsu4.bellcore.com

James,

I will resist adding DM in the MIBs -- because
not all systems support DMs.  You have to support
all the objects in the table and cannot have optional
objects in a mandatory table.
At one time DMs were in the Bellcore TAs/TRs, but it
was removed for whatever reason -- I am not
sure if they were _ever_ defined in T1M1.
I prefer to keep the MIBs with a necessary subset of all
the counters that systems support.

Also, how would we in the existing MIB structure define
a 60 second group -- we only have ds*ElapsedTime which
counts the seconds elapsed in a 15-minute interval.
We would need a new counter.
We also have no notion of a day, month, week, ......
so an evaluation period really does not make sense in
our paradigm unless it is 15-minutes.

Tracy










Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa02436;
          3 Jun 92 11:44 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa16684;
          3 Jun 92 11:52 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa16675; 3 Jun 92 11:52 EDT
Received: from nbkanata.Newbridge.COM (NEWBRIDGE.COM) by fennel.acc.com (4.1/SMI-4.1)
	id AA25832; Wed, 3 Jun 92 08:44:25 PDT
Received: from Newbridge.COM ([138.120.100.14]) by nbkanata.Newbridge.COM (4.1/SMI-4.1)
	id AA19462; Wed, 3 Jun 92 11:27:44 EDT
Received: from nbntwk. by Newbridge.COM (4.0/SMI-4.0)
	id AA02620; Wed, 3 Jun 92 11:24:38 EDT
Received: from mailux.UUCP by nbntwk. (4.0/SMI-4.0)
	id AA02003; Wed, 3 Jun 92 11:24:14 EDT
Received: from MAILCENTRE1 (QM 2.5.1) by mailux  (UMCP\QM 2.0.1)
 id AA00763; Wed, 3 Jun 1992 11:29:57 EST    
Message-Id: <00412.2790415797.763@mailux >
Organization: Newbridge Networks 600 March Road, Kanata Ontario, K2K2E6
X-Charset: MACINTOSH
X-Umcp-To: tacox
X-Umcp-Cc: DS1/DS3 MIB List IETF
From: James Watt <James_Watt@newbridge.com>
To: DS1/DS3 MIB List IETF <trunk-mib@acc.com>
Date: Wed, 3 Jun 1992 11:22:59 EST    
Subject: Re: >G.821 

Date	6/3/92
Subject	RE>>G.821
From	James Watt
To	tacox
CC	DS1/DS3 MIB List IETF

        Reply to:   RE>>G.821
Tracy:
  With respect to 60-second groups, this is more of a conceptual mechanism
than the actual mechansim.  The only counters needed are the
TotalSecondsSinceReset, TotalUASsSinceReset, TotalESsSinceReset,
TotalSESsSinceReset and TotalDegradedMinutesSinceReset.  The Router/DSU does
the degraded minute calculation on the fly and just reports the results.
  These new counters are reasonably independent of the 15 minute counters --
they'd probably need their own table.
  In addition to inventing DegradedMinutes, G.821 has a table of objectives
(Table 1/G.821).  The idea is to take the information listed above, and see
whether the DMs, SESs and ESs are above or below the objectives.
  I do agree however, there is a bit of a problem putting table items in
which are not implemented by most systems.

-james
____________________________________________________________________________
James W. Watt,     jamesw@newbridge.com                  Ph:  (613) 591-3600
Newbridge Networks 600 March Rd Kanata ON Canada K2K 2E6 FAX: (613) 591-3680












Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa08045;
          25 Jun 92 19:49 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa08041;
          25 Jun 92 19:49 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa03654;
          25 Jun 92 19:50 EDT
Received: from saffron.acc.com by fennel.acc.com (4.1/SMI-4.1)
	id AA26208; Thu, 25 Jun 92 16:37:09 PDT
Received: by saffron.acc.com (4.1/SMI-4.1)
	id AA19827; Thu, 25 Jun 92 16:36:31 PDT
Date: Thu, 25 Jun 92 16:36:31 PDT
From: Fred Baker <fbaker@acc.com>
Message-Id: <9206252336.AA19827@saffron.acc.com>
To: trunk-mib@acc.com
Subject: DS1 MIB

I just sent a first cut of the MIB proper to the list.  It is largely
derived from Tracy's work (oh, heck, I just remembered the SYNTRAN stuff -
I forgot to edit the DS3 words out), and I have a bit of work ahead of me
to insert it into a pretty NROFF file.  Coming, coming. But we can work
with this text for the moment.

Fred










Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa08205;
          25 Jun 92 20:18 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa08201;
          25 Jun 92 20:18 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa04277;
          25 Jun 92 20:18 EDT
Received: from saffron.acc.com by fennel.acc.com (4.1/SMI-4.1)
	id AA26150; Thu, 25 Jun 92 16:31:52 PDT
Received: by saffron.acc.com (4.1/SMI-4.1)
	id AA19819; Thu, 25 Jun 92 16:31:15 PDT
Date: Thu, 25 Jun 92 16:31:15 PDT
From: Fred Baker <fbaker@acc.com>
Message-Id: <9206252331.AA19819@saffron.acc.com>
To: trunk-mib@fennel.acc.com
Subject: First cut DS1 MIB

RFCxxxx-MIB DEFINITIONS ::= BEGIN

               IMPORTS
                       Counter, Gauge
                               FROM RFC1155-SMI
                       transmission, DisplayString
                               FROM RFC1213-MIB
                       OBJECT-TYPE
                               FROM RFC-1212;

               --  This MIB module uses the extended OBJECT-TYPE macro as
               --  defined in RFC 1212.

               --  this is the MIB module for the ds1 objects


                              ds1 OBJECT IDENTIFIER ::= { transmission 18 }

               -- The DS1 Near End Group

               -- Implementation of this group is mandatory for all systems
               -- that attach to a ds1 Interface.

               -- The ds1 Near End Group consists of four tables:
               --    ds1 Configuration
               --    ds1 Current
               --    ds1 Gauge Interval
               --    ds1 Gauge Total

               -- the ds1 Configuration Table

               -- Although the objects in this table are read-only, at the
               -- agent's discretion they may be made read-write so that the
               -- management station, when appropriately authorized, may
               -- change the behavior of the interface, e.g., to place the interface
               -- into a loopback state.

               ds1ConfigTable OBJECT-TYPE
                   SYNTAX  SEQUENCE OF DS1ConfigEntry
                   ACCESS  not-accessible
                   STATUS  mandatory
                   DESCRIPTION
                           "The ds1 Configuration table."
                  ::= { ds1 1 }

              ds1ConfigEntry OBJECT-TYPE
                  SYNTAX  DS1ConfigEntry
                  ACCESS  not-accessible
                  STATUS  mandatory
                  DESCRIPTION
                          "An entry in the ds1 Configuration table."
                 INDEX   { ds1LineIndex }
                 ::= { ds1ConfigTable 1 }

            DS1ConfigEntry ::=
                 SEQUENCE {
                     ds1LineIndex
                         INTEGER,
                     ds1IfIndex
                         INTEGER,
                     ds1TimeElapsed
                         INTEGER,
                     ds1ValidIntervals
                         INTEGER,
                     ds1LineType
                         INTEGER,
                     ds1ZeroCoding
                         INTEGER,
                     ds1Loopback
                         INTEGER,
                     ds1SendCode
                         INTEGER,
                     ds1YellowAlarm
                         INTEGER,
                     ds1RedAlarm
                         INTEGER,
                     ds1CircuitIdentifier
                         DisplayString,
                     ds1LoopbackConfig
                         INTEGER,
                     ds1LineStatus
                         INTEGER
             }

             ds1LineIndex OBJECT-TYPE
                 SYNTAX  INTEGER
                 ACCESS  read-only
                 STATUS  mandatory
                 DESCRIPTION
"This object is the identifier of a DS1 Interface on a manged
device.  If there is an ifEntry that is directly associated with
this and only this DS3 interface, it should have the same value
as ifIndex.
Otherwise,
the value exceeds ifNumber,
and is a unique
identifier following this rule: inside interfaces (e.g., equipment
side) with even numbers and outside interfaces (e.g, network side)
with odd numbers."
                ::= { ds1ConfigEntry 1 }

            ds1IfIndex OBJECT-TYPE
                SYNTAX  INTEGER
                ACCESS  read-only
                STATUS  mandatory
                DESCRIPTION
                        "This value for this object is equal to the
                        value of ifIndex from the Interfaces table of
                        MIB II (RFC 1213)."
               ::= { ds1ConfigEntry 2 }

           ds1TimeElapsed OBJECT-TYPE
               SYNTAX  INTEGER (1..900)
               ACCESS  read-only
               STATUS  mandatory
               DESCRIPTION
                       "The number of seconds, including partial
                       seconds, that have elapsed since the beginning of
                       the current error-measurement period."
              ::= { ds1ConfigEntry 3 }

          ds1ValidIntervals OBJECT-TYPE
              SYNTAX  INTEGER (0..96)
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The number of previous intervals for which valid
                      data was collected.  The value will be 96 unless
                      the interface was brought online within the last
                      24 hours, in which case the value will be the
                      number of complete 15 minute intervals the
                      interface has been online."
              ::= { ds1ConfigEntry 4 }

          ds1LineType OBJECT-TYPE
              SYNTAX  INTEGER {
                          other(1),
                          ds1ESF(2),
                          ds1D4(3),
                          ds1ANSI-ESF(4),
                          ds1G704(5),
                          ds1G704-CRC(6)
                      }
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "This variable indicates the variety of DS1 Line
                      implementing this circuit.  The type of circuit
                      affects the number of bits per second that the
                      circuit can reasonably carry, as well as the
                      interpretation of the usage and error statistics.

                      The values, in sequence, describe:
                      TITLE:       SPECIFICATION:
                      ds1ESF        AT&T Extended SuperFrame DS1 [10]
                      ds1D4         AT&T D4 format DS1 [16], [17]
                      ds1ANSI-ESF   ANSI Extended SuperFrame format [14]
                      ds1G704       CCITT Recommendation G.704 [12]
                                      (section 2.1.3.2)
                      ds1G704-CRC   CCITT Recommendation G.704 [12]
                                      (section 2.1.3.1)
                      "
              ::= { ds1ConfigEntry 5 }

          ds1ZeroCoding OBJECT-TYPE
              SYNTAX  INTEGER {
                          ds1JammedBit(1),
                          ds1B8ZS(2),
                          ds1InvertedHDLC(3),
                          ds1HDB3(4),
                          ds1ZBTSI(5),
			  ds1NoZeroEncoding (6)
                      }
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "This variable describes the variety of Zero Code
                      Suppression used on the link, which in turn
                      affects a number of its characteristics.

                      ds1JammedBit refers the Jammed bit Zero Encoding,
                      in which the AT&T specification of at least one
                      pulse every 8 bit periods is literally implemented
	              by forcing a pulse in bit 8 of each channel.
                      Thus, only seven bits per channel, or 1.344 Mbps,
                      is available for data.

                      ds1B8ZS refers to the use of a specified pattern
                      of normal bits and bipolar violations which are
                      used to replace a sequence of eight zero bits (see
                      [14]).  In this context, all eight bits in a
                      channel are technically available for data, but
                      care must be taken with D4 encoded data to avoid
                      having HDLC Flag streams imitate spurious Yellow
                      Alarm conditions.  Typically, one bit per frame is
                      ignored to force flag streams to rotate, thereby
                      avoiding this error type.  CCITT Recommendation
                      G.703 [11] may be referred to for further
                      definition of these.

                      ds1InvertedHDLC refers to the practice, common on
                      HDLC encoded DS1 data links, of inverting the data
                      between the serial interface chip and the CSU.
                      Since HDLC guarantees one zero every 6 bits in the
                      worst case, while the standards call for (in
                      effect) at least one pulse every eight, inverted
                      HDLC enjoys 4/24 one's density on the line, which
                      may improve the effective clock stability of a DS1
                      line.  As with B8ZS, all eight bits in a channel
                      are technically available for data, but care must
                      be taken with D4 encoded data to avoid having HDLC
                      Flag streams imitate spurious Yellow Alarm
                      conditions.  Typically, one bit per frame is
                      ignored to force flag streams to rotate, thereby
                      avoiding this error type.

                      ANSI Clear Channels may use ds1ZBTSI, or Zero Byte
                      Time Slot Interchange (see [14]).

                      G.704 links, with or without CRC, use ds1HDB3 (see
                      [11]) or ds1NoZeroEncoding."
              ::= { ds1ConfigEntry 6 }

              ds1Loopback OBJECT-TYPE
                        SYNTAX  INTEGER {
                                    ds1NoLoop(1),
                                    ds1LocalLoopbackLocalSide(2),
                                    ds1LocalLoopbackRemoteSide(3),
                                    ds1RemoteLoopbackLocalSide(4),
                                    ds1RemoteLoopbackRemoteSide(5)
                                }
                        ACCESS  read-only
                        STATUS  deprecated
                        DESCRIPTION
                                "This variable represents the loopback state of
                                the device.  Agents supporting read/write access
                                should return badValue in response to a requested
                                loopback state that the device does not support.  The
                                values mean:

                                  ds1NoLoop
                                     Not in the loopback state.  A device that is
                                     not capable of performing a loopback on
                                     either interface shall always return this as
                                     it's value.

                                  ds1LocalLoopbackLocalSide
                                     Signal received from the local side of the
                                     device is looped back at the local connector
                                     (eg, without involving the device).

                                  ds1LocalLoopbackRemoteSide
                                     Signal received from the local side of the
                                     device is looped back at the remote connector
                                     (eg, through the device).

                                  ds1RemoteLoopbackLocalSide
                                     Signal received from the remote side of the
                                     device is looped back at the local connector
                                     (eg, through the device).

                                  ds1RemoteLoopbackRemoteSide
                                     Signal received from the remote side of the
                                     device is looped back at the remote connector
                                     (eg, without involving the device)."
                        ::= { ds1ConfigEntry 7 }

                ds1SendCode OBJECT-TYPE
                        SYNTAX  INTEGER {
                                    ds1SendTestMessage(1),
                                    ds1SendNoCode(2),
                                    ds1SendSetCode(3),
                                    ds1SendLoopbackCode(4),
                                    ds1SendResetCode(5)
                                }
                        ACCESS  read-only
                        STATUS  mandatory
                        DESCRIPTION
                                "This variable indicates what type of code is
                                being sent across the ds1 interface by the device.  The
                                values mean:

                                  ds1SendNoCode
                                     sending looped or normal data

                                  ds1SendSetCode
                                     sending a loopback request

                                  ds1SendLoopbackCode
                                     sending a loopback test code/pattern

                                  ds1SendResetCode
                                     sending a loopback termination request

                                  ds1SendTestMessage
                                     sending a Test pattern as defined in
                                     T1.107a-1990."
                        ::= { ds1ConfigEntry 8 }

          ds1YellowAlarm OBJECT-TYPE
              SYNTAX  INTEGER {
                          ds1YellowAlarm(1),
                          ds1NoYellowAlarm(2)
                      }
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "This variable indicates if a Yellow Alarm
                      condition exists."
              ::= { ds1ConfigEntry 9 }

          ds1RedAlarm OBJECT-TYPE
              SYNTAX  INTEGER {
                          ds1RedAlarm(1),
                          ds1NoRedAlarm(2)
                      }
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "This variable indicates if a Red Alarm condition
                      exists."
              ::= { ds1ConfigEntry 10 }

          ds1CircuitIdentifier OBJECT-TYPE
              SYNTAX  DisplayString (SIZE (0..255))
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "This variable contains the transmission vendor's
                      circuit identifier, for the purpose of
                      facilitating troubleshooting."
              ::= { ds1ConfigEntry 11 }

                 ds1LoopbackConfig OBJECT-TYPE
                           SYNTAX  INTEGER {
                                       ds1NoLoop(1),
                                       ds1MgrPayloadLoop(2),
                                       ds1MgrLineLoop(3),
                                       ds1NetReqPayloadLoop(4),
                                       ds1NetReqLineLoop(5),
                                       ds1OtherLoop(6)
                                   }
                           ACCESS  read-only
                           STATUS  mandatory
                           DESCRIPTION
                                   "This variable represents the loopback configuration of
                                   the ds1 interface.  Agents supporting read/write
                                   access should return badValue in response to a
                                   requested loopback state that the interface does not support.
                                   The values mean:

                                         ds1NoLoop

                                           Not in the loopback state.  A device that is
                                           not capable of performing a loopback on
                                           the interface shall always return this as
                                           it's value.

                                         ds1MgrPayloadLoop

                                           The received signal at this interface is looped through
                                           the device; this loopback is initiated by a
                                           manager of the device. Typically the received signal
                                           is looped back for retransmission after it has
                                           passed through the device's framing function.

                                         ds1MgrLineLoop

                                           The received signal at this interface does not
                                           go through the device (minimum penetration) but
                                           is looped back out; this loopback is initiated
                                           by a manager of the device.

                                         ds1NetReqPayloadLoop

                                           The received signal at this interface is looped through
                                           the device; this loopback is initiated/requested by the

                                           far end equipment. Typically the received signal
                                           is looped back for retransmission after it has
                                           passed through the device's framing function.

                                         ds1NetReqLineLoop

                                           The received signal at this interface does not
                                           go through the device (minimum penetration) but
                                           is looped back out; this loopback is initiated/requested
                                           by the far end equipment.

                                         ds1OtherLoop

                                           Loopbacks that are not defined here."
                           ::= { ds1ConfigEntry 12 }

                    ds1LineStatus OBJECT-TYPE
                        SYNTAX  INTEGER
                        ACCESS  read-only
                        STATUS  mandatory
                        DESCRIPTION
                 "This variable indicates the
                 Line Status of the interface.
                 It contains loopback state information
                 and alarm state information.
                 The ds1LineStatus is a bit map represented as a sum, therefore,
                 it can represent multiple alarms and a LoopbackState
                 simultaneously.

		The various bit positions are:
                                 1     ds1FarEndAlarm
                                 2     ds1AlarmIndicationSignal
                                 4     ds1LossOfFrame
                                 8     ds1LossOfSignal
                                16     ds1LoopbackState
                                32     ds1T16AlarmIndicationSignal
                                64     ds1LossOfMultiFrame
                               128     ds1DistantLossOfMultiFrame
                               256     ds1DistantLossOfSignal
		"
                        ::= { ds1ConfigEntry 13 }

          -- the ds1 Interval

          -- The ds1 Interval Table contains various statistics
          -- collected by each ds1 Interface over the previous 24 hours of
          -- operation.  The past 24 hours are broken into 96 completed
          -- 15 minute intervals.
          -- This table has been deprecated and replaced by ds1GgIntervalTable.

          ds1IntervalTable OBJECT-TYPE
              SYNTAX  SEQUENCE OF DS1IntervalEntry
              ACCESS  not-accessible
              STATUS  deprecated
              DESCRIPTION
                      "The ds1 Interval table."
              ::= { ds1 2 }

          ds1IntervalEntry OBJECT-TYPE
              SYNTAX  DS1IntervalEntry
              ACCESS  not-accessible
              STATUS  deprecated
              DESCRIPTION
                      "An entry in the ds1 Interval table."
              INDEX   { ds1IntervalIndex, ds1IntervalNumber }
              ::= { ds1IntervalTable 1 }

          DS1IntervalEntry ::=
              SEQUENCE {
                  ds1IntervalIndex
                      INTEGER,
                  ds1IntervalNumber
                      INTEGER,
                  ds1IntervalESs
                      Counter,
                  ds1IntervalSESs
                      Counter,
                  ds1IntervalSEFSs
                      Counter,
                  ds1IntervalUASs
                      Counter,
                  ds1IntervalCSSs
                      Counter,
                  ds1IntervalLESs
                      Counter,
                  ds1IntervalCVs
                      Counter

              }

          ds1IntervalIndex OBJECT-TYPE
              SYNTAX  INTEGER (1..65535)
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "The index value which uniquely identifies the ds1
                      interface to which this entry is applicable.  The
                      interface identified by a particular value of this
                      index is the same interface as identified by the
                      same value an ds1LineIndex object instance."
              ::= { ds1IntervalEntry 1 }

          ds1IntervalNumber OBJECT-TYPE
              SYNTAX  INTEGER (1..96)
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "A number between 1 and 96, where 1 is the most
                      recently completed 15 minute interval and 96 is
                      the least recently completed 15 minutes interval
                      (assuming that all 96 intervals are valid)."
              ::= { ds1IntervalEntry 2 }

          ds1IntervalESs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "The counter associated with the number of Errored
                      Seconds, encountered by a ds1 interface in one of
                      the previous 96, individual 15 minute, intervals."
              ::= { ds1IntervalEntry 3 }

          ds1IntervalSESs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "The counter associated with the number of
                      Severely Errored Seconds, encountered by a ds1
                      interface in one of the previous 96, individual 15
                      minute, intervals."
              ::= { ds1IntervalEntry 4 }

          ds1IntervalSEFSs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "The counter associated with the number of
                      Severely Errored Framing Seconds, encountered by a
                      ds1 interface in one of the previous 96,
                      individual 15 minute, intervals."
              ::= { ds1IntervalEntry 5 }

          ds1IntervalUASs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "The counter associated with the number of
                      Unavailable Seconds, encountered by a ds1
                      interface in one of the previous 96, individual 15
                      minute, intervals."
              ::= { ds1IntervalEntry 6 }

          ds1IntervalCSSs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "The counter associated with the number of
                      Controlled Slip Seconds, encountered by a ds1
                      interface in one of the previous 96, individual 15
                      minute, intervals.  Note that SYNTRAN interfaces
                      are the only interfaces that support the
                      Controlled Slip Seconds managed object.
                      Accordingly, agents configured with non-SYNTRAN
                      interfaces may treat this object as having an
                      ACCESS clause value of not-accessible."
              ::= { ds1IntervalEntry 7 }

          ds1IntervalLESs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "The counter associated with the number of Bipolar
                      Violations, encountered by a ds1 interface in one

                      of the previous 96, individual 15 minute,
                      intervals."
              ::= { ds1IntervalEntry 8 }

          ds1IntervalCVs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "The counter associated with the number of Coding
                      Violations, encountered by a ds1 interface in one
                      of the previous 96, individual 15 minute,
                      intervals."
              ::= { ds1IntervalEntry 9 }

          -- the ds1 Current

          -- The ds1 current table contains various statistics being
          -- collected for the current 15 minute interval.

          ds1CurrentTable OBJECT-TYPE
              SYNTAX  SEQUENCE OF DS1CurrentEntry
              ACCESS  not-accessible
              STATUS  mandatory
              DESCRIPTION
                      "The ds1 Current table."
              ::= { ds1 3 }

          ds1CurrentEntry OBJECT-TYPE
              SYNTAX  DS1CurrentEntry
              ACCESS  not-accessible
              STATUS  mandatory
              DESCRIPTION
                      "An entry in the ds1 Current table."
              INDEX   { ds1CurrentIndex }
              ::= { ds1CurrentTable 1 }

          DS1CurrentEntry ::=
              SEQUENCE {
                  ds1CurrentIndex
                      INTEGER,
                  ds1CurrentESs
                      Counter,
                  ds1CurrentSESs
                      Counter,
                  ds1CurrentSEFSs
                      Counter,
                  ds1CurrentUASs
                      Counter,
                  ds1CurrentCSSs
                      Counter,
                  ds1CurrentLESs
                      Counter,
                  ds1CurrentCVs
                      Counter
              }

          ds1CurrentIndex OBJECT-TYPE
              SYNTAX  INTEGER (1..65535)
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The index value which uniquely identifies the ds1
                      interface to which this entry is applicable.  The
                      interface identified by a particular value of this
                      index is the same interface as identified by the
                      same value an ds1LineIndex object instance."
              ::= { ds1CurrentEntry 1 }

          ds1CurrentESs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Errored
                      Seconds, encountered by a ds1 interface in the
                      current 15 minute interval."
              ::= { ds1CurrentEntry 2 }

          ds1CurrentSESs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of
                      Severely Errored Seconds, encountered by a ds1
                      interface in the current 15 minute interval."
              ::= { ds1CurrentEntry 3 }

          ds1CurrentSEFSs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of
                      Severely Errored Framing Seconds, encountered by a
                      ds1 interface in the current 15 minute interval."
              ::= { ds1CurrentEntry 4 }

          ds1CurrentUASs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of
                      Unavailable Seconds encountered by a ds1
                      interface in the current 15 minute interval."
              ::= { ds1CurrentEntry 5 }

          ds1CurrentCSSs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of
                      Controlled Slip Seconds, encountered by a ds1
                      interface in the current 15 minute interval.  Note
                      that SYNTRAN interfaces are the only interfaces
                      that support the Controlled Slip Seconds managed
                      object.  Accordingly, agents configured with non-
                      SYNTRAN interfaces may treat this object as having
                      an ACCESS clause value of not-accessible."
              ::= { ds1CurrentEntry 6 }

          ds1CurrentLESs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Bipolar
                      Violations, encountered by a ds1 interface in the
                      current 15 minute interval."
              ::= { ds1CurrentEntry 7 }

          ds1CurrentCVs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Coding
                      Violations, encountered by a ds1 interface in the
                      current 15 minute interval."
              ::= { ds1CurrentEntry 8 }

          -- the ds1 Total

          -- The ds1 Total Table contains the cumulative sum of the
          -- various statistics for the 24 hour interval preceding the
          -- first valid interval in the ds1CurrentTable.
          -- This table has been deprecated and replaced by ds1GgTotalTable.

          ds1TotalTable OBJECT-TYPE
              SYNTAX  SEQUENCE OF DS1TotalEntry
              ACCESS  not-accessible
              STATUS  deprecated
              DESCRIPTION
                      "The ds1 Total table.  24 hour interval."
              ::= { ds1 4 }

          ds1TotalEntry OBJECT-TYPE
              SYNTAX  DS1TotalEntry
              ACCESS  not-accessible
              STATUS  deprecated
              DESCRIPTION
                      "An entry in the ds1 Total table."
              INDEX   { ds1TotalIndex }
              ::= { ds1TotalTable 1 }

          DS1TotalEntry ::=
              SEQUENCE {
                  ds1TotalIndex
                      INTEGER,
                  ds1TotalESs
                      Counter,
                  ds1TotalSESs
                      Counter,
                  ds1TotalSEFSs
                      Counter,
                  ds1TotalUASs
                      Counter,
                  ds1TotalCSSs
                      Counter,
                  ds1TotalLESs
                      Counter,
                  ds1TotalCVs
                      Counter
              }

          ds1TotalIndex OBJECT-TYPE

              SYNTAX  INTEGER (1..65535)
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "The index value which uniquely identifies the ds1
                      interface to which this entry is applicable.  The
                      interface identified by a particular value of this
                      index is the same interface as identified by the
                      same value an ds1LineIndex object instance."
              ::= { ds1TotalEntry 1 }

          ds1TotalESs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "The counter associated with the number of Errored
                      Seconds, encountered by a ds1 interface in the
                      previous 24 hour interval"
              ::= { ds1TotalEntry 2 }

          ds1TotalSESs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "The counter associated with the number of
                      Severely Errored Seconds, encountered by a ds1
                      interface in the previous 24 hour interval."
              ::= { ds1TotalEntry 3 }

          ds1TotalSEFSs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "The counter associated with the number of
                      Severely Errored Framing Seconds, encountered by a
                      ds1 interface in the previous 24 hour interval."
              ::= { ds1TotalEntry 4 }

          ds1TotalUASs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  deprecated

              DESCRIPTION
                      "The counter associated with the number of
                      Unavailable Seconds, encountered by a ds1
                      interface in the previous 24 hour interval."
              ::= { ds1TotalEntry 5 }

          ds1TotalCSSs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "The counter associated with the number of
                      Controlled Slip Seconds, encountered by a ds1
                      interface in the previous 24 hour interval.  Note
                      that SYNTRAN interfaces are the only interfaces
                      that support the Controlled Slip Seconds managed
                      object.  Accordingly, agents configured with non-
                      SYNTRAN interfaces may treat this object as having
                      an ACCESS clause value of not-accessible."
              ::= { ds1TotalEntry 6 }

          ds1TotalLESs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "The counter associated with the number of Bipolar
                      Violations, encountered by a ds1 interface in the
                      previous 24 hour interval."
              ::= { ds1TotalEntry 7 }

          ds1TotalCVs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "The counter associated with the number of Coding
                      Violations, encountered by a ds1 interface in the
                      previous 24 hour interval."
              ::= { ds1TotalEntry 8 }

          -- the ds1 Gauge Interval

          -- The ds1 Gauge Interval Table contains various statistics
          -- collected by each ds1 Interface over the previous 24 hours of
          -- operation.  The past 24 hours are broken into 96 completed
          -- 15 minute intervals.

          ds1GgIntervalTable OBJECT-TYPE
              SYNTAX  SEQUENCE OF DS1GgIntervalEntry
              ACCESS  not-accessible
              STATUS  mandatory
              DESCRIPTION
                      "The ds1 Gauge Interval table."
              ::= { ds1 6 }

          ds1GgIntervalEntry OBJECT-TYPE
              SYNTAX  DS1GgIntervalEntry
              ACCESS  not-accessible
              STATUS  mandatory
              DESCRIPTION
                      "An entry in the ds1 Gauge Interval table."
              INDEX   { ds1GgIntervalIndex, ds1GgIntervalNumber }
              ::= { ds1GgIntervalTable 1 }

          DS1GgIntervalEntry ::=
              SEQUENCE {
                  ds1GgIntervalIndex
                      INTEGER,
                  ds1GgIntervalNumber
                      INTEGER,
                  ds1GgIntervalESs
                      Gauge,
                  ds1GgIntervalSESs
                      Gauge,
                  ds1GgIntervalSEFSs
                      Gauge,
                  ds1GgIntervalUASs
                      Gauge,
                  ds1GgIntervalCSSs
                      Gauge,
                  ds1GgIntervalLESs
                      Gauge,
                  ds1GgIntervalCVs
                      Gauge
              }

          ds1GgIntervalIndex OBJECT-TYPE
              SYNTAX  INTEGER (1..65535)
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The index value which uniquely identifies the ds1
                      interface to which this entry is applicable.  The
                      interface identified by a particular value of this
                      index is the same interface as identified by the
                      same value an ds1LineIndex object instance."
              ::= { ds1GgIntervalEntry 1 }

          ds1GgIntervalNumber OBJECT-TYPE
              SYNTAX  INTEGER (1..96)
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "A number between 1 and 96, where 1 is the most
                      recently completed 15 minute interval and 96 is
                      the least recently completed 15 minutes interval
                      (assuming that all 96 intervals are valid)."
              ::= { ds1GgIntervalEntry 2 }

          ds1GgIntervalESs OBJECT-TYPE
              SYNTAX  Gauge
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Errored
                      Seconds, encountered by a ds1 interface in one of
                      the previous 96, individual 15 minute, intervals."
              ::= { ds1GgIntervalEntry 3 }

          ds1GgIntervalSESs OBJECT-TYPE
              SYNTAX  Gauge
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of
                      Severely Errored Seconds, encountered by a ds1
                      interface in one of the previous 96, individual 15
                      minute, intervals."
              ::= { ds1GgIntervalEntry 4 }

          ds1GgIntervalSEFSs OBJECT-TYPE

              SYNTAX  Gauge
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of
                      Severely Errored Framing Seconds, encountered by a
                      ds1 interface in one of the previous 96,
                      individual 15 minute, intervals."
              ::= { ds1GgIntervalEntry 5 }

          ds1GgIntervalUASs OBJECT-TYPE
              SYNTAX  Gauge
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of
                      Unavailable Seconds, encountered by a ds1
                      interface in one of the previous 96, individual 15
                      minute, intervals."
              ::= { ds1GgIntervalEntry 6 }

          ds1GgIntervalCSSs OBJECT-TYPE
              SYNTAX  Gauge
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of
                      Controlled Slip Seconds, encountered by a ds1
                      interface in one of the previous 96, individual 15
                      minute, intervals.  Note that SYNTRAN interfaces
                      are the only interfaces that support the
                      Controlled Slip Seconds managed object.
                      Accordingly, agents configured with non-SYNTRAN
                      interfaces may treat this object as having an
                      ACCESS clause value of not-accessible."
              ::= { ds1GgIntervalEntry 7 }

          ds1GgIntervalLESs OBJECT-TYPE
              SYNTAX  Gauge
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Bipolar
                      Violations, encountered by a ds1 interface in one
                      of the previous 96, individual 15 minute,

                      intervals."
              ::= { ds1GgIntervalEntry 8 }

          ds1GgIntervalCVs OBJECT-TYPE
              SYNTAX  Gauge
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Coding
                      Violations, encountered by a ds1 interface in one
                      of the previous 96, individual 15 minute,
                      intervals."
              ::= { ds1GgIntervalEntry 9 }

          -- the ds1 Gauge Total

          -- The ds1 Gauge Total Table contains the cumulative sum of the
          -- various statistics for the 24 hour interval preceding the
          -- first valid interval in the ds1CurrentTable.

          ds1GgTotalTable OBJECT-TYPE
              SYNTAX  SEQUENCE OF DS1GgTotalEntry
              ACCESS  not-accessible
              STATUS  mandatory
              DESCRIPTION
                      "The ds1 Gauge Total table.  24 hour interval."
              ::= { ds1 7 }

          ds1GgTotalEntry OBJECT-TYPE
              SYNTAX  DS1GgTotalEntry
              ACCESS  not-accessible
              STATUS  mandatory
              DESCRIPTION
                      "An entry in the ds1 Gauge Total table."
              INDEX   { ds1GgTotalIndex }
              ::= { ds1GgTotalTable 1 }

          DS1GgTotalEntry ::=
              SEQUENCE {
                  ds1GgTotalIndex
                      INTEGER,
                  ds1GgTotalESs
                      Gauge,
                  ds1GgTotalSESs
                      Gauge,
                  ds1GgTotalSEFSs
                      Gauge,
                  ds1GgTotalUASs
                      Gauge,
                  ds1GgTotalCSSs
                      Gauge,
                  ds1GgTotalLESs
                      Gauge,
                  ds1GgTotalCVs
                      Gauge
              }

          ds1GgTotalIndex OBJECT-TYPE
              SYNTAX  INTEGER (1..65535)

              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The index value which uniquely identifies the ds1
                      interface to which this entry is applicable.  The
                      interface identified by a particular value of this
                      index is the same interface as identified by the
                      same value an ds1LineIndex object instance."
              ::= { ds1GgTotalEntry 1 }

          ds1GgTotalESs OBJECT-TYPE
              SYNTAX  Gauge
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Errored
                      Seconds, encountered by a ds1 interface in the
                      previous 24 hour interval"
              ::= { ds1GgTotalEntry 2 }

          ds1GgTotalSESs OBJECT-TYPE
              SYNTAX  Gauge
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of
                      Severely Errored Seconds, encountered by a ds1
                      interface in the previous 24 hour interval."
              ::= { ds1GgTotalEntry 3 }

          ds1GgTotalSEFSs OBJECT-TYPE
              SYNTAX  Gauge
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of
                      Severely Errored Framing Seconds, encountered by a
                      ds1 interface in the previous 24 hour interval."
              ::= { ds1GgTotalEntry 4 }

          ds1GgTotalUASs OBJECT-TYPE
              SYNTAX  Gauge
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION

                      "The counter associated with the number of
                      Unavailable Seconds, encountered by a ds1
                      interface in the previous 24 hour interval."
              ::= { ds1GgTotalEntry 5 }

          ds1GgTotalCSSs OBJECT-TYPE
              SYNTAX  Gauge
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of
                      Controlled Slip Seconds, encountered by a ds1
                      interface in the previous 24 hour interval.  Note
                      that SYNTRAN interfaces are the only interfaces
                      that support the Controlled Slip Seconds managed
                      object.  Accordingly, agents configured with non-
                      SYNTRAN interfaces may treat this object as having
                      an ACCESS clause value of not-accessible."
              ::= { ds1GgTotalEntry 6 }

          ds1GgTotalLESs OBJECT-TYPE
              SYNTAX  Gauge
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Bipolar
                      Violations, encountered by a ds1 interface in the
                      previous 24 hour interval."
              ::= { ds1GgTotalEntry 7 }

          ds1GgTotalCVs OBJECT-TYPE
              SYNTAX  Gauge
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Coding
                      Violations, encountered by a ds1 interface in the
                      previous 24 hour interval."
              ::= { ds1GgTotalEntry 8 }

          -- The ds1 Far End Group

          -- Implementation of this group is optional for all systems
          -- that attach to a ds1 Interface.

          -- The ds1 Far End Group consists of three tables:
          --   ds1 Far End Current
          --   ds1 Far End Gauge Interval
          --   ds1 Far End Gauge Total

          -- The ds1 Far End Current

          -- The ds1 Far End Current table contains various statistics being
          -- collected for the current 15 minute interval.
          -- The statistics are collected from the far end block error code
          -- within the C-bits.  The definitions are the same as described for
          -- the near-end information.

                    ds1FarEndCurrentTable OBJECT-TYPE
                        SYNTAX  SEQUENCE OF DS1FarEndCurrentEntry
                        ACCESS  not-accessible
                        STATUS  mandatory
                        DESCRIPTION
                                "The ds1 Far End Current table."
                        ::= { ds1 8 }

                    ds1FarEndCurrentEntry OBJECT-TYPE
                        SYNTAX  DS1FarEndCurrentEntry
                        ACCESS  not-accessible
                        STATUS  mandatory
                        DESCRIPTION
                                "An entry in the ds1 Far End Current table."
                        INDEX   { ds1FarEndCurrentIndex }
                        ::= { ds1FarEndCurrentTable 1 }

                    DS1FarEndCurrentEntry ::=
                        SEQUENCE {
                            ds1FarEndCurrentIndex
                                INTEGER,
                            ds1FarEndCurrentESs
                                Counter,
                            ds1FarEndCurrentSESs
                                Counter,
                  ds1FarEndCurrentSEFSs
                      Counter,
                  ds1FarEndCurrentCSSs
                      Counter,
                  ds1FarEndCurrentLESs
                      Counter,
                            ds1FarEndCurrentCVs
                                Counter
                        }

                     ds1FarEndCurrentIndex OBJECT-TYPE
                        SYNTAX  INTEGER (1..65535)
                        ACCESS  read-only
                        STATUS  mandatory
                        DESCRIPTION

                                "The index value which uniquely identifies the
                                ds1 interface
                                to which this entry is applicable.  The interface
                                identified by a particular value of this index is
                                the same interface as identified by the same value
                                an ds1LineIndex object instance."
                        ::= { ds1FarEndCurrentEntry 1 }

                    ds1FarEndCurrentESs OBJECT-TYPE
                        SYNTAX  Counter
                        ACCESS  read-only
                        STATUS  mandatory
                        DESCRIPTION
                                "The counter associated with the number of Far
                                Far End Errored Seconds encountered by a ds1
                                interface in the current 15 minute interval."
                        ::= { ds1FarEndCurrentEntry 2 }

                    ds1FarEndCurrentSESs OBJECT-TYPE
                        SYNTAX  Counter
                        ACCESS  read-only
                        STATUS  mandatory
                        DESCRIPTION
                                "The counter associated with the number of
                                Far End Severely Errored Seconds
                                encountered by a ds1 interface in the current 15 minute
                                interval."
                        ::= { ds1FarEndCurrentEntry 3 }

          ds1FarEndCurrentSEFSs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Far End
                      Severely Errored Framing Seconds, encountered by a
                      ds1 interface in the current 15 minute interval."
              ::= { ds1FarEndCurrentEntry 4 }

          ds1FarEndCurrentCSSs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Far End
                      Controlled Slip Seconds, encountered by a ds1
                      interface in the current 15 minute interval.  Note
                      that SYNTRAN interfaces are the only interfaces
                      that support the Controlled Slip Seconds managed
                      object.  Accordingly, agents configured with non-
                      SYNTRAN interfaces may treat this object as having
                      an ACCESS clause value of not-accessible."
              ::= { ds1FarEndCurrentEntry 5 }

          ds1FarEndCurrentLESs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Far End Bipolar
                      Violations, encountered by a ds1 interface in the
                      current 15 minute interval."
              ::= { ds1FarEndCurrentEntry 6 }

                    ds1FarEndCurrentCVs OBJECT-TYPE
                        SYNTAX  Counter
                        ACCESS  read-only
                        STATUS  mandatory
                        DESCRIPTION
                                "The counter associated with the number of
                                Far End Coding Violations reported via
                                the far end block error count
                                encountered by a
                                ds1 interface in the current 15 minute interval."
                        ::= { ds1FarEndCurrentEntry 7 }

          -- The ds1 Far End Gauge Interval

          -- Only C-bit Parity Applications and SYNTRAN applications
          -- can provide this information.

          -- The ds1 Far End Gauge Interval Table contains various statistics
          -- collected by each ds1 interface over the previous 24 hours of
          -- operation.  The past 24 hours are broken into 96
          -- completed 15 minute intervals.

                    ds1FarEndGgIntervalTable OBJECT-TYPE
                        SYNTAX  SEQUENCE OF DS1FarEndGgIntervalEntry
                        ACCESS  not-accessible
                        STATUS  mandatory
                        DESCRIPTION
                               "The ds1 Far End Gauge Interval table."
                        ::= { ds1 9 }

                    ds1FarEndGgIntervalEntry OBJECT-TYPE
                        SYNTAX  DS1FarEndGgIntervalEntry
                        ACCESS  not-accessible
                        STATUS  mandatory
                        DESCRIPTION
                              "An entry in the ds1 Far
                              End Gauge Interval table."
                        INDEX   { ds1FarEndGgIntervalIndex, ds1FarEndGgIntervalNumber }
                        ::= { ds1FarEndGgIntervalTable 1 }

                    DS1FarEndGgIntervalEntry ::=
                        SEQUENCE {
                             ds1FarEndGgIntervalIndex
                                  INTEGER,
                             ds1FarEndGgIntervalNumber
                                  INTEGER,
                             ds1FarEndGgIntervalESs
                                  Gauge,
                             ds1FarEndGgIntervalSESs
                                  Gauge,
                  ds1FarEndGgIntervalSEFSs
                      Gauge,
                  ds1FarEndGgIntervalCSSs
                      Gauge,
                  ds1FarEndGgIntervalLESs
                      Gauge,
                             ds1FarEndGgIntervalCVs
                                  Gauge
                        }

                    ds1FarEndGgIntervalIndex OBJECT-TYPE
                        SYNTAX  INTEGER (1..65535)
                        ACCESS  read-only

                        STATUS  mandatory
                        DESCRIPTION
                                "The index value which uniquely identifies the
                                ds1 interface
                                to which this entry is applicable.  The
                                interface identified by a particular value of
                                this index is the same interface as identified
                                by the same value an ds1LineIndex object
                                instance."
                        ::= { ds1FarEndGgIntervalEntry 1 }

                   ds1FarEndGgIntervalNumber OBJECT-TYPE
                       SYNTAX  INTEGER (1..96)
                       ACCESS  read-only
                       STATUS  mandatory
                       DESCRIPTION
                              "A number between 1 and 96, where 1 is the most
                              recently completed 15 minute interval and 96 is
                              the least recently completed 15 minutes
                              interval (assuming that all 96 intervals are
                              valid)."
                       ::= { ds1FarEndGgIntervalEntry 2 }

                   ds1FarEndGgIntervalESs OBJECT-TYPE
                       SYNTAX  Gauge
                       ACCESS  read-only
                       STATUS  mandatory
                       DESCRIPTION
                               "The counter associated with the number of
                               Far End Errored Seconds encountered
                               by a ds1 interface in one of the previous 96,
                               individual 15 minute, intervals."
                      ::= { ds1FarEndGgIntervalEntry 3 }

                   ds1FarEndGgIntervalSESs OBJECT-TYPE
                       SYNTAX  Gauge
                       ACCESS  read-only
                       STATUS  mandatory
                       DESCRIPTION
                               "The counter associated with the number of
                               Far End Severely Errored Seconds
                               encountered by a ds1 interface in one of the previous
                               96, individual 15 minute, intervals."
                      ::= { ds1FarEndGgIntervalEntry 4 }

          ds1FarEndGgIntervalSEFSs OBJECT-TYPE
              SYNTAX  Gauge
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Far End
                      Severely Errored Framing Seconds, encountered by a
                      ds1 interface in one of the previous
                               96, individual 15 minute, intervals."
              ::= { ds1FarEndGgIntervalEntry 5 }

          ds1FarEndGgIntervalCSSs OBJECT-TYPE
              SYNTAX  Gauge
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Far End
                      Controlled Slip Seconds, encountered by a ds1 interface in one of the previous
                               96, individual 15 minute, intervals."
              ::= { ds1FarEndGgIntervalEntry 6 }

          ds1FarEndGgIntervalLESs OBJECT-TYPE
              SYNTAX  Gauge
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Far End Bipolar
                      Violations, encountered by a ds1 interface in one of the previous
                               96, individual 15 minute, intervals."
              ::= { ds1FarEndGgIntervalEntry 7 }

                    ds1FarEndGgIntervalCVs OBJECT-TYPE
                        SYNTAX  Gauge
                        ACCESS  read-only
                        STATUS  mandatory
                        DESCRIPTION
                                "The counter associated with the number of
                                Far End Coding Violations reported via
                                the far end block error count
                                encountered by a
                                ds1 interface in one of the previous 96, individual 15
                                minute, intervals."
                        ::= { ds1FarEndGgIntervalEntry 8 }

          -- The ds1 Far End Gauge Total

          -- Only C-bit Parity Applications and SYNTRAN applications
          -- can provide this information.

          -- The ds1 Far End Gauge Total Table contains the cumulative sum of the
          -- various statistics for the 24 hour interval preceding the
          -- first valid interval in the ds1FarEndCurrentTable.

                    ds1FarEndGgTotalTable OBJECT-TYPE
                        SYNTAX  SEQUENCE OF DS1FarEndGgTotalEntry
                        ACCESS  not-accessible
                        STATUS  mandatory
                        DESCRIPTION
                                "The ds1 Far End Gauge Total table.  24 hour interval."
                        ::= { ds1 10 }

                    ds1FarEndGgTotalEntry OBJECT-TYPE
                        SYNTAX  DS1FarEndGgTotalEntry
                        ACCESS  not-accessible
                        STATUS  mandatory
                        DESCRIPTION
                                "An entry in the ds1 Far End Gauge Total table."
                        INDEX   { ds1FarEndGgTotalIndex }
                        ::= { ds1FarEndGgTotalTable 1 }

                    DS1FarEndGgTotalEntry ::=
                        SEQUENCE {
                            ds1FarEndGgTotalIndex
                                INTEGER,
                            ds1FarEndGgTotalESs
                                Gauge,
                            ds1FarEndGgTotalSESs
                                Gauge,
                  ds1FarEndGgTotalSEFSs
                      Gauge,
                  ds1FarEndGgTotalCSSs
                      Gauge,
                  ds1FarEndGgTotalLESs
                      Gauge,
                            ds1FarEndGgTotalCVs
                                Gauge
                        }

                    ds1FarEndGgTotalIndex OBJECT-TYPE
                        SYNTAX  INTEGER (1..65535)
                        ACCESS  read-only
                        STATUS  mandatory
                        DESCRIPTION
                                "The index value which uniquely identifies the
                                ds1 interface

                                to which this entry is applicable.  The interface
                                identified by a particular value of this index is
                                the same interface as identified by the same value
                                an ds1LineIndex object instance."
                        ::= { ds1FarEndGgTotalEntry 1 }

                   ds1FarEndGgTotalESs OBJECT-TYPE
                       SYNTAX  Gauge
                       ACCESS  read-only
                       STATUS  mandatory
                       DESCRIPTION
                               "The counter associated with the number of Far
                               End Errored Seconds encountered by a ds1
                               interface in the previous 24 hour interval."
                       ::= { ds1FarEndGgTotalEntry 2 }

                   ds1FarEndGgTotalSESs OBJECT-TYPE
                       SYNTAX  Gauge
                       ACCESS  read-only
                       STATUS  mandatory
                       DESCRIPTION
                               "The counter associated with the number of
                               Far End Severely Errored Seconds
                               encountered by a ds1 interface in the previous 24 hour
                               interval."
                       ::= { ds1FarEndGgTotalEntry 3 }

          ds1FarEndGgTotalSEFSs OBJECT-TYPE
              SYNTAX  Gauge
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Far End
                      Severely Errored Framing Seconds, encountered by a
                      ds1 interface in the previous 24 hour interval."
              ::= { ds1FarEndGgTotalEntry 5 }

          ds1FarEndGgTotalCSSs OBJECT-TYPE
              SYNTAX  Gauge
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Far End
                      Controlled Slip Seconds, encountered by a ds1 interface in the previous 24 hour interval."
              ::= { ds1FarEndGgTotalEntry 6 }

          ds1FarEndGgTotalLESs OBJECT-TYPE
              SYNTAX  Gauge
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Far End Bipolar
                      Violations, encountered by a ds1 interface in the previous 24 hour interval."
              ::= { ds1FarEndGgTotalEntry 7 }

                   ds1FarEndGgTotalCVs OBJECT-TYPE
                       SYNTAX  Gauge
                       ACCESS  read-only
                       STATUS  mandatory
                       DESCRIPTION
                               "The counter associated with the number of
                               Far End Coding Violations reported via the
                               far end block error count
                               encountered by a
                               ds1 interface in the previous 24 hour interval."
                       ::= { ds1FarEndGgTotalEntry 8 }

          -- the DS1 Fractional group

          -- Implementation of this group is mandatory for those
          -- systems dividing a DS1 into channels containing different
          -- data streams that are of local interest.  Systems which
          -- are indifferent to data content, such as CSUs, need not
          -- implement it.

          -- The DS1 fractional table contains identifies which DS1
          -- channels associated with a CSU are being used to support a
          -- logical interface, i.e., an entry in the interfaces table
          -- from the Internet-standard MIB.

          -- For example, consider an application managing a North
          -- American ISDN Primary Rate link whose division is a 384 KBPS
          -- H1 "B" Channel for Video, a second H1 for data to a primary
          -- routing peer, and 12 64 KBPS H0 "B" Channels. Consider that
          -- some subset of the H0 channels are used for voice and the
          -- remainder are available for dynamic data calls.

          -- we count a total of 14 interfaces multiplexed onto the DS1
          -- interface. Six DS1 channels (for the sake of the example,
          -- channels 1..6) are used for Video, six more (7..11 and 13)
          -- are used for data, and the remaining 12 are are in channels
          -- 12 and 14..24.

          -- Let us further imagine that ifIndex 2 is of type DS1 and
          -- refers to the DS1 interface, and that the interfaces layered
          -- onto it are numbered 3..16.

          -- We might describe the allocation of channels, in the
          -- ds1FracTable, as follows:

          -- ds1FracIfIndex.2. 1 = 3    ds1FracIfIndex.2.13 = 4
	  -- ds1FracIfIndex.2. 2 = 3    ds1FracIfIndex.2.14 = 6
	  -- ds1FracIfIndex.2. 3 = 3    ds1FracIfIndex.2.15 = 7
	  -- ds1FracIfIndex.2. 4 = 3    ds1FracIfIndex.2.16 = 8
          -- ds1FracIfIndex.2. 5 = 3    ds1FracIfIndex.2.17 = 9
	  -- ds1FracIfIndex.2. 6 = 3    ds1FracIfIndex.2.18 = 10
	  -- ds1FracIfIndex.2. 7 = 4    ds1FracIfIndex.2.19 = 11
	  -- ds1FracIfIndex.2. 8 = 4    ds1FracIfIndex.2.20 = 12
          -- ds1FracIfIndex.2. 9 = 4    ds1FracIfIndex.2.21 = 13
	  -- ds1FracIfIndex.2.10 = 4    ds1FracIfIndex.2.22 = 14
	  -- ds1FracIfIndex.2.11 = 4    ds1FracIfIndex.2.23 = 15
	  -- ds1FracIfIndex.2.12 = 5    ds1FracIfIndex.2.24 = 16

          --      For ds1ESF, ds1D4, and ds1ANSI-ESF, there are 24 legal
          --      channels, numbered 1 through 24.
          --
          --      For G.704, there are 32 legal channels, numbered 1
          --      through 32.

          ds1FracTable OBJECT-TYPE
              SYNTAX  SEQUENCE OF DS1FracEntry
              ACCESS  not-accessible
              STATUS  mandatory
              DESCRIPTION
                      "The DS1 Fractional table."
              ::= { ds1 5 }

          ds1FracEntry OBJECT-TYPE
              SYNTAX  DS1FracEntry
              ACCESS  not-accessible
              STATUS  mandatory
              DESCRIPTION
                      "An entry in the DS1 Fractional table."
              INDEX   { ds1FracIndex, ds1FracNumber }
              ::= { ds1FracTable 1 }

          DS1FracEntry ::=
              SEQUENCE {
                  ds1FracIndex
                      INTEGER,
                  ds1FracNumber
                      INTEGER (1..32),
                  ds1FracIfIndex
                      INTEGER
              }

          ds1FracIndex OBJECT-TYPE
              SYNTAX  INTEGER
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The index value which uniquely identifies the DS1
                      interface
                      to which this entry is applicable.  The interface
                      identified by a particular value of this index is
                      the same interface as identified by the same value
                      an ds1LineIndex object instance."
              ::= { ds1FracEntry 1 }

          ds1FracNumber OBJECT-TYPE
              SYNTAX  INTEGER (1..32)
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The channel number for this entry."
              ::= { ds1FracEntry 2 }

          ds1FracIfIndex OBJECT-TYPE
              SYNTAX  INTEGER
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "An index value that uniquely identifies an
                      interface.  The interface identified by a
                      particular value of this index is the same
                      interface as identified by the same value an
                      ifIndex object instance. If no interface is
                      currently using a channel, the value should
                      be zero.  If a single interface occupies more
                      than one time slot, that ifIndex value will
                      be found in multiple time slots."
              ::= { ds1FracEntry 3 }

END










Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa04926;
          26 Jun 92 10:24 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa04922;
          26 Jun 92 10:24 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa12568;
          26 Jun 92 10:25 EDT
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA13534; Fri, 26 Jun 92 07:14:06 PDT
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA02600; Fri, 26 Jun 92 10:16:37 EDT
Return-Path: <tacox@sabre.bellcore.com>
Received: by ginsu4 (4.1/4.7)
	id AA00791; Fri, 26 Jun 92 10:02:30 EDT
Date: Fri, 26 Jun 92 10:02:30 EDT
From: Tracy Cox <tacox@sabre.bellcore.com>
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9206261402.AA00791@ginsu4>
To: trunk-mib@acc.com
Subject: DS1 MIB

Fred,

LESs should be BPVs in all near end
tables and only LESs in the
far end tables.

Unless the group thinks otherwise?

Also in the FarEndGgTotalTable,
why do you skip ds1FarEndGgTotalEntry 4?
Move the last 4 objects up one OID.

I know I am picky picky picky .....


Tracy












Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa05555;
          26 Jun 92 11:31 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa05551;
          26 Jun 92 11:31 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa15348;
          26 Jun 92 11:32 EDT
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA13894; Fri, 26 Jun 92 08:22:58 PDT
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA00532; Fri, 26 Jun 92 11:25:27 EDT
Return-Path: <tacox@sabre.bellcore.com>
Received: by ginsu4 (4.1/4.7)
	id AA00919; Fri, 26 Jun 92 11:11:21 EDT
Date: Fri, 26 Jun 92 11:11:21 EDT
From: Tracy Cox <tacox@sabre.bellcore.com>
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9206261511.AA00919@ginsu4>
To: fbaker@acc.com, trunk-mib@acc.com
Subject: DS1 MIB

Fred,

Why don't we just explicitly state that
ds1NoAlarm is equal to one (1).
Therefore, we advoid the value of zero.

Again, I know that it is picky, but it makes
my life easier.

Therefore, we would have:


		The various bit positions are:
                                 1     ds1NoAlarm
                                 2     ds1FarEndAlarm
                                 4     ds1AlarmIndicationSignal
                                 8     ds1LossOfFrame
                                16     ds1LossOfSignal
                                32     ds1LoopbackState
                                64     ds1T16AlarmIndicationSignal
                               128     ds1LossOfMultiFrame
                               256     ds1DistantLossOfMultiFrame
                               512     ds1DistantLossOfSignal


Thanks.

Tracy










Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa05854;
          26 Jun 92 12:04 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa05850;
          26 Jun 92 12:04 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa16585;
          26 Jun 92 12:05 EDT
Received: from saffron.acc.com by fennel.acc.com (4.1/SMI-4.1)
	id AA14078; Fri, 26 Jun 92 08:56:42 PDT
Received: by saffron.acc.com (4.1/SMI-4.1)
	id AA20498; Fri, 26 Jun 92 08:54:47 PDT
Date: Fri, 26 Jun 92 08:54:47 PDT
From: Fred Baker <fbaker@acc.com>
Message-Id: <9206261554.AA20498@saffron.acc.com>
To: tacox@sabre.bellcore.com
Subject: Re:  DS1 MIB
Cc: trunk-mib@acc.com

>> LESs should be BPVs in all near end tables and only LESs in the
>> far end tables.

>> Unless the group thinks otherwise?

>> Also in the FarEndGgTotalTable, why do you skip
>> ds1FarEndGgTotalEntry 4?  Move the last 4 objects up one OID.

>> I know I am picky picky picky .....

Tut, tut :^}

462c462
<                   ds1IntervalBPVs
---
>                   ds1IntervalLESs
546c546
<           ds1IntervalBPVs OBJECT-TYPE
---
>           ds1IntervalLESs OBJECT-TYPE
605c605
<                   ds1CurrentBPVs
---
>                   ds1CurrentLESs
673c673
<           ds1CurrentBPVs OBJECT-TYPE
---
>           ds1CurrentLESs OBJECT-TYPE
731c731
<                   ds1TotalBPVs
---
>                   ds1TotalLESs
801c801
<           ds1TotalBPVs OBJECT-TYPE
---
>           ds1TotalLESs OBJECT-TYPE
861c861
<                   ds1GgIntervalBPVs
---
>                   ds1GgIntervalLESs
945c945
<           ds1GgIntervalBPVs OBJECT-TYPE
---
>           ds1GgIntervalLESs OBJECT-TYPE
1005c1005
<                   ds1GgTotalBPVs
---
>                   ds1GgTotalLESs
1075c1075
<           ds1GgTotalBPVs OBJECT-TYPE
---
>           ds1GgTotalLESs OBJECT-TYPE
1447c1447
<               ::= { ds1FarEndGgTotalEntry 4 }
---
>               ::= { ds1FarEndGgTotalEntry 5 }
1456c1456
<               ::= { ds1FarEndGgTotalEntry 5 }
---
>               ::= { ds1FarEndGgTotalEntry 6 }
1465c1465
<               ::= { ds1FarEndGgTotalEntry 6 }
---
>               ::= { ds1FarEndGgTotalEntry 7 }
1477c1477
<                        ::= { ds1FarEndGgTotalEntry 7 }
---
>                        ::= { ds1FarEndGgTotalEntry 8 }










Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa06208;
          26 Jun 92 12:42 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa06204;
          26 Jun 92 12:42 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa18155;
          26 Jun 92 12:43 EDT
Received: from saffron.acc.com by fennel.acc.com (4.1/SMI-4.1)
	id AA14700; Fri, 26 Jun 92 09:29:24 PDT
Received: by saffron.acc.com (4.1/SMI-4.1)
	id AA20533; Fri, 26 Jun 92 09:27:29 PDT
Date: Fri, 26 Jun 92 09:27:29 PDT
From: Fred Baker <fbaker@acc.com>
Message-Id: <9206261627.AA20533@saffron.acc.com>
To: tacox@sabre.bellcore.com, trunk-mib@acc.com
Subject: Re:  DS1 MIB

I'm not sure I follow the reasoning, but if you say so...

407a408,409
>               ds1NoAlarm should be set if and only if no other flag is set.
> 
409,418c411,420
<                                  1     ds1FarEndAlarm
<                                  2     ds1AlarmIndicationSignal
<                                  4     ds1LossOfFrame
<                                  8     ds1LossOfSignal
<                                 16     ds1LoopbackState
<                                 32     ds1T16AlarmIndicationSignal
<                                 64     ds1LossOfMultiFrame
<                                128     ds1DistantLossOfMultiFrame
<                                256     ds1DistantLossOfSignal
<               "
---
>                                  1     ds1NoAlarm
>                                  2     ds1FarEndAlarm
>                                  4     ds1AlarmIndicationSignal
>                                  8     ds1LossOfFrame
>                                 16     ds1LossOfSignal
>                                 32     ds1LoopbackState
>                                 64     ds1T16AlarmIndicationSignal
>                                128     ds1LossOfMultiFrame
>                                256     ds1DistantLossOfMultiFrame
>                                512     ds1DistantLossOfSignal"










Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa07587;
          26 Jun 92 15:13 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa07583;
          26 Jun 92 15:12 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa25370;
          26 Jun 92 15:13 EDT
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA15659; Fri, 26 Jun 92 10:28:57 PDT
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA01480; Fri, 26 Jun 92 13:30:56 EDT
Return-Path: <tacox@sabre.bellcore.com>
Received: by ginsu4 (4.1/4.7)
	id AA00982; Fri, 26 Jun 92 13:16:49 EDT
Date: Fri, 26 Jun 92 13:16:49 EDT
From: Tracy Cox <tacox@sabre.bellcore.com>
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9206261716.AA00982@ginsu4>
To: trunk-mib@acc.com
Subject: DS3 MIB

Gang,

Here is the DS3 MIB.  It is consistent
with the latest DS1 MIB.
Any comments?

See you in Boston.

Tracy





          Internet Draft           DS3 Objects                 June 1992


                          Definitions of Managed Objects
                            for the DS3 Interface Type

                                    June 1992
                                    Version 1


                             Trunk MIB Working Group

                              Tracy A. Cox (editor)
                               Kaj Tesink (editor)
                           Bell Communications Research
                             331 Newman Springs Road
                               Red Bank, NJ  07701

                             tacox@sabre.bellcore.com
                            kaj@nvuxr.cc.bellcore.com




          1.  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. Internet Drafts may be updated, replaced, or obsoleted
          by other documents at any time.  It is not appropriate to use
          Internet Drafts as reference material or to cite them other
          than as a "working draft" or "work in progress."

          Please check the I-D abstract listing contained in each
          Internet Draft directory to learn the current status of this
          or any other Internet Draft.

          2.  Abstract

          This memo defines an extension to the Management Information
          Base (MIB) for use with network management protocols in
          TCP/IP-based internets.  In particular, it defines objects for
          managing DS3 objects.  This document is a companion document





          T. Cox & K. Tesink (editors) Expires 11/30/92         [Page 1]





          Internet Draft           DS3 Objects                 June 1992


          with Definitions of Managed Objects for the DS1 Interface
          Type.

          This memo does not specify a standard for the Internet
          community.













































          T. Cox & K. Tesink (editors) Expires 11/30/92         [Page 2]





          Internet Draft           DS3 Objects                 June 1992


          3.  The Network Management Framework

          The Internet-standard Network Management Framework consists of three
          components.  They are:

                RFC 1155 which defines the SMI, the mechanisms used for describing
                and naming objects for the purpose of management.  RFC 1212
                defines a more concise description mechanism, which is wholly
                consistent with the SMI.

                RFC 1156 which defines MIB-I, the core set of managed objects for
                the Internet suite of protocols.  RFC 1213, defines MIB-II, an
                evolution of MIB-I based on implementation experience and new
                operational requirements.

                RFC 1157 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.






























          T. Cox & K. Tesink (editors) Expires 11/30/92         [Page 3]





          Internet Draft           DS3 Objects                 June 1992


          4.  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) [7] 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 [3]
          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 [8], subject to the additional requirements
          imposed by the SNMP.

          4.1.  Format of Definitions

          Section 6 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 RFC1212 [13].

          4.2.  Changes from RFC1233

          The changes from RFC1233 are the following:

          --  This MIB module contains two groups:
               DS3 Near End Group which is mandatory and
               DS3 Far End Group which is optional.

          --  The Far End Group is a new group and contains
              configuration information and statistics





          T. Cox & K. Tesink (editors) Expires 11/30/92         [Page 4]





          Internet Draft           DS3 Objects                 June 1992


              that are collected from the far end DS3 interface.
              The Far End Group may only be implemented by DS3 systems that
              use C-bit Parity or SYNTRAN.

          --  ds3CSUIndex has been renamed ds3LineIndex.  This object
              is the identifier of a DS3 Interface on a device.

          --  ds3Index has been renamed ds3IfIndex.  This value for this
              object is equal to the value of ifIndex from the Interfaces
              table of MIB II (RFC 1213).

          --  ds3Loopback has been deprecated.

          --  A new object has been added called ds3LoopbackConfig,
              which better describes the loopback capabilities of
              a DS3 interface on a device.

          --  ds3YellowAlarm has been deprecated.

          --  ds3RedAlarm has been deprecated.

          --  A new object has been added called ds3LineStatus.
              This object better describes the status (e.g.,
              alarm state and loopback state) of a
              DS3 interface.

          --  ds3CurrentCSSs have been deprecated.

          --  The ds3IntervalTable and the ds3TotalTable have been deprecated and replaced with
              two other tables, ds3GgIntervalTable
              and ds3GgTotalTable, respectively, whose objects have a SYNTAX of
              Gauge.  The objects, ds3GgIntervalCSSs and ds3GgTotalCSSs, do not exist
              in these new tables.

















          T. Cox & K. Tesink (editors) Expires 11/30/92         [Page 5]





          Internet Draft           DS3 Objects                 June 1992


          5.  Overview

          These objects are used when the particular media being used to
          realize an interface is a DS3 interface.  At present, this
          applies to these values of the ifType variable in the
          Internet-standard MIB:

               ds3 (30)

          The definitions contained herein are based on the DS3
          specifications in ANSI T1.102-1987, ANSI T1.107-1988, ANSI
          T1.107a-1990, and ANSI T1.404-1989 [9,10,10a,11].

          5.1.  Binding between ifIndex and DS3 Interfaces

          Different physical configurations for the support of SNMP with
          DS3 equipment exist. To accommodate these scenarios, two
          different indices for DS3 interfaces are introduced in this
          MIB.  These indices are ds3IfIndex and ds3LineIndex.

          External interface scenario: the SNMP Agent represents all
          managed DS3 lines as external interfaces (for example, an
          Agent residing on the device supporting DS3 interfaces
          directly):

          For this scenario, all interfaces are assigned an integer
          value equal to ifIndex, and the following applies:

             ifIndex=ds3IfIndex=ds3LineIndex for all interfaces.

          The ds3IfIndex column of the DS3 Configuration table relates
          each DS3 interface to its corresponding interface (ifIndex) in
          the Internet-standard MIB (MIB-II RFC1213).

          External&Internal interface scenario: the SNMP Agents resides
          on an host external from the device supporting DS3 interfaces
          (e.g., a router). The Agent represents both the host and the
          DS3 device.  The index ds3LineIndex is used to not only
          represent the DS3 interfaces external from the host/DS3-device
          combination, but also the DS3 interfaces connecting the host
          and the DS3 device.  The index ds3IfIndex is always equal to
          ifIndex.

          Example:






          T. Cox & K. Tesink (editors) Expires 11/30/92         [Page 6]





          Internet Draft           DS3 Objects                 June 1992


          A shelf full of CSUs connected to a Router. An SNMP Agent
          residing on the router proxies for itself and the CSU. The
          router has also an Ethernet interface:


                +-----+
          |     |     |
          |     |     |               +---------------------+
          |E    |     |  44.736 MBPS  |   ds3 M13    Line#A | ds3 C-bit Parity
          |t    |  R  |---------------+ - - - - -  - - -  - +------>
          |h    |     |               |                     |
          |e    |  O  |  44.736 MBPS  |   ds3 M13    Line#B | ds3 C-bit Parity
          |r    |     |---------------+ - - - - - - - - - - +------>
          |n    |  U  |               |                     |
          |e    |     |  44.736 MBPS  |   ds3 M13    Line#C | ds3 C-bit Parity
          |t    |  T  |---------------+ - - - -- -- - - - - +------>
          |     |     |               |                     |
          |-----|  E  |  44.736 MBPS  |   ds3 M13    Line#D | ds3 C-bit Parity
          |     |     |---------------+ -  - - - -- - - - - +------>
          |     |  R  |               |_____________________|
          |     |     |
          |     +-----+

          The assignment of the index values could for example be:

                  ifIndex (= ds3IfIndex)                       ds3LineIndex

                          1                   NA                  NA (Ethernet)
                          2      Line#A   Router Side             7
                          2      Line#A   Network Side            6
                          3      Line#B   Router Side             9
                          3      Line#B   Network Side            8
                          4      Line#C   Router Side            11
                          4      Line#C   Network Side           10
                          5      Line#D   Router Side            13
                          5      Line#D   Network Side           12

          For this example, ifNumber is equal to 5.  Note the
          following description of ds3LineIndex:
          the ds3LineIndex identifies a DS3 Interface on a managed
          device.  If there is an ifEntry that is directly associated with
          this and only this DS3 interface, it should have the same value
          as ifIndex.  Otherwise, number the ds3LineIndices with an unique
          identifier following the rules of choosing a number greater
          than ifNumber and numbering inside interfaces (e.g., equipment





          T. Cox & K. Tesink (editors) Expires 11/30/92         [Page 7]





          Internet Draft           DS3 Objects                 June 1992


          side) with even numbers and outside interfaces
          (e.g, network side) with odd numbers.

          If the CSU shelf is managed by itself by a local SNMP Agent,
          the situation would be:


                  ifIndex (= ds3IfIndex)                      ds3LineIndex

                          1      Line#A     RouterSide              1
                          2      Line#A     Network Side            2
                          3      Line#B     RouterSide              3
                          4      Line#B     Network Side            4
                          5      Line#C     Router Side             5
                          6      Line#C     Network Side            6
                          7      Line#D     Router Side             7
                          8      Line#D     Network Side            8


          5.2.  Objectives of this MIB Module

          There are numerous things that could be included in a MIB for
          DS3 signals: the management of multiplexors, CSUs, DSUs, and
          the like.  The intent of this document is to facilitate the
          common management of all devices with DS3 interfaces.  As
          such, a design decision was made up front to very closely
          align the MIB with the set of objects that can generally be
          read from DS3 devices that are currently deployed.

          5.3.  DS3 Terminology

          The terminology used in this document to describe error
          conditions on a DS3 interface as monitored by a DS3 device are
          based on the definitions from the ANSI T1M1.3/92-005 draft
          standard [12].  If the definition in this document does not
          match the definition in the ANSI T1M1.3/92-005 draft document,
          the implementer should follow the definition described in this
          document.

          Bipolar Violation (BPV)
            A bipolar violation, for B3ZS-coded signals, is the
            occurrence of a pulse of the same polarity as the previous
            pulse without being part of the zero substitution code,
            B3ZS.  For B3ZS-coded
            signals, a bipolar violation may also include other error





          T. Cox & K. Tesink (editors) Expires 11/30/92         [Page 8]





          Internet Draft           DS3 Objects                 June 1992


            patterns such as:  three or more consecutive zeros and
            incorrect polarity.

          Coding Violation (CV)
            For all DS3 applications, a coding violation is a P-bit
            Parity Error event.  A P-bit Parity Error event is the
            occurrence of a received P-bit code on the DS3 M-frame
            that is not identical to the corresponding locally-
            calculated code.

          Errored Seconds (ES)
            An ES is a second with one or more Coding Violation OR
            one or more Out of Frame events OR a detected incoming AIS.

          Severely Errored Seconds (SES)
            A SES is a second with 44 or more Coding Violations OR
            one or more Out of Frame events OR a detected incoming AIS.

          Severely Errored Framing Seconds (SEFS)
            A SEFS is a second with one or more Out of Frame events
            OR a detected incoming AIS.

          Unavailable Seconds (UAS)
            UAS are calculated by counting the number of seconds that
            the interface is unavailable.  The DS3 interface is said
            to be unavailable from the onset of 10 contiguous SESs, or
            the onset of the condition leading to a failure (see Alarm
            States).  If the condition leading to the failure was
            immediately preceded by one or more contiguous SESs, then
            the DS3 interface unavailability starts from the onset of these
            SESs.  Once unavailable, and if no failure is present, the DS3
            interface becomes available at the onset of 10 contiguous seconds
            with no SESs.  Once unavailable, and if a failure is present,
            the DS3 interface becomes available at the onset of 10 contiguous
            seconds with no SESs, if the failure clearing time is less than
            or equal to 10 seconds.  If the failure clearing time is more than
            10 seconds, the DS3 interface becomes available at the onset of 10
            contiguous seconds with no SESs, or the onset period leading to the
            successful clearing condition, whichever occurs later.
            With respect to the DS3 error counts, all counters are incremented
            while the DS3 interface is deemed available.  While the interface is
            deemed unavailable, the only count that is incremented is UASs.

            A special case exists when the 10 or more second period
            crosses the 900 second statistics window boundary, as the





          T. Cox & K. Tesink (editors) Expires 11/30/92         [Page 9]





          Internet Draft           DS3 Objects                 June 1992


            foregoing description implies that the SES and UAS
            counters must be adjusted when the Unavailable Signal
            State is entered. Clearly, successive GETs of the
            affected ds3GgIntervalSESs and ds3GgIntervalUASs objects will
            return differing values if the first GET occurs during
            the first few seconds of the window.  This is viewed as
            an unavoidable side-effect of selecting the presently
            defined managed objects as a basis for this memo.

          Alarm States:
            The Far End Alarm (or Yellow Alarm) is declared after detecting
            the Yellow Alarm-Signal.  See ANSI T1.107a-1990 [10].

            Also, the incoming alarm state is declared when a failure condition
            persists for at least 2-10 seconds.  The failure conditions are
            the following:  Loss of
            Signal (LOS), a Loss of Frame (LOF) (a persistent Out
            of Frame event), or an
            Alarm Indication Signal (AIS).
            The Alarm State is cleared at the onset of 10
            consecutive seconds with no SESs.

          Out of Frame (OOF) event
            An OOF event is detected when any three or more errors in
            sixteen or fewer consecutive F-bits occur within a DS3
            M-frame.  An OOF event is cleared when reframe occurs.
            A Loss of Frame (LOF) failure condition is declared when the OOF
            event is consistent for 2 to 10 seconds.  The OOF event ends when
            reframe occurs.  The LOF failure condition is cleared when the OOF
            defect is absent for 10 to 20 seconds.

          Loss of Signal (LOS)
            The LOS event is declared upon observing 175 +/- 75
            contiguous pulse positions with no pulses of either
            positive or negative polarity.
            The LOS is terminated upon observing an average pulse density
            of at least 33% over a period of 175 +/- 75 contiguous pulse
            positions starting with the receipt of a pulse.

          Alarm Indication Signal (AIS)
            The AIS is framed with "stuck stuffing."  This implies
            that it has a valid M-subframe alignments bits, M-frame
            alignment bits, and P bits.  The information bits are set
            to a 1010... sequence, starting with a one (1) after each
            M-subframe alignment bit, M-frame alignment bit, X bit, P bit,





          T. Cox & K. Tesink (editors) Expires 11/30/92        [Page 10]





          Internet Draft           DS3 Objects                 June 1992


            and C bit.  The C bits are all set to zero giving what is called
            "stuck stuffing."  The X bits are set to one.
            The AIS is declared after AIS is present in contiguous M-frames
            for a time equal to or greater than T, where
            0.2 ms <= T <= 100 ms.
            The AIS is terminated after AIS is absent in contiguous M-frames
            for a time equal to or greater than T.

          Circuit Identifier
            This is a character string specified by the circuit
            vendor, and is useful when communicating with the vendor
            during the troubleshooting process.






































          T. Cox & K. Tesink (editors) Expires 11/30/92        [Page 11]





          Internet Draft           DS3 Objects                 June 1992


          6.  Object Definitions

               RFCxxxx-MIB DEFINITIONS ::= BEGIN

               IMPORTS
                       Counter, Gauge
                               FROM RFC1155-SMI
                       DisplayString, transmission
                               FROM RFC1213-MIB
                       OBJECT-TYPE
                               FROM RFC-1212;

               --  This MIB module uses the extended OBJECT-TYPE macro as
               --  defined in RFC 1212.

                       ds3  OBJECT IDENTIFIER ::= { transmission 30 }


































          T. Cox & K. Tesink (editors) Expires 11/30/92        [Page 12]





          Internet Draft           DS3 Objects                 June 1992


               -- The DS3 Near End Group

               -- Implementation of this group is mandatory for all systems
               -- that attach to a DS3 Interface.

               -- The DS3 Near End Group consists of four tables:
               --    DS3 Configuration
               --    DS3 Current
               --    DS3 Gauge Interval
               --    DS3 Gauge Total

               -- the DS3 Configuration

               -- Although the objects in this table are read-only, at the
               -- agent's discretion they may be made read-write so that the
               -- management station, when appropriately authorized, may
               -- change the behavior of the interface, e.g., to place the
               -- interface into a loopback state.

               ds3ConfigTable OBJECT-TYPE
                   SYNTAX  SEQUENCE OF DS3ConfigEntry
                   ACCESS  not-accessible
                   STATUS  mandatory
                   DESCRIPTION
                           "The DS3 Configuration table."
                  ::= { ds3 1 }

              ds3ConfigEntry OBJECT-TYPE
                  SYNTAX  DS3ConfigEntry
                  ACCESS  not-accessible
                  STATUS  mandatory
                  DESCRIPTION
                          "An entry in the DS3 Configuration table."
                 INDEX   { ds3LineIndex }
                 ::= { ds3ConfigTable 1 }

             DS3ConfigEntry ::=
                 SEQUENCE {
                     ds3LineIndex
                         INTEGER,
                     ds3IfIndex
                         INTEGER,
                     ds3TimeElapsed
                         INTEGER,
                     ds3ValidIntervals





          T. Cox & K. Tesink (editors) Expires 11/30/92        [Page 13]





          Internet Draft           DS3 Objects                 June 1992


                         INTEGER,
                     ds3LineType
                         INTEGER,
                     ds3ZeroCoding
                         INTEGER,
                     ds3Loopback
                         INTEGER,
                     ds3SendCode
                         INTEGER,
                     ds3YellowAlarm
                         INTEGER,
                     ds3RedAlarm
                         INTEGER,
                     ds3CircuitIdentifier
                         DisplayString,
                     ds3LoopbackConfig
                         INTEGER,
                     ds3LineStatus
                         INTEGER
             }

             ds3LineIndex OBJECT-TYPE
                 SYNTAX  INTEGER (1..65535)
                 ACCESS  read-only
                 STATUS  mandatory
                 DESCRIPTION
                         "This object is the identifier of a DS3
                         Interface on a managed device.  If there is an
                         ifEntry that is directly associated with this
                         and only this DS3 interface, it should have the
                         same value as ifIndex.  Otherwise, number the
                         ds3LineIndices with an unique identifier
                         following the rules of choicing a number that
                         is greater than ifNumber and numbering the
                         inside interfaces (e.g., equipment side) with
                         even numbers and outside interfaces (e.g,
                         network side) with odd numbers."
                ::= { ds3ConfigEntry 1 }

            ds3IfIndex OBJECT-TYPE
                SYNTAX  INTEGER (1..65535)
                ACCESS  read-only
                STATUS  mandatory
                DESCRIPTION
                        "This value for this object is equal to the





          T. Cox & K. Tesink (editors) Expires 11/30/92        [Page 14]





          Internet Draft           DS3 Objects                 June 1992


                        value of ifIndex from the Interfaces table of
                        MIB II (RFC 1213)."
               ::= { ds3ConfigEntry 2 }

           ds3TimeElapsed OBJECT-TYPE
               SYNTAX  INTEGER (1..900)
               ACCESS  read-only
               STATUS  mandatory
               DESCRIPTION
                       "The number of seconds, including partial
                       seconds, that have elapsed since the beginning of
                       the current error-measurement period."
              ::= { ds3ConfigEntry 3 }

          ds3ValidIntervals OBJECT-TYPE
              SYNTAX  INTEGER (0..96)
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The number of previous intervals for which valid
                      data was collected.  The value will be 96 unless
                      the interface was brought online within the last
                      24 hours, in which case the value will be the
                      number of complete 15 minute intervals the
                      interface has been online."
              ::= { ds3ConfigEntry 4 }

          ds3LineType OBJECT-TYPE
              SYNTAX  INTEGER {
                          other(1),
                          ds3M23(2),
                          ds3SYNTRAN(3),
                          ds3CbitParity(4),
                          ds3ClearChannel(5)
                      }
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "This variable indicates the variety of DS3 C-bit
                      application
                      implementing this interface.  The type of interface
                      affect
                      the interpretation of the usage and error statistics.
                      The rate of all of them is 44.736 Mbps.






          T. Cox & K. Tesink (editors) Expires 11/30/92        [Page 15]





          Internet Draft           DS3 Objects                 June 1992


                      The values, in sequence, describe:

                      TITLE:            SPECIFICATION:
                      ds3M23            ANSI T1.107-1988 [10]
                      ds3SYNTRAN        ANSI T1.107-1988 [10]
                      ds3C-bit Parity   ANSI T1.107a-1989 [10a]
                      ds3Clear Channel  ANSI T1.102-1987 [9]."
              ::= { ds3ConfigEntry 5 }

          ds3ZeroCoding OBJECT-TYPE
              SYNTAX  INTEGER {
                          ds3Other(1),
                          ds3B3ZS(2)
                      }
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "This variable describes the variety of Zero Code
                      Suppression used on this interface, which in turn
                      affects a number of its characteristics.

                      DS3B3ZS refer to the use of specified patterns of
                      normal bits and bipolar violations which are used
                      to replace sequences of zero bits of a specified
                      length."
              ::= { ds3ConfigEntry 6 }

          ds3Loopback OBJECT-TYPE
                    SYNTAX  INTEGER {
                            ds3NoLoop(1),
                            ds3LocalLoopbackLocalSide(2),
                            ds3LocalLoopbackRemoteSide(3),
                            ds3RemoteLoopbackLocalSide(4),
                            ds3RemoteLoopbackRemoteSide(5)
                            }
                    ACCESS  read-only
                    STATUS  deprecated
                    DESCRIPTION
                        "This variable represents the loopback state of
                        the device.  Agents supporting read/write access
                        should return badValue in response to a requested
                        loopback state that the device does not support.
                        The values mean:

                        ds3NoLoop





          T. Cox & K. Tesink (editors) Expires 11/30/92        [Page 16]





          Internet Draft           DS3 Objects                 June 1992


                           Not in the loopback state.  A device that is
                           not capable of performing a loopback on
                           either interface shall always return this as
                           it's value.

                        ds3LocalLoopbackLocalSide
                           Signal received from the local side of the
                           device is looped back at the local connector
                           (eg, without involving the device).

                        ds3LocalLoopbackRemoteSide
                           Signal received from the local side of the
                           device is looped back at the remote connector
                           (eg, through the device).

                        ds3RemoteLoopbackLocalSide
                           Signal received from the remote side of the
                           device is looped back at the local connector
                           (eg, through the device).

                        ds3RemoteLoopbackRemoteSide
                           Signal received from the remote side of the
                           device is looped back at the remote connector
                           (eg, without involving the device)."
                    ::= { ds3ConfigEntry 7 }

          ds3SendCode OBJECT-TYPE
                 SYNTAX  INTEGER {
                         ds3SendTestMessage(1),
                         ds3SendNoCode(2),
                         ds3SendSetCode(3),
                         ds3SendLoopbackCode(4),
                         ds3SendResetCode(5)
                         }
                 ACCESS  read-only
                 STATUS  mandatory
                 DESCRIPTION
                      "This variable indicates what type of code is
                      being sent across the DS3 interface by the device.
                      The values mean:

                          ds3SendNoCode
                            sending looped or normal data

                          ds3SendSetCode





          T. Cox & K. Tesink (editors) Expires 11/30/92        [Page 17]





          Internet Draft           DS3 Objects                 June 1992


                            sending a loopback request

                          ds3SendLoopbackCode
                            sending a loopback test code/pattern

                          ds3SendResetCode
                            sending a loopback termination request

                          ds3SendTestMessage
                            sending a Test pattern as defined in
                            T1.107a-1990."
                 ::= { ds3ConfigEntry 8 }

          ds3YellowAlarm OBJECT-TYPE
              SYNTAX  INTEGER {
                      ds3YellowAlarm(1),
                      ds3NoYellowAlarm(2)
                      }
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "This variable indicates if a Yellow Alarm
                      condition exists."
              ::= { ds3ConfigEntry 9 }

          ds3RedAlarm OBJECT-TYPE
              SYNTAX  INTEGER {
                          ds3RedAlarm(1),
                          ds3NoRedAlarm(2)
                      }
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "This variable indicates if a Red Alarm condition
                      exists."
              ::= { ds3ConfigEntry 10 }

          ds3CircuitIdentifier OBJECT-TYPE
              SYNTAX  DisplayString (SIZE (0..255))
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "This variable contains the transmission vendor's
                      circuit identifier, for the purpose of
                      facilitating troubleshooting."





          T. Cox & K. Tesink (editors) Expires 11/30/92        [Page 18]





          Internet Draft           DS3 Objects                 June 1992


              ::= { ds3ConfigEntry 11 }

          ds3LoopbackConfig OBJECT-TYPE
                 SYNTAX  INTEGER {
                           ds3NoLoop(1),
                           ds3MgrPayloadLoop(2),
                           ds3MgrLineLoop(3),
                           ds3NetReqPayloadLoop(4),
                           ds3NetReqLineLoop(5),
                           ds3OtherLoop(6)
                         }
                 ACCESS  read-only
                 STATUS  mandatory
                 DESCRIPTION
                    "This variable represents the loopback configuration
                    of the DS3 interface.  Agents supporting read/write
                    access should return badValue in response to a
                    requested loopback state that the interface does not
                    support.  The values mean:

                    ds3NoLoop
                      Not in the loopback state.  A device that is
                      not capable of performing a loopback on
                      the interface shall always return this as
                      it's value.

                    ds3MgrPayloadLoop
                      The received signal at this interface is looped through
                      the device; this loopback is initiated by a
                      manager of the device. Typically the received signal
                      is looped back for retransmission after it has
                      passed through the device's framing function.

                    ds3MgrLineLoop
                      The received signal at this interface does not
                      go through the device (minimum penetration) but
                      is looped back out; this loopback is initiated
                      by a manager of the device.

                    ds3NetReqPayloadLoop
                      The received signal at this interface is looped through
                      the device; this loopback is initiated/requested by the
                      far end equipment. Typically the received signal
                      is looped back for retransmission after it has
                      passed through the device's framing function.





          T. Cox & K. Tesink (editors) Expires 11/30/92        [Page 19]





          Internet Draft           DS3 Objects                 June 1992


                    ds3NetReqLineLoop
                      The received signal at this interface does not
                      go through the device (minimum penetration) but
                      is looped back out; this loopback is initiated/requested
                      by the far end equipment.

                    ds3OtherLoop
                      Loopbacks that are not defined here."
                 ::= { ds3ConfigEntry 12 }

          ds3LineStatus OBJECT-TYPE
              SYNTAX  INTEGER
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                 "This variable indicates the
                 Line Status of the interface.
                 It contains loopback state information
                 and alarm state information.
                 The ds3LineStatus is a bit map represented
                 as a sum, therefore,
                 it can represent multiple alarms and a LoopbackState
                 simultaneously.
                 The ds3NoAlarm should be set if and only if
                 no other flag is set.

                 The various bit positions are:
                            1     ds3NoAlarm
                            2     ds3FarEndAlarm
                            4     ds3AlarmIndicationSignal
                            8     ds3LossOfFrame
                           16     ds3LossOfSignal
                           32     ds3LoopbackState"
              ::= { ds3ConfigEntry 13 }
















          T. Cox & K. Tesink (editors) Expires 11/30/92        [Page 20]





          Internet Draft           DS3 Objects                 June 1992


          -- the DS3 Interval

          -- The DS3 Interval Table contains various statistics
          -- collected by each DS3 Interface over the previous 24 hours of
          -- operation.  The past 24 hours are broken into 96 completed
          -- 15 minute intervals.
          -- This table has been deprecated and replaced by ds3GgIntervalTable.

          ds3IntervalTable OBJECT-TYPE
              SYNTAX  SEQUENCE OF DS3IntervalEntry
              ACCESS  not-accessible
              STATUS  deprecated
              DESCRIPTION
                      "The DS3 Interval table."
              ::= { ds3 2 }

          ds3IntervalEntry OBJECT-TYPE
              SYNTAX  DS3IntervalEntry
              ACCESS  not-accessible
              STATUS  deprecated
              DESCRIPTION
                      "An entry in the DS3 Interval table."
              INDEX   { ds3IntervalIndex, ds3IntervalNumber }
              ::= { ds3IntervalTable 1 }

          DS3IntervalEntry ::=
              SEQUENCE {
                  ds3IntervalIndex
                      INTEGER,
                  ds3IntervalNumber
                      INTEGER,
                  ds3IntervalESs
                      Counter,
                  ds3IntervalSESs
                      Counter,
                  ds3IntervalSEFSs
                      Counter,
                  ds3IntervalUASs
                      Counter,
                  ds3IntervalCSSs
                      Counter,
                  ds3IntervalBPVs
                      Counter,
                  ds3IntervalCVs
                      Counter





          T. Cox & K. Tesink (editors) Expires 11/30/92        [Page 21]





          Internet Draft           DS3 Objects                 June 1992


              }

          ds3IntervalIndex OBJECT-TYPE
              SYNTAX  INTEGER (1..65535)
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "The index value which uniquely identifies the DS3
                      interface to which this entry is applicable.  The
                      interface identified by a particular value of this
                      index is the same interface as identified by the
                      same value an DS3LineIndex object instance."
              ::= { ds3IntervalEntry 1 }

          ds3IntervalNumber OBJECT-TYPE
              SYNTAX  INTEGER (1..96)
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "A number between 1 and 96, where 1 is the most
                      recently completed 15 minute interval and 96 is
                      the least recently completed 15 minutes interval
                      (assuming that all 96 intervals are valid)."
              ::= { ds3IntervalEntry 2 }

          ds3IntervalESs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "The counter associated with the number of Errored
                      Seconds, encountered by a DS3 interface in one of
                      the previous 96, individual 15 minute, intervals."
              ::= { ds3IntervalEntry 3 }

          ds3IntervalSESs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "The counter associated with the number of
                      Severely Errored Seconds, encountered by a DS3
                      interface in one of the previous 96, individual 15
                      minute, intervals."
              ::= { ds3IntervalEntry 4 }





          T. Cox & K. Tesink (editors) Expires 11/30/92        [Page 22]





          Internet Draft           DS3 Objects                 June 1992


          ds3IntervalSEFSs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "The counter associated with the number of
                      Severely Errored Framing Seconds, encountered by a
                      DS3 interface in one of the previous 96,
                      individual 15 minute, intervals."
              ::= { ds3IntervalEntry 5 }

          ds3IntervalUASs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "The counter associated with the number of
                      Unavailable Seconds, encountered by a DS3
                      interface in one of the previous 96, individual 15
                      minute, intervals."
              ::= { ds3IntervalEntry 6 }

          ds3IntervalCSSs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "The counter associated with the number of
                      Controlled Slip Seconds, encountered by a DS3
                      interface in one of the previous 96, individual 15
                      minute, intervals."
              ::= { ds3IntervalEntry 7 }

          ds3IntervalBPVs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "The counter associated with the number of Bipolar
                      Violations, encountered by a DS3 interface in one
                      of the previous 96, individual 15 minute,
                      intervals."
              ::= { ds3IntervalEntry 8 }

          ds3IntervalCVs OBJECT-TYPE





          T. Cox & K. Tesink (editors) Expires 11/30/92        [Page 23]





          Internet Draft           DS3 Objects                 June 1992


              SYNTAX  Counter
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "The counter associated with the number of Coding
                      Violations, encountered by a DS3 interface in one
                      of the previous 96, individual 15 minute,
                      intervals."
              ::= { ds3IntervalEntry 9 }









































          T. Cox & K. Tesink (editors) Expires 11/30/92        [Page 24]





          Internet Draft           DS3 Objects                 June 1992


          -- the DS3 Current

          -- The DS3 current table contains various statistics being
          -- collected for the current 15 minute interval.
          -- Each 15 minute interval is measured in
          -- seconds and is clocked by ds3TimeElapsed.
          -- At the end of a 15 minute interval, (ds3TimeElapsed = 900),
          -- all the counters are reset
          -- to zero and begin to count again.

          ds3CurrentTable OBJECT-TYPE
              SYNTAX  SEQUENCE OF DS3CurrentEntry
              ACCESS  not-accessible
              STATUS  mandatory
              DESCRIPTION
                      "The DS3 Current table."
              ::= { ds3 3 }

          ds3CurrentEntry OBJECT-TYPE
              SYNTAX  DS3CurrentEntry
              ACCESS  not-accessible
              STATUS  mandatory
              DESCRIPTION
                      "An entry in the DS3 Current table."
              INDEX   { ds3CurrentIndex }
              ::= { ds3CurrentTable 1 }

          DS3CurrentEntry ::=
              SEQUENCE {
                  ds3CurrentIndex
                      INTEGER,
                  ds3CurrentESs
                      Counter,
                  ds3CurrentSESs
                      Counter,
                  ds3CurrentSEFSs
                      Counter,
                  ds3CurrentUASs
                      Counter,
                  ds3CurrentCSSs
                      Counter,
                  ds3CurrentBPVs
                      Counter,
                  ds3CurrentCVs
                      Counter





          T. Cox & K. Tesink (editors) Expires 11/30/92        [Page 25]





          Internet Draft           DS3 Objects                 June 1992


              }

          ds3CurrentIndex OBJECT-TYPE
              SYNTAX  INTEGER (1..65535)
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The index value which uniquely identifies the DS3
                      interface to which this entry is applicable.  The
                      interface identified by a particular value of this
                      index is the same interface as identified by the
                      same value an DS3LineIndex object instance."
              ::= { ds3CurrentEntry 1 }

          ds3CurrentESs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Errored
                      Seconds, encountered by a DS3 interface in the
                      current 15 minute interval."
              ::= { ds3CurrentEntry 2 }

          ds3CurrentSESs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of
                      Severely Errored Seconds, encountered by a DS3
                      interface in the current 15 minute interval."
              ::= { ds3CurrentEntry 3 }

          ds3CurrentSEFSs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of
                      Severely Errored Framing Seconds, encountered by a
                      DS3 interface in the current 15 minute interval."
              ::= { ds3CurrentEntry 4 }

          ds3CurrentUASs OBJECT-TYPE





          T. Cox & K. Tesink (editors) Expires 11/30/92        [Page 26]





          Internet Draft           DS3 Objects                 June 1992


              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of
                      Unavailable Seconds, encountered by a DS3
                      interface in the current 15 minute interval."
              ::= { ds3CurrentEntry 5 }

          ds3CurrentCSSs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "The counter associated with the number of
                      Controlled Slip Seconds, encountered by a DS3
                      interface in the current 15 minute interval."
              ::= { ds3CurrentEntry 6 }

          ds3CurrentBPVs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Bipolar
                      Violations, encountered by a DS3 interface in the
                      current 15 minute interval."
              ::= { ds3CurrentEntry 7 }

          ds3CurrentCVs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Coding
                      Violations, encountered by a DS3 interface in the
                      current 15 minute interval."
              ::= { ds3CurrentEntry 8 }












          T. Cox & K. Tesink (editors) Expires 11/30/92        [Page 27]





          Internet Draft           DS3 Objects                 June 1992


          -- the DS3 Total

          -- The DS3 Total Table contains the cumulative sum of the
          -- various statistics for the 24 hour interval preceding the
          -- first valid interval in the DS3CurrentTable.
          -- This table has been deprecated and replaced by ds3GgTotalTable.

          ds3TotalTable OBJECT-TYPE
              SYNTAX  SEQUENCE OF DS3TotalEntry
              ACCESS  not-accessible
              STATUS  deprecated
              DESCRIPTION
                      "The DS3 Total table.  24 hour interval."
              ::= { ds3 4 }

          ds3TotalEntry OBJECT-TYPE
              SYNTAX  DS3TotalEntry
              ACCESS  not-accessible
              STATUS  deprecated
              DESCRIPTION
                      "An entry in the DS3 Total table."
              INDEX   { ds3TotalIndex }
              ::= { ds3TotalTable 1 }

          DS3TotalEntry ::=
              SEQUENCE {
                  ds3TotalIndex
                      INTEGER,
                  ds3TotalESs
                      Counter,
                  ds3TotalSESs
                      Counter,
                  ds3TotalSEFSs
                      Counter,
                  ds3TotalUASs
                      Counter,
                  ds3TotalCSSs
                      Counter,
                  ds3TotalBPVs
                      Counter,
                  ds3TotalCVs
                      Counter
              }

          ds3TotalIndex OBJECT-TYPE





          T. Cox & K. Tesink (editors) Expires 11/30/92        [Page 28]





          Internet Draft           DS3 Objects                 June 1992


              SYNTAX  INTEGER (1..65535)
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "The index value which uniquely identifies the DS3
                      interface to which this entry is applicable.  The
                      interface identified by a particular value of this
                      index is the same interface as identified by the
                      same value an DS3LineIndex object instance."
              ::= { ds3TotalEntry 1 }

          ds3TotalESs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "The counter associated with the number of Errored
                      Seconds, encountered by a DS3 interface in the
                      previous 24 hour interval"
              ::= { ds3TotalEntry 2 }

          ds3TotalSESs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "The counter associated with the number of
                      Severely Errored Seconds, encountered by a DS3
                      interface in the previous 24 hour interval."
              ::= { ds3TotalEntry 3 }

          ds3TotalSEFSs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "The counter associated with the number of
                      Severely Errored Framing Seconds, encountered by a
                      DS3 interface in the previous 24 hour interval."
              ::= { ds3TotalEntry 4 }

          ds3TotalUASs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  deprecated





          T. Cox & K. Tesink (editors) Expires 11/30/92        [Page 29]





          Internet Draft           DS3 Objects                 June 1992


              DESCRIPTION
                      "The counter associated with the number of
                      Unavailable Seconds, encountered by a DS3
                      interface in the previous 24 hour interval."
              ::= { ds3TotalEntry 5 }

          ds3TotalCSSs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "The counter associated with the number of
                      Controlled Slip Seconds, encountered by a DS3
                      interface in the previous 24 hour interval."
              ::= { ds3TotalEntry 6 }

          ds3TotalBPVs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "The counter associated with the number of Bipolar
                      Violations, encountered by a DS3 interface in the
                      previous 24 hour interval."
              ::= { ds3TotalEntry 7 }

          ds3TotalCVs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  deprecated
              DESCRIPTION
                      "The counter associated with the number of Coding
                      Violations, encountered by a DS3 interface in the
                      previous 24 hour interval."
              ::= { ds3TotalEntry 8 }















          T. Cox & K. Tesink (editors) Expires 11/30/92        [Page 30]





          Internet Draft           DS3 Objects                 June 1992


          -- the DS3 Gauge Interval

          -- The DS3 Gauge Interval Table contains various statistics
          -- collected by each DS3 Interface over the previous 24 hours of
          -- operation.  The past 24 hours are broken into 96 completed
          -- 15 minute intervals.  Each 15 minute interval is measured in
          -- seconds and is clocked by ds3TimeElapsed.

          -- For example, at the end of a 15 minute interval,
          -- (ds3TimeElapsed = 900),
          -- ds3CurrentCVs.1 becomes ds3GgIntervalCVs.1.1,
          -- ds3GgIntervalCVs.1.n becomes ds3GgIntervalCVs.1.n+1,
          -- (for n 1 to 95), and
          -- ds3GgIntervalCVs.1.96 is erased.

          ds3GgIntervalTable OBJECT-TYPE
              SYNTAX  SEQUENCE OF DS3GgIntervalEntry
              ACCESS  not-accessible
              STATUS  mandatory
              DESCRIPTION
                      "The DS3 Gauge Interval table."
              ::= { ds3 5 }

          ds3GgIntervalEntry OBJECT-TYPE
              SYNTAX  DS3GgIntervalEntry
              ACCESS  not-accessible
              STATUS  mandatory
              DESCRIPTION
                      "An entry in the DS3 Gauge Interval table."
              INDEX   { ds3GgIntervalIndex, ds3GgIntervalNumber }
              ::= { ds3GgIntervalTable 1 }

          DS3GgIntervalEntry ::=
              SEQUENCE {
                  ds3GgIntervalIndex
                      INTEGER,
                  ds3GgIntervalNumber
                      INTEGER,
                  ds3GgIntervalESs
                      Gauge,
                  ds3GgIntervalSESs
                      Gauge,
                  ds3GgIntervalSEFSs
                      Gauge,
                  ds3GgIntervalUASs





          T. Cox & K. Tesink (editors) Expires 11/30/92        [Page 31]





          Internet Draft           DS3 Objects                 June 1992


                      Gauge,
                  ds3GgIntervalBPVs
                      Gauge,
                  ds3GgIntervalCVs
                      Gauge
              }

          ds3GgIntervalIndex OBJECT-TYPE
              SYNTAX  INTEGER (1..65535)
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The index value which uniquely identifies the DS3
                      interface to which this entry is applicable.  The
                      interface identified by a particular value of this
                      index is the same interface as identified by the
                      same value an DS3LineIndex object instance."
              ::= { ds3GgIntervalEntry 1 }

          ds3GgIntervalNumber OBJECT-TYPE
              SYNTAX  INTEGER (1..96)
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "A number between 1 and 96, where 1 is the most
                      recently completed 15 minute interval and 96 is
                      the least recently completed 15 minutes interval
                      (assuming that all 96 intervals are valid)."
              ::= { ds3GgIntervalEntry 2 }

          ds3GgIntervalESs OBJECT-TYPE
              SYNTAX  Gauge
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Errored
                      Seconds, encountered by a DS3 interface in one of
                      the previous 96, individual 15 minute, intervals."
              ::= { ds3GgIntervalEntry 3 }

          ds3GgIntervalSESs OBJECT-TYPE
              SYNTAX  Gauge
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION





          T. Cox & K. Tesink (editors) Expires 11/30/92        [Page 32]





          Internet Draft           DS3 Objects                 June 1992


                      "The counter associated with the number of
                      Severely Errored Seconds, encountered by a DS3
                      interface in one of the previous 96, individual 15
                      minute, intervals."
              ::= { ds3GgIntervalEntry 4 }

          ds3GgIntervalSEFSs OBJECT-TYPE
              SYNTAX  Gauge
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of
                      Severely Errored Framing Seconds, encountered by a
                      DS3 interface in one of the previous 96,
                      individual 15 minute, intervals."
              ::= { ds3GgIntervalEntry 5 }

          ds3GgIntervalUASs OBJECT-TYPE
              SYNTAX  Gauge
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of
                      Unavailable Seconds, encountered by a DS3
                      interface in one of the previous 96, individual 15
                      minute, intervals."
              ::= { ds3GgIntervalEntry 6 }

          ds3GgIntervalBPVs OBJECT-TYPE
              SYNTAX  Gauge
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Bipolar
                      Violations, encountered by a DS3 interface in one
                      of the previous 96, individual 15 minute,
                      intervals."
              ::= { ds3GgIntervalEntry 7 }

          ds3GgIntervalCVs OBJECT-TYPE
              SYNTAX  Gauge
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Coding





          T. Cox & K. Tesink (editors) Expires 11/30/92        [Page 33]





          Internet Draft           DS3 Objects                 June 1992


                      Violations, encountered by a DS3 interface in one
                      of the previous 96, individual 15 minute,
                      intervals."
              ::= { ds3GgIntervalEntry 8 }














































          T. Cox & K. Tesink (editors) Expires 11/30/92        [Page 34]





          Internet Draft           DS3 Objects                 June 1992


          -- the DS3 Gauge Total

          -- The DS3 Gauge Total Table contains the cumulative sum of the
          -- various statistics for the 24 hour interval preceding the
          -- first valid 15 minute interval in the DS3CurrentTable.
          -- Each 15 minute interval is measured in
          -- seconds and is clocked by ds3TimeElapsed.

          -- The values of the objects in the
          -- ds3GgTotalTable is the sum of the values of the objects of
          -- the 96 15 minute intervals in
          -- the ds3GgIntervalTable.

          ds3GgTotalTable OBJECT-TYPE
              SYNTAX  SEQUENCE OF DS3GgTotalEntry
              ACCESS  not-accessible
              STATUS  mandatory
              DESCRIPTION
                      "The DS3 Gauge Total table.  24 hour interval."
              ::= { ds3 6 }

          ds3GgTotalEntry OBJECT-TYPE
              SYNTAX  DS3GgTotalEntry
              ACCESS  not-accessible
              STATUS  mandatory
              DESCRIPTION
                      "An entry in the DS3 Gauge Total table."
              INDEX   { ds3GgTotalIndex }
              ::= { ds3GgTotalTable 1 }

          DS3GgTotalEntry ::=
              SEQUENCE {
                  ds3GgTotalIndex
                      INTEGER,
                  ds3GgTotalESs
                      Gauge,
                  ds3GgTotalSESs
                      Gauge,
                  ds3GgTotalSEFSs
                      Gauge,
                  ds3GgTotalUASs
                      Gauge,
                  ds3GgTotalBPVs
                      Gauge,
                  ds3GgTotalCVs





          T. Cox & K. Tesink (editors) Expires 11/30/92        [Page 35]





          Internet Draft           DS3 Objects                 June 1992


                      Gauge
              }

          ds3GgTotalIndex OBJECT-TYPE
              SYNTAX  INTEGER (1..65535)
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The index value which uniquely identifies the DS3
                      interface to which this entry is applicable.  The
                      interface identified by a particular value of this
                      index is the same interface as identified by the
                      same value an DS3LineIndex object instance."
              ::= { ds3GgTotalEntry 1 }

          ds3GgTotalESs OBJECT-TYPE
              SYNTAX  Gauge
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Errored
                      Seconds, encountered by a DS3 interface in the
                      previous 24 hour interval"
              ::= { ds3GgTotalEntry 2 }

          ds3GgTotalSESs OBJECT-TYPE
              SYNTAX  Gauge
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of
                      Severely Errored Seconds, encountered by a DS3
                      interface in the previous 24 hour interval."
              ::= { ds3GgTotalEntry 3 }

          ds3GgTotalSEFSs OBJECT-TYPE
              SYNTAX  Gauge
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of
                      Severely Errored Framing Seconds, encountered by a
                      DS3 interface in the previous 24 hour interval."
              ::= { ds3GgTotalEntry 4 }






          T. Cox & K. Tesink (editors) Expires 11/30/92        [Page 36]





          Internet Draft           DS3 Objects                 June 1992


          ds3GgTotalUASs OBJECT-TYPE
              SYNTAX  Gauge
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of
                      Unavailable Seconds, encountered by a DS3
                      interface in the previous 24 hour interval."
              ::= { ds3GgTotalEntry 5 }

          ds3GgTotalBPVs OBJECT-TYPE
              SYNTAX  Gauge
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Bipolar
                      Violations, encountered by a DS3 interface in the
                      previous 24 hour interval."
              ::= { ds3GgTotalEntry 6 }

          ds3GgTotalCVs OBJECT-TYPE
              SYNTAX  Gauge
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Coding
                      Violations, encountered by a DS3 interface in the
                      previous 24 hour interval."
              ::= { ds3GgTotalEntry 7 }





















          T. Cox & K. Tesink (editors) Expires 11/30/92        [Page 37]





          Internet Draft           DS3 Objects                 June 1992


          -- The DS3 Far End Group

          -- Implementation of this group is optional for all systems
          -- that attach to a DS3 Interface.
          -- However, only C-bit Parity and SYNTRAN applications
          -- have the capability (option) of providing this information.

          -- The DS3 Far End Group consists of four tables:
          --   DS3 Far End Configuration
          --   DS3 Far End Current
          --   DS3 Far End Gauge Interval
          --   DS3 Far End Gauge Total


          -- The DS3 Far End Configuration Table contains
          -- configuration information
          -- reported in the C-bits from the remote end.

          ds3FarEndConfigTable OBJECT-TYPE
              SYNTAX  SEQUENCE OF DS3FarEndConfigEntry
              ACCESS  not-accessible
              STATUS  mandatory
              DESCRIPTION
                 "The DS3 Far End Configuration table."
              ::= { ds3 7 }

          ds3FarEndConfigEntry OBJECT-TYPE
              SYNTAX  DS3FarEndConfigEntry
              ACCESS  not-accessible
              STATUS  mandatory
              DESCRIPTION
                   "An entry in the DS3 Far End Configuration table."
              INDEX   { ds3FarEndLineIndex }
              ::= { ds3FarEndConfigTable 1 }

          DS3FarEndConfigEntry ::=
              SEQUENCE {
                  ds3FarEndLineIndex
                      INTEGER,
                  ds3FarEndEquipCode
                      DisplayString,
                  ds3FarEndLocationIDCode
                      DisplayString,
                  ds3FarEndFrameIDCode
                      DisplayString,





          T. Cox & K. Tesink (editors) Expires 11/30/92        [Page 38]





          Internet Draft           DS3 Objects                 June 1992


                  ds3FarEndUnitCode
                      DisplayString,
                  ds3FarEndFacilityIDCode
                      DisplayString
               }

          ds3FarEndLineIndex OBJECT-TYPE
              SYNTAX  INTEGER (1..65535)
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                   "The index value which uniquely identifies the
                   DS3 interface
                   to which this entry is applicable.  The
                   interface identified by a particular value of
                   this index is the same interface as identified
                   by the same value an DS3LineIndex object
                   instance."
             ::= { ds3FarEndConfigEntry 1 }

          ds3FarEndEquipCode OBJECT-TYPE
              SYNTAX  DisplayString (SIZE (0..10))
              ACCESS  read-write
              STATUS  mandatory
              DESCRIPTION
                    "This is the Far End Equipment Identification code
                    that describes the specific piece of equipment.
                    It is sent within the Path
                    Identification Message."
              ::= { ds3FarEndConfigEntry 2 }

          ds3FarEndLocationIDCode OBJECT-TYPE
              SYNTAX  DisplayString (SIZE (0..11))
              ACCESS  read-write
              STATUS  mandatory
              DESCRIPTION
                    "This is the Far End Location Identification code
                    that describes the specific location of the equipment.
                    It is sent within the Path
                    Identification Message."
              ::= { ds3FarEndConfigEntry 3 }

          ds3FarEndFrameIDCode OBJECT-TYPE
              SYNTAX  DisplayString (SIZE (0..10))
              ACCESS  read-write





          T. Cox & K. Tesink (editors) Expires 11/30/92        [Page 39]





          Internet Draft           DS3 Objects                 June 1992


              STATUS  mandatory
              DESCRIPTION
                    "This is the Far End Frame Identification code
                    that identifies where the equipment is located
                    within a building at a given location.
                    It is sent within the Path
                    Identification Message."
              ::= { ds3FarEndConfigEntry 4 }

          ds3FarEndUnitCode OBJECT-TYPE
              SYNTAX  DisplayString (SIZE (0..6))
              ACCESS  read-write
              STATUS  mandatory
              DESCRIPTION
                    "This is the Far End code
                    that identifies the equipment location within a bay.
                    It is sent within the Path
                    Identification Message."
              ::= { ds3FarEndConfigEntry 5 }

          ds3FarEndFacilityIDCode OBJECT-TYPE
              SYNTAX  DisplayString (SIZE (0..38))
              ACCESS  read-write
              STATUS  mandatory
              DESCRIPTION
                    "This code identifies a specific Far End DS3 path.
                    It is sent within the Path
                    Identification Message."
              ::= { ds3FarEndConfigEntry 6 }





















          T. Cox & K. Tesink (editors) Expires 11/30/92        [Page 40]





          Internet Draft           DS3 Objects                 June 1992


          -- The DS3 Far End Current

          -- The DS3 Far End Current table contains various statistics being
          -- collected for the current 15 minute interval.
          -- The statistics are collected from the far end block error code
          -- within the C-bits.  The definitions are the same as described for
          -- the near-end information.

          ds3FarEndCurrentTable OBJECT-TYPE
              SYNTAX  SEQUENCE OF DS3FarEndCurrentEntry
              ACCESS  not-accessible
              STATUS  mandatory
              DESCRIPTION
                      "The DS3 Far End Current table."
              ::= { ds3 8 }

          ds3FarEndCurrentEntry OBJECT-TYPE
              SYNTAX  DS3FarEndCurrentEntry
              ACCESS  not-accessible
              STATUS  mandatory
              DESCRIPTION
                      "An entry in the DS3 Far End Current table."
              INDEX   { ds3FarEndCurrentIndex }
              ::= { ds3FarEndCurrentTable 1 }

          DS3FarEndCurrentEntry ::=
              SEQUENCE {
                  ds3FarEndCurrentIndex
                      INTEGER,
                  ds3FarEndCurrentESs
                      Counter,
                  ds3FarEndCurrentSESs
                      Counter,
                  ds3FarEndCurrentCVs
                      Counter
              }

           ds3FarEndCurrentIndex OBJECT-TYPE
              SYNTAX  INTEGER (1..65535)
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The index value which uniquely identifies the
                      DS3 interface
                      to which this entry is applicable.  The interface





          T. Cox & K. Tesink (editors) Expires 11/30/92        [Page 41]





          Internet Draft           DS3 Objects                 June 1992


                      identified by a particular value of this index is
                      the same interface as identified by the same value
                      an DS3LineIndex object instance."
              ::= { ds3FarEndCurrentEntry 1 }

          ds3FarEndCurrentESs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of Far
                      Far End Errored Seconds encountered by a DS3
                      interface in the current 15 minute interval."
              ::= { ds3FarEndCurrentEntry 2 }

          ds3FarEndCurrentSESs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of
                      Far End Severely Errored Seconds
                      encountered by a DS3 interface in the current 15 minute
                      interval."
              ::= { ds3FarEndCurrentEntry 3 }

          ds3FarEndCurrentCVs OBJECT-TYPE
              SYNTAX  Counter
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of
                      Far End Coding Violations reported via
                      the far end block error count
                      encountered by a
                      DS3 interface in the current 15 minute interval."
              ::= { ds3FarEndCurrentEntry 4 }













          T. Cox & K. Tesink (editors) Expires 11/30/92        [Page 42]





          Internet Draft           DS3 Objects                 June 1992


          -- The DS3 Far End Gauge Interval

          -- The DS3 Far End Gauge Interval Table contains various statistics
          -- collected by each DS3 interface over the previous 24 hours of
          -- operation.  The past 24 hours are broken into 96
          -- completed 15 minute intervals. The definitions are the same
          -- as described for the near-end information.

          ds3FarEndGgIntervalTable OBJECT-TYPE
              SYNTAX  SEQUENCE OF DS3FarEndGgIntervalEntry
              ACCESS  not-accessible
              STATUS  mandatory
              DESCRIPTION
                     "The DS3 Far End Gauge Interval table."
              ::= { ds3 9 }

          ds3FarEndGgIntervalEntry OBJECT-TYPE
              SYNTAX  DS3FarEndGgIntervalEntry
              ACCESS  not-accessible
              STATUS  mandatory
              DESCRIPTION
                    "An entry in the DS3 Far
                    End Gauge Interval table."
              INDEX   { ds3FarEndGgIntervalIndex, ds3FarEndGgIntervalNumber }
              ::= { ds3FarEndGgIntervalTable 1 }

          DS3FarEndGgIntervalEntry ::=
              SEQUENCE {
                   ds3FarEndGgIntervalIndex
                        INTEGER,
                   ds3FarEndGgIntervalNumber
                        INTEGER,
                   ds3FarEndGgIntervalESs
                        Gauge,
                   ds3FarEndGgIntervalSESs
                        Gauge,
                   ds3FarEndGgIntervalCVs
                        Gauge
              }

          ds3FarEndGgIntervalIndex OBJECT-TYPE
              SYNTAX  INTEGER (1..65535)
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION





          T. Cox & K. Tesink (editors) Expires 11/30/92        [Page 43]





          Internet Draft           DS3 Objects                 June 1992


                      "The index value which uniquely identifies the
                      DS3 interface
                      to which this entry is applicable.  The
                      interface identified by a particular value of
                      this index is the same interface as identified
                      by the same value an DS3LineIndex object
                      instance."
              ::= { ds3FarEndGgIntervalEntry 1 }

          ds3FarEndGgIntervalNumber OBJECT-TYPE
             SYNTAX  INTEGER (1..96)
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                    "A number between 1 and 96, where 1 is the most
                    recently completed 15 minute interval and 96 is
                    the least recently completed 15 minutes
                    interval (assuming that all 96 intervals are
                    valid)."
             ::= { ds3FarEndGgIntervalEntry 2 }

          ds3FarEndGgIntervalESs OBJECT-TYPE
             SYNTAX  Gauge
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                     "The counter associated with the number of
                      Far End Errored Seconds encountered
                      by a DS3 interface in one of the previous 96,
                      individual 15 minute, intervals."
            ::= { ds3FarEndGgIntervalEntry 3 }

          ds3FarEndGgIntervalSESs OBJECT-TYPE
             SYNTAX  Gauge
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                     "The counter associated with the number of
                     Far End Severely Errored Seconds
                     encountered by a DS3 interface in one of the previous
                     96, individual 15 minute, intervals."
            ::= { ds3FarEndGgIntervalEntry 4 }

          ds3FarEndGgIntervalCVs OBJECT-TYPE
              SYNTAX  Gauge





          T. Cox & K. Tesink (editors) Expires 11/30/92        [Page 44]





          Internet Draft           DS3 Objects                 June 1992


              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The counter associated with the number of
                      Far End Coding Violations reported via
                      the far end block error count
                      encountered by a
                      DS3 interface in one of the previous 96, individual 15
                      minute, intervals."
              ::= { ds3FarEndGgIntervalEntry 5 }








































          T. Cox & K. Tesink (editors) Expires 11/30/92        [Page 45]





          Internet Draft           DS3 Objects                 June 1992


          -- The DS3 Far End Gauge Total

          -- The DS3 Far End Gauge Total Table contains the cumulative sum
          -- of the various statistics for the 24 hour interval preceding
          -- the first valid interval in the DS3FarEndCurrentTable.
          -- The definitions are the same as described for
          -- the near-end information.

          ds3FarEndGgTotalTable OBJECT-TYPE
              SYNTAX  SEQUENCE OF DS3FarEndGgTotalEntry
              ACCESS  not-accessible
              STATUS  mandatory
              DESCRIPTION
                      "The DS3 Far End Gauge Total table.  24 hour interval."
              ::= { ds3 10 }

          ds3FarEndGgTotalEntry OBJECT-TYPE
              SYNTAX  DS3FarEndGgTotalEntry
              ACCESS  not-accessible
              STATUS  mandatory
              DESCRIPTION
                      "An entry in the DS3 Far End Gauge Total table."
              INDEX   { ds3FarEndGgTotalIndex }
              ::= { ds3FarEndGgTotalTable 1 }

          DS3FarEndGgTotalEntry ::=
              SEQUENCE {
                  ds3FarEndGgTotalIndex
                      INTEGER,
                  ds3FarEndGgTotalESs
                      Gauge,
                  ds3FarEndGgTotalSESs
                      Gauge,
                  ds3FarEndGgTotalCVs
                      Gauge
              }

          ds3FarEndGgTotalIndex OBJECT-TYPE
              SYNTAX  INTEGER (1..65535)
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The index value which uniquely identifies the
                      DS3 interface
                      to which this entry is applicable.  The interface





          T. Cox & K. Tesink (editors) Expires 11/30/92        [Page 46]





          Internet Draft           DS3 Objects                 June 1992


                      identified by a particular value of this index is
                      the same interface as identified by the same value
                      an DS3LineIndex object instance."
              ::= { ds3FarEndGgTotalEntry 1 }

          ds3FarEndGgTotalESs OBJECT-TYPE
             SYNTAX  Gauge
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                     "The counter associated with the number of Far
                     End Errored Seconds encountered by a DS3
                     interface in the previous 24 hour interval."
             ::= { ds3FarEndGgTotalEntry 2 }

          ds3FarEndGgTotalSESs OBJECT-TYPE
             SYNTAX  Gauge
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                     "The counter associated with the number of
                     Far End Severely Errored Seconds
                     encountered by a DS3 interface in the previous 24 hour
                     interval."
             ::= { ds3FarEndGgTotalEntry 3 }

          ds3FarEndGgTotalCVs OBJECT-TYPE
             SYNTAX  Gauge
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                     "The counter associated with the number of
                     Far End Coding Violations reported via the
                     far end block error count
                     encountered by a
                     DS3 interface in the previous 24 hour interval."
             ::= { ds3FarEndGgTotalEntry 4 }



          END









          T. Cox & K. Tesink (editors) Expires 11/30/92        [Page 47]





          Internet Draft           DS3 Objects                 June 1992


          7.  Acknowledgments

          This document was produced by the SNMP and the Trunk MIB
          Working Groups:

                              Anne Ambler, Spider
                              Karl Auerbach, Sun
                              Fred Baker, ACC
                              Ken Brinkerhoff
                              Ron Broersma, NOSC
                              Jack Brown, US Army
                              Theodore Brunner, Bellcore
                              Jeffrey Buffum, HP
                              Jeffrey D. Case, UTK
                              Chris Chiptasso, Spartacus
                              Paul Ciarfella, DEC
                              Bob Collet
                              Tracy Cox, Bellcore
                              James R. Davin, MIT-LCS
                              Kurt Dobbins, Cabletron
                              Nadya El-Afandi, Network Systems
                              Gary Ellis, HP
                              Fred Engle
                              Mike Erlinger
                              Richard Fox, Synoptics
                              Karen Frisa, CMU
                              Chris Gunner, DEC
                              Ken Hibbard, Xylogics
                              Ole Jacobsen, Interop
                              Ken Jones
                              Satish Joshi, Synoptics
                              Frank Kastenholz, Racal-Interlan
                              Shimshon Kaufman, Spartacus
                              Jim Kinder, Fibercom
                              Alex Koifman, BBN
                              Christopher Kolb, PSI
                              Cheryl Krupczak, NCR
                              Peter Lin, Vitalink
                              John Lunny, TWG
                              Carl Malamud
                              Keith McCloghrie, HLS
                              Donna McMaster, David Systems
                              Lynn Monsanto, Sun
                              Dave Perkins, 3COM
                              Jim Reinstedler, Ungerman Bass





          T. Cox & K. Tesink (editors) Expires 11/30/92        [Page 48]





          Internet Draft           DS3 Objects                 June 1992


                              Anil Rijsinghani, DEC
                              Kary Robertson
                              Marshall T. Rose, PSI (chair)
                              L. Michael Sabo, NCSC
                              Jon Saperia, DEC
                              John Seligson
                              Fei Shu, NEC
                              Sam Sjogren, TGV
                              Mark Sleeper, Sparta
                              Lance Sprung
                              Mike St.Johns
                              Bob Stewart, Xyplex
                              Emil Sturniold
                              Kaj Tesink, Bellcore
                              Dean Throop, Data General
                              Bill Townsend, Xylogics
                              Maurice Turcotte
                              Kannan Varadhou
                              Sudhanshu Verma, HP
                              Warren Vik, Interactive Systems
                              David Waitzman, BBN
                              Steve Waldbusser, CMU
                              Dan Wintringhan
                              David Wood
                              Jeff Young, Cray Research

























          T. Cox & K. Tesink (editors) Expires 11/30/92        [Page 49]





          Internet Draft           DS3 Objects                 June 1992


          8.  References

             [1] Cerf, V., "IAB Recommendations for the Development of Internet
                 Network Management Standards", RFC 1052, NRI, April 1988.

             [2] Cerf, V., "Report of the Second Ad Hoc Network Management
                 Review Group", RFC 1109, NRI, August 1989.

             [3] Rose M., and K. McCloghrie, "Structure and Identification of
                 Management Information for TCP/IP-based internets", RFC 1155,
                 Performance Systems International, Hughes LAN Systems, May 1990.

             [4] 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.

             [5] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
                 Network Management Protocol", RFC 1157, SNMP Research,
                 Performance Systems International, Performance Systems
                 International, MIT Laboratory for Computer Science, May 1990.

             [6] McCloghrie K., and M. Rose, Editors, "Management Information
                 Base for Network Management of TCP/IP-based internets", RFC 1213,
                 Performance Systems International, March 1991.

             [7] Information processing systems - Open Systems Interconnection -
                 Specification of Abstract Syntax Notation One (ASN.1),
                 International Organization for Standardization, International
                 Standard 8824, December 1987.

             [8] 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.

             [9] American National Standard for telecommunications - digital
                 hierarchy - electrical interfaces, ANSI T1.102- 1987.

            [10] American National Standard for telecommunications - digital
                 hierarchy - formats specification, ANSI T1.107- 1988.

            [10a] ANSI T1.107a-1990.

            [11] American National Standard for telecommunications - Carrier-to-
                 Customer Installation - DS3 Metallic Interface, ANSI T1.404-1989.





          T. Cox & K. Tesink (editors) Expires 11/30/92        [Page 50]





          Internet Draft           DS3 Objects                 June 1992


            [12] In-Service Digital Transmission Performance Monitoring Draft
                 Standard, T1M1.3/92-005.

            [13] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions",
                 RFC 1212, Performance Systems International, Hughes LAN Systems,
                 March 1991.












































          T. Cox & K. Tesink (editors) Expires 11/30/92        [Page 51]





          Internet Draft           DS3 Objects                 June 1992


          9.  Security Considerations

          Security issues are not discussed in this memo.


          10.  Authors' Addresses

             Tracy A. Cox
             Bell Communications Research
             331 Newman Springs Road
             P.O. Box 7020
             Red Bank, NJ  07701-7020

             Phone: (908) 758-2107

             EMail: tacox@sabre.bellcore.com


             Kaj Tesink
             Bell Communications Research
             331 Newman Springs Road
             P.O. Box 7020
             Red Bank, NJ  07701-7020

             Phone: (908) 758-5254

             EMail: kaj@nvuxr.cc.bellcore.com























          T. Cox & K. Tesink (editors) Expires 11/30/92        [Page 52]





          Internet Draft           DS3 Objects                 June 1992


          Table of Contents


          1 Status of this Memo ...................................    1
          2 Abstract ..............................................    1
          3 The Network Management Framework ......................    3
          4 Objects ...............................................    4
          4.1 Format of Definitions ...............................    4
          4.2 Changes from RFC1233 ................................    4
          5 Overview ..............................................    6
          5.1 Binding between ifIndex and DS3 Interfaces ..........    6
          5.2 Objectives of this MIB Module .......................    8
          5.3 DS3 Terminology .....................................    8
          6 Object Definitions ....................................   12
          6.1 The DS3 Near End Group ..............................   13
          6.1.1 The DS3 Configuration .............................   13
          6.1.2 The DS3 Interval ..................................   21
          6.1.3 The DS3 Current ...................................   25
          6.1.4 The DS3 Total .....................................   28
          6.1.5 The DS3 Gauge Interval ............................   31
          6.1.6 The DS3 Gauge Total ...............................   35
          6.2 The DS3 Far End Group ...............................   38
          6.2.1 The DS3 Far End Configuration .....................   38
          6.2.2 The DS3 Far End Current ...........................   41
          6.2.3 The DS3 Far End Gauge Interval ....................   43
          6.2.4 The DS3 Far End Gauge Total .......................   46
          7 Acknowledgments .......................................   48
          8 References ............................................   50
          9 Security Considerations ...............................   52
          10 Authors' Addresses ...................................   52




















          T. Cox & K. Tesink (editors) Expires 11/30/92        [Page 53]











Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa09629;
          29 Jun 92 13:11 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa09618;
          29 Jun 92 13:11 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa08482;
          29 Jun 92 13:12 EDT
Received: from saffron.acc.com by fennel.acc.com (4.1/SMI-4.1)
	id AA19752; Mon, 29 Jun 92 09:49:24 PDT
Received: by saffron.acc.com (4.1/SMI-4.1)
	id AA00383; Mon, 29 Jun 92 09:48:46 PDT
Date: Mon, 29 Jun 92 09:48:46 PDT
From: Fred Baker <fbaker@acc.com>
Message-Id: <9206291648.AA00383@saffron.acc.com>
To: trunk-mib@fennel.acc.com
Subject: DS1 MIB, document form





     Internet Draft             DS1 MIB                   June 1992


       Definitions of Managed Objects for the DS1 Interface Type

                      Mon Jun 29 09:47:34 PDT 1992


                           Fred Baker, Editor

                    Advanced Computer Communications
                            315 Bollay Drive
                    Santa Barbara, California 93117

                             fbaker@acc.com






     1.  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. Internet Drafts may be updated, replaced, or obsoleted
     by other documents at any time.  It is not appropriate to use
     Internet Drafts as reference material or to cite them other
     than as a "working draft" or "work in progress."

     Please check the I-D abstract listing contained in each
     Internet Draft directory to learn the current status of this
     or any other Internet Draft.

     2.  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 DS1 Interfaces.

     This memo does not, in its draft form, specify a standard for
     the Internet community.





     F. Baker (editor)    Expires Nov 30 1992              [Page 1]





     Internet Draft             DS1 MIB                   June 1992


     3.  Abstract

     This memo defines an extension to the Management Information
     Base (MIB) for use with network management protocols in
     TCP/IP-based internets.  In particular, it defines objects for
     managing DS1 objects.  This document is a companion document
     with Definitions of Managed Objects for the DS3 Interface
     Type.

     This memo does not specify a standard for the Internet
     community.


     4.  The Network Management Framework

     The Internet-standard Network Management Framework consists of
     three components.  They are:

     RFC 1155 which defines the SMI, the mechanisms used for
     describing and naming objects for the purpose of management.
     RFC 1212 defines a more concise description mechanism, which
     is wholly consistent with the SMI.

     RFC 1156 which defines MIB-I, the core set of managed objects
     for the Internet suite of protocols.  RFC 1213 defines MIB-II,
     an evolution of MIB-I based on implementation experience and
     new operational requirements.

     RFC 1157 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.

















     F. Baker (editor)    Expires Nov 30 1992              [Page 2]





     Internet Draft             DS1 MIB                   June 1992


     5.  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) [7] 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 [3]
     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
     [8], subject to the additional requirements imposed by the
     SNMP.


     5.1.  Format of Definitions

     Section 6 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 RFC1212 [13].

     5.2.  Changes from RFC 1232

     The changes from RFC1232 are the following:

     (1)  This MIB module contains three groups: DS1 Near End Group
          which is mandatory, DS1 Far End Group which is optional,
          and the Fractional Table, which is optional.





     F. Baker (editor)    Expires Nov 30 1992              [Page 3]





     Internet Draft             DS1 MIB                   June 1992


     (2)  The Far End Group is a new group and contains
          configuration information and statistics that are
          collected from the far end DS1 interface.  The Far End
          Group may only be implemented by DS1 systems that use the
          facilities data link to exchange this information.
          Typically, these are ANSI ESF links, although some
          vendors use proprietary means to do this on other types
          of links.

     (3)  ds1CSUIndex has been renamed ds1LineIndex.  This object
          is the identifier of a DS1 Interface on a device.

     (4)  ds1Index has been renamed ds1IfIndex.  This value for
          this object is equal to the value of ifIndex from the
          Interfaces table of MIB II (RFC 1213).

     (5)  ds1Loopback has been deprecated.

     (6)  A new object has been added called ds1LoopbackConfig,
          which better describes the loopback capabilities of a DS1
          interface on a device.

     (7)  ds1YellowAlarm has been deprecated.

     (8)  ds1RedAlarm has been deprecated.

     (9)  A new object has been added called ds1LineStatus.  This
          object better describes the status (e.g., alarm state and
          loopback state) of a DS1 interface.

     (10) The ds1IntervalTable and the ds1TotalTable have been
          deprecated and replaced with two other tables,
          ds1GgIntervalTable and ds1GgTotalTable, respectively,
          whose objects have a SYNTAX of Gauge.
















     F. Baker (editor)    Expires Nov 30 1992              [Page 4]





     Internet Draft             DS1 MIB                   June 1992


     5.3.  Overview

     These objects are used when the particular media being used to
     realize an interface is a DS1 physical interface.  At present,
     this applies to these values of the ifType variable in the
     Internet- standard MIB:
            ds1 (18)
            e1  (19)

     The definitions contained herein are based on the AT&T T-1
     specifications and Extended Superframe (ESF) format [11, 12],
     the latter of which conforms to proposed ANSI specifications
     [15].  The various T1 and E1 line disciplines are similar
     enough that separate MIBs are unwarranted, although there are
     some differences.  For example, Loss of Frame is defined more
     rigorously in the ESF specification than in the D4
     specification, but it is defined in both.

     5.4.  Binding between ifIndex and DS1 Interfaces

     Different physical configurations for the support of SNMP with
     DS1 equipment exist. To accommodate these scenarios, two
     different indices for DS1 interfaces are introduced in this
     MIB.  These indices are ds1IfIndex and ds1LineIndex.

     External interface scenario: the SNMP Agent represents all
     managed DS1 lines as external interfaces (for example, an
     Agent residing on the device supporting DS1 interfaces
     directly):

     For this scenario, all interfaces are assigned an integer
     value equal to ifIndex, and the following applies:

          ifIndex=ds1IfIndex=ds1LineIndex for all interfaces.

     The ds1IfIndex column of the DS1 Configuration table relates
     each DS1 interface to its corresponding interface (ifIndex) in
     the Internet-standard MIB (MIB-II RFC1213).

     External&Internal interface scenario: the SNMP Agents resides
     on an host external from the device supporting DS1 interfaces
     (e.g., a router). The Agent represents both the host and the
     DS1 device.  The index ds1LineIndex is used to not only
     represent the DS1 interfaces external from the host/DS1-device
     combination, but also the DS1 interfaces connecting the host





     F. Baker (editor)    Expires Nov 30 1992              [Page 5]





     Internet Draft             DS1 MIB                   June 1992


     and the DS1 device.  The index ds1IfIndex is always equal to
     ifIndex.

     Example:

     A shelf full of CSUs connected to a Router. An SNMP Agent
     residing on the router proxies for itself and the CSU. The
     router has also an Ethernet interface:
           +-----+
     |     |     |
     |     |     |               +---------------------+
     |E    |     |  1.544  MBPS  |   ds1 M13    Line#A | DS1 Link
     |t    |  R  |---------------+ - - - - -  - - -  - +------>
     |h    |     |               |                     |
     |e    |  O  |  1.544  MBPS  |   ds1 M13    Line#B | DS1 Link
     |r    |     |---------------+ - - - - - - - - - - +------>
     |n    |  U  |               |                     |
     |e    |     |  1.544  MBPS  |   ds1 M13    Line#C | DS1 Link
     |t    |  T  |---------------+ - - - -- -- - - - - +------>
     |     |     |               |                     |
     |-----|  E  |  1.544  MBPS  |   ds1 M13    Line#D | DS1 Link
     |     |     |---------------+ -  - - - -- - - - - +------>
     |     |  R  |               |_____________________|
     |     |     |
     |     +-----+

     The assignment of the index values could for example be:

     ifIndex (= ds1IfIndex)                  ds1LineIndex

     1                   NA                  NA (Ethernet)
     2      Line#A   Router Side             7
     2      Line#A   Network Side            6
     3      Line#B   Router Side             9
     3      Line#B   Network Side            8
     4      Line#C   Router Side            11
     4      Line#C   Network Side           10
     5      Line#D   Router Side            13
     5      Line#D   Network Side           12

     For this example, ifNumber is equal to 5.  Note the following
     description of ds1LineIndex: the ds1LineIndex identifies a DS1
     Interface on a managed device.  If there is an ifEntry that is
     directly associated with this and only this DS1 interface, it
     should have the same value as ifIndex.  Otherwise, number the





     F. Baker (editor)    Expires Nov 30 1992              [Page 6]





     Internet Draft             DS1 MIB                   June 1992


     ds1LineIndices with an unique identifier following the rules
     of choosing a number greater than ifNumber and numbering
     inside interfaces (e.g., equipment side) with even numbers and
     outside interfaces (e.g, network side) with odd numbers.

     If the CSU shelf is managed by itself by a local SNMP Agent,
     the situation would be:
          ifIndex (= ds1IfIndex)               ds1LineIndex

          1      Line#A     Router Side              1
          2      Line#A     Network Side            2
          3      Line#B     Router Side              3
          4      Line#B     Network Side            4
          5      Line#C     Router Side             5
          6      Line#C     Network Side            6
          7      Line#D     Router Side             7
          8      Line#D     Network Side            8

     5.5.  Objectives of this MIB Module

     There are numerous things that could be included in a MIB for
     DS1 signals: the management of multiplexors, CSUs, DSUs, and
     the like.  The intent of this document is to facilitate the
     common management of all devices with DS1 interfaces.  As
     such, a design decision was made up front to very closely
     align the MIB with the set of objects that can generally be
     read from DS1 devices that are currently deployed.

     5.6.  DS1 Terminology

     The terminology used in this document to describe error
     conditions on a DS1 interface as monitored by a DS1 device are
     based on the definitions from the ANSI T1M1.3/92-005 draft
     standard [12].  If the definition in this document does not
     match the definition in the ANSI T1M1.3/92-005R1 draft
     document, the implementer should follow the definition
     described in this document.

     Bipolar Violation (BPV)
          A BPV for an AMI-coded signal is the occurrence of a
          pulse of the same polarity as the previous pulse.  A BPV
          for a B8ZS-coded signal is the occurrence of a pulse of
          the same polarity as the previous pulse without being a
          part of the zero substitution code.






     F. Baker (editor)    Expires Nov 30 1992              [Page 7]





     Internet Draft             DS1 MIB                   June 1992


     Coding Violation (CV)
          A coding violation is a count of frame synchronization
          bit errors in the SF format, or a count of CRC-6 errors
          in the ESF format.

     Errored Seconds (ES)
          An ES is a second with one or more Coding Violation OR
          one or more Out of Frame events OR a detected incoming
          AIS.

     Severely Errored Seconds (SES)
          A SES is a second with 320 or more Coding Violations OR
          one or more Out of Frame events OR a detected incoming
          AIS.

     Severely Errored Framing Seconds (SEFS)
          A SEFS is a second with one or more Out of Frame events
          OR a detected incoming AIS.

     Unavailable Seconds (UAS)
          UAS are calculated by counting the number of seconds that
          the interface is unavailable.  The DS1 interface is said
          to be unavailable from the onset of 10 contiguous SESs,
          or the onset of the condition leading to a failure (see
          Alarm States).  If the condition leading to the failure
          was immediately preceded by one or more contiguous SESs,
          then the DS1 interface unavailability starts from the
          onset of these SESs.  Once unavailable, and if no failure
          is present, the DS1 interface becomes available at the
          onset of 10 contiguous seconds with no SESs.  Once
          unavailable, and if a failure is present, the DS1
          interface becomes available at the onset of 10 contiguous
          seconds with no SESs, if the failure clearing time is
          less than or equal to 10 seconds.  If the failure
          clearing time is more than 10 seconds, the DS1 interface
          becomes available at the onset of 10 contiguous seconds
          with no SESs, or the onset period leading to the
          successful clearing condition, whichever occurs later.
          With respect to the DS1 error counts, all counters are
          incremented while the DS1 interface is deemed available.
          While the interface is deemed unavailable, the only count
          that is incremented is UASs.

          A special case exists when the 10 or more second period
          crosses the 900 second statistics window boundary, as the





     F. Baker (editor)    Expires Nov 30 1992              [Page 8]





     Internet Draft             DS1 MIB                   June 1992


          foregoing description implies that the SES and UAS
          counters must be adjusted when the Unavailable Signal
          State is entered. Clearly, successive GETs of the
          affected ds1GgIntervalSESs and ds1GgIntervalUASs objects
          will return differing values if the first GET occurs
          during the first few seconds of the window.  This is
          viewed as an unavoidable side-effect of selecting the
          presently defined managed objects as a basis for this
          memo.

     Alarm States:
          The Far End Alarm (or Yellow Alarm) is declared after
          detecting the Yellow Alarm-Signal.

          Also, the incoming alarm state is declared when a failure
          condition persists for at least 2-10 seconds.  The
          failure conditions are the following:  Loss of Signal
          (LOS), a Loss of Frame (LOF) (a persistent Out of Frame
          event), or an Alarm Indication Signal (AIS).  The Alarm
          State is cleared at the onset of 10 consecutive seconds
          with no SESs.

     Out of Frame (OOF) event
          An OOF event is detected when any three or more errors in
          sixteen or fewer consecutive F-bits occur within a DS1
          M-frame.  An OOF event is cleared when reframe occurs.  A
          Loss of Frame (LOF) failure condition is declared when
          the OOF event is consistent for 2 to 10 seconds.  The OOF
          event ends when reframe occurs.  The LOF failure
          condition is cleared when the OOF defect is absent for 10
          to 20 seconds.

     Loss of Signal (LOS)
          The LOS event is declared upon observing 175 +/- 75
          contiguous pulse positions with no pulses of either
          positive or negative polarity.  The LOS is terminated
          upon observing an average pulse density of at least 33%
          over a period of 175 +/- 75 contiguous pulse positions
          starting with the receipt of a pulse.

     Alarm Indication Signal (AIS)
          The AIS is encoded encoded in various ways depending on
          the line encoding, but indicates that the system sending
          it either is experiencing LOS or LOF on its inputs, or
          has experienced this within a defined interval of time.





     F. Baker (editor)    Expires Nov 30 1992              [Page 9]





     Internet Draft             DS1 MIB                   June 1992


     Circuit Identifier
          This is a character string specified by the circuit
          vendor, and is useful when communicating with the vendor
          during the troubleshooting process.














































     F. Baker (editor)    Expires Nov 30 1992             [Page 10]





     Internet Draft             DS1 MIB                   June 1992


     6.  Definitions

     RFCxxxx-MIB DEFINITIONS ::= BEGIN

     IMPORTS
             Counter, Gauge
                     FROM RFC1155-SMI
             transmission, DisplayString
                     FROM RFC1213-MIB
             OBJECT-TYPE
                     FROM RFC-1212;

     --  This MIB module uses the extended OBJECT-TYPE macro as
     --  defined in RFC 1212.

     --  this is the MIB module for the DS1 objects

     ds1 OBJECT IDENTIFIER ::= { transmission 18 }
































     F. Baker (editor)    Expires Nov 30 1992             [Page 11]





     Internet Draft             DS1 MIB                   June 1992


     -- The DS1 Near End Group

     -- Implementation of this group is mandatory for all systems
     -- that attach to a DS1 Interface.

     -- The DS1 Near End Group consists of four tables:
     --    DS1 Configuration
     --    DS1 Current
     --    DS1 Gauge Interval
     --    DS1 Gauge Total

     -- the DS1 Configuration Table

     -- Although the objects in this table are read-only, at the
     -- agent's discretion they may be made read-write so that the
     -- management station, when appropriately authorized, may
     -- change the behavior of the interface, e.g., to place the interface
     -- into a loopback state.


         ds1ConfigTable OBJECT-TYPE
             SYNTAX  SEQUENCE OF DS1ConfigEntry
             ACCESS  not-accessible
             STATUS  mandatory
             DESCRIPTION
                "The DS1 Configuration table."
            ::= { ds1 1 }



         ds1ConfigEntry OBJECT-TYPE
             SYNTAX  DS1ConfigEntry
             ACCESS  not-accessible
             STATUS  mandatory
             DESCRIPTION
                "An entry in the DS1 Configuration table."
            INDEX   { ds1LineIndex }
            ::= { ds1ConfigTable 1 }


     DS1ConfigEntry ::=
         SEQUENCE {
             ds1LineIndex
                 INTEGER,
             ds1IfIndex





     F. Baker (editor)    Expires Nov 30 1992             [Page 12]





     Internet Draft             DS1 MIB                   June 1992


                 INTEGER,
             ds1TimeElapsed
                 INTEGER,
             ds1ValidIntervals
                 INTEGER,
             ds1LineType
                 INTEGER,
             ds1ZeroCoding
                 INTEGER,
             ds1Loopback
                 INTEGER,
             ds1SendCode
                 INTEGER,
             ds1YellowAlarm
                 INTEGER,
             ds1RedAlarm
                 INTEGER,
             ds1CircuitIdentifier
                 DisplayString,
             ds1LoopbackConfig
                 INTEGER,
             ds1LineStatus
                 INTEGER
         }


         ds1LineIndex OBJECT-TYPE
             SYNTAX  INTEGER
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "This object is the identifier of a DS1  Inter-
                face on a managed device.  If there is an ifEn-
                try that is directly associated with  this  and
                only  this  DS1  interface,  it should have the
                same value as ifIndex.   Otherwise,  the  value
                exceeds  ifNumber,  and  is a unique identifier
                following this rule: inside  interfaces  (e.g.,
                equipment  side)  with even numbers and outside
                interfaces  (e.g,  network   side)   with   odd
                numbers."
            ::= { ds1ConfigEntry 1 }








     F. Baker (editor)    Expires Nov 30 1992             [Page 13]





     Internet Draft             DS1 MIB                   June 1992


         ds1IfIndex OBJECT-TYPE
             SYNTAX  INTEGER
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "This value for this object  is  equal  to  the
                value  of  ifIndex from the Interfaces table of
                MIB II (RFC 1213)."
            ::= { ds1ConfigEntry 2 }



         ds1TimeElapsed OBJECT-TYPE
             SYNTAX  INTEGER (1..900)
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The  number  of  seconds,  including   partial
                seconds,  that have elapsed since the beginning
                of the current error-measurement period."
            ::= { ds1ConfigEntry 3 }



         ds1ValidIntervals OBJECT-TYPE
             SYNTAX  INTEGER (0..96)
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The number of  previous  intervals  for  which
                valid data was collected.  The value will be 96
                unless the interface was brought online  within
                the last 24 hours, in which case the value will
                be the number of complete 15  minute  intervals
                the interface has been online."
            ::= { ds1ConfigEntry 4 }














     F. Baker (editor)    Expires Nov 30 1992             [Page 14]





     Internet Draft             DS1 MIB                   June 1992


         ds1LineType OBJECT-TYPE
             SYNTAX  INTEGER {
                         other(1),
                         ds1ESF(2),
                         ds1D4(3),
                         ds1ANSI-ESF(4),
                         ds1G704(5),
                         ds1G704-CRC(6)
                     }
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "This variable indicates  the  variety  of  DS1
                Line  implementing  this  circuit.  The type of
                circuit affects the number of bits  per  second
                that  the circuit can reasonably carry, as well
                as the interpretation of the  usage  and  error
                statistics.

                The  values,  in  sequence,  describe:   TITLE:
                SPECIFICATION:  ds1ESF        AT&T Extended Su-
                perFrame DS1 ds1D4         AT&T D4  format  DS1
                ds1ANSI-ESF    ANSI  Extended SuperFrame format
                ds1G704       CCITT Recommendation G.704  (sec-
                tion  2.1.3.2)  ds1G704-CRC   CCITT Recommenda-
                tion G.704 (section 2.1.3.1)
                       "
                   ::= { ds1ConfigEntry 5 }






















     F. Baker (editor)    Expires Nov 30 1992             [Page 15]





     Internet Draft             DS1 MIB                   June 1992


         ds1ZeroCoding OBJECT-TYPE
             SYNTAX  INTEGER {
                         ds1JammedBit(1),
                         ds1B8ZS(2),
                         ds1InvertedHDLC(3),
                         ds1HDB3(4),
                         ds1ZBTSI(5),
                         ds1NoZeroEncoding (6)
                     }
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "This variable describes the  variety  of  Zero
                Code  Suppression  used  on  the link, which in
                turn affects a number of its characteristics.

                ds1JammedBit refers the Jammed bit Zero  Encod-
                ing,  in  which  the  AT&T  specification of at
                least one pulse every 8 bit periods is literal-
                ly  implemented  by forcing a pulse in bit 8 of
                each channel.  Thus, only seven bits per  chan-
                nel, or 1.344 Mbps, is available for data.

                ds1B8ZS refers to the use of a  specified  pat-
                tern  of  normal  bits  and  bipolar violations
                which are used to replace a sequence  of  eight
                zero  bits.  In this context, all eight bits in
                a channel are technically available  for  data,
                but  care must be taken with D4 encoded data to
                avoid having HDLC Flag streams imitate spurious
                Yellow  Alarm  conditions.   Typically, one bit
                per frame is ignored to force flag  streams  to
                rotate,   thereby  avoiding  this  error  type.
                CCITT Recommendation G.703 may be  referred  to
                for further definition of these.

                ds1InvertedHDLC refers to the practice,  common
                on  HDLC  encoded  DS1 data links, of inverting
                the data between the serial interface chip  and
                the  CSU.  Since HDLC guarantees one zero every
                6 bits in the worst case, while  the  standards
                call  for  (in effect) at least one pulse every
                eight, inverted HDLC enjoys 4/24 one's  density
                on  the  line,  which may improve the effective
                clock stability of a DS1 line.  As  with  B8ZS,





     F. Baker (editor)    Expires Nov 30 1992             [Page 16]





     Internet Draft             DS1 MIB                   June 1992


                all  eight  bits  in  a channel are technically
                available for data, but care must be taken with
                D4  encoded  data  to  avoid  having  HDLC Flag
                streams imitate spurious  Yellow  Alarm  condi-
                tions.  Typically, one bit per frame is ignored
                to force flag streams to rotate, thereby avoid-
                ing this error type.

                ANSI Clear Channels may use ds1ZBTSI,  or  Zero
                Byte Time Slot Interchange.

                G.704 links, with or without CRC,  use  ds1HDB3
                or ds1NoZeroEncoding."
            ::= { ds1ConfigEntry 6 }




































     F. Baker (editor)    Expires Nov 30 1992             [Page 17]





     Internet Draft             DS1 MIB                   June 1992


         ds1Loopback OBJECT-TYPE
             SYNTAX  INTEGER {
                         ds1NoLoop(1),
                         ds1LocalLoopbackLocalSide(2),
                         ds1LocalLoopbackRemoteSide(3),
                         ds1RemoteLoopbackLocalSide(4),
                         ds1RemoteLoopbackRemoteSide(5)
                     }
             ACCESS  read-only
             STATUS  deprecated
             DESCRIPTION
                "This variable represents the loopback state of
                the  device.   Agents supporting read/write ac-
                cess should return badValue in  response  to  a
                requested  loopback  state that the device does
                not support.  The values mean:

                ds1NoLoop
                     Not in the loopback state.  A device  that
                     is not capable of performing a loopback on
                     either interface shall always return  this
                     as it's value.

                ds1LocalLoopbackLocalSide
                     Signal received from the local side of the
                     device is looped back at the local connec-
                     tor (eg, without involving the device).

                ds1LocalLoopbackRemoteSide
                     Signal received from the local side of the
                     device  is  looped back at the remote con-
                     nector (eg, through the device).

                ds1RemoteLoopbackLocalSide
                     Signal received from the  remote  side  of
                     the  device  is  looped  back at the local
                     connector (eg, through the device).

                ds1RemoteLoopbackRemoteSide
                     Signal received from the  remote  side  of
                     the  device  is  looped back at the remote
                     connector (eg, without involving the  dev-
                     ice)."
            ::= { ds1ConfigEntry 7 }






     F. Baker (editor)    Expires Nov 30 1992             [Page 18]





     Internet Draft             DS1 MIB                   June 1992


         ds1SendCode OBJECT-TYPE
             SYNTAX  INTEGER {
                         ds1SendTestMessage(1),
                         ds1SendNoCode(2),
                         ds1SendSetCode(3),
                         ds1SendLoopbackCode(4),
                         ds1SendResetCode(5)
                     }
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "This variable indicates what type of  code  is
                being sent across the DS1 interface by the dev-
                ice.  The values mean:

                ds1SendNoCode
                         sending looped or normal data

                ds1SendSetCode
                         sending a loopback request

                ds1SendLoopbackCode
                         sending a loopback test code/pattern

                ds1SendResetCode
                         sending a loopback termination request

                ds1SendTestMessage
                         sending a Test pattern as  defined  in
                     T1.107a-1990."
            ::= { ds1ConfigEntry 8 }



















     F. Baker (editor)    Expires Nov 30 1992             [Page 19]





     Internet Draft             DS1 MIB                   June 1992


         ds1YellowAlarm OBJECT-TYPE
             SYNTAX  INTEGER {
                         ds1YellowAlarm(1),
                         ds1NoYellowAlarm(2)
                     }
             ACCESS  read-only
             STATUS  deprecated
             DESCRIPTION
                "This variable indicates if a Yellow Alarm con-
                dition exists."
            ::= { ds1ConfigEntry 9 }



         ds1RedAlarm OBJECT-TYPE
             SYNTAX  INTEGER {
                         ds1RedAlarm(1),
                         ds1NoRedAlarm(2)
                     }
             ACCESS  read-only
             STATUS  deprecated
             DESCRIPTION
                "This variable indicates if a Red Alarm  condi-
                tion exists."
            ::= { ds1ConfigEntry 10 }



         ds1CircuitIdentifier OBJECT-TYPE
             SYNTAX  DisplayString (SIZE (0..255))
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "This  variable   contains   the   transmission
                vendor's circuit identifier, for the purpose of
                facilitating troubleshooting."
            ::= { ds1ConfigEntry 11 }













     F. Baker (editor)    Expires Nov 30 1992             [Page 20]





     Internet Draft             DS1 MIB                   June 1992


         ds1LoopbackConfig OBJECT-TYPE
             SYNTAX  INTEGER {
                         ds1NoLoop(1),
                         ds1MgrPayloadLoop(2),
                         ds1MgrLineLoop(3),
                         ds1NetReqPayloadLoop(4),
                         ds1NetReqLineLoop(5),
                         ds1OtherLoop(6)
                     }
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "This variable represents the  loopback  confi-
                guration of the DS1 interface.  Agents support-
                ing read/write access should return badValue in
                response to a requested loopback state that the
                interface does not support.  The values mean:

                ds1NoLoop
                     Not in the loopback state.  A device  that
                     is not capable of performing a loopback on
                     the interface shall always return this  as
                     it's value.

                ds1MgrPayloadLoop
                     The received signal at this  interface  is
                     looped  through  the device; this loopback
                     is initiated by a manager of  the  device.
                     Typically  the  received  signal is looped
                     back  for  retransmission  after  it   has
                     passed  through the device's framing func-
                     tion.

                ds1MgrLineLoop
                     The received signal at this interface does
                     not  go  through the device (minimum pene-
                     tration) but  is  looped  back  out;  this
                     loopback  is initiated by a manager of the
                     device.

                ds1NetReqPayloadLoop
                     The received signal at this  interface  is
                     looped  through  the device; this loopback
                     is  initiated/requested  by  the  far  end
                     equipment.  Typically  the received signal





     F. Baker (editor)    Expires Nov 30 1992             [Page 21]





     Internet Draft             DS1 MIB                   June 1992


                     is looped back for retransmission after it
                     has  passed  through  the device's framing
                     function.

                ds1NetReqLineLoop
                     The received signal at this interface does
                     not  go  through the device (minimum pene-
                     tration) but  is  looped  back  out;  this
                     loopback is initiated/requested by the far
                     end equipment.

                ds1OtherLoop
                     Loopbacks that are not defined here."
            ::= { ds1ConfigEntry 12 }



         ds1LineStatus OBJECT-TYPE
             SYNTAX  INTEGER
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "This variable indicates the Line Status of the
                interface.  It contains loopback state informa-
                tion  and   alarm   state   information.    The
                ds1LineStatus  is  a  bit  map represented as a
                sum,  therefore,  it  can  represent   multiple
                alarms and a LoopbackState simultaneously.

                ds1NoAlarm should be set if and only if no oth-
                er flag is set.

                The various bit positions are:
                       1     ds1NoAlarm
                       2     ds1FarEndAlarm
                       4     ds1AlarmIndicationSignal
                       8     ds1LossOfFrame
                      16     ds1LossOfSignal
                      32     ds1LoopbackState
                      64     ds1T16AlarmIndicationSignal
                     128     ds1LossOfMultiFrame
                     256     ds1DistantLossOfMultiFrame
                     512     ds1DistantLossOfSignal"
            ::= { ds1ConfigEntry 13 }






     F. Baker (editor)    Expires Nov 30 1992             [Page 22]





     Internet Draft             DS1 MIB                   June 1992


     -- the DS1 Interval

     -- The DS1 Interval Table contains various statistics
     -- collected by each DS1 Interface over the previous 24 hours of
     -- operation.  The past 24 hours are broken into 96 completed
     -- 15 minute intervals.

     -- This table has been deprecated and replaced by ds1GgIntervalTable.


         ds1IntervalTable OBJECT-TYPE
             SYNTAX  SEQUENCE OF DS1IntervalEntry
             ACCESS  not-accessible
             STATUS  deprecated
             DESCRIPTION
                "The DS1 Interval table."
            ::= { ds1 2 }



         ds1IntervalEntry OBJECT-TYPE
             SYNTAX  DS1IntervalEntry
             ACCESS  not-accessible
             STATUS  deprecated
             DESCRIPTION
                "An entry in the DS1 Interval table."
            INDEX   { ds1IntervalIndex, ds1IntervalNumber }
            ::= { ds1IntervalTable 1 }


     DS1IntervalEntry ::=
         SEQUENCE {
             ds1IntervalIndex
                 INTEGER,
             ds1IntervalNumber
                 INTEGER,
             ds1IntervalESs
                 Counter,
             ds1IntervalSESs
                 Counter,
             ds1IntervalSEFSs
                 Counter,
             ds1IntervalUASs
                 Counter,
             ds1IntervalCSSs





     F. Baker (editor)    Expires Nov 30 1992             [Page 23]





     Internet Draft             DS1 MIB                   June 1992


                 Counter,
             ds1IntervalBPVs
                 Counter,
             ds1IntervalCVs
                 Counter
         }


         ds1IntervalIndex OBJECT-TYPE
             SYNTAX  INTEGER (1..65535)
             ACCESS  read-only
             STATUS  deprecated
             DESCRIPTION
                "The index value which uniquely identifies  the
                ds1  interface  to which this entry is applica-
                ble.  The interface identified by a  particular
                value  of  this  index is the same interface as
                identified by the same  value  an  ds1LineIndex
                object instance."
            ::= { ds1IntervalEntry 1 }



         ds1IntervalNumber OBJECT-TYPE
             SYNTAX  INTEGER (1..96)
             ACCESS  read-only
             STATUS  deprecated
             DESCRIPTION
                "A number between 1 and 96, where 1 is the most
                recently completed 15 minute interval and 96 is
                the least recently completed 15 minutes  inter-
                val   (assuming   that  all  96  intervals  are
                valid)."
            ::= { ds1IntervalEntry 2 }
















     F. Baker (editor)    Expires Nov 30 1992             [Page 24]





     Internet Draft             DS1 MIB                   June 1992


         ds1IntervalESs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  deprecated
             DESCRIPTION
                "The counter associated with the number of  Er-
                rored  Seconds,  encountered by a DS1 interface
                in  one  of  the  previous  96,  individual  15
                minute, intervals."
            ::= { ds1IntervalEntry 3 }



         ds1IntervalSESs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  deprecated
             DESCRIPTION
                "The counter  associated  with  the  number  of
                Severely  Errored Seconds, encountered by a ds1
                interface in one of the previous 96, individual
                15 minute, intervals."
            ::= { ds1IntervalEntry 4 }



         ds1IntervalSEFSs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  deprecated
             DESCRIPTION
                "The counter  associated  with  the  number  of
                Severely  Errored  Framing Seconds, encountered
                by a DS1 interface in one of the  previous  96,
                individual 15 minute, intervals."
            ::= { ds1IntervalEntry 5 }














     F. Baker (editor)    Expires Nov 30 1992             [Page 25]





     Internet Draft             DS1 MIB                   June 1992


         ds1IntervalUASs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  deprecated
             DESCRIPTION
                "The counter associated with the number of Una-
                vailable  Seconds,  encountered by a ds1 inter-
                face in one of the previous 96,  individual  15
                minute, intervals."
            ::= { ds1IntervalEntry 6 }



         ds1IntervalCSSs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  deprecated
             DESCRIPTION
                "The counter associated with the number of Con-
                trolled  Slip Seconds, encountered by a ds1 in-
                terface in one of the previous  96,  individual
                15 minute, intervals."
            ::= { ds1IntervalEntry 7 }



         ds1IntervalBPVs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  deprecated
             DESCRIPTION
                "The counter associated with the number of  Bi-
                polar  Violations,  encountered by a DS1 inter-
                face in one

                of the previous 96, individual 15  minute,  in-
                tervals."
            ::= { ds1IntervalEntry 8 }












     F. Baker (editor)    Expires Nov 30 1992             [Page 26]





     Internet Draft             DS1 MIB                   June 1992


         ds1IntervalCVs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  deprecated
             DESCRIPTION
                "The counter associated with the number of Cod-
                ing  Violations, encountered by a DS1 interface
                in  one  of  the  previous  96,  individual  15
                minute, intervals."
            ::= { ds1IntervalEntry 9 }








































     F. Baker (editor)    Expires Nov 30 1992             [Page 27]





     Internet Draft             DS1 MIB                   June 1992


     -- the DS1 Current

     -- The DS1 current table contains various statistics being
     -- collected for the current 15 minute interval.


         ds1CurrentTable OBJECT-TYPE
             SYNTAX  SEQUENCE OF DS1CurrentEntry
             ACCESS  not-accessible
             STATUS  mandatory
             DESCRIPTION
                "The DS1 Current table."
            ::= { ds1 3 }



         ds1CurrentEntry OBJECT-TYPE
             SYNTAX  DS1CurrentEntry
             ACCESS  not-accessible
             STATUS  mandatory
             DESCRIPTION
                "An entry in the DS1 Current table."
            INDEX   { ds1CurrentIndex }
            ::= { ds1CurrentTable 1 }


     DS1CurrentEntry ::=
         SEQUENCE {
             ds1CurrentIndex
                 INTEGER,
             ds1CurrentESs
                 Counter,
             ds1CurrentSESs
                 Counter,
             ds1CurrentSEFSs
                 Counter,
             ds1CurrentUASs
                 Counter,
             ds1CurrentCSSs
                 Counter,
             ds1CurrentBPVs
                 Counter,
             ds1CurrentCVs
                 Counter
         }





     F. Baker (editor)    Expires Nov 30 1992             [Page 28]





     Internet Draft             DS1 MIB                   June 1992


         ds1CurrentIndex OBJECT-TYPE
             SYNTAX  INTEGER (1..65535)
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The index value which uniquely identifies  the
                ds1  interface  to which this entry is applica-
                ble.  The interface identified by a  particular
                value  of  this  index is the same interface as
                identified by the same  value  an  ds1LineIndex
                object instance."
            ::= { ds1CurrentEntry 1 }



         ds1CurrentESs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter associated with the number of  Er-
                rored  Seconds,  encountered by a DS1 interface
                in the current 15 minute interval."
            ::= { ds1CurrentEntry 2 }



         ds1CurrentSESs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter  associated  with  the  number  of
                Severely  Errored Seconds, encountered by a ds1
                interface in the current 15 minute interval."
            ::= { ds1CurrentEntry 3 }














     F. Baker (editor)    Expires Nov 30 1992             [Page 29]





     Internet Draft             DS1 MIB                   June 1992


         ds1CurrentSEFSs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter  associated  with  the  number  of
                Severely  Errored  Framing Seconds, encountered
                by a DS1 interface in the current 15 minute in-
                terval."
            ::= { ds1CurrentEntry 4 }



         ds1CurrentUASs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter associated with the number of Una-
                vailable Seconds encountered by a ds1 interface
                in the current 15 minute interval."
            ::= { ds1CurrentEntry 5 }



         ds1CurrentCSSs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter associated with the number of Con-
                trolled  Slip Seconds, encountered by a ds1 in-
                terface in the current 15 minute interval."
            ::= { ds1CurrentEntry 6 }
















     F. Baker (editor)    Expires Nov 30 1992             [Page 30]





     Internet Draft             DS1 MIB                   June 1992


         ds1CurrentBPVs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter associated with the number of  Bi-
                polar  Violations,  encountered by a DS1 inter-
                face in the current 15 minute interval."
            ::= { ds1CurrentEntry 7 }



         ds1CurrentCVs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter associated with the number of Cod-
                ing  Violations, encountered by a DS1 interface
                in the current 15 minute interval."
            ::= { ds1CurrentEntry 8 }





























     F. Baker (editor)    Expires Nov 30 1992             [Page 31]





     Internet Draft             DS1 MIB                   June 1992


     -- the DS1 Total

     -- The DS1 Total Table contains the cumulative sum of the
     -- various statistics for the 24 hour interval preceding the
     -- first valid interval in the ds1CurrentTable.
     -- This table has been deprecated and replaced by ds1GgTotalTable.


         ds1TotalTable OBJECT-TYPE
             SYNTAX  SEQUENCE OF DS1TotalEntry
             ACCESS  not-accessible
             STATUS  deprecated
             DESCRIPTION
                "The DS1 Total table.  24 hour interval."
            ::= { ds1 4 }



         ds1TotalEntry OBJECT-TYPE
             SYNTAX  DS1TotalEntry
             ACCESS  not-accessible
             STATUS  deprecated
             DESCRIPTION
                "An entry in the DS1 Total table."
            INDEX   { ds1TotalIndex }
            ::= { ds1TotalTable 1 }


     DS1TotalEntry ::=
         SEQUENCE {
             ds1TotalIndex
                 INTEGER,
             ds1TotalESs
                 Counter,
             ds1TotalSESs
                 Counter,
             ds1TotalSEFSs
                 Counter,
             ds1TotalUASs
                 Counter,
             ds1TotalCSSs
                 Counter,
             ds1TotalBPVs
                 Counter,
             ds1TotalCVs





     F. Baker (editor)    Expires Nov 30 1992             [Page 32]





     Internet Draft             DS1 MIB                   June 1992


                 Counter
         }


         ds1TotalIndex OBJECT-TYPE

             SYNTAX  INTEGER (1..65535)
             ACCESS  read-only
             STATUS  deprecated
             DESCRIPTION
                "The index value which uniquely identifies  the
                ds1  interface  to which this entry is applica-
                ble.  The interface identified by a  particular
                value  of  this  index is the same interface as
                identified by the same  value  an  ds1LineIndex
                object instance."
            ::= { ds1TotalEntry 1 }



         ds1TotalESs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  deprecated
             DESCRIPTION
                "The counter associated with the number of  Er-
                rored  Seconds,  encountered by a DS1 interface
                in the previous 24 hour interval"
            ::= { ds1TotalEntry 2 }



         ds1TotalSESs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  deprecated
             DESCRIPTION
                "The counter  associated  with  the  number  of
                Severely  Errored Seconds, encountered by a ds1
                interface in the previous 24 hour interval."
            ::= { ds1TotalEntry 3 }









     F. Baker (editor)    Expires Nov 30 1992             [Page 33]





     Internet Draft             DS1 MIB                   June 1992


         ds1TotalSEFSs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  deprecated
             DESCRIPTION
                "The counter  associated  with  the  number  of
                Severely  Errored  Framing Seconds, encountered
                by a DS1 interface in the previous 24 hour  in-
                terval."
            ::= { ds1TotalEntry 4 }



         ds1TotalUASs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  deprecated

             DESCRIPTION
                "The counter associated with the number of Una-
                vailable  Seconds,  encountered by a ds1 inter-
                face in the previous 24 hour interval."
            ::= { ds1TotalEntry 5 }



         ds1TotalCSSs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  deprecated
             DESCRIPTION
                "The counter associated with the number of Con-
                trolled  Slip Seconds, encountered by a ds1 in-
                terface in the previous 24 hour interval."
            ::= { ds1TotalEntry 6 }















     F. Baker (editor)    Expires Nov 30 1992             [Page 34]





     Internet Draft             DS1 MIB                   June 1992


         ds1TotalBPVs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  deprecated
             DESCRIPTION
                "The counter associated with the number of  Bi-
                polar  Violations,  encountered by a DS1 inter-
                face in the previous 24 hour interval."
            ::= { ds1TotalEntry 7 }



         ds1TotalCVs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  deprecated
             DESCRIPTION
                "The counter associated with the number of Cod-
                ing  Violations, encountered by a DS1 interface
                in the previous 24 hour interval."
            ::= { ds1TotalEntry 8 }





























     F. Baker (editor)    Expires Nov 30 1992             [Page 35]





     Internet Draft             DS1 MIB                   June 1992


     -- the DS1 Gauge Interval

     -- The DS1 Gauge Interval Table contains various statistics
     -- collected by each DS1 Interface over the previous 24 hours of
     -- operation.  The past 24 hours are broken into 96 completed
     -- 15 minute intervals.


         ds1GgIntervalTable OBJECT-TYPE
             SYNTAX  SEQUENCE OF DS1GgIntervalEntry
             ACCESS  not-accessible
             STATUS  mandatory
             DESCRIPTION
                "The DS1 Gauge Interval table."
            ::= { ds1 6 }



         ds1GgIntervalEntry OBJECT-TYPE
             SYNTAX  DS1GgIntervalEntry
             ACCESS  not-accessible
             STATUS  mandatory
             DESCRIPTION
                "An entry in the DS1 Gauge Interval table."
            INDEX   { ds1GgIntervalIndex, ds1GgIntervalNumber }
            ::= { ds1GgIntervalTable 1 }


     DS1GgIntervalEntry ::=
         SEQUENCE {
             ds1GgIntervalIndex
                 INTEGER,
             ds1GgIntervalNumber
                 INTEGER,
             ds1GgIntervalESs
                 Gauge,
             ds1GgIntervalSESs
                 Gauge,
             ds1GgIntervalSEFSs
                 Gauge,
             ds1GgIntervalUASs
                 Gauge,
             ds1GgIntervalCSSs
                 Gauge,
             ds1GgIntervalBPVs





     F. Baker (editor)    Expires Nov 30 1992             [Page 36]





     Internet Draft             DS1 MIB                   June 1992


                 Gauge,
             ds1GgIntervalCVs
                 Gauge
         }


         ds1GgIntervalIndex OBJECT-TYPE
             SYNTAX  INTEGER (1..65535)
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The index value which uniquely identifies  the
                ds1  interface  to which this entry is applica-
                ble.  The interface identified by a  particular
                value  of  this  index is the same interface as
                identified by the same  value  an  ds1LineIndex
                object instance."
            ::= { ds1GgIntervalEntry 1 }



         ds1GgIntervalNumber OBJECT-TYPE
             SYNTAX  INTEGER (1..96)
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "A number between 1 and 96, where 1 is the most
                recently completed 15 minute interval and 96 is
                the least recently completed 15 minutes  inter-
                val   (assuming   that  all  96  intervals  are
                valid)."
            ::= { ds1GgIntervalEntry 2 }


















     F. Baker (editor)    Expires Nov 30 1992             [Page 37]





     Internet Draft             DS1 MIB                   June 1992


         ds1GgIntervalESs OBJECT-TYPE
             SYNTAX  Gauge
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter associated with the number of  Er-
                rored  Seconds,  encountered by a DS1 interface
                in  one  of  the  previous  96,  individual  15
                minute, intervals."
            ::= { ds1GgIntervalEntry 3 }



         ds1GgIntervalSESs OBJECT-TYPE
             SYNTAX  Gauge
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter  associated  with  the  number  of
                Severely  Errored Seconds, encountered by a ds1
                interface in one of the previous 96, individual
                15 minute, intervals."
            ::= { ds1GgIntervalEntry 4 }



         ds1GgIntervalSEFSs OBJECT-TYPE

             SYNTAX  Gauge
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter  associated  with  the  number  of
                Severely  Errored  Framing Seconds, encountered
                by a DS1 interface in one of the  previous  96,
                individual 15 minute, intervals."
            ::= { ds1GgIntervalEntry 5 }













     F. Baker (editor)    Expires Nov 30 1992             [Page 38]





     Internet Draft             DS1 MIB                   June 1992


         ds1GgIntervalUASs OBJECT-TYPE
             SYNTAX  Gauge
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter associated with the number of Una-
                vailable  Seconds,  encountered by a ds1 inter-
                face in one of the previous 96,  individual  15
                minute, intervals."
            ::= { ds1GgIntervalEntry 6 }



         ds1GgIntervalCSSs OBJECT-TYPE
             SYNTAX  Gauge
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter associated with the number of Con-
                trolled  Slip Seconds, encountered by a ds1 in-
                terface in one of the previous  96,  individual
                15 minute, intervals."
            ::= { ds1GgIntervalEntry 7 }



         ds1GgIntervalBPVs OBJECT-TYPE
             SYNTAX  Gauge
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter associated with the number of  Bi-
                polar  Violations,  encountered by a DS1 inter-
                face in one of the previous 96,  individual  15
                minute, intervals."
            ::= { ds1GgIntervalEntry 8 }














     F. Baker (editor)    Expires Nov 30 1992             [Page 39]





     Internet Draft             DS1 MIB                   June 1992


         ds1GgIntervalCVs OBJECT-TYPE
             SYNTAX  Gauge
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter associated with the number of Cod-
                ing  Violations, encountered by a DS1 interface
                in  one  of  the  previous  96,  individual  15
                minute, intervals."
            ::= { ds1GgIntervalEntry 9 }








































     F. Baker (editor)    Expires Nov 30 1992             [Page 40]





     Internet Draft             DS1 MIB                   June 1992


     -- the DS1 Gauge Total

     -- The DS1 Gauge Total Table contains the cumulative sum of the
     -- various statistics for the 24 hour interval preceding the
     -- first valid interval in the ds1CurrentTable.


         ds1GgTotalTable OBJECT-TYPE
             SYNTAX  SEQUENCE OF DS1GgTotalEntry
             ACCESS  not-accessible
             STATUS  mandatory
             DESCRIPTION
                "The DS1 Gauge Total table.  24 hour interval."
            ::= { ds1 7 }



         ds1GgTotalEntry OBJECT-TYPE
             SYNTAX  DS1GgTotalEntry
             ACCESS  not-accessible
             STATUS  mandatory
             DESCRIPTION
                "An entry in the DS1 Gauge Total table."
            INDEX   { ds1GgTotalIndex }
            ::= { ds1GgTotalTable 1 }


     DS1GgTotalEntry ::=
         SEQUENCE {
             ds1GgTotalIndex
                 INTEGER,
             ds1GgTotalESs
                 Gauge,
             ds1GgTotalSESs
                 Gauge,
             ds1GgTotalSEFSs
                 Gauge,
             ds1GgTotalUASs
                 Gauge,
             ds1GgTotalCSSs
                 Gauge,
             ds1GgTotalBPVs
                 Gauge,
             ds1GgTotalCVs
                 Gauge





     F. Baker (editor)    Expires Nov 30 1992             [Page 41]





     Internet Draft             DS1 MIB                   June 1992


         }


         ds1GgTotalIndex OBJECT-TYPE
             SYNTAX  INTEGER (1..65535)
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The index value which uniquely identifies  the
                ds1  interface  to which this entry is applica-
                ble.  The interface identified by a  particular
                value  of  this  index is the same interface as
                identified by the same  value  an  ds1LineIndex
                object instance."
            ::= { ds1GgTotalEntry 1 }



         ds1GgTotalESs OBJECT-TYPE
             SYNTAX  Gauge
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter associated with the number of  Er-
                rored  Seconds,  encountered by a DS1 interface
                in the previous 24 hour interval"
            ::= { ds1GgTotalEntry 2 }



         ds1GgTotalSESs OBJECT-TYPE
             SYNTAX  Gauge
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter  associated  with  the  number  of
                Severely  Errored Seconds, encountered by a ds1
                interface in the previous 24 hour interval."
            ::= { ds1GgTotalEntry 3 }











     F. Baker (editor)    Expires Nov 30 1992             [Page 42]





     Internet Draft             DS1 MIB                   June 1992


         ds1GgTotalSEFSs OBJECT-TYPE
             SYNTAX  Gauge
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter  associated  with  the  number  of
                Severely  Errored  Framing Seconds, encountered
                by a DS1 interface in the previous 24 hour  in-
                terval."
            ::= { ds1GgTotalEntry 4 }



         ds1GgTotalUASs OBJECT-TYPE
             SYNTAX  Gauge
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION

                "The counter associated with the number of Una-
                vailable  Seconds,  encountered by a ds1 inter-
                face in the previous 24 hour interval."
            ::= { ds1GgTotalEntry 5 }



         ds1GgTotalCSSs OBJECT-TYPE
             SYNTAX  Gauge
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter associated with the number of Con-
                trolled  Slip Seconds, encountered by a ds1 in-
                terface in the previous 24 hour interval."
            ::= { ds1GgTotalEntry 6 }















     F. Baker (editor)    Expires Nov 30 1992             [Page 43]





     Internet Draft             DS1 MIB                   June 1992


         ds1GgTotalBPVs OBJECT-TYPE
             SYNTAX  Gauge
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter associated with the number of  Bi-
                polar  Violations,  encountered by a DS1 inter-
                face in the previous 24 hour interval."
            ::= { ds1GgTotalEntry 7 }



         ds1GgTotalCVs OBJECT-TYPE
             SYNTAX  Gauge
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter associated with the number of Cod-
                ing  Violations, encountered by a DS1 interface
                in the previous 24 hour interval."
            ::= { ds1GgTotalEntry 8 }





























     F. Baker (editor)    Expires Nov 30 1992             [Page 44]





     Internet Draft             DS1 MIB                   June 1992


     -- The DS1 Far End Group

     -- Implementation of this group is optional for all systems
     -- that attach to a DS1 Interface.

     -- The DS1 Far End Group consists of three tables:
     --   DS1 Far End Current
     --   DS1 Far End Gauge Interval
     --   DS1 Far End Gauge Total

     -- The DS1 Far End Current

     -- The DS1 Far End Current table contains various statistics being
     -- collected for the current 15 minute interval.
     -- The statistics are collected from the far end messages on the
     -- Facilities Data Link.  The definitions are the same as described for
     -- the near-end information.


         ds1FarEndCurrentTable OBJECT-TYPE
             SYNTAX  SEQUENCE OF DS1FarEndCurrentEntry
             ACCESS  not-accessible
             STATUS  mandatory
             DESCRIPTION
                "The DS1 Far End Current table."
            ::= { ds1 8 }



         ds1FarEndCurrentEntry OBJECT-TYPE
             SYNTAX  DS1FarEndCurrentEntry
             ACCESS  not-accessible
             STATUS  mandatory
             DESCRIPTION
                "An entry in the DS1 Far End Current table."
            INDEX   { ds1FarEndCurrentIndex }
            ::= { ds1FarEndCurrentTable 1 }


     DS1FarEndCurrentEntry ::=
         SEQUENCE {
             ds1FarEndCurrentIndex
                 INTEGER,
             ds1FarEndCurrentESs
                 Counter,





     F. Baker (editor)    Expires Nov 30 1992             [Page 45]





     Internet Draft             DS1 MIB                   June 1992


             ds1FarEndCurrentSESs
                 Counter,
             ds1FarEndCurrentSEFSs
                 Counter,
             ds1FarEndCurrentCSSs
                 Counter,
             ds1FarEndCurrentLESs
                 Counter,
             ds1FarEndCurrentCVs
                 Counter
         }


         ds1FarEndCurrentIndex OBJECT-TYPE
             SYNTAX  INTEGER (1..65535)
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The index value which uniquely identifies  the
                DS1  interface  to which this entry is applica-
                ble.  The interface identified by a  particular
                value  of  this  index is the same interface as
                identified by the same  value  an  ds1LineIndex
                object instance."
            ::= { ds1FarEndCurrentEntry 1 }



         ds1FarEndCurrentESs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter associated with the number of  Far
                Far  End  Errored  Seconds encountered by a ds1
                interface in the current 15 minute interval."
            ::= { ds1FarEndCurrentEntry 2 }













     F. Baker (editor)    Expires Nov 30 1992             [Page 46]





     Internet Draft             DS1 MIB                   June 1992


         ds1FarEndCurrentSESs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter associated with the number of  Far
                End  Severely  Errored Seconds encountered by a
                DS1 interface in the current 15  minute  inter-
                val."
            ::= { ds1FarEndCurrentEntry 3 }



         ds1FarEndCurrentSEFSs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter associated with the number of  Far
                End  Severely  Errored Framing Seconds, encoun-
                tered by a DS1  interface  in  the  current  15
                minute interval."
            ::= { ds1FarEndCurrentEntry 4 }



         ds1FarEndCurrentCSSs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter associated with the number of  Far
                End  Controlled  Slip Seconds, encountered by a
                ds1 interface in the current 15  minute  inter-
                val."
            ::= { ds1FarEndCurrentEntry 5 }














     F. Baker (editor)    Expires Nov 30 1992             [Page 47]





     Internet Draft             DS1 MIB                   June 1992


         ds1FarEndCurrentLESs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter associated with the number of  Far
                End  Bipolar  Violations,  encountered by a DS1
                interface in the current 15 minute interval."
            ::= { ds1FarEndCurrentEntry 6 }



         ds1FarEndCurrentCVs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter associated with the number of  Far
                End  Coding Violations reported via the far end
                block error count encountered by a  DS1  inter-
                face in the current 15 minute interval."
            ::= { ds1FarEndCurrentEntry 7 }




























     F. Baker (editor)    Expires Nov 30 1992             [Page 48]





     Internet Draft             DS1 MIB                   June 1992


     -- The DS1 Far End Gauge Interval

     -- The DS1 Far End Gauge Interval Table contains various statistics
     -- collected by each DS1 interface over the previous 24 hours of
     -- operation.  The past 24 hours are broken into 96
     -- completed 15 minute intervals.


         ds1FarEndGgIntervalTable OBJECT-TYPE
             SYNTAX  SEQUENCE OF DS1FarEndGgIntervalEntry
             ACCESS  not-accessible
             STATUS  mandatory
             DESCRIPTION
                "The DS1 Far End Gauge Interval table."
            ::= { ds1 9 }



         ds1FarEndGgIntervalEntry OBJECT-TYPE
             SYNTAX  DS1FarEndGgIntervalEntry
             ACCESS  not-accessible
             STATUS  mandatory
             DESCRIPTION
                "An entry in the DS1  Far  End  Gauge  Interval
                table."
            INDEX   { ds1FarEndGgIntervalIndex, ds1FarEndGgIntervalNumber }
            ::= { ds1FarEndGgIntervalTable 1 }


     DS1FarEndGgIntervalEntry ::=
         SEQUENCE {
             ds1FarEndGgIntervalIndex
                 INTEGER,
             ds1FarEndGgIntervalNumber
                 INTEGER,
             ds1FarEndGgIntervalESs
                 Gauge,
             ds1FarEndGgIntervalSESs
                 Gauge,
             ds1FarEndGgIntervalSEFSs
                 Gauge,
             ds1FarEndGgIntervalCSSs
                 Gauge,
             ds1FarEndGgIntervalLESs
                 Gauge,





     F. Baker (editor)    Expires Nov 30 1992             [Page 49]





     Internet Draft             DS1 MIB                   June 1992


             ds1FarEndGgIntervalCVs
                 Gauge
         }


         ds1FarEndGgIntervalIndex OBJECT-TYPE
             SYNTAX  INTEGER (1..65535)
             ACCESS  read-only

             STATUS  mandatory
             DESCRIPTION
                "The index value which uniquely identifies  the
                DS1  interface  to which this entry is applica-
                ble.  The interface identified by a  particular
                value  of  this  index is the same interface as
                identified by the same  value  an  ds1LineIndex
                object instance."
            ::= { ds1FarEndGgIntervalEntry 1 }



         ds1FarEndGgIntervalNumber OBJECT-TYPE
             SYNTAX  INTEGER (1..96)
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "A number between 1 and 96, where 1 is the most
                recently completed 15 minute interval and 96 is
                the least recently completed 15 minutes  inter-
                val   (assuming   that  all  96  intervals  are
                valid)."
            ::= { ds1FarEndGgIntervalEntry 2 }


















     F. Baker (editor)    Expires Nov 30 1992             [Page 50]





     Internet Draft             DS1 MIB                   June 1992


         ds1FarEndGgIntervalESs OBJECT-TYPE
             SYNTAX  Gauge
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter associated with the number of  Far
                End Errored Seconds encountered by a DS1 inter-
                face in one of the previous 96,  individual  15
                minute, intervals."
            ::= { ds1FarEndGgIntervalEntry 3 }



         ds1FarEndGgIntervalSESs OBJECT-TYPE
             SYNTAX  Gauge
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter associated with the number of  Far
                End  Severely  Errored Seconds encountered by a
                DS1 interface in one of the previous 96,  indi-
                vidual 15 minute, intervals."
            ::= { ds1FarEndGgIntervalEntry 4 }



         ds1FarEndGgIntervalSEFSs OBJECT-TYPE
             SYNTAX  Gauge
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter associated with the number of  Far
                End  Severely  Errored Framing Seconds, encoun-
                tered by a DS1 interface in one of the previous
                96, individual 15 minute, intervals."
            ::= { ds1FarEndGgIntervalEntry 5 }














     F. Baker (editor)    Expires Nov 30 1992             [Page 51]





     Internet Draft             DS1 MIB                   June 1992


         ds1FarEndGgIntervalCSSs OBJECT-TYPE
             SYNTAX  Gauge
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter associated with the number of  Far
                End  Controlled  Slip Seconds, encountered by a
                DS1 interface in one of the previous 96,  indi-
                vidual 15 minute, intervals."
            ::= { ds1FarEndGgIntervalEntry 6 }



         ds1FarEndGgIntervalLESs OBJECT-TYPE
             SYNTAX  Gauge
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter associated with the number of  Far
                End  Bipolar  Violations,  encountered by a DS1
                interface in one of the previous 96, individual
                15 minute, intervals."
            ::= { ds1FarEndGgIntervalEntry 7 }



         ds1FarEndGgIntervalCVs OBJECT-TYPE
             SYNTAX  Gauge
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter associated with the number of  Far
                End  Coding Violations reported via the far end
                block error count encountered by a  DS1  inter-
                face  in  one of the previous 96, individual 15
                minute, intervals."
            ::= { ds1FarEndGgIntervalEntry 8 }













     F. Baker (editor)    Expires Nov 30 1992             [Page 52]





     Internet Draft             DS1 MIB                   June 1992


     -- The DS1 Far End Gauge Total

     -- The DS1 Far End Gauge Total Table contains the cumulative sum of the
     -- various statistics for the 24 hour interval preceding the
     -- first valid interval in the ds1FarEndCurrentTable.


         ds1FarEndGgTotalTable OBJECT-TYPE
             SYNTAX  SEQUENCE OF DS1FarEndGgTotalEntry
             ACCESS  not-accessible
             STATUS  mandatory
             DESCRIPTION
                "The DS1 Far End Gauge Total  table.   24  hour
                interval."
            ::= { ds1 10 }



         ds1FarEndGgTotalEntry OBJECT-TYPE
             SYNTAX  DS1FarEndGgTotalEntry
             ACCESS  not-accessible
             STATUS  mandatory
             DESCRIPTION
                "An entry  in  the  DS1  Far  End  Gauge  Total
                table."
            INDEX   { ds1FarEndGgTotalIndex }
            ::= { ds1FarEndGgTotalTable 1 }


     DS1FarEndGgTotalEntry ::=
         SEQUENCE {
             ds1FarEndGgTotalIndex
                 INTEGER,
             ds1FarEndGgTotalESs
                 Gauge,
             ds1FarEndGgTotalSESs
                 Gauge,
             ds1FarEndGgTotalSEFSs
                 Gauge,
             ds1FarEndGgTotalCSSs
                 Gauge,
             ds1FarEndGgTotalLESs
                 Gauge,
             ds1FarEndGgTotalCVs
                 Gauge





     F. Baker (editor)    Expires Nov 30 1992             [Page 53]





     Internet Draft             DS1 MIB                   June 1992


         }


         ds1FarEndGgTotalIndex OBJECT-TYPE
             SYNTAX  INTEGER (1..65535)
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The index value which uniquely identifies  the
                DS1  interface  to which this entry is applica-
                ble.  The interface identified by a  particular
                value  of  this  index is the same interface as
                identified by the same  value  an  ds1LineIndex
                object instance."
            ::= { ds1FarEndGgTotalEntry 1 }



         ds1FarEndGgTotalESs OBJECT-TYPE
             SYNTAX  Gauge
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter associated with the number of  Far
                End Errored Seconds encountered by a ds1 inter-
                face in the previous 24 hour interval."
            ::= { ds1FarEndGgTotalEntry 2 }



         ds1FarEndGgTotalSESs OBJECT-TYPE
             SYNTAX  Gauge
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter associated with the number of  Far
                End  Severely  Errored Seconds encountered by a
                DS1 interface in the previous  24  hour  inter-
                val."
            ::= { ds1FarEndGgTotalEntry 3 }










     F. Baker (editor)    Expires Nov 30 1992             [Page 54]





     Internet Draft             DS1 MIB                   June 1992


         ds1FarEndGgTotalSEFSs OBJECT-TYPE
             SYNTAX  Gauge
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter associated with the number of  Far
                End  Severely  Errored Framing Seconds, encoun-
                tered by a DS1 interface  in  the  previous  24
                hour interval."
            ::= { ds1FarEndGgTotalEntry 4 }



         ds1FarEndGgTotalCSSs OBJECT-TYPE
             SYNTAX  Gauge
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter associated with the number of  Far
                End  Controlled  Slip Seconds, encountered by a
                DS1 interface in the previous  24  hour  inter-
                val."
            ::= { ds1FarEndGgTotalEntry 5 }



         ds1FarEndGgTotalLESs OBJECT-TYPE
             SYNTAX  Gauge
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter associated with the number of  Far
                End  Bipolar  Violations,  encountered by a DS1
                interface in the previous 24 hour interval."
            ::= { ds1FarEndGgTotalEntry 6 }















     F. Baker (editor)    Expires Nov 30 1992             [Page 55]





     Internet Draft             DS1 MIB                   June 1992


         ds1FarEndGgTotalCVs OBJECT-TYPE
             SYNTAX  Gauge
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter associated with the number of  Far
                End  Coding Violations reported via the far end
                block error count encountered by a  DS1  inter-
                face in the previous 24 hour interval."
            ::= { ds1FarEndGgTotalEntry 7 }








































     F. Baker (editor)    Expires Nov 30 1992             [Page 56]





     Internet Draft             DS1 MIB                   June 1992


     -- the DS1 Fractional group

     -- Implementation of this group is mandatory for those
     -- systems dividing a DS1 into channels containing different
     -- data streams that are of local interest.  Systems which
     -- are indifferent to data content, such as CSUs, need not
     -- implement it.

     -- The DS1 fractional table contains identifies which DS1
     -- channels associated with a CSU are being used to support a
     -- logical interface, i.e., an entry in the interfaces table
     -- from the Internet-standard MIB.

     -- For example, consider an application managing a North
     -- American ISDN Primary Rate link whose division is a 384 KBPS
     -- H1 "B" Channel for Video, a second H1 for data to a primary
     -- routing peer, and 12 64 KBPS H0 "B" Channels. Consider that
     -- some subset of the H0 channels are used for voice and the
     -- remainder are available for dynamic data calls.

     -- we count a total of 14 interfaces multiplexed onto the DS1
     -- interface. Six DS1 channels (for the sake of the example,
     -- channels 1..6) are used for Video, six more (7..11 and 13)
     -- are used for data, and the remaining 12 are are in channels
     -- 12 and 14..24.

     -- Let us further imagine that ifIndex 2 is of type DS1 and
     -- refers to the DS1 interface, and that the interfaces layered
     -- onto it are numbered 3..16.

     -- We might describe the allocation of channels, in the
     -- ds1FracTable, as follows:

     -- ds1FracIfIndex.2. 1 = 3    ds1FracIfIndex.2.13 = 4
     -- ds1FracIfIndex.2. 2 = 3    ds1FracIfIndex.2.14 = 6
     -- ds1FracIfIndex.2. 3 = 3    ds1FracIfIndex.2.15 = 7
     -- ds1FracIfIndex.2. 4 = 3    ds1FracIfIndex.2.16 = 8
     -- ds1FracIfIndex.2. 5 = 3    ds1FracIfIndex.2.17 = 9
     -- ds1FracIfIndex.2. 6 = 3    ds1FracIfIndex.2.18 = 10
     -- ds1FracIfIndex.2. 7 = 4    ds1FracIfIndex.2.19 = 11
     -- ds1FracIfIndex.2. 8 = 4    ds1FracIfIndex.2.20 = 12
     -- ds1FracIfIndex.2. 9 = 4    ds1FracIfIndex.2.21 = 13
     -- ds1FracIfIndex.2.10 = 4    ds1FracIfIndex.2.22 = 14
     -- ds1FracIfIndex.2.11 = 4    ds1FracIfIndex.2.23 = 15
     -- ds1FracIfIndex.2.12 = 5    ds1FracIfIndex.2.24 = 16





     F. Baker (editor)    Expires Nov 30 1992             [Page 57]





     Internet Draft             DS1 MIB                   June 1992


     --      For ds1ESF, ds1D4, and ds1ANSI-ESF, there are 24 legal
     --      channels, numbered 1 through 24.
     --
     --      For G.704, there are 32 legal channels, numbered 1
     --      through 32.


         ds1FracTable OBJECT-TYPE
             SYNTAX  SEQUENCE OF DS1FracEntry
             ACCESS  not-accessible
             STATUS  mandatory
             DESCRIPTION
                "The DS1 Fractional table."
            ::= { ds1 5 }



         ds1FracEntry OBJECT-TYPE
             SYNTAX  DS1FracEntry
             ACCESS  not-accessible
             STATUS  mandatory
             DESCRIPTION
                "An entry in the DS1 Fractional table."
            INDEX   { ds1FracIndex, ds1FracNumber }
            ::= { ds1FracTable 1 }


     DS1FracEntry ::=
         SEQUENCE {
             ds1FracIndex
                 INTEGER,
             ds1FracNumber
                 INTEGER (1..32),
             ds1FracIfIndex
                 INTEGER
         }














     F. Baker (editor)    Expires Nov 30 1992             [Page 58]





     Internet Draft             DS1 MIB                   June 1992


         ds1FracIndex OBJECT-TYPE
             SYNTAX  INTEGER
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The index value which uniquely identifies  the
                DS1  interface  to which this entry is applica-
                ble.  The interface identified by a  particular
                value  of  this  index is the same interface as
                identified by the same  value  an  ds1LineIndex
                object instance."
            ::= { ds1FracEntry 1 }



         ds1FracNumber OBJECT-TYPE
             SYNTAX  INTEGER (1..32)
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The channel number for this entry."
            ::= { ds1FracEntry 2 }



         ds1FracIfIndex OBJECT-TYPE
             SYNTAX  INTEGER
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "An index value that uniquely identifies an in-
                terface.  The interface identified by a partic-
                ular value of this index is the same  interface
                as  identified by the same value an ifIndex ob-
                ject instance. If no interface is currently us-
                ing  a channel, the value should be zero.  If a
                single interface occupies more  than  one  time
                slot,  that ifIndex value will be found in mul-
                tiple time slots."
            ::= { ds1FracEntry 3 }


     END







     F. Baker (editor)    Expires Nov 30 1992             [Page 59]





     Internet Draft             DS1 MIB                   June 1992


     7.  Acknowledgements

     This document was produced by the Trunk MIB Working Group:

     In addition, the comments of the following individuals are
     also acknowledged.  Without their input, the document would
     not be what it is.

          Tracy Cox       Bellcore
          James Watt      Newbridge








































     F. Baker (editor)    Expires Nov 30 1992             [Page 60]





     Internet Draft             DS1 MIB                   June 1992


     8.  References

     [1]  V. Cerf, IAB Recommendations for the Development of
          Internet Network Management Standards.  Internet Working
          Group Request for Comments 1052.  Network Information
          Center, SRI International, Menlo Park, California,
          (April, 1988).

     [2]  V. Cerf, Report of the Second Ad Hoc Network Management
          Review Group, Internet Working Group Request for Comments
          1109.  Network Information Center, SRI International,
          Menlo Park, California, (August, 1989).

     [3]  M.T. Rose and K. McCloghrie, Structure and Identification
          of Management Information for TCP/IP-based internets,
          Internet Working Group Request for Comments 1155.
          Network Information Center, SRI International, Menlo
          Park, California, (May, 1990).

     [4]  K. McCloghrie and M.T. Rose, Management Information Base
          for Network Management of TCP/IP-based internets,
          Internet Working Group Request for Comments 1156.
          Network Information Center, SRI International, Menlo
          Park, California, (May, 1990).

     [5]  J.D. Case, M.S. Fedor, M.L. Schoffstall, and J.R. Davin,
          Simple Network Management Protocol, Internet Working
          Group Request for Comments 1157.  Network Information
          Center, SRI International, Menlo Park, California, (May,
          1990).

     [6]  M.T. Rose (editor), Management Information Base for
          Network Management of TCP/IP-based internets, Internet
          Working Group Request for Comments 1213.  Network
          Information Center, SRI International, Menlo Park,
          California, (May, 1990).

     [7]  Information processing systems - Open Systems
          Interconnection - Specification of Abstract Syntax
          Notation One (ASN.1), International Organization for
          Standardization.  International Standard 8824, (December,
          1987).

     [8]  Information processing systems - Open Systems
          Interconnection - Specification of Basic Encoding Rules





     F. Baker (editor)    Expires Nov 30 1992             [Page 61]





     Internet Draft             DS1 MIB                   June 1992


          for Abstract Notation One (ASN.1), International
          Organization for Standardization.  International Standard
          8825, (December, 1987).

     [9]  M.T. Rose, K. McCloghrie (editors), Towards Concise MIB
          Definitions, Internet Draft, Internet Engineering Task
          Force, (September, 1990).

     [10] M.T. Rose (editor), A Convention for Defining Traps for
          use with the SNMP, Internet Draft, Internet Engineering
          Task Force, (September, 1990).

     [11] AT&T Information Systems, AT&T ESF DS1 Channel Service
          Unit User's Manual, 999-100-305, February 1988.

     [12] AT&T Technical Reference, Requirements for Interfacing
          Digital Terminal Equipment to Services Employing the
          Extended Superframe Format, Publication 54016, May 1988.

     [13] CCITT Specifications Volume III, Recommendation G.703,
          Physical/Electrical Characteristics of Hierarchical
          Digital Interfaces, July 1988.

     14]  CCITT Specifications Volume III, Recommendation G.704,
          Synchronous frame structures used at primary and
          secondary hierarchical levels, July 1988.

     [15] American National Standard for Telecommunications --
          Layer 1 In-Service Digital Transmission Performance
          Monitoring T1M1/92-0xx, T1M1.3/92-005R1, April 1992.

     [16] Bell System Technical Reference, Publication 62411, High
          Capacity Digital Service Channel Interface Specification,
          September 1983.

     [17] Bell System Technical Reference, Publication 43801,
          "Digital Channel Bank Requirements and Objectives",
          November 1982.












     F. Baker (editor)    Expires Nov 30 1992             [Page 62]





     Internet Draft             DS1 MIB                   June 1992


     Table of Contents


     1 Status of this Memo ...................................    1
     2 Abstract ..............................................    1
     3 Abstract ..............................................    2
     4 The Network Management Framework ......................    2
     5 Objects ...............................................    3
     5.1 Format of Definitions ...............................    3
     5.2 Changes from RFC 1232 ...............................    3
     5.3 Overview ............................................    5
     5.4 Binding between ifIndex and DS1 Interfaces ..........    5
     5.5 Objectives of this MIB Module .......................    7
     5.6 DS1 Terminology .....................................    7
     6 Definitions ...........................................   11
     6.1 DS1 Near End Group ..................................   12
     6.1.1 DS1 Configuration Table ...........................   12
     6.1.2 DS1 Interval Table (deprecated) ...................   23
     6.1.3 DS1 Current Table .................................   28
     6.1.4 DS1 Total Table (deprecated) ......................   32
     6.1.5 DS1 Gauge Interval Table ..........................   36
     6.1.6 DS1 Gauge Total Table .............................   41
     6.2 DS1 Far End Group ...................................   45
     6.2.1 DS1 Far End Current Table .........................   45
     6.2.2 DS1 Far End Gauge Interval Table ..................   49
     6.2.3 DS1 Far End Gauge Total Table .....................   53
     6.3 DS1 Fractional Group ................................   57
     6.3.1 DS1 Fractional Table ..............................   57
     7 Acknowledgements ......................................   60
     8 References ............................................   61




















     F. Baker (editor)    Expires Nov 30 1992             [Page 63]











Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa10084;
          29 Jun 92 13:52 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa10080;
          29 Jun 92 13:52 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa10273;
          29 Jun 92 13:53 EDT
Received: from saffron.acc.com by fennel.acc.com (4.1/SMI-4.1)
	id AA19974; Mon, 29 Jun 92 10:26:21 PDT
Received: by saffron.acc.com (4.1/SMI-4.1)
	id AA00455; Mon, 29 Jun 92 10:25:43 PDT
Date: Mon, 29 Jun 92 10:25:43 PDT
From: Fred Baker <fbaker@acc.com>
Message-Id: <9206291725.AA00455@saffron.acc.com>
To: trunk-mib@fennel.acc.com
Subject: DS1 MIB, throw out the one you just got

Folks:

I got Tracy's comments and edited them in, and mailed the DS1 MIB proposal
to the list a few minutes ago.  Then I got some more comments from her.

Scrap the one you just got and review this. :^)

Thanks, Fred.
=========================================================================





     Internet Draft             DS1 MIB                   June 1992


       Definitions of Managed Objects for the DS1 Interface Type

                      Mon Jun 29 10:21:09 PDT 1992


                           Fred Baker, Editor

                    Advanced Computer Communications
                            315 Bollay Drive
                    Santa Barbara, California 93117

                             fbaker@acc.com






     1.  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. Internet Drafts may be updated, replaced, or obsoleted
     by other documents at any time.  It is not appropriate to use
     Internet Drafts as reference material or to cite them other
     than as a "working draft" or "work in progress."

     Please check the I-D abstract listing contained in each
     Internet Draft directory to learn the current status of this
     or any other Internet Draft.

     2.  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 DS1 Interfaces.

     This memo does not, in its draft form, specify a standard for
     the Internet community.





     F. Baker (editor)    Expires Nov 30 1992              [Page 1]





     Internet Draft             DS1 MIB                   June 1992


     3.  The Network Management Framework

     The Internet-standard Network Management Framework consists of
     three components.  They are:

     RFC 1155 which defines the SMI, the mechanisms used for
     describing and naming objects for the purpose of management.
     RFC 1212 defines a more concise description mechanism, which
     is wholly consistent with the SMI.

     RFC 1156 which defines MIB-I, the core set of managed objects
     for the Internet suite of protocols.  RFC 1213 defines MIB-II,
     an evolution of MIB-I based on implementation experience and
     new operational requirements.

     RFC 1157 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.






























     F. Baker (editor)    Expires Nov 30 1992              [Page 2]





     Internet Draft             DS1 MIB                   June 1992


     4.  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) [7] 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 [3]
     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
     [8], subject to the additional requirements imposed by the
     SNMP.


     4.1.  Format of Definitions

     Section 6 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 RFC1212 [13].

     4.2.  Changes from RFC 1232

     The changes from RFC1232 are the following:

     (1)  This MIB module contains three groups: DS1 Near End Group
          which is mandatory, DS1 Far End Group which is optional,
          and the Fractional Table, which is optional.





     F. Baker (editor)    Expires Nov 30 1992              [Page 3]





     Internet Draft             DS1 MIB                   June 1992


     (2)  The Far End Group is a new group and contains statistics
          that are collected from the far end DS1 interface.  The
          Far End Group may only be implemented by DS1 systems that
          use the facilities data link to exchange this
          information.  Typically, these are ANSI ESF links,
          although some vendors use proprietary means to do this on
          other types of links.

     (3)  ds1CSUIndex has been renamed ds1LineIndex.  This object
          is the identifier of a DS1 Interface on a device.

     (4)  ds1Index has been renamed ds1IfIndex.  This value for
          this object is equal to the value of ifIndex from the
          Interfaces table of MIB II (RFC 1213).

     (5)  ds1Loopback has been deprecated.

     (6)  A new object has been added called ds1LoopbackConfig,
          which better describes the loopback capabilities of a DS1
          interface on a device.

     (7)  ds1YellowAlarm has been deprecated.

     (8)  ds1RedAlarm has been deprecated.

     (9)  A new object has been added called ds1LineStatus.  This
          object better describes the status (e.g., failure state
          and loopback state) of a DS1 interface.

     (10) The ds1IntervalTable and the ds1TotalTable have been
          deprecated and replaced with two other tables,
          ds1GgIntervalTable and ds1GgTotalTable, respectively,
          whose objects have a SYNTAX of Gauge.

















     F. Baker (editor)    Expires Nov 30 1992              [Page 4]





     Internet Draft             DS1 MIB                   June 1992


     5.  Overview

     These objects are used when the particular media being used to
     realize an interface is a DS1 physical interface.  At present,
     this applies to these values of the ifType variable in the
     Internet- standard MIB:
            ds1 (18)
            e1  (19)

     The definitions contained herein are based on the AT&T T-1
     specifications and Extended Superframe (ESF) format [11, 12],
     the latter of which conforms to proposed ANSI specifications
     [15].  The various T1 and E1 line disciplines are similar
     enough that separate MIBs are unwarranted, although there are
     some differences.  For example, Loss of Frame is defined more
     rigorously in the ESF specification than in the D4
     specification, but it is defined in both.

     5.1.  Binding between ifIndex and DS1 Interfaces

     Different physical configurations for the support of SNMP with
     DS1 equipment exist. To accommodate these scenarios, two
     different indices for DS1 interfaces are introduced in this
     MIB.  These indices are ds1IfIndex and ds1LineIndex.

     External interface scenario: the SNMP Agent represents all
     managed DS1 lines as external interfaces (for example, an
     Agent residing on the device supporting DS1 interfaces
     directly):

     For this scenario, all interfaces are assigned an integer
     value equal to ifIndex, and the following applies:

          ifIndex=ds1IfIndex=ds1LineIndex for all interfaces.

     The ds1IfIndex column of the DS1 Configuration table relates
     each DS1 interface to its corresponding interface (ifIndex) in
     the Internet-standard MIB (MIB-II RFC1213).

     External&Internal interface scenario: the SNMP Agents resides
     on an host external from the device supporting DS1 interfaces
     (e.g., a router). The Agent represents both the host and the
     DS1 device.  The index ds1LineIndex is used to not only
     represent the DS1 interfaces external from the host/DS1-device
     combination, but also the DS1 interfaces connecting the host





     F. Baker (editor)    Expires Nov 30 1992              [Page 5]





     Internet Draft             DS1 MIB                   June 1992


     and the DS1 device.  The index ds1IfIndex is always equal to
     ifIndex.

     Example:

     A shelf full of CSUs connected to a Router. An SNMP Agent
     residing on the router proxies for itself and the CSU. The
     router has also an Ethernet interface:
           +-----+
     |     |     |
     |     |     |               +---------------------+
     |E    |     |  1.544  MBPS  |              Line#A | DS1 Link
     |t    |  R  |---------------+ - - - - -  - - -  - +------>
     |h    |     |               |                     |
     |e    |  O  |  1.544  MBPS  |              Line#B | DS1 Link
     |r    |     |---------------+ - - - - - - - - - - +------>
     |n    |  U  |               |  CSU Shelf          |
     |e    |     |  1.544  MBPS  |              Line#C | DS1 Link
     |t    |  T  |---------------+ - - - -- -- - - - - +------>
     |     |     |               |                     |
     |-----|  E  |  1.544  MBPS  |              Line#D | DS1 Link
     |     |     |---------------+ -  - - - -- - - - - +------>
     |     |  R  |               |_____________________|
     |     |     |
     |     +-----+

     The assignment of the index values could for example be:

     ifIndex (= ds1IfIndex)                  ds1LineIndex

     1                   NA                  NA (Ethernet)
     2      Line#A   Router Side             7
     2      Line#A   Network Side            6
     3      Line#B   Router Side             9
     3      Line#B   Network Side            8
     4      Line#C   Router Side            11
     4      Line#C   Network Side           10
     5      Line#D   Router Side            13
     5      Line#D   Network Side           12

     For this example, ifNumber is equal to 5.  Note the following
     description of ds1LineIndex: the ds1LineIndex identifies a DS1
     Interface on a managed device.  If there is an ifEntry that is
     directly associated with this and only this DS1 interface, it
     should have the same value as ifIndex.  Otherwise, number the





     F. Baker (editor)    Expires Nov 30 1992              [Page 6]





     Internet Draft             DS1 MIB                   June 1992


     ds1LineIndices with an unique identifier following the rules
     of choosing a number greater than ifNumber and numbering
     inside interfaces (e.g., equipment side) with even numbers and
     outside interfaces (e.g, network side) with odd numbers.

     If the CSU shelf is managed by itself by a local SNMP Agent,
     the situation would be:
          ifIndex (= ds1IfIndex)               ds1LineIndex

          1      Line#A     Router Side              1
          2      Line#A     Network Side            2
          3      Line#B     Router Side              3
          4      Line#B     Network Side            4
          5      Line#C     Router Side             5
          6      Line#C     Network Side            6
          7      Line#D     Router Side             7
          8      Line#D     Network Side            8

     5.2.  Objectives of this MIB Module

     There are numerous things that could be included in a MIB for
     DS1 signals: the management of multiplexors, CSUs, DSUs, and
     the like.  The intent of this document is to facilitate the
     common management of all devices with DS1 interfaces.  As
     such, a design decision was made up front to very closely
     align the MIB with the set of objects that can generally be
     read from DS1 devices that are currently deployed.

     5.3.  DS1 Terminology

     The terminology used in this document to describe error
     conditions on a DS1 interface as monitored by a DS1 device are
     based on the definitions from the ANSI T1M1.3/92-005 draft
     standard [12].  If the definition in this document does not
     match the definition in the ANSI T1M1.3/92-005R1 draft
     document, the implementer should follow the definition
     described in this document.

     Bipolar Violation (BPV)
          A BPV for an AMI-coded signal is the occurrence of a
          pulse of the same polarity as the previous pulse.  A BPV
          for a B8ZS-coded signal is the occurrence of a pulse of
          the same polarity as the previous pulse without being a
          part of the zero substitution code.






     F. Baker (editor)    Expires Nov 30 1992              [Page 7]





     Internet Draft             DS1 MIB                   June 1992


     Coding Violation (CV)
          A coding violation is a count of frame synchronization
          bit errors in the SF format, or a count of CRC-6 errors
          in the ESF format.

     Controlled Slip Seconds (CSS)
          A CS is the replication or deletion of the 192 payload
          bits of a DS1 frame.  A CS may be performed when there is
          a difference between the timing of a synchronous
          receiving terminal and the received signal.  A CS does
          not cause an Out of Frame defect.  A CSS is a count of
          one-second intervals with one or more controlled slips.

     Errored Seconds (ES)
          For ESF signals an Errored Second is a second with one or
          more Code Violations OR one or more Out of Frame defects
          OR one or more Controlled Slip events OR a detected
          incoming AIS.  In D4 and G.704 (E1 signals) section
          2.1.3.2 (eg, G.704 which does not implement the CRC), the
          presence of Bipolar Violations also triggers an Errored
          Second.  For SF signals an ES is a count of one-second
          intervals containing one or more FE (framing errors)
          events, one or more OOF defects or a detected incoming
          AIS, or one or more CS events.

     Severely Errored Seconds (SES)
          A Severely Errored Second for ANSI ESF signals is a
          second with 320 or more Code Violation Error Events OR
          one or more Out of Frame defects OR a detected incoming
          AIS.  For SF signal, a SES is a count of one-second
          intervals with eight or more FE events, or an OOF defect
          or a detected incoming AIS.  Controlled slips are not
          included in this parameter.  Severely Errored Framing
          Second (SEFS) An Severely Errored Framing Second is a
          second with one or more Out of Frame defects or a
          detected incoming AIS.

     Unavailable Seconds (UAS)
          UAS are calculated by counting the number of seconds that
          the interface is unavailable.  The DS1 interface is said
          to be unavailable from the onset of 10 contiguous SESs,
          or the onset of the condition leading to a failure (see
          Failure States).  If the condition leading to the failure
          was immediately preceded by one or more contiguous SESs,
          then the DS1 interface unavailability starts from the





     F. Baker (editor)    Expires Nov 30 1992              [Page 8]





     Internet Draft             DS1 MIB                   June 1992


          onset of these SESs.  Once unavailable, and if no failure
          is present, the DS1 interface becomes available at the
          onset of 10 contiguous seconds with no SESs.  Once
          unavailable, and if a failure is present, the DS1
          interface becomes available at the onset of 10 contiguous
          seconds with no SESs, if the failure clearing time is
          less than or equal to 10 seconds.  If the failure
          clearing time is more than 10 seconds, the DS1 interface
          becomes available at the onset of 10 contiguous seconds
          with no SESs, or the onset period leading to the
          successful clearing condition, whichever occurs later.
          With respect to the DS1 error counts, all counters are
          incremented while the DS1 interface is deemed available.
          While the interface is deemed unavailable, the only count
          that is incremented is UASs.

          A special case exists when the 10 or more second period
          crosses the 900 second statistics window boundary, as the
          foregoing description implies that the Severely Errored
          Second and Unavailable Second counters must be adjusted
          when the Unavailable Signal State is entered.  Clearly,
          successive GETs of the affected ds1GgIntervalSESs and
          ds1GgIntervalUASs objects will return differing values if
          the first GET occurs during the first few seconds of the
          window.    This is viewed as an unavoidable side-effect
          of selecting the presently defined managed objects as a
          basis for this memo.  Failure States: The Far End Alarm
          (or Yellow Alarm) is declared after detecting the Yellow
          Signal (or Remote Alarm Indication).  See ANSI T1.107-
          1989 [10].

          Also, The incoming failure states consist of the
          following incoming signal defects:  Loss of Signal (LOS),
          a Loss of Frame (LOF)  (a persistent Out of Frame
          defect), or an Alarm Indication Signal (AIS), for at
          least 2-10 seconds.  The Failures are cleared at the
          onset of 10 consecutive seconds with no SES or no
          detected far end alarms for 2-10 seconds.

     Out of Frame (OOF) defect
          An OOF defect is the occurrence of a particular density
          of FEs.  An Out of Frame defect is declared when the
          receiver detects two or more framing-bit errors within a
          3 msec period for ESF signals and 0.75 msec for SF
          signals, or two or more errors out of five or less





     F. Baker (editor)    Expires Nov 30 1992              [Page 9]





     Internet Draft             DS1 MIB                   June 1992


          consecutive framing-bits.  At this time, the framer
          enters the Out of Frame State, and starts searching for a
          correct framing pattern.  The Out of Frame defect ends
          when reframe occurs and there is less than two frame bit
          errors within 3 msec period for ESF signals and 0.75 msec
          for SF signals.

     Loss of Signal (LOS)
          This defect is declared upon observing 175 +/- 75
          contiguous pulse positions with no pulses of either
          positive or negative polarity.  The LOS is terminated
          upon observing an average pulse density of at least 12.5%
          over a period of 175 +/- 75 contiguous pulse positions
          starting with the receipt of a pulse.

     Alarm Indication Signal (AIS)
          An AIS is detected at a DS1 line interface upon observing
          an unframed signal with a one's density of at least 99.9%
          present for a time equal to or greater than T, where 3 ms
          <= T <= 75 ms.  The AIS is terminated upon observing a
          signal not meeting the one's density or the unframed
          signal criteria for a period equal to or greater than
          than T.

     Circuit Identifier
          This is a character string specified by the circuit
          vendor, and is useful when communicating with the vendor
          during the troubleshooting process.






















     F. Baker (editor)    Expires Nov 30 1992             [Page 10]





     Internet Draft             DS1 MIB                   June 1992


     6.  Definitions

     RFCxxxx-MIB DEFINITIONS ::= BEGIN

     IMPORTS
             Counter, Gauge
                     FROM RFC1155-SMI
             transmission, DisplayString
                     FROM RFC1213-MIB
             OBJECT-TYPE
                     FROM RFC-1212;

     --  This MIB module uses the extended OBJECT-TYPE macro as
     --  defined in RFC 1212.

     --  this is the MIB module for the DS1 objects

     ds1 OBJECT IDENTIFIER ::= { transmission 18 }
































     F. Baker (editor)    Expires Nov 30 1992             [Page 11]





     Internet Draft             DS1 MIB                   June 1992


     -- The DS1 Near End Group

     -- Implementation of this group is mandatory for all systems
     -- that attach to a DS1 Interface.

     -- The DS1 Near End Group consists of four tables:
     --    DS1 Configuration
     --    DS1 Current
     --    DS1 Gauge Interval
     --    DS1 Gauge Total

     -- the DS1 Configuration Table

     -- Although the objects in this table are read-only, at the
     -- agent's discretion they may be made read-write so that the
     -- management station, when appropriately authorized, may
     -- change the behavior of the interface, e.g., to place the interface
     -- into a loopback state.


         ds1ConfigTable OBJECT-TYPE
             SYNTAX  SEQUENCE OF DS1ConfigEntry
             ACCESS  not-accessible
             STATUS  mandatory
             DESCRIPTION
                "The DS1 Configuration table."
            ::= { ds1 1 }



         ds1ConfigEntry OBJECT-TYPE
             SYNTAX  DS1ConfigEntry
             ACCESS  not-accessible
             STATUS  mandatory
             DESCRIPTION
                "An entry in the DS1 Configuration table."
            INDEX   { ds1LineIndex }
            ::= { ds1ConfigTable 1 }


     DS1ConfigEntry ::=
         SEQUENCE {
             ds1LineIndex
                 INTEGER,
             ds1IfIndex





     F. Baker (editor)    Expires Nov 30 1992             [Page 12]





     Internet Draft             DS1 MIB                   June 1992


                 INTEGER,
             ds1TimeElapsed
                 INTEGER,
             ds1ValidIntervals
                 INTEGER,
             ds1LineType
                 INTEGER,
             ds1ZeroCoding
                 INTEGER,
             ds1Loopback
                 INTEGER,
             ds1SendCode
                 INTEGER,
             ds1YellowAlarm
                 INTEGER,
             ds1RedAlarm
                 INTEGER,
             ds1CircuitIdentifier
                 DisplayString,
             ds1LoopbackConfig
                 INTEGER,
             ds1LineStatus
                 INTEGER
         }


         ds1LineIndex OBJECT-TYPE
             SYNTAX  INTEGER
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "This object is the identifier of a DS1  Inter-
                face on a managed device.  If there is an ifEn-
                try that is directly associated with  this  and
                only  this  DS1  interface,  it should have the
                same value as ifIndex.   Otherwise,  the  value
                exceeds  ifNumber,  and  is a unique identifier
                following this rule: inside  interfaces  (e.g.,
                equipment  side)  with even numbers and outside
                interfaces  (e.g,  network   side)   with   odd
                numbers."
            ::= { ds1ConfigEntry 1 }








     F. Baker (editor)    Expires Nov 30 1992             [Page 13]





     Internet Draft             DS1 MIB                   June 1992


         ds1IfIndex OBJECT-TYPE
             SYNTAX  INTEGER
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "This value for this object  is  equal  to  the
                value  of  ifIndex from the Interfaces table of
                MIB II (RFC 1213)."
            ::= { ds1ConfigEntry 2 }



         ds1TimeElapsed OBJECT-TYPE
             SYNTAX  INTEGER (1..900)
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The  number  of  seconds,  including   partial
                seconds,  that have elapsed since the beginning
                of the current error-measurement period."
            ::= { ds1ConfigEntry 3 }



         ds1ValidIntervals OBJECT-TYPE
             SYNTAX  INTEGER (0..96)
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The number of  previous  intervals  for  which
                valid data was collected.  The value will be 96
                unless the interface was brought online  within
                the last 24 hours, in which case the value will
                be the number of complete 15  minute  intervals
                the interface has been online."
            ::= { ds1ConfigEntry 4 }














     F. Baker (editor)    Expires Nov 30 1992             [Page 14]





     Internet Draft             DS1 MIB                   June 1992


         ds1LineType OBJECT-TYPE
             SYNTAX  INTEGER {
                         other(1),
                         ds1ESF(2),
                         ds1D4(3),
                         ds1ANSI-ESF(4),
                         ds1G704(5),
                         ds1G704-CRC(6)
                     }
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "This variable indicates  the  variety  of  DS1
                Line  implementing  this  circuit.  The type of
                circuit affects the number of bits  per  second
                that  the circuit can reasonably carry, as well
                as the interpretation of the  usage  and  error
                statistics.

                The  values,  in  sequence,  describe:   TITLE:
                SPECIFICATION:  ds1ESF        AT&T Extended Su-
                perFrame DS1 ds1D4         AT&T D4  format  DS1
                ds1ANSI-ESF    ANSI  Extended SuperFrame format
                ds1G704       CCITT Recommendation G.704  (sec-
                tion  2.1.3.2)  ds1G704-CRC   CCITT Recommenda-
                tion G.704 (section 2.1.3.1)
                       "
                   ::= { ds1ConfigEntry 5 }






















     F. Baker (editor)    Expires Nov 30 1992             [Page 15]





     Internet Draft             DS1 MIB                   June 1992


         ds1ZeroCoding OBJECT-TYPE
             SYNTAX  INTEGER {
                         ds1JammedBit(1),
                         ds1B8ZS(2),
                         ds1InvertedHDLC(3),
                         ds1HDB3(4),
                         ds1ZBTSI(5),
                         ds1NoZeroEncoding (6)
                     }
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "This variable describes the  variety  of  Zero
                Code  Suppression  used  on  the link, which in
                turn affects a number of its characteristics.

                ds1JammedBit refers the Jammed bit Zero  Encod-
                ing,  in  which  the  AT&T  specification of at
                least one pulse every 8 bit periods is literal-
                ly  implemented  by forcing a pulse in bit 8 of
                each channel.  Thus, only seven bits per  chan-
                nel, or 1.344 Mbps, is available for data.

                ds1B8ZS refers to the use of a  specified  pat-
                tern  of  normal  bits  and  bipolar violations
                which are used to replace a sequence  of  eight
                zero  bits.  In this context, all eight bits in
                a channel are technically available  for  data,
                but  care must be taken with D4 encoded data to
                avoid having HDLC Flag streams imitate spurious
                Yellow  Alarm  conditions.   Typically, one bit
                per frame is ignored to force flag  streams  to
                rotate,   thereby  avoiding  this  error  type.
                CCITT Recommendation G.703 may be  referred  to
                for further definition of these.

                ds1InvertedHDLC refers to the practice,  common
                on  HDLC  encoded  DS1 data links, of inverting
                the data between the serial interface chip  and
                the  CSU.  Since HDLC guarantees one zero every
                6 bits in the worst case, while  the  standards
                call  for  (in effect) at least one pulse every
                eight, inverted HDLC enjoys 4/24 one's  density
                on  the  line,  which may improve the effective
                clock stability of a DS1 line.  As  with  B8ZS,





     F. Baker (editor)    Expires Nov 30 1992             [Page 16]





     Internet Draft             DS1 MIB                   June 1992


                all  eight  bits  in  a channel are technically
                available for data, but care must be taken with
                D4  encoded  data  to  avoid  having  HDLC Flag
                streams imitate spurious  Yellow  Alarm  condi-
                tions.  Typically, one bit per frame is ignored
                to force flag streams to rotate, thereby avoid-
                ing this error type.

                ANSI Clear Channels may use ds1ZBTSI,  or  Zero
                Byte Time Slot Interchange.

                G.704 links, with or without CRC,  use  ds1HDB3
                or ds1NoZeroEncoding."
            ::= { ds1ConfigEntry 6 }




































     F. Baker (editor)    Expires Nov 30 1992             [Page 17]





     Internet Draft             DS1 MIB                   June 1992


         ds1Loopback OBJECT-TYPE
             SYNTAX  INTEGER {
                         ds1NoLoop(1),
                         ds1LocalLoopbackLocalSide(2),
                         ds1LocalLoopbackRemoteSide(3),
                         ds1RemoteLoopbackLocalSide(4),
                         ds1RemoteLoopbackRemoteSide(5)
                     }
             ACCESS  read-only
             STATUS  deprecated
             DESCRIPTION
                "This variable represents the loopback state of
                the  device.   Agents supporting read/write ac-
                cess should return badValue in  response  to  a
                requested  loopback  state that the device does
                not support.  The values mean:

                ds1NoLoop
                     Not in the loopback state.  A device  that
                     is not capable of performing a loopback on
                     either interface shall always return  this
                     as it's value.

                ds1LocalLoopbackLocalSide
                     Signal received from the local side of the
                     device is looped back at the local connec-
                     tor (eg, without involving the device).

                ds1LocalLoopbackRemoteSide
                     Signal received from the local side of the
                     device  is  looped back at the remote con-
                     nector (eg, through the device).

                ds1RemoteLoopbackLocalSide
                     Signal received from the  remote  side  of
                     the  device  is  looped  back at the local
                     connector (eg, through the device).

                ds1RemoteLoopbackRemoteSide
                     Signal received from the  remote  side  of
                     the  device  is  looped back at the remote
                     connector (eg, without involving the  dev-
                     ice)."
            ::= { ds1ConfigEntry 7 }






     F. Baker (editor)    Expires Nov 30 1992             [Page 18]





     Internet Draft             DS1 MIB                   June 1992


         ds1SendCode OBJECT-TYPE
             SYNTAX  INTEGER {
                         ds1SendTestMessage(1),
                         ds1SendNoCode(2),
                         ds1SendSetCode(3),
                         ds1SendLoopbackCode(4),
                         ds1SendResetCode(5)
                     }
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "This variable indicates what type of  code  is
                being sent across the DS1 interface by the dev-
                ice.  The values mean:

                ds1SendNoCode
                         sending looped or normal data

                ds1SendSetCode
                         sending a loopback request

                ds1SendLoopbackCode
                         sending a loopback test code/pattern

                ds1SendResetCode
                         sending a loopback termination request

                ds1SendTestMessage
                         sending a Test pattern as  defined  in
                     T1.107a-1990."
            ::= { ds1ConfigEntry 8 }



















     F. Baker (editor)    Expires Nov 30 1992             [Page 19]





     Internet Draft             DS1 MIB                   June 1992


         ds1YellowAlarm OBJECT-TYPE
             SYNTAX  INTEGER {
                         ds1YellowAlarm(1),
                         ds1NoYellowAlarm(2)
                     }
             ACCESS  read-only
             STATUS  deprecated
             DESCRIPTION
                "This variable indicates if a Yellow Alarm con-
                dition exists."
            ::= { ds1ConfigEntry 9 }



         ds1RedAlarm OBJECT-TYPE
             SYNTAX  INTEGER {
                         ds1RedAlarm(1),
                         ds1NoRedAlarm(2)
                     }
             ACCESS  read-only
             STATUS  deprecated
             DESCRIPTION
                "This variable indicates if a Red Alarm  condi-
                tion exists."
            ::= { ds1ConfigEntry 10 }



         ds1CircuitIdentifier OBJECT-TYPE
             SYNTAX  DisplayString (SIZE (0..255))
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "This  variable   contains   the   transmission
                vendor's circuit identifier, for the purpose of
                facilitating troubleshooting."
            ::= { ds1ConfigEntry 11 }













     F. Baker (editor)    Expires Nov 30 1992             [Page 20]





     Internet Draft             DS1 MIB                   June 1992


         ds1LoopbackConfig OBJECT-TYPE
             SYNTAX  INTEGER {
                         ds1NoLoop(1),
                         ds1MgrPayloadLoop(2),
                         ds1MgrLineLoop(3),
                         ds1NetReqPayloadLoop(4),
                         ds1NetReqLineLoop(5),
                         ds1OtherLoop(6)
                     }
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "This variable represents the  loopback  confi-
                guration of the DS1 interface.  Agents support-
                ing read/write access should return badValue in
                response to a requested loopback state that the
                interface does not support.  The values mean:

                ds1NoLoop
                     Not in the loopback state.  A device  that
                     is not capable of performing a loopback on
                     the interface shall always return this  as
                     it's value.

                ds1MgrPayloadLoop
                     The received signal at this  interface  is
                     looped  through  the device; this loopback
                     is initiated by a manager of  the  device.
                     Typically  the  received  signal is looped
                     back  for  retransmission  after  it   has
                     passed  through the device's framing func-
                     tion.

                ds1MgrLineLoop
                     The received signal at this interface does
                     not  go  through the device (minimum pene-
                     tration) but  is  looped  back  out;  this
                     loopback  is initiated by a manager of the
                     device.

                ds1NetReqPayloadLoop
                     The received signal at this  interface  is
                     looped  through  the device; this loopback
                     is  initiated/requested  by  the  far  end
                     equipment.  Typically  the received signal





     F. Baker (editor)    Expires Nov 30 1992             [Page 21]





     Internet Draft             DS1 MIB                   June 1992


                     is looped back for retransmission after it
                     has  passed  through  the device's framing
                     function.

                ds1NetReqLineLoop
                     The received signal at this interface does
                     not  go  through the device (minimum pene-
                     tration) but  is  looped  back  out;  this
                     loopback is initiated/requested by the far
                     end equipment.

                ds1OtherLoop
                     Loopbacks that are not defined here."
            ::= { ds1ConfigEntry 12 }




































     F. Baker (editor)    Expires Nov 30 1992             [Page 22]





     Internet Draft             DS1 MIB                   June 1992


         ds1LineStatus OBJECT-TYPE
             SYNTAX  INTEGER
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "This variable indicates the Line Status of the
                interface.  It contains loopback state informa-
                tion and  failure  (alarm)  state  information.
                The ds1LineStatus is a bit map represented as a
                sum,  therefore,  it  can  represent   multiple
                failures  (alarms)  and  a LoopbackState simul-
                taneously.

                ds1NoAlarm should be set if and only if no oth-
                er flag is set.

                The various bit positions are:
                       1     ds1NoAlarm
                       2     ds1FarEndAlarm
                       4     ds1AlarmIndicationSignal
                       8     ds1LossOfFrame
                      16     ds1LossOfSignal
                      32     ds1LoopbackState
                      64     ds1T16AlarmIndicationSignal
                     128     ds1LossOfMultiFrame
                     256     ds1DistantLossOfMultiFrame
                     512     ds1DistantLossOfSignal"
            ::= { ds1ConfigEntry 13 }






















     F. Baker (editor)    Expires Nov 30 1992             [Page 23]





     Internet Draft             DS1 MIB                   June 1992


     -- the DS1 Interval

     -- The DS1 Interval Table contains various statistics
     -- collected by each DS1 Interface over the previous 24 hours of
     -- operation.  The past 24 hours are broken into 96 completed
     -- 15 minute intervals.

     -- This table has been deprecated and replaced by ds1GgIntervalTable.


         ds1IntervalTable OBJECT-TYPE
             SYNTAX  SEQUENCE OF DS1IntervalEntry
             ACCESS  not-accessible
             STATUS  deprecated
             DESCRIPTION
                "The DS1 Interval table."
            ::= { ds1 2 }



         ds1IntervalEntry OBJECT-TYPE
             SYNTAX  DS1IntervalEntry
             ACCESS  not-accessible
             STATUS  deprecated
             DESCRIPTION
                "An entry in the DS1 Interval table."
            INDEX   { ds1IntervalIndex, ds1IntervalNumber }
            ::= { ds1IntervalTable 1 }


     DS1IntervalEntry ::=
         SEQUENCE {
             ds1IntervalIndex
                 INTEGER,
             ds1IntervalNumber
                 INTEGER,
             ds1IntervalESs
                 Counter,
             ds1IntervalSESs
                 Counter,
             ds1IntervalSEFSs
                 Counter,
             ds1IntervalUASs
                 Counter,
             ds1IntervalCSSs





     F. Baker (editor)    Expires Nov 30 1992             [Page 24]





     Internet Draft             DS1 MIB                   June 1992


                 Counter,
             ds1IntervalBPVs
                 Counter,
             ds1IntervalCVs
                 Counter
         }


         ds1IntervalIndex OBJECT-TYPE
             SYNTAX  INTEGER (1..65535)
             ACCESS  read-only
             STATUS  deprecated
             DESCRIPTION
                "The index value which uniquely identifies  the
                ds1  interface  to which this entry is applica-
                ble.  The interface identified by a  particular
                value  of  this  index is the same interface as
                identified by the same  value  an  ds1LineIndex
                object instance."
            ::= { ds1IntervalEntry 1 }



         ds1IntervalNumber OBJECT-TYPE
             SYNTAX  INTEGER (1..96)
             ACCESS  read-only
             STATUS  deprecated
             DESCRIPTION
                "A number between 1 and 96, where 1 is the most
                recently completed 15 minute interval and 96 is
                the least recently completed 15 minutes  inter-
                val   (assuming   that  all  96  intervals  are
                valid)."
            ::= { ds1IntervalEntry 2 }
















     F. Baker (editor)    Expires Nov 30 1992             [Page 25]





     Internet Draft             DS1 MIB                   June 1992


         ds1IntervalESs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  deprecated
             DESCRIPTION
                "The counter associated with the number of  Er-
                rored  Seconds,  encountered by a DS1 interface
                in  one  of  the  previous  96,  individual  15
                minute, intervals."
            ::= { ds1IntervalEntry 3 }



         ds1IntervalSESs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  deprecated
             DESCRIPTION
                "The counter  associated  with  the  number  of
                Severely  Errored Seconds, encountered by a ds1
                interface in one of the previous 96, individual
                15 minute, intervals."
            ::= { ds1IntervalEntry 4 }



         ds1IntervalSEFSs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  deprecated
             DESCRIPTION
                "The counter  associated  with  the  number  of
                Severely  Errored  Framing Seconds, encountered
                by a DS1 interface in one of the  previous  96,
                individual 15 minute, intervals."
            ::= { ds1IntervalEntry 5 }














     F. Baker (editor)    Expires Nov 30 1992             [Page 26]





     Internet Draft             DS1 MIB                   June 1992


         ds1IntervalUASs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  deprecated
             DESCRIPTION
                "The counter associated with the number of Una-
                vailable  Seconds,  encountered by a ds1 inter-
                face in one of the previous 96,  individual  15
                minute, intervals."
            ::= { ds1IntervalEntry 6 }



         ds1IntervalCSSs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  deprecated
             DESCRIPTION
                "The counter associated with the number of Con-
                trolled  Slip Seconds, encountered by a ds1 in-
                terface in one of the previous  96,  individual
                15 minute, intervals."
            ::= { ds1IntervalEntry 7 }



         ds1IntervalBPVs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  deprecated
             DESCRIPTION
                "The counter associated with the number of  Bi-
                polar  Violations,  encountered by a DS1 inter-
                face in one

                of the previous 96, individual 15  minute,  in-
                tervals."
            ::= { ds1IntervalEntry 8 }












     F. Baker (editor)    Expires Nov 30 1992             [Page 27]





     Internet Draft             DS1 MIB                   June 1992


         ds1IntervalCVs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  deprecated
             DESCRIPTION
                "The counter associated with the number of Cod-
                ing  Violations, encountered by a DS1 interface
                in  one  of  the  previous  96,  individual  15
                minute, intervals."
            ::= { ds1IntervalEntry 9 }








































     F. Baker (editor)    Expires Nov 30 1992             [Page 28]





     Internet Draft             DS1 MIB                   June 1992


     -- the DS1 Current

     -- The DS1 current table contains various statistics being
     -- collected for the current 15 minute interval.


         ds1CurrentTable OBJECT-TYPE
             SYNTAX  SEQUENCE OF DS1CurrentEntry
             ACCESS  not-accessible
             STATUS  mandatory
             DESCRIPTION
                "The DS1 Current table."
            ::= { ds1 3 }



         ds1CurrentEntry OBJECT-TYPE
             SYNTAX  DS1CurrentEntry
             ACCESS  not-accessible
             STATUS  mandatory
             DESCRIPTION
                "An entry in the DS1 Current table."
            INDEX   { ds1CurrentIndex }
            ::= { ds1CurrentTable 1 }


     DS1CurrentEntry ::=
         SEQUENCE {
             ds1CurrentIndex
                 INTEGER,
             ds1CurrentESs
                 Counter,
             ds1CurrentSESs
                 Counter,
             ds1CurrentSEFSs
                 Counter,
             ds1CurrentUASs
                 Counter,
             ds1CurrentCSSs
                 Counter,
             ds1CurrentBPVs
                 Counter,
             ds1CurrentCVs
                 Counter
         }





     F. Baker (editor)    Expires Nov 30 1992             [Page 29]





     Internet Draft             DS1 MIB                   June 1992


         ds1CurrentIndex OBJECT-TYPE
             SYNTAX  INTEGER (1..65535)
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The index value which uniquely identifies  the
                ds1  interface  to which this entry is applica-
                ble.  The interface identified by a  particular
                value  of  this  index is the same interface as
                identified by the same  value  an  ds1LineIndex
                object instance."
            ::= { ds1CurrentEntry 1 }



         ds1CurrentESs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter associated with the number of  Er-
                rored  Seconds,  encountered by a DS1 interface
                in the current 15 minute interval."
            ::= { ds1CurrentEntry 2 }



         ds1CurrentSESs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter  associated  with  the  number  of
                Severely  Errored Seconds, encountered by a ds1
                interface in the current 15 minute interval."
            ::= { ds1CurrentEntry 3 }














     F. Baker (editor)    Expires Nov 30 1992             [Page 30]





     Internet Draft             DS1 MIB                   June 1992


         ds1CurrentSEFSs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter  associated  with  the  number  of
                Severely  Errored  Framing Seconds, encountered
                by a DS1 interface in the current 15 minute in-
                terval."
            ::= { ds1CurrentEntry 4 }



         ds1CurrentUASs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter associated with the number of Una-
                vailable Seconds encountered by a ds1 interface
                in the current 15 minute interval."
            ::= { ds1CurrentEntry 5 }



         ds1CurrentCSSs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter associated with the number of Con-
                trolled  Slip Seconds, encountered by a ds1 in-
                terface in the current 15 minute interval."
            ::= { ds1CurrentEntry 6 }
















     F. Baker (editor)    Expires Nov 30 1992             [Page 31]





     Internet Draft             DS1 MIB                   June 1992


         ds1CurrentBPVs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter associated with the number of  Bi-
                polar  Violations,  encountered by a DS1 inter-
                face in the current 15 minute interval."
            ::= { ds1CurrentEntry 7 }



         ds1CurrentCVs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter associated with the number of Cod-
                ing  Violations, encountered by a DS1 interface
                in the current 15 minute interval."
            ::= { ds1CurrentEntry 8 }





























     F. Baker (editor)    Expires Nov 30 1992             [Page 32]





     Internet Draft             DS1 MIB                   June 1992


     -- the DS1 Total

     -- The DS1 Total Table contains the cumulative sum of the
     -- various statistics for the 24 hour interval preceding the
     -- first valid interval in the ds1CurrentTable.
     -- This table has been deprecated and replaced by ds1GgTotalTable.


         ds1TotalTable OBJECT-TYPE
             SYNTAX  SEQUENCE OF DS1TotalEntry
             ACCESS  not-accessible
             STATUS  deprecated
             DESCRIPTION
                "The DS1 Total table.  24 hour interval."
            ::= { ds1 4 }



         ds1TotalEntry OBJECT-TYPE
             SYNTAX  DS1TotalEntry
             ACCESS  not-accessible
             STATUS  deprecated
             DESCRIPTION
                "An entry in the DS1 Total table."
            INDEX   { ds1TotalIndex }
            ::= { ds1TotalTable 1 }


     DS1TotalEntry ::=
         SEQUENCE {
             ds1TotalIndex
                 INTEGER,
             ds1TotalESs
                 Counter,
             ds1TotalSESs
                 Counter,
             ds1TotalSEFSs
                 Counter,
             ds1TotalUASs
                 Counter,
             ds1TotalCSSs
                 Counter,
             ds1TotalBPVs
                 Counter,
             ds1TotalCVs





     F. Baker (editor)    Expires Nov 30 1992             [Page 33]





     Internet Draft             DS1 MIB                   June 1992


                 Counter
         }


         ds1TotalIndex OBJECT-TYPE

             SYNTAX  INTEGER (1..65535)
             ACCESS  read-only
             STATUS  deprecated
             DESCRIPTION
                "The index value which uniquely identifies  the
                ds1  interface  to which this entry is applica-
                ble.  The interface identified by a  particular
                value  of  this  index is the same interface as
                identified by the same  value  an  ds1LineIndex
                object instance."
            ::= { ds1TotalEntry 1 }



         ds1TotalESs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  deprecated
             DESCRIPTION
                "The counter associated with the number of  Er-
                rored  Seconds,  encountered by a DS1 interface
                in the previous 24 hour interval"
            ::= { ds1TotalEntry 2 }



         ds1TotalSESs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  deprecated
             DESCRIPTION
                "The counter  associated  with  the  number  of
                Severely  Errored Seconds, encountered by a ds1
                interface in the previous 24 hour interval."
            ::= { ds1TotalEntry 3 }









     F. Baker (editor)    Expires Nov 30 1992             [Page 34]





     Internet Draft             DS1 MIB                   June 1992


         ds1TotalSEFSs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  deprecated
             DESCRIPTION
                "The counter  associated  with  the  number  of
                Severely  Errored  Framing Seconds, encountered
                by a DS1 interface in the previous 24 hour  in-
                terval."
            ::= { ds1TotalEntry 4 }



         ds1TotalUASs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  deprecated

             DESCRIPTION
                "The counter associated with the number of Una-
                vailable  Seconds,  encountered by a ds1 inter-
                face in the previous 24 hour interval."
            ::= { ds1TotalEntry 5 }



         ds1TotalCSSs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  deprecated
             DESCRIPTION
                "The counter associated with the number of Con-
                trolled  Slip Seconds, encountered by a ds1 in-
                terface in the previous 24 hour interval."
            ::= { ds1TotalEntry 6 }















     F. Baker (editor)    Expires Nov 30 1992             [Page 35]





     Internet Draft             DS1 MIB                   June 1992


         ds1TotalBPVs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  deprecated
             DESCRIPTION
                "The counter associated with the number of  Bi-
                polar  Violations,  encountered by a DS1 inter-
                face in the previous 24 hour interval."
            ::= { ds1TotalEntry 7 }



         ds1TotalCVs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  deprecated
             DESCRIPTION
                "The counter associated with the number of Cod-
                ing  Violations, encountered by a DS1 interface
                in the previous 24 hour interval."
            ::= { ds1TotalEntry 8 }





























     F. Baker (editor)    Expires Nov 30 1992             [Page 36]





     Internet Draft             DS1 MIB                   June 1992


     -- the DS1 Gauge Interval

     -- The DS1 Gauge Interval Table contains various statistics
     -- collected by each DS1 Interface over the previous 24 hours of
     -- operation.  The past 24 hours are broken into 96 completed
     -- 15 minute intervals.


         ds1GgIntervalTable OBJECT-TYPE
             SYNTAX  SEQUENCE OF DS1GgIntervalEntry
             ACCESS  not-accessible
             STATUS  mandatory
             DESCRIPTION
                "The DS1 Gauge Interval table."
            ::= { ds1 6 }



         ds1GgIntervalEntry OBJECT-TYPE
             SYNTAX  DS1GgIntervalEntry
             ACCESS  not-accessible
             STATUS  mandatory
             DESCRIPTION
                "An entry in the DS1 Gauge Interval table."
            INDEX   { ds1GgIntervalIndex, ds1GgIntervalNumber }
            ::= { ds1GgIntervalTable 1 }


     DS1GgIntervalEntry ::=
         SEQUENCE {
             ds1GgIntervalIndex
                 INTEGER,
             ds1GgIntervalNumber
                 INTEGER,
             ds1GgIntervalESs
                 Gauge,
             ds1GgIntervalSESs
                 Gauge,
             ds1GgIntervalSEFSs
                 Gauge,
             ds1GgIntervalUASs
                 Gauge,
             ds1GgIntervalCSSs
                 Gauge,
             ds1GgIntervalBPVs





     F. Baker (editor)    Expires Nov 30 1992             [Page 37]





     Internet Draft             DS1 MIB                   June 1992


                 Gauge,
             ds1GgIntervalCVs
                 Gauge
         }


         ds1GgIntervalIndex OBJECT-TYPE
             SYNTAX  INTEGER (1..65535)
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The index value which uniquely identifies  the
                ds1  interface  to which this entry is applica-
                ble.  The interface identified by a  particular
                value  of  this  index is the same interface as
                identified by the same  value  an  ds1LineIndex
                object instance."
            ::= { ds1GgIntervalEntry 1 }



         ds1GgIntervalNumber OBJECT-TYPE
             SYNTAX  INTEGER (1..96)
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "A number between 1 and 96, where 1 is the most
                recently completed 15 minute interval and 96 is
                the least recently completed 15 minutes  inter-
                val   (assuming   that  all  96  intervals  are
                valid)."
            ::= { ds1GgIntervalEntry 2 }


















     F. Baker (editor)    Expires Nov 30 1992             [Page 38]





     Internet Draft             DS1 MIB                   June 1992


         ds1GgIntervalESs OBJECT-TYPE
             SYNTAX  Gauge
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter associated with the number of  Er-
                rored  Seconds,  encountered by a DS1 interface
                in  one  of  the  previous  96,  individual  15
                minute, intervals."
            ::= { ds1GgIntervalEntry 3 }



         ds1GgIntervalSESs OBJECT-TYPE
             SYNTAX  Gauge
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter  associated  with  the  number  of
                Severely  Errored Seconds, encountered by a ds1
                interface in one of the previous 96, individual
                15 minute, intervals."
            ::= { ds1GgIntervalEntry 4 }



         ds1GgIntervalSEFSs OBJECT-TYPE

             SYNTAX  Gauge
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter  associated  with  the  number  of
                Severely  Errored  Framing Seconds, encountered
                by a DS1 interface in one of the  previous  96,
                individual 15 minute, intervals."
            ::= { ds1GgIntervalEntry 5 }













     F. Baker (editor)    Expires Nov 30 1992             [Page 39]





     Internet Draft             DS1 MIB                   June 1992


         ds1GgIntervalUASs OBJECT-TYPE
             SYNTAX  Gauge
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter associated with the number of Una-
                vailable  Seconds,  encountered by a ds1 inter-
                face in one of the previous 96,  individual  15
                minute, intervals."
            ::= { ds1GgIntervalEntry 6 }



         ds1GgIntervalCSSs OBJECT-TYPE
             SYNTAX  Gauge
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter associated with the number of Con-
                trolled  Slip Seconds, encountered by a ds1 in-
                terface in one of the previous  96,  individual
                15 minute, intervals."
            ::= { ds1GgIntervalEntry 7 }



         ds1GgIntervalBPVs OBJECT-TYPE
             SYNTAX  Gauge
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter associated with the number of  Bi-
                polar  Violations,  encountered by a DS1 inter-
                face in one of the previous 96,  individual  15
                minute, intervals."
            ::= { ds1GgIntervalEntry 8 }














     F. Baker (editor)    Expires Nov 30 1992             [Page 40]





     Internet Draft             DS1 MIB                   June 1992


         ds1GgIntervalCVs OBJECT-TYPE
             SYNTAX  Gauge
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter associated with the number of Cod-
                ing  Violations, encountered by a DS1 interface
                in  one  of  the  previous  96,  individual  15
                minute, intervals."
            ::= { ds1GgIntervalEntry 9 }








































     F. Baker (editor)    Expires Nov 30 1992             [Page 41]





     Internet Draft             DS1 MIB                   June 1992


     -- the DS1 Gauge Total

     -- The DS1 Gauge Total Table contains the cumulative sum of the
     -- various statistics for the 24 hour interval preceding the
     -- first valid interval in the ds1CurrentTable.


         ds1GgTotalTable OBJECT-TYPE
             SYNTAX  SEQUENCE OF DS1GgTotalEntry
             ACCESS  not-accessible
             STATUS  mandatory
             DESCRIPTION
                "The DS1 Gauge Total table.  24 hour interval."
            ::= { ds1 7 }



         ds1GgTotalEntry OBJECT-TYPE
             SYNTAX  DS1GgTotalEntry
             ACCESS  not-accessible
             STATUS  mandatory
             DESCRIPTION
                "An entry in the DS1 Gauge Total table."
            INDEX   { ds1GgTotalIndex }
            ::= { ds1GgTotalTable 1 }


     DS1GgTotalEntry ::=
         SEQUENCE {
             ds1GgTotalIndex
                 INTEGER,
             ds1GgTotalESs
                 Gauge,
             ds1GgTotalSESs
                 Gauge,
             ds1GgTotalSEFSs
                 Gauge,
             ds1GgTotalUASs
                 Gauge,
             ds1GgTotalCSSs
                 Gauge,
             ds1GgTotalBPVs
                 Gauge,
             ds1GgTotalCVs
                 Gauge





     F. Baker (editor)    Expires Nov 30 1992             [Page 42]





     Internet Draft             DS1 MIB                   June 1992


         }


         ds1GgTotalIndex OBJECT-TYPE
             SYNTAX  INTEGER (1..65535)
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The index value which uniquely identifies  the
                ds1  interface  to which this entry is applica-
                ble.  The interface identified by a  particular
                value  of  this  index is the same interface as
                identified by the same  value  an  ds1LineIndex
                object instance."
            ::= { ds1GgTotalEntry 1 }



         ds1GgTotalESs OBJECT-TYPE
             SYNTAX  Gauge
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter associated with the number of  Er-
                rored  Seconds,  encountered by a DS1 interface
                in the previous 24 hour interval"
            ::= { ds1GgTotalEntry 2 }



         ds1GgTotalSESs OBJECT-TYPE
             SYNTAX  Gauge
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter  associated  with  the  number  of
                Severely  Errored Seconds, encountered by a ds1
                interface in the previous 24 hour interval."
            ::= { ds1GgTotalEntry 3 }











     F. Baker (editor)    Expires Nov 30 1992             [Page 43]





     Internet Draft             DS1 MIB                   June 1992


         ds1GgTotalSEFSs OBJECT-TYPE
             SYNTAX  Gauge
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter  associated  with  the  number  of
                Severely  Errored  Framing Seconds, encountered
                by a DS1 interface in the previous 24 hour  in-
                terval."
            ::= { ds1GgTotalEntry 4 }



         ds1GgTotalUASs OBJECT-TYPE
             SYNTAX  Gauge
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION

                "The counter associated with the number of Una-
                vailable  Seconds,  encountered by a ds1 inter-
                face in the previous 24 hour interval."
            ::= { ds1GgTotalEntry 5 }



         ds1GgTotalCSSs OBJECT-TYPE
             SYNTAX  Gauge
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter associated with the number of Con-
                trolled  Slip Seconds, encountered by a ds1 in-
                terface in the previous 24 hour interval."
            ::= { ds1GgTotalEntry 6 }















     F. Baker (editor)    Expires Nov 30 1992             [Page 44]





     Internet Draft             DS1 MIB                   June 1992


         ds1GgTotalBPVs OBJECT-TYPE
             SYNTAX  Gauge
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter associated with the number of  Bi-
                polar  Violations,  encountered by a DS1 inter-
                face in the previous 24 hour interval."
            ::= { ds1GgTotalEntry 7 }



         ds1GgTotalCVs OBJECT-TYPE
             SYNTAX  Gauge
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter associated with the number of Cod-
                ing  Violations, encountered by a DS1 interface
                in the previous 24 hour interval."
            ::= { ds1GgTotalEntry 8 }





























     F. Baker (editor)    Expires Nov 30 1992             [Page 45]





     Internet Draft             DS1 MIB                   June 1992


     -- The DS1 Far End Group

     -- Implementation of this group is optional for all systems
     -- that attach to a DS1 Interface.

     -- The DS1 Far End Group consists of three tables:
     --   DS1 Far End Current
     --   DS1 Far End Gauge Interval
     --   DS1 Far End Gauge Total

     -- The DS1 Far End Current

     -- The DS1 Far End Current table contains various statistics being
     -- collected for the current 15 minute interval.
     -- The statistics are collected from the far end messages on the
     -- Facilities Data Link.  The definitions are the same as described for
     -- the near-end information.


         ds1FarEndCurrentTable OBJECT-TYPE
             SYNTAX  SEQUENCE OF DS1FarEndCurrentEntry
             ACCESS  not-accessible
             STATUS  mandatory
             DESCRIPTION
                "The DS1 Far End Current table."
            ::= { ds1 8 }



         ds1FarEndCurrentEntry OBJECT-TYPE
             SYNTAX  DS1FarEndCurrentEntry
             ACCESS  not-accessible
             STATUS  mandatory
             DESCRIPTION
                "An entry in the DS1 Far End Current table."
            INDEX   { ds1FarEndCurrentIndex }
            ::= { ds1FarEndCurrentTable 1 }


     DS1FarEndCurrentEntry ::=
         SEQUENCE {
             ds1FarEndCurrentIndex
                 INTEGER,
             ds1FarEndCurrentESs
                 Counter,





     F. Baker (editor)    Expires Nov 30 1992             [Page 46]





     Internet Draft             DS1 MIB                   June 1992


             ds1FarEndCurrentSESs
                 Counter,
             ds1FarEndCurrentSEFSs
                 Counter,
             ds1FarEndCurrentCSSs
                 Counter,
             ds1FarEndCurrentLESs
                 Counter,
             ds1FarEndCurrentCVs
                 Counter
         }


         ds1FarEndCurrentIndex OBJECT-TYPE
             SYNTAX  INTEGER (1..65535)
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The index value which uniquely identifies  the
                DS1  interface  to which this entry is applica-
                ble.  The interface identified by a  particular
                value  of  this  index is the same interface as
                identified by the same  value  an  ds1LineIndex
                object instance."
            ::= { ds1FarEndCurrentEntry 1 }



         ds1FarEndCurrentESs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter associated with the number of  Far
                Far  End  Errored  Seconds encountered by a ds1
                interface in the current 15 minute interval."
            ::= { ds1FarEndCurrentEntry 2 }













     F. Baker (editor)    Expires Nov 30 1992             [Page 47]





     Internet Draft             DS1 MIB                   June 1992


         ds1FarEndCurrentSESs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter associated with the number of  Far
                End  Severely  Errored Seconds encountered by a
                DS1 interface in the current 15  minute  inter-
                val."
            ::= { ds1FarEndCurrentEntry 3 }



         ds1FarEndCurrentSEFSs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter associated with the number of  Far
                End  Severely  Errored Framing Seconds, encoun-
                tered by a DS1  interface  in  the  current  15
                minute interval."
            ::= { ds1FarEndCurrentEntry 4 }



         ds1FarEndCurrentCSSs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter associated with the number of  Far
                End  Controlled  Slip Seconds, encountered by a
                ds1 interface in the current 15  minute  inter-
                val."
            ::= { ds1FarEndCurrentEntry 5 }














     F. Baker (editor)    Expires Nov 30 1992             [Page 48]





     Internet Draft             DS1 MIB                   June 1992


         ds1FarEndCurrentLESs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter associated with the number of  Far
                End  Bipolar  Violations,  encountered by a DS1
                interface in the current 15 minute interval."
            ::= { ds1FarEndCurrentEntry 6 }



         ds1FarEndCurrentCVs OBJECT-TYPE
             SYNTAX  Counter
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter associated with the number of  Far
                End  Coding Violations reported via the far end
                block error count encountered by a  DS1  inter-
                face in the current 15 minute interval."
            ::= { ds1FarEndCurrentEntry 7 }




























     F. Baker (editor)    Expires Nov 30 1992             [Page 49]





     Internet Draft             DS1 MIB                   June 1992


     -- The DS1 Far End Gauge Interval

     -- The DS1 Far End Gauge Interval Table contains various statistics
     -- collected by each DS1 interface over the previous 24 hours of
     -- operation.  The past 24 hours are broken into 96
     -- completed 15 minute intervals.


         ds1FarEndGgIntervalTable OBJECT-TYPE
             SYNTAX  SEQUENCE OF DS1FarEndGgIntervalEntry
             ACCESS  not-accessible
             STATUS  mandatory
             DESCRIPTION
                "The DS1 Far End Gauge Interval table."
            ::= { ds1 9 }



         ds1FarEndGgIntervalEntry OBJECT-TYPE
             SYNTAX  DS1FarEndGgIntervalEntry
             ACCESS  not-accessible
             STATUS  mandatory
             DESCRIPTION
                "An entry in the DS1  Far  End  Gauge  Interval
                table."
            INDEX   { ds1FarEndGgIntervalIndex, ds1FarEndGgIntervalNumber }
            ::= { ds1FarEndGgIntervalTable 1 }


     DS1FarEndGgIntervalEntry ::=
         SEQUENCE {
             ds1FarEndGgIntervalIndex
                 INTEGER,
             ds1FarEndGgIntervalNumber
                 INTEGER,
             ds1FarEndGgIntervalESs
                 Gauge,
             ds1FarEndGgIntervalSESs
                 Gauge,
             ds1FarEndGgIntervalSEFSs
                 Gauge,
             ds1FarEndGgIntervalCSSs
                 Gauge,
             ds1FarEndGgIntervalLESs
                 Gauge,





     F. Baker (editor)    Expires Nov 30 1992             [Page 50]





     Internet Draft             DS1 MIB                   June 1992


             ds1FarEndGgIntervalCVs
                 Gauge
         }


         ds1FarEndGgIntervalIndex OBJECT-TYPE
             SYNTAX  INTEGER (1..65535)
             ACCESS  read-only

             STATUS  mandatory
             DESCRIPTION
                "The index value which uniquely identifies  the
                DS1  interface  to which this entry is applica-
                ble.  The interface identified by a  particular
                value  of  this  index is the same interface as
                identified by the same  value  an  ds1LineIndex
                object instance."
            ::= { ds1FarEndGgIntervalEntry 1 }



         ds1FarEndGgIntervalNumber OBJECT-TYPE
             SYNTAX  INTEGER (1..96)
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "A number between 1 and 96, where 1 is the most
                recently completed 15 minute interval and 96 is
                the least recently completed 15 minutes  inter-
                val   (assuming   that  all  96  intervals  are
                valid)."
            ::= { ds1FarEndGgIntervalEntry 2 }


















     F. Baker (editor)    Expires Nov 30 1992             [Page 51]





     Internet Draft             DS1 MIB                   June 1992


         ds1FarEndGgIntervalESs OBJECT-TYPE
             SYNTAX  Gauge
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter associated with the number of  Far
                End Errored Seconds encountered by a DS1 inter-
                face in one of the previous 96,  individual  15
                minute, intervals."
            ::= { ds1FarEndGgIntervalEntry 3 }



         ds1FarEndGgIntervalSESs OBJECT-TYPE
             SYNTAX  Gauge
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter associated with the number of  Far
                End  Severely  Errored Seconds encountered by a
                DS1 interface in one of the previous 96,  indi-
                vidual 15 minute, intervals."
            ::= { ds1FarEndGgIntervalEntry 4 }



         ds1FarEndGgIntervalSEFSs OBJECT-TYPE
             SYNTAX  Gauge
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter associated with the number of  Far
                End  Severely  Errored Framing Seconds, encoun-
                tered by a DS1 interface in one of the previous
                96, individual 15 minute, intervals."
            ::= { ds1FarEndGgIntervalEntry 5 }














     F. Baker (editor)    Expires Nov 30 1992             [Page 52]





     Internet Draft             DS1 MIB                   June 1992


         ds1FarEndGgIntervalCSSs OBJECT-TYPE
             SYNTAX  Gauge
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter associated with the number of  Far
                End  Controlled  Slip Seconds, encountered by a
                DS1 interface in one of the previous 96,  indi-
                vidual 15 minute, intervals."
            ::= { ds1FarEndGgIntervalEntry 6 }



         ds1FarEndGgIntervalLESs OBJECT-TYPE
             SYNTAX  Gauge
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter associated with the number of  Far
                End  Bipolar  Violations,  encountered by a DS1
                interface in one of the previous 96, individual
                15 minute, intervals."
            ::= { ds1FarEndGgIntervalEntry 7 }



         ds1FarEndGgIntervalCVs OBJECT-TYPE
             SYNTAX  Gauge
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter associated with the number of  Far
                End  Coding Violations reported via the far end
                block error count encountered by a  DS1  inter-
                face  in  one of the previous 96, individual 15
                minute, intervals."
            ::= { ds1FarEndGgIntervalEntry 8 }













     F. Baker (editor)    Expires Nov 30 1992             [Page 53]





     Internet Draft             DS1 MIB                   June 1992


     -- The DS1 Far End Gauge Total

     -- The DS1 Far End Gauge Total Table contains the cumulative sum of the
     -- various statistics for the 24 hour interval preceding the
     -- first valid interval in the ds1FarEndCurrentTable.


         ds1FarEndGgTotalTable OBJECT-TYPE
             SYNTAX  SEQUENCE OF DS1FarEndGgTotalEntry
             ACCESS  not-accessible
             STATUS  mandatory
             DESCRIPTION
                "The DS1 Far End Gauge Total  table.   24  hour
                interval."
            ::= { ds1 10 }



         ds1FarEndGgTotalEntry OBJECT-TYPE
             SYNTAX  DS1FarEndGgTotalEntry
             ACCESS  not-accessible
             STATUS  mandatory
             DESCRIPTION
                "An entry  in  the  DS1  Far  End  Gauge  Total
                table."
            INDEX   { ds1FarEndGgTotalIndex }
            ::= { ds1FarEndGgTotalTable 1 }


     DS1FarEndGgTotalEntry ::=
         SEQUENCE {
             ds1FarEndGgTotalIndex
                 INTEGER,
             ds1FarEndGgTotalESs
                 Gauge,
             ds1FarEndGgTotalSESs
                 Gauge,
             ds1FarEndGgTotalSEFSs
                 Gauge,
             ds1FarEndGgTotalCSSs
                 Gauge,
             ds1FarEndGgTotalLESs
                 Gauge,
             ds1FarEndGgTotalCVs
                 Gauge





     F. Baker (editor)    Expires Nov 30 1992             [Page 54]





     Internet Draft             DS1 MIB                   June 1992


         }


         ds1FarEndGgTotalIndex OBJECT-TYPE
             SYNTAX  INTEGER (1..65535)
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The index value which uniquely identifies  the
                DS1  interface  to which this entry is applica-
                ble.  The interface identified by a  particular
                value  of  this  index is the same interface as
                identified by the same  value  an  ds1LineIndex
                object instance."
            ::= { ds1FarEndGgTotalEntry 1 }



         ds1FarEndGgTotalESs OBJECT-TYPE
             SYNTAX  Gauge
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter associated with the number of  Far
                End Errored Seconds encountered by a ds1 inter-
                face in the previous 24 hour interval."
            ::= { ds1FarEndGgTotalEntry 2 }



         ds1FarEndGgTotalSESs OBJECT-TYPE
             SYNTAX  Gauge
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter associated with the number of  Far
                End  Severely  Errored Seconds encountered by a
                DS1 interface in the previous  24  hour  inter-
                val."
            ::= { ds1FarEndGgTotalEntry 3 }










     F. Baker (editor)    Expires Nov 30 1992             [Page 55]





     Internet Draft             DS1 MIB                   June 1992


         ds1FarEndGgTotalSEFSs OBJECT-TYPE
             SYNTAX  Gauge
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter associated with the number of  Far
                End  Severely  Errored Framing Seconds, encoun-
                tered by a DS1 interface  in  the  previous  24
                hour interval."
            ::= { ds1FarEndGgTotalEntry 4 }



         ds1FarEndGgTotalCSSs OBJECT-TYPE
             SYNTAX  Gauge
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter associated with the number of  Far
                End  Controlled  Slip Seconds, encountered by a
                DS1 interface in the previous  24  hour  inter-
                val."
            ::= { ds1FarEndGgTotalEntry 5 }



         ds1FarEndGgTotalLESs OBJECT-TYPE
             SYNTAX  Gauge
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter associated with the number of  Far
                End  Bipolar  Violations,  encountered by a DS1
                interface in the previous 24 hour interval."
            ::= { ds1FarEndGgTotalEntry 6 }















     F. Baker (editor)    Expires Nov 30 1992             [Page 56]





     Internet Draft             DS1 MIB                   June 1992


         ds1FarEndGgTotalCVs OBJECT-TYPE
             SYNTAX  Gauge
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The counter associated with the number of  Far
                End  Coding Violations reported via the far end
                block error count encountered by a  DS1  inter-
                face in the previous 24 hour interval."
            ::= { ds1FarEndGgTotalEntry 7 }








































     F. Baker (editor)    Expires Nov 30 1992             [Page 57]





     Internet Draft             DS1 MIB                   June 1992


     -- the DS1 Fractional group

     -- Implementation of this group is mandatory for those
     -- systems dividing a DS1 into channels containing different
     -- data streams that are of local interest.  Systems which
     -- are indifferent to data content, such as CSUs, need not
     -- implement it.

     -- The DS1 fractional table contains identifies which DS1
     -- channels associated with a CSU are being used to support a
     -- logical interface, i.e., an entry in the interfaces table
     -- from the Internet-standard MIB.

     -- For example, consider an application managing a North
     -- American ISDN Primary Rate link whose division is a 384 KBPS
     -- H1 "B" Channel for Video, a second H1 for data to a primary
     -- routing peer, and 12 64 KBPS H0 "B" Channels. Consider that
     -- some subset of the H0 channels are used for voice and the
     -- remainder are available for dynamic data calls.

     -- we count a total of 14 interfaces multiplexed onto the DS1
     -- interface. Six DS1 channels (for the sake of the example,
     -- channels 1..6) are used for Video, six more (7..11 and 13)
     -- are used for data, and the remaining 12 are are in channels
     -- 12 and 14..24.

     -- Let us further imagine that ifIndex 2 is of type DS1 and
     -- refers to the DS1 interface, and that the interfaces layered
     -- onto it are numbered 3..16.

     -- We might describe the allocation of channels, in the
     -- ds1FracTable, as follows:

     -- ds1FracIfIndex.2. 1 = 3    ds1FracIfIndex.2.13 = 4
     -- ds1FracIfIndex.2. 2 = 3    ds1FracIfIndex.2.14 = 6
     -- ds1FracIfIndex.2. 3 = 3    ds1FracIfIndex.2.15 = 7
     -- ds1FracIfIndex.2. 4 = 3    ds1FracIfIndex.2.16 = 8
     -- ds1FracIfIndex.2. 5 = 3    ds1FracIfIndex.2.17 = 9
     -- ds1FracIfIndex.2. 6 = 3    ds1FracIfIndex.2.18 = 10
     -- ds1FracIfIndex.2. 7 = 4    ds1FracIfIndex.2.19 = 11
     -- ds1FracIfIndex.2. 8 = 4    ds1FracIfIndex.2.20 = 12
     -- ds1FracIfIndex.2. 9 = 4    ds1FracIfIndex.2.21 = 13
     -- ds1FracIfIndex.2.10 = 4    ds1FracIfIndex.2.22 = 14
     -- ds1FracIfIndex.2.11 = 4    ds1FracIfIndex.2.23 = 15
     -- ds1FracIfIndex.2.12 = 5    ds1FracIfIndex.2.24 = 16





     F. Baker (editor)    Expires Nov 30 1992             [Page 58]





     Internet Draft             DS1 MIB                   June 1992


     --      For ds1ESF, ds1D4, and ds1ANSI-ESF, there are 24 legal
     --      channels, numbered 1 through 24.
     --
     --      For G.704, there are 32 legal channels, numbered 1
     --      through 32.


         ds1FracTable OBJECT-TYPE
             SYNTAX  SEQUENCE OF DS1FracEntry
             ACCESS  not-accessible
             STATUS  mandatory
             DESCRIPTION
                "The DS1 Fractional table."
            ::= { ds1 5 }



         ds1FracEntry OBJECT-TYPE
             SYNTAX  DS1FracEntry
             ACCESS  not-accessible
             STATUS  mandatory
             DESCRIPTION
                "An entry in the DS1 Fractional table."
            INDEX   { ds1FracIndex, ds1FracNumber }
            ::= { ds1FracTable 1 }


     DS1FracEntry ::=
         SEQUENCE {
             ds1FracIndex
                 INTEGER,
             ds1FracNumber
                 INTEGER (1..32),
             ds1FracIfIndex
                 INTEGER
         }














     F. Baker (editor)    Expires Nov 30 1992             [Page 59]





     Internet Draft             DS1 MIB                   June 1992


         ds1FracIndex OBJECT-TYPE
             SYNTAX  INTEGER
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The index value which uniquely identifies  the
                DS1  interface  to which this entry is applica-
                ble.  The interface identified by a  particular
                value  of  this  index is the same interface as
                identified by the same  value  an  ds1LineIndex
                object instance."
            ::= { ds1FracEntry 1 }



         ds1FracNumber OBJECT-TYPE
             SYNTAX  INTEGER (1..32)
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "The channel number for this entry."
            ::= { ds1FracEntry 2 }



         ds1FracIfIndex OBJECT-TYPE
             SYNTAX  INTEGER
             ACCESS  read-only
             STATUS  mandatory
             DESCRIPTION
                "An index value that uniquely identifies an in-
                terface.  The interface identified by a partic-
                ular value of this index is the same  interface
                as  identified by the same value an ifIndex ob-
                ject instance. If no interface is currently us-
                ing  a channel, the value should be zero.  If a
                single interface occupies more  than  one  time
                slot,  that ifIndex value will be found in mul-
                tiple time slots."
            ::= { ds1FracEntry 3 }


     END







     F. Baker (editor)    Expires Nov 30 1992             [Page 60]





     Internet Draft             DS1 MIB                   June 1992


     7.  Acknowledgements

     This document was produced by the Trunk MIB Working Group:

     In addition, the comments of the following individuals are
     also acknowledged.  Without their input, the document would
     not be what it is.

          Tracy Cox       Bellcore
          James Watt      Newbridge








































     F. Baker (editor)    Expires Nov 30 1992             [Page 61]





     Internet Draft             DS1 MIB                   June 1992


     8.  References

     [1]  V. Cerf, IAB Recommendations for the Development of
          Internet Network Management Standards.  Internet Working
          Group Request for Comments 1052.  Network Information
          Center, SRI International, Menlo Park, California,
          (April, 1988).

     [2]  V. Cerf, Report of the Second Ad Hoc Network Management
          Review Group, Internet Working Group Request for Comments
          1109.  Network Information Center, SRI International,
          Menlo Park, California, (August, 1989).

     [3]  M.T. Rose and K. McCloghrie, Structure and Identification
          of Management Information for TCP/IP-based internets,
          Internet Working Group Request for Comments 1155.
          Network Information Center, SRI International, Menlo
          Park, California, (May, 1990).

     [4]  K. McCloghrie and M.T. Rose, Management Information Base
          for Network Management of TCP/IP-based internets,
          Internet Working Group Request for Comments 1156.
          Network Information Center, SRI International, Menlo
          Park, California, (May, 1990).

     [5]  J.D. Case, M.S. Fedor, M.L. Schoffstall, and J.R. Davin,
          Simple Network Management Protocol, Internet Working
          Group Request for Comments 1157.  Network Information
          Center, SRI International, Menlo Park, California, (May,
          1990).

     [6]  M.T. Rose (editor), Management Information Base for
          Network Management of TCP/IP-based internets, Internet
          Working Group Request for Comments 1213.  Network
          Information Center, SRI International, Menlo Park,
          California, (May, 1990).

     [7]  Information processing systems - Open Systems
          Interconnection - Specification of Abstract Syntax
          Notation One (ASN.1), International Organization for
          Standardization.  International Standard 8824, (December,
          1987).

     [8]  Information processing systems - Open Systems
          Interconnection - Specification of Basic Encoding Rules





     F. Baker (editor)    Expires Nov 30 1992             [Page 62]





     Internet Draft             DS1 MIB                   June 1992


          for Abstract Notation One (ASN.1), International
          Organization for Standardization.  International Standard
          8825, (December, 1987).

     [9]  M.T. Rose, K. McCloghrie (editors), Towards Concise MIB
          Definitions, Internet Draft, Internet Engineering Task
          Force, (September, 1990).

     [10] M.T. Rose (editor), A Convention for Defining Traps for
          use with the SNMP, Internet Draft, Internet Engineering
          Task Force, (September, 1990).

     [11] AT&T Information Systems, AT&T ESF DS1 Channel Service
          Unit User's Manual, 999-100-305, February 1988.

     [12] AT&T Technical Reference, Requirements for Interfacing
          Digital Terminal Equipment to Services Employing the
          Extended Superframe Format, Publication 54016, May 1988.

     [13] CCITT Specifications Volume III, Recommendation G.703,
          Physical/Electrical Characteristics of Hierarchical
          Digital Interfaces, July 1988.

     14]  CCITT Specifications Volume III, Recommendation G.704,
          Synchronous frame structures used at primary and
          secondary hierarchical levels, July 1988.

     [15] American National Standard for Telecommunications --
          Layer 1 In-Service Digital Transmission Performance
          Monitoring T1M1/92-0xx, T1M1.3/92-005R1, April 1992.

     [16] Bell System Technical Reference, Publication 62411, High
          Capacity Digital Service Channel Interface Specification,
          September 1983.

     [17] Bell System Technical Reference, Publication 43801,
          "Digital Channel Bank Requirements and Objectives",
          November 1982.












     F. Baker (editor)    Expires Nov 30 1992             [Page 63]





     Internet Draft             DS1 MIB                   June 1992


     Table of Contents


     1 Status of this Memo ...................................    1
     2 Abstract ..............................................    1
     3 The Network Management Framework ......................    2
     4 Objects ...............................................    3
     4.1 Format of Definitions ...............................    3
     4.2 Changes from RFC 1232 ...............................    3
     5 Overview ..............................................    5
     5.1 Binding between ifIndex and DS1 Interfaces ..........    5
     5.2 Objectives of this MIB Module .......................    7
     5.3 DS1 Terminology .....................................    7
     6 Definitions ...........................................   11
     6.1 DS1 Near End Group ..................................   12
     6.1.1 DS1 Configuration Table ...........................   12
     6.1.2 DS1 Interval Table (deprecated) ...................   24
     6.1.3 DS1 Current Table .................................   29
     6.1.4 DS1 Total Table (deprecated) ......................   33
     6.1.5 DS1 Gauge Interval Table ..........................   37
     6.1.6 DS1 Gauge Total Table .............................   42
     6.2 DS1 Far End Group ...................................   46
     6.2.1 DS1 Far End Current Table .........................   46
     6.2.2 DS1 Far End Gauge Interval Table ..................   50
     6.2.3 DS1 Far End Gauge Total Table .....................   54
     6.3 DS1 Fractional Group ................................   58
     6.3.1 DS1 Fractional Table ..............................   58
     7 Acknowledgements ......................................   61
     8 References ............................................   62





















     F. Baker (editor)    Expires Nov 30 1992             [Page 64]











Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa04090;
          30 Jun 92 12:42 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa04085;
          30 Jun 92 12:42 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa15959;
          30 Jun 92 12:43 EDT
Received: from saffron.acc.com by fennel.acc.com (4.1/SMI-4.1)
	id AA13972; Tue, 30 Jun 92 09:34:49 PDT
Received: by saffron.acc.com (4.1/SMI-4.1)
	id AA01688; Tue, 30 Jun 92 09:34:07 PDT
Date: Tue, 30 Jun 92 09:34:07 PDT
From: Fred Baker <fbaker@acc.com>
Message-Id: <9206301634.AA01688@saffron.acc.com>
To: trunk-mib@fennel.acc.com
Subject: DS1/DS3 Meeting Agenda
Cc: megan@NRI.Reston.VA.US

Trunk MIB workers:

In the last couple of days, both Tracy and myself have mailed updated
copies of the DS1 and DS3 MIBs to the mailing list.  This morning, I
have also posted both mibs at fennel.acc.com (I *think* you can get
there just as acc.com, at least I know you can mail there that way).
They are under anonymous FTP, in the directory pub/trunk-mib

The agenda for our meeting at the IETF is quite simple.  The MIBs are
structurally similar and contain many objects that have very similar
meanings.  We should be able to go through them together.  So, we will
simply run through the tables and make sure that we all agree that
what's there is what should be, and iron out any difficulties.

We will post the MIBs as Internet Drafts after the IETF, hopefully with
a "the working group thinks these should be proposed standards"
statement, so that we don't have to bother CNRI very often.

Fred and Tracy










Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa14335;
          6 Jul 92 17:49 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa14331;
          6 Jul 92 17:49 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa25547; 6 Jul 92 17:51 EDT
Received: from uu3.psi.com by fennel.acc.com (4.1/SMI-4.1)
	id AA00709; Mon, 6 Jul 92 14:39:21 PDT
Received: by uu3.psi.com (5.65b/4.0.071791-PSI/PSINet)
	id AA26259; Mon, 6 Jul 92 17:38:54 -0400
Date: Mon, 6 Jul 92 17:28:28 EDT
From: Bill VerSteeg <bvs-snmp@ver.com>
Received: by veratl.ver.com (4.1/3.2.083191-VerSteeg CodeWorks)
	id AA01367; Mon, 6 Jul 92 17:28:28 EDT
Message-Id: <9207062128.AA01367@veratl.ver.com>
To: trunk-mib@fennel.acc.com
Subject: Interface table and un-implementable elements


The current document is a great improvement over rfc1232 in terms
of readability and clarity, particularly the section on
interface mappings. 

I will withold judgement on the technical merit of
the changes until I try to implement them (hopefully this
week).

One area I am still concerned with, however, is the lack of
direction in the specification of what to do with the actual
interface table. Clearly, there are things in the interface table
that can't be instrumented in the typical CSU ( like packets
in an interface ). The question of whether to return a 
bogus zero value when asked for this value, or to not
include this element in the MIB view is currently a hotly
debated topic.

Perhaps we could take some of the heat off of implementors
be stating in the RFC that certain interface table items may
not make sense for a CSU, and that the proper course of action
is to return NoSuchName. This would allow implementors
to "do the right thing" without the risk of being called
on the carpet for non-conformance to rfc1213.

Bill VerSteeg 












Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa15103;
          6 Jul 92 18:31 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa15099;
          6 Jul 92 18:31 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa27796; 6 Jul 92 18:33 EDT
Received: from saffron.acc.com by fennel.acc.com (4.1/SMI-4.1)
	id AA01012; Mon, 6 Jul 92 15:19:01 PDT
Received: by saffron.acc.com (4.1/SMI-4.1)
	id AA01720; Mon, 6 Jul 92 15:18:13 PDT
Date: Mon, 6 Jul 92 15:18:13 PDT
From: Fred Baker <fbaker@acc.com>
Message-Id: <9207062218.AA01720@saffron.acc.com>
To: bvs-snmp@ver.com
Subject: Re:  Interface table and un-implementable elements
Cc: trunk-mib@fennel.acc.com

>> I will withold judgement on the technical merit of
>> the changes until I try to implement them (hopefully this
>> week).

:^}	I hope your results are positive...

>> One area I am still concerned with, however, is the lack of
>> direction in the specification of what to do with the actual
>> interface table.

>> Perhaps we could take some of the heat off of implementors
>> be stating in the RFC that certain interface table items may
>> not make sense for a CSU, and that the proper course of action
>> is to return NoSuchName.

I'm willing if Chuck Davin is willing.  We can ask him at the IETF; I
suspect he's up to his eyeballs in administrivia at the moment.

Fred










Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa15612;
          6 Jul 92 18:50 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa15608;
          6 Jul 92 18:50 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa28871; 6 Jul 92 18:52 EDT
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA01243; Mon, 6 Jul 92 15:34:46 PDT
Return-Path: <kaj@cc.bellcore.com@sabre.bellcore.com>
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA03133; Mon, 6 Jul 92 18:37:36 EDT
Received: by sword.bellcore.com;id 9207062236.AA19924
Message-Id: <9207062236.AA19924@sword.bellcore.com>
Date: Mon, 6 Jul 92 18:36:25 EDT
To: Bill VerSteeg <bvs-snmp@ver.com>
From: kaj@cc.bellcore.com
Subject: Re: Interface table and un-implementable elements
Cc: trunk-mib@fennel.acc.com


>Perhaps we could take some of the heat off of implementors
>be stating in the RFC that certain interface table items may
>not make sense for a CSU, and that the proper course of action
>is to return NoSuchName. This would allow implementors
>to "do the right thing" without the risk of being called
>on the carpet for non-conformance to rfc1213.
>
>Bill VerSteeg 

very good idea!

0------------0--------------0-------------0-------------0-----------0
Kaj Tesink                            vmail (908) 758-5254
pmail Bellcore                      faxmail (908) 758-4196
      331 Newman Springs Rd.          email kaj@cc.bellcore.com
      Red Bank, NJ 07701











Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa01700;
          7 Jul 92 8:45 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa01696;
          7 Jul 92 8:45 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa08447; 7 Jul 92 8:47 EDT
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA23120; Tue, 7 Jul 92 05:39:04 PDT
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA05402; Tue, 7 Jul 92 08:41:55 EDT
Return-Path: <tacox@ginsu4@sabre.bellcore.com>
Received: from localhost by ginsu4 (4.1/4.7)
	id AA00722; Tue, 7 Jul 92 08:26:32 EDT
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9207071226.AA00722@ginsu4>
To: Bill VerSteeg <bvs-snmp@ver.com>
Cc: trunk-mib@fennel.acc.com
Subject: Re: Interface table and un-implementable elements 
In-Reply-To: Your message of "Mon, 06 Jul 92 17:28:28 EDT."
             <9207062128.AA01367@veratl.ver.com> 
Date: Tue, 07 Jul 92 08:26:31 -0400
From: tacox@ginsu4.bellcore.com


Bill,

To respond to you question:


One area I am still concerned with, however, is the lack of
direction in the specification of what to do with the actual
interface table. Clearly, there are things in the interface table
that can't be instrumented in the typical CSU ( like packets
in an interface ). The question of whether to return a 
bogus zero value when asked for this value, or to not
include this element in the MIB view is currently a hotly
debated topic.

Perhaps we could take some of the heat off of implementors
be stating in the RFC that certain interface table items may
not make sense for a CSU, and that the proper course of action
is to return NoSuchName. This would allow implementors
to "do the right thing" without the risk of being called
on the carpet for non-conformance to rfc1213.


-------------------
I agree with your last paragraph.  That is precisely what
we plan to do when instrumenting an SNMP agent on an SMDS
network.  We only use approx. the first 8 objects of the interface
table of MIB II -- the other objects we return noSuchName.

We think that the following objects make the most sense to be
implemented for an SMDS interface:
ifIndex
ifDesc
ifType
ifMtu
ifSpeed
ifOperStatus
ifAdminStatus
ifLastChange

Tracy










Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa03004;
          7 Jul 92 10:21 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa03000;
          7 Jul 92 10:21 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa12526; 7 Jul 92 10:23 EDT
Received: from signet.com (signet3.signet.com) by fennel.acc.com (4.1/SMI-4.1)
	id AA23522; Tue, 7 Jul 92 07:15:13 PDT
Received: from sigmadsk2.signet.com by signet.com (4.1/SMI-4.1)
	id AA16750; Tue, 7 Jul 92 09:09:26 EDT
Date: Tue, 7 Jul 92 09:09:26 EDT
From: Kenneth Virgile <ken@signet.com>
Message-Id: <9207071309.AA16750@signet.com>
To: trunk-mib@fennel.acc.com
Subject: Interface table and un-implementable elements

Suggestion:

Do what is best for the people/machines who want to
look at the mib-2 data (i.e., NMSes).
Why not the let marketplace decide what it wants, i.e.,
place no requirements on certain items in the interface table?

If the CSU MIB defines requirements for that mib-2 data,
the following will result:
 1. The data will not be what the NMSes want.
 2. Many implementors will not follow the requirements,
    because good NMS support is often more important
    than 100% MIB compliance.
 3. NMS operators will lose out on the ability to check
    both ends of a link for data consistency in certain
    mib-2 counters.  This is not needed, and due to
    lack of 100% MIB compliance, will not be viable anyway.


Ken V.










Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa05515;
          7 Jul 92 13:27 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa05511;
          7 Jul 92 13:27 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa21947; 7 Jul 92 13:29 EDT
Received: from relay1.UU.NET by fennel.acc.com (4.1/SMI-4.1)
	id AA25250; Tue, 7 Jul 92 10:15:00 PDT
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA05153; Tue, 7 Jul 92 13:14:25 -0400
Received: from clrcom.UUCP by uunet.uu.net with UUCP/RMAIL
	(queueing-rmail) id 131219.1686; Tue, 7 Jul 1992 13:12:19 EDT
Received: from worf.clear by clear (4.1/SMI-4.0)
	id AA12978; Tue, 7 Jul 92 11:47:36 CDT
Received: from kirk.clear by worf.clear (4.1/SMI-4.1)
	id AA17644; Tue, 7 Jul 92 11:47:41 CDT
Date: Tue, 7 Jul 92 11:47:41 CDT
From: Kurt Hall <clrcom!worf!khall@uunet.uu.net>
Message-Id: <9207071647.AA17644@worf.clear>
To: uunet!acc.com!fbaker@uunet.uu.net
Subject: Re: DS1 MIB, throw out the one you just got
Cc: trunk-mib@fennel.acc.com, worf!musa@uunet.uu.net


I have a few minor corrections/suggestions as well as some 
technical issues.  Unfortunately I will probably not be able 
to attend the IETF meeting.


Page 6, line 5 (not counting the header or blank lines) should read:

  residing on the router proxies for itself and the CSUs. The
                                                       -

Page 8, the 4th line under the title Severely Errored Seconds 
(SES) should read:

  AIS.  For SF signals, a SES is a count of one-second
                     -

Page 8, also under Severely Errored Seconds, the following lines
should be corrected:

  included in this parameter.  Severely Errored Framing
                               ------------------------
  Second (SEFS) An Severely Errored Framing Second is a
  ----------------


Page 8, under Unavailable Seconds (UAS) you have the text
"(see Failure States)".  I was unable to find what it was
referring to until a second reading of the document.  Could
you please break it into its own paragraphs with a heading
or otherwise highlight it so it can be easily found when it
is referred to?

Also, in the discussion of failure clearing time, is this 
referring to the 2-10 seconds of no detected far end alarms?
Could you also elaborate on the 2-10 second ranges and how 
(and where) they are determined.


Page 16, ds1JammedBit 
this is commonly referred to as bit or pulse stuffing.
Perhaps its too late to change the name, but you may want
to throw the terminology in there somewhere.


Page 16, ds1B8ZS
Most (if not all) CSU manaufacturers make a distinction between
B8ZS and AMI coding.  What should the value returned be for a
CSU with AMI (not B8ZS) coding?  Should there be a new value?


Page 19, ds1SendLoopbackCode & ds1SendTestMessage
Could you elaborate on the test pattern names? Should I assume 
that ds1SendTestMessage specifies a single named test pattern
and that ds1SendLoopbackCode includes any other test pattern?


Page 21,
Say the CSU has a loopback to the DTE side, would this object
be set to ds1OtherLoop or ds1NoLoop?  Technically, the NI side
is not in a loopback state.


Page 23,
I found the value names ambiguous or confusing without any 
definitions.  In particular:
	ds1FarEndAlarm - yellow alarm? or indication of far-end
		alarm obtained via the facility data link?
	ds1AlarmIndicationSignal - receiving? or generating?
	ds1LossOfFrame - aka Red Alarm
	ds1LoopbackState - presence of any loopback as indicated
		in object ds1LoopbackConfig?
	ds1T16AlarmIndicationSignal - ?
	ds1LossOfMultiFrame - ?
	ds1Distant* - ?


Page 37, DS1 Guage Interval
I understand the depricating of the ds1IntervalTable and the
need to have a new but essentially equivalent one, but I feel
uncomfortable about using the word "Gauge" within the names.
Gauge really refers more to the terminology used in implementing
the MIB as opposed to the contents of the table (and seems like
a grasp at finding a unique name).

Since the contents of the table are intervals, it can correctly 
be called the DS1 Intervals (note the plural) Table or 
ds1IntervalsTable.  This is a very subtle change but quite 
logical.  I don't fear any confusion will result from the 
similarity since any future discussion will always be referring 
to the new table.  Another suggestion would be to use something 
along the lines of DS1 Previous (Historical?) Interval Table or 
ds1PrevIntervalTable.


Page 42, ds1 Gauge Total
[You can probably guess my suggestion 8^) ].  I would like to
suggest DS1 Totals (note the plural) Table or ds1TotalsTable
instead of using Gauge.  The logic follows the above.


Page 47,49,50,53,54,56
Is *LESs supposed to be *BPVs?  If not, what does LES stand
for?


Page 50, DS1 Far End Gauge Interval
see above naming suggestion


Page 54, DS1 Far End Gauge Total
see above naming suggestion


- kurt 










Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa13209;
          8 Jul 92 0:49 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa13205;
          8 Jul 92 0:49 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa17147; 8 Jul 92 0:51 EDT
Received: from uu3.psi.com by fennel.acc.com (4.1/SMI-4.1)
	id AA01408; Tue, 7 Jul 92 21:41:33 PDT
Received: by uu3.psi.com (5.65b/4.0.071791-PSI/PSINet)
	id AA12587; Wed, 8 Jul 92 00:41:03 -0400
Date: Wed, 8 Jul 92 00:17:37 EDT
From: Bill VerSteeg <bvs-snmp@ver.com>
Received: by veratl.ver.com (4.1/3.2.083191-VerSteeg CodeWorks)
	id AA01797; Wed, 8 Jul 92 00:17:37 EDT
Message-Id: <9207080417.AA01797@veratl.ver.com>
To: trunk-mib@acc.com
Subject: new mib, miscellaneous observations



A few ramblings while I implement the
new DS1 MIB.



Page 4
The act of carefully deprecating objects to maintain
compatibilty with rfc1232 may be mental masturbation.
When the meaning of ds1LineIndex and ds1IfIndex were changed,
and the old numbers re-used, we lost all hope of running
both rfc1232 compliant and new-MIB compliant systems
in the same box. We need to either REALLY depricate the
old DS1CSUIndex and the old DS1Index (i.e. use a new number
for the new MIB) or just pretend rfc1232 never happened.
Trust me, I am trying to make my old code work with
the new code, and if we mean to "depricate", we must use
new numbers. When my agent is asked for {ds1ConfigEntry 1}, I have
no way of knowing whether to return the old syntax or the new.


Page 23
The bit values for Line Status are fuzzy to me. Could we spell
them out or reference the appropriate document that spells
them out?

Page 27
I am no longer sure about the rational for 
deprecating Interval and Total and not depricating Current. As
I recall, we can't use counter for Total and Interval because
the values may decrease when the 15 minutes elapse. The same
test held to Current also holds. Every 15 minutes, Current values 
may decrease.

Page 43
Current Table values may decrease. Can this be a counter? 

Page 53
What is LESs? Should this be BPVs? If LESs is correct,
we should note what LESs are.



In summary, if we want to have one agent be able to run
both rfc1232 and new-mib at the same time, we need to
fix the DS1LineIndex/ds1IfIndex "deprication".
The only other alternative is to declare the rfc1232
stuff null and void and just re-use the numbers.
A half-measure is MUCH worse than either of the two
alternatives.

I will probably run only the new-mib stuff in production
systems, but if anyone has fielded rfc1232 based systems,
we will trash them unless we fix these half-depricated
items.



Bill VerSteeg

P.S. Other than the administrative issues associated
with rooting the MIB and numbering the branches, 
the document looks pretty good. 
I grafted the SNMP portion of the new MIB onto my
rfc1232 based stuff in a few hours. I will try to tackle
the T1 issues next to see what else shakes out.











Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa04125;
          15 Jul 92 15:28 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa04121;
          15 Jul 92 15:28 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa24460;
          15 Jul 92 15:30 EDT
Received: from saffron.acc.com by fennel.acc.com (4.1/SMI-4.1)
	id AA27635; Wed, 15 Jul 92 12:17:49 PDT
Received: by saffron.acc.com (4.1/SMI-4.1)
	id AA00651; Wed, 15 Jul 92 12:17:08 PDT
Date: Wed, 15 Jul 92 12:17:08 PDT
From: Fred Baker <fbaker@acc.com>
Message-Id: <9207151917.AA00651@saffron.acc.com>
To: trunk-mib@fennel.acc.com
Subject: DS1 MIB Update

Folks:

I have updated the DS1 MIB per the comments of the working group, both on
the mailing list and in the workingg group this morning.  The decision of
the Working Group, per Bill Versteeg's suggestion, was to completely
obsolete RFC 1232 and RFC 1233, and remove all of the deprecated objects
from this document.  It reflects this.  In addition, we added LESs to the
near end tables, changed all Counters remaining (current table) to Gauges,
and modified the Zero Code Suppression, Alarm, and Loopback Object
descriptions, and added a Signaling Mode object.

James Watt took an action item to supply appropriate text for the failure
states description. A description of Line Errored Seconds (which T1M1 has
available only from the far end, but we decided to include for the near end
for symmetry's sake) was added.

A question for the world: in the near end tables, we are now recording BPVs
experienced AND Line Errored Seconds, which are seconds in which either a
BPV or an illegal zero sequence was received. Do we really need both?
I would like to remove the BPV counts.

The MIB is available for anonymous FTP at fennel.acc.com.  Tracy hasn't
updated her document yet; she'll let us know when it's there.  Please
review the DS1 document, and when you throw bricks, throw them gently :^}

While you're reviewing, please check the ACKNOWLEDGEMENTS and make sure
that your name and corporate affiliation are there and correctly spelled,
and that your contributions are correctly described.  If you're not there
(and if you weren't at the IETF this morning, that's a real possibility)
drop me a private e-mail and we'll get it taken care of.

The MIB has passed cleanly through Dave Perkin's SMIC compiler and through
mosy. For quick reference, I have included the mosy output in theis
message, so that you can see quickly what tables and objects are there.

Fred
=======================================================
-- automatically generated by mosy 6.0 #53 (wp2), do not edit!

-- object definitions compiled from RFCxxxx-MIB

ds1                  transmission.18

dsx1ConfigTable      ds1.6            Aggregate       not-accessible  mandatory
dsx1ConfigEntry      dsx1ConfigTable.1 Aggregate       not-accessible  mandatory
dsx1LineIndex        dsx1ConfigEntry.1 INTEGER         read-only       mandatory
dsx1IfIndex          dsx1ConfigEntry.2 INTEGER         read-only       mandatory
dsx1TimeElapsed      dsx1ConfigEntry.3 INTEGER         read-only       mandatory
dsx1ValidIntervals   dsx1ConfigEntry.4 INTEGER         read-only       mandatory
dsx1LineType         dsx1ConfigEntry.5 INTEGER         read-only       mandatory
dsx1ZeroCoding       dsx1ConfigEntry.6 INTEGER         read-only       mandatory
dsx1SendCode         dsx1ConfigEntry.7 INTEGER         read-only       mandatory
dsx1CircuitIdentifier dsx1ConfigEntry.8 DisplayString   read-only       mandatory
dsx1LoopbackConfig   dsx1ConfigEntry.9 INTEGER         read-only       mandatory
dsx1LineStatus       dsx1ConfigEntry.10 INTEGER         read-only       mandatory
dsx1SignalMode       dsx1ConfigEntry.11 INTEGER         read-only       mandatory
dsx1CurrentTable     ds1.7            Aggregate       not-accessible  mandatory
dsx1CurrentEntry     dsx1CurrentTable.1 Aggregate       not-accessible  mandatory
dsx1CurrentIndex     dsx1CurrentEntry.1 INTEGER         read-only       mandatory
dsx1CurrentESs       dsx1CurrentEntry.2 Gauge           read-only       mandatory
dsx1CurrentSESs      dsx1CurrentEntry.3 Gauge           read-only       mandatory
dsx1CurrentSEFSs     dsx1CurrentEntry.4 Gauge           read-only       mandatory
dsx1CurrentUASs      dsx1CurrentEntry.5 Gauge           read-only       mandatory
dsx1CurrentCSSs      dsx1CurrentEntry.6 Gauge           read-only       mandatory
dsx1CurrentBPVs      dsx1CurrentEntry.7 Gauge           read-only       mandatory
dsx1CurrentCVs       dsx1CurrentEntry.8 Gauge           read-only       mandatory
dsx1CurrentLESs      dsx1CurrentEntry.9 Gauge           read-only       mandatory
dsx1IntervalTable    ds1.8            Aggregate       not-accessible  mandatory
dsx1IntervalEntry    dsx1IntervalTable.1 Aggregate       not-accessible  mandatory
dsx1IntervalIndex    dsx1IntervalEntry.1 INTEGER         read-only       mandatory
dsx1IntervalNumber   dsx1IntervalEntry.2 INTEGER         read-only       mandatory
dsx1IntervalESs      dsx1IntervalEntry.3 Gauge           read-only       mandatory
dsx1IntervalSESs     dsx1IntervalEntry.4 Gauge           read-only       mandatory
dsx1IntervalSEFSs    dsx1IntervalEntry.5 Gauge           read-only       mandatory
dsx1IntervalUASs     dsx1IntervalEntry.6 Gauge           read-only       mandatory
dsx1IntervalCSSs     dsx1IntervalEntry.7 Gauge           read-only       mandatory
dsx1IntervalBPVs     dsx1IntervalEntry.8 Gauge           read-only       mandatory
dsx1IntervalCVs      dsx1IntervalEntry.9 Gauge           read-only       mandatory
dsx1IntervalLESs     dsx1IntervalEntry.10 Gauge           read-only       mandatory
dsx1TotalTable       ds1.9            Aggregate       not-accessible  mandatory
dsx1TotalEntry       dsx1TotalTable.1 Aggregate       not-accessible  mandatory
dsx1TotalIndex       dsx1TotalEntry.1 INTEGER         read-only       mandatory
dsx1TotalESs         dsx1TotalEntry.2 Gauge           read-only       mandatory
dsx1TotalSESs        dsx1TotalEntry.3 Gauge           read-only       mandatory
dsx1TotalSEFSs       dsx1TotalEntry.4 Gauge           read-only       mandatory
dsx1TotalUASs        dsx1TotalEntry.5 Gauge           read-only       mandatory
dsx1TotalCSSs        dsx1TotalEntry.6 Gauge           read-only       mandatory
dsx1TotalBPVs        dsx1TotalEntry.7 Gauge           read-only       mandatory
dsx1TotalCVs         dsx1TotalEntry.8 Gauge           read-only       mandatory
dsx1TotalLESs        dsx1TotalEntry.9 Gauge           read-only       mandatory
dsx1FarEndCurrentTable ds1.10           Aggregate       not-accessible  mandatory
dsx1FarEndCurrentEntry dsx1FarEndCurrentTable.1 Aggregate       not-accessible  mandatory
dsx1FarEndCurrentIndex dsx1FarEndCurrentEntry.1 INTEGER         read-only       mandatory
dsx1FarEndCurrentESs dsx1FarEndCurrentEntry.2 Gauge           read-only       mandatory
dsx1FarEndCurrentSESs dsx1FarEndCurrentEntry.3 Gauge           read-only       mandatory
dsx1FarEndCurrentSEFSs dsx1FarEndCurrentEntry.4 Gauge           read-only       mandatory
dsx1FarEndCurrentCSSs dsx1FarEndCurrentEntry.5 Gauge           read-only       mandatory
dsx1FarEndCurrentLESs dsx1FarEndCurrentEntry.6 Gauge           read-only       mandatory
dsx1FarEndCurrentCVs dsx1FarEndCurrentEntry.7 Gauge           read-only       mandatory
dsx1FarEndIntervalTable ds1.11           Aggregate       not-accessible  mandatory
dsx1FarEndIntervalEntry dsx1FarEndIntervalTable.1 Aggregate       not-accessible  mandatory
dsx1FarEndIntervalIndex dsx1FarEndIntervalEntry.1 INTEGER         read-only       mandatory
dsx1FarEndIntervalNumber dsx1FarEndIntervalEntry.2 INTEGER         read-only       mandatory
dsx1FarEndIntervalESs dsx1FarEndIntervalEntry.3 Gauge           read-only       mandatory
dsx1FarEndIntervalSESs dsx1FarEndIntervalEntry.4 Gauge           read-only       mandatory
dsx1FarEndIntervalSEFSs dsx1FarEndIntervalEntry.5 Gauge           read-only       mandatory
dsx1FarEndIntervalCSSs dsx1FarEndIntervalEntry.6 Gauge           read-only       mandatory
dsx1FarEndIntervalLESs dsx1FarEndIntervalEntry.7 Gauge           read-only       mandatory
dsx1FarEndIntervalCVs dsx1FarEndIntervalEntry.8 Gauge           read-only       mandatory
dsx1FarEndTotalTable ds1.12           Aggregate       not-accessible  mandatory
dsx1FarEndTotalEntry dsx1FarEndTotalTable.1 Aggregate       not-accessible  mandatory
dsx1FarEndTotalIndex dsx1FarEndTotalEntry.1 INTEGER         read-only       mandatory
dsx1FarEndTotalESs   dsx1FarEndTotalEntry.2 Gauge           read-only       mandatory
dsx1FarEndTotalSESs  dsx1FarEndTotalEntry.3 Gauge           read-only       mandatory
dsx1FarEndTotalSEFSs dsx1FarEndTotalEntry.4 Gauge           read-only       mandatory
dsx1FarEndTotalCSSs  dsx1FarEndTotalEntry.5 Gauge           read-only       mandatory
dsx1FarEndTotalLESs  dsx1FarEndTotalEntry.6 Gauge           read-only       mandatory
dsx1FarEndTotalCVs   dsx1FarEndTotalEntry.7 Gauge           read-only       mandatory
dsx1FracTable        ds1.13           Aggregate       not-accessible  mandatory
dsx1FracEntry        dsx1FracTable.1  Aggregate       not-accessible  mandatory
dsx1FracIndex        dsx1FracEntry.1  INTEGER         read-only       mandatory
dsx1FracNumber       dsx1FracEntry.2  INTEGER         read-only       mandatory
dsx1FracIfIndex      dsx1FracEntry.3  INTEGER         read-only       mandatory












Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa03869;
          17 Jul 92 13:19 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa03865;
          17 Jul 92 13:19 EDT
Received: from ietf.NRI.Reston.Va.US by NRI.Reston.VA.US id aa19194;
          17 Jul 92 13:21 EDT
Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa03845;
          17 Jul 92 13:18 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa03841;
          17 Jul 92 13:18 EDT
Received: from sabre.bellcore.com by NRI.Reston.VA.US id aa19163;
          17 Jul 92 13:20 EDT
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA29002; Fri, 17 Jul 92 13:23:26 EDT
Return-Path: <tacox@sabre.bellcore.com>
Received: by ginsu4 (4.1/4.7)
	id AA02448; Fri, 17 Jul 92 13:08:09 EDT
Date: Fri, 17 Jul 92 13:08:09 EDT
From: Tracy Cox <tacox@sabre.bellcore.com>
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9207171708.AA02448@ginsu4>
To: iplpdn@NRI.Reston.VA.US, atm@sun.com, trunk-mib@acc.com
Subject: SONET MIB

Gang, 

This message serves to tell you that there
is a SONET MIB posted in Internet-Drafts
directory. 

It is called:

draft-ietf-cox-sonetmib-00.txt

If you have any questions
or comments on it please direct them
to the authors --

Tracy Cox -- tacox@sabre.bellcore.com
Kaj Tesink -- kaj@cc.bellcore.com

We are very interested in hearing from people
who are interested in the this MIB.

Thanks.

Tracy
===========================================
Tracy A. Cox
Bellcore
NVC 1C-354
331 Newman Springs Rd.
Red Bank, NJ  07701
tacox@sabre.bellcore.com email
(908) 758-2107 vmail
(908) 758-4177 fax
===========================================










Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa03959;
          17 Jul 92 13:28 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa03955;
          17 Jul 92 13:28 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa19588;
          17 Jul 92 13:31 EDT
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA12691; Fri, 17 Jul 92 10:20:50 PDT
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA29002; Fri, 17 Jul 92 13:23:26 EDT
Return-Path: <tacox@sabre.bellcore.com>
Received: by ginsu4 (4.1/4.7)
	id AA02448; Fri, 17 Jul 92 13:08:09 EDT
Date: Fri, 17 Jul 92 13:08:09 EDT
From: Tracy Cox <tacox@sabre.bellcore.com>
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9207171708.AA02448@ginsu4>
To: iplpdn@NRI.Reston.VA.US, atm@sun.com, trunk-mib@acc.com
Subject: SONET MIB

Gang, 

This message serves to tell you that there
is a SONET MIB posted in Internet-Drafts
directory. 

It is called:

draft-ietf-cox-sonetmib-00.txt

If you have any questions
or comments on it please direct them
to the authors --

Tracy Cox -- tacox@sabre.bellcore.com
Kaj Tesink -- kaj@cc.bellcore.com

We are very interested in hearing from people
who are interested in the this MIB.

Thanks.

Tracy
===========================================
Tracy A. Cox
Bellcore
NVC 1C-354
331 Newman Springs Rd.
Red Bank, NJ  07701
tacox@sabre.bellcore.com email
(908) 758-2107 vmail
(908) 758-4177 fax
===========================================










Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa04345;
          17 Jul 92 16:10 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa04341;
          17 Jul 92 16:10 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa26674;
          17 Jul 92 16:13 EDT
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA15115; Fri, 17 Jul 92 13:04:44 PDT
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA29718; Fri, 17 Jul 92 16:00:22 EDT
Return-Path: <tacox@sabre.bellcore.com>
Received: by ginsu4 (4.1/4.7)
	id AA02638; Fri, 17 Jul 92 15:45:06 EDT
Date: Fri, 17 Jul 92 15:45:06 EDT
From: Tracy Cox <tacox@sabre.bellcore.com>
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9207171945.AA02638@ginsu4>
To: trunk-mib@acc.com
Subject: LESs for DS3 MIB

Gang,

Should the DS3 MIB also count LESs at the near end?
The reason for the question is that the DS3 Far End Tables
only provides for ESs, SESs, and CVs -- nothing else.
So the symmetry problem is not present for DS3.  We CAN
count it for the near end only.

What do people think -- keep LESs for DS3 near end tables
for symmetry with DS1 counts at the near end?

Should we remove the BPVs as Fred suggests from the near end
tables of both MIBs?


Tracy










Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa04579;
          17 Jul 92 18:11 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa04575;
          17 Jul 92 18:11 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa01305;
          17 Jul 92 18:14 EDT
Received: from vnet.ibm.com by fennel.acc.com (4.1/SMI-4.1)
	id AA16042; Fri, 17 Jul 92 15:03:53 PDT
Message-Id: <9207172203.AA16042@fennel.acc.com>
Received: from RALVM29 by vnet.ibm.com (IBM VM SMTP V2R2) with BSMTP id 2417;
   Fri, 17 Jul 92 18:03:06 EDT
Date: Fri, 17 Jul 92 17:56:55 EDT
From: "Laurence V. Marks" <lmarks@vnet.ibm.com>
To: trunk-mib@acc.com, fbaker@acc.com
Cc: DILLON@ralvm29.vnet.ibm.com
Subject: Comments on new ds1-mib

Fred:

Here are some comments on the latest ds1mib draft.  I am sorry I was
never able to attend a Working Group meeting with you, and meet the
contributors.

Please take these comments in the spirit in which they are offered;
in the interests of a better final product.

Laurence V. Marks
----------------------------------------------------------------------
The best way to distinguish E1-without-CRC from E1-with-CRC is to refer
to them as G.704-Table 4a and G.704-Table 4b, I think, since it is
difficult to identify crisp section references.  The references to
sections 2.1.3.1 and 2.1.3.2 carried forward from old version are
incorrect.  I believe I first brought this to your attention in
November 1991.

The Section 5 Overview states that the intent is to cover ds1 and E1,
but several subsequent paragraphs are ds1-specific.  I know that you
are more concerned with North America than the rest of the world, but
have nevertheless noted some places that could be easily changed.

Section 5.3
-----------

Under Bipolar Violation
Change "for a B8ZS-coded signal" to "for a B8ZS- or HDB3-coded signal"

Under Controlled Slip Seconds
Delete "192"

Under Errored Seconds
Change "For ESF signals" to "For ESF signals or E-1 G.704 (Table 4b)
signals with CRC"
Change "G.704 (E1 signals) section 2.1.3.2" to "G.704 (E1 signals) Table
4a"

Under Severely Errored Seconds
The MIB lacks a definition for E1.  CCITT O.162 specifies break points
at 10**-3, 10**-4 and 10**-5, corresponding to 2040, 204.8, and 20.48
errors per second.  Hence it might be reasonable to specify 205 errors
per second, as roughly corresponding to 320 for ds1.

Hard carriage returns and a hanging outdent are needed to separate the
following paragraph (Severely Errored Framing Seconds) from this one,
into which it has been reflowed.

Under Failure States:
The reference is to ANSI T1.107.  The endnote points to Rose's work on
SNMP Traps.  There is no endnote corresponding to ANSI T1.107.
The corresponding E1 reference is CCITT O.162, Paragraph 3.3.6.

Under Out of Frame (OOF) Defect
The corresponding E1 definition is "Frame alignment will be assumed to
have been lost when three consecutive incorrect frame alignment signals
have been received."  This statement comes from CCITT G.706,
Section 4.1.1.

Under Loss of Signal (LOS)
I cannot find a corresponding definition for E1.  prETS 300 011
(March 1991) refers to a signal 20dB below the nominal output amplitude
specified in G.703 for a time duration of at least 1 ms, but
--This is a draft also, and not accepted.
--I am unaware of any conforming implementations.

Under Alarm Indication Signal (AIS)
The accepted definition for E1 is a string of 512 bits containing less
than three zero bits, found in CCITT O.162, section 3.3.2.

Section 6
---------

Under dsx1LineType  (page 16)
Change "CCITT Recommendation G.704 (section 2.1.3.2)"
to     "CCITT Recommendation G.704, Table 4a"
Change "CCITT Recommendation G.704 (section 2.1.3.1)"
to     "CCITT Recommendation G.704, Table 4b"

Under the section describing the ds1 Fractional Group  (page xlv)
The numbering for E1 is not correct.  There are only 31 channels
available for data, since the first channel contains the CRC and RAI and
framing information.  (See G.704, sections 2.3.1 and 2.3.2.) I don't
know whether it is easier with ASN.1 to number the remaining channels 1
to 31 or 0 to 30.

Section 8
---------
It is always difficult to keep references up to date.

Endnote 12 refers to the May 1988 version of AT&T TR 54016.  The version
of AT&T TR 54016 I have is September 1989. There may be a later one.
(I do not believe the update affects the MIB.

Endnote 16 refers to the September 1983 version of AT&T TR 62411. The
version of AT&T TR 62411 I have is December 1990. There may be a later
one.  (I do not believe the update affects the MIB.













Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa12420;
          20 Jul 92 8:45 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa12416;
          20 Jul 92 8:45 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa28747; 20 Jul 92 8:48 EDT
Received: from vnet.ibm.com by fennel.acc.com (4.1/SMI-4.1)
	id AA08271; Mon, 20 Jul 92 05:34:32 PDT
Message-Id: <9207201234.AA08271@fennel.acc.com>
Received: from RALVM29 by vnet.ibm.com (IBM VM SMTP V2R2) with BSMTP id 3931;
   Mon, 20 Jul 92 08:33:41 EDT
Date: Mon, 20 Jul 92 08:12:24 EDT
From: "Laurence V. Marks" <lmarks@vnet.ibm.com>
To: trunk-mib@acc.com, fbaker@acc.com
Subject: 20-20 Hindsight

After reflecting on my comments regarding E-1 definitions, I wish to
clarify them.

I am not aware that the criteria I proposed for Severely Errored Seconds
or Loss of Signal are implemented anywhere.  Thus it is unreasonable to
define them in the MIB, and I withdraw those comments.

Laurence V. Marks












Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa06097;
          21 Jul 92 14:40 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa06093;
          21 Jul 92 14:40 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa21231;
          21 Jul 92 14:43 EDT
Received: from saffron.acc.com by fennel.acc.com (4.1/SMI-4.1)
	id AA10430; Tue, 21 Jul 92 11:26:00 PDT
Received: by saffron.acc.com (4.1/SMI-4.1)
	id AA25058; Tue, 21 Jul 92 11:25:19 PDT
Date: Tue, 21 Jul 92 11:25:19 PDT
From: Fred Baker <fbaker@acc.com>
Message-Id: <9207211825.AA25058@saffron.acc.com>
To: trunk-mib@fennel.acc.com
Subject: Re: DS1 MIB Update

I forgot to put in the name of the file for the DS1 MIB proposal.
It's:

	fennel.acc.com: pub/trunk-mib/DS1.mib

Sorry about that

Fred










Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id ab04091;
          24 Jul 92 11:34 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa04087;
          24 Jul 92 11:34 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa18687;
          24 Jul 92 11:34 EDT
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA27186; Fri, 24 Jul 92 08:22:57 PDT
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA04701; Fri, 24 Jul 92 11:26:01 EDT
Return-Path: <tacox@ginsu4@sabre.bellcore.com>
Received: from localhost by ginsu4 (4.1/4.7)
	id AA01239; Fri, 24 Jul 92 11:10:25 EDT
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9207241510.AA01239@ginsu4>
To: Fred Baker <fbaker@acc.com>
Cc: trunk-mib@fennel.acc.com
Subject: Re: DS1 MIB Update -- DS3
In-Reply-To: Your message of "Tue, 21 Jul 92 11:25:19 PDT."
             <9207211825.AA25058@saffron.acc.com> 
Date: Fri, 24 Jul 92 11:10:24 -0400
From: tacox@ginsu4.bellcore.com

> 
> 
> I forgot to put in the name of the file for the DS1 MIB proposal.
> It's:
> 
> 	fennel.acc.com: pub/trunk-mib/DS1.mib
> 
> Sorry about that
> 
> Fred


Trunk-mibbers,

The DS3.mib is there also -- ftp fennel.acc.com
and get /pub/trunk-mib/DS3.mib

Any comments -- let us know ASAP, because Fred and I would
like to finish off these MIBs and forward them to the IESG for
their approval as RFCs!!!

I put the LES counter into the DS3 mib also.
I also kept BPV counter there also.

What do people think -- both or LES only?


Tracy











Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa03570;
          28 Jul 92 13:14 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa03566;
          28 Jul 92 13:14 EDT
Received: from [129.192.64.25] by NRI.Reston.VA.US id aa18316;
          28 Jul 92 13:15 EDT
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA23061; Tue, 28 Jul 92 09:56:05 PDT
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA25683; Tue, 28 Jul 92 12:59:08 EDT
Return-Path: <tacox@sabre.bellcore.com>
Received: by ginsu4 (4.1/4.7)
	id AA03126; Tue, 28 Jul 92 12:43:22 EDT
Date: Tue, 28 Jul 92 12:43:22 EDT
From: Tracy Cox <tacox@sabre.bellcore.com>
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9207281643.AA03126@ginsu4>
To: mdavies@NRI.Reston.VA.US, trunk-mib@acc.com
Subject: Trunk-MIB WG Minutes

Megan and trunk-mibbers,

Here are the minutes from the trunk-mib
WG.

Tracy
===========================================
Tracy A. Cox
Bellcore
NVC 1C-354
331 Newman Springs Rd.
Red Bank, NJ  07701
tacox@sabre.bellcore.com email
(908) 758-2107 vmail
(908) 758-4177 fax
===========================================
The minutes of the Trunk-MIB Working Group

IETF Meeting 7/15/92
San Diego, CA


The decision of
the Working Group, per Bill Versteeg's suggestion, was to completely
obsolete RFC 1232 and RFC 1233, and remove all of the deprecated objects
from this document.  All tables have been given new names
and new OIDs.  The beginning delimiter for all objects
is dsx* (* = 1 or 3).  In addition, we added LESs to the
near end tables, changed all Counters remaining (current table) to Gauges,
and modified the dsx1LineCoding, dsx1LineStatus, dsx*SendCode Object
descriptions, and added a Signaling Mode object (DS1 MIB only).
We have an action item to resolve on whether to keep or remove
the BPVs count.

James Watt took an action item to supply appropriate text for the failure
states description. A description of Line Errored Seconds (which T1M1 has
available only from the far end, but we decided to include for the near end
for symmetry's sake) was added.

The DS1 and DS3 MIBs are available for anonymous FTP at fennel.acc.com.

New internet drafts reflecting these changes will be sent to
the trunk-mib mailing list and posted in the internet-drafts
directories; when consensus is acheived on the mailing list, they will
be forwarded to the IESG for their review and approval as new RFCs
obsoleting RFC1232 and RFC1233.










Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa03580;
          28 Jul 92 13:15 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa03576;
          28 Jul 92 13:15 EDT
Received: from [129.192.64.25] by NRI.Reston.VA.US id aa18339;
          28 Jul 92 13:15 EDT
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA23062; Tue, 28 Jul 92 09:56:09 PDT
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA25686; Tue, 28 Jul 92 12:59:20 EDT
Return-Path: <tacox@sabre.bellcore.com>
Received: by ginsu4 (4.1/4.7)
	id AA03129; Tue, 28 Jul 92 12:43:34 EDT
Date: Tue, 28 Jul 92 12:43:34 EDT
From: Tracy Cox <tacox@sabre.bellcore.com>
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9207281643.AA03129@ginsu4>
To: mdavies@NRI.Reston.VA.US, trunk-mib@acc.com
Subject: Trunk-MIB WG Minutes

Megan and trunk-mibbers,

Here are the minutes from the trunk-mib
WG.

Tracy
===========================================
Tracy A. Cox
Bellcore
NVC 1C-354
331 Newman Springs Rd.
Red Bank, NJ  07701
tacox@sabre.bellcore.com email
(908) 758-2107 vmail
(908) 758-4177 fax
===========================================
The minutes of the Trunk-MIB Working Group

IETF Meeting 7/15/92
San Diego, CA

The decision of
the Working Group, per Bill Versteeg's suggestion, was to completely
obsolete RFC 1232 and RFC 1233, and remove all of the deprecated objects
from this document.  All tables have been given new names
and new OIDs.  The beginning delimiter for all objects
is dsx* (* = 1 or 3).  In addition, we added LESs to the
near end tables, changed all Counters remaining (current table) to Gauges,
and modified the dsx1LineCoding, dsx1LineStatus, dsx*SendCode Object
descriptions, and added a Signaling Mode object (DS1 MIB only).
We have an action item to resolve on whether to keep or remove
the BPVs count.

James Watt took an action item to supply appropriate text for the failure
states description. A description of Line Errored Seconds (which T1M1 has
available only from the far end, but we decided to include for the near end
for symmetry's sake) was added.

The DS1 and DS3 MIBs are available for anonymous FTP at fennel.acc.com.

New internet drafts reflecting these changes will be sent to
the trunk-mib mailing list and posted in the internet-drafts
directories; when consensus is acheived on the mailing list, they will
be forwarded to the IESG for their review and approval as new RFCs
obsoleting RFC1232 and RFC1233.










Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa05197;
          28 Jul 92 15:16 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa05192;
          28 Jul 92 15:16 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa23545;
          28 Jul 92 15:16 EDT
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA24351; Tue, 28 Jul 92 12:06:09 PDT
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA26448; Tue, 28 Jul 92 15:09:04 EDT
Return-Path: <tacox@sabre.bellcore.com>
Received: by ginsu4 (4.1/4.7)
	id AA03204; Tue, 28 Jul 92 14:53:19 EDT
Date: Tue, 28 Jul 92 14:53:19 EDT
From: Tracy Cox <tacox@sabre.bellcore.com>
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9207281853.AA03204@ginsu4>
To: clrcom!worf!khall@uunet.uu.net, trunk-mib@acc.com, 
    worf!musa@uunet.uu.net
Subject: re: DS1 MIB comments

Kurt,

Sorry that I have taken so long to answer you
questions on your DS1 comments.

Most of your comments have been accommodated
in the new version of the DS1 MIB.  Have
you seen that one?  It is dated July 15th and
can be obtained via anonymous ftp at fennel.acc.com
and cd into pub/trunk-mib and get DS1.mib and DS3.mib.

Please look it over and see if all of your
concerns have been answered.  The minutes
from the meeting have also been posted on
trunk-mib@acc.com.  I hope that you have
received them also.

The new draft should answer you comments except this one:
Page 21,
Say the CSU has a loopback to the DTE side, would this object
be set to ds1OtherLoop or ds1NoLoop?  Technically, the NI side
is not in a loopback state.

To answer this question, you first have to understand that the DS1
MIB manages DS1 interfaces and not CSUs.
Therefore, if the CSU has a loopback to the DTE side, then this
DS1 interface identified by
dsx1LineIndex dsx1IfIndex will have the dsx1LoopbackConfig
object equal to dsx1MgrPayloadLoop or dsx1MgrLineLoop depending
on what type of loopback it is.  The DS1 Loopback on the NI
side identified by dsx1LineIndex and dsx1IfIndex wil have
the dsx1LoopbackConfig object equal to dsx1NoLoop.
Each DS1 interface off of the CSU is managed and is identified
by a unique dsx1LineIndex.  See Section 5.1 for a description
of dsx1LineIndex and dsx1IfIndex.

I hope that this answers you questions.

If you have any more comments or suggestions please just ask.

Tracy










Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa01041;
          1 Aug 92 7:15 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa01037;
          1 Aug 92 7:15 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa06015; 1 Aug 92 7:16 EDT
Received: from uu3.psi.com by fennel.acc.com (4.1/SMI-4.1)
	id AA21190; Sat, 1 Aug 92 04:04:05 PDT
Received: by uu3.psi.com (5.65b/4.0.071791-PSI/PSINet)
	id AA27534; Sat, 1 Aug 92 07:03:42 -0400
Date: Fri, 31 Jul 92 16:39:12 EDT
From: Bill VerSteeg <bvs@ver.com>
Received: by veratl.ver.com (4.1/3.2.083191-VerSteeg CodeWorks)
	id AA00290; Fri, 31 Jul 92 16:39:12 EDT
Message-Id: <9207312039.AA00290@veratl.ver.com>
To: trunk-mib@acc.com
Subject: BPVs and LESs


I am no expert on this issue, so I went and asked a couple
of people who are well versed in this space.

The consensus was that Fred was on the right track. LESs
are prefferable to BPVs. LESs are easier to monitor, and they
are more usefull to the end user. They also thought that if
you had LESs, you did not need BPVs. 

However, the "T1 guys" that I polled
did not hold these views with religous fervor, and considered
the choice to be a relatively minor distinction. They indicated
that either way would be OK, and not to allow this to delay
the MIB.


Bill VerSteeg
bvs@ver.com










Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa01657;
          1 Aug 92 16:05 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id ab01653;
          1 Aug 92 16:05 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa16472; 1 Aug 92 16:06 EDT
Received: from saffron.acc.com by fennel.acc.com (4.1/SMI-4.1)
	id AA24202; Sat, 1 Aug 92 12:56:27 PDT
Received: by saffron.acc.com (4.1/SMI-4.1)
	id AA02047; Sat, 1 Aug 92 12:55:45 PDT
Date: Sat, 1 Aug 92 12:55:45 PDT
From: Fred Baker <fbaker@acc.com>
Message-Id: <9208011955.AA02047@saffron.acc.com>
To: trunk-mib@acc.com
Subject: table groups

I've been talking with some folks in the ISDN context about the DS1
MIB.  Seems to me like a reasonable thing to use in conjunction with a
primary rate line.  Maybe I'm out in left field... :^)

I'm getting a fair amount of resistance to asking a router to implement
"all those counters" in the router or ISDN host if they are *not*
managign the CSU, or if there is no CSU required.

My thought is to revisit our grouping; is it reasonable for the host or
router to *only* implement the configuration table?

Thinking out loud, wondering...

Fred










Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa09405;
          3 Aug 92 13:28 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa09400;
          3 Aug 92 13:28 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa06711; 3 Aug 92 13:28 EDT
Received: from vnet.ibm.com by fennel.acc.com (4.1/SMI-4.1)
	id AA05178; Mon, 3 Aug 92 10:15:28 PDT
Message-Id: <9208031715.AA05178@fennel.acc.com>
Received: from RALVM29 by vnet.ibm.com (IBM VM SMTP V2R2) with BSMTP id 9764;
   Mon, 03 Aug 92 13:13:04 EDT
Date: Mon, 3 Aug 92 13:14:29 EDT
From: "Laurence V. Marks" <lmarks@vnet.ibm.com>
To: FBAKER@acc.com, TRUNK-MIB@acc.com
Subject: table groups

Ref:  Your note of Sat, 1 Aug 92 12:55:45 PDT (attached)

Fred, my former project was both T-1 and ISDN-P.  The physical layers
are the same (except ISDN-P is supposed to always be ESF, never D4).

The terminology changes a little:

         +-------+       +----------+      +----------+
         |       |       |          |      |          |
         |       |       |          |      |          |
         |       |       |          |      |          |
         |       +-------+          +------+          +-------------
         |       |       |          |      |          |
         |       |       |          |      |          |
         |       |       |          |      |          |
         |       |       |          |      |          |
Term:    +-------+       +----------+      +----------+

T-1       DTE       *         DSU     DSX-1    CSU        DS-1
ISDN-P     TE       S         NT-2    T        NT-1       U

                    *= RS-422, V.35, etc.

ANSI T-1  Std.: T1.403
ANSI ISDN Std.: T1.408

I've been reviewing the MIB all along with a view toward mapping to
ISDN.  The major differences seem to be:

1) If the ISDN is channelized (23B+D / 30B+D), then the CRC and
   performance reporting terminate at the network boundary.

2) Maybe the MIB needs some additional counts for
   --Number of call attmepts
     --Successful
     --Failed
       --Busy
       --Congestion
       --Rejected
   --Number of abnormal terminations
   --Number of incoming calls rejected
     --Improper CLID
     --Invalid capability request
       --Bearer
       --High-level
       --Low-level
This is just a 30-second stab off the top of my head.  One should really
not attempt this without Q.921 and Q.931 balanced on one's lap.... :-)

Ta address your question, ISDN-P requires the same counter set (plus
more, possibly).  Whether there is a CSU, or it's 'under the covers'
is not pertinant; you still need the counters, don't you?

Larry
lmarks@vnet.ibm.com
----------------------------- Note follows ------------------------------
Received: from fennel.acc.com by vnet.ibm.com (IBM VM SMTP V2R2) with TCP;
   Sat, 01 Aug 92 15:57:47 EDT
Received: from saffron.acc.com by fennel.acc.com (4.1/SMI-4.1)
    id AA24202; Sat, 1 Aug 92 12:56:27 PDT
Received: by saffron.acc.com (4.1/SMI-4.1)
    id AA02047; Sat, 1 Aug 92 12:55:45 PDT
Date: Sat, 1 Aug 92 12:55:45 PDT
From: fbaker@acc.com (Fred Baker)
Message-Id: <9208011955.AA02047@saffron.acc.com>
To: trunk-mib@acc.com
Subject: table groups

I've been talking with some folks in the ISDN context about the DS1
MIB.  Seems to me like a reasonable thing to use in conjunction with a
primary rate line.  Maybe I'm out in left field... :^)

I'm getting a fair amount of resistance to asking a router to implement
"all those counters" in the router or ISDN host if they are *not*
managign the CSU, or if there is no CSU required.

My thought is to revisit our grouping; is it reasonable for the host or
router to *only* implement the configuration table?

Thinking out loud, wondering...

Fred










Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa14342;
          3 Aug 92 17:46 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa14338;
          3 Aug 92 17:46 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa18807; 3 Aug 92 17:46 EDT
Received: from nbkanata.Newbridge.COM (NEWBRIDGE.COM) by fennel.acc.com (4.1/SMI-4.1)
	id AA09690; Mon, 3 Aug 92 14:34:14 PDT
Received: from Newbridge.COM ([138.120.100.14]) by nbkanata.Newbridge.COM (4.1/SMI-4.1)
	id AA00266; Mon, 3 Aug 92 17:36:29 EDT
Received: by Newbridge.COM (4.0/SMI-4.0)
	id AA12449; Mon, 3 Aug 92 17:32:04 EDT
From: James Watt <james@newbridge.com>
Message-Id: <9208032132.AA12449@Newbridge.COM>
Subject: Re: table groups
To: Fred Baker <fbaker@acc.com>
Date: Mon, 3 Aug 92 17:32:04 EDT
Cc: trunk-mib@acc.com
In-Reply-To: <9208011955.AA02047@saffron.acc.com>; from "Fred Baker" at Aug 1, 92 12:55 pm
X-Mailer: ELM [version 2.3 PL8]

Fred:
  It seems reasonable for any box that only does a DSX-1 interface to leave the
performance monitoring to the CSU.  However, if there is a built in CSU 
interface, as a customer I would expect built in performance monitoring.  For
E1, you can't get at the CSU, so as a customer I would expect the box to do
the performance monitoring.  Of course, as a customer buying E1 equipment I 
would expect G.821-style statistics too :->.
  I would suggest that any box which _directly_ attaches to the network, 
_must_ include "all of those counters".  This would presumably include all
boxes with an E1 and boxes with a T1 CSU interface.  Boxes which have a CSU
between them and the network need only the configuration (and probably the 
fractional) table.  Routers proxying for a CSU would need "all the counters"
as well.
-james

ps
  Unfortunately, it turns out that some of counters are useful in diagnosing
initial setup problems, even for DSX interfaces.  However, I am willing to
let the market decide that one...










Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa02335;
          4 Aug 92 9:44 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa02331;
          4 Aug 92 9:44 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa09751; 4 Aug 92 9:44 EDT
Received: from vnet.ibm.com by fennel.acc.com (4.1/SMI-4.1)
	id AA27728; Tue, 4 Aug 92 06:32:31 PDT
Message-Id: <9208041332.AA27728@fennel.acc.com>
Received: from RALVM29 by vnet.ibm.com (IBM VM SMTP V2R2) with BSMTP id 3073;
   Tue, 04 Aug 92 09:29:54 EDT
Date: Tue, 4 Aug 92 09:23:59 EDT
From: "Laurence V. Marks" <lmarks@vnet.ibm.com>
To: JAMES@newbridge.com, FBAKER@acc.com
Cc: TRUNK-MIB@acc.com
Subject: table groups

Ref:  Your note of Mon, 3 Aug 92 17:32:04 EDT (attached)

James, I'm not sure I completely agree.  If a North American box has a
DSX-1 interface, either:
--Performance monitoring can be done in the box, with a the CSU doing
  only signal conditioning (cheap, dumb CSU).  My former project was
  like this.
--Performance monitoring can be done in the CSU (smart CSU), with an
  out-of-band proprietary link between box and CSU so the box can proxy
  for the CSU.  (This scheme must have developed because it was the
  easiest way to upgrade an installed system when the network changed
  from D4 to ESF.  The smart CSU immediately satisfied network
  requirements--management access could be added later.)

I reviewed the MIB with both viewpoints in mind, and concluded that it
was consistent in either case.  I don't believe that

>                     ...any box which _directly_ attaches to the network
> _must_ include "all of those counters".

I believe that one of the boxes between the management agent and the
Network Interface must contain all the counters, and make them
accessible to both sides, but it could be any one, e.g.,
--Combined CSU/DSU
--Smart CSU
--NCTE/DSU with dumb CSU

With regard to G.821 statistics, I thought G.821 referred to
international (cross-border) service only.

Laurence V. Marks
lmarks@vnet.ibm.com
(These are my opinions, not those of my employer.)










Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa04477;
          4 Aug 92 13:22 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id ab04473;
          4 Aug 92 13:22 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa20116; 4 Aug 92 13:21 EDT
Received: from nbkanata.Newbridge.COM (NEWBRIDGE.COM) by fennel.acc.com (4.1/SMI-4.1)
	id AA29133; Tue, 4 Aug 92 10:10:04 PDT
Received: from Newbridge.COM ([138.120.100.14]) by nbkanata.Newbridge.COM (4.1/SMI-4.1)
	id AA08712; Tue, 4 Aug 92 11:50:48 EDT
Received: by Newbridge.COM (4.0/SMI-4.0)
	id AA21146; Tue, 4 Aug 92 11:46:23 EDT
From: James Watt <james@newbridge.com>
Message-Id: <9208041546.AA21146@Newbridge.COM>
Subject: Re: table groups
To: "Laurence V. Marks" <lmarks@vnet.ibm.com>
Date: Tue, 4 Aug 92 11:46:22 EDT
Cc: trunk-mib@acc.com
In-Reply-To: <9208041332.AA27728@fennel.acc.com>; from "Laurence V. Marks" at Aug 4, 92 9:23 am
X-Mailer: ELM [version 2.3 PL8]

Laurence:
True enough. "One of" is a good way to express it.  The question is, does that
imply that all routers implementing the MIB _must_ implement all counters ?? 

  Wrt to G.821, the title and scope are in agreement with your belief.  However,
in the absence of a 54016-like equivalent for E1 links, more and more of our
customers have come to demand G.821-style statistics for E1 links.  The HRX and
allocations are not of interest, only the numbers...

-james
ps 
> 
> Ref:  Your note of Mon, 3 Aug 92 17:32:04 EDT (attached)
> 
> James, I'm not sure I completely agree.  If a North American box has a
> DSX-1 interface, either:
> --Performance monitoring can be done in the box, with a the CSU doing
>   only signal conditioning (cheap, dumb CSU).  My former project was
>   like this.
> --Performance monitoring can be done in the CSU (smart CSU), with an
>   out-of-band proprietary link between box and CSU so the box can proxy
>   for the CSU.  (This scheme must have developed because it was the
>   easiest way to upgrade an installed system when the network changed
>   from D4 to ESF.  The smart CSU immediately satisfied network
>   requirements--management access could be added later.)
> 
> I reviewed the MIB with both viewpoints in mind, and concluded that it
> was consistent in either case.  I don't believe that
> 
> >                     ...any box which _directly_ attaches to the network
> > _must_ include "all of those counters".
> 
> I believe that one of the boxes between the management agent and the
> Network Interface must contain all the counters, and make them
> accessible to both sides, but it could be any one, e.g.,
> --Combined CSU/DSU
> --Smart CSU
> --NCTE/DSU with dumb CSU
> 
> With regard to G.821 statistics, I thought G.821 referred to
> international (cross-border) service only.
> 
> Laurence V. Marks
> lmarks@vnet.ibm.com
> (These are my opinions, not those of my employer.)
> 











Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa10507;
          5 Aug 92 17:17 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa10502;
          5 Aug 92 17:17 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa00272; 5 Aug 92 17:17 EDT
Received: from vnet.ibm.com by fennel.acc.com (4.1/SMI-4.1)
	id AA27842; Wed, 5 Aug 92 14:02:54 PDT
Message-Id: <9208052102.AA27842@fennel.acc.com>
Received: from RALVM29 by vnet.ibm.com (IBM VM SMTP V2R2) with BSMTP id 2439;
   Wed, 05 Aug 92 17:00:22 EDT
Date: Wed, 5 Aug 92 17:02:13 EDT
From: "Laurence V. Marks" <lmarks@vnet.ibm.com>
To: JAMES@newbridge.com, LMARKS@vnet.ibm.com
Cc: TRUNK-MIB@acc.com
Subject: table groups

Ref:  Your note of Tue, 4 Aug 92 11:46:22 EDT

> True enough. "One of" is a good way to express it.  The question is, does that
> imply that all routers implementing the MIB _must_ implement all counters ??

It seems to me that the marketplace must be the arbiter.

One offering might have no intelligence in the DTE, and management in
the DSU/CSU, connected by an auxiliary port.

Another might have smart DSU function under the covers.

Yet another might have smart DSU and CSU under the covers.

The manufacturer (e.g., your employer and mine) make what we think the
customer wants.  The customer picks, and proves us right or wrong.
A customer whose needs management capability will pick a choice that
works--that is, "one of" his entities will have accessible counters.

I don't think the MIB should specify which entity implements the counter
set.  ANSI T1.408 shows that (for ISDN) performance report statistics
must be maintained in the CPE, on the customer side of the NI, but the
only place that hints at how you might partition it is Annex E which
is 'informative' (non-binding).

Laurence V. Marks










Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa05352;
          7 Aug 92 10:21 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa05348;
          7 Aug 92 10:21 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa13473; 7 Aug 92 10:22 EDT
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA04249; Fri, 7 Aug 92 07:14:14 PDT
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA05486; Fri, 7 Aug 92 09:18:07 EDT
Return-Path: <tacox@ginsu4@sabre.bellcore.com>
Received: from localhost by ginsu4 (4.1/4.7)
	id AA05061; Fri, 7 Aug 92 09:02:12 EDT
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9208071302.AA05061@ginsu4>
To: lmarks@vnet.ibm.com
Cc: FBAKER@acc.com, TRUNK-MIB@acc.com
Subject: Re: table groups 
In-Reply-To: Your message of "Mon, 03 Aug 92 13:14:29 EDT."
             <9208031715.AA05178@fennel.acc.com> 
Date: Fri, 07 Aug 92 09:02:12 -0400
From: tacox@ginsu4.bellcore.com

> 
> 
> Ref:  Your note of Sat, 1 Aug 92 12:55:45 PDT (attached)
> 
> Fred, my former project was both T-1 and ISDN-P.  The physical layers
> are the same (except ISDN-P is supposed to always be ESF, never D4).
> 
> The terminology changes a little:
> 
>          +-------+       +----------+      +----------+
>          |       |       |          |      |          |
>          |       |       |          |      |          |
>          |       |       |          |      |          |
>          |       +-------+          +------+          +-------------
>          |       |       |          |      |          |
>          |       |       |          |      |          |
>          |       |       |          |      |          |
>          |       |       |          |      |          |
> Term:    +-------+       +----------+      +----------+
> 
> T-1       DTE       *         DSU     DSX-1    CSU        DS-1
> ISDN-P     TE       S         NT-2    T        NT-1       U
> 
>                     *= RS-422, V.35, etc.
> 
> ANSI T-1  Std.: T1.403
> ANSI ISDN Std.: T1.408
> 
> I've been reviewing the MIB all along with a view toward mapping to
> ISDN.  The major differences seem to be:
> 
> 1) If the ISDN is channelized (23B+D / 30B+D), then the CRC and
>    performance reporting terminate at the network boundary.
> 
> 2) Maybe the MIB needs some additional counts for
>    --Number of call attmepts
>      --Successful
>      --Failed
>        --Busy
>        --Congestion
>        --Rejected
>    --Number of abnormal terminations
>    --Number of incoming calls rejected
>      --Improper CLID
>      --Invalid capability request
>        --Bearer
>        --High-level
>        --Low-level
> This is just a 30-second stab off the top of my head.  One should really
> not attempt this without Q.921 and Q.931 balanced on one's lap.... :-)
> 

These counters are not appropriate for a DS1 MIB, but for an ISDN
MIB -- isn't iplpdn working on an ISDN MIB?  The DS1 MIB is used only
to managed a device with a DS1 interface -- any device -- CSU, DSU,
mux, digital cross-connect, switch, router, bridge, workstation, .....
as long as the device has a DS1 interface it can use this MIB.

What portions of the MIB that the device supports is up to the implementor.
You are _supposed_ to implement whole groups, but ....
This means supporting the Near End group with Config and statistics and
optionally supporting the Far End group.

I suggest that we keep the MIB as is and finish it up -- any more comments
on either MIB before forwarding them to the IESG?

Tracy


> Ta address your question, ISDN-P requires the same counter set (plus
> more, possibly).  Whether there is a CSU, or it's 'under the covers'
> is not pertinant; you still need the counters, don't you?
> 
> Larry
> lmarks@vnet.ibm.com










Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa04297;
          11 Aug 92 12:40 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id ab04293;
          11 Aug 92 12:40 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa23266;
          11 Aug 92 12:40 EDT
Received: from vnet.ibm.com by fennel.acc.com (4.1/SMI-4.1)
	id AA14777; Tue, 11 Aug 92 09:20:30 PDT
Message-Id: <9208111620.AA14777@fennel.acc.com>
Received: from RALVM29 by vnet.ibm.com (IBM VM SMTP V2R2) with BSMTP id 1064;
   Tue, 11 Aug 92 12:17:00 EDT
Date: Tue, 11 Aug 92 11:47:28 EDT
From: "Laurence V. Marks" <lmarks@vnet.ibm.com>
To: TACOX@ginsu4.bellcore.com, LMARKS@vnet.ibm.com
Cc: FBAKER@acc.com, TRUNK-MIB@acc.com
Subject: table groups

Ref:  Your note of Fri, 07 Aug 92 09:02:12 -0400 (attached)

Tracy, my suggestion was not to overturn the ds1 MIB applecart.

Since the question was raised about relationship to ISDN-P, I responded.

When thinking about it, it really does seem that the right variables
for ISDN-P are the ds1 set plus some more.  (That's what was supposed to
be conveyed by my last paragraph.)

What I was wondering was whether the right way to actually construct
this is:
(1) A separate MIB is created with all this information.
(2) The ds1 MIB is utilized for physical layer errors; a separate RFC
    is written for the others.
(3) An optional table (like the Fractional Table) is added to the ds1
    MIB.

My earlier suggestion was (3)--I can see why you don't like it.
(1) seems to have a lot of redundant overlap with RFC1232.

Maybe option (2) is best--I haven't been following iplpdn.  If their
work is designed as supplemental to RFC1232, than this is the way to go.

Laurence V. Marks
----------------------------- Note follows ------------------------------
Received: from sabre.bellcore.com by vnet.ibm.com (IBM VM SMTP V2R2) with TCP;
   Fri, 07 Aug 92 09:13:36 EDT
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
    id AA05486; Fri, 7 Aug 92 09:18:07 EDT
Return-Path: <tacox@ginsu4@sabre.bellcore.com>
Received: from localhost by ginsu4 (4.1/4.7)
    id AA05061; Fri, 7 Aug 92 09:02:12 EDT
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9208071302.AA05061@ginsu4>
To: lmarks@vnet.ibm.com
Cc: FBAKER@acc.com, TRUNK-MIB@acc.com
Subject: Re: table groups
In-Reply-To: Your message of "Mon, 03 Aug 92 13:14:29 EDT."
             <9208031715.AA05178@fennel.acc.com>
Date: Fri, 07 Aug 92 09:02:12 -0400
From: tacox@ginsu4.bellcore.com

>
>
> Ref:  Your note of Sat, 1 Aug 92 12:55:45 PDT (attached)
>
> Fred, my former project was both T-1 and ISDN-P.  The physical layers
> are the same (except ISDN-P is supposed to always be ESF, never D4).
>
> The terminology changes a little:
>
>          +-------+       +----------+      +----------+
>          |       |       |          |      |          |
>          |       |       |          |      |          |
>          |       |       |          |      |          |
>          |       +-------+          +------+          +-------------
>          |       |       |          |      |          |
>          |       |       |          |      |          |
>          |       |       |          |      |          |
>          |       |       |          |      |          |
> Term:    +-------+       +----------+      +----------+
>
> T-1       DTE       *         DSU     DSX-1    CSU        DS-1
> ISDN-P     TE       S         NT-2    T        NT-1       U
>
>                     *= RS-422, V.35, etc.
>
> ANSI T-1  Std.: T1.403
> ANSI ISDN Std.: T1.408
>
> I've been reviewing the MIB all along with a view toward mapping to
> ISDN.  The major differences seem to be:
>
> 1) If the ISDN is channelized (23B+D / 30B+D), then the CRC and
>    performance reporting terminate at the network boundary.
>
> 2) Maybe the MIB needs some additional counts for
>    --Number of call attmepts
>      --Successful
>      --Failed
>        --Busy
>        --Congestion
>        --Rejected
>    --Number of abnormal terminations
>    --Number of incoming calls rejected
>      --Improper CLID
>      --Invalid capability request
>        --Bearer
>        --High-level
>        --Low-level
> This is just a 30-second stab off the top of my head.  One should really
> not attempt this without Q.921 and Q.931 balanced on one's lap.... :-)
>

These counters are not appropriate for a DS1 MIB, but for an ISDN
MIB -- isn't iplpdn working on an ISDN MIB?  The DS1 MIB is used only
to managed a device with a DS1 interface -- any device -- CSU, DSU,
mux, digital cross-connect, switch, router, bridge, workstation, .....
as long as the device has a DS1 interface it can use this MIB.

What portions of the MIB that the device supports is up to the implementor.
You are _supposed_ to implement whole groups, but ....
This means supporting the Near End group with Config and statistics and
optionally supporting the Far End group.

I suggest that we keep the MIB as is and finish it up -- any more comments
on either MIB before forwarding them to the IESG?

Tracy


> Ta address your question, ISDN-P requires the same counter set (plus
> more, possibly).  Whether there is a CSU, or it's 'under the covers'
> is not pertinant; you still need the counters, don't you?
>
> Larry
> lmarks@vnet.ibm.com










Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa03100;
          12 Aug 92 9:45 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id ab03096;
          12 Aug 92 9:45 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa06828; 12 Aug 92 9:46 EDT
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA10095; Wed, 12 Aug 92 06:34:21 PDT
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA08015; Wed, 12 Aug 92 09:37:02 EDT
Return-Path: <tacox@ginsu4@sabre.bellcore.com>
Received: from localhost by ginsu4 (4.1/4.7)
	id AA01773; Wed, 12 Aug 92 09:18:57 EDT
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9208121318.AA01773@ginsu4>
To: lmarks@vnet.ibm.com
Cc: FBAKER@acc.com, TRUNK-MIB@acc.com
Subject: Re: table groups 
In-Reply-To: Your message of "Tue, 11 Aug 92 11:47:28 EDT."
             <9208111622.AA19481@flash.bellcore.com> 
Date: Wed, 12 Aug 92 09:18:56 -0400
From: tacox@ginsu4.bellcore.com

Larry,

It seems that Fred and I both sent a message to the ISDN WG
mailing list -- which is:
imib@hobbit.netcs.com

Oliver Korfmacher responded to my question and said:

> My questions to your group are the following:
> How do you handle managing the DS1 layer for
> ISDN Primary Rate Interface devices?  Are you
> even aware of the work in the trunk-mib wg?
> I would suggest that you get a copy of the DS1 MIB --
> anonymous ftp at fennel.acc.com and cd into /pub/trunk-mib
> and get DS1.mib.
Oh thank you. Due to my moveing to Aschaffenburg, I'm not online, that
is a cause perhaps for any delays.

> Look this mib over to see if it suits your phy. layer
> needs for primary rate ISDN.  It is our hope that
> you can use parts of this MIB in its current form.
I will do so, and I agree that using parts of it is a good idea.
Fred Baker already purposed a similar thing.

Gruesse, Oliver

So it seems that option (2) is the best:

(2) The ds1 MIB is utilized for physical layer errors; a separate RFC
    is written for the others.

So on that note -- what is next?  Are we done?  Can Fred and I
recommend to Chuck Davin that we have reached consensus in the WG
on these MIBs?

Tracy










Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa03559;
          12 Aug 92 10:40 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa03555;
          12 Aug 92 10:40 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa08413;
          12 Aug 92 10:40 EDT
Received: from vnet.ibm.com by fennel.acc.com (4.1/SMI-4.1)
	id AA10525; Wed, 12 Aug 92 07:27:13 PDT
Message-Id: <9208121427.AA10525@fennel.acc.com>
Received: from RALVM29 by vnet.ibm.com (IBM VM SMTP V2R2) with BSMTP id 0479;
   Wed, 12 Aug 92 10:24:40 EDT
Date: Wed, 12 Aug 92 10:22:10 EDT
From: "Laurence V. Marks" <lmarks@vnet.ibm.com>
To: TACOX@ginsu4.bellcore.com
Cc: FBAKER@acc.com, TRUNK-MIB@acc.com
Subject: table groups

Ref:  Your note of Wed, 12 Aug 92 09:18:56 -0400 (attached)

Date: Wed, 12 Aug 92 09:18:56 -0400
From: tacox@ginsu4.bellcore.com

>  Larry,
>
>  So on that note -- what is next?  Are we done?  Can Fred and I
>  recommend to Chuck Davin that we have reached consensus in the WG
>  on these MIBs?
>
>  Tracy

Tracy,

Yes, we have reached consensus.

(It was never my intention to do other than assist in the development of
a ds-1 MIB.  But someone raised the ISDN question, and then someone else
raised the question of where the counters reside, and then...)

By all means, if the others are satisfied, let's advance.

Larry










Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id ab04448;
          12 Aug 92 11:30 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id ab04444;
          12 Aug 92 11:30 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa09435;
          12 Aug 92 11:31 EDT
Received: from saffron.acc.com by fennel.acc.com (4.1/SMI-4.1)
	id AA11389; Wed, 12 Aug 92 08:19:25 PDT
Received: by saffron.acc.com (4.1/SMI-4.1)
	id AA17967; Wed, 12 Aug 92 08:18:34 PDT
Date: Wed, 12 Aug 92 08:18:34 PDT
From: Fred Baker <fbaker@acc.com>
Message-Id: <9208121518.AA17967@saffron.acc.com>
To: lmarks@vnet.ibm.com
Subject: Re:  table groups
Cc: trunk-mib@fennel.acc.com

>> By all means, if the others are satisfied, let's advance.

Advance *after* I get all your comments edit in, right?   :^)

Fred










Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa14962;
          25 Aug 92 0:32 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa14958;
          25 Aug 92 0:32 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa05400; 25 Aug 92 0:33 EDT
Received: from uu3.psi.com by fennel.acc.com (4.1/SMI-4.1)
	id AA24924; Mon, 24 Aug 92 21:22:42 PDT
Received: by uu3.psi.com (5.65b/4.0.071791-PSI/PSINet)
	id AA26537; Tue, 25 Aug 92 00:22:20 -0400
Date: Mon, 24 Aug 92 18:52:08 EDT
From: Bill VerSteeg <bvs@ver.com>
Received: by veratl.ver.com (4.1/3.2.083191-VerSteeg CodeWorks)
	id AA06443; Mon, 24 Aug 92 18:52:08 EDT
Message-Id: <9208242252.AA06443@veratl.ver.com>
To: trunk-mib@acc.com
Subject: far end tables


As I implement the far end tables in the new MIB, I have a few
ruminations.

The primary index into the far end interval table
for a given CSU is the interval number of the desired datum.

As background, the mechanisms available to query the far end 
for information via 54016 are limited to-

1- "give me the last four 15 minute intervals of everything"

or

2- "give me all counters for interval X"

Furthermore, I am told that far end queries tend to be low-priority
events, and can take a number of seconds to complete.

So, as long as the SNMP requests come into the device "walk the MIB"
in lexicographical order, a great deal of caching may be done on the
near end when it is queried for far end data. However, if the
SNMP queries are ordered by value instead of interval (i.e. a manager
generates SNMP queries for "24 hours of SES data"), the agent will have
to generate an ENORMOUS amount of 54016 traffic to respnd to the request.

To take this point further, take the case of an agent with a very
simple (one deep) caching strategy, and two different managers. 
The agent will look to see if the response to his most
recent 54016 query contains the SNMP variable, and that is
is not stale.

SNMP manager 1 makes 96 queries in order to dump the 24
hour far-end table of an agent.  Each query asks for an interval's
worth of data. The agent with a simple caching strategy 
makes an individual 54016 query for each packet.
This is 96 queries, at about 5 seconds per query for 
a rough total of about 8 minutes to get the far end table.

SNMP manager 2 makes 48 queries in order to dump the 
24 hour far-end table of an agent. Each query asks for 12 intervals
worth of a particular variable. (I chose 12 variables 
because many SNMP managers limit their
packet sizes to quite small values. ) The agent with a simple
caching strategy makes an individual query for each variable
in each packet. 
This is (48 * 12 = 576) far-end queries, at about 5 seconds per query
for a rough total of about 48 minutes to get the far end table.
Also notice that each query will take about 1 minute to
complete. Most SNMP managers will time this request out
well before 1 minute.
Notice that this is significantly worse than getting the
table in lexicographical order.

In fact, if one was to dump the far end table in a brain-dead,
one variable at a time, snmpwalk fashion, the table would be walk
in a lexicographical order. The first reference to each
interval would generate a 54016 query. The next 5 queries
would hit the cache. The total time for this table
traversal would be about 9 minutes. The cache on the agent would make
the brain-dead walk perform much better than the "intelligent"
queries that ask for more than one data point in a way
that does not lend itself to query via 54016 primitives.

The problem with this situation is that most implementors of SNMP
managers will probably want to get the data on a per variable
basis, rather than a per interval basis. People like to look at
line graphs of variables, so applications tend to get data
in this fashion. 

I hope this note helps some manager implementors understand
the ramifications of how they access far end data.


Bill VerSteeg
bvs@ver.com













Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa03135;
          9 Sep 92 9:43 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa03131;
          9 Sep 92 9:43 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa08635; 9 Sep 92 9:46 EDT
Received: from saffron.acc.com by fennel.acc.com (4.1/SMI-4.1)
	id AA18429; Wed, 9 Sep 92 06:30:36 PDT
Received: from coral.com (gatekeeper.coral.com) by saffron.acc.com (4.1/SMI-4.1)
	id AA08911; Wed, 9 Sep 92 06:29:46 PDT
Received: from maui.coral.com by coral.com (4.1/SMI-4.1)
	id AA07499; Wed, 9 Sep 92 09:33:12 EDT
Received: by maui.coral.com (4.1/SMI-4.1)
	id AA29297; Wed, 9 Sep 92 09:36:53 EDT
Date: Wed, 9 Sep 92 09:36:53 EDT
From: Jason Perreault <jason@coral.com>
Message-Id: <9209091336.AA29297@maui.coral.com>
To: trunk-mib@acc.com
Subject: SNMP interface "layering"

I'm a newcomer to SNMP-based WAN mgmt, and in my LAN experience I haven't 
yet had to deal with "layering" of SNMP interfaces, so...
 
Regarding the example given in the DS1.mib draft for the DS1 Fractional
Group:
 
1. Could someone detail the ifDescr, ifType, ifMtu, ifSpeed, and 
   ifPhysAddress values for each interface in the example?

2. What are the implications for the implementation of the ifAdminStatus
   function at intermediate layers?

3. What might an example IP->FrameRelay->T1 "stack" look like, in terms
   of ifTable entries?

4. How does one track the "hierarchy" of layered interfaces, from network
   layer to the wire?

5. What other layerings are common?

[From DS1.mib]

>     -- the DS1 Fractional Group
>
>     -- Implementation of this group is mandatory for those
>     -- systems dividing a DS1 into channels containing different
>     -- data streams that are of local interest.  Systems which
>     -- are indifferent to data content, such as CSUs, need not
>     -- implement it.
>
>     -- The DS1 fractional table contains identifies which DS1
>     -- channels associated with a CSU are being used to support a
>     -- logical interface, i.e., an entry in the interfaces table
>     -- from the Internet-standard MIB.
>
>     -- For example, consider an application managing a North
>     -- American ISDN Primary Rate link whose division is a 384 KBPS
>     -- H1 "B" Channel for Video, a second H1 for data to a primary
>     -- routing peer, and 12 64 KBPS H0 "B" Channels. Consider that
>     -- some subset of the H0 channels are used for voice and the
>     -- remainder are available for dynamic data calls.
>
>     -- we count a total of 14 interfaces multiplexed onto the DS1
>     -- interface. Six DS1 channels (for the sake of the example,
>     -- channels 1..6) are used for Video, six more (7..11 and 13)
>     -- are used for data, and the remaining 12 are are in channels
>     -- 12 and 14..24.
>
>     -- Let us further imagine that ifIndex 2 is of type DS1 and
>     -- refers to the DS1 interface, and that the interfaces layered
>     -- onto it are numbered 3..16.
>
>     -- We might describe the allocation of channels, in the
>     -- dsx1FracTable, as follows:
>
>     -- dsx1FracIfIndex.2. 1 = 3    dsx1FracIfIndex.2.13 = 4
>     -- dsx1FracIfIndex.2. 2 = 3    dsx1FracIfIndex.2.14 = 6
>     -- dsx1FracIfIndex.2. 3 = 3    dsx1FracIfIndex.2.15 = 7
>     -- dsx1FracIfIndex.2. 4 = 3    dsx1FracIfIndex.2.16 = 8
>     -- dsx1FracIfIndex.2. 5 = 3    dsx1FracIfIndex.2.17 = 9
>     -- dsx1FracIfIndex.2. 6 = 3    dsx1FracIfIndex.2.18 = 10
>     -- dsx1FracIfIndex.2. 7 = 4    dsx1FracIfIndex.2.19 = 11
>     -- dsx1FracIfIndex.2. 8 = 4    dsx1FracIfIndex.2.20 = 12
>     -- dsx1FracIfIndex.2. 9 = 4    dsx1FracIfIndex.2.21 = 13
>     -- dsx1FracIfIndex.2.10 = 4    dsx1FracIfIndex.2.22 = 14
>     -- dsx1FracIfIndex.2.11 = 4    dsx1FracIfIndex.2.23 = 15
>     -- dsx1FracIfIndex.2.12 = 5    dsx1FracIfIndex.2.24 = 16
------------------------------------------------------
Jason Perreault           net   : jason@maui.coral.com
Coral Network Corp        voice : (508) 460-6010 x228
Marlborough MA 01752      fax   : (508) 481-6258












Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa05528;
          9 Sep 92 13:26 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa05524;
          9 Sep 92 13:26 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa01490; 9 Sep 92 13:29 EDT
Received: from saffron.acc.com by fennel.acc.com (4.1/SMI-4.1)
	id AA20980; Wed, 9 Sep 92 10:09:40 PDT
Received: by saffron.acc.com (4.1/SMI-4.1)
	id AA08999; Wed, 9 Sep 92 10:08:39 PDT
Date: Wed, 9 Sep 92 10:08:39 PDT
From: Fred Baker <fbaker@acc.com>
Message-Id: <9209091708.AA08999@saffron.acc.com>
To: jason@coral.com
Subject: Re:  SNMP interface "layering"
Cc: kzm@hls.com, trunk-mib@acc.com

>> I'm a newcomer to SNMP-based WAN mgmt, and in my LAN experience I haven't 
>> yet had to deal with "layering" of SNMP interfaces, so...
>>  
>> Regarding the example given in the DS1.mib draft for the DS1 Fractional
>> Group:
>>  
>> 1. Could someone detail the ifDescr, ifType, ifMtu, ifSpeed, and 
>>    ifPhysAddress values for each interface in the example?

:^)

I have copied Keith McCloghrie on this response; the fact is that I've
asked him the same question more than once, and I have to say that we
don't entirely agree.  The layering of interfaces is none-the-less the
architecture of SNMP below the network layer, and in this MIB I've
chosen to live with it.  (fact is, this table was originally written by
or under the direction of Marshall Rose; I couldn't figure out multiple
indices at the time, and he wrote it to show me how it was done).

To answer specifically,

	ifDescr is a description of the interface, a text string.  I
	would expect that "channel 79 of this DS1" might fly.

	ifMtu applies to the interface in question.  X.25 might take an
	MTU of 1600, break it up into 128 byte units (ifMtu of a LAPB
	interface), and send it on the circuit composed of an H1
	channel (384 KBPS in DS1 channels) taken out of the DS1
	interface.

	ifSpeed is <= n*64 KBPS, where n is the number of DS1 channels
	in use.

	ifPhysAddress is layer specific.  In X.25, it is an X.121
	address.  in LAPB, it is normally either 01 or 03.  It is
	probably a null string for DS1.

>> 2. What are the implications for the implementation of the ifAdminStatus
>>    function at intermediate layers?

	The implications of ifAdminStatus are the same as they are for
	more familiar interfaces.  If you turn off the DS1 underlying a
	LAPB interface, I suspect you will eventually experience a
	neighbor loss in LAPB and enter the NDM (Normal Disconnected
	Mode).

>> 3. What might an example IP->FrameRelay->T1 "stack" look like, in terms
>>    of ifTable entries?

		ip
	dlci dlci dlci dlci dlci dlci	    <== these have circuit tables,
						may or may not have ifEntries
		frame relay		    <== ifEntry
		ds1			    <== ifEntry
	
>> 4. How does one track the "hierarchy" of layered interfaces, from network
>>    layer to the wire?

	Frank Kastenholtz has suggested a MIB if this form, though he hasn't
	been prevailed upon to post it in Internet Drafts.

	ifStackTable
	  ifStackEntry [ifStackUpperIf, ifStackLowerIf]
	    ifStackUpperIf INTEGER  "the 'client' interface in a pair"
	    ifStackLowerIf INTEGER  "the 'service' interface in the pair."
	    ifStackStatus  INTEGER {valid(1),invalid(2)}

>> 5. What other layerings are common?

	Well, there are not a lot of them, but you might take a look at
	the X.25 suite of MIBs, which layer the packet layer onto LAPB
	onto something else...

>> [From DS1.mib]
>> 
>> >     -- the DS1 Fractional Group
>> >
>> >     -- Implementation of this group is mandatory for those
>> >     -- systems dividing a DS1 into channels containing different
>> >     -- data streams that are of local interest.  Systems which
>> >     -- are indifferent to data content, such as CSUs, need not
>> >     -- implement it.
>> >
>> >     -- The DS1 fractional table contains identifies which DS1
>> >     -- channels associated with a CSU are being used to support a
>> >     -- logical interface, i.e., an entry in the interfaces table
>> >     -- from the Internet-standard MIB.
>> >
>> >     -- For example, consider an application managing a North
>> >     -- American ISDN Primary Rate link whose division is a 384 KBPS
>> >     -- H1 "B" Channel for Video, a second H1 for data to a primary
>> >     -- routing peer, and 12 64 KBPS H0 "B" Channels. Consider that
>> >     -- some subset of the H0 channels are used for voice and the
>> >     -- remainder are available for dynamic data calls.
>> >
>> >     -- we count a total of 14 interfaces multiplexed onto the DS1
>> >     -- interface. Six DS1 channels (for the sake of the example,
>> >     -- channels 1..6) are used for Video, six more (7..11 and 13)
>> >     -- are used for data, and the remaining 12 are are in channels
>> >     -- 12 and 14..24.
>> >
>> >     -- Let us further imagine that ifIndex 2 is of type DS1 and
>> >     -- refers to the DS1 interface, and that the interfaces layered
>> >     -- onto it are numbered 3..16.
>> >
>> >     -- We might describe the allocation of channels, in the
>> >     -- dsx1FracTable, as follows:
>> >
>> >     -- dsx1FracIfIndex.2. 1 = 3    dsx1FracIfIndex.2.13 = 4
>> >     -- dsx1FracIfIndex.2. 2 = 3    dsx1FracIfIndex.2.14 = 6
>> >     -- dsx1FracIfIndex.2. 3 = 3    dsx1FracIfIndex.2.15 = 7
>> >     -- dsx1FracIfIndex.2. 4 = 3    dsx1FracIfIndex.2.16 = 8
>> >     -- dsx1FracIfIndex.2. 5 = 3    dsx1FracIfIndex.2.17 = 9
>> >     -- dsx1FracIfIndex.2. 6 = 3    dsx1FracIfIndex.2.18 = 10
>> >     -- dsx1FracIfIndex.2. 7 = 4    dsx1FracIfIndex.2.19 = 11
>> >     -- dsx1FracIfIndex.2. 8 = 4    dsx1FracIfIndex.2.20 = 12
>> >     -- dsx1FracIfIndex.2. 9 = 4    dsx1FracIfIndex.2.21 = 13
>> >     -- dsx1FracIfIndex.2.10 = 4    dsx1FracIfIndex.2.22 = 14
>> >     -- dsx1FracIfIndex.2.11 = 4    dsx1FracIfIndex.2.23 = 15
>> >     -- dsx1FracIfIndex.2.12 = 5    dsx1FracIfIndex.2.24 = 16
>> ------------------------------------------------------
>> Jason Perreault           net   : jason@maui.coral.com
>> Coral Network Corp        voice : (508) 460-6010 x228
>> Marlborough MA 01752      fax   : (508) 481-6258
>> 
>> 
>> 












Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa04040;
          23 Sep 92 10:31 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa04036;
          23 Sep 92 10:31 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa09283;
          23 Sep 92 10:35 EDT
Received: from saffron.acc.com by fennel.acc.com (4.1/SMI-4.1)
	id AA27283; Wed, 23 Sep 92 07:23:01 PDT
Received: from coral.com (gatekeeper.coral.com) by saffron.acc.com (4.1/SMI-4.1)
	id AA08104; Wed, 23 Sep 92 07:22:09 PDT
Received: from maui.coral.com by coral.com (4.1/SMI-4.1)
	id AA17099; Wed, 23 Sep 92 10:25:45 EDT
Received: by maui.coral.com (4.1/SMI-4.1)
	id AA12816; Wed, 23 Sep 92 10:31:55 EDT
Date: Wed, 23 Sep 92 10:31:55 EDT
Sender:ietf-archive-request@IETF.NRI.Reston.VA.US
From: Jason Perreault <jason@coral.com>
Message-Id: <9209231431.AA12816@maui.coral.com>
To: trunk-mib@acc.com
Subject: interval table


Is it implementation-specific as to whether an agents returns
interval table entries for intervals beyond that indicated by
dsx1ValidIntervals?










Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa15648;
          28 Sep 92 14:01 EDT
Received: from NRI.RESTON.VA.US by IETF.NRI.Reston.VA.US id aa15644;
          28 Sep 92 14:01 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa22688;
          28 Sep 92 14:06 EDT
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA11365; Mon, 28 Sep 92 08:35:16 PDT
Errors-To: fbaker@ginsu4.bellcore.com, debra@ginsu4.bellcore.com
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA05913; Mon, 28 Sep 92 10:00:26 EDT
Return-Path: <tacox@sabre.bellcore.com>
Received: by ginsu4 (4.1/4.7)
	id AA01247; Mon, 28 Sep 92 09:38:35 EDT
Date: Mon, 28 Sep 92 09:38:35 EDT
Sender:ietf-archive-request@IETF.NRI.Reston.VA.US
From: Tracy Cox <tacox@sabre.bellcore.com>
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9209281338.AA01247@ginsu4>
To: jason@coral.com, trunk-mib@acc.com
Subject: re: interval table

Jason,  

To answer your question:

Is it implementation-specific as to whether an agents returns
interval table entries for intervals beyond that indicated by
dsx1ValidIntervals?

I am not sure why you would want to do this?
Do you want to keep more than 96 previous 15-minute
intervals?  Are you worried that the number of intervals
and dsx1ValidIntervals will become out-of-sync at some
time?

Tracy










Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa03828;
          29 Sep 92 11:17 EDT
Received: from NRI.RESTON.VA.US by IETF.NRI.Reston.VA.US id aa03820;
          29 Sep 92 11:17 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa09176;
          29 Sep 92 11:22 EDT
Received: from saffron.acc.com by fennel.acc.com (4.1/SMI-4.1)
	id AA07935; Tue, 29 Sep 92 08:11:13 PDT
Received: from coral.com (gatekeeper.coral.com) by saffron.acc.com (4.1/SMI-4.1)
	id AA01062; Tue, 29 Sep 92 08:10:22 PDT
Received: from maui.coral.com by coral.com (4.1/SMI-4.1)
	id AA21906; Tue, 29 Sep 92 11:14:00 EDT
Received: by maui.coral.com (4.1/SMI-4.1)
	id AA04726; Tue, 29 Sep 92 11:21:15 EDT
Date: Tue, 29 Sep 92 11:21:15 EDT
Sender:ietf-archive-request@IETF.NRI.Reston.VA.US
From: Jason Perreault <jason@coral.com>
Message-Id: <9209291521.AA04726@maui.coral.com>
To: trunk-mib@acc.com
Subject: re: interval table

> Jason,  
>
> To answer your question:
>
>> Is it implementation-specific as to whether an agents returns
>> interval table entries for intervals beyond that indicated by
>> dsx1ValidIntervals?
>
> I am not sure why you would want to do this?
> Do you want to keep more than 96 previous 15-minute
> intervals?  Are you worried that the number of intervals
> and dsx1ValidIntervals will become out-of-sync at some
> time?
>
> Tracy


I just have in mind that a simple implementation might return objects
for 1 <= instance <= 96, without regard for the current value of
dsx1ValidIntervals.

I don't think the MIB contains any language to suggest that 
dsx1validIntervals < 96 implies that higher-instanced intervals
don't exist. Should it? 


------------------------------------------------------
Jason Perreault           net   : jason@maui.coral.com
Coral Network Corp        voice : (508) 460-6010 x228










Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa05482;
          29 Sep 92 12:41 EDT
Received: from NRI.RESTON.VA.US by IETF.NRI.Reston.VA.US id aa05478;
          29 Sep 92 12:41 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa11700;
          29 Sep 92 12:45 EDT
Received: from saffron.acc.com by fennel.acc.com (4.1/SMI-4.1)
	id AA08738; Tue, 29 Sep 92 09:33:35 PDT
Received: by saffron.acc.com (4.1/SMI-4.1)
	id AA01137; Tue, 29 Sep 92 09:32:39 PDT
Date: Tue, 29 Sep 92 09:32:39 PDT
Sender:ietf-archive-request@IETF.NRI.Reston.VA.US
From: Fred Baker <fbaker@acc.com>
Message-Id: <9209291632.AA01137@saffron.acc.com>
To: jason@coral.com
Subject: re: interval table
Cc: trunk-mib@acc.com

I don't see any substantive reason that it HAS to respond with those
entries; if it does, it is saying that they don't containing
meaningfull information.  As with the IP Route Table, whose entries may
have the status "invalid", and returning those entries in a
GET-RESPONSE is at the implementor's option, you can do it whichever
way works best in your implementation.

Fred










Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa10065;
          29 Sep 92 18:26 EDT
Received: from NRI.RESTON.VA.US by IETF.NRI.Reston.VA.US id aa10061;
          29 Sep 92 18:26 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa21455;
          29 Sep 92 18:31 EDT
Received: from saffron.acc.com by fennel.acc.com (4.1/SMI-4.1)
	id AA13124; Tue, 29 Sep 92 15:16:15 PDT
Received: from coral.com (gatekeeper.coral.com) by saffron.acc.com (4.1/SMI-4.1)
	id AA01281; Tue, 29 Sep 92 15:15:21 PDT
Received: from maui.coral.com by coral.com (4.1/SMI-4.1)
	id AA22274; Tue, 29 Sep 92 18:18:59 EDT
Received: by maui.coral.com (4.1/SMI-4.1)
	id AA05316; Tue, 29 Sep 92 18:26:16 EDT
Date: Tue, 29 Sep 92 18:26:16 EDT
Sender:ietf-archive-request@IETF.NRI.Reston.VA.US
From: Jason Perreault <jason@coral.com>
Message-Id: <9209292226.AA05316@maui.coral.com>
To: trunk-mib@acc.com
Subject: dsx1LineIndex even-odd assignments


I don't know whether this has already been noticed in DS1.mib:

>     A shelf full of CSUs connected to a Router. An SNMP Agent
>     residing on the router proxies for itself and the CSU. The
>     router has also an Ethernet interface:
>           :
>           :
>     The assignment of the index values could for example be:
>     ifIndex (= dsx1IfIndex)                  dsx1LineIndex
>     1                   NA                  NA (Ethernet)
>     2      Line#A   Router Side             7
>     2      Line#A   Network Side            6
>     3      Line#B   Router Side             9
>     3      Line#B   Network Side            8
>     4      Line#C   Router Side            11
>     4      Line#C   Network Side           10
>     5      Line#D   Router Side            13
>     5      Line#D   Network Side           12
>
>     ...number the dsx1LineIndices with an unique
>     identifier following the rules of choosing a number greater
>     than ifNumber and numbering [equipment-side] interfaces ...
>                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>     with even numbers and [network-side] interfaces ...
>     ^^^^^^^^^^^^^^^^^     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>     with odd numbers.
>     ^^^^^^^^^^^^^^^^

The example dsx1LineIndex assignments shown above conflict with
the even-odd convention described in the text.
------------------------------------------------------
Jason Perreault           net   : jason@maui.coral.com
Coral Network Corp        voice : (508) 460-6010 x228










Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa10556;
          29 Sep 92 19:31 EDT
Received: from NRI.RESTON.VA.US by IETF.NRI.Reston.VA.US id aa10551;
          29 Sep 92 19:31 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa22605;
          29 Sep 92 19:35 EDT
Received: from saffron.acc.com by fennel.acc.com (4.1/SMI-4.1)
	id AA13634; Tue, 29 Sep 92 16:24:47 PDT
Received: from coral.com (gatekeeper.coral.com) by saffron.acc.com (4.1/SMI-4.1)
	id AA02930; Tue, 29 Sep 92 16:23:54 PDT
Received: from maui.coral.com by coral.com (4.1/SMI-4.1)
	id AA22322; Tue, 29 Sep 92 19:27:32 EDT
Received: by maui.coral.com (4.1/SMI-4.1)
	id AA05438; Tue, 29 Sep 92 19:34:50 EDT
Date: Tue, 29 Sep 92 19:34:50 EDT
Sender:ietf-archive-request@IETF.NRI.Reston.VA.US
From: Jason Perreault <jason@coral.com>
Message-Id: <9209292334.AA05438@maui.coral.com>
To: trunk-mib@acc.com
Subject: ifEntries for DLCIs

   A while back I asked the following question, and received Fred 
   Baker's kind reply:


   >> 3. What might an example IP->FrameRelay->T1 "stack" look like, in terms
   >>    of ifTable entries?
   >
   >		ip
   >	dlci dlci dlci dlci dlci dlci	    <== these have circuit tables,
   >                                        may or may not have ifEntries
   >     frame relay                    <== ifEntry
   >     ds1                            <== ifEntry
	
   Now I'll ask:
     Under what circumstances might one want to enumerate DLCIs as 
     distinct entries in ifTable?

   And I'll venture one answer:
      To associate IP addresses with DLCIs via ipAddrTable?

   Is this a good answer? Are there others?

   Thanks for any leading suggestions...

  (I'm continuing on this list because this line of questioning
   arose with regard to the DS1 mib and layered interfaces implied
   by the DS1 Fractional Table -- but is it more appropriate to
   direct frame relay questions to iplpdn?)
------------------------------------------------------
Jason Perreault           net   : jason@maui.coral.com
Coral Network Corp        voice : (508) 460-6010 x228










Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa10688;
          29 Sep 92 20:01 EDT
Received: from NRI.RESTON.VA.US by IETF.NRI.Reston.VA.US id aa10684;
          29 Sep 92 20:01 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa22995;
          29 Sep 92 20:05 EDT
Received: from saffron.acc.com by fennel.acc.com (4.1/SMI-4.1)
	id AA14334; Tue, 29 Sep 92 16:54:40 PDT
Received: by saffron.acc.com (4.1/SMI-4.1)
	id AA03910; Tue, 29 Sep 92 16:53:45 PDT
Date: Tue, 29 Sep 92 16:53:45 PDT
Sender:ietf-archive-request@IETF.NRI.Reston.VA.US
From: Fred Baker <fbaker@acc.com>
Message-Id: <9209292353.AA03910@saffron.acc.com>
To: jason@coral.com
Subject: Re:  ifEntries for DLCIs
Cc: trunk-mib@acc.com

>>      Under what circumstances might one want to enumerate DLCIs as 
>>      distinct entries in ifTable?
>> 
>>    And I'll venture one answer:
>>       To associate IP addresses with DLCIs via ipAddrTable?
>> 
>>    Is this a good answer? Are there others?

I'm not sure why DLCIs are being discussed on this list...

The structure of the FR MIB targets IP support, just as IP support is
handled in X.25; the X.25 packet (or frame relay physical interface)
gets an IP Address, and the circuits over it all use that address.
Between Inverse ARP and the ability to support multiple subnets on an
interface, there is really no problem for addressed links even in a
sparse installation.

The issue is when one wants to treat DLCIs as *unnumbered* links.  The
rest of the MIB (by which I mean RFC 1213) doesn't handle unnumbered
links very gracefully, and in the OSPF MIB I put in a reference via
either IP Address *or* ifIndex, since OSPF is the one standard routing
protocol that admits to their existence.  ifIndex becomes the only way
you can identify the OSPF Interface Entry associated with an FR DLCI.
And when SVCs are implemented, anyone whose architecture depends on
treating the SVC as a static object that might get, for example, and
OSPF interface associated with it will be in deep pucky.

Fred










Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa02746;
          30 Sep 92 9:14 EDT
Received: from NRI.RESTON.VA.US by IETF.NRI.Reston.VA.US id aa02741;
          30 Sep 92 9:14 EDT
Received: from FENNEL.ACC.COM by NRI.Reston.VA.US id aa06752; 30 Sep 92 9:18 EDT
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1)
	id AA04266; Wed, 30 Sep 92 06:07:04 PDT
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C)
	id AA17531; Wed, 30 Sep 92 09:09:50 EDT
Return-Path: <tacox@ginsu4@sabre.bellcore.com>
Received: from localhost by ginsu4 (4.1/4.7)
	id AA00307; Wed, 30 Sep 92 09:03:42 EDT
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9209301303.AA00307@ginsu4>
To: Jason Perreault <jason@coral.com>
Cc: trunk-mib@acc.com
Subject: Re: dsx1LineIndex even-odd assignments 
In-Reply-To: Your message of "Tue, 29 Sep 92 18:26:16 EDT."
             <9209292226.AA05316@maui.coral.com> 
Date: Wed, 30 Sep 92 09:03:34 -0400
Sender:ietf-archive-request@IETF.NRI.Reston.VA.US
From: tacox@ginsu4.bellcore.com

OOOOOOPPPPPSS --
I think that was my fault -- it is wrong in the DS3 MIB too.

I will just reverse it --

equipment side interfaces -- odd numbers
network side interfaces -- even numbers

instead of changing the numbers  --
it is in two places -- Section 5.1 text as described in the
email and
in the description clause of dsx1LineIndex.

Thanks for the thorough review!!!

Tracy

===========================================
Tracy A. Cox
Bellcore
NVC 1C-354
331 Newman Springs Rd.
Red Bank, NJ  07701
tacox@sabre.bellcore.com email
(908) 758-2107 vmail
(908) 758-4177 fax
===========================================