tech-invite   World Map     

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

RFC 3592

 Errata 
Draft STD
Pages: 73
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: ATOMMIB

Definitions of Managed Objects for the Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Interface Type

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

Obsoletes:    2558


Top       ToC       Page 1 
Network Working Group                                          K. Tesink
Request for Comments: 3592                        Telcordia Technologies
Obsoletes: 2558                                           September 2003
Category: Standards Track


                Definitions of Managed Objects for the
            Synchronous Optical Network/Synchronous Digital
                  Hierarchy (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 (2003).  All Rights Reserved.

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.

   This memo replaces RFC 2558.  Changes relative to RFC 2558 are
   summarized in the MIB module's REVISION clause.

Table of Contents

   1.  Conventions ..................................................  2
   2.  The Internet-Standard Management Framework ...................  3
   3.  Overview .....................................................  3
       3.1.  Use of the ifTable .....................................  3
       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 ..................................  7
   4.  Object Definitions ........................................... 15
       4.1.  The SONET/SDH Medium Group ............................. 19
       4.2.  The SONET/SDH Section Group ............................ 23

Top      ToC       Page 2 
             4.2.1.  The SONET/SDH Section Current Group ............ 23
             4.2.2.  The SONET/SDH Section Interval Group ........... 25
       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 ....... 32
             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 ................................ 56
       4.10. Compliance Statements .................................. 56
   5.  Acknowledgments .............................................. 65
   6.  Security Considerations ...................................... 65
   7.  References ................................................... 66
       7.1.  Normative References ................................... 66
       7.2.  Informative References ................................. 68
   8.  Intellectual Property Statement .............................. 68
   Appendix A: The delay-line approach to statistics collection ..... 69
   Appendix B: RFC 1595 SES interpretation .......................... 71
   Author's Address ................................................. 72
   Full Copyright Statement ......................................... 73

1.  Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL", when they appear in this document, are to be interpreted
   as described in BCP 14, RFC 2119 [RFC2119].

Top      ToC       Page 3 
2.  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].

   Textual conventions used in this document are defined in RFC 2579
   [RFC2579] and RFC 3593 [RFC3593].

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
   [T1.105a][T1.105b][T1.106] and CCITT G.707, 708, 709, and G.783
   [G.707][G.708][G.709][G.783].

3.1.  Use of the ifTable

   This section specifies how the MIB II interfaces group, as defined in
   [RFC2863], 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.

Top      ToC       Page 4 
   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 [RFC1213], as extended by [RFC2863], 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
   [RFC2863], as follows:

    _____________________________
   |             |          |    |  >
   |             |          |    |  |
   |    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 [RFC2863] and in the ifInvStackTable [RFC2864].

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

    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     May be implemented with 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).
                             May be implemented with read-only access.

    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.

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

    ifPhysAddress     Circuit Identifier or OCTET STRING of zero length.

    ifAdminStatus     May be implemented with 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).
                             May be implemented with read-only access.

    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.

Top      ToC       Page 7 
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     May be implemented with read-only access.
                      The desired administrative status of the
                      interface.

    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).
                             May be implemented with read-only access.

    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
   [T1M1.3][T1.231a][T1.231b].  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 [G.783].  Only the SONET Performance

Top      ToC       Page 8 
   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 [G.783].  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.

      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.

Top      ToC       Page 9 
   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 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 2.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:

Top      ToC       Page 10 
      -  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
      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
         [T1.231a][T1.231b] or 10 [T1.231b].

Top      ToC       Page 11 
      -  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 [T1.231a][T1.231b] or 10 [T1.231b].

      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 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
         [T1.231a] or 10 [T1.231b].

      -  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 [T1.231a] or 10 [T1.231b].

      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
         [T1.231a] or 10 [T1.231b].

Top      ToC       Page 12 
      -  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 [T1.231a] or 10 [T1.231b].

      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 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 [T1M1.3][T1.231a][TR253][GR253][T1.231b] 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

Top      ToC       Page 13 
      RFC 1595 [RFC1595] were based on [T1M1.3] and [TR253] (see
      Appendix B).  These values have subsequently been relaxed in
      [T1.231a][GR253][T1.231b].  In addition, according to G.826
      [G.826] 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 CV counts should be frozen during SESs.

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

   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

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

Top      ToC       Page 15 
   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 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 15 continued on part 2)

Next RFC Part