rfc1233.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,291 行 · 第 1/4 页

Network Working Group                                            T. Cox
Request for Comments: 1233                                    K. Tesink
                                           Bell Communications Research
                                                                Editors
                                                               May 1991


                     Definitions of Managed Objects
                       for the DS3 Interface Type

Status of this Memo

   This memo defines objects for managing DS3 Interface objects for use
   with the SNMP protocol.  This memo is a product of the SNMP and
   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 ........................    3
   4.3 DS3 Terminology ......................................    3
   5. Object Definitions ....................................    5
   5.1 The DS3 Configuration Group ..........................    6
   5.2 The DS3 Interval Group ...............................   11
   5.3 The DS3 Current Group ................................   14
   5.4 The DS3 Total Group ..................................   17
   6. Acknowledgments .......................................   20
   7. References ............................................   22
   8. Security Considerations................................   23
   9. Authors' Addresses.....................................   23

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
   for representing DS3 physical interfaces.  Implementors should
   consult in addition to this memo the companion document that



SNMP & Transmission MIB Working Groups                          [Page 1]

RFC 1233                 DS3 Interface Objects                  May 1991


   describes that DS1 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.  The SMI
   specifies the use of the basic encoding rules of ASN.1 [8], subject
   to the additional requirements imposed by the SNMP.



SNMP & Transmission MIB Working Groups                          [Page 2]

RFC 1233                 DS3 Interface Objects                  May 1991


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 DS3 interface.  At present, this applies to
   these values of the ifType variable in the Internet-standard MIB:

               ds3 (30)

   The definitions contained herein are based on the DS3 specifications
   in ANSI T1.102-1987, ANSI T1.107-1988, and ANSI T1.404-1989
   [9,10,11].

4.1.  Binding between Interfaces and CSUs

   Each agent which resides on a host which uses DS3 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 DS3 interfaces.

   The ds3Index column of the DS3 Configuration table relates each CSU
   to its corresponding interface in the Internet-standard MIB.

4.2.  Objectives of this MIB Module

   There are numerous things that could be included in a MIB for DS3
   signals: 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.

4.3.  DS3 Terminology

   The terminology used in this document to describe error conditions on
   a DS3 circuit as monitored by a DS3 CSU are from the ANSI T1M1.3/90
   draft standard [12].

          Out of Frame (OOF) event
               An OOF event is detected when any three or more errors in



SNMP & Transmission MIB Working Groups                          [Page 3]

RFC 1233                 DS3 Interface Objects                  May 1991


               sixteen or fewer consecutive F-bits occur within a DS3
               M-frame.  An OOF event is cleared when reframe occurs.

          Loss of Signal (LOS)
               This state is declared upon observing 175 +/- 75
               contiguous pulse positions with no pulses of either
               positive or negative polarity.

          Coding Violation (CV)
               For all DS3 applications, a coding violation is a P-bit
               Parity Error event.  A P-bit Parity Error event is the
               occurrence of a received P-bit code on the DS3 M-frame
               that is not identical to the corresponding locally-
               calculated code.  For C-Bit Parity applications, it is
               also the occurrence of a received CP-Bit parity
               violation.  For SYNTRAN applications, it is also the
               occurrence of a received CRC-9 code that is not identical
               to the corresponding locally calculated code.

          Bipolar Violation (BPV)
               A bipolar violation, for B3ZS-coded signals, is the
               occurrence of a received bipolar violation that is not
               part of a zero-substitution code.  For B3ZS-coded
               signals, a bipolar violation may also include other error
               patterns such as:  three or more consecutive zeros and
               incorrect parity.

          Errored Seconds (ES)
               An ES is a second with one or more Coding Violation OR
               one or more Out of Frame events OR an AIS.

          Severely Errored Seconds (SES)
               A SES is a second with 44 or more Coding Violations OR
               one or more Out of Frame events OR an AIS.

          Severely Errored Framing Seconds (SEFS)
               A SEFS is a second with one or more Out of Frame events.

          Unavailable Seconds (UAS)
               UAS are calculated by counting the number of seconds that
               the CSU is in the Unavailable signal state (i.e.,
               declared a Red Alarm or a Yellow Alarm), 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 UAS may
               not be counted as an ES or a SES.  Since the 10 SESs that
               comprise the transition from the available to unavailable



SNMP & Transmission MIB Working Groups                          [Page 4]

RFC 1233                 DS3 Interface Objects                  May 1991


               signal state may also be counted as ESs and SESs 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 ESs.

               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 SES and UAS
               counters must be adjusted when the Unavailable Signal
               State is entered. Clearly, successive GETs of the
               affected ds3IntervalSES and ds3IntervalUAS 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
               defined managed objects as a basis for this memo.

          Yellow Alarm
               The Yellow Alarm is declared after detecting the Yellow
               Signal.  See ANSI T1.107-1989 [10].

          Red Alarm
               The Red Alarm is declared after detecting a Loss of
               Signal, a Loss of Frame (a persistent OOF event), or an
               Alarm Indication Signal, see [10] for at least 2-10
               seconds.  The Red Alarm is cleared at the onset of 10
               consecutive seconds with no SES.

          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.  Object Definitions

               RFC1233-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].




SNMP & Transmission MIB Working Groups                          [Page 5]

RFC 1233                 DS3 Interface Objects                  May 1991


               --  this is the MIB module for the DS3 objects

               ds3     OBJECT IDENTIFIER ::= { experimental 15 }

               -- the DS3 Configuration group

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

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

               ds3ConfigTable OBJECT-TYPE
                   SYNTAX  SEQUENCE OF DS3ConfigEntry
                   ACCESS  not-accessible
                   STATUS  mandatory
                   DESCRIPTION
                           "The DS3 Configuration table."
                  ::= { ds3 1 }

              ds3ConfigEntry OBJECT-TYPE
                  SYNTAX  DS3ConfigEntry
                  ACCESS  not-accessible
                  STATUS  mandatory
                  DESCRIPTION
                          "An entry in the DS3 Configuration table."
                 INDEX   { ds3CSUIndex }
                 ::= { ds3ConfigTable 1 }

             DS3ConfigEntry ::=
                 SEQUENCE {
                     ds3CSUIndex
                         INTEGER,
                     ds3Index