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