rfc2024.txt

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

Network Working Group                                   D. Chen, Editor
Request for Comments: 2024                                     P. Gayek
Category: Standards Track                                           IBM
                                                                 S. Nix
                                                         Metaplex, Inc.
                                                           October 1996


         Definitions of Managed Objects for Data Link Switching
                              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 specification defines an extension to the Management Information
   Base (MIB) for use with SNMP-based network management.  In
   particular, it defines objects for configuring, monitoring, and
   controlling Data Link Switches (DLSw) [1].

   This memo specifies a MIB module in a manner that is both compliant
   to the SNMPv2 SMI [2], and semantically identical to the SNMPv1
   definitions [3].

Table of Contents

   1.0  The SNMPv2 Network Management Framework    . . . . . . . . .   2
   1.1  Object Definitions  . . . . . . . . . . .  . . . . . . . . .   2
   2.0  Overview  . . . . . . . . . . . . . . . .  . . . . . . . . .   2
   2.1  Relation to Interface Group (RFC 1573) [8] . . . . . . . . .   2
   2.2  Relation to Underlying DLC Layer  . . . .  . . . . . . . . .   3
   2.3  Relation to SDLC MIB (RFC 1747)   . . . .  . . . . . . . . .   3
   2.4  DLSw MIB Structure  . . . . . . . . . . .  . . . . . . . . .   4
     2.4.1  Compliance  . . . . . . . . . . . . .  . . . . . . . . .   4
   2.5  DLSw MIB Usage  . . . . . . . . . . . . .  . . . . . . . . .   5
     2.5.1  Cooperative DLSw nodes  . . . . . . .  . . . . . . . . .   5
     2.5.2  Setting capabilities exchange-related objects    . . . .   5
     2.5.3  Examples of Tasks Using This MIB  . . . . . . .  . . . .   6
   3.0  Definitions   . . . . . . . . . . . . . . . . . . .  . . . .  11
   4.0  Acknowledgements  . . . . . . . . . . . . . . . . .  . . . .  89
   5.0  References  . . . . . . . . . . . . . . . . . . . .  . . . .  89
   6.0  Security Considerations   . . . . . . . . . . . . .  . . . .  90



Chen, et. al.               Standards Track                     [Page 1]

RFC 2024                  DLSw MIB using SMIv2              October 1996


   7.0  Authors' Addresses  . . . . . . . . . . . . . . . .  . . . .  90

1.0  The SNMPv2 Network Management Framework

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

      RFC 1902 [2] which defines the SMI, the mechanisms used for
      describing and naming objects for the purpose of management.

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

      STD 15, RFC 1157 [5] and RFC 1905 [6] which define two versions of
      the protocol used for network access to 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.0  Overview

   This memo identifies the set of objects for configuring, monitoring,
   and controlling Data Link Switches.

2.1  Relation to Interface Group (RFC 1573) [8]

o   ifIndex is used as the index into dlswIfTable, which shows and
    controls the interfaces that DLSw is active on.

o   Local entries in the MAC address and NetBIOS (NB) name caches can
    point to an ifEntry to indicate the interface through which DLSw can
    reach that MAC address or NB name.  See the objects
    dlswDirMacLocation and dlswDirNBLocation.

o   Local entries in the circuit table use ifIndex to indicate the
    interface through which DLSw is connected to the local end station.



Chen, et. al.               Standards Track                     [Page 2]

RFC 2024                  DLSw MIB using SMIv2              October 1996


    See the object dlswCircuitS1Index.

o   ifIndex is the primary index into dlswSdlcLsTable, which lists the
    SDLC stations DLSw is serving.

2.2  Relation to Underlying DLC Layer

   The DLSw MIB does not duplicate the information in the MIBs for the
   DLC layer underneath it.  Instead, each circuit table entry contains
   a pointer to a conceptual row in an underlying enterprise-specific or
   standard DLC MIB.

   Using the 802.2 LLC management as an example, the following rules
   should be considered when developing new DLSw related DLC MIBs, and
   when implementing the interactions between DLSw MIB and DLC MIBs:

o   The referenced row should represent the local LLC-2 (and/or LLC-1,
    if supported) link station that DLSw is using.  In the current 802.2
    LLC MIB draft, this might be a row of one of the tables
    llcCcAdminTable, llcCcOperTable, or llcCcStatsTable.

    A circuit using local LLC services will therefore have
    dlswCircuitS1DlcType = llc, and dlswCircuitS1Dlc = pointer to an LLC
    MIB table row.

o   Because DLSw is the user of LLC services, it is generally preferable
    to initiate administrative actions using the DLSw MIB and allow DLSw
    to control LLC directly, rather than starting with LLC MIB
    administrative actions.  For example, a hung circuit should be
    disconnected by setting dlswCircuitState, as opposed to setting
    llcCcAdminStatus to disable the LLC part of the circuit.  Similarly,
    setting bits in dlswIfSapList will cause row creation in
    llcSapOperTable as well as set the necessary DLSw-LLC relationship.

2.3  Relation to SDLC MIB (RFC 1747)

   The general comments stated in 2.2, "Relation to Underlying DLC
   Layer" apply to the SDLC MIB.  The following apply if the DLSw MIB is
   implemented in a product that also implements RFC 1747 [9]:

o   The row referenced from dlswCircuitS1Dlc should represent the local
    SDLC link station that DLSw is using.  This might be a row of one of
    the tables sdlcLSAdminTable, sdlcLSOperTable, or sdlcLSStatsTable.

    A circuit using local SDLC services will therefore have
    dlswCircuitS1DlcType = sdlc, and dlswCircuitS1Dlc = OID of one of
    these table rows.




Chen, et. al.               Standards Track                     [Page 3]

RFC 2024                  DLSw MIB using SMIv2              October 1996


o   dlswSdlcLsTable uses the same indices that are used to index link
    station information in RFC 1747.  This table provides a mapping
    between this native SDLC addressing (interface, link station
    address) and the addressing used in the DLSw domain (local MAC and
    SAP).

2.4  DLSw MIB Structure

   See 3 .0, "Definitions" on page 11 for a diagram outlining the DLSw
   MIB structure.  The following groups of objects are included:

   dlswNode       Objects related to this DLSw node's configuration,
                  monitoring and control.

   dlswTConn      Objects relating to transport connections to this
                  DLSw's partner nodes.

   dlswInterface  Objects configured for this DLSw relating to its local
                  interfaces.

   dlswDirectory  Objects reflecting this DLSw's view of where
                  end-station resources (MAC addresses and NetBIOS names)
                  are located.

   dlswCircuit    Objects showing the end-station connections that
                  DLSw currently has established, or that are coming up
                  or have gone down.

   dlswSDLC       Objects configured for this DLSw's SDLC-attached end
                  stations.

2.4.1  Compliance

   The MIB provides the following compliance statements:

   dlswCoreCompliance      Defines the minimum support required of all
                           implementations.  Note that for this and the
                           other compliance statements, NetBIOS-related
                           objects are grouped separately because the
                           DLSw Version 1 Standard [1] does not require
                           NetBIOS support.

   dlswTConnTCPCompliance  Defines the minimum support required of
                           implementations that use TCP as a transport
                           protocol.

   dlswDirCompliance       Defines the minimum support required of
                           implementations that support some sort of



Chen, et. al.               Standards Track                     [Page 4]

RFC 2024                  DLSw MIB using SMIv2              October 1996


                           directory function.

   dlswDirLocateCompliance Defines the minimum support required of
                           implementations that support a directory
                           function and also support the ordered
                           retrieval of the entries that match a given
                           resource.

   dlswSdlcCompliance      Defines the minimum support required of
                           implementations that support SDLC-attached
                           end stations.
2.5  DLSw MIB Usage

2.5.1  Cooperative DLSw nodes

   To reduce the size of the MIB, thus the amount of data that each
   agent needs to keep, the information that usually could be made
   available in two partner nodes (e.g., information exchanged between
   them) is only defined in the MIB as the info received.  That is,
   there are no objects defined for the info sent.  In order to form the
   complete picture of the state of a resource, the manager needs to
   retrieve info from multiple DLSw nodes.  An example is that the SAP
   list, NETBIOS list and MAC list are kept at the receiving end of a
   DLSw capabilities exchange (the sender does not save what it sent to
   each partner).

   Note well:  The DLSw protocol does not specify a technique for a
   manager to correlate the transport address of the partner managed
   DLSw node and the transport address that the management protocol
   uses.

2.5.2  Setting capabilities exchange-related objects

   This MIB supports changes to DLSw variables whose change should be
   reported to DLSw partner nodes in a "run-time" capabilities exchange.
   Since a DLSw node normally unicasts these capabilities messages to
   all its active partners, frequent changes to these variables can
   result in excessive network traffic.  To avoid this problem,
   developers of network management applications using this MIB should
   try to group all such changes in a few SNMP SET requests, and should
   send them in bulk.  Agent developers should implement a technique to
   group a number of changes into a single capabilities exchange
   message.  One possible approach is to send a run-time capabilities
   message only if no capabilities-related changes have been received
   for a pre-defined period of time.






Chen, et. al.               Standards Track                     [Page 5]

RFC 2024                  DLSw MIB using SMIv2              October 1996


2.5.3  Examples of Tasks Using This MIB

2.5.3.1  Configuring DLSw to actively connect to a specific TCP/IP
   partner

   Create a conceptual row in dlswTConnConfigTable with:  Index = the
   highest the managed station has used so far + 1; TDomain =
   dlswTCPDomain;  LocalTAddr = this node's DLSw IP address; RemoteTAddr
   = the partner's DLSw IP address;  EntryType = individual; SetupType =
   activePersistent.  Note that determining the index to use may require
   dumping the TConnConfigTable, but this will not typically be a large
   table.  If the DLSw node rejects the row creation due to index
   collision, the management station should increment its index value
   and try again.

2.5.3.2  Configuring DLSw to passively accept any partner

   Create a conceptual row in dlswTConnConfigTable as above but with:
   RemoteTAddr = 0;  EntryType = global;  SetUpType = passive.  Every
   individual transport connection accepted as a result of this global
   row will inherit the configuration values from this row.

   To prevent a specific remote node from being passively accepted as a
   partner, create another row with:  RemoteTAddr = that node's IP
   address; EntryType = individual;  SetupType = excluded.

2.5.3.3  Configuring DLSw to allow or connect to a group of partners

   Define a conceptual row in dlswTConnConfigTable as above but with:
   EntryType = group;  GroupDefinition = pointer to an enterprise-
   specific representation of a group.  For example, a group definition
   might consist of an IP address value and mask, or a multicast IP
   address.  Every individual transport connection accepted as a result
   of this group row will inherit the configuration values from this
   row.

   When a group is created that has some overlap with entries where
   EntryType = individual (there will always be this overlap when a
   global row exists), the DLSw node must use the configured rows using
   a "most specific match wins" rule.  That is, the entry in
   TConnConfigTable with the remote address most nearly matching an
   incoming connection should be used to provide the values for the new
   connection.  For equal matches, the choice of TConnConfigTable entry
   is up to the DLSw node implementation.  Note that the management
   station should never create two TConnConfig rows with duplicate
   remote addressing values.





Chen, et. al.               Standards Track                     [Page 6]

RFC 2024                  DLSw MIB using SMIv2              October 1996