tech-invite   World Map
3GPP     Specs     Glossaries     UICC       IETF     RFCs     Groups     SIP     ABNFs       T+       Search     Home

RFC 4805

Proposed STD
Pages: 94
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: ~mib

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

Part 1 of 4, p. 1 to 20
None       Next RFC Part

Obsoletes:    3895


Top       ToC       Page 1 
Network Working Group                                   O. Nicklass, Ed.
Request for Comments: 4805                 RAD Data Communications, Ltd.
Obsoletes: 3895                                               March 2007
Category: Standards Track


                     Definitions of Managed Objects
            for the DS1, J1, 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 IETF Trust (2007).

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, J1, E1,
   DS2, and E2 interfaces.  This document is a companion to the
   documents that define managed objects for the DS0, DS3/E3, and
   Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH)
   Interface Types.

   This document obsoletes RFC 3895.

Top       Page 2 
Table of Contents

   1. The Internet-Standard Management Framework ......................2
   2. Conventions Used in This Document ...............................3
   3. Overview ........................................................3
      3.1. Use of ifTable for DS1 Layer ...............................4
      3.2. Usage Guidelines ...........................................5
           3.2.1. Usage of ifStackTable for Routers and DSUs ..........5
           3.2.2. Usage of ifStackTable for DS1/J1/E1 on DS2/E2 .......7
           3.2.3. Usage of Channelization for DS3, DS1, DS0 ...........8
           3.2.4. Usage of Channelization for DS3, DS2, DS1 ...........9
           3.2.5. Usage of Loopbacks .................................10
      3.3. Objectives of This MIB Module .............................10
      3.4. DS1 Terminology ...........................................11
           3.4.1. Error Events .......................................11
           3.4.2. Performance Defects ................................12
           3.4.3. Performance Parameters .............................13
           3.4.4. Failure States .....................................17
           3.4.5. Other Terms ........................................20
   4. Object Definitions .............................................20
   5. Security Considerations ........................................83
   6. Acknowledgments ................................................84
   7. References .....................................................84
      7.1. Normative References ......................................84
      7.2. Informative References ....................................86
   Appendix A - Use of dsx1IfIndex and dsx1LineIndex .................88
   Appendix B - The Delay Approach to Unavailable Seconds ............90
   Appendix C - Changes from Previous Versions .......................92
      C.1. Changes from RFC 3895 .....................................92
      C.2. Changes from RFC 2495 .....................................92
      C.3. Changes from RFC 1406 .....................................92
      C.4. Companion Documents .......................................93

1.  The Internet-Standard Management Framework

   For a detailed overview of the documents that describe the current
   Internet-Standard Management Framework, please refer to section 7 of
   RFC 3410 [RFC3410].

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  MIB objects are generally
   accessed through the Simple Network Management Protocol (SNMP).
   Objects in the MIB are defined using the mechanisms defined in the
   Structure of Management Information (SMI).  This memo specifies a MIB
   module that is compliant to the SMIv2, which is described in STD 58,
   RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
   [RFC2580].

Top      ToC       Page 3 
2.  Conventions Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

3.  Overview

   These objects are used when the particular media being used to
   realize an interface is a DS1/J1/E1/DS2/E2 interface.  At present,
   this applies to the following value 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) [ANSI-T1.107] and Extended Superframe (ESF) formats
   [AT&T-UM-305], [AT&T-TR-54016], the latter of which conforms to ANSI
   specifications [ANSI-T1.403], and the CCITT Recommendations
   [CCITT-G.703], [ITU-T-G.704], referred to as E1 for the rest of this
   memo.  J1 refers to the definition presented in [JT-G704], [JT-G706],
   and [JT-I431].

   The various DS1, J1, 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, or Yellow Alarm
   generation and detection are a bit different between T1 and J1 but in
   both examples, there is definition in both related lines.  Therefore,
   interface types e1(19) and g703at2mb(67) have been obsoleted and
   there is also no need for special type for J1.

   Where it is necessary to distinguish between the flavors of E1 with
   and without Cyclic Redundancy Check (CRC), E1-CRC denotes the "with
   CRC" form (G.704 Table 5B) and E1-noCRC denotes the "without CRC"
   form (G.704 Table 5A).

Top      ToC       Page 4 
3.1.  Use of ifTable for DS1 Layer

   Only the ifGeneralInformationGroup needs to be supported.

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

           ifDescr           See interfaces MIB [RFC2863].

           ifType            ds1(18)

           ifSpeed           Speed of line rate
                             DS1 - 1544000
                             J1  - 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 [RFC2863].

           ifOperStatus      See interfaces MIB [RFC2863].

           ifLastChange      See interfaces MIB [RFC2863].

           ifName            See interfaces MIB [RFC2863].

           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
                              cases such as DS1/E1 over AAL1/ATM where
                              false(2) is appropriate.

Top      ToC       Page 5 
3.2.  Usage Guidelines

3.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
   Channel Service Units (CSUs).  This section now describes how to use
   the 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, i.e., 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 High-Level Data Link Control (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 and 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.

Top      ToC       Page 6 
   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 as follows:

           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.

Top      ToC       Page 7 
          ifStackTable Entries

          HigherLayer   LowerLayer
           2             6
           3             7
           4             8
           5             9
           6             10
           7             11
           8             12
           9             13

   If the CSU shelf is managed by itself by a local SNMP agent, the
   situation would be identical, except the Ethernet and the four 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

3.2.2.  Usage of ifStackTable for DS1/J1/E1 on DS2/E2

   An example is given of how DS1/J1/E1 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.

Top      ToC       Page 8 
           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

3.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 implementer 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:

Top      ToC       Page 9 
           dsx0ChanMappingTable Entries

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

3.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 implementer use the objects correctly.

   Assume that a DS3 (with ifIndex 1) is channelized into DS2s.  The
   object dsx3Channelization [RFC3896] 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

Top      ToC       Page 10 
3.2.5.  Usage of Loopbacks

   This section discusses the behavior 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

   The remote end can also request loopbacks either through the Facility
   Data Link (FDL) channel if ESF or inband if D4.  The loopbacks that
   can be requested 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 applied
   to an interface.  This object, which is a bitmap, will have bits
   turned on that 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.

3.3.  Objectives of This MIB Module

   There are numerous things that could be included in a MIB for DS1
   signals:  the management of multiplexers, CSUs, Data Service Units
   (DSUs), and the like.  The intent of this document is to facilitate
   the common management of all devices with DS1, J1, E1, DS2, or E2
   interfaces.  As such, a design decision was made up front to very

Top      ToC       Page 11 
   closely align the MIB with the set of objects that can generally be
   read from these types of devices that are currently deployed.

   J2 interfaces are not supported by this MIB.

3.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 latest
   ANSI T1.231 standard [ANSI-T1.231].  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.

3.4.1.  Error Events

   Bipolar Violation (BPV) Error Event
      A BPV error event for an AMI-coded (AMI stands for Alternate Mark
      Inversion) signal is the occurrence of a pulse of the same
      polarity as the previous pulse (see T1.231, Section 4.2.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 4.2.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 4.6.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 4.6.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 4.2.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.

Top      ToC       Page 12 
3.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 4.2.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 [CCITT-G.706]).

      For DS2 links, an Out of Frame defect is declared when seven or
      more consecutive errored framing patterns (four multiframe) are
      received.  The OOF is cleared when three 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 a 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 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 [ITU-T-O.162], Section 3.3.2).

Top      ToC       Page 13 
      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 [ITU-T-G.775] Section 5.5:

      -  a DS2 AIS defect is detected when the incoming signal has two
         or less zeroes in a sequence of 3156 bits (0.5 ms).

      -  a DS2 AIS defect is cleared when the incoming signal has three
         or more zeroes in a sequence of 3156 bits (0.5 ms).

3.4.3.  Performance Parameters

   All performance parameters are accumulated in 15-minute intervals,
   and up to 96 intervals (24 hours' worth) are kept by an agent.  Fewer
   than 96 intervals of data will 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 a fixed relationship
   between the start of a 15-minute interval and any wall clock;
   however, some agents may align the 15-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
   occur across a 15-minute interval boundary.  See Unavailable Second
   discussion later in this section.

   Line Errored Second (LES)
      A Line Errored Second is a second in which one or more Line Coding
      Violation error events were detected. (Also known as ES-L; see
      T1.231, Section 4.6.1.2.)

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

Top      ToC       Page 14 
   Errored Second (ES)
      For ESF and E1-CRC links, an Errored Second is a second with one
      or more Path Coding Violations OR one or more Out of Frame defects
      OR one or more Controlled Slip events OR a detected AIS defect.
      (See T1.231, Section 4.6.2.2 and G.826 [ITU-T-G.826], 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.

   Bursty Errored Second (BES)
      A Bursty Errored Second (also known as Errored Second type B in
      T1.231, Section 4.6.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 Second (SES)
      A Severely Errored Second for ESF signals is a second with 320 or
      more Path Coding Violation error events OR one or more Out of
      Frame defects OR a detected AIS defect (see T1.231, Section
      4.6.2.5).

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

      For E1-noCRC signals, a Severely Errored Second is 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 4.6.2.6.)

Top      ToC       Page 15 
   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 [CCITT-G.821]).

      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 that are not Unavailable as described
      below.

   Unavailable Second (UAS)
      Unavailable Seconds (UASs) 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 10-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,

Top      ToC       Page 16 
      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.

   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
   that 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 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.

Top      ToC       Page 17 
3.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.

   Far End Alarm Failure
      The Far End Alarm failure is also known as "Yellow Alarm" in the
      DS1 and J1 cases, "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 five seconds.
      The Far End Alarm failure is not declared for D4 links when a Loss
      of Signal is detected.  In J1 the 12th F-bit is set to 1.

      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 DS1 the patterns is FF00 and for J1
      the pattern is FFFF.

      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 16-bit 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.

Top      ToC       Page 18 
   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
      4.3.1.2.2).

      An AIS defect at a 6312-kbit/s (G.704) interface is detected when
      the incoming signal has two or less zeroes in a sequence of 3156
      bits (0.5ms).

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

   Loss Of Frame (LOF) 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
      [AT&T-TR-62411].

      For E1 links, the Loss of Frame failure is declared when an OOF
      defect is detected.

   Loss Of Signal (LOS) 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.

Top      ToC       Page 19 
      A signal with "transitions" corresponds to a G.703-compliant
      signal.

   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 [CCITT-G.732] 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 failure is declared when the incoming signal
      of the 6,312-kbps frame payload (time-slots 1 through 96) has two
      or less zeroes 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 has three or more zeroes in a sequence of 3072 bits
      (0.5 ms).

   DS2 Performance Threshold Failure
      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 declared when the bit
      error ratio exceeds 10^-4 (Performance Threshold), and the DS2

Top      ToC       Page 20 
      Performance Threshold failure is cleared when the bit error ratio
      decreases to less than 10^-6."

3.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 (see M.1400 [ITU-T-M.1400] for additional
      information).

   Proxy
      In this document, the word proxy is meant to indicate an
      application that receives SNMP messages and replies to them on
      behalf of the devices that implement the actual DS1/E1 interfaces.
      The proxy may have already collected the information about the
      DS1/J1/E1 interfaces into its local database and may not
      necessarily forward the requests to the actual DS1/J1/E1
      interface.  It is expected in such an application that there are
      periods of time where the proxy is not communicating with the
      DS1/J1/E1 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 20 continued on part 2)

Next RFC Part