RFC 3592
Definitions of Managed Objects for the Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Interface Type
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
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].
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.
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].
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.
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.
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
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.
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:
- 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].
- 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].
- 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
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
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.
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)
