Internet Draft DS1 Interface OBJECTS November 1990 Definitions of Managed Objects for the DS1 Interface Type Mon Oct 29 16:38:34 1990 Transmission MIB Working Group Editors: F. Baker Advanced Computer Communications, Inc. fbaker@acc.com C. Kolb Performance Systems International, Inc. Kolb@PSI.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 DS1 Interface objects. Note to implementors: a companion document describes DS3 Managed Objects; implementors looking at this one should also reference that. This memo does not specify a standard for the Internet community. F. Baker and C. Kolb (editors) [Page 1] Internet Draft DS1 Interface OBJECTS November 1990 3. Historical Perspective As reported in RFC 1052, IAB Recommendations for the Development of Internet Network Management Standards [1], a two-prong strategy for network management of TCP/IP-based internets was undertaken. In the short-term, the Simple Network Management Protocol (SNMP), defined in RFC 1067, was to be used to manage nodes in the Internet community. In the long-term, the use of the OSI network management framework was to be examined. Two documents were produced to define the management information: RFC 1065, which defined the Structure of Management Information (SMI), and RFC 1066, which defined the Management Information Base (MIB). Both of these documents were designed so as to be compatible with both the SNMP and the OSI network management framework. This strategy was quite successful in the short-term: Internet-based network management technology was fielded, by both the research and commercial communities, within a few months. As a result of this, portions of the Internet community became network manageable in a timely fashion. As reported in RFC 1109, Report of the Second Ad Hoc Network Management Review Group [2], the requirements of the SNMP and the OSI network management frameworks were more different than anticipated. As such, the requirement for compatibility between the SMI/MIB and both frameworks was suspended. This action permitted the operational network management framework, based on the SNMP, to respond to new operational needs in the Internet community by producing MIB-II. In May of 1990, the core documents were elevated to "Standard Protocols" with "Recommended" status. As such, the Internet- standard network management framework consists of: Structure and Identification of Management Information for TCP/IP-based internets, RFC 1155 [3], which describes how managed objects contained in the MIB are defined; Management Information Base for Network Management of TCP/IP-based internets, which describes the managed objects contained in the MIB, RFC 1156 [4]; and, the Simple Network Management Protocol, RFC 1157 [5], which defines the protocol used to manage these objects. Consistent with the IAB directive to produce simple, workable systems in the short-term, the list of managed objects defined in the Internet-standard MIB was derived by taking only those F. Baker and C. Kolb (editors) [Page 2] Internet Draft DS1 Interface OBJECTS November 1990 elements which are considered essential. However, the SMI defined three extensibility mechanisms: one, the addition of new standard objects through the definitions of new versions of the MIB; two, the addition of widely-available but non- standard objects through the experimental subtree; and three, the addition of private objects through the enterprises subtree. Such additional objects can not only be used for vendor-specific elements, but also for experimentation as required to further the knowledge of which other objects are essential. This memo defines extensions to the MIB using the second method. It contains definitions of managed objects used for experimentation. F. Baker and C. Kolb (editors) [Page 3] Internet Draft DS1 Interface OBJECTS November 1990 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 [13, 14]. F. Baker and C. Kolb (editors) [Page 4] Internet Draft DS1 Interface OBJECTS November 1990 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: t1-carrier(18) cept(19) The definitions contained herein are based on the AT&T T-1 specifications and Extended Superframe Format (ESF) [9, 10], the latter of which conforms to ANSI and proposed international specifications [15, 16]. 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 Interfaces and CSUs It should be noted that it is possible to multiplex multiple bit streams onto a single DS1 physical interface (CSU), realizing multiple interfaces from the perspective of the Internet-standard MIB. It is also possible to concatenate physical interfaces to provide a single logical interface. As such, it is important to be able to distinguish between the indices used to identify the CSUs attached to a node and the indices used to identify an interface (in the MIB sense) attached to a node. Each agent which resides on a host which uses DS1 physical interfaces is required to assign a small, non-negative integer uniquely to each CSU. This is known as the "CSUIndex", and is used to distinguish between different CSUs attached to a node. The CSUIndex is also used as the `key' when accessing tabular information about DS1 physical interfaces. The potentially many-to-one binding between CSU indices and the ifIndex value assigned to each MIB interface are defined in the ds1ConfigTable table defined in the next section. F. Baker and C. Kolb (editors) [Page 5] Internet Draft DS1 Interface OBJECTS November 1990 5.2. Objectives of this MIB Module There are numerous things that could be included in a MIB for DS1 Interfaces: the management of multiplexors, CSUs, DSUs, and the like. The intent of this document is to facilitate the common management 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, which is to say ESF CSUs conforming to AT&T specifications. However, by simple generalization of these objects, the MIB is also made applicable to D4 and G.704 devices. To meet a requirement not easily satisfied in other places, There is one additional group present, the Fractional DS1 group. This is intended to facilitate the use of fractional DS1 devices (ie, devices which utilize a subset of the 8 bit channels available in the frame) over the managed CSUs. 5.3. DS1 Terminology The terminology used in this document to describe error conditions on a T1 or E1 circuit monitored by a CSU are from the AT&T Technical Reference [11]. Out of Frame event An Out of Frame event is declared when the receiver detects two or more framing-bit errors within a 3 millisecond period, or two or more errors out of five or less 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 state ends when reframe occurs. Loss of Signal This event is declared upon observing 175 +/- 75 contiguous pulse positions with no pulses of either positive or negative polarity (also called keep alive). Code Violation Error Event A Code Violation Error Event is the occurrence of a received Cyclic Redundancy Check code that is not identical to the corresponding locally-calculated code. F. Baker and C. Kolb (editors) [Page 6] Internet Draft DS1 Interface OBJECTS November 1990 Bipolar Violation A Bipolar Violation, for B8ZS-coded signals, is the occurrence of a received bipolar violation that is not part of a zero-substitution code. It also includes other error patterns such as: eight or more consecutive zeros and incorrect parity. Errored Seconds An Errored Second is a second with one or more Code Violation Error Events OR one or more Out of Frame events. In D4 and G.704 section 2.1.3.2 (eg, G.704 which does not implement the CRC), the presence of Bipolar Violations also triggers an Errored Second. Bursty Errored Seconds A Bursty Errored Second is a second with more than one and less that 320 Code Violation Error Events. Note that this value is not defined if the DS1 Line type is ds1D4 or ds1G704. Severely Errored Seconds A Severely Errored Second is a second with 320 or more Code Violation Error Events OR one or more Out of Frame events. Severely Errored Framing Second An Severely Errored Framing Second is a second with one or more Out of Frame events. Unavailable Signal State This state is declared at the onset of 10 consecutive Severely Errored Seconds. It is cleared at the onset of 10 consecutive seconds with no Severely Errored Second. Unavailable Seconds Unavailable Seconds are calculated by counting the number of seconds that the CSU is in the Unavailable Signal State, 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 Unavailable Second may not be counted as an Errored Second, a Bursty Errored Second, or a Severely Errored Second. Since the 10 Severely Errored Seconds that comprise the transition from the available to Unavailable F. Baker and C. Kolb (editors) [Page 7] Internet Draft DS1 Interface OBJECTS November 1990 Signal State may also be counted as Errored Seconds, Bursty Errored Seconds, and Severely Errored Seconds 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 Errored Seconds or Bursty Errored Seconds. 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 ds1IntervalSES and ds1IntervalUAS 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 deployed AT&T objects as a basis for this memo. Yellow Alarm A Yellow Alarm is declared because of an incoming Yellow Signal from the far-end. In effect, the circuit is declared to be a one way link. Red Alarm A Red Alarm is declared because of an incoming Loss of Signal, Loss of Framing, Alarm Indication Signal. After a Red Alarm is declared, the device sends a Yellow Signal to the far-end. The far-end, when receives the Yellow Signal, declares a Yellow Alarm. 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 and C. Kolb (editors) [Page 8] Internet Draft DS1 Interface OBJECTS November 1990 6. Definitions RFCxxxx-MIB DEFINITIONS ::= BEGIN IMPORTS experimental, Counter FROM RFC1155-SMI DisplayString FROM RFC1158-MIB OBJECT-TYPE FROM RFC-oooo TRAP-TYPE FROM RFC-tttt; -- This MIB module uses the extended OBJECT-TYPE macro as -- defined in [13], and the TRAP-TYPE macro as defined in [14] -- this is the MIB module for ds1-interface objects ds1-interface OBJECT IDENTIFIER ::= { experimental 2 } F. Baker and C. Kolb (editors) [Page 9] Internet Draft DS1 Interface OBJECTS November 1990 -- the DS1 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 ds1-interface. ds1ConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF DS1ConfigEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The DS1 Configuration table." ::= { ds1-interface 1 } ds1ConfigEntry OBJECT-TYPE SYNTAX DS1ConfigEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "An entry in the DS1 Configuration table." INDEX { ds1CSUIndex } ::= { ds1ConfigTable 1 } DS1ConfigEntry ::= SEQUENCE { ds1CSUIndex INTEGER, ds1Index INTEGER, ds1TimeElapsed INTEGER (0..899), ds1ValidIntervals INTEGER (0..96), ds1LineType INTEGER, ds1ZeroCoding INTEGER, ds1Loopback INTEGER, ds1SendCode F. Baker and C. Kolb (editors) [Page 10] Internet Draft DS1 Interface OBJECTS November 1990 INTEGER, ds1RecvCode INTEGER, ds1YellowAlarm INTEGER, ds1RedAlarm INTEGER, ds1CircuitIdentifier DisplayString (SIZE (0..255)) } ds1CSUIndex OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The index value which uniquely identifies the CSU to which this entry is applicable." ::= { ds1ConfigEntry 1 } ds1Index OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "An index value that uniquely identifies an interface to a ds1-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." ::= { ds1ConfigEntry 2 } ds1TimeElapsed OBJECT-TYPE SYNTAX INTEGER (0..899) ACCESS read-only STATUS mandatory DESCRIPTION "The number of 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 F. Baker and C. Kolb (editors) [Page 11] Internet Draft DS1 Interface OBJECTS November 1990 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." ::= { 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 ds1D4 AT&T D4 format DS1 ds1ANSI-ESF ANSI Extended SuperFrame format ds1G704 CCITT Recommendation G.704 (section 2.1.3.2) ds1G704-CRC CCITT Recommendation G.704 (section 2.1.3.1) " ::= { ds1ConfigEntry 5 } ds1ZeroCoding OBJECT-TYPE SYNTAX INTEGER { ds1JammedBit(1), ds1B8ZS(2), ds1InvertedHDLC(3), F. Baker and C. Kolb (editors) [Page 12] Internet Draft DS1 Interface OBJECTS November 1990 ds1HDB3(4), ds1ZBTSI(5) } 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. 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. F. Baker and C. Kolb (editors) [Page 13] Internet Draft DS1 Interface OBJECTS November 1990 ANSI Clear Channels may use ds1ZBTSI, or Zero Byte Time Slot Interchange. G.704 links, with or without CRC, use ds1HDB3. " ::= { ds1ConfigEntry 6 } ds1Loopback OBJECT-TYPE SYNTAX INTEGER { ds1NoLoop(1), ds1DTELoopback(2), ds1NetLoopback(3) } ACCESS read-only STATUS mandatory DESCRIPTION "This variable represents the loopback state of the CSU." ::= { ds1ConfigEntry 7 } ds1SendCode OBJECT-TYPE SYNTAX INTEGER { other(1), ds1SendNoCode(2), ds1SendSetCode(3), ds1SendResetCode(4), ds1SendQRSS(5) } ACCESS read-only STATUS mandatory DESCRIPTION "This variable indicates what type of code is being sent across the DS1 circuit by the CSU. The values mean: ds1SendNoCode sending looped or straight data ds1SendSetCode sending a loopback request ds1SendResetCode sending a loopback termination request ds1SendQRSS sending a certain quasi-random BERT patt ern other sending a different BERT/BLERT pattern, such as all zeroes, all ones, etc." ::= { ds1ConfigEntry 8 } ds1RecvCode OBJECT-TYPE SYNTAX INTEGER { other(1), F. Baker and C. Kolb (editors) [Page 14] Internet Draft DS1 Interface OBJECTS November 1990 ds1RecvNoCode(2), ds1RecvSetCode(3), ds1RecvResetCode(4), ds1RecvQRSS(5) } ACCESS read-only STATUS mandatory DESCRIPTION "This variable indicates what type of code is being received from the DS1 circuit by the CSU. ds1RecvNoCode receiving looped or straight data ds1RecvSetCode receiving a loopback request ds1RecvResetCode receiving a loopback termination request ds1RecvQRSS receiving a certain quasi-random BERT pa ttern other receiving a different BERT/BLERT pattern , such as all zeroes, all ones, etc." ::= { ds1ConfigEntry 9 } ds1YellowAlarm OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "This variable indicates if a Yellow Alarm condition exists. A value of zero indicates that a Yellow Alarm condition does not exist. A non- zero value indicates that it does. Note that G.704 interfaces do not support Yellow Alarms. Accordingly, some agents may treat this object as having an ACCESS clause value of not- accessible." ::= { ds1ConfigEntry 10 } ds1RedAlarm OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "This variable indicates if a Red Alarm condition exists. A value of zero indicates that a Red Alarm condition does not exist. A non-zero value indicates that it does. F. Baker and C. Kolb (editors) [Page 15] Internet Draft DS1 Interface OBJECTS November 1990 Note that G.704 interfaces do not support Red Alarms. Accordingly, some agents may treat this object as having an ACCESS clause value of not- accessible." ::= { ds1ConfigEntry 11 } 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 12 } F. Baker and C. Kolb (editors) [Page 16] Internet Draft DS1 Interface OBJECTS November 1990 -- the DS1 Interval group -- Implementation of this group is mandatory for all systems -- that attach to a ds1-interface. -- It is recognized that some currently deployed CSUs do not -- record the entire set of statistics specified in this -- group. Accordingly, some agents queried for these objects -- may treat these objects as having an ACCESS clause value -- of not-accessible. -- The DS1 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. ds1IntervalTable OBJECT-TYPE SYNTAX SEQUENCE OF DS1IntervalEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The DS1 Interval table." ::= { ds1-interface 2 } ds1IntervalEntry OBJECT-TYPE SYNTAX DS1IntervalEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "An entry in the DS1 Interval table." INDEX { ds1IntervalIndex, ds1IntervalNumber } ::= { ds1IntervalTable 1 } DS1IntervalEntry ::= SEQUENCE { ds1IntervalIndex INTEGER, ds1IntervalNumber INTEGER (0..96), ds1IntervalESs Counter, ds1IntervalBESs Counter, ds1IntervalSESs F. Baker and C. Kolb (editors) [Page 17] Internet Draft DS1 Interface OBJECTS November 1990 Counter, ds1IntervalSEFSs Counter, ds1IntervalUASs Counter, ds1IntervalCSSs Counter, ds1IntervalBPVs Counter, ds1IntervalCVs Counter } ds1IntervalIndex OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The index value which uniquely identifies the CSU 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 ds1CSUIndex object instance." ::= { ds1IntervalEntry 1 } ds1IntervalNumber 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 minute interval (assuming that all 96 intervals are valid)." ::= { ds1IntervalEntry 2 } ds1IntervalESs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The counter associated with the number of Errored Seconds, as defined by ANSI Draft Standard T1M1.3/90 - 027R2[16], encountered by a DS1 CSU during one of the previous 96 fifteen minute F. Baker and C. Kolb (editors) [Page 18] Internet Draft DS1 Interface OBJECTS November 1990 intervals." ::= { ds1IntervalEntry 3 } ds1IntervalBESs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The counter associated with the number of Bursty Errored Seconds encountered by a DS1 CSU during one of the previous 96 fifteen minute intervals. Note that D4 and G.704 (section 2.1.3.2) interfaces do not support Bursty Errored Seconds, as they do not define Code Violation Errors. Accordingly, such agents may treat this object as having an ACCESS clause value of not-accessible." ::= { ds1IntervalEntry 4 } ds1IntervalSESs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The counter associated with the number of Severely Errored Seconds, as defined by ANSI Draft Standard T1M1.3/90 - 027R2[16], encountered by a DS1 CSU during one of the previous 96 fifteen minute intervals." ::= { ds1IntervalEntry 5 } ds1IntervalSEFSs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The counter associated with the number of Severely Errored Framing Seconds, as defined by ANSI Draft Standard T1M1.3/90 - 027R2[16], encountered by a DS1 CSU during one of the previous 96 fifteen minute intervals." ::= { ds1IntervalEntry 6 } ds1IntervalUASs OBJECT-TYPE SYNTAX Counter F. Baker and C. Kolb (editors) [Page 19] Internet Draft DS1 Interface OBJECTS November 1990 ACCESS read-only STATUS mandatory DESCRIPTION "The counter associated with the number of Unavailable Seconds, as defined by ANSI Draft Standard T1M1.3/90 - 027R2[16], encountered by a DS1 CSU during one of the previous 96 fifteen minute intervals." ::= { ds1IntervalEntry 7 } ds1IntervalCSSs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The counter associated with the number of Controlled Slip Seconds, as defined by ANSI Draft Standard T1M1.3/90 - 027R2[16], encountered by a DS1 CSU during one of the previous 96 fifteen minute intervals." ::= { ds1IntervalEntry 8 } ds1IntervalBPVs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The counter associated with the number of Bipolar Violations, as defined by ANSI Draft Standard T1M1.3/90 - 027R2[16], encountered by a DS1 CSU during one of the previous 96 fifteen minute intervals." ::= { ds1IntervalEntry 9 } ds1IntervalCVs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The counter associated with the number of Code Violation Error Events, as defined by ANSI Draft Standard T1M1.3/90 - 027R2[16], encountered by a DS1 CSU during one of the previous 96 fifteen minute intervals. F. Baker and C. Kolb (editors) [Page 20] Internet Draft DS1 Interface OBJECTS November 1990 Note that D4 and G.704 (section 2.1.3.2) interfaces do not support Code Violation Error Events. Accordingly, such agents may treat this object as having an ACCESS clause value of not- accessible." ::= { ds1IntervalEntry 10 } F. Baker and C. Kolb (editors) [Page 21] Internet Draft DS1 Interface OBJECTS November 1990 -- the DS1 Current group -- Implementation of this group is mandatory for all systems -- that attach to a ds1-interface. -- It is recognized that some currently deployed CSUs do not -- record the entire set of statistics specified in this -- group. Accordingly, some agents queried for these objects -- may treat these objects as having an ACCESS clause value -- of not-accessible. -- 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-interface 3 } ds1CurrentEntry OBJECT-TYPE SYNTAX DS1CurrentEntry ACCESS read-only STATUS mandatory DESCRIPTION "An entry in the DS1 Current table." INDEX { ds1CurrentIndex } ::= { ds1CurrentTable 1 } DS1CurrentEntry ::= SEQUENCE { ds1CurrentIndex INTEGER, ds1CurrentESs Counter, ds1CurrentBESs Counter, ds1CurrentSESs Counter, ds1CurrentSEFSs Counter, ds1CurrentUASs F. Baker and C. Kolb (editors) [Page 22] Internet Draft DS1 Interface OBJECTS November 1990 Counter, ds1CurrentCSSs Counter, ds1CurrentBPVs Counter, ds1CurrentCVs Counter } ds1CurrentIndex OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The index value which uniquely identifies the CSU 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 ds1CSUIndex object instance." ::= { ds1CurrentEntry 1 } ds1CurrentESs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The counter associated with the number of Errored Seconds, as defined by ANSI Draft Standard T1M1.3/90 - 027R2[16], encountered by a DS1 CSU in the current 15 minute interval." ::= { ds1CurrentEntry 2 } ds1CurrentBESs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The counter associated with the number of Bursty Errored Seconds encountered by a DS1 CSU in the current 15 minute interval. Note that D4 and G.704 (section 2.1.3.2) interfaces do not support Bursty Errored Seconds, as they do not define Code Violation Errors. Accordingly, such agents may treat this object as F. Baker and C. Kolb (editors) [Page 23] Internet Draft DS1 Interface OBJECTS November 1990 having an ACCESS clause value of not-accessible." ::= { ds1CurrentEntry 3 } ds1CurrentSESs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The counter associated with the number of Severely Errored Seconds, as defined by ANSI Draft Standard T1M1.3/90 - 027R2[16], encountered by a DS1 CSU in the current 15 minute interval." ::= { ds1CurrentEntry 4 } ds1CurrentSEFSs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The counter associated with the number of Severely Errored Framing Seconds, as defined by ANSI Draft Standard T1M1.3/90 - 027R2[16], encountered by a DS1 CSU in the current 15 minute interval." ::= { ds1CurrentEntry 5 } ds1CurrentUASs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The counter associated with the number of Unavailable Seconds, as defined by ANSI Draft Standard T1M1.3/90 - 027R2[16], encountered by a DS1 CSU in the current 15 minute interval." ::= { ds1CurrentEntry 6 } ds1CurrentCSSs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The counter associated with the number of Controlled Slip Seconds, as defined by ANSI Draft Standard T1M1.3/90 - 027R2[16], encountered by a F. Baker and C. Kolb (editors) [Page 24] Internet Draft DS1 Interface OBJECTS November 1990 DS1 CSU in the current 15 minute interval." ::= { ds1CurrentEntry 7 } ds1CurrentBPVs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The counter associated with the number of Bipolar Violations, as defined by ANSI Draft Standard T1M1.3/90 - 027R2[16], encountered by a DS1 CSU in the current 15 minute interval." ::= { ds1CurrentEntry 8 } ds1CurrentCVs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The counter associated with the number of Code Violation Error Events, as defined by ANSI Draft Standard T1M1.3/90 - 027R2[16], encountered by a DS1 CSU in the current 15 minute interval. Note that D4 and G.704 (section 2.1.3.2) interfaces do not support Code Violation Error Events. Accordingly, such agents may treat this object as having an ACCESS clause value of not- accessible." ::= { ds1CurrentEntry 9 } F. Baker and C. Kolb (editors) [Page 25] Internet Draft DS1 Interface OBJECTS November 1990 -- the DS1 Total group -- Implementation of this group is mandatory for all systems -- that attach to a ds1-interface. -- It is recognized that some currently deployed CSUs do not -- record the entire set of statistics specified in this -- group. Accordingly, some agents queried for these objects -- may treat these objects as having an ACCESS clause value -- of not-accessible. -- 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. ds1TotalTable OBJECT-TYPE SYNTAX SEQUENCE OF DS1TotalEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The DS1 Total table. 24 hour interval." ::= { ds1-interface 4 } ds1TotalEntry OBJECT-TYPE SYNTAX DS1TotalEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "An entry in the DS1 Total table." INDEX { ds1TotalIndex } ::= { ds1TotalTable 1 } DS1TotalEntry ::= SEQUENCE { ds1TotalIndex INTEGER, ds1TotalESs Counter, ds1TotalBESs Counter, ds1TotalSESs Counter, ds1TotalSEFSs Counter, F. Baker and C. Kolb (editors) [Page 26] Internet Draft DS1 Interface OBJECTS November 1990 ds1TotalUASs Counter, ds1TotalCSSs Counter, ds1TotalBPVs Counter, ds1TotalCVs Counter } ds1TotalIndex OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The index value which uniquely identifies the CSU 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 ds1CSUIndex object instance." ::= { ds1TotalEntry 1 } ds1TotalESs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The counter associated with the number of Errored Seconds, as defined by ANSI Draft Standard T1M1.3/90 - 027R2[16], encountered by a DS1 CSU in the previous 24 hour interval" ::= { ds1TotalEntry 2 } ds1TotalBESs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The counter associated with the number of Bursty Errored Seconds encountered by a DS1 CSU in the previous 24 hour interval. Note that D4 and G.704 (section 2.1.3.2) interfaces do not support Bursty Errored Seconds, as they do not define Code Violation Errors. F. Baker and C. Kolb (editors) [Page 27] Internet Draft DS1 Interface OBJECTS November 1990 Accordingly, such agents may treat this object as having an ACCESS clause value of not-accessible." ::= { ds1TotalEntry 3 } ds1TotalSESs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The counter associated with the number of Severely Errored Seconds, as defined by ANSI Draft Standard T1M1.3/90 - 027R2[16], encountered by a DS1 CSU in the previous 24 hour interval." ::= { ds1TotalEntry 4 } ds1TotalSEFSs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The counter associated with the number of Severely Errored Framing Seconds, as defined by ANSI Draft Standard T1M1.3/90 - 027R2[16], encountered by a DS1 CSU in the previous 24 hour interval." ::= { ds1TotalEntry 5 } ds1TotalUASs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The counter associated with the number of Unavailable Seconds, as defined by ANSI Draft Standard T1M1.3/90 - 027R2[16], encountered by a DS1 CSU in the previous 24 hour interval." ::= { ds1TotalEntry 6 } ds1TotalCSSs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The counter associated with the number of Controlled Slip Seconds, as defined by ANSI Draft F. Baker and C. Kolb (editors) [Page 28] Internet Draft DS1 Interface OBJECTS November 1990 Standard T1M1.3/90 - 027R2[16], encountered by a DS1 CSU in the previous 24 hour interval." ::= { ds1TotalEntry 7 } ds1TotalBPVs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The counter associated with the number of Bipolar Violations, as defined by ANSI Draft Standard T1M1.3/90 - 027R2[16], encountered by a DS1 CSU in the previous 24 hour interval." ::= { ds1TotalEntry 8 } ds1TotalCVs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The counter associated with the number of Code Violation Error Events, as defined by ANSI Draft Standard T1M1.3/90 - 027R2[16], encountered by a DS1 CSU in the previous 24 hour interval. Note that D4 and G.704 (section 2.1.3.2) interfaces do not support Code Violation Error Events. Accordingly, such agents may treat this object as having an ACCESS clause value of not- accessible." ::= { ds1TotalEntry 9 } F. Baker and C. Kolb (editors) [Page 29] Internet Draft DS1 Interface OBJECTS November 1990 -- the DS1 Fractional group -- Implementation of this group is mandatory for those -- systems utilizing a fractional DS1 capability -- 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 Clear Channel -- implementations, exactly one ifTable entry corresponds to -- the CSU being managed. In this very typical case, the -- variable ds1Index indicates the value of ifIndex which -- corresponds to the interface being supported by a -- particular CSU. -- However, for fractional DS1 implementations, the -- correspondent value of ds1Index is 0, and for each DS1 -- channel supporting a logical interface, there is an entry -- in the DS1 fractional table which names a value for -- ifIndex. -- -- 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. ds1G704 can carry user data in channels 2 -- through 32, channel 1 being an overhead channel. -- ds1G704-CRC can carry user data in channels 2 through -- 16 and 18 through 32, channels 1 and 17 being overhead -- channels. ds1FracTable OBJECT-TYPE SYNTAX SEQUENCE OF DS1FracEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The DS1 Fractional table." ::= { ds1-interface 5 } ds1FracEntry OBJECT-TYPE SYNTAX DS1FracEntry ACCESS not-accessible STATUS mandatory DESCRIPTION F. Baker and C. Kolb (editors) [Page 30] Internet Draft DS1 Interface OBJECTS November 1990 "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 CSU 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 ds1CSUIndex 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 to a ds1-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." ::= { ds1FracEntry 3 } F. Baker and C. Kolb (editors) [Page 31] Internet Draft DS1 Interface OBJECTS November 1990 END F. Baker and C. Kolb (editors) [Page 32] Internet Draft DS1 Interface OBJECTS November 1990 7. Acknowledgements This document was produced by the Transmission MIB Working Group. Special thanks go to Tracy Cox of Bellcore. F. Baker and C. Kolb (editors) [Page 33] Internet Draft DS1 Interface OBJECTS November 1990 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 1158. 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 and C. Kolb (editors) [Page 34] Internet Draft DS1 Interface OBJECTS November 1990 for Abstract Notation One (ASN.1), International Organization for Standardization. International Standard 8825, (December, 1987). [9] AT&T Information Systems, AT&T ESF DS1 Channel Service Unit User's Manual, 999-100-305, (February, 1988). [10] AT&T Technical Reference, Requirements for Interfacing Digital Terminal Equipment to Services Employing the Extended Superframe Format, Publication 54016, (May, 1988). [11] CCITT Specifications Volume III, Recommendation G.703, Physical/Electrical Characteristics of Hierarchical Digital Interfaces, (July 1988). [12] CCITT Specifications Volume III, Recommendation G.704, Synchronous frame structures used at primary and secondary hierarchical levels, (July 1988). [13] M.T. Rose, K. McCloghrie (editors), Towards Concise MIB Definitions, Internet Draft, Internet Engineering Task Force, (September, 1990). [14] M.T. Rose (editor), A Convention for Defining Traps for use with the SNMP, Internet Draft, Internet Engineering Task Force, (September, 1990). [15] ANSI T1.403-1989 American National Standard for Telecommunications -- Carrier-to-Customer Installation -- DS1 Metallic Interface. [16] ANSI T1M1.3/90 - 027R2 Draft Proposed Standard -- Description of Installation and Maintenance Parameters for Digital Circuits, Facilities, and Networks. F. Baker and C. Kolb (editors) [Page 35] Internet Draft DS1 Interface OBJECTS November 1990 Table of Contents 1 Status of this Memo ................................... 1 2 Abstract .............................................. 1 3 Historical Perspective ................................ 2 4 Objects ............................................... 4 4.1 Format of Definitions ............................... 4 5 Overview .............................................. 5 5.1 Binding between Interfaces and CSUs ................. 5 5.2 Objectives of this MIB Module ....................... 6 5.3 DS1 Terminology ..................................... 6 6 Definitions ........................................... 9 6.1 The DS1 Configuration Group ......................... 10 6.2 The DS1 Interval Group .............................. 17 6.3 The DS1 Current Group ............................... 22 6.4 The DS1 Total Group ................................. 26 6.5 The DS1 Fractional Group ............................ 30 7 Acknowledgements ...................................... 33 8 References ............................................ 34 F. Baker and C. Kolb (editors) [Page 36]