RFC 3896 - Definitions of Managed Objects for the DS3/E3 Int(2)

时间:2006-10-31 来源: 作者: 点击:
theaccumulationperiod.AnEXZincrementstheLCVbyone regardlessofthelengthofthezerostring.(Alsoknownas CV-L.SeeT1.231section7.4.1.1.) P-bitCodingViolation(PCV)ErrorEvent ForallDS3applications,acodingviol
  
         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.

   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

           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

   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.

   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)

           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.

3.  Object Definitions

   DS3-MIB DEFINITIONS ::= BEGIN

   IMPORTS
        MODULE-IDENTITY, OBJECT-TYPE,
        NOTIFICATION-TYPE, transmission
             FROM SNMPv2-SMI                    -- [RFC2578]
        DisplayString, TimeStamp, TruthValue
             FROM SNMPv2-TC                     -- [RFC2579]
        MODULE-COMPLIANCE, OBJECT-GROUP,
        NOTIFICATION-GROUP
             FROM SNMPv2-CONF                   -- [RFC2580]
        InterfaceIndex
             FROM IF-MIB                        -- [RFC2863]
        PerfCurrentCount, PerfIntervalCount,
        PerfTotalCount
             FROM PerfHist-TC-MIB;              -- [RFC3593]

   ds3 MODULE-IDENTITY
       LAST-UPDATED "200409080000Z"  -- September 08, 2004
       ORGANIZATION "IETF AToM MIB Working Group"
       CONTACT-INFO
         "WG charter:
            http://www.ietf.org/html.charters/atommib-charter.html

          Mailing Lists:
            General Discussion: atommib@research.telcordia.com
            To Subscribe: atommib-request@research.telcordia.com

          Editor: Orly Nicklass

          Postal: RAD Data Communications, Ltd.
                  Ziv Tower, 24 Roul Walenberg
                  Tel Aviv, Israel, 69719

                  Tel: +9723 765 9969
          E-mail: orly_n@rad.com"

       DESCRIPTION
            "The is the MIB module that describes
             DS3 and E3 interfaces objects.

             Copyright (c) The Internet Society (2004).  This
             version of this MIB module is part of RFC 3896;
             see the RFC itself for full legal notices."

       REVISION "200409080000Z"  -- September 08, 2004

        DESCRIPTION
             "The RFC 3896 version of this MIB module.
             The key changes made to this MIB module
             since its publication in RFC 2496 are as follows:

         (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
             thenear end definition, the far end definition and with
             RFC 3593.

         (5) Add new value, dsx3M13, to dsx3LineType."

        REVISION "199808012130Z"

        DESCRIPTION
             "The RFC 2496 version of this MIB module.
             The key changes made to this MIB module
             since its publication in RFC 1407 are as follows:

            (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."

       REVISION "199301252028Z"
       DESCRIPTION
            "Initial version, published as RFC 1407."
       ::= { transmission 30 }

   -- The DS3/E3 Near End Group

   -- The DS3/E3 Near End Group consists of four tables:
   --    DS3/E3 Configuration
   --    DS3/E3 Current
   --    DS3/E3 Interval
   --    DS3/E3 Total

   -- the DS3/E3 Configuration Table

   dsx3ConfigTable OBJECT-TYPE
        SYNTAX  SEQUENCE OF Dsx3ConfigEntry
        MAX-ACCESS  not-accessible
        STATUS  current
        DESCRIPTION
               "The DS3/E3 Configuration table."
        ::= { ds3 5 }

   dsx3ConfigEntry OBJECT-TYPE
        SYNTAX  Dsx3ConfigEntry
        MAX-ACCESS  not-accessible
        STATUS  current
        DESCRIPTION
               "An entry in the DS3/E3 Configuration table."
        INDEX   { dsx3LineIndex }
        ::= { dsx3ConfigTable 1 }

   Dsx3ConfigEntry ::=
        SEQUENCE {
            dsx3LineIndex                        InterfaceIndex,
            dsx3IfIndex                          InterfaceIndex,
            dsx3TimeElapsed                      INTEGER,
            dsx3ValidIntervals                   INTEGER,
            dsx3LineType                         INTEGER,
            dsx3LineCoding                       INTEGER,
            dsx3SendCode                         INTEGER,
            dsx3CircuitIdentifier                DisplayString,
            dsx3LoopbackConfig                   INTEGER,
            dsx3LineStatus                       INTEGER,
            dsx3TransmitClockSource              INTEGER,
            dsx3InvalidIntervals                 INTEGER,
------分隔线----------------------------
顶一下
(0)
0%
踩一下
(0)
0%
------分隔线----------------------------
最新评论 查看所有评论
发表评论 查看所有评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
用户名: 密码: 验证码:
推荐内容