Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3896

Definitions of Managed Objects for the DS3/E3 Interface Type

Pages: 63
Proposed Standard
Obsoletes:  2496
Part 1 of 3 – Pages 1 to 16
None   None   Next

Top   ToC   RFC3896 - Page 1
Network Working Group                                   O. Nicklass, Ed.
Request for Comments: 3896                 RAD Data Communications, Ltd.
Obsoletes: 2496                                           September 2004
Category: Standards Track


      Definitions of Managed Objects for the DS3/E3 Interface Type

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 (2004).

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

Table of Contents

1. The Internet Standard Management Framework. . . . . . . . . . 2 1.1. Changes from RFC 2496 . . . . . . . . . . . . . . . . . 2 1.2. Changes from RFC 1407 . . . . . . . . . . . . . . . . . 3 1.3. Companion Documents . . . . . . . . . . . . . . . . . . 4 2. Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Use of ifTable for DS3 Layer . . . . . . . . . . . . . 4 2.2. Usage Guidelines. . . . . . . . . . . . . . . . . . . . 5 2.2.1. Usage of ifStackTable . . . . . . . . . . . . . 5 2.2.2. Usage of Channelization for DS3, DS1, DS0 . . . 7 2.2.3. Usage of Channelization for DS3, DS2, DS1 . . . 8 2.2.4. Usage of Loopbacks . . . . . . . . . . . . . . 9 2.3. Objectives of this MIB Module . . . . . . . . . . . . . 10 2.4. DS3/E3 Terminology . . . . . . . . . . . . . . . . . . 10 2.4.1. Error Events. . . . . . . . . . . . . . . . . . 10 2.4.2. Performance Parameters. . . . . . . . . . . . . 11 2.4.3. Performance Defects . . . . . . . . . . . . . . 14
Top   ToC   RFC3896 - Page 2
              2.4.4.  Other Terms . . . . . . . . . . . . . . . . . . 16
   3.  Object Definitions . . . . . . . . . . . . . . . . . . . . . . 16
   4.  Appendix A - Use of the dsx3IfIndex and dsx3LineIndex. . . . . 54
   5.  Appendix B - The delay approach to Unavailable Seconds . . . . 56
   6.  Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 58
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 58
       7.1.  Normative References . . . . . . . . . . . . . . . . . . 58
       7.2.  Informative References . . . . . . . . . . . . . . . . . 59
   8.  Security Considerations. . . . . . . . . . . . . . . . . . . . 60
   9.  Author's Address . . . . . . . . . . . . . . . . . . . . . . . 62
   10. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 63

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

1.1. Changes from RFC 2496

The changes from [RFC2496] are the following: (1) The dsx3FracIfIndex SYNTAX matches the description range. (2) Reference was added to Circuit Identifier object. (3) Usage of ifStackTable section was updated. (4) Align the DESCRIPTION clauses of few statistic objects with the near end definition, the far end definition and with [RFC3593]. (5) Add new value, dsx3M13, to dsx3LineType.
Top   ToC   RFC3896 - Page 3

1.2. Changes from RFC 1407

The changes from RFC 1407 are the following: (1) The Fractional Table has been deprecated. (2) This document uses SMIv2. (3) Values are given for ifTable and ifXTable. (4) Example usage of ifStackTable is included. (5) dsx3IfIndex has been deprecated. (6) 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. (7) An inward loopback has been added. (8) Additional lineStatus bits have been added for Near End in Unavailable Signal State, Carrier Equipment Out of Service. (9) A read-write line Length object has been added. (10) Added a lineStatus last change, trap and enabler. (11) Textual Conventions for statistics objects have been used. (12) A new object, dsx3LoopbackStatus, has been introduced to reflect the loopbacks established on a DS3/E3 interface and the source to the requests. dsx3LoopbackConfig continues to be the desired loopback state while dsx3LoopbackStatus reflects the actual state. (13) A dual loopback has been added to allow the setting of an inward loopback and a line loopback at the same time. (14) An object has been added to indicated whether or not this is a channelized DS3/E3. (15) A new object has been added to indicate which DS1 is to set for remote loopback.
Top   ToC   RFC3896 - Page 4

1.3. Companion Documents

This document is a companion to the documents that define Managed Objects for the DS0 [RFC2494], DS1/E1/DS2/E2 [RFC3895], and Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) [RFC3592] Interface Types.

2. Overview

These objects are used when the particular media being used to realize an interface is a DS3/E3 interface. At present, this applies to these values of the ifType variable in the Internet-standard MIB: ds3 (30) The DS3 definitions contained herein are based on the DS3 specifications in ANSI T1.102-1987 [ANSI-T1.102], ANSI T1.107-1988 [ANSI-T1.107], ANSI T1.107a-1990 [ANSI-T1.107a], and ANSI T1.404-1989 [ANSI-T1.404]. The E3 definitions contained herein are based on the E3 specifications in CCITT G.751 [CCITT-G.751] and ETSI T/NA(91)18 [ETSI-T/NA(91)18].

2.1. Use of ifTable for DS3 Layer

Only the ifGeneralInformationGroup needs to be supported. ifTable Object Use for DS3 Layer =================================================================== ifIndex Interface index. ifDescr See interfaces MIB [RFC2863] ifType ds3(30) ifSpeed Speed of line rate DS3 - 44736000 E3 - 34368000 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]
Top   ToC   RFC3896 - Page 5
           ifName            See interfaces MIB [RFC2863]

           ifLinkUpDownTrapEnable   Set to enabled(1).

           ifHighSpeed       Speed of line in Mega-bits per second
                             (either 45 or 34)

           ifConnectorPresent Set to true(1) normally, except for
                              cases such as DS3/E3 over AAL1/ATM where
                              false(2) is appropriate

2.2. Usage Guidelines

2.2.1. Usage of ifStackTable

The object dsx3IfIndex 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 dsx3IfIndex and dsx3LineIndex 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 DS3 is attached to that DS3. 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 DS3, entire DS3 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 DS3/E3 interfaces (e.g., a router). The Agent represents both the host and the DS3/E3 device.
Top   ToC   RFC3896 - 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    |     |  44.736 MBPS  |   ds3 M13    Line#A | ds3 C-bit Parity
   |t    |  R  |---------------+ - - - - -  - - -  - +------>
   |h    |     |               |                     |
   |e    |  O  |  44.736 MBPS  |   ds3 M13    Line#B | ds3 C-bit Parity
   |r    |     |---------------+ - - - - - - - - - - +------>
   |n    |  U  |               |                     |
   |e    |     |  44.736 MBPS  |   ds3 M13    Line#C | ds3 C-bit Parity
   |t    |  T  |---------------+ - - - -- -- - - - - +------>
   |     |     |               |                     |
   |-----|  E  |  44.736 MBPS  |   ds3 M13    Line#D | ds3 C-bit Parity
   |     |     |---------------+ -  - - - -- - - - - +------>
   |     |  R  |               |_____________________|
   |     |     |
   |     +-----+

   The assignment of the index values could for example be:

           ifIndex  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
Top   ToC   RFC3896 - Page 7
   The ifStackTable is then used to show the relationships between the
   various DS3 interfaces.

           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 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 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.
Top   ToC   RFC3896 - Page 8
   Assume that a DS3 (with ifIndex 1) is Channelized into DS1s (without
   DS2s).  The object dsx3Channelization is set to enabledDs1.  When
   this object is set to enabledDS1, 28 ifEntries of type DS1 will be
   created by the agent. If dsx3Channelization is set to disabled, then
   the DS1s are destroyed.

   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.  There will be
   24 DS0s in the ifTable for each DS1.  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 [RFC2494],
   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.3. 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. 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 [RFC3895], there will be an entry in the dsx1ChanMappingTable for each DS2. The entries will be as follows:
Top   ToC   RFC3896 - Page 9
           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.4. Usage of Loopbacks

This section discusses the behaviour of objects related to loopbacks. The object dsx3LoopbackConfig 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 lookbacks either through the FDL channel if ESF or inband if D4. The loopbacks that can be requested this way are: LineLoopback PayloadLoopback (if ESF framing) NoLoopback
Top   ToC   RFC3896 - Page 10
   To model the current state of loopbacks on a DS3 interface, the
   object dsx3LoopbackStatus defines which loopback is currently applied
   to an interface.  This object, 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 DS3/E3 signals: the management of multiplexors, CSUs, DSUs, and the like. The intent of this document is to facilitate the common management of all devices with DS3/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 DS3/E3 devices that are currently deployed.

2.4. DS3/E3 Terminology

The terminology used in this document to describe error conditions on a DS3 interface as monitored by a DS3 device are based on the late but not final draft of what became the 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.

2.4.1. Error Events

Bipolar Violation (BPV) Error Event A bipolar violation error event, for B3ZS(HDB3)-coded signals, is the occurrence of a pulse of the same polarity as the previous pulse without being part of the zero substitution code, B3ZS(HDB3). For B3ZS(HDB3)-coded signals, a bipolar violation error event may also include other error patterns such as: three(four) or more consecutive zeros and incorrect polarity (See T1.231 section 7.1.1.1.1).
Top   ToC   RFC3896 - Page 11
   Excessive Zeros (EXZ) Error Event
         An EXZ is the occurrence of any zero string length equal to or
         greater than 3 for B3ZS, or greater than 4 for HDB3 (See T1.231
         section 7.1.1.1.2).

   Line Coding Violation (LCV) Error Event
         This parameter is a count of both BPVs and EXZs occurring over
         the accumulation period.  An EXZ increments the LCV by one
         regardless of the length of the zero string. (Also known as
         CV-L.  See T1.231 section 7.4.1.1.)

   P-bit Coding Violation (PCV) Error Event
         For all DS3 applications, a coding violation error event is a
         P-bit Parity Error event.  A P-bit Parity Error event is the
         occurrence of a received P-bit code on the DS3 M-frame that is
         not identical to the corresponding locally-calculated code (See
         T1.231 section 7.1.1.2.1).

   C-bit Coding Violation (CCV) Error Event
         For C-bit Parity and SYNTRAN DS3 applications, this is the
         count of coding violations reported via the C-bits.  For C-bit
         Parity, it is a count of CP-bit parity errors occurring in the
         accumulation interval.  For SYNTRAN, it is a count of CRC-9
         errors occurring in the accumulation interval (See T1.231
         section 7.1.1.2.2).

2.4.2. 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 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. 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.
Top   ToC   RFC3896 - Page 12
   Line Errored Seconds (LES)
           A Line Errored Second is a second in which one or more CV
           occurred OR one or more LOS defects.  (Also known as ES-L.
           See T1.231 section 7.4.1.2.)

   P-bit Errored Seconds (PES)
           An PES is a second with one or more PCVs OR one or more Out
           of Frame defects OR a detected incoming AIS.  This gauge is
           not incremented when UASs are counted.  (Also known as ESP-P.
           See T1.231 section 7.4.2.2.)

   P-bit Severely Errored Seconds (PSES)
           A PSES is a second with 44 or more PCVs OR one or more Out of
           Frame defects OR a detected incoming AIS.  This gauge is not
           incremented when UASs are counted.  (Also known as SESP-P.
           See T1.231 section 7.4.2.5.)

   C-bit Errored Seconds (CES)
           An CES is a second with one or more CCVs OR one or more Out
           of Frame defects OR a detected incoming AIS.  This count is
           only for the SYNTRAN and C-bit Parity DS3 applications.  This
           gauge is not incremented when UASs are counted. (Also known
           as ESCP-P.  See T1.231 section 7.4.2.2.)

   C-bit Severely Errored Seconds (CSES)
           A CSES is a second with 44 or more CCVs OR one or more Out of
           Frame defects OR a detected incoming AIS.  This count is only
           for the SYNTRAN and C-bit Parity DS3 applications.  This
           gauge is not incremented when UASs are counted. (Also known
           as SESCP-P.  See T1.231 section 7.4.2.5.)

   Severely Errored Framing Seconds (SEFS)
           A SEFS is a second with one or more Out of Frame defects OR a
           detected incoming AIS.  This item is not incremented during
           unavailable seconds.  (Also known as SAS-P.  See T1.231
           section 7.4.2.6.)

   Unavailable Seconds (UAS)
           UAS are calculated by counting the number of seconds that the
           interface is unavailable.  The DS3 interface is said to be
           unavailable from the onset of 10 contiguous PSESs, 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 PSESs, then
           the DS3 interface unavailability starts from the onset of
           these PSESs.  Once unavailable, and if no failure is present,
           the DS3 interface becomes available at the onset of 10
           contiguous seconds with no PSESs.  Once unavailable, and if a
Top   ToC   RFC3896 - Page 13
           failure is present, the DS3 interface becomes available at
           the onset of 10 contiguous seconds with no PSESs, if the
           failure clearing time is less than or equal to 10 seconds.
           If the failure clearing time is more than 10 seconds, the DS3
           interface becomes available at the onset of 10 contiguous
           seconds with no PSESs, or the onset period leading to the
           successful clearing condition, whichever occurs later.  With
           respect to the DS3 error counts, all counters are incremented
           while the DS3 interface is deemed available.  While the
           interface is deemed unavailable, the only count that is
           incremented is UASs.

           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 PES, PSES, CES, and CSES 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, CCV, and SEFS count as necessary
           since these parameters are not accumulated during unavailable
           time.  Similarly, it must be prepared to retroactively
           decrease the UAS count by 10 and increase the PES, CES, PCV,
           and CCV 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 PCV, CCV, PES, CES, PSES, CSEC, SEFS, and UAS counts for
           the PREVIOUS interval must be adjusted.  In this case
           successive GETs of the affected dsx3IntervalPSESs and
           dsx3IntervalUASs 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
Top   ToC   RFC3896 - Page 14
   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 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.3. Performance Defects

Failure States: The Remote Alarm Indication (RAI) failure, in SYNTRAN applications, is declared after detecting the Yellow Alarm Signal on the alarm channel. See ANSI T1.107a-1990 [ANSI- T1.107a]. The Remote Alarm Indication failure, in C-bit Parity DS3 applications, is declared as soon as the presence of either one or two alarm signals are detected on the Far End Alarm Channel. See [ANSI-T1.107]. The Remote Alarm Indication failure may also be declared after detecting the far-end SEF/AIS defect (aka yellow). The Remote Alarm Indication failure is cleared as soon as the presence of the any of the above alarms are removed. Also, the incoming failure state is declared when a defect persists for at least 2-10 seconds. The defects are the following: Loss of Signal (LOS), an Out of Frame (OOF) or an incoming Alarm Indication Signal (AIS). The Failure State is cleared when the defect is absent for less than or equal to 20 seconds.
Top   ToC   RFC3896 - Page 15
   Far End SEF/AIS defect (aka yellow)
           A Far End SEF/AIS defect is the occurrence of the two X-bits
           in a M-frame set to zero.  The Far End SEF/AIS defect is
           terminated when the two X-bits in a M-frame are set to one.
           (Also known as SASCP-PFE.  See T1.231 section 7.4.4.2.6)

   Out of Frame (OOF) defect
           A DS3 OOF defect is detected when any three or more errors in
           sixteen or fewer consecutive F-bits occur within a DS3 M-
           frame.  An OOF defect may also be called a Severely Errored
           Frame (SEF) defect.  An OOF defect is cleared when reframe
           occurs.  A DS3 Loss of Frame (LOF) failure is declared when
           the DS3 OOF defect is consistent for 2 to 10 seconds.  The
           DS3 OOF defect ends when reframe occurs.  The DS3 LOF failure
           is cleared when the DS3 OOF defect is absent for 10 to 20
           seconds. (See T1.231 section 7.1.2.2.1)

           An E3 OOF defect is detected when four consecutive frame
           alignment signals have been incorrectly received in there
           predicted positions in an E3 signal.  E3 frame alignment
           occurs when the presence of three consecutive frame alignment
           signals have been detected.

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

   Alarm Indication Signal (AIS) defect
           The DS3 AIS is framed with "stuck stuffing."  This implies
           that it has a valid M-subframe alignments bits, M-frame
           alignment bits, and P bits.  The information bits are set to
           a 1010... sequence, starting with a one (1) after each M-
           subframe alignment bit, M-frame alignment bit, X bit, P bit,
           and C bit.  The C bits are all set to zero giving what is
           called "stuck stuffing."  The X bits are set to one.  The DS3
           AIS defect is declared after DS3 AIS is present in contiguous
           M-frames for a time equal to or greater than T, where 0.2 ms
           <= T <= 100 ms.  The DS3 AIS defect is terminated after AIS
           is absent in contiguous M-frames for a time equal to or
           greater than T.  (See T1.231 section 7.1.2.2.3)
Top   ToC   RFC3896 - Page 16
           The E3 binary content of the AIS is nominally a continuous
           stream of ones.  AIS detection and the application of
           consequent actions, should be completed within a time limit
           of 1 ms.

2.4.4. 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 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 16 continued on part 2)

Next Section