Request for Comments: 3895 RAD Data Communications, Ltd.
Obsoletes: 2495 September 2004
Category: Standards Track
Definitions of Managed Objects
for the DS1, E1, DS2, and E2 Interface Types
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 (2004).
Abstract
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes objects used for managing DS1, E1, DS2
and E2 interfaces. This document is a companion to the documents
that define Managed Objects for the DS0, DS3/E3 and Synchronous
Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Interface
Types. This document obsoletes RFC 2495.
Table of Contents
1. The Internet-Standard Management Framework . . . . . . . . . . 2
1.1. Changes from RFC 2495. . . . . . . . . . . . . . . . . . 3
1.2. Changes from RFC 1406. . . . . . . . . . . . . . . . . . 3
1.3. Companion Documents. . . . . . . . . . . . . . . . . . . 4
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Use of ifTable for DS1 Layer . . . . . . . . . . . . . . 5
2.2. Usage Guidelines . . . . . . . . . . . . . . . . . . . . 6
2.2.1. Usage of ifStackTable for Routers and DSUs. . . . 6
2.2.2. Usage of ifStackTable for DS1/E1 on DS2/E2. . . . 8
2.2.3. Usage of Channelization for DS3, DS1, DS0 . . . . 9
2.2.4. Usage of Channelization for DS3, DS2, DS1 . . . . 10
2.2.5. Usage of Loopbacks. . . . . . . . . . . . . . . . 11
2.3. Objectives of this MIB Module. . . . . . . . . . . . . . 11
2.4. DS1 Terminology. . . . . . . . . . . . . . . . . . . . . 12
2.4.1. Error Events. . . . . . . . . . . . . . . . . . . 12
2.4.2. Performance Defects . . . . . . . . . . . . . . . 13
2.4.3. Performance Parameters. . . . . . . . . . . . . . 14
2.4.4. Failure States. . . . . . . . . . . . . . . . . . 18
2.4.5. Other Terms . . . . . . . . . . . . . . . . . . . 21
3. Object Definitions . . . . . . . . . . . . . . . . . . . . . . 21
4. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 74
5. Security Considerations. . . . . . . . . . . . . . . . . . . . 74
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.1. Normative References . . . . . . . . . . . . . . . . . . 76
6.2. Informative References . . . . . . . . . . . . . . . . . 78
Appendix A - Use of dsx1IfIndex and dsx1LineIndex. . . . . . . . . 79
Appendix B - The delay approach to Unavailable Seconds . . . . . . 81
Author’s Address . . . . . . . . . . . . . . . . . . . . . . . . . 83
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 84
1. 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].
1.1. Changes from RFC 2495
The changes from [RFC2495] are the following:
(1) The dsx1FracIfIndex SYNTAX matches the description range.
(2) A value was added to dsx1TransmitClockSource.
(3) Values were added to dsx1LineType.
(4) Two objects were added, dsx1LineMode and dsx1LineBuildOut to
better express transceiver mode and LineBuildOut for T1.
(5) Reference was added to Circuit Identifier object.
(6) Align the DESCRIPTION clauses of few statistic objects with the
near end definition, the far end definition and with [RFC3593].
(7) Changes in Compliance Statements to include new objects.
(8) A typographical error in dsx2E2 was fixed, new name is dsx1E2.
1.2. Changes from RFC 1406
The changes from RFC 1406 [RFC1406] are the following:
(1) The Fractional Table has been deprecated.
(2) This document uses SMIv2.
(3) Usage is given for ifTable and ifXTable.
(4) Example usage of ifStackTable is included.
(5) dsx1IfIndex has been deprecated.
(6) Support for DS2 and E2 have been added.
(7) Additional lineTypes for DS2, E2, and unframed E1 were added.
(8) The definition of valid intervals has been clarified for the
case where the agent proxied for other devices. In particular,
the treatment of missing intervals has been clarified.
(9) An inward loopback has been added.
(10) Additional lineStatus bits have been added for Near End in
Unavailable Signal State, Carrier Equipment Out of Service, DS2
Payload AIS, and DS2 Performance Threshold.
(11) A read-write line Length object has been added.
(12) Signal mode of other has been added.
(13) Added a lineStatus last change, trap and enabler.
(14) The e1(19) ifType has been obsoleted so this MIB does not list
it as a supported ifType.
(15) Textual Conventions for statistics objects have been used.
(16) A new object, dsx1LoopbackStatus has been introduced to reflect
the loopbacks established on a DS1 interface and the source to
the requests. dsx1LoopbackConfig continues to be the desired
loopback state while dsx1LoopbackStatus reflects the actual
state.
(17) A dual loopback has been added to allow the setting of an inward
loopback and a line loopback at the same time.
(18) An object indicating which channel to use within a parent object
(i.e., DS3) has been added.
(19) An object has been added to indicate whether or not this DS1/E1
is channelized.
(20) Line coding type of B6ZS has been added for DS2.
1.3. Companion Documents
This document is a companion to the documents that define Managed
Objects for the DS0 [RFC2494], DS3/E3 [RFC3896], and Synchronous
Optical Network/Synchronous Digital Hierarchy (SONET/SDH) [RFC3592]
Interface Types.
2. Overview
These objects are used when the particular media being used to
realize an interface is a DS1/E1/DS2/E2 interface. At present, this
applies to these values of the ifType variable in the Internet-
standard MIB:
ds1 (18)
The definitions contained herein are based on the AT&T T-1 Superframe
(a.k.a., D4) [ANSI-T1.107] and Extended Superframe (ESF) formats
[AT&T-UM-305] [AT&T-TR-54016], the latter of which conforms to ANSI
specification [ANSI-T1.403], and the CCITT Recommendations
[CCITT-G.703] [ITU-T-G.704], referred to as E1 for the rest of this
memo.
The various DS1 and E1 line disciplines are similar enough that
separate MIBs are unwarranted, although there are some differences.
For example, Loss of Frame is defined more rigorously in the ESF
specification than in the D4 specification, but it is defined in
both. Therefore, interface types e1(19) and g703at2mb(67) have been
obsoleted.
Where it is necessary to distinguish between the flavors of E1 with
and without CRC, E1-CRC denotes the "with CRC" form (G.704 Table 4b)
and E1-noCRC denotes the "without CRC" form (G.704 Table 4a).
2.1. Use of ifTable for DS1 Layer
Only the ifGeneralInformationGroup needs to be supported.
ifTable Object Use for DS1 Layer
======================================================================
ifIndex Interface index.
ifDescr See interfaces MIB [RFC2863]
ifType ds1(18)
ifSpeed Speed of line rate
DS1 - 1544000
E1 - 2048000
DS2 - 6312000
E2 - 8448000
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 See interfaces MIB [RFC2863]
ifOperStatus See interfaces MIB [RFC2863]
ifLastChange See interfaces MIB [RFC2863]
ifName See interfaces MIB [RFC2863].
ifLinkUpDownTrapEnable Set to enabled(1).
ifHighSpeed Speed of line in Mega-bits per second
(2, 6, or 8)
ifConnectorPresent Set to true(1) normally, except for
cases such as DS1/E1 over AAL1/ATM where
false(2) is appropriate
2.2. Usage Guidelines
2.2.1. Usage of ifStackTable for Routers and DSUs
The object dsx1IfIndex has been deprecated. This object previously
allowed a very special proxy situation to exist for Routers and CSUs.
This section now describes how to use ifStackTable to represent this
relationship.
The paragraphs discussing dsx1IfIndex and dsx1LineIndex have been
preserved in Appendix A for informational purposes.
The ifStackTable is used in the proxy case to represent the
association between pairs of interfaces, e.g., this T1 is attached to
that T1. This use is consistent with the use of the ifStackTable to
show the association between various sub-layers of an interface. In
both cases entire PDUs are exchanged between the interface pairs - in
the case of a T1, entire T1 frames are exchanged; in the case of PPP
and HDLC, entire HDLC frames are exchanged. This usage is not meant
to suggest the use of the ifStackTable to represent Time Division
Multiplexing (TDM) connections in general.
External&Internal interface scenario: the SNMP Agent resides on a
host external from the device supporting DS1 interfaces (e.g., a
router). The Agent represents both the host and the DS1 device.
Example:
A shelf full of CSUs connected to a Router. An SNMP Agent residing
on the router proxies for itself and the CSU. The router has also an
Ethernet interface:
+-----+
| | |
| | | +---------------------+
|E | | 1.544 MBPS | Line#A | DS1 Link
|t | R |---------------+ - - - - - - - - - +------>
|h | | | |
|e | O | 1.544 MBPS | Line#B | DS1 Link
|r | |---------------+ - - - - - - - - - - +------>
|n | U | | CSU Shelf |
|e | | 1.544 MBPS | Line#C | DS1 Link
|t | T |---------------+ - - - -- -- - - - - +------>
| | | | |
|-----| E | 1.544 MBPS | Line#D | DS1 Link
| | |---------------+ - - - - -- - - - - +------>
| | R | |_____________________|
| | |
| +-----+
The assignment of the index values could for example be:
ifIndex Description
1 Ethernet
2 Line#A Router
3 Line#B Router
4 Line#C Router
5 Line#D Router
6 Line#A CSU Router
7 Line#B CSU Router
8 Line#C CSU Router
9 Line#D CSU Router
10 Line#A CSU Network
11 Line#B CSU Network
12 Line#C CSU Network
13 Line#D CSU Network
The ifStackTable is then used to show the relationships between the
various DS1 interfaces.
ifStackTable Entries
HigherLayer LowerLayer
2 6
3 7
4 8
5 9
6 10
7 11
8 12
9 13
If the CSU shelf is managed by itself by a local SNMP Agent, the
situation would be identical, except the Ethernet and the 4 router
interfaces are deleted. Interfaces would also be numbered from 1 to
8.
ifIndex Description
1 Line#A CSU Router
2 Line#B CSU Router
3 Line#C CSU Router
4 Line#D CSU Router
5 Line#A CSU Network
6 Line#B CSU Network
7 Line#C CSU Network
8 Line#D CSU Network
ifStackTable Entries
HigherLayer LowerLayer
1 5
2 6
3 7
4 8
2.2.2. Usage of ifStackTable for DS1/E1 on DS2/E2
An example is given of how DS1/E1 interfaces are stacked on DS2/E2
interfaces. It is not necessary nor is it always desirable to
represent DS2 interfaces. If this is required, the following
stacking should be used. All ifTypes are ds1. The DS2 is determined
by examining ifSpeed or dsx1LineType.
ifIndex Description
1 DS1 #1
2 DS1 #2
3 DS1 #3
4 DS1 #4
5 DS2
ifStackTable Entries
HigherLayer LowerLayer
1 5
2 5
3 5
4 5
2.2.3. Usage of Channelization for DS3, DS1, DS0
An example is given here to explain the channelization objects in the
DS3, DS1, and DS0 MIBs to help the implementor use the objects
correctly. Treatment of E3 and E1 would be similar, with the number
of DS0s being different depending on the framing of the E1.
Assume that a DS3 (with ifIndex 1) is Channelized into DS1s (without
DS2s). The object dsx3Channelization is set to enabledDs1. There
will be 28 DS1s in the ifTable. Assume the entries in the ifTable
for the DS1s are created in channel order and the ifIndex values are
2 through 29. In the DS1 MIB, there will be an entry in the
dsx1ChanMappingTable for each ds1. The entries will be as follows:
dsx1ChanMappingTable Entries
ifIndex dsx1Ds1ChannelNumber dsx1ChanMappedIfIndex
1 1 2
1 2 3
......
1 28 29
In addition, the DS1s are channelized into DS0s. The object
dsx1Channelization is set to enabledDS0 for each DS1. When this
object is set to this value, 24 DS0s are created by the agent. There
will be 24 DS0s in the ifTable for each DS1. If the
dsx1Channelization is set to disabled, the 24 DS0s are destroyed.
Assume the entries in the ifTable are created in channel order and
the ifIndex values for the DS0s in the first DS1 are 30 through 53.
In the DS0 MIB, there will be an entry in the dsx0ChanMappingTable
for each DS0. The entries will be as follows:
dsx0ChanMappingTable Entries
ifIndex dsx0Ds0ChannelNumber dsx0ChanMappedIfIndex
2 1 30
2 2 31
......
2 24 53
2.2.4. Usage of Channelization for DS3, DS2, DS1
An example is given here to explain the channelization objects in the
DS3 and DS1 MIBs to help the implementor use the objects correctly.
Assume that a DS3 (with ifIndex 1) is Channelized into DS2s. The
object dsx3Channelization [RFC3896] is set to enabledDs2. There will
be 7 DS2s (ifType of DS1) in the ifTable. Assume the entries in the
ifTable for the DS2s are created in channel order and the ifIndex
values are 2 through 8. In the DS1 MIB, there will be an entry in
the dsx1ChanMappingTable for each DS2. The entries will be as
follows:
dsx1ChanMappingTable Entries
ifIndex dsx1Ds1ChannelNumber dsx1ChanMappedIfIndex
1 1 2
1 2 3
......
1 7 8
In addition, the DS2s are channelized into DS1s. The object
dsx1Channelization is set to enabledDS1 for each DS2. There will be
4 DS1s in the ifTable for each DS2. Assume the entries in the
ifTable are created in channel order and the ifIndex values for the
DS1s in the first DS2 are 9 through 12, then 13 through 16 for the
second DS2, and so on. In the DS1 MIB, there will be an entry in the
dsx1ChanMappingTable for each DS1. The entries will be as follows:
dsx1ChanMappingTable Entries
ifIndex dsx1Ds1ChannelNumber dsx1ChanMappedIfIndex
2 1 9
2 2 10
2 3 11
2 4 12
3 1 13
3 2 14
...
8 4 36
2.2.5. Usage of Loopbacks
This section discusses the behaviour of objects related to loopbacks.
The object dsx1LoopbackConfig represents the desired state of
loopbacks on this interface. Using this object a Manager can
request:
LineLoopback
PayloadLoopback (if ESF framing)
InwardLoopback
DualLoopback (Line + Inward)
NoLoopback
The remote end can also request loopbacks either through the FDL
channel if ESF or inband if D4. The loopbacks that can be requested
this way are:
LineLoopback
PayloadLoopback (if ESF framing)
NoLoopback
To model the current state of loopbacks on a DS1 interface, the
object dsx1LoopbackStatus defines which loopback is currently applied
to an interface. This objects, which is a bitmap, will have bits
turned on which reflect the currently active loopbacks on the
interface as well as the source of those loopbacks.
The following restrictions/rules apply to loopbacks:
The far end cannot undo loopbacks set by a manager.
A manager can undo loopbacks set by the far end.
Both a line loopback and an inward loopback can be set at the same
time. Only these two loopbacks can co-exist and either one may be
set by the manager or the far end. A LineLoopback request from the
far end is incremental to an existing Inward loopback established by
a manager. When a NoLoopback is received from the far end in this
case, the InwardLoopback remains in place.
2.3. Objectives of this MIB Module
There are numerous things that could be included in a MIB for DS1
signals: the management of multiplexors, CSUs, DSUs, and the like.
The intent of this document is to facilitate the common management of
all devices with DS1, E1, DS2, or E3 interfaces. As such, a design
decision was made up front to very closely align the MIB with the set
of objects that can generally be read from these types devices that
are currently deployed.