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.
4. Object Definitions
SONET-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE,
Integer32, transmission
FROM SNMPv2-SMI
DisplayString, TruthValue
FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP
FROM SNMPv2-CONF
ifIndex
FROM IF-MIB
PerfCurrentCount, PerfIntervalCount
FROM PerfHist-TC-MIB;
-- This is the MIB module for the SONET/SDH Interface objects.
sonetMIB MODULE-IDENTITY
LAST-UPDATED "200308110000Z"
ORGANIZATION "IETF AToM MIB Working Group"
CONTACT-INFO
"WG charter:
http://www.ietf.org/html.charters/atommib-charter.html
Mailing Lists:
General Discussion: atommib@research.telcordia.com
To Subscribe: atommib-request@research.telcordia.com
Kaj Tesink
Telcordia Technologies
Tel: (732) 758-5254
Fax: (732) 758-2269
E-mail: kaj@research.telcordia.com."
DESCRIPTION
"The MIB module to describe SONET/SDH interface objects.
Copyright (C) The Internet Society (2003). This version
of this MIB module is part of RFC 3592; see the RFC
itself for full legal notices."
REVISION "200308110000Z"
DESCRIPTION
"The key changes made to this MIB module
since its publication in RFC 2558
are as follows.
(1) Corrected typographical error
(bellcore1991(2) in sonetSESthresholdSet)
(2) Added support for sts192cSTM64(6) and
sts768cSTM256(7) in sonetPathCurrentWidth
(3) Corrected description of the applicability
of VTs for SDH for improved accuracy
(4) Added clarification in the SES description that
CV counts should be frozen during SESs
(5) Corrected typographical errors:
- Line Alarm Indication Signal description of the
Terminology section (20.5 --> 2.5 seconds)
- In the Terminology section
sonetSESThresholdSet --> sonetSESthresholdSet
"
REVISION "199810190000Z"
DESCRIPTION
"The RFC 2558 version of this MIB module.
The key changes made to this MIB module
since its initial publication in RFC 1595
are as follows.
(1) The MODULE-IDENTITY has been updated to reflect the
changes to the MIB.
(2) Where applicable, the textual conventions
PerfCurrentCount and PerfIntervalCount from
PerfHist-TC-MIB have been used in place of Gauge32.
(3) An agent now has the option to delay updates to
the various performance counts in lieu of performing
retroactive adjustments upon entering into or exiting
from unavailable time. This implementation option is
described in Appendix A of this memo.
(4) In order to make the SONET-MIB more useful for
circuit provisioning, the formerly read-only objects
sonetMediumType, sonetMediumLineCoding,
sonetMediumLineType, and sonetMediumCircuitIdentifier
have been given a MAX-ACCESS of read-write. The
MIN-ACCESS remains read-only.
(5) The DESCRIPTION clause for sonetMediumTimeElapsed has
been updated to describe its behaviour if the duration
of the current interval exceeds the maximum value.
(6) The DESCRIPTION clause for sonetMediumValidIntervals
has been updated to describe its behaviour when some
intervals may be unavailable, and the object
sonetMediumInvalidIntervals has been added to keep
count of the number of missing intervals (if any).
(7) The object sonetMediumLoopbackConfig has been added
to enable or disable loopback configurations.
(8) Because the error count thresholds for declaring
severely errored seconds that are specified in ANSI
T1.231-1993, ITU-T G.826-1995, and ANSI T1.231-1997
are all different from each other and from the thresholds
specified in RFC 1595, an enumerated INTEGER object
sonetSESthresholdSet has been added to allow an agent
to specify which threshold set is in use. Text has
been added to Section 3 stating that if this object is
not implemented the thresholds specified in RFC 1595
should be assumed, and the table containing those
thresholds has been moved to Appendix B of this memo.
(9) A column with SYNTAX TruthValue has been added to each
interval table. The purpose of the additional column
is to indicate, for each interval, whether the data
is valid in the sense intended by ANSI T1.231 clause
9.1.2.2 [T1.231a][T1.231b]. The objects in question are:
sonetSectionIntervalValidData
sonetLineIntervalValidData
sonetFarEndLineIntervalValidData
sonetPathIntervalValidData
sonetFarEndPathIntervalValidData
sonetVTIntervalValidData
sonetFarEndVTIntervalValidData
(10) The ranges for sonetPathCurrentStatus and
sonetVTCurrentStatus have been made consistent
with the DESCRIPTION clauses.
(11) The conformance information has been updated. Previous
conformance information from RFC 1595 has been
deprecated. Some typographical errors in the deprecated
section have been corrected in order to prevent
MIB compilation errors."
REVISION "199401030000Z"
DESCRIPTION
"The RFC 1595 version of this MIB module."
::= { transmission 39 }
-- This is the MIB module for the SONET/SDH objects
sonetObjects OBJECT IDENTIFIER ::= { sonetMIB 1 }
sonetObjectsPath OBJECT IDENTIFIER ::= { sonetMIB 2 }
sonetObjectsVT OBJECT IDENTIFIER ::= { sonetMIB 3 }
-- groups in the SONET/SDH MIB module
sonetMedium OBJECT IDENTIFIER ::= { sonetObjects 1 }
sonetSection OBJECT IDENTIFIER ::= { sonetObjects 2 }
sonetLine OBJECT IDENTIFIER ::= { sonetObjects 3 }
sonetFarEndLine OBJECT IDENTIFIER ::= { sonetObjects 4 }
sonetPath OBJECT IDENTIFIER ::= { sonetObjectsPath 1 }
sonetFarEndPath OBJECT IDENTIFIER ::= { sonetObjectsPath 2 }
sonetVT OBJECT IDENTIFIER ::= { sonetObjectsVT 1 }
sonetFarEndVT OBJECT IDENTIFIER ::= { sonetObjectsVT 2 }
-- the SONET/SDH Medium group
-- SONET/SDH interfaces for some applications may be electrical
-- interfaces and not optical interfaces. This group handles
-- the configuration information for both optical SONET/SDH
-- interfaces and electrical SONET/SDH interfaces.
sonetMediumTable OBJECT-TYPE
SYNTAX SEQUENCE OF SonetMediumEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The SONET/SDH Medium table."
::= { sonetMedium 1 }
sonetMediumEntry OBJECT-TYPE
SYNTAX SonetMediumEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the SONET/SDH Medium table."
INDEX { ifIndex }
::= { sonetMediumTable 1 }
SonetMediumEntry ::=
SEQUENCE {
sonetMediumType INTEGER,
sonetMediumTimeElapsed Integer32,
sonetMediumValidIntervals Integer32,
sonetMediumLineCoding INTEGER,
sonetMediumLineType INTEGER,
sonetMediumCircuitIdentifier DisplayString,
sonetMediumInvalidIntervals Integer32,
sonetMediumLoopbackConfig BITS
}
sonetMediumType OBJECT-TYPE
SYNTAX INTEGER {
sonet(1),
sdh(2)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This variable identifies whether a SONET
or a SDH signal is used across this interface."
::= { sonetMediumEntry 1 }
sonetMediumTimeElapsed OBJECT-TYPE
SYNTAX Integer32 (1..900)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of seconds, including partial seconds,
that have elapsed since the beginning of the current