RFC 2024
Definitions of Managed Objects for Data Link Switching using SMIv2
Pages: 90
Proposed Standard
Proposed Standard
Part 1 of 3 – Pages 1 to 10
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
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.
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.
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
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.
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.
2.5.3.4 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. 2.5.3.5 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. 2.5.3.6 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. 2.5.3.7 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.
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
disappears.
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.
2.5.3.8 Checking configuration validity for an active transport
connection
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.
2.5.3.9 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.
2.5.3.10 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.
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
implementation.
The dlswDirStat objects can be used to get an idea of the success
rate for a particular static caching scheme.
2.5.3.11 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.
2.5.3.12 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.
dlswCircuitEntryTime, StateTime, and State may provide useful information about intermediate states the circuit is reaching before becoming disconnected again. 2.5.3.13 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. 2.5.3.14 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. 2.5.3.15 Cutting down the flow of DLSw-related traps Set some or all of the dlswTrapCntl* objects to the value of `disabled' or `partial'.
(next page on part 2)