rfc1232.txt

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

Network Working Group                                           F. Baker
Request for Comments: 1232        Advanced Computer Communications, Inc.
                                                                 C. Kolb
                                 Performance Systems International, Inc.
                                                                 Editors
                                                                May 1991


                     Definitions of Managed Objects
                       for the DS1 Interface Type

Status of this Memo

   This memo defines objects for managing DS1 Interface objects for use
   with the SNMP protocol.  This memo is a product of the Transmission
   MIB Working Group of the Internet Engineering Task Force (IETF).
   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.

Table of Contents

   1. Abstract ..............................................    1
   2. The Network Management Framework.......................    2
   3. Objects ...............................................    2
   3.1 Format of Definitions ...............................     3
   4. Overview ..............................................    3
   4.1 Binding between Interfaces and CSUs .................     3
   4.2 Objectives of this MIB Module .......................     4
   4.3 DS1 Terminology .....................................     4
   5. Definitions ...........................................    6
   5.1 The DS1 Configuration Group .........................     6
   5.2 The DS1 Interval Group ..............................    13
   5.3 The DS1 Current Group ...............................    16
   5.4 The DS1 Total Group .................................    19
   5.5 The DS1 Fractional Group ............................    22
   6. Acknowledgements ......................................   25
   7. References ............................................   26
   8. Security Considerations................................   27
   9. Authors' Addresses.....................................   28

1.  Abstract

   This memo defines an experimental portion of the Management
   Information Base (MIB) for use with network management protocols in
   TCP/IP-based internets.  In particular, this memo defines MIB objects



Transmission MIB Working Group                                  [Page 1]

RFC 1232                 DS1 Interface Objects                  May 1991


   for representing DS1 physical interfaces.  Implementors should
   consult in addition to this memo the companion document that
   describes that DS3 managed objects.

2.  The Network Management Framework

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

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

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

      RFC 1157 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.

3.  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) [7]
   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.

   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 [3] 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.



Transmission MIB Working Group                                  [Page 2]

RFC 1232                 DS1 Interface Objects                  May 1991


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

3.1.  Format of Definitions

   Section 5 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 [13].

4.  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
   specifications and Extended Superframe (ESF) format [9, 10], the
   latter of which conforms to proposed ANSI specifications [14, 15].
   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.

4.1.  Binding between Interfaces and CSUs

   It should be noted that it is possible to multiplex multiple bit
   streams onto a single DS1 physical interface (CSU), realizing
   multiple interfaces from the perspective of the Internet-standard
   MIB.  It is also possible to concatenate physical interfaces to
   provide a single logical interface.  As such, it is important to be
   able to distinguish between the indices used to identify the CSUs
   attached to a node and the indices used to identify an interface (in
   the MIB sense) attached to a node.

   Each agent which resides on a host which uses DS1 physical interfaces
   is required to assign a small, positive integer uniquely to each CSU.
   This is known as the "CSUIndex", and is used to distinguish between
   different CSUs attached to a node.  The CSUIndex is also used as the
   "key" when accessing tabular information about DS1 physical
   interfaces.

   The potentially many-to-one binding between CSU indices and the



Transmission MIB Working Group                                  [Page 3]

RFC 1232                 DS1 Interface Objects                  May 1991


   ifIndex value assigned to each MIB interface are defined in the
   ds1ConfigTable table defined in the next section.

4.2.  Objectives of this MIB Module

   There are numerous things that could be included in a MIB for DS1
   Interfaces: the management of multiplexors, CSUs, DSUs, and the like.
   The intent of this document is to facilitate the common management of
   CSUs, both in-chassis and external via proxy.  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 CSUs that are currently
   deployed, which is to say ESF CSUs conforming to AT&T specifications.
   However, by simple generalization of these objects, the MIB is also
   made applicable to D4 and G.704 devices.

   To meet a requirement not easily satisfied in other places, there is
   one additional group present, the Fractional DS1 group.  This is
   intended to facilitate the use of fractional DS1 devices (i.e.,
   devices which utilize a subset of the 8 bit channels available in the
   frame) over the managed CSUs.

4.3.  DS1 Terminology

   The terminology used in this document to describe error conditions on
   a T1 or E1 circuit monitored by a CSU are from references [10], [11],
   [14], and [15].

          Out of Frame event
               An Out of Frame event is declared when the receiver
               detects two or more framing-bit errors within a 3
               millisecond period, or two or more errors out of five or
               less consecutive framing-bits.  At this time, the framer
               enters the Out of Frame State, and starts searching for a
               correct framing pattern.  The Out of Frame state ends
               when reframe occurs.

          Loss of Signal
               This event is declared upon observing 175 +/- 75
               contiguous pulse positions with no pulses of either
               positive or negative polarity (also called keep alive).

          Code Violation Error Event
               A Code Violation Error Event is the occurrence of a
               received Cyclic Redundancy Check code that is not
               identical to the corresponding locally-calculated code.

          Bipolar Violation
               A Bipolar Violation, for B8ZS-coded signals, is the



Transmission MIB Working Group                                  [Page 4]

RFC 1232                 DS1 Interface Objects                  May 1991


               occurrence of a received bipolar violation that is not
               part of a zero-substitution code.  It also includes other
               error patterns such as: eight or more consecutive zeros
               and incorrect parity.

          Errored Seconds
               An Errored Second is a second with one or more Code
               Violation Error Events OR one or more Out of Frame
               events.  In D4 and G.704 section 2.1.3.2 (eg, G.704 which
               does not implement the CRC), the presence of Bipolar
               Violations also triggers an Errored Second.

          Severely Errored Seconds
               A Severely Errored Second is a second with 320 or more
               Code Violation Error Events OR one or more Out of Frame
               events.

          Severely Errored Framing Second
               An Severely Errored Framing Second is a second with one
               or more Out of Frame events.

          Unavailable Signal State
               This state is declared at the onset of 10 consecutive
               Severely Errored Seconds.  It is cleared at the onset of
               10 consecutive seconds with no Severely Errored Second.

          Unavailable Seconds
               Unavailable Seconds are calculated by counting the number
               of seconds that the CSU is in the Unavailable Signal
               State, including the initial 10 seconds to enter the
               state but not including the 10 seconds to exit the state.

               Note that any second that may be counted as an
               Unavailable Second may not be counted as an Errored
               Second, a Severely Errored Second.  Since the 10 Severely
               Errored Seconds that comprise the transition from the
               available to Unavailable Signal State may also be counted
               as Errored Seconds, and Severely Errored Seconds previous
               to entering the state, these three counters are adjusted
               so that any second counted during this transition is then
               subtracted.  The 10 seconds in the transition from
               unavailable to available may be counted as Errored
               Seconds.

               A special case exists when the 10 or more second period
               crosses the 900 second statistics window boundary, as the
               foregoing description implies that the Severely Errored
               Second and Unavailable Second counters must be adjusted



Transmission MIB Working Group                                  [Page 5]

RFC 1232                 DS1 Interface Objects                  May 1991


               when the Unavailable Signal State is entered.  Clearly,
               successive GETs of the affected ds1IntervalSES and
               ds1IntervalUAS objects will return differing values if
               the first GET occurs during the first few seconds of the
               window.  This is viewed as an unavoidable side-effect of
               selecting the presently deployed AT&T objects as a basis
               for this memo.

          Yellow Alarm
               A Yellow Alarm is declared because of an incoming Yellow
               Signal from the far-end.  In effect, the circuit is
               declared to be a one way link.

          Red Alarm
               A Red Alarm is declared because of an incoming Loss of
               Signal, Loss of Framing, Alarm Indication Signal.  After
               a Red Alarm is declared, the device sends a Yellow Signal
               to the far-end.  The far-end, when receives the Yellow
               Signal, declares a Yellow Alarm.

          Circuit Identifier
               This is a character string specified by the circuit
               vendor, and is useful when communicating with the vendor
               during the troubleshooting process.

5.  Definitions


          RFC1232-MIB DEFINITIONS ::= BEGIN

          IMPORTS
                  experimental, Counter
                          FROM RFC1155-SMI
                  DisplayString
                          FROM RFC1158-MIB
                  OBJECT-TYPE
                          FROM RFC-1212;

          --  This MIB module uses the extended OBJECT-TYPE macro as
          --  defined in [13].


          --  this is the MIB module for ds1 objects

          ds1 OBJECT IDENTIFIER ::= { experimental 2 }

          -- the DS1 Configuration group




Transmission MIB Working Group                                  [Page 6]

RFC 1232                 DS1 Interface Objects                  May 1991


          -- Although the objects in this group are read-only, at the
          -- agent's discretion they may be made read-write so that the
          -- management station, when appropriately authorized, may
          -- change the behavior of the CSU, e.g., to place the device
          -- into a loopback state or emit a QRSS BER test.

          -- Implementation of this group is mandatory for all systems
          -- that attach to a ds1.

          ds1ConfigTable OBJECT-TYPE
              SYNTAX  SEQUENCE OF DS1ConfigEntry
              ACCESS  not-accessible
              STATUS  mandatory
              DESCRIPTION
                      "The DS1 Configuration table."
              ::= { ds1 1 }

          ds1ConfigEntry OBJECT-TYPE
              SYNTAX  DS1ConfigEntry
              ACCESS  not-accessible
              STATUS  mandatory
              DESCRIPTION
                      "An entry in the DS1 Configuration table."
              INDEX   { ds1CSUIndex }
              ::= { ds1ConfigTable 1 }

          DS1ConfigEntry ::=
              SEQUENCE {
                  ds1CSUIndex
                      INTEGER,
                  ds1Index
                      INTEGER,
                  ds1TimeElapsed
                      INTEGER (1..900),
                  ds1ValidIntervals
                      INTEGER (0..96),
                  ds1LineType
                      INTEGER,
                  ds1ZeroCoding
                      INTEGER,
                  ds1Loopback
                      INTEGER,
                  ds1SendCode
                      INTEGER,
                  ds1YellowAlarm
                      INTEGER,
                  ds1RedAlarm
                      INTEGER,