rfc2115.txt

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

Network Working Group                                       C. Brown
Request for Comments: 2115                      Cadia Networks, Inc.
Obsoletes: 1315                                             F. Baker
Category: Standards Track                              Cisco Systems
                                                      September 1997



            Management Information Base for Frame Relay DTEs
                              Using SMIv2

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


2.  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 Frame Relay interfaces
   on DTEs.

Table of Contents

   1 Status of this Memo ...................................    1
   2 Abstract ..............................................    1
   3 The SNMPv2 Network Management Framework ...............    2
   4 Overview ..............................................    2
   4.1 Frame Relay Operational Model .......................    2
   4.2 Textual Conventions .................................    6
   4.3 Structure of MIB ....................................    6
   5 Changes from RFC 1315 .................................    6
   6 Definitions ...........................................    8
   6.1 Data Link Connection Management Interface ...........    9
   6.2 Circuit Table .......................................   14
   6.3 Error Table .........................................   22
   6.4 Trap Management .....................................   25
   7 Security Issues .......................................   30
   8 Acknowledgments .......................................   30
   9 Authors' Addresses ....................................   31
   10 References ...........................................   31





Brown & Baker               Standards Track                     [Page 1]

RFC 2115                  Frame Relay DTE MIB             September 1997


3.  The SNMPv2 Network Management Framework

   The major components of the SNMPv2 Network Management framework are
   described in the documents listed below.

   o    RFC 1902 [1] defines the Structure of Management
        Information (SMI), the mechanisms used for describing and
        naming objects for the purpose of management.

   o    STD 17, RFC 1213 [2] defines MIB-II, the core set of
        managed objects (MO) for the Internet suite of protocols.

   o    RFC 1905 [3] defines the protocol used for network access
        to managed objects.

   The framework is adaptable/extensible by defining new MIBs to suit
   the requirements of specific applications/protocols/situations.

   Managed objects are accessed via a virtual information store, the
   MIB.  Objects in the MIB are defined using the subset of Abstract
   Syntax Notation One (ASN.1) defined in the SMI. In particular, each
   object type is named by an OBJECT IDENTIFIER, which is an
   administratively assigned name. The object type together with an
   object instance serves to uniquely identify a specific instantiation
   of the object. For human convenience, often a textual string, termed
   the descriptor, is used to refer to the object type.

4.  Overview

4.1.  Frame Relay Operational Model

   For the purposes of understanding this document, Frame Relay is
   viewed as a multi-access media, not as a group of point- to-point
   connections. This model proposes that Frame Relay is a single
   interface to the network (physical connection) with many destinations
   or neighbors (virtual connections). This view enables a network
   manager the ability to group all virtual connections with their
   corresponding physical connection thereby allowing simpler
   diagnostics and trouble shooting.

   With the extension of the interfaces MIB, it is possible to configure
   frame relay DLCs as individual interfaces and create ifTable entries
   for each. This is not recommended and is not directly supported by
   this MIB. Additionally, in the presence of demand circuits creation
   of individual ifEntries for each is not possible.






Brown & Baker               Standards Track                     [Page 2]

RFC 2115                  Frame Relay DTE MIB             September 1997


   Should the user wish to group DLCs together to associate them with a
   higher layer, or to associate a DLC with an unnumbered point-to-point
   service, the frame relay DTE MIB provides an entry in the
   frCircuitEntry record. For example, suppose one were to configure a
   company proprietary protocol to run above several of the frame relay
   VCs. The basic layering would look something like the following:

      IP (ipaddrEntry 1 )  IP (ipaddrEntry 2)  IP (ipaddrEntry 3)
         |                    |                     |
         |                    |                     |
         |                    |              proprietary protocol
         |                    |              layer   (ifIndex 3)
         |                    |                     |
         |                    |                     |
      DLCI 20            DLCI 30            DLCI 40/41/42
      (ifIndex 2)        (ifIndex 2)         (ifIndex 2,
                                              logical ifIndex 3)
         |                    |                     |
         |                    |                     |
         |____________________|_____________________|
                              |
                              |
                      FR  DLMCI (ifIndex.2)
                              |
                              |
                   Physical Interface (ifIndex.1)



A configuration which specified that DLCI 40, 41,and 42 were associated
with a proprietary protocol layer, while DLCI 20 and 30 were to run IP
directly can now be expressed using a combination of frCircuitIfIndex
and frCircuitLogicalIfIndex.  In this particular case DLCIs 40, 41 and
42 would use frCircuitIfIndex equal to the frame relay interface level
(2) while their frCircuitLogicalIfIndex would indicate the proprietary
protocol (3). DLCIs 20 and 30 would have both instances set to the frame
relay interface (2).

      Object           Meaning for Frame Relay Interface
      ______           _____________________________________

      ifDescr          As per DESCRIPTION in RFC 1573.
      ifType           The value allocated for Frame Relay
                       Interfaces - frameRelay (32).

      ifMtu            Set to maximum frame size in octets for
                       this frame relay interface.




Brown & Baker               Standards Track                     [Page 3]

RFC 2115                  Frame Relay DTE MIB             September 1997


      ifSpeed          The access rate for the frame relay
                       interface.  This could be different from
                       the speed of the underlying physical
                       interface, e.g. in a fractional T1 case
                       the access rate could be 384 kbits/s (the
                       value reported in this object) whereas the
                       speed of the underlying interface would be
                       1.544 Mbits/s (the value reported in the
                       instance of ifSpeed for the ifEntry with
                       type ds1).

      ifPhysAddress    The primary address for this interface
                       assigned by the Frame Relay interface
                       provider.  An octet string of zero length
                       if no address is used for this interface.

      ifAdminStatus    As per DESCRIPTION in RFC 1573.

      ifOperStatus     As per DESCRIPTION in RFC 1573.

      ifLastChange     As per DESCRIPTION in RFC 1573.

      ifInOctets       The number of received octets.  This
                       includes not only the information field
                       (user data) but also the frame relay header
                       and CRC.

      ifInUcastPkts    The number of frames received on non-
                       multicast DLCIs

      ifInDiscards     The number of frames that were successfully
                       received but were discarded because of
                       format errors or because the VC was not
                       known.  Format errors, in this case, are
                       any errors which would prevent the system
                       from recognizing the DLCI and placing the
                       error in the frCircuitDiscard category.

      ifInErrors       The number of received frames that are
                       discarded, because of an error.
                       Possible errors can be the following: the
                       frame relay frames were too long or were
                       too short, the frames had an invalid or
                       unrecognized DLCI values, or incorrect
                       header values.






Brown & Baker               Standards Track                     [Page 4]

RFC 2115                  Frame Relay DTE MIB             September 1997


      ifInUnknownProtos  Number of unknown or unsupported
                       upper layer protocol frames received
                       and discarded.

      ifOutOctets      The number of received octets.  This
                       includes not only the information field
                       (user data) but also the frame relay header
                       and CRC.

      ifOutUcastpkts   The number of frames sent.

      ifOutDiscards    The number of frames discarded in the
                       transmit direction.

      ifOutErrors      The number of frames discarded in the
                       egress direction, because of errors.

      ifName           As per DESCRIPTION in RFC 1573.

      ifInMulticastPkts   The number of unerrored frames received
                          on a multicast DLCI.

      ifInBroadcastPkts   Always zero (0) as there are no broadcast
                          frames.

      ifOutMulticastPkts  The number of frames transmitted over a
                          multicast DLCI.

      ifOutBroadcastPkts  Always zero (0) as there are no broadcast
                          frames.

      ifHCInOctets     Only required when ifSpeed >= 155 Mbits/s.
     See
                       details for ifInOctets.

      ifHCOutOctets    Only required when ifSpeed >= 155 Mbits/s.
     See
                       details for ifInOctets.

      ifLinkUpDownTrapEnble  As per DESCRIPTION in RFC 1573.

      ifHighSpeed      The access rate of the frame relay interface
                       measured in Mbits/s.  If the access rate is
                       less than 1 Mbits/s, this object returns 0.

      ifPromiscuousMode   Set to false(2).

      ifConnectorPresent  Set to false(2).



Brown & Baker               Standards Track                     [Page 5]

RFC 2115                  Frame Relay DTE MIB             September 1997



4.2.  Textual Conventions

   One new data type is introduced as a textual convention in this MIB
   document.  This textual convention enhances the readability of the
   specification and can ease comparison with other specifications if
   appropriate.  It should be noted that the introduction of this
   textual conventions has no effect on either the syntax nor the
   semantics of any managed objects.  The use of this is merely an
   artifact of the explanatory method used.  Objects defined in terms of
   one of these methods are always encoded by means of the rules that
   define the primitive type.  Hence, no changes to the SMI or the SNMP
   are necessary to accommodate this textual conventions which is
   adopted merely for the convenience of readers and writers in pursuit
   of the elusive goal of clear, concise, and unambiguous MIB documents.

   The new data type is DLCI.  DLCI refers to the range 0..DLCINumber,
   and is used to refer to the valid Data Link Connection Indices.
   DLCINumber is, by definition, the largest possible DLCI value
   possible under the configured Q.922 Address Format.

4.3.  Structure of MIB

   The MIB is composed of three groups, one defining the Data Link
   Connection Management Interface (DLCMI), one describing the Circuits,
   and a third describing errors.

   During normal operation, Frame Relay virtual circuits will be added,
   deleted and change availability. The occurrence of such changes is of
   interest to the network manager and therefore, one trap is defined,
   intended to be corollary to the SNMP "Link Up" and "Link Down" traps.

5.  Changes from RFC 1315

   Below are listed the changes from the previously published version
   this document, which was RFC 1315:

   o    The MIB module was converted from SMIv1 to SMIv2 format.
        Note: due to this, the table indices have access of
        "read-only" instead of "not-accessible", which is the
        typical value for index objects in SMIv2.

   o    The module name was changed from RFC1315-MIB to FRAME-
        RELAY-DTE-MIB.

   o    The textual convention "Index" was dropped from the MIB
        module and "InterfaceIndex" from the interfaces MIB
        module, IF-MIB, was used in its place.



Brown & Baker               Standards Track                     [Page 6]

RFC 2115                  Frame Relay DTE MIB             September 1997



   o    Objects frDlcmiStatus and frDlcmiRowStatus were added to
        table frDlcmiTable.

   o    Added values "itut933A(5)" (from CCITT Q933 Annex A) and
        "ansiT1617D1994(6)" (from ANSI T1.617a-1994 Annex D) to
        the enumerations for object frDlcmiState.

   o    The labels for the enumerated values for object
        frDlcmiAddressLen were renamed to remove their hyphens as
        required by SMIv2.

   o    Added clarification that the "management virtual circuit"
        (i.e. DLCI 0) is a member of the circuit table.

   o    Added the following objects to table frCircuitTable:
        frCircuitMulticast, frCircuitType, frCircuitDiscards,
        frCircuitReceivedDEs, frCircuitSentDEs,
        frCircuitLogicalIfIndex, and  frCircuitRowStatus.

   o    The definition of object frCircuitReceivedOctets was
        clarified as to which octets were counted.

   o    Added the objects frErrFaults and frErrFaultTime to table
        frErrTable.

   o    Added clarification to the values of object frErrType.

   o    Added size on definition of object frErrData and
        clarified what data to capture.

   o    Changed identififier for OID value { frameDelayDTE 4 }
        from frame-relay-globals to frameRelayTrapControl.

   o    Added object frTrapMaxRate.


   o    Created object groups frPortGroup, frCircuitGroup,
        frTrapGroup, frErrGroup, frPortGroup0, frCircuitGroup0,
        frTrapGroup0, and frErrGroup0.

   o    Created notification group frNotificationGroup.

   o    Created module compliances frCompliance and
        frCompliance0.

   o    Added ranges to objects frCircuitCommittedBurst,
        frCircuitExcessBurst, and frCircuitThroughput.



Brown & Baker               Standards Track                     [Page 7]

RFC 2115                  Frame Relay DTE MIB             September 1997



6.  Definitions

     FRAME-RELAY-DTE-MIB DEFINITIONS ::= BEGIN

     IMPORTS
                 MODULE-IDENTITY, OBJECT-TYPE, Counter32,
                 Integer32, NOTIFICATION-TYPE            FROM SNMPv2-SMI
                 TEXTUAL-CONVENTION, RowStatus, TimeStamp FROM SNMPv2-TC
                 MODULE-COMPLIANCE, OBJECT-GROUP,
                 NOTIFICATION-GROUP                     FROM SNMPv2-CONF
                 transmission                           FROM RFC1213-MIB
                 InterfaceIndex                           FROM IF-MIB;

     --  Frame Relay DTE MIB

     frameRelayDTE MODULE-IDENTITY
         LAST-UPDATED "9705010229Z" -- Thu May  1 02:29:46 PDT 1997
         ORGANIZATION "IETF IPLPDN Working Group"
         CONTACT-INFO
            "       Caralyn Brown
            Postal: Cadia Networks, Inc.
                    1 Corporate Drive
                    Andover, Massachusetts  01810
            Tel:    [phone] x133
            E-Mail: [e-mail]

                    Fred Baker
            Postal: Cisco Systems
                    519 Lado Drive
                    Santa Barbara, California 93111
            Tel:    [phone]
            E-Mail: [e-mail]"
         DESCRIPTION
            "The MIB module to describe the use of a Frame Relay
            interface by a DTE."
         REVISION "9705010229Z" -- Thu May  1 02:29:46 PDT 1997
         DESCRIPTION
            "Converted from SMIv1 to SMIv2. (Thus, indices are
            read-only rather than being not-accessible.) Added
            objects and made clarifications based on implementation
            experience."

         REVISION "9204010000Z"
         DESCRIPTION
            "Published as RFC 1315, the initial version of this MIB
            module."
         ::= { transmission 32 }