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 RFC1595 [30]. Changes relative to RFC1595 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
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 RFC2271 [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, RFC1155 [2], STD 16, RFC1212 [3] and RFC1215 [4].
The second version, called SMIv2, is described in RFC1902 [5],
RFC1903 [6] and RFC1904 [7].
0 Message protocols for transferring management information. The
first version of the SNMP message protocol is called SNMPv1 and
described in STD 15, RFC1157 [8]. A second version of the SNMP
message protocol, which is not an Internet standards track
protocol, is called SNMPv2c and described in RFC1901 [9] and
RFC1906 [10]. The third version of the message protocol is
called SNMPv3 and described in RFC1906 [10], RFC2272 [11] and
RFC2274 [12].
0 Protocol operations for accessing management information. The
first set of protocol operations and associated PDU formats is
described in STD 15, RFC1157 [8]. A second set of protocol
operations and associated PDU formats is described in RFC1905
[13].
0 A set of fundamental applications described in RFC2273 [14] and
the view-based access control mechanism described in RFC2275
[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].
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:
_____________________________
| | | | >
| | | | |
| 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).
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.)
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.
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.
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 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
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
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
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.
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 "9810190000Z"
ORGANIZATION "IETF AToM MIB Working Group"
CONTACT-INFO
"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 interfaces objects."
REVISION "9810190000Z"
DESCRIPTION
"The key changes made to this MIB module
since its initial publication in RFC1595
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 RFC1595, 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 RFC1595
should be assumed, and the table containing those
thresholds has been moved to Appendix B of this memo.
(9) A column with SYNTAX TruthValue has been added to each
interval table. The purpose of the additional column
is to indicate, for each interval, whether the data
is valid in the sense intended by ANSI T1.231 clause
9.1.2.2 [31][35]. The objects in question are:
sonetSectionIntervalValidData
sonetLineIntervalValidData
sonetFarEndLineIntervalValidData
sonetPathIntervalValidData
sonetFarEndPathIntervalValidData
sonetVTIntervalValidData
sonetFarEndVTIntervalValidData
(10) The ranges for sonetPathCurrentStatus and
sonetVTCurrentStatus have been made consistent
with the DESCRIPTION clauses.
(11) The conformance information has been updated. Previous
conformance information from RFC1595 has been
deprecated. Some typographical errors in the deprecated
section have been corrected in order to prevent
MIB compilation errors."
REVISION "9401030000Z"
DESCRIPTION
"The RFC1595 version of this MIB module."
::= { transmission 39 }
-- This is the MIB module for the SONET/SDH objects
sonetObjects OBJECT IDENTIFIER ::= { sonetMIB 1 }
sonetObjectsPath OBJECT IDENTIFIER ::= { sonetMIB 2 }
sonetObjectsVT OBJECT IDENTIFIER ::= { sonetMIB 3 }
-- groups in the SONET/SDH MIB module
sonetMedium OBJECT IDENTIFIER ::= { sonetObjects 1 }
sonetSection OBJECT IDENTIFIER ::= { sonetObjects 2 }
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
measurement period. If, for some reason, such as an
adjustment in the system's time-of-day clock, the
current interval exceeds the maximum value, the
agent will return the maximum value."
::= { sonetMediumEntry 2 }
sonetMediumValidIntervals OBJECT-TYPE
SYNTAX Integer32 (0..96)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of previous 15-minute intervals
for which data was collected.
A SONET/SDH interface must be capable
of supporting at least n intervals.
The minimum value of n is 4.
The default of n is 32.
The maximum value of n is 96.
The value will be <n> unless the measurement was
(re-)started within the last (<n>*15) minutes, in which
case the value will be the number of complete 15
minute intervals for which the agent has at least
some data. In certain cases (e.g., in the case
where the agent is a proxy) it is possible that some
intervals are unavailable. In this case, this
interval is the maximum interval number for
which data is available. "
::= { sonetMediumEntry 3 }
sonetMediumLineCoding OBJECT-TYPE
SYNTAX INTEGER {
sonetMediumOther(1),
sonetMediumB3ZS(2),
sonetMediumCMI(3),
sonetMediumNRZ(4),
sonetMediumRZ(5)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This variable describes the line coding for
this interface. The B3ZS and CMI are used for
electrical SONET/SDH signals (STS-1 and STS-3).
The Non-Return to Zero (NRZ) and the Return
to Zero are used for optical SONET/SDH signals."
::= { sonetMediumEntry 4 }
sonetMediumLineType OBJECT-TYPE
SYNTAX INTEGER {
sonetOther(1),
sonetShortSingleMode(2),
sonetLongSingleMode(3),
sonetMultiMode(4),
sonetCoax(5),
sonetUTP(6)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This variable describes the line type for
this interface. The line types are
Short and Long Range
Single Mode fiber or Multi-Mode fiber interfaces,
and coax and UTP for electrical interfaces. The
value sonetOther should be used when the Line Type is
not one of the listed values."
::= { sonetMediumEntry 5 }
sonetMediumCircuitIdentifier OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..255))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This variable contains the transmission
vendor's circuit identifier, for the
purpose of facilitating troubleshooting.
Note that the circuit identifier, if available,
is also represented by ifPhysAddress."
::= { sonetMediumEntry 6 }
sonetMediumInvalidIntervals OBJECT-TYPE
SYNTAX Integer32 (0..96)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of intervals in the range from
0 to sonetMediumValidIntervals for which no
data is available. This object will typically
be zero except in cases where the data for some
intervals are not available (e.g., in proxy
situations)."
::= { sonetMediumEntry 7 }
sonetMediumLoopbackConfig OBJECT-TYPE
SYNTAX BITS {
sonetNoLoop(0),
sonetFacilityLoop(1),
sonetTerminalLoop(2),
sonetOtherLoop(3) }
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The current loopback state of the SONET/SDH interface. The
values mean:
sonetNoLoop
Not in the loopback state. A device that is not
capable of performing a loopback on this interface
shall always return this value.
sonetFacilityLoop
The received signal at this interface is looped back
out through the corresponding transmitter in the return
direction.
sonetTerminalLoop
The signal that is about to be transmitted is connected
to the associated incoming receiver.
sonetOtherLoop
Loopbacks that are not defined here."
::= { sonetMediumEntry 8 }
sonetSESthresholdSet OBJECT-TYPE
SYNTAX INTEGER {
other(1),
Bellcore1991(2),
ansi1993(3),
itu1995(4),
ansi1997(5)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"An enumerated integer indicating which
recognized set of SES thresholds that
the agent uses for determining severely
errored seconds and unavailable time.
other(1)
None of the following.
Bellcore1991(2)
Bellcore TR-NWT-000253, 1991 [32], or
ANSI T1M1.3/93-005R2, 1993 [22].
See also Appendix B.
ansi1993(3)
ANSI T1.231, 1993 [31], or
Bellcore GR-253-CORE, Issue 2, 1995 [34]
itu1995(4)
ITU Recommendation G.826, 1995 [33]
ansi1997(5)
ANSI T1.231, 1997 [35]
If a manager changes the value of this
object then the SES statistics collected
prior to this change must be invalidated."
::= { sonetMedium 2 }
-- the SONET/SDH Section group
-- this group consists of 2 tables:
-- - the SONET/SDH Section Current Table
-- - the SONET/SDH Section Interval Table
-- the SONET/SDH Section Current Table
-- The SONET/SDH Section
-- current table contains various statistics
-- being collected for the current 15 minute interval.
sonetSectionCurrentTable OBJECT-TYPE
SYNTAX SEQUENCE OF SonetSectionCurrentEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The SONET/SDH Section Current table."
::= { sonetSection 1 }
sonetSectionCurrentEntry OBJECT-TYPE
SYNTAX SonetSectionCurrentEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the SONET/SDH Section Current table."
INDEX { ifIndex }
::= { sonetSectionCurrentTable 1 }
SonetSectionCurrentEntry ::=
SEQUENCE {
sonetSectionCurrentStatus Integer32,
sonetSectionCurrentESs PerfCurrentCount,
sonetSectionCurrentSESs PerfCurrentCount,
sonetSectionCurrentSEFSs PerfCurrentCount,
sonetSectionCurrentCVs PerfCurrentCount
}
sonetSectionCurrentStatus OBJECT-TYPE
SYNTAX Integer32 (1..6)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This variable indicates the
status of the interface.
The sonetSectionCurrentStatus
is a bit map represented
as a sum, therefore,
it can represent multiple defects
simultaneously.
The sonetSectionNoDefect should be
set if and only if
no other flag is set.
The various bit positions are:
1 sonetSectionNoDefect
2 sonetSectionLOS
4 sonetSectionLOF"
::= { sonetSectionCurrentEntry 1 }
sonetSectionCurrentESs OBJECT-TYPE
SYNTAX PerfCurrentCount
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The counter associated with the number of Errored
Seconds encountered by a SONET/SDH
Section in the current 15 minute interval."
::= { sonetSectionCurrentEntry 2 }
sonetSectionCurrentSESs OBJECT-TYPE
SYNTAX PerfCurrentCount
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The counter associated with the number of
Severely Errored Seconds
encountered by a SONET/SDH Section in the current 15
minute interval."
::= { sonetSectionCurrentEntry 3 }
sonetSectionCurrentSEFSs OBJECT-TYPE
SYNTAX PerfCurrentCount
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The counter associated with the number of
Severely Errored Framing Seconds
encountered by a SONET/SDH Section in the current
15 minute interval."
::= { sonetSectionCurrentEntry 4 }
sonetSectionCurrentCVs OBJECT-TYPE
SYNTAX PerfCurrentCount
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The counter associated with the number of Coding
Violations encountered by a
SONET/SDH Section in the current 15 minute interval."
::= { sonetSectionCurrentEntry 5 }
-- the SONET/SDH Section Interval Table
-- The SONET/SDH Section Interval Table
-- contains various statistics
-- collected by each system over a maximum
-- of the previous 24 hours of
-- operation. The past 24 hours may be broken into 96
-- completed 15 minute intervals.
-- A system is required to store at
-- least 4 completed 15 minute interval.
-- The default value is 32 intervals.
sonetSectionIntervalTable OBJECT-TYPE
SYNTAX SEQUENCE OF SonetSectionIntervalEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The SONET/SDH Section Interval table."
::= { sonetSection 2 }
sonetSectionIntervalEntry OBJECT-TYPE
SYNTAX SonetSectionIntervalEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the SONET/SDH Section Interval table."
INDEX { ifIndex,
sonetSectionIntervalNumber }
::= { sonetSectionIntervalTable 1 }
SonetSectionIntervalEntry ::=
SEQUENCE {
sonetSectionIntervalNumber Integer32,
sonetSectionIntervalESs PerfIntervalCount,
sonetSectionIntervalSESs PerfIntervalCount,
sonetSectionIntervalSEFSs PerfIntervalCount,
sonetSectionIntervalCVs PerfIntervalCount,
sonetSectionIntervalValidData TruthValue
}
sonetSectionIntervalNumber OBJECT-TYPE
SYNTAX Integer32 (1..96)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A number between 1 and 96, which identifies the
interval for which the set of statistics is available.
The interval identified by 1 is the most recently
completed 15 minute interval,
and the interval identified
by N is the interval immediately preceding the
one identified
by N-1."
::= { sonetSectionIntervalEntry 1 }
sonetSectionIntervalESs OBJECT-TYPE
SYNTAX PerfIntervalCount
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The counter associated with the number of
Errored Seconds encountered
by a SONET/SDH Section in a
particular 15-minute interval
in the past 24 hours."
::= { sonetSectionIntervalEntry 2 }
sonetSectionIntervalSESs OBJECT-TYPE
SYNTAX PerfIntervalCount
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The counter associated with the number of
Severely Errored Seconds
encountered by a SONET/SDH Section in a
particular 15-minute interval
in the past 24 hours."
::= { sonetSectionIntervalEntry 3 }
sonetSectionIntervalSEFSs OBJECT-TYPE
SYNTAX PerfIntervalCount
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The counter associated with the number of
Severely Errored Framing Seconds
encountered by a SONET/SDH Section in a
particular 15-minute interval
in the past 24 hours."