rfc2495.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

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: