📄 rfc2495.txt
字号:
Network Working Group D. Fowler, Editor
Request for Comments: 2495 Newbridge Networks
Obsoletes: 1406 January 1999
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 (1999). All Rights Reserved.
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 document with
Definitions of Managed Objects for the DS0 (RFC 2494 [30]), DS3/E3
(RFC 2496 [28]), and the work in progress, SONET/SDH Interface Types.
This memo specifies a MIB module in a manner that is both compliant
to the SNMPv2 SMI, and semantically identical to the peer SNMPv1
definitions.
Table of Contents
1 The SNMP Management Framework ................................ 2
1.1 Changes from RFC1406 ....................................... 3
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 ................ 9
2.2.5 Usage of Loopbacks ....................................... 10
2.3 Objectives of this MIB Module .............................. 11
2.4 DS1 Terminology ............................................ 11
Fowler, Ed. Standards Track [Page 1]
RFC 2495 DS1/E1/DS2/E2 MIB January 1999
2.4.1 Error Events ............................................. 12
2.4.2 Performance Defects ...................................... 12
2.4.3 Performance Parameters ................................... 14
2.4.4 Failure States ........................................... 17
2.4.5 Other Terms .............................................. 21
3 Object Definitions ........................................... 21
3.1 The DS1 Near End Group ..................................... 22
3.1.1 The DS1 Configuration Table .............................. 22
3.1.2 The DS1 Current Table .................................... 33
3.1.3 The DS1 Interval Table ................................... 36
3.1.4 The DS1 Total Table ...................................... 39
3.1.5 The DS1 Channel Table .................................... 42
3.2 The DS1 Far End Group ...................................... 43
3.2.1 The DS1 Far End Current Table ............................ 43
3.2.2 The DS1 Far End Interval Table ........................... 47
3.2.3 The DS1 Far End Total Table .............................. 50
3.3 The DS1 Fractional Table ................................... 53
3.4 The DS1 Trap Group ......................................... 55
3.5 Conformance Groups ......................................... 61
4 Appendix A - Use of dsx1IfIndex and dsx1LineIndex ............ 66
5 Appendix B - The delay approach to Unavialable Seconds. ..... 69
6 Intellectual Property ........................................ 70
7 Acknowledgments .............................................. 70
8 References ................................................... 71
9 Security Considerations ...................................... 73
10 Author's Address ............................................ 74
11 Full Copyright Statement .................................... 75
1. The SNMP Management Framework
The SNMP Management Framework presently consists of five major
components:
o An overall architecture, described in RFC 2271 [1].
o 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, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4]. The
second version, called SMIv2, is described in RFC 1902 [5], RFC
1903 [6] and RFC 1904 [7].
o Message protocols for transferring management information. The
first version of the SNMP message protocol is called SNMPv1 and
described in STD 15, RFC 1157 [8]. A second version of the SNMP
message protocol, which is not an Internet standards track
protocol, is called SNMPv2c and described in RFC 1901 [9] and
RFC 1906 [10]. The third version of the message protocol is
Fowler, Ed. Standards Track [Page 2]
RFC 2495 DS1/E1/DS2/E2 MIB January 1999
called SNMPv3 and described in RFC 1906 [10], RFC 2272 [11] and
RFC 2274 [12].
o Protocol operations for accessing management information. The
first set of protocol operations and associated PDU formats is
described in STD 15, RFC 1157 [8]. A second set of protocol
operations and associated PDU formats is described in RFC 1905
[13].
o A set of fundamental applications described in RFC 2273 [14] and
the view-based access control mechanism described in RFC 2275
[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 (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.
1.1. Changes from RFC1406
The changes from 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.
Fowler, Ed. Standards Track [Page 3]
RFC 2495 DS1/E1/DS2/E2 MIB January 1999
(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
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) and Extended Superframe (ESF) formats [17, 18], the
latter of which conforms to ANSI specifications [19], and the CCITT
Recommendations [20, 21], referred to as E1 for the rest of this
memo.
Fowler, Ed. Standards Track [Page 4]
RFC 2495 DS1/E1/DS2/E2 MIB January 1999
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 ifGeneralGroup needs to be supported.
ifTable Object Use for DS1 Layer
======================================================================
ifIndex Interface index.
ifDescr See interfaces MIB [16]
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 [16]
ifOperStatus See interfaces MIB [16]
ifLastChange See interfaces MIB [16]
ifName See interfaces MIB [16].
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
Fowler, Ed. Standards Track [Page 5]
RFC 2495 DS1/E1/DS2/E2 MIB January 1999
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:
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -