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) . This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI , and semantically identical to the SNMPv1 definitions . 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)  . . . . . . . . . 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  which defines the SMI, the mechanisms used for describing and naming objects for the purpose of management. STD 17, RFC 1213  defines MIB-II, the core set of managed objects for the Internet suite of protocols. STD 15, RFC 1157  and RFC 1905  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)  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 : 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  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 220.127.116.11 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. 18.104.22.168 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. 22.214.171.124 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.
126.96.36.199 Identifying the protocol level of a partner DLSw If the partner DLSw has implemented at least the AIW Version 1 DLSw Standard , 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. 188.8.131.52 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. 184.108.40.206 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. 220.127.116.11 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. 18.104.22.168 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. 22.214.171.124 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. 126.96.36.199 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. 188.8.131.52 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. 184.108.40.206 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. 220.127.116.11 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. 18.104.22.168 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. 22.214.171.124 Cutting down the flow of DLSw-related traps Set some or all of the dlswTrapCntl* objects to the value of `disabled' or `partial'.