rfc1406.txt

<VC++网络游戏建摸与实现>源代码

Network Working Group                                           F. Baker
Request for Comments: 1406              Advanced Computer Communications
Obsoletes: 1232                                                  J. Watt
                                          Newbridge Networks Corporation
                                                                 Editors
                                                            January 1993


   Definitions of Managed Objects for the DS1 and E1 Interface Types

Status of this Memo

   This RFC specifies an IAB standards track protocol for the Internet
   community, and requests discussion and suggestions for improvements.
   Please refer to the current edition of the "IAB Official Protocol
   Standards" for the standardization state and status of this protocol.
   Distribution of this memo is unlimited.

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 DS1 Interfaces --
   including both T1 and E1 (a.k.a., CEPT 2 Mbit/s) links.

   This document entirely replaces RFC 1232, which contains a
   fundamental error: many objects are encoded as Counters that must be
   encoded as INTEGERs or Gauges.  The magnitude of the change required
   is sufficient that virtually every object changed.  Therefore, the
   MIB documented in RFC 1232 should not be implemented.

Table of Contents

   1. The Network Management Framework ......................    2
   2. Objects ...............................................    2
   2.1 Format of Definitions ................................    3
   2.2 Changes from RFC 1232 ................................    3
   3. Overview ..............................................    4
   3.1 Binding between ifIndex and DS1 Interfaces ...........    5
   3.2 Objectives of this MIB Module ........................    7
   3.3 DS1 Terminology ......................................    7
   3.3.1 Error Events .......................................    7
   3.3.2 Performance Defects ................................    8
   3.3.3 Performance Parameters .............................    9
   3.3.4 Failure States .....................................   11
   3.3.5 Other Terms ........................................   13
   4. Definitions ...........................................   14
   4.1 DS1 Near End Group ...................................   14



Trunk MIB Working Group                                         [Page 1]

RFC 1406                       DS1/E1 MIB                   January 1993


   4.1.1 DS1 Configuration Table ............................   14
   4.1.2 DS1 Current Table ..................................   22
   4.1.3 DS1 Interval Table .................................   26
   4.1.4 DS1 Total Table ....................................   30
   4.2 DS1 Far End Group ....................................   33
   4.2.1 DS1 Far End Current Table ..........................   34
   4.2.2 DS1 Far End Interval Table .........................   38
   4.2.3 DS1 Far End Total Table ............................   41
   4.3 DS1 Fractional Group .................................   45
   4.3.1 DS1 Fractional Table ...............................   45
   5. Acknowledgements ......................................   47
   6. References ............................................   48
   7. Security Considerations ...............................   50
   8. Authors' Addresses ....................................   50

1.  The Network Management Framework

   The Internet-standard Network Management Framework consists of three
   components.  They are:

      STD 16/RFC 1155 [1] which defines the SMI, the mechanisms used for
      describing and naming objects for the purpose of management.  STD
      16/RFC 1212 [2] defines a more concise description mechanism,
      which is wholly consistent with the SMI.

      RFC 1156 [3] which defines MIB-I, the core set of managed objects
      for the Internet suite of protocols.  STD 17/RFC 1213 [4] defines
      MIB-II, an evolution of MIB-I based on implementation experience
      and new operational requirements.

      STD 15/RFC 1157 [5] which defines the SNMP, the protocol used for
      network access to managed objects.

   The Framework permits new objects to be defined for the purpose of
   experimentation and evaluation.

2.  Objects

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  Objects in the MIB are
   defined using the subset of Abstract Syntax Notation One (ASN.1) [6]
   defined in the SMI.  In particular, each object has a name, a syntax,
   and an encoding.  The name is an object identifier, an
   administratively assigned name, which specifies an object type.  The
   object type together with an object instance serves to uniquely
   identify a specific instantiation of the object.  For human
   convenience, we often use a textual string, termed the OBJECT
   DESCRIPTOR, to also refer to the object type.



Trunk MIB Working Group                                         [Page 2]

RFC 1406                       DS1/E1 MIB                   January 1993


   The syntax of an object type defines the abstract data structure
   corresponding to that object type.  The ASN.1 language is used for
   this purpose.  However, the SMI [1] purposely restricts the ASN.1
   constructs which may be used.  These restrictions are explicitly made
   for simplicity.

   The encoding of an object type is simply how that object type is
   represented using the object type's syntax.  Implicitly tied to the
   notion of an object type's syntax and encoding is how the object type
   is represented when being transmitted on the network.

   The SMI specifies the use of the basic encoding rules of ASN.1 [7],
   subject to the additional requirements imposed by the SNMP.

2.1.  Format of Definitions

   Section 4 contains contains the specification of all object types
   contained in this MIB module.  The object types are defined using the
   conventions defined in the SMI, as amended by the extensions
   specified in STD 16, RFC 1212 [2].

2.2.  Changes from RFC 1232

   The changes from RFC 1232 are the following:

     (1)  This MIB module contains three groups: DS1 Near End Group
          which is mandatory, DS1 Far End Group which is optional,
          and the Fractional Table, which is optional.

     (2)  The Far End Group is a new group and contains statistics
          that are collected from the far end DS1 interface.  The
          Far End Group may only be implemented by DS1 systems that
          use the facilities data link to exchange this information
          - both T1.403 and PUB 54016 define ways to exchange this
          information over data links; vendors may use other
          proprietary means to do this on various link types.

     (3)  ds1CSUIndex has been renamed dsx1LineIndex.  This object
          is the identifier of a DS1 Interface on a device.  On a
          CSU, a single DS1 data stream will cross two DS1
          interfaces, which have separate dsx1LineIndex values.

     (4)  ds1Index has been renamed dsx1IfIndex.  This value for
          this object is equal to the value of ifIndex from the
          Interfaces table of MIB II (STD 17, RFC 1213).

     (5)  an object has been added (dsx1TransmitClockSource) to
          indicate the source of transmit clock.



Trunk MIB Working Group                                         [Page 3]

RFC 1406                       DS1/E1 MIB                   January 1993


     (6)  The ACCESS for objects in the dsx1ConfigTable has been
          set to read-write for items that are configurable.

     (7)  Description of test configurations has changed.  A new
          object has been added called dsx1LoopbackConfig, which
          better describes the loopback capabilities of a DS1
          interface on a device.

     (8)  The description of line alarm status has changed.  A new
          object has been added called dsx1LineStatus.  This object
          better describes the status (e.g., failure state and
          loopback state) of a DS1 interface.

     (9)  All Counters have been changed to Gauges.

     (10) Information about how applications might use the zero
          code suppression have been removed; only the actual line
          coding algorithm is described.  For clarity the object
          was thus renamed to dsx1LineCoding.

     (11) A Line Errored Seconds object has been added to all near
          end tables and the count of Bipolar Violations (BPVs) was
          changed to a count of Line Code Violations (LCVs).

     (12) Bursty Errored Seconds (a.k.a., Errored Seconds Type B)
          and Degraded Minutes objects have been added to all near
          end tables.

     (13) The Coding Violation error event is now referred to as a
          Path Coding Violation (PCV) Error Event.

3.  Overview

   These objects are used when the particular media being used to
   realize an interface is a DS1 physical interface.  At present, this
   applies to these values of the ifType variable in the Internet-
   standard MIB:

            ds1 (18)
            e1  (19)

   The definitions contained herein are based on the AT&T T-1 Superframe
   (a.k.a., D4) and Extended Superframe (ESF) formats [8, 9], the latter
   of which conforms to ANSI specifications [10], and the CCITT
   Recommendations [11, 12], referred to as E1 for the rest of this
   memo.





Trunk MIB Working Group                                         [Page 4]

RFC 1406                       DS1/E1 MIB                   January 1993


   The various T1 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.

   Where it is necessary to distinguish between the flavors of E1 with
   and without CRC, E1-CRC to denotes the "with CRC" form (G.704 Table
   4b) and E1-noCRC denotes the "without CRC" form (G.704 Table 4a).

3.1.  Binding between ifIndex and DS1 Interfaces

   Different physical configurations for the support of SNMP with DS1
   equipment exist. To accommodate these scenarios, two different
   indices for DS1 interfaces are introduced in this MIB.  These indices
   are dsx1IfIndex and dsx1LineIndex.

   External interface scenario: the SNMP Agent represents all managed
   DS1 lines as external interfaces (for example, an Agent residing on
   the device supporting DS1 interfaces directly):

   For this scenario, all interfaces are assigned an integer value equal
   to ifIndex, and the following applies:

         ifIndex=dsx1IfIndex=dsx1LineIndex for all interfaces.

   The dsx1IfIndex column of the DS1 Configuration table relates each
   DS1 interface to its corresponding interface (ifIndex) in the
   Internet-standard MIB (MIB-II STD 17, RFC 1213).

   External & Internal interface scenario: the SNMP Agents resides on an
   host external from the device supporting DS1 interfaces (e.g., a
   router).  The Agent represents both the host and the DS1 device.  The
   index dsx1LineIndex is used to not only represent the DS1 interfaces
   external from the host/DS1-device combination, but also the DS1
   interfaces connecting the host and the DS1 device.  The index
   dsx1IfIndex is always equal to ifIndex.

   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:








Trunk MIB Working Group                                         [Page 5]

RFC 1406                       DS1/E1 MIB                   January 1993


           +-----+
     |     |     |
     |     |     |               +---------------------+
     |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 (= dsx1IfIndex)             dsx1LineIndex
     1                   NA                  NA (Ethernet)
     2      Line#A   Router Side             6
     2      Line#A   Network Side            7
     3      Line#B   Router Side             8
     3      Line#B   Network Side            9
     4      Line#C   Router Side            10
     4      Line#C   Network Side           11
     5      Line#D   Router Side            12
     5      Line#D   Network Side           13

   For this example, ifNumber is equal to 5.  Note the following
   description of dsx1LineIndex: the dsx1LineIndex identifies a DS1
   Interface on a managed device.  If there is an ifEntry that is
   directly associated with this and only this DS1 interface, it should
   have the same value as ifIndex.  Otherwise, number the
   dsx1LineIndices with an unique identifier following the rules of
   choosing a number greater than ifNumber and numbering inside
   interfaces (e.g., equipment side) with even numbers and outside
   interfaces (e.g., network side) with odd numbers.

   If the CSU shelf is managed by itself by a local SNMP Agent, the
   situation would be:








Trunk MIB Working Group                                         [Page 6]

RFC 1406                       DS1/E1 MIB                   January 1993


          ifIndex (= dsx1IfIndex)               dsx1LineIndex
          2      Line#A     Router Side             2
          1      Line#A     Network Side            1
          4      Line#B     Router Side             4
          3      Line#B     Network Side            3
          6      Line#C     Router Side             6
          5      Line#C     Network Side            5
          8      Line#D     Router Side             8
          7      Line#D     Network Side            7

3.2.  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 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 DS1 devices that are currently deployed.

3.3.  DS1 Terminology