rfc2128.txt

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

Network Working Group                                 G. Roeck, Editor
Request for Comments: 2128                               cisco Systems
Category: Standards Track                                   March 1997


          Dial Control Management Information Base using SMIv2

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.

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 managed objects used for managing demand
   access circuits, including ISDN.

   This document specifies a MIB module in a manner that is compliant to
   the SNMPv2 SMI.  The set of objects is consistent with the SNMP
   framework and existing SNMP standards.

   This document is a product of the ISDN MIB working group within the
   Internet Engineering Task Force.  Comments are solicited and should
   be addressed to the working group's mailing list at isdn-
   [e-mail] and/or the author.

Table of Contents

   1 The SNMPv2 Network Management Framework ......................    2
   1.1 Object Definitions .........................................    2
   2 Overview .....................................................    2
   2.1 Structure of MIB ...........................................    2
   2.2 Relationship to the Interfaces MIB .........................    3
   2.2.1 Layering Model and Virtual Circuits ......................    3
   2.2.2 ifTestTable ..............................................    4
   2.2.3 ifRcvAddressTable ........................................    4
   2.2.3.1 ifEntry for a single peer ..............................    5
   2.3 Multilink and backup line support ..........................    5
   2.4 Support for generic peers ..................................    5
   3 Definitions ..................................................    6
   3.1 Dial Control MIB ...........................................    6
   4 Acknowledgments ..............................................   32
   5 References ...................................................   33



Roeck                   Standards Track                         [Page 1]

RFC 2128                    Dial Control MIB                  March 1997


   6 Security Considerations ......................................   33
   7 Author's Address .............................................   34

1.  The SNMPv2 Network Management Framework

   The SNMPv2 Network Management Framework presently consists of three
   major components.  They are:

   o    the SMI, described in RFC 1902 [1] - the mechanisms used for
        describing and naming objects for the purpose of management.

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

   o    the protocol, STD 15, RFC 1157 [3] and/or RFC 1905 [4], -
        the protocol for accessing managed objects.

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

1.1.  Object Definitions

   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)
   defined in the SMI.  In particular, each object type is named by an
   OBJECT IDENTIFIER, 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, we
   often use a textual string, termed the descriptor, to refer to the
   object type.

2.  Overview

2.1.  Structure of MIB

   Managing demand access circuits requires the following groups of
   information:

   o    General configuration information.

   o    Information to describe peer configuration and peer statistics.
        In this respect, peer configuration means information on how to
        connect to peers on outgoing calls, how to identify peers on
        incoming calls, and other call related configuration
        information.

   o    Information to store active call information.



Roeck                   Standards Track                         [Page 2]

RFC 2128                    Dial Control MIB                  March 1997


   o    Information to retain call history.

   The MIB, therefore, is structured into four groups.

   o    The dialCtlConfiguration group is used to specify general
        configuration information.

   o    The dialCtlPeer group is used to describe peer configuration
        and peer statistics.

   o    The callActive group is used to store active call information.

   o    The callHistory group is used to store call history information.
        These calls could be circuit switched or they could be virtual
        circuits. History of each and every call is stored, of successful
        calls as well as unsuccessful and rejected calls.  An entry will
        be created when a call is cleared.

2.2.  Relationship to the Interfaces MIB

   This section clarifies the relationship of this MIB to the Interfaces
   MIB [8].  Several areas of correlation are addressed in the following
   subsections.  The implementor is referred to the Interfaces MIB
   document in order to understand the general intent of these areas.

2.2.1.  Layering Model and Virtual Circuits

   On an occasional access channel, there are a number of peer systems
   that are permitted to call or be called, all of which need to be
   treated as active from a routing viewpoint, but most of which have no
   call in progress at any given time.

   On dialup interfaces, this is further complicated by the fact that
   calls to a given peer float from channel to channel. One cannot
   definitively say "I call this peer on that interface." It is
   necessary, therefore, to provide a mapping algorithm between the
   low-level interfaces, and the various logical interfaces supporting
   the peers.  This is solved by creating a logical interface (ifEntry)
   for each peer and a logical interface (ifEntry) for each low-level
   interface.  These are then correlated using the ifStackTable.

   The low-level interfaces are either physical interfaces, e.g.  modem
   interfaces, or logical interfaces, e.g. ISDN B channels, which then
   in turn are layered on top of physical ISDN interfaces.







Roeck                   Standards Track                         [Page 3]

RFC 2128                    Dial Control MIB                  March 1997


   The model, therefore, looks something like this, taking ISDN as an
   example:

+-------------------------------------------------------+
|               Network Layer Protocol                  |
+------+ +-------+ +-------+ +-------+ +-------+ +------+
       | |       | |       | |       | |       | | <== appears active
     +-+ +-+   +-+ +-+   +-+ +-+   +-+ +-+   +-+ +-+
     | PPP |   | PPP |   | F/R |   | PPP |   | F/R |
     | for |   | for |   | for |   | for |   | for |   ifEntry with
     |Peer1|   |Peer2|   |switch   |Peer3|   |switch   shadow PeerEntry
     |     |   |     |   |  A  |   |     |   |  B  |
     +-+ +-+   +-+ +-+   +-+ +-+   +-+ +-+   +-+ +-+
                 | |                 | |           <== some actually are
    +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+
    |   B   | |   B   | |   B   | |   B   | |   B   |
    |channel| |channel| |channel| |channel| |channel|
    +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+
       | |       | |       | |       | |       | |
+------+ +-------+ +-------+ +-------+ +-------+ +------+
|             Basic/Primary Rate Interface              |
+-------------------------------------------------------+

   Mapping of IP interfaces to Called Peers to B Channels

   IfEntries are maintained for each peer.

   In this model, each peer is required to have an associated
   encapsulation layer interface. This interface can be of any kind,
   e.g. PPP or LAPB.

   In order to specify the network address for a given peer, one would
   then usually add a routing/forwarding table entry, pointing to the
   encapsulation layer interface through which this peer can be reached.

2.2.2.  ifTestTable

   The ifTestTable usage is defined in the MIBs defining the
   encapsulation below the network layer.  For example, if PPP
   encapsulation is being used, the ifTestTable is defined by PPP.

2.2.3.  ifRcvAddressTable

   The ifRcvAddressTable usage is defined in the MIBs defining the
   encapsulation below the network layer.  For example, if PPP
   encapsulation is being used, the ifRcvAddressTable is defined by PPP.





Roeck                   Standards Track                         [Page 4]

RFC 2128                    Dial Control MIB                  March 1997


2.2.3.1.  ifEntry for a single peer

   IfEntries are defined in the MIBs defining the encapsulation below
   the network layer.  For example, if PPP encapsulation is being used,
   the ifEntry is defined by PPP.

   ifEntries will never be created by the Dial Control MIB.  The Dial
   Control MIB always depends on some other ifIndex of some set of
   ifTypes.  That is, to create an entry in the Dial Control MIB, the
   base ifEntry must already have been created through some other
   mechanism.

   The Dial Control entry does have its own RowStatus, permitting the
   Dial Control supplementary information to come and go, but not
   otherwise disturbing the ifIndex to which it is attached.  If in a
   given implementation the two are tightly bound, deleting the ifEntry
   may have the side effect of deleting the Dial Control entry.

2.3.  Multilink and backup line support

   In order to support multilink and backup procedures, there may be
   several entries for a single peer in the dialCtlPeerCfgTable.

   A single peer is identified using the dialCtlPeerCfgId object of the
   dialCtlPeerCfgTable.  There may be several entries in
   dialCtlPeerCfgTable with the same value of dialCtlPeerCfgId, but
   different ifIndex values.  Each of those entries will then describe a
   possible connection to the same peer.  Such entries can then be used
   to handle multilink as well as backup procedures, e.g. by bundling
   the attached ifEntries using PPP multilink.

2.4.  Support for generic peers

   Generic peers can for example be supported by permitting wild-card
   characters (e.g., '?' or '*') in dialCtlPeerCfgAnswerAddress.  A
   number to be accepted could then be defined as partly (e.g., '*1234')
   or entirely generic (e.g., '*').

   A detailed specification of such a functionality is outside the scope
   of this document.

   However, the implementor should be aware that supporting generic
   peers may cause a security hole.  The user would not know where a
   call is from, which could potentially allow unauthorized access.







Roeck                   Standards Track                         [Page 5]

RFC 2128                    Dial Control MIB                  March 1997


3.  Definitions

3.1.  Dial Control MIB

DIAL-CONTROL-MIB DEFINITIONS ::= BEGIN

IMPORTS
        MODULE-IDENTITY,
        NOTIFICATION-TYPE,
        OBJECT-TYPE,
        Unsigned32
                FROM SNMPv2-SMI
        TEXTUAL-CONVENTION,
        DisplayString,
        TimeStamp,
        RowStatus
                 FROM SNMPv2-TC
        MODULE-COMPLIANCE,
        OBJECT-GROUP,
        NOTIFICATION-GROUP
                FROM SNMPv2-CONF
        IANAifType
                FROM IANAifType-MIB
        ifOperStatus,
        ifIndex,
        InterfaceIndex,
        InterfaceIndexOrZero
                FROM IF-MIB
        transmission
                FROM RFC1213-MIB;

dialControlMib MODULE-IDENTITY
        LAST-UPDATED    "9609231544Z" -- Sep 23, 1996
        ORGANIZATION    "IETF ISDN Working Group"
        CONTACT-INFO
            "        Guenter Roeck
             Postal: cisco Systems
                     170 West Tasman Drive
                     San Jose, CA 95134
                     U.S.A.
             Phone:  [phone]
             E-mail: [e-mail]"
        DESCRIPTION
            "The MIB module to describe peer information for
             demand access and possibly other kinds of interfaces."
        ::= { transmission 21 }

AbsoluteCounter32 ::= TEXTUAL-CONVENTION



Roeck                   Standards Track                         [Page 6]

RFC 2128                    Dial Control MIB                  March 1997


        STATUS      current
        DESCRIPTION
            "Represents a Counter32-like value that starts at zero,
             does not decrease, and does not wrap. This may be used
             only in situations where wrapping is not possible or
             extremely unlikely. Should such a counter overflow,
             it locks at the maxium value of 4,294,967,295.

             The primary use of this type of counter is situations
             where a counter value is to be recorded as history
             and is thus no longer subject to reading for changing
             values."
        SYNTAX      Unsigned32

-- Dial Control Mib objects definitions

dialControlMibObjects OBJECT IDENTIFIER ::= { dialControlMib 1 }

-- General configuration group

dialCtlConfiguration OBJECT IDENTIFIER ::= { dialControlMibObjects 1 }

-- general configuration data/parameters

dialCtlAcceptMode OBJECT-TYPE
        SYNTAX INTEGER {
            acceptNone(1),