tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 2558


Pages: 74
Top     in Index     Prev     Next
 

Definitions of Managed Objects for the SONET/SDH Interface Type

Part 1 of 3, p. 1 to 16
None       Next RFC Part

Obsoleted by:    3592
Obsoletes:    1595


Top       ToC       Page 1 
Network Working Group                                       K. Tesink
Request for Comments: 2558                     Telcordia Technologies
Obsoletes: 1595                                            March 1999
Category: Standards Track


                     Definitions of Managed Objects
                    for the SONET/SDH 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 (1999).  All Rights Reserved.

1.  Abstract

   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in TCP/IP-based internets.
   In particular, it defines objects for managing Synchronous Optical
   Network/Synchronous Digital Hierarchy (SONET/SDH) interfaces.  This
   document is a companion to the documents that define Managed Objects
   for the DS1/E1/DS2/E2 and DS3/E3 Interface Types [24][25].

   Textual Conventions used in this MIB are defined in [6] and [36].

   This memo replaces RFC 1595 [30]. Changes relative to RFC 1595 are
   summarized in the MIB module's REVISION clause.

Table of Contents

   1 Abstract ..............................................    1
   2 The SNMP Network Management Framework .................    2
   3 Overview ..............................................    3
   3.1 Use of the ifTable ..................................    4
   3.2 Use of ifTable for  SONET/SDH  Medium/Section/Line
       Layer ...............................................    5
   3.3 Use of ifTable for SONET/SDH Paths ..................    6
   3.4 Use of ifTable for SONET/SDH VTs/VCs ................    7
   3.5 SONET/SDH Terminology ...............................    8
   4 Object Definitions ....................................   16
   4.1 The SONET/SDH Medium Group ..........................   19

Top      ToC       Page 2 
   4.2 The SONET/SDH Section Group .........................   23
   4.2.1 The SONET/SDH Section Current Group ...............   23
   4.2.2 The SONET/SDH Section Interval Group ..............   26
   4.3 The SONET/SDH Line Group ............................   28
   4.3.1 The SONET/SDH Line Current Group ..................   28
   4.3.2 The SONET/SDH Line Interval Group .................   30
   4.4 The SONET/SDH Far End Line Group ....................   32
   4.4.1 The SONET/SDH Far End Line Current Group ..........   33
   4.4.2 The SONET/SDH Far End Line Interval Group .........   34
   4.5 The SONET/SDH Path Group ............................   37
   4.5.1 The SONET/SDH Path Current Group ..................   37
   4.5.2 The SONET/SDH Path Interval Group .................   39
   4.6 The SONET/SDH Far End Path Group ....................   42
   4.6.1 The SONET/SDH Far End Path Current Group ..........   42
   4.6.2 The SONET/SDH Far End Path Interval Group .........   44
   4.7 The SONET/SDH Virtual Tributary Group ...............   46
   4.7.1 The SONET/SDH VT Current Group ....................   46
   4.7.2 The SONET/SDH VT Interval Group ...................   49
   4.8 The SONET/SDH Far End VT Group ......................   51
   4.8.1 The SONET/SDH Far End VT Current Group ............   51
   4.8.2 The SONET/SDH Far End VT Interval Group ...........   53
   4.9 Conformance Information .............................   55
   4.10 Compliance Statements ..............................   56
   5 Acknowledgments .......................................   65
   6 Security Considerations ...............................   65
   7 References ............................................   66
   8 Author's Address ......................................   69
   9 Intellectual Property .................................   69
   Appendix A ..............................................   70
   Appendix B ..............................................   72
   Full Copyright Statement ................................   74

2.  The SNMP Network Management Framework

   The SNMP Management Framework presently consists of five major
   components:

   0    An overall architecture, described in RFC 2271 [1].

   0    Mechanisms for describing and naming objects and events for the
        purpose of management.  The first version of this Structure of
        Management Information (SMI) is called SMIv1 and described in
        STD 16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4].
        The second version, called SMIv2, is described in RFC 1902 [5],
        RFC 1903 [6] and RFC 1904 [7].

Top      ToC       Page 3 
   0    Message protocols for transferring management information.  The
        first version of the SNMP message protocol is called SNMPv1 and
        described in STD 15, RFC 1157 [8].  A second version of the SNMP
        message protocol, which is not an Internet standards track
        protocol, is called SNMPv2c and described in RFC 1901 [9] and
        RFC 1906 [10].  The third version of the message protocol is
        called SNMPv3 and described in RFC 1906 [10], RFC 2272 [11] and
        RFC 2274 [12].

   0    Protocol operations for accessing management information.  The
        first set of protocol operations and associated PDU formats is
        described in STD 15, RFC 1157 [8].  A second set of protocol
        operations and associated PDU formats is described in RFC 1905
        [13].

   0    A set of fundamental applications described in RFC 2273 [14] and
        the view-based access control mechanism described in RFC 2275
        [15].

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  Objects in the MIB are
   defined using the mechanisms defined in the SMI.

   This memo specifies a MIB module that is compliant to the SMIv2.  A
   MIB conforming to the SMIv1 can be produced through the appropriate
   translations.  The resulting translated MIB must be semantically
   equivalent, except where objects or events are omitted because no
   translation is possible (e.g., use of Counter64).  Some machine
   readable information in SMIv2 will be converted into textual
   descriptions in SMIv1 during the translation process.  However, this
   loss of machine readable information is not considered to change the
   semantics of the MIB.

3.  Overview

   These objects are used when the particular media being used to
   realize an interface is a SONET/SDH interface.  At present, this
   applies to these values of the ifType variable in the Internet-
   standard MIB:

        sonet (39), sonetPath (50), sonetVT (51)

   The definitions contained herein are based on the SONET/SDH
   specifications in ANSI T1.105 and T1.106-1988 [19][20][21] and CCITT
   G.707, 708, 709, and G.783 [26][27][28][29].

Top      ToC       Page 4 
3.1.  Use of the ifTable

   This section specifies how the MIB II interfaces group, as defined in
   [23], is used for SONET/SDH interfaces.  The SONET/SDH layers support
   several multiplexing possibilities.

   For example in SONET, an Synchronous Transport Signal 3 (STS-3) has 3
   SONET Paths, and a STS-3c has 1 SONET Path. Another example could be
   a STS-12 having 4 SONET STS-3c Paths.  Similarly, a SONET Synchronous
   Payload Envelope (SPE) can carry many Virtual Tributaries (VTs), for
   example, one SONET SPE can carry 28 VT1.5s.  It is important to note
   that an SPE and a VT in SONET is collectively referred to as a
   Virtual Container (VC) in SDH.  Also, an STS is called Synchronous
   Transport Module (STM) in SDH.

   Not all SONET/SDH equipment terminates all SONET/SDH layers.  For
   example, a SONET/SDH STE regenerator terminates SONET/SDH Sections
   only, and is transparent for all layers above that.  SONET/SDH Add-
   Drop multiplexers and Digital Cross Connect Systems terminate
   SONET/SDH Lines. SONET/SDH Terminal Multiplexers may also terminate
   SONET/SDH Paths and VTs/VCs.

   MIB II [16], as extended by [23], accommodates these cases by
   appropriate use of the MIB II system group, and the interfaces group.
   The system group can name and describe the type of managed resource.
   The interfaces group defines which SONET/SDH layers apply, how these
   layers are configured and multiplexed.  This is achieved by proper
   representation of SONET/SDH Layers by ifEntries as defined in [23],
   as follows:

Top      ToC       Page 5 
                 _____________________________
                |             |          |    |  >
                |             |          |    |  |
                |    VT 1     |..........|VT K|   > K ifEntries
                |             |          |    |  |
                |_____________|__________|____|  >
                |               |      |      |  >
                |               |      |      |  |
                |    Path 1     |......|Path L|   > L ifEntries
                |               |      |      |  |
                |_______________|______|______|  >
                |                             |  >
                |                             |  |
                |    Line                     |  |
                |                             |  |
                |_____________________________|  |
                |                             |  |
                |                             |  |
                |    Section Layer            |   > 1 ifEntry
                |                             |  |
                |_____________________________|  |
                |                             |  |
                |                             |  |
                |    Physical Medium Layer    |  |
                |                             |  |
                |_____________________________|  >

                Use of ifTable for a SONET/SDH port

   The exact configuration and multiplexing of the layers is maintained
   in the ifStackTable [23].

3.2.  Use of ifTable for SONET/SDH Medium/Section/Line Layer

   Only the ifGeneralInformationGroup needs to be supported.

   ifTable Object    Use for combined SONET/SDH
                     Medium/Section/Line Layer
   ======================================================================
    ifIndex           Interface index.

    ifDescr           SONET/SDH Medium/Section/Line

    ifType            sonet(39)

    ifSpeed           Speed of line rate for SONET/SDH,
                      (e.g., 155520000 bps).

Top      ToC       Page 6 
    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     Supports read-only access.
                      The desired administrative status of the
                      interface.

    ifOperStatus      The value testing(3) is not used.
                      This object assumes the value down(2),
                      if the objects sonetSectionCurrentStatus
                      and sonetLineCurrentStatus have
                      any other value than sonetSectionNoDefect(1)
                      and sonetLineNoDefect(1), respectively.

    ifLastChange      sysUpTime at the last change in ifOperStatus.

    ifName            Textual name of the interface or an OCTET STRING
                      of zero length.

    ifLinkUpDownTrapEnable   Default value is enabled(1).
                             Just read-only access may be supported.

    ifHighSpeed       Speed of line in Mega-bits per second
                      (e.g., 155 Mbps)

    ifConnectorPresent Set to true(1).

    ifAlias            The (non-volatile) alias name for this interface
                       as assigned by the network manager.

3.3.  Use of ifTable for SONET/SDH Paths

   Only the ifGeneralInformationGroup needs to be supported.

   ifTable Object    Use for SONET/SDH Paths
   =========================================
    ifIndex           Interface index.

    ifDescr           SONET/SDH Path

    ifType            sonetPath(50)

    ifSpeed           set to speed of SONET/SDH path
                      (e.g., an STS-1 path has a
                      rate of 50112000 bps.)

Top      ToC       Page 7 
    ifPhysAddress     Circuit Identifier or OCTET STRING of zero length.

    ifAdminStatus     Supports read-only access.
                      The desired administrative status of the
                      interface.

    ifOperStatus      This object assumes the value down(2),
                      if the object sonetPathCurrentStatus has
                      any other value than sonetPathNoDefect(1).

    ifLastChange      sysUpTime at the last change in ifOperStatus.

    ifName            Textual name of the interface or an OCTET STRING
                      of zero length.

    ifLinkUpDownTrapEnable   Default value is disabled(2).
                             Just read-only access may be supported.

    ifHighSpeed       Set to rate of SONET/SDH path
                      in Mega-bits per second.

    ifConnectorPresent Set to false(2).

    ifAlias            The (non-volatile) alias name for this interface
                       as assigned by the network manager.

3.4.  Use of ifTable for SONET/SDH VTs/VCs

   Only the ifGeneralInformationGroup needs to be supported.

   ifTable Object    Use for SONET/SDH VTs/VCs
   ===========================================
    ifIndex           Interface index.

    ifDescr           SONET/SDH VT/VC

    ifType            sonetVT(51)


    ifSpeed           Set to speed of VT/VC
                      (e.g., a VT1.5 has a rate of
                      1728000 bps.)

    ifPhysAddress     Circuit Identifier or OCTET STRING of zero length.

    ifAdminStatus     Supports read-only access.
                      The desired administrative status of the
                      interface.

Top      ToC       Page 8 
    ifOperStatus      This object assumes the value down(2),
                      if the object sonetVTCurrentStatus has
                      any other value than sonetVTNoDefect(1).

    ifLastChange      sysUpTime at the last change in ifOperStatus.

    ifName            Textual name of the interface or an OCTET STRING
                      of zero length.

    ifLinkUpDownTrapEnable   Default value is disabled(2).
                             Just read-only access may be supported.

    ifHighSpeed       Set to rate of VT in Mega-bits per second.

    ifConnectorPresent Set to false(2).

    ifAlias            The (non-volatile) alias name for this interface
                       as assigned by the network manager.

3.5.  SONET/SDH Terminology

   The terminology used in this document to describe error conditions on
   a SONET circuit as monitored by a SONET system are from the T1.231
   [22][31][35].  The terminology used in this document to describe
   error conditions on a SDH circuit as monitored by a SDH system are
   from the CCITT G.783 [29].  Only the SONET Performance Monitoring
   terminology is defined in this document.  The definitions for SDH
   Performance Monitoring terms are similar but not identical, and they
   can be found in [29].  If the definition in this document does not
   match the definition in the T1.231 document, the implementer should
   follow the definition described in this document.  In some cases
   other or additional references are used as compared with the ones
   cited above. This will be indicated in the text.

   Section Loss Of Frame Failure (Out of Frame Event, Severely
        Errored Frame Defect)
        An Out of Frame (OOF) event (or Severely Errored Frame defect)
        is the occurrence of four contiguous errored frame alignment
        words.  A frame alignment word occupies the A1 and A2 bytes of
        an STS frame, and is defined in T1.105.  The SEF defect is
        terminated when two contiguous error-free frame words are
        detected.  Any implementation of the frame recovery circuitry
        which achieves realignment following an OOF within the 250
        microsecond (two frames) interval implied by this definition is
        acceptable.

Top      ToC       Page 9 
        A Loss of Frame (LOF) defect is declared when an OOF/SEF defect
        persists for a period of 3 milliseconds.  The LOF defect is
        terminated when the incoming signal remains continuously in-
        frame for a period of 1 ms to 3 ms.

        A LOF failure is declared when the LOF defect persists for a
        period of 2.5 +/- 0.5 seconds, except when an LOS defect or
        failure is present.  The LOF failure is cleared when the LOS
        failure is declared, or when the LOF defect is absent for 10 +/-
        0.5 seconds.

   Loss of Signal
        The Loss of Signal (LOS) defect is declared when no transitions
        are detected on the incoming signal (before descrambling).  The
        LOS defect is detected  upon observing 2.3 to 100 microseconds
        of no transitions.  The LOS defect is cleared after a 125
        microsecond interval (one frame) during which no LOS defect is
        detected.

        The LOS failure is declared when the LOS defect persists for a
        period of 2.5 +/- 0.5 seconds, or if LOS defect is present when
        the criteria for LOF failure declaration have been met.  The LOS
        failure is cleared when the LOS defect is absent for a period of
        10 +/- 0.5 seconds.  Declaration of LOS failure clears any
        existing LOF failure.  Clearing the LOS failure allows immediate
        declaration of the LOF failure if conditions warrant.

   STS-Path Loss of Pointer
        A Loss of Pointer (LOP) defect is declared when either a valid
        pointer is not detected in eight consecutive frames, or when
        eight consecutive frames are detected with the New Data Flag
        (NDF) set to "1001" without a valid concatenation indicator (see
        ANSI T1.105).  A LOP defect is terminated when either a valid
        pointer with a normal NDF set to "0110", or a valid
        concatenation indicator is detected for three contiguous frames.
        Incoming STS-Path AIS shall not result in the declaration of a
        LOP defect.

        An STS-Path LOP failure is declared when the STS-Path LOP defect
        persists for a period of 2.5 +/- 0.5 seconds.  A STS-Path LOP
        failure is cleared when the STS-Path LOP defect is absent for 10
        +/- 0.5 seconds.

   VT Loss of Pointer
        A VT LOP defect is declared when either a valid pointer is not
        detected in eight consecutive VT superframes, or when eight
        consecutive VT superframes are detected with the NDF set to
        "1001" without a valid concatenation indicator.  A VT LOP defect

Top      ToC       Page 10 
        is terminated when either a valid pointer with a normal NDF set
        to "0110", or a valid concatenation indicator is detected for
        three contiguous VT superframes.  Incoming VT-Path AIS shall not
        result in declaring a VT LOP defect.

        A VT LOP failure is declared when the VT LOP defect persists for
        2.5 +/- 0.5 seconds.  A VT LOP failure is cleared when the VT
        LOP defect is absent for 10 +/- 0.5 seconds.

   Line Alarm Indication Signal
        A Line Alarm Indication Signal (L-AIS) is defined in ANSI
        T1.105.  The following criteria are specific to the L-AIS
        defect:

        --  Line AIS defect is detected as a "111" pattern in bits 6, 7,
        and 8 of the K2 byte in five consecutive frames.

        --  Line AIS defect is terminated when bits 6, 7, and 8 of the
        K2 byte do not contain the code "111" for five consecutive
        frames.

        A Line AIS failure is declared when the Line AIS defect persists
        for a period of 20.5 +/- 0.5 seconds.  A Line AIS failure is
        cleared when the Line AIS defect is absent for 10 +/- 0.5
        seconds.

   STS-Path Alarm Indication Signal
        The STS-Path Alarm Indication Signal (AIS) is defined in ANSI
        T1.105 as all ones in bytes H1, H2, and H3 as well as all ones
        in the entire STS SPE.  The following criteria are specific to
        the STS-Path AIS defect:

        -- STS-Path AIS defect is detected as all ones in bytes H1 and
        H2 in three contiguous frames.

        -- The STS-Path AIS defect is terminated when a valid STS
        Pointer is detected with the NDF set to "1001" (inverted) for
        one frame, or  "0110" (normal) for three contiguous frames.

        An STS-Path AIS failure is declared when the STS-Path AIS defect
        persists for 2.5 +/- 0.5 seconds.  An STS-Path AIS failure is
        cleared when the STS-Path AIS defect is absent for 10 +/- 0.5
        seconds.

   VT-Path Alarm Indication Signal
        The VT-Path Alarm Indication Signal (AIS) is only applicable for
        VTs in the floating mode of operation.  VT-Path AIS is used to
        alert the downstream VT Path Terminating Entity (PTE) of an

Top      ToC       Page 11 
        upstream failure.  Upon detection of a failure, Line AIS, or
        STS-Path AIS, an STS PTE will generate downstream VT-Path AIS if
        the STS Synchronous Payload Envelope (SPE) is carrying floating
        VTs.  VT-Path AIS is specified in ANSI T1.105 as all ones in
        bytes V1, V2, V3, and V4, as well as all ones in the entire VT
        SPE.  The following criteria are specific to VT-Path AIS defect:

        --  VT-Path AIS defect is detected by a VT PTE as all ones in
        bytes V1 and V2 in three contiguous VT superframes.

        --  VT-Path AIS defect is terminated when valid VT pointer with
        a valid VT size is detected with the NDF set to "1001"
        (inverted) for one VT superframe, or "0110" (normal) for three
        contiguous VT superframes are detected.

        A VT-Path AIS failure is declared when the VT-Path AIS defect
        persists for 2.5 +/- 0.5 seconds.  A VT-Path AIS failure is
        cleared when the VT-Path AIS defect is absent for 10 +/- 0.5
        seconds.

   Line Remote Defect Indication
        Line Remote Defect Indication (RDI) (aka Line FERF) signal is
        the occurrence of a "110" pattern in bit positions 6, 7, and 8
        of the K2 byte in STS-1 #1 of the STS-N signal.  Line RDI is
        defined in ANSI T1.105.  The following criteria are specific to
        Line RDI defect:

        --  Line RDI defect is a "110" code in bits 6, 7, and 8 of the
        K2 byte of in STS-1 #1 in x consecutive frames, where x = 5
        [31][35] or 10 [35].

        --  Line RDI defect is terminated when any code other than "110"
        is detected in bits 6, 7, and 8 of the K2 byte in x consecutive
        frames, where x = 5 [31][35] or 10 [35].

        A Line Remote Failure Indication (RFI) failure is declared when
        the incoming Line RDI defects lasts for 2.5 +/- 0.5 seconds.
        The Line RFI failure is cleared when no Line RDI defects are
        detected for 10 +/- 0.5 seconds.

   STS-Path Remote Defect Indication
        STS-Path RDI (aka STS-Path FERF) signal shall be generated
        within 100 milliseconds by the STS PTE upon detection of an AIS
        or LOP defect.  Transmission of the STS-Path RDI signal shall
        cease within 100 milliseconds when the STS PTE no longer detects
        STS-Path AIS or STS-Path LOP defect.  The STS-Path RDI  shall
        accurately report the presence or absence of STS-Path AIS or
        STS-Path LOP defects.  STS-Path RDI defect is defined in ANSI

Top      ToC       Page 12 
        T1.105.  The following requirements are specific to the STS-Path
        RDI defect:

        --  STS-Path RDI is detected by all STS PTEs.  STS-Path RDI is
        detected by the upstream STS PTE as a "1" in bit five of the
        Path Status byte (G1) for x consecutive frames, where x = 5 [31]
        or 10 [35].

        --  Removal of STS-Path Remote Defect Indication is detected by
        a "0" in bit 5 of the G1 byte in x consecutive frames, where x =
        5 [31] or 10 [35].

        An STS-Path Remote Failure Indication (RFI) failure is declared
        when the incoming STS-Path RDI defects lasts for 2.5 +/- 0.5
        seconds.  The STS-Path RFI failure is cleared when no STS-Path
        RDI defects are detected for 10 +/- 0.5 seconds.

   VT-Path Remote Defect Indication
        VT Path RDI (aka VT Path FERF) signal shall be generated within
        100 milliseconds by the VT PTE upon detection of a VT-Path AIS
        or LOP defect.  Transmission of the VT-Path RDI signal shall
        cease within 100 milliseconds when the VT PTE no longer detects
        VT-Path AIS or VT-Path LOP defect.  The VT-Path RDI  shall
        accurately report the presence or absence of VT-Path AIS or VT-
        Path LOP defects.  VT-Path RDI defect is defined in ANSI T1.105.
        The following requirements are specific to VT-Path RDI defect:

        --  VT-Path RDI defect is the occurrence of a "1" in bit 4 of
        the VT-Path Overhead byte (V5) in x consecutive frames, where x
        = 5 [31] or 10 [35].

        --  VT-Path RDI defect is terminated when a "0" is detected in
        bit 4 of the VT-Path Overhead byte (V5) for x consecutive
        frames, where x = 5 [31] or 10 [35].

        A VT-Path Remote Failure Indication (RFI) (derived) failure is
        declared when the incoming VT-Path RDI defects lasts for 2.5 +/-
        0.5 seconds.  The VT-Path RFI failure is cleared when no VT-Path
        RDI defects are detected for 10 +/- 0.5 seconds.

   VT-Path Remote Failure Indication
        The VT-Path RFI signal is only required for the case of byte
        synch mapped DS1s where the DS1 frame bit is not mapped.  The
        VT-Path RFI is specified in ANSI T1.105, where it is currently
        called VT path yellow.  When provided, the VT-Path RFI signal is
        used to indicate the occurrence of far-end failures.  When the
        VT-Path RFI is not provided, far-end failures are derived from
        local timing of the VT-Path RDI defect.  The VT-Path RFI failure

Top      ToC       Page 13 
        is declared within 5 ms of detecting the incoming VT-Path RFI
        Signal.  The VT-Path Remote Failure Indication (RFI) failure is
        cleared within 50 ms of detecting the removal of the incoming
        VT-Path RFI signal.

   Coding Violation
        Coding Violations (CV) are Bit Interleaved Parity (BIP) errors
        that are detected in the incoming signal.  CV counters are
        incremented for each BIP error detected.  That is, each BIP-8
        can detect up to eight errors per STS-N frame, with each error
        incrementing the CV counter.  Section CVs shall be collected
        using the BIP-8 in the B1 byte located in the Section Overhead
        of STS-1 #1.  Line CVs shall be collected using the BIP-8s in B2
        bytes located in the Line Overhead of each STS-1 (since all CVs
        on an STS-N line are counted together, this is equivalent to
        counting each error in the BIP-8*N contained in the B2 bytes of
        the STS-N Line Overhead).  Thus, on an STS-N signal, up to 8 x N
        CVs may occur in each frame.  Path CVs shall be collected using
        the BIP-8 in the B3 byte of the STS-Path Overhead of the STS
        SPE.  VT CVs shall be collected using the BIP-2 in the V5
        overhead byte of the floating VT.

   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.

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

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

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



(page 16 continued on part 2)

Next RFC Part