rfc2495.txt

RFC 的详细文档！

       Bipolar Violation (BPV) or Excessive Zeroes (EXZ) Error Event.
       (Also known as CV-L; See T1.231 Section 6.5.1.1)

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

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

2.4.2.  Performance Defects

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

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

       For E1 links, an Out Of Frame defect is declared when three
       consecutive frame alignment signals have been received with an
       error (see G.706 Section 4.1 [26]).



Fowler, Ed.                 Standards Track                    [Page 12]

RFC 2495                   DS1/E1/DS2/E2 MIB                January 1999


       For DS2 links, an Out of Frame defect is declared when 7 or more
       consecutive errored framing patterns (4 multiframe) are received.
       The LOF is cleared when 3 or more consecutive correct framing
       patterns are received.

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

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

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

   Alarm Indication Signal (AIS) Defect
       For D4 and ESF links, the 'all ones' condition is detected at a
       DS1 line interface upon observing an unframed signal with a one's
       density of at least 99.9% present for a time equal to or greater
       than T, where 3 ms <= T <= 75 ms.  The AIS is terminated upon
       observing a signal not meeting the one's density or the unframed
       signal criteria for a period equal to or greater than than T.
       (See G.775, Section 5.4)

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

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

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








Fowler, Ed.                 Standards Track                    [Page 13]

RFC 2495                   DS1/E1/DS2/E2 MIB                January 1999


2.4.3.  Performance Parameters

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

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

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

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

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

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

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

        This is not incremented during an Unavailable Second.









Fowler, Ed.                 Standards Track                    [Page 14]

RFC 2495                   DS1/E1/DS2/E2 MIB                January 1999


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

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

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

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

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

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

        Controlled slips are not included in this parameter.

        This is not incremented during an Unavailable Second.

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

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

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




Fowler, Ed.                 Standards Track                    [Page 15]

RFC 2495                   DS1/E1/DS2/E2 MIB                January 1999


    Unavailable Seconds (UAS)
        Unavailable Seconds (UAS) are calculated by counting the number
        of seconds that the interface is unavailable.  The DS1 interface
        is said to be unavailable from the onset of 10 contiguous SESs,
        or the onset of the condition leading to a failure (see Failure
        States).  If the condition leading to the failure was
        immediately preceded by one or more contiguous SESs, then the
        DS1 interface unavailability starts from the onset of these
        SESs.  Once unavailable, and if no failure is present, the DS1
        interface becomes available at the onset of 10 contiguous
        seconds with no SESs.  Once unavailable, and if a failure is
        present, the DS1 interface becomes available at the onset of 10
        contiguous seconds with no SESs, if the failure clearing time is
        less than or equal to 10 seconds.  If the failure clearing time
        is more than 10 seconds, the DS1 interface becomes available at
        the onset of 10 contiguous seconds with no SESs, or the onset
        period leading to the successful clearing condition, whichever
        occurs later.  With respect to the DS1 error counts, all
        counters are incremented while the DS1 interface is deemed
        available.  While the interface is deemed unavailable, the only
        count that is incremented is UASs.

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

        The agent may instead choose to delay updates to the various
        statistics by 10 seconds in order to avoid retroactive
        adjustments to the counters.  A way to do this is sketched in
        Appendix B.




Fowler, Ed.                 Standards Track                    [Page 16]

RFC 2495                   DS1/E1/DS2/E2 MIB                January 1999


        In any case, a linkDown trap shall be sent only after the agent
        has determined for certain that the unavailable state has been
        entered, but the time on the trap will be that of the first UAS
        (i.e., 10 seconds earlier).  A linkUp trap shall be handled
        similarly.

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

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

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

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

   This approach is further described in Appendix B.

2.4.4.  Failure States

   The following failure states are received, or detected failures, that
   are reported in the dsx1LineStatus object.  When a DS1 interface
   would, if ever, produce the conditions leading to the failure state
   is described in the appropriate specification.







Fowler, Ed.                 Standards Track                    [Page 17]

RFC 2495                   DS1/E1/DS2/E2 MIB                January 1999


    Far End Alarm Failure
        The Far End Alarm failure is also known as "Yellow Alarm" in the