rfc2558.txt

RFC 的详细文档！

   Errored Seconds
        At each layer, an Errored Second (ES) is a second with one or
        more Coding Violations at that layer OR one or more incoming
        defects (e.g., SEF, LOS, AIS, LOP) at that layer has occurred.

   Severely Errored Seconds
        According to [22][31][32][34][35] at each layer, an Severely
        Errored Second (SES) is a second with x or more CVs at that
        layer, or a second during which at least one or more incoming
        defects at that layer has occurred.  The values of x in
        RFC1595[30] were based on [22] and [32] (see Appendix B). These
        values have subsequently been relaxed in [31][34][35]. In
        addition, according to G.826 [33] SESs are measured as a
        percentage of errored blocks.

        To deal with these sets of definitions this memo defines an
        object sonetSESThresholdSet that determines the correct
        interpretation of SES. For backward compatibility, if this
        object is not implemented the interpretation of Appendix B shall
        apply.  Otherwise, a more recent interpretation is suggested.
        An agent is not required to support all sets of definitions.

        Note that if a manager changes the value of this object all SES
        statistics collected prior to this change shall be invalidated.





Tesink                      Standards Track                    [Page 13]

RFC 2558                   SONET/SDH Objects                  March 1999


   Severely Errored Framing Seconds
        A Severely Errored Framing Second (SEFS) is a second containing
        one or more SEF events.  This counter is only counted at the
        Section Layer.

   Unavailable Seconds
        At the Line, Path, and VT layers, an unavailable second is
        calculated by counting the number of seconds that the interface
        is unavailable.  At each layer, the SONET/SDH interface is said
        to be unavailable at the onset of 10 contiguous SESs.  The 10
        SESs are included in unavailable time.  Once unavailable, the
        SONET/SDH interface becomes available at the onset of 10
        contiguous seconds with no SESs.  The 10 seconds with no SESs
        are excluded from unavailable time.  With respect to the
        SONET/SDH error counts at each layer, all counters at that layer
        are incremented while the SONET/SDH interface is deemed
        available at that layer.  While the interface is deemed
        unavailable at that layer, the only count that is incremented is
        UASs at that layer.

        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, 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 reduce the
        CV count by the number of violations counted since the onset of
        unavailable time.  The agent must be similarly prepared to
        retroactively decrease the UAS count by 10 and increase the ES
        and CV 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
        CV, ES, SES, SEFS, and UAS counts the PREVIOUS interval must be
        adjusted.  In this case successive GETs of the affected
        sonetPathIntervalSES and sonetPathIntervalUAS objects (and the
        analogous Line and VT objects also) objects will return
        differing values if the first GET occurs during the first few
        seconds of the window.

        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



Tesink                      Standards Track                    [Page 14]

RFC 2558                   SONET/SDH Objects                  March 1999


        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 A. An agent may
        choose to use this approach in lieu of retroactive adjustments
        to the counters.

        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.

   Unequipped
        If a Path or VT connection is not provisioned (idle) the SONET
        equipment will signal this state by transmitting the Path or VT
        Signal Label as follows:
        - byte C2 of the STS Path Overhead equal to 0 for an unequipped
        Path,
        - byte V5 of the VT Path Overhead equal to 0 for an unequipped
        VT.

   Signal Label Mismatch
        A Path or VT connection is not correctly provisioned if a
        received Path or VT Signal Label mismatch occurs.  A received
        Signal Label is considered mismatched if it does not equal
        either the locally provisioned value or the value 'equipped



Tesink                      Standards Track                    [Page 15]

RFC 2558                   SONET/SDH Objects                  March 1999


        non-specific' (1 hex). Note that any received non-zero Signal
        Label is considered a locally provisioned value of 'equipped
        non-specific'.  Only in-service, provisioned Path Terminating
        equipment can detect mismatched Signal labels. It is considered
        provisioned if it has been configured for a mapping and has been
        assigned signals to and from which the mapping takes place.
        While a Path is unequipped or has mismatched signal labels
        ES/SES counts continue, but these conditions do not themselves
        contribute to ES/SES.

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

4.  Object Definitions

SONET-MIB DEFINITIONS ::= BEGIN


IMPORTS
    MODULE-IDENTITY, OBJECT-TYPE,
    Integer32, transmission
          FROM SNMPv2-SMI
    DisplayString, TruthValue
          FROM SNMPv2-TC
    MODULE-COMPLIANCE, OBJECT-GROUP
          FROM SNMPv2-CONF
    ifIndex
          FROM IF-MIB
    PerfCurrentCount, PerfIntervalCount
          FROM PerfHist-TC-MIB;

--  This is the MIB module for the SONET/SDH Interface objects.


sonetMIB MODULE-IDENTITY
    LAST-UPDATED "9810190000Z"
    ORGANIZATION "IETF AToM MIB Working Group"
    CONTACT-INFO
      "Kaj Tesink
       Telcordia Technologies
       Tel: [phone]
       Fax: [phone]
       E-mail: [e-mail]."
    DESCRIPTION
         "The MIB module to describe
         SONET/SDH interfaces objects."



Tesink                      Standards Track                    [Page 16]

RFC 2558                   SONET/SDH Objects                  March 1999


    REVISION      "9810190000Z"
    DESCRIPTION
        "The key changes made to this MIB module
        since its initial publication in RFC 1595
        are as follows.

        (1) The MODULE-IDENTITY has been updated to reflect the
            changes to the MIB.

        (2) Where applicable, the textual conventions
            PerfCurrentCount and PerfIntervalCount from
            PerfHist-TC-MIB have been used in place of Gauge32.

        (3) An agent now has the option to delay updates to
            the various performance counts in lieu of performing
            retroactive adjustments upon entering into or exiting
            from unavailable time. This implementation option is
            described in Appendix A of this memo.

        (4) In order to make the SONET-MIB more useful for
            circuit provisioning, the formerly read-only objects
            sonetMediumType, sonetMediumLineCoding,
            sonetMediumLineType, and sonetMediumCircuitIdentifier
            have been given a MAX-ACCESS of read-write. The
            MIN-ACCESS remains read-only.

        (5) The DESCRIPTION clause for sonetMediumTimeElapsed has
            been updated to describe its behaviour if the duration
            of the current interval exceeds the maximum value.

        (6) The DESCRIPTION clause for sonetMediumValidIntervals
            has been updated to describe its behaviour when some
            intervals may be unavailable, and the object
            sonetMediumInvalidIntervals has been added to keep
            count of the number of missing intervals (if any).

        (7) The object sonetMediumLoopbackConfig has been added
            to enable or disable loopback configurations.

        (8) Because the error count thresholds for declaring
            severely errored seconds that are specified in ANSI
            T1.231-1993, ITU-T G.826-1995, and ANSI T1.231-1997
            are all different from each other and from the thresholds
            specified in RFC 1595, an enumerated INTEGER object
            sonetSESthresholdSet has been added to allow an agent
            to specify which threshold set is in use. Text has
            been added to Section 3 stating that if this object is
            not implemented the thresholds specified in RFC 1595



Tesink                      Standards Track                    [Page 17]

RFC 2558                   SONET/SDH Objects                  March 1999


            should be assumed, and the table containing those
            thresholds has been moved to Appendix B of this memo.

        (9) A column with SYNTAX TruthValue has been added to each
            interval table.  The purpose of the additional column
            is to indicate, for each interval, whether the data
            is valid in the sense intended by ANSI T1.231 clause
            9.1.2.2 [31][35]. The objects in question are:

                sonetSectionIntervalValidData
                sonetLineIntervalValidData
                sonetFarEndLineIntervalValidData
                sonetPathIntervalValidData
                sonetFarEndPathIntervalValidData
                sonetVTIntervalValidData
                sonetFarEndVTIntervalValidData

       (10) The ranges for sonetPathCurrentStatus and
            sonetVTCurrentStatus have been made consistent
            with the DESCRIPTION clauses.

       (11) The conformance information has been updated. Previous
            conformance information from RFC 1595 has been
            deprecated. Some typographical errors in the deprecated
            section have been corrected in order to prevent
            MIB compilation errors."

    REVISION      "9401030000Z"
    DESCRIPTION
        "The RFC1595 version of this MIB module."

    ::= { transmission 39 }


--  This is the MIB module for the SONET/SDH objects

sonetObjects      OBJECT IDENTIFIER ::= { sonetMIB 1 }

sonetObjectsPath  OBJECT IDENTIFIER ::= { sonetMIB 2 }

sonetObjectsVT    OBJECT IDENTIFIER ::= { sonetMIB 3 }


-- groups in the SONET/SDH MIB module

sonetMedium        OBJECT IDENTIFIER ::= { sonetObjects 1 }

sonetSection       OBJECT IDENTIFIER ::= { sonetObjects 2 }



Tesink                      Standards Track                    [Page 18]

RFC 2558                   SONET/SDH Objects                  March 1999


sonetLine          OBJECT IDENTIFIER ::= { sonetObjects 3 }

sonetFarEndLine    OBJECT IDENTIFIER ::= { sonetObjects 4 }

sonetPath          OBJECT IDENTIFIER ::= { sonetObjectsPath 1 }

sonetFarEndPath    OBJECT IDENTIFIER ::= { sonetObjectsPath 2 }

sonetVT            OBJECT IDENTIFIER ::= { sonetObjectsVT 1 }

sonetFarEndVT      OBJECT IDENTIFIER ::= { sonetObjectsVT 2 }

-- the SONET/SDH Medium group

-- SONET/SDH interfaces for some applications may be electrical
-- interfaces and not optical interfaces.  This group handles
-- the configuration information for both optical SONET/SDH
-- interfaces and electrical SONET/SDH interfaces.

sonetMediumTable OBJECT-TYPE
    SYNTAX  SEQUENCE OF SonetMediumEntry
    MAX-ACCESS  not-accessible
    STATUS  current
    DESCRIPTION
       "The SONET/SDH Medium table."
     ::= { sonetMedium 1 }

sonetMediumEntry OBJECT-TYPE
    SYNTAX  SonetMediumEntry
    MAX-ACCESS  not-accessible
    STATUS  current
    DESCRIPTION
       "An entry in the SONET/SDH Medium table."
    INDEX   { ifIndex }
     ::= { sonetMediumTable 1 }