Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 2495

Definitions of Managed Objects for the DS1, E1, DS2 and E2 Interface Types

Pages: 75
Obsoletes:  1406
Obsoleted by:  3895
Part 1 of 3 – Pages 1 to 21
None   None   Next

ToP   noToC   RFC2495 - Page 1
Network Working Group                              D. Fowler, Editor
Request for Comments: 2495                        Newbridge Networks
Obsoletes: 1406                                         January 1999
Category: Standards Track


                     Definitions of Managed Objects
              for the DS1, E1, DS2 and E2 Interface Types

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Abstract

   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it describes objects used for managing DS1, E1, DS2
   and E2 interfaces.  This document is a companion document with
   Definitions of Managed Objects for the DS0 (RFC 2494 [30]), DS3/E3
   (RFC 2496 [28]), and the work in progress, SONET/SDH Interface Types.

   This memo specifies a MIB module in a manner that is both compliant
   to the SNMPv2 SMI, and semantically identical to the peer SNMPv1
   definitions.

Table of Contents

   1 The SNMP Management Framework ................................    2
   1.1 Changes from RFC1406 .......................................    3
   2 Overview .....................................................    4
   2.1 Use of ifTable for DS1 Layer ...............................    5
   2.2 Usage Guidelines ...........................................    6
   2.2.1 Usage of ifStackTable for Routers and DSUs ...............    6
   2.2.2 Usage of ifStackTable for DS1/E1 on DS2/E2 ...............    8
   2.2.3 Usage of Channelization for DS3, DS1, DS0 ................    9
   2.2.4 Usage of Channelization for DS3, DS2, DS1 ................    9
   2.2.5 Usage of Loopbacks .......................................   10
   2.3 Objectives of this MIB Module ..............................   11
   2.4 DS1 Terminology ............................................   11
ToP   noToC   RFC2495 - Page 2
   2.4.1 Error Events .............................................   12
   2.4.2 Performance Defects ......................................   12
   2.4.3 Performance Parameters ...................................   14
   2.4.4 Failure States ...........................................   17
   2.4.5 Other Terms ..............................................   21
   3 Object Definitions ...........................................   21
   3.1 The DS1 Near End Group .....................................   22
   3.1.1 The DS1 Configuration Table ..............................   22
   3.1.2 The DS1 Current Table ....................................   33
   3.1.3 The DS1 Interval Table ...................................   36
   3.1.4 The DS1 Total Table ......................................   39
   3.1.5 The DS1 Channel Table ....................................   42
   3.2 The DS1 Far End Group ......................................   43
   3.2.1 The DS1 Far End Current Table ............................   43
   3.2.2 The DS1 Far End Interval Table ...........................   47
   3.2.3 The DS1 Far End Total Table ..............................   50
   3.3 The DS1 Fractional Table ...................................   53
   3.4 The DS1 Trap Group .........................................   55
   3.5 Conformance Groups .........................................   61
   4 Appendix A - Use of dsx1IfIndex and dsx1LineIndex ............   66
   5 Appendix B - The delay approach to Unavialable Seconds.  .....   69
   6 Intellectual Property ........................................   70
   7 Acknowledgments ..............................................   70
   8 References ...................................................   71
   9 Security Considerations ......................................   73
   10 Author's Address ............................................   74
   11 Full Copyright Statement ....................................   75

1.  The SNMP Management Framework

   The SNMP Management Framework presently consists of five major
   components:

    o   An overall architecture, described in RFC 2271 [1].

    o   Mechanisms for describing and naming objects and events for the
        purpose of management. The first version of this Structure of
        Management Information (SMI) is called SMIv1 and described in
        STD 16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4]. The
        second version, called SMIv2, is described in RFC 1902 [5], RFC
        1903 [6] and RFC 1904 [7].

    o   Message protocols for transferring management information. The
        first version of the SNMP message protocol is called SNMPv1 and
        described in STD 15, RFC 1157 [8]. A second version of the SNMP
        message protocol, which is not an Internet standards track
        protocol, is called SNMPv2c and described in RFC 1901 [9] and
        RFC 1906 [10].  The third version of the message protocol is
ToP   noToC   RFC2495 - Page 3
        called SNMPv3 and described in RFC 1906 [10], RFC 2272 [11] and
        RFC 2274 [12].

    o   Protocol operations for accessing management information. The
        first set of protocol operations and associated PDU formats is
        described in STD 15, RFC 1157 [8]. A second set of protocol
        operations and associated PDU formats is described in RFC 1905
        [13].

    o   A set of fundamental applications described in RFC 2273 [14] and
        the view-based access control mechanism described in RFC 2275
        [15].  Managed objects are accessed via a virtual information
        store, termed the Management Information Base or MIB.  Objects
        in the MIB are defined using the mechanisms defined in the SMI.
        This memo specifies a MIB module that is compliant to the SMIv2.
        A MIB conforming to the SMIv1 can be produced through the
        appropriate translations. The resulting translated MIB must be
        semantically equivalent, except where objects or events are
        omitted because no translation is possible (use of Counter64).
        Some machine readable information in SMIv2 will be converted
        into textual descriptions in SMIv1 during the translation
        process. However, this loss of machine readable information is
        not considered to change the semantics of the MIB.

1.1.  Changes from RFC1406

   The changes from RFC1406 are the following:

        (1)  The Fractional Table has been deprecated.

        (2)  This document uses SMIv2.

        (3)  Usage is given for ifTable and ifXTable.

        (4)  Example usage of ifStackTable is included.

        (5)  dsx1IfIndex has been deprecated.

        (6)  Support for DS2 and E2 have been added.

        (7)  Additional lineTypes for DS2, E2, and unframed E1
             were added.

        (8)  The definition of valid intervals has been clarified
             for the case where the agent proxied for other devices.  In
             particular, the treatment of missing intervals has been
             clarified.
ToP   noToC   RFC2495 - Page 4
        (9)  An inward loopback has been added.

        (10) Additional lineStatus bits have been added for Near End in
             Unavailable Signal State, Carrier Equipment Out of Service,
             DS2 Payload AIS, and DS2 Performance Threshold.

        (11) A read-write line Length object has been added.

        (12) Signal mode of other has been added.

        (13) Added a lineStatus last change, trap and enabler.

        (14) The e1(19) ifType has been obsoleted so this MIB
             does not list it as a supported ifType.

        (15) Textual Conventions for statistics objects have been used.

        (16) A new object, dsx1LoopbackStatus has been introduced to
             reflect the loopbacks established on a DS1 interface and
             the source to the requests.  dsx1LoopbackConfig continues
             to be the desired loopback state while dsx1LoopbackStatus
             reflects the actual state.

        (17) A dual loopback has been added to allow the setting of an
             inward loopback and a line loopback at the same time.

        (18) An object indicating which channel to use within a parent
             object (i.e. DS3) has been added.

        (19) An object has been added to indicate whether or not this
             DS1/E1 is channelized.

        (20) Line coding type of B6ZS has been added for DS2

2.  Overview

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

        ds1 (18)

   The definitions contained herein are based on the AT&T T-1 Superframe
   (a.k.a., D4) and Extended Superframe (ESF) formats [17, 18], the
   latter of which conforms to ANSI specifications [19], and the CCITT
   Recommendations [20, 21], referred to as E1 for the rest of this
   memo.
ToP   noToC   RFC2495 - Page 5
   The various DS1 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.  Therefore,  interface types e1(19) and g703at2mb(67) have been
   obsoleted.

   Where it is necessary to distinguish between the flavors of E1 with
   and without CRC, E1-CRC denotes the "with CRC" form (G.704 Table 4b)
   and E1-noCRC denotes the "without CRC" form (G.704 Table 4a).

2.1.  Use of ifTable for DS1 Layer

   Only the ifGeneralGroup needs to be supported.

           ifTable Object    Use for DS1 Layer
======================================================================
           ifIndex           Interface index.

           ifDescr           See interfaces MIB [16]

           ifType            ds1(18)

           ifSpeed           Speed of line rate
                             DS1 - 1544000
                             E1  - 2048000
                             DS2 - 6312000
                             E2  - 8448000

           ifPhysAddress     The value of the Circuit Identifier.
                             If no Circuit Identifier has been assigned
                             this object should have an octet string
                             with zero length.

           ifAdminStatus     See interfaces MIB [16]

           ifOperStatus      See interfaces MIB [16]

           ifLastChange      See interfaces MIB [16]

           ifName            See interfaces MIB [16].

           ifLinkUpDownTrapEnable   Set to enabled(1).

           ifHighSpeed       Speed of line in Mega-bits per second
                             (2, 6, or 8)

           ifConnectorPresent Set to true(1) normally, except for
ToP   noToC   RFC2495 - Page 6
                              cases such as DS1/E1 over AAL1/ATM where
                              false(2) is appropriate

2.2.  Usage Guidelines

2.2.1.  Usage of ifStackTable for Routers and DSUs

   The object dsx1IfIndex has been deprecated.  This object previously
   allowed a very special proxy situation to exist for Routers and CSUs.
   This section now describes how to use ifStackTable to represent this
   relationship.

   The paragraphs discussing dsx1IfIndex and dsx1LineIndex have been
   preserved in Appendix A for informational purposes.

   The ifStackTable is used in the proxy case to represent the
   association between pairs of interfaces, e.g. this T1 is attached to
   that T1.  This use is consistent with the use of the ifStackTable to
   show the association between various sub-layers of an interface.  In
   both cases entire PDUs are exchanged between the interface pairs - in
   the case of a T1, entire T1 frames are exchanged; in the case of PPP
   and HDLC, entire HDLC frames are exchanged.  This usage is not meant
   to suggest the use of the ifStackTable to represent Time Division
   Multiplexing (TDM) connections in general.

   External&Internal interface scenario: the SNMP Agent resides on a
   host external from the device supporting DS1 interfaces (e.g., a
   router). The Agent represents both the host and the DS1 device.

   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:
ToP   noToC   RFC2495 - Page 7
         +-----+
   |     |     |
   |     |     |               +---------------------+
   |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  Description
           1        Ethernet
           2        Line#A Router
           3        Line#B Router
           4        Line#C Router
           5        Line#D Router
           6        Line#A CSU Router
           7        Line#B CSU Router
           8        Line#C CSU Router
           9        Line#D CSU Router
           10       Line#A CSU Network
           11       Line#B CSU Network
           12       Line#C CSU Network
           13       Line#D CSU Network

   The ifStackTable is then used to show the relationships between the
   various DS1 interfaces.

           ifStackTable Entries
           HigherLayer   LowerLayer
           2             6
           3             7
           4             8
           5             9
           6             10
           7             11
           8             12
           9             13
ToP   noToC   RFC2495 - Page 8
   If the CSU shelf is managed by itself by a local SNMP Agent, the
   situation would be identical, except the Ethernet and the 4 router
   interfaces are deleted.  Interfaces would also be numbered from 1 to
   8.

           ifIndex  Description
           1        Line#A CSU Router
           2        Line#B CSU Router
           3        Line#C CSU Router
           4        Line#D CSU Router
           5        Line#A CSU Network
           6        Line#B CSU Network
           7        Line#C CSU Network
           8        Line#D CSU Network

           ifStackTable Entries

           HigherLayer   LowerLayer
           1             5
           2             6
           3             7
           4             8

2.2.2.  Usage of ifStackTable for DS1/E1 on DS2/E2

   An example is given of how DS1/E2 interfaces are stacked on DS2/E2
   interfaces.  It is not necessary nor is it always desirable to
   represent DS2 interfaces.  If this is required, the following
   stacking should be used.  All ifTypes are ds1.  The DS2 is determined
   by examining ifSpeed or dsx1LineType.

        ifIndex  Description
        1        DS1 #1
        2        DS1 #2
        3        DS1 #3
        4        DS1 #4
        5        DS2

        ifStackTable Entries

        HigherLayer   LowerLayer
        1             5
        2             5
        3             5
        4             5
ToP   noToC   RFC2495 - Page 9
2.2.3.  Usage of Channelization for DS3, DS1, DS0

   An example is given here to explain the channelization objects in the
   DS3, DS1, and DS0 MIBs to help the implementor use the objects
   correctly. Treatment of E3 and E1 would be similar, with the number
   of DS0s being different depending on the framing of the E1.


   Assume that a DS3 (with ifIndex 1) is Channelized into DS1s (without
   DS2s).  The object dsx3Channelization is set to enabledDs1.  There
   will be 28 DS1s in the ifTable.  Assume the entries in the ifTable
   for the DS1s are created in channel order and the ifIndex values are
   2 through 29. In the DS1 MIB, there will be an entry in the
   dsx1ChanMappingTable for each ds1.  The entries will be as follows:

           dsx1ChanMappingTable Entries

           ifIndex  dsx1Ds1ChannelNumber   dsx1ChanMappedIfIndex
           1        1                      2
           1        2                      3
           ......
           1        28                     29

   In addition, the DS1s are channelized into DS0s.  The object
   dsx1Channelization is set to enabledDS0 for each DS1.   When this
   object is set to this value, 24 DS0s are created by the agent. There
   will be 24 DS0s in the ifTable for each DS1.  If the
   dsx1Channelization is set to disabled, the 24 DS0s are destroyed.

   Assume the entries in the ifTable are created in channel order and
   the ifIndex values for the DS0s in the first DS1 are 30 through 53.
   In the DS0 MIB, there will be an entry in the dsx0ChanMappingTable
   for each DS0.  The entries will be as follows:

           dsx0ChanMappingTable Entries

           ifIndex   dsx0Ds0ChannelNumber  dsx0ChanMappedIfIndex
           2         1                     30
           2         2                     31
           ......
           2         24                    53

2.2.4.  Usage of Channelization for DS3, DS2, DS1

   An example is given here to explain the channelization objects in the
   DS3 and DS1 MIBs to help the implementor use the objects correctly.
ToP   noToC   RFC2495 - Page 10
   Assume that a DS3 (with ifIndex 1) is Channelized into DS2s.  The
   object dsx3Channelization is set to enabledDs2.  There will be 7 DS2s
   (ifType of DS1) in the ifTable.  Assume the entries in the ifTable
   for the DS2s are created in channel order and the ifIndex values are
   2 through 8. In the DS1 MIB, there will be an entry in the
   dsx1ChanMappingTable for each DS2.  The entries will be as follows:

           dsx1ChanMappingTable Entries

           ifIndex  dsx1Ds1ChannelNumber   dsx1ChanMappedIfIndex
           1        1                      2
           1        2                      3
           ......
           1        7                      8

   In addition, the DS2s are channelized into DS1s.  The object
   dsx1Channelization is set to enabledDS1 for each DS2.  There will be
   4 DS1s in the ifTable for each DS2.  Assume the entries in the
   ifTable are created in channel order and the ifIndex values for the
   DS1s in the first DS2 are 9 through 12, then 13 through 16 for the
   second DS2, and so on.  In the DS1 MIB, there will be an entry in the
   dsx1ChanMappingTable for each DS1.  The entries will be as follows:

           dsx1ChanMappingTable Entries

           ifIndex   dsx1Ds1ChannelNumber  dsx1ChanMappedIfIndex
           2         1                     9
           2         2                     10
           2         3                     11
           2         4                     12
           3         1                     13
           3         2                     14
           ...
           8         4                     36


2.2.5.  Usage of Loopbacks

   This section discusses the behaviour of objects related to loopbacks.

   The object dsx1LoopbackConfig represents the desired state of
   loopbacks on this interface.  Using this object a Manager can
   request:
       LineLoopback
       PayloadLoopback (if ESF framing)
       InwardLoopback
       DualLoopback (Line + Inward)
       NoLoopback
ToP   noToC   RFC2495 - Page 11
   The remote end can also request loopbacks either through the FDL
   channel if ESF or inband if D4.  The loopbacks that can be request
   this way are:
       LineLoopback
       PayloadLoopback (if ESF framing)
       NoLoopback

   To model the current state of loopbacks on a DS1 interface, the
   object dsx1LoopbackStatus defines which loopback is currently applies
   to an interface.  This objects, which is a bitmap, will have bits
   turned on which reflect the currently active loopbacks on the
   interface as well as the source of those loopbacks.

   The following restrictions/rules apply to loopbacks:

   The far end cannot undo loopbacks set by a manager.

   A manager can undo loopbacks set by the far end.

   Both a line loopback and an inward loopback can be set at the same
   time.  Only these two loopbacks can co-exist and either one may be
   set by the manager or the far end.  A LineLoopback request from the
   far end is incremental to an existing Inward loopback established by
   a manager.  When a NoLoopback is received from the far end in this
   case, the InwardLoopback remains in place.

2.3.  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, E1, DS2, or E3 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 these types devices that
   are currently deployed.

   J2 interfaces are not supported by this MIB.

2.4.  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 late
   but not final draft of what became the ANSI T1.231 standard [11].  If
   the definition in this document does not match the definition in the
   ANSI T1.231 document, the implementer should follow the definition
   described in this document.
ToP   noToC   RFC2495 - Page 12
2.4.1.  Error Events

   Bipolar Violation (BPV) Error Event
       A BPV error event for an AMI-coded signal is the occurrence of a
       pulse of the same polarity as the previous pulse.  (See T1.231
       Section 6.1.1.1.1) A BPV error event for a B8ZS- or HDB3- 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.

   Excessive Zeroes (EXZ) Error Event
       An Excessive Zeroes error event for an AMI-coded signal is the
       occurrence of more than fifteen contiguous zeroes.  (See T1.231
       Section 6.1.1.1.2) For a B8ZS coded signal, the defect occurs
       when more than seven contiguous zeroes are detected.

   Line Coding Violation (LCV) Error Event
       A Line Coding Violation (LCV) is the occurrence of either a
       Bipolar Violation (BPV) or Excessive Zeroes (EXZ) Error Event.
       (Also known as CV-L; See T1.231 Section 6.5.1.1)

   Path Coding Violation (PCV) Error Event
       A Path Coding Violation error event is a frame synchronization
       bit error in the D4 and E1-noCRC formats, or a CRC or frame
       synch. bit error in the ESF and E1-CRC formats. (Also known as
       CV-P; See T1.231 Section 6.5.2.1)

   Controlled Slip (CS) Error Event
       A Controlled Slip is the replication or deletion of the payload
       bits of a DS1 frame.  (See T1.231 Section 6.1.1.2.3) A Controlled
       Slip may be performed when there is a difference between the
       timing of a synchronous receiving terminal and the received
       signal.  A Controlled Slip does not cause an Out of Frame defect.

2.4.2.  Performance Defects

   Out Of Frame (OOF) Defect
       An OOF defect is the occurrence of a particular density of
       Framing Error events. (See T1.231 Section 6.1.2.2.1)

       For DS1 links, an Out of Frame defect is declared when the
       receiver detects two or more framing errors within a 3 msec
       period for ESF signals and 0.75 msec for D4 signals, or two or
       more errors out of five or fewer consecutive framing-bits.

       For E1 links, an Out Of Frame defect is declared when three
       consecutive frame alignment signals have been received with an
       error (see G.706 Section 4.1 [26]).
ToP   noToC   RFC2495 - Page 13
       For DS2 links, an Out of Frame defect is declared when 7 or more
       consecutive errored framing patterns (4 multiframe) are received.
       The LOF is cleared when 3 or more consecutive correct framing
       patterns are received.

       Once an Out Of Frame Defect is declared, the framer starts
       searching for a correct framing pattern.  The Out of Frame defect
       ends when the signal is in frame.

       In-frame occurs when there are fewer than two frame bit errors
       within 3 msec period for ESF signals and 0.75 msec for D4
       signals.

       For E1 links, in-frame occurs when a) in frame N the frame
       alignment signal is correct and b) in frame N+1 the frame
       alignment signal is absent (i.e., bit 2 in TS0 is a one) and c)
       in frame N+2 the frame alignment signal is present and correct.
       (See G.704 Section 4.1)

   Alarm Indication Signal (AIS) Defect
       For D4 and ESF links, the 'all ones' condition 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.
       (See G.775, Section 5.4)

       For E1 links, the 'all-ones' condition is detected at the line
       interface as a string of 512 bits containing fewer than three
       zero bits (see O.162 [23] Section 3.3.2).

       For DS2 links, the DS2 AIS shall be sent from the NT1 to the user
       to indicate a loss of the 6,312 kbps frame capability on the
       network side.  The DS2 AIS is defined as a bit array of 6,312
       kbps in which all binary bits are set to '1'.

       The DS2 AIS detection and removal shall be implemented according
       to ITU-T Draft Recommendation G.775 [31] Section 5.5:
       - a DS2 AIS defect is detected when the incoming signal has two
       (2) or less ZEROs in a sequence of 3156 bits (0.5 ms).
       - a DS2 AIS defect is cleared when the incoming signal has three
       (3) or more ZEROs in a sequence of 3156 bits (0.5 ms).
ToP   noToC   RFC2495 - Page 14
2.4.3.  Performance Parameters

   All performance parameters are accumulated in fifteen minute
   intervals and up to 96 intervals (24 hours worth) are kept by an
   agent.  Fewer than 96 intervals of data whelfill be available if the
   agent has been restarted within the last 24 hours.  In addition,
   there is a rolling 24-hour total of each performance parameter.
   Performance parameters continue to be collected when the interface is
   down.

   There is no requirement for an agent to ensure fixed relationship
   between the start of a fifteen minute interval and any wall clock;
   however some agents may align the fifteen minute intervals with
   quarter hours.

   Performance parameters are of types PerfCurrentCount,
   PerfIntervalCount and PerfTotalCount.  These textual conventions are
   all Gauge32, and they are used because it is possible for these
   objects to decrease.  Objects may decrease when Unavailable Seconds
   occurs across a fifteen minutes interval boundary. See Unavailable
   Seconds discussion later in this section.

    Line Errored Seconds (LES)
        A Line Errored Second is a second in which one or more Line Code
        Violation error events were detected. (Also known as ES-L; See
        T1.231 Section 6.5.1.2)

    Controlled Slip Seconds (CSS)
        A Controlled Slip Second is a one-second interval containing one
        or more controlled slips.  (See T1.231 Section 6.5.2.8) This is
        not incremented during an Unavailable Second.

    Errored Seconds (ES)
        For ESF and E1-CRC links an Errored Second is a second with one
        or more Path Code Violation OR one or more Out of Frame defects
        OR one or more Controlled Slip events OR a detected AIS defect.
        (See T1.231 Section 6.5.2.2 and G.826 [32] Section B.1)

        For D4 and E1-noCRC links, the presence of Bipolar Violations
        also triggers an Errored Second.

        This is not incremented during an Unavailable Second.
ToP   noToC   RFC2495 - Page 15
    Bursty Errored Seconds (BES)
        A Bursty Errored Second (also known as Errored Second type B in
        T1.231 Section 6.5.2.4) is a second with fewer than 320 and more
        than 1 Path Coding Violation error events, no Severely Errored
        Frame defects and no detected incoming AIS defects.  Controlled
        slips are not included in this parameter.

        This is not incremented during an Unavailable Second.  It
        applies to ESF signals only.

    Severely Errored Seconds (SES)
        A Severely Errored Second for ESF signals is a second with 320
        or more Path Code Violation Error Events OR one or more Out of
        Frame defects OR a detected AIS defect. (See T1.231 Section
        6.5.2.5)

        For E1-CRC signals, a Severely Errored Second is a second with
        832 or more Path Code Violation error events OR one or more Out
        of Frame defects.

        For E1-noCRC signals, a Severely Errored Second is a 2048 LCVs
        or more.

        For D4 signals, a Severely Errored Second is a count of one-
        second intervals with Framing Error events, or an OOF defect, or
        1544 LCVs or more.

        Controlled slips are not included in this parameter.

        This is not incremented during an Unavailable Second.

    Severely Errored Framing Second (SEFS)
        An Severely Errored Framing Second is a second with one or more
        Out of Frame defects OR a detected AIS defect.  (Also known as
        SAS-P (SEF/AIS second); See T1.231 Section 6.5.2.6)

    Degraded Minutes
        A Degraded Minute is one in which the estimated error rate
        exceeds 1E-6 but does not exceed 1E-3 (see G.821 [24]).

        Degraded Minutes are determined by collecting all of the
        Available Seconds, removing any Severely Errored Seconds
        grouping the result in 60-second long groups and counting a 60-
        second long group (a.k.a., minute) as degraded if the cumulative
        errors during the seconds present in the group exceed 1E-6.
        Available seconds are merely those seconds which are not
        Unavailable as described below.
ToP   noToC   RFC2495 - Page 16
    Unavailable Seconds (UAS)
        Unavailable Seconds (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 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.

        Note that this definition implies that the agent cannot
        determine until after a ten second interval has passed whether a
        given one-second interval belongs to available or unavailable
        time.  If the agent chooses to update the various performance
        statistics in real time then it must be prepared to
        retroactively reduce the ES, BES, SES, and SEFS counts by 10 and
        increase the UAS count by 10 when it determines that available
        time has been entered.  It must also be prepared to adjust the
        PCV count and the DM count as necessary since these parameters
        are not accumulated during unavailable time.  It must be
        similarly prepared to retroactively decrease the UAS count by 10
        and increase the ES, BES, and DM counts as necessary upon
        entering available time.  A special case exists when the 10
        second period leading to available or unavailable time crosses a
        900 second statistics window boundary, as the foregoing
        description implies that the ES, BES, SES, SEFS, DM, and UAS
        counts the PREVIOUS interval must be adjusted.  In this case
        successive GETs of the affected dsx1IntervalSESs and
        dsx1IntervalUASs objects will return differing values if the
        first GET occurs during the first few seconds of the window.

        The agent may instead choose to delay updates to the various
        statistics by 10 seconds in order to avoid retroactive
        adjustments to the counters.  A way to do this is sketched in
        Appendix B.
ToP   noToC   RFC2495 - Page 17
        In any case, a linkDown trap shall be sent only after the agent
        has determined for certain that the unavailable state has been
        entered, but the time on the trap will be that of the first UAS
        (i.e., 10 seconds earlier).  A linkUp trap shall be handled
        similarly.

        According to ANSI T1.231 unavailable time begins at the _onset_
        of 10 contiguous severely errored seconds -- that is,
        unavailable time starts with the _first_ of the 10 contiguous
        SESs.  Also, while an interface is deemed unavailable all
        counters for that interface are frozen except for the UAS count.
        It follows that an implementation which strictly complies with
        this standard must _not_ increment any counters other than the
        UAS count -- even temporarily -- as a result of anything that
        happens during those 10 seconds.  Since changes in the signal
        state lag the data to which they apply by 10 seconds, an ANSI-
        compliant implementation must pass the the one-second statistics
        through a 10-second delay line prior to updating any counters.
        That can be done by performing the following steps at the end of
        each one second interval.

   i)   Read near/far end CV counter and alarm status flags from the
        hardware.

   ii)  Accumulate the CV counts for the preceding second and compare
        them to the ES and SES threshold for the layer in question.
        Update the signal state and shift the one-second CV counts and
        ES/SES flags into the 10-element delay line.  Note that far-end
        one-second statistics are to be flagged as "absent" during any
        second in which there is an incoming defect at the layer in
        question or at any lower layer.

   iii) Update the current interval statistics using the signal state
        from the _previous_ update cycle and the one-second CV counts
        and ES/SES flags shifted out of the 10-element delay line.

   This approach is further described in Appendix B.

2.4.4.  Failure States

   The following failure states are received, or detected failures, that
   are reported in the dsx1LineStatus object.  When a DS1 interface
   would, if ever, produce the conditions leading to the failure state
   is described in the appropriate specification.
ToP   noToC   RFC2495 - Page 18
    Far End Alarm Failure
        The Far End Alarm failure is also known as "Yellow Alarm" in the
        DS1 case, "Distant Alarm" in the E1 case, and "Remote Alarm" in
        the DS2 case.

        For D4 links, the Far End Alarm failure is declared when bit 6
        of all channels has been zero for at least 335 ms and is cleared
        when bit 6 of at least one channel is non-zero for a period T,
        where T is usually less than one second and always less than 5
        seconds.  The Far End Alarm failure is not declared for D4 links
        when a Loss of Signal is detected.

        For ESF links, the Far End Alarm failure is declared if the
        Yellow Alarm signal pattern occurs in at least seven out of ten
        contiguous 16-bit pattern intervals and is cleared if the Yellow
        Alarm signal pattern does not occur in ten contiguous 16-bit
        signal pattern intervals.

        For E1 links, the Far End Alarm failure is declared when bit 3
        of time-slot zero is received set to one on two consecutive
        occasions.  The Far End Alarm failure is cleared when bit 3 of
        time-slot zero is received set to zero.

        For DS2 links, if a loss of frame alignment (LOF or LOS) and/or
        DS2 AIS condition, is detected, the RAI signal shall be
        generated and transmitted to the remote side.

        The Remote Alarm Indication(RAI) signal is defined on m-bits as
        a repetition of the 16bit sequence consisting of eight binary
        '1s' and eight binary '0s' in m-bits(1111111100000000).  When
        the RAI signal is not sent (in normal operation),the HDLC flag
        pattern (01111110) in the m-bit is sent.

        The RAI failure is detected when 16 or more consecutive RAI-
        patterns (1111111100000000) are received.  The RAI failure is
        cleared when 4 or more consecutive incorrect-RAI-patterns are
        received.

    Alarm Indication Signal (AIS) Failure
        The Alarm Indication Signal failure is declared when an AIS
        defect is detected at the input and the  AIS defect still exists
        after the Loss Of Frame failure (which is caused by the unframed
        nature of the 'all-ones' signal) is declared. The AIS failure is
        cleared when the Loss Of Frame failure is cleared.  (See T1.231
        Section 6.2.1.2.1)
ToP   noToC   RFC2495 - Page 19
        An AIS defect at a 6312 kbit/s (G.704) interface is detected
        when the incoming signal has two {2} or less ZEROs in a sequence
        of 3156 bits (0.5ms).

        The AIS signal defect is cleared when the incoming signal has
        three {3} or more ZEROs in a sequence of 3156 bits (0.5ms).

    Loss Of Frame Failure
        For DS1 links, the Loss Of Frame failure is declared when an OOF
        or LOS  defect has persisted for T seconds, where 2 <= T <= 10.
        The Loss Of Frame failure is cleared when there have been no OOF
        or LOS defects during a period T where 0 <= T <= 20.  Many
        systems will perform "hit integration" within the period T
        before declaring or clearing the failure e.g., see TR 62411
        [25].

        For E1 links, the Loss Of Frame Failure is declared when an OOF
        defect is detected.

    Loss Of Signal Failure
        For DS1, the Loss Of Signal failure is declared upon observing
        175 +/- 75 contiguous pulse positions with no pulses of either
        positive or negative polarity.  The LOS failure is cleared 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.

        For E1 links, the Loss Of Signal failure is declared when
        greater than 10 consecutive zeroes are detected (see O.162
        Section 3.4`<.4).

        A LOS defect at 6312kbit/s interfaces is detected when the
        incoming signal has "no transitions", i.e. when the signal level
        is less than or equal to a signal level of 35dB below nominal,
        for N consecutive pulse intervals, where 10 <=N<=255.

        The LOS defect is cleared when the incoming signal has
        "transitions", i.e. when the signal level is greater than or
        equal to a signal level of 9dB below nominal, for N consecutive
        pulse intervals, where 10<=N<=255.

        A signal with "transitions" corresponds to a G.703 compliant
        signal.
ToP   noToC   RFC2495 - Page 20
    Loopback Pseudo-Failure
        The Loopback Pseudo-Failure is declared when the near end
        equipment has placed a loopback (of any kind) on the DS1.  This
        allows a management entity to determine from one object whether
        the DS1 can be considered to be in service or not (from the
        point of view of the near end equipment).

    TS16 Alarm Indication Signal Failure
        For E1 links, the TS16 Alarm Indication Signal failure is
        declared when time-slot 16 is received as all ones for all
        frames of two consecutive multiframes (see G.732 Section 4.2.6).
        This condition is never declared for DS1.

    Loss Of MultiFrame Failure
        The Loss Of MultiFrame failure is declared when two consecutive
        multiframe alignment signals (bits 4 through 7 of TS16 of frame
        0) have been received with an error.  The Loss Of Multiframe
        failure is cleared when the first correct multiframe alignment
        signal is received.  The Loss Of Multiframe failure can only be
        declared for E1 links operating with G.732 [27] framing
        (sometimes called "Channel Associated Signalling" mode).

    Far End Loss Of Multiframe Failure
        The Far End Loss Of Multiframe failure is declared when bit 2 of
        TS16 of frame 0 is received set to one on two consecutive
        occasions.  The Far End Loss Of Multiframe failure is cleared
        when bit 2 of TS16 of frame 0 is received set to zero.  The Far
        End Loss Of Multiframe failure can only be declared for E1 links
        operating in "Channel Associated Signalling" mode. (See G.732)

    DS2 Payload AIS Failure
        The DS2 Payload AIS is detected when the incoming signal of the
        6,312 kbps frame payload [TS1-TS96] has 2 or less 0's in a
        sequence of 3072 bits (0.5ms).  The DS2 Payload AIS is cleared
        when the incoming signal of the 6,312 kbps frame payload [TS1-
        TS96] has 3 or more 0's in a sequence of 3072 bits (0.5 ms).

    DS2 Performance Threshold
        DS2 Performance Threshold Failure monitors equipment performance
        and is based on the CRC (Cyclic Redundancy Check) Procedure
        defined in G.704.

        The DS2 Performance Threshold Failure is detected when the bit
        error ratio exceeds 10^-4 (Performance Threshold), and the DS2
        Performance Threshold Failure shall be cleared when the bit
        error ratio decreased to less than 10^-6."
ToP   noToC   RFC2495 - Page 21
2.4.5.  Other Terms

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

    Proxy
        In this document, the word proxy is meant to indicate an
        application which receives SNMP messages and replies to them on
        behalf of the devices which implement the actual DS3/E3
        interfaces.  The proxy may have already collected the
        information about the DS3/E3 interfaces into its local database
        and may not necessarily forward the requests to the actual
        DS3/E3 interface.  It is expected in such an application that
        there are periods of time where the proxy is not communicating
        with the DS3/E3 interfaces.  In these instances the proxy will
        not necessarily have up-to-date configuration information and
        will most likely have missed the collection of some statistics
        data.  Missed statistics data collection will result in invalid
        data in the interval table.



(page 21 continued on part 2)

Next Section