tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 2024

Proposed STD
Pages: 90
Top     in Index     Prev     Next
in Group Index     No Prev: Lowest Number in Group     No Next: Highest Number in Group     Group: DLSWMIB

Definitions of Managed Objects for Data Link Switching using SMIv2

Part 1 of 3, p. 1 to 10
None       Next RFC Part


Top       ToC       Page 1 
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.


   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

Top      ToC       Page 2 
   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.

Top      ToC       Page 3 
    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.

Top      ToC       Page 4 
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

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

   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

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

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

Top      ToC       Page 5 
                           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

   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

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.

Top      ToC       Page 6 
2.5.3  Examples of Tasks Using This MIB  Configuring DLSw to actively connect to a specific TCP/IP

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

   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.

Top      ToC       Page 7  Identifying the protocol level of a partner DLSw

   If the partner DLSw has implemented at least the AIW Version 1 DLSw
   Standard [1], the AIW version and release number for the DLSw
   protocol is accessible from dlswTConnOperPartnerVersion.  If
   TConnOperPartnerVersion is a string of zero length but the
   TConnOperState = `connected' state (i.e., is not still performing
   capabilities exchange), the partner DLSw can be assumed to be an RFC
   1434+ node.  Recycling a transport connection

   Quiesce or forcibly disconnect the transport connection by setting
   TConnOperState to `quiescing' or `disconnecting', and monitor until
   it moves to the `disconnected' state or the TConnOper row disappears.
   The row may disappear because implementations are not required to
   maintain transport connection information after a transport
   connection has gone down.

   The action required to re-activate the transport connection depends
   on the value of TConnConfigSetupType for the relevant TConnConfig
   row.  ActivePersistent connections will attempt to come back
   automatically.  Passive connections must be re-established from the
   remote partner.  ActiveOnDemand connections will be re-established by
   this node, but only after some end-station operation triggers a
   circuit setup attempt.  Investigating why a transport connection went down

   TConnOperDiscTime and TConnOperDiscReason provide the vital
   information of the time and the cause of the disconnection of a
   transport connection and TConnOperDiscActiveCir indicates whether end
   users may have been affected.  This MIB does not specify the duration
   that an agent must make this information available after the
   disconnection of a transport connection occurs.  Manager should try
   the agent of the partner DLSw, if such information is not available
   in one DLSw node.  Additional information might come from the MIB for
   the transport protocol (e.g., TCP or LLC).  dlswTConnStat* and
   dlswTConnConfigOpens give a more general picture of transport
   connection activity, but can't give specific reasons for problems.  Changing the configuration of an active transport connection

   Follow this sequence of managment protocol set operations:

   1.  Use TConnOperConfigIndex to locate the TConnConfig entry that
       governs the configuration of the transport connection.

Top      ToC       Page 8 
   2.  Change the rowStatus of that conceptual row to notInService.  This
       prevents the transport connection from being connected automatically
       if TConnConfigSetupType = activePersistent.
   3.  Quiesce or forcibly disconnect the transport connection by setting
       TConnOperState to `quiescing' or `disconnecting', and monitor until
       it moves to the `disconnected' state or the TConnOper row
   4.  Change the values of TConnConfig variables as desired.
   5.  Change the rowStatus of the TConnConfig conceptual row to active.
       TConnConfigSetupType will subsequently control whether this node
       will actively seek to re-establish the transport connection, or will
       wait.  Checking configuration validity for an active transport

   Use TConnOperConfigIndex to identify the row of TConnConfig for the
   transport connection.  If TConnConfigLastModifyTime is greater than
   TConnOperConnectTime, then one or more of the variables in the
   TConnConfig row may not be valid for the current state of the active
   transport connection.  This is an exception condition and will not
   normally be the case.  Configuring the interfaces and SAPs DLSw will use

   To add DLSw end-station support (not transport connection support) to
   an interface, create a conceptual row for that ifIndex in the
   dlswIfTable.  For many products, you will specify the same single
   virtual segment number for all interfaces.  Indicate the list of SAPs
   to be supported by that interface - this could be all 0xFFs if the
   product has some automatic SAP opening function.

   To open or close a SAP to DLSw on an existing interface, simply set
   or reset the appropriate bit in dlswIfSapList in the table row for
   that interface.  Configuring static MAC address (or NetBIOS name) cache entries

   It is common to configure a few static directory entries to preload
   in the caches of the DLSw nodes and reduce the need for broadcast
   searches.  The following example adds entries to the MAC cache to
   indicate that a specific MAC address is reachable through two
   different remote partners:

   1.  The manager retrieves dlswDirMacCacheNextIndex to get an index
       assignment from the DLSw node.  The DLSw node ensures that the
       retrieved index will not be reused.

Top      ToC       Page 9 
   2.  The manager creates a conceptual row in dlswDirMacTable with:
       Index = the retrieved index; Mac = the MAC address; Mask = all
       0xFF's; EntryType = userConfiguredPublic; LocationType = remote;
       Location = OID for dlswTConnConfigEntry of the 1st partner; Status
       = unknown (recommended for new entries).
   3.  The manager repeats the preceding 2 steps and creates a second row
       using Index = second index retrieved;  Location = OID for
       dlswTConnConfigEntry of the 2nd partner.

   Note that the DLSw node is not obligated to use newly created
   directory entries in the order in which they were created.  It is
   recommended that entries be used in most-specific match first order,
   i.e., an entry with a Mask of all 0xFFs should take precedence over
   one with a "partial wildcard".  The relative order of static versus
   dynamic entries and of "equal length" matches is up to the DLSw

   The dlswDirStat objects can be used to get an idea of the success
   rate for a particular static caching scheme.  Seeing where the directory indicates a given resource is

   To retrieve all directory information related to a given resource (in
   this example, a NetBIOS name), the management station should:

   1.  Retrieve dlswDirLocateNBLocation in the dlswDirLocateNBTable entry
       where NBName = the fully-specified NetBIOS name without wildcards;
       NBMatch = 1.
   2.  Use the returned value (i.e., OID) to retrieve the contents of the
       dlswDirNBEntry itself.
   3.  Repeat the previous two steps with NBMatch = 2, 3, ..., until the
       end of dlswDirLocateNBTable is reached.

   The DLSw node conveys the precedence relationship of the different
   matching directory entries by the order in which it returns their
   OIDs.  Investigating circuit bringup failure

   Circuit bringup takes place in two stages:  explorer flows to locate
   the target resource (MAC address or NetBIOS name);  and establishing
   the circuit itself.  To determine the success of explorer flows, have
   the origin end station initiate a link establishment to the target,
   and look later for cache entries for the target MAC address or
   NetBIOS name.  The dlswTConn*ex* counters also give some visibility
   to which transport connections are being used to look for resources.
   Once circuit establishment is started, an entry of dlswCircuitTable
   for the two MAC/SAP addresses involved is created.

Top      ToC       Page 10 
   dlswCircuitEntryTime, StateTime, and State may provide useful
   information about intermediate states the circuit is reaching before
   becoming disconnected again.  Investigating the failure of an established circuit

   The variables dlswCircuitDiscReason* in the dlswCircuitTable provide
   the key information of the cause of the disconnection of circuits.
   In addition, the underlying DLC MIBs may provide information at the
   link station level, and some clues (e.g., DISC or FRMR counters) at
   the SAP or interface level.  Seeing circuit-level traffic statistics

   Locate the relevant dlswCircuitEntry and follow dlswCircuitS1Dlc to a
   link station-level table entry in the underlying DLC MIB.  Move to
   the corresponding link station's statistics table in the DLC MIB to
   get counters of frames, bytes, etc. for this circuit.  Cutting down the flow of DLSw-related traps

   Set some or all of the dlswTrapCntl* objects to the value of
   `disabled' or `partial'.

Next RFC Part