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 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. Chen, et. al. Standards Track [Page 7] RFC 2024 DLSw MIB using SMIv2 October 1996 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. Chen, et. al. Standards Track [Page 8] RFC 2024 DLSw MIB using SMIv2 October 1996 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. Chen, et. al. Standards Track [Page 9] RFC 2024 DLSw MIB using SMIv2 October 1996 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'. Chen, et. al. Standards Track [Page 10] RFC 2024 DLSw MIB using SMIv2 October 1996 3.0 Definitions -- ******************************************************************* -- -- The structure of the DLSw MIB (t: indicates table): -- DLSw MIB -- |-- Node Group -- | |-- Node Identity -- | |-- Node Operational Related -- | |-- Node Resource -- | -- |-- Transport Connection Group -- | |-- Statistics -- | |t- Transport Connection Configuration -- | |t- Transport Connection Operation -- | | |-- capabilities -- | | |-- Supported SAP List -- | | |-- statistics -- | | |-- transport connection itself -- | | |-- traffic over the transport connection -- | | |-- directory search activities -- | | |-- search filtered statistics -- | | |-- circuits over the transport connection -- | |-- Transport Specific -- | |-- Tcp -- | |t- Transport Connection Config (Tcp Specific) -- | |t- Transport Connection Operation (Tcp Specific) -- | -- |-- Interface Group -- | |t- interfaces that DLSw is active on. -- | -- |-- Directory Group -- | |-- Statistics -- | |-- Directory Cache -- | | |t- Directory of MAC addresses -- | | |t- Directory of NETBIOS names -- | |-- Locate -- | |t- Directory of Locate MAC -- | |t- Directory of Locate NETBIOS -- | -- |-- Circuit Group -- | |-- Statistics -- | |t- Circuits -- | -- |-- Virtual and non-LAN end stations -- | |t- SDLC end station -- | -- ******************************************************************* Chen, et. al. Standards Track [Page 11] RFC 2024 DLSw MIB using SMIv2 October 1996 -- ******************************************************************* -- This MIB module contains objects necessary for management of Data -- Link Switches. -- -- Terminology: -- (1) DLSw: -- A device which provides data link switching function. -- Sometimes it is referred as a DLSw or DLSw node. -- Local DLSw: The DLSw that the DLSw SNMP Agent is running on. -- Partner DLSw (or DLSw partner): A DLSw node that is "transport -- connected" with the local DLSw. Sometimes the term "DLSw -- partners" is used to indicate the two ends of a transport -- connection. -- -- (2) TCP Connection: -- Full-duplex (-capable) association defined by a pair of -- (IP address, port) pairs, running the TCP protocol. The port -- addresses in RFC 1795 define two TCP connections between -- a pair of DLSw nodes, each being used to send data in a -- single direction. -- Local: This end of TCP connection -- Foreign: Remote end of TCP connection -- -- (3) Transport Connection: -- It is a generic term for a full-duplex reliable connection -- between DLSw nodes. This term is used to refer to the -- association between DLSw nodes without being concerned -- about whether TCP is the protocol or whether there are -- one or two TCP connection. -- (Note: for two TCP connections, the transport connection is -- opened if and only if both TCP connections are operational. -- Also note: sometimes race conditions will occur, but the -- condition should only be temporary.) -- -- (4) Data Link: -- An instance of OSI layer-2 procedures for exchanging information -- using either connection-oriented (e.g., LLC-2) or connectionless -- (e.g., LLC-1) services. A DLSw node or pair of partner nodes -- switches data traffic from stations of one data link to -- stations of another data link. Data link switching is -- transparent to end stations. -- Source: the end station which sends a message. -- Destination: the end station which receives a message. -- (This DLSw role is with respect to a give message) -- -- (5) Circuit: -- End-to-end association of two DLC entities through one or -- two DLSw nodes. A circuit is the concatenation of two Chen, et. al. Standards Track [Page 12] RFC 2024 DLSw MIB using SMIv2 October 1996 -- "data links", optionally with an intervening transport -- connection. -- Origin: the end station which initiates the circuit. -- Target: the end station which receives the initiation. -- -- (6) Link Station: -- It is one end of an LLC-2 connection. It performs error -- recovery procedure, retries, and various timers. -- DLSw terminates LLC-2 connection at each end of DLSw nodes, -- thus, keepAlive and error recovery on LLC-2 connections are -- kept to each side of LAN and do not flow through the WAN. -- A link station is substantiated when SABME is sent/received. -- All link stations have circuits, but not all circuits -- have link stations. -- -- Key assumptions are: -- (1) The MIB is designed to manage a single DLSw entity. -- -- (2) A DLSw may support various types of transport connections. -- - This DLSw MIB module does not restrict the possibility to -- have, at any given moment, more than one "transport -- connection" defined or active between two DLSw's. -- - However, current DLSw architecture does not provide a mechanism, -- e.g., DLSw host name, to prevent two transport connections of -- different types between the same two DLSw's. -- -- (3) This MIB assumes that interface MIB is implemented. ifIndex -- is used in this MIB module. -- -- (4) This MIB assumes that the SDLC MIB (or an equivalent enterprise -- specific MIB) is implemented, since SDLC-specific objects -- are not duplicated here. -- -- (5) This MIB assumes that the LLC-2 MIB (or an equivalent enterprise -- specific MIB) is implemented, since LLC-related objects are not -- duplicated here. -- -- (6) All MACs, SAPs, Ring numbers, ... are in non-canonical form. -- That is, the most significant bit will be transmitted first. -- -- ******************************************************************* DLSW-MIB DEFINITIONS ::= BEGIN IMPORTS DisplayString, RowStatus, RowPointer, TruthValue, TEXTUAL-CONVENTION FROM SNMPv2-TC Chen, et. al. Standards Track [Page 13] RFC 2024 DLSw MIB using SMIv2 October 1996 Counter32, Gauge32, TimeTicks, OBJECT-TYPE, MODULE-IDENTITY, NOTIFICATION-TYPE FROM SNMPv2-SMI MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF ifIndex FROM IF-MIB sdlcLSAddress FROM SNA-SDLC-MIB; dlsw MODULE-IDENTITY LAST-UPDATED "9606040900Z" ORGANIZATION "AIW DLSw MIB RIGLET and IETF DLSw MIB Working Group" CONTACT-INFO "David D. Chen IBM Corporation 800 Park, Highway 54 Research Triangle Park, NC 27709-9990 Tel: 1 919 254 6182 E-mail: dchen@vnet.ibm.com" DESCRIPTION "This MIB module contains objects to manage Data Link Switches." ::= { mib-2 46 } dlswMIB OBJECT IDENTIFIER ::= { dlsw 1 } dlswDomains OBJECT IDENTIFIER ::= { dlsw 2 } -- ******************************************************************* -- Textual convention definitions -- ******************************************************************* NBName ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Represents a single qualified NetBIOS name, which can include `don't care' and `wildcard' characters to represent a number of real NetBIOS names. If an individual character position in the qualified name contains a `?', the corresponding character position in a real NetBIOS name is a `don't care'. If the qualified name ends in `*', the remainder of a real NetBIOS name is a `don't care'. `*' is only considered a wildcard if it appears at the end of a name." SYNTAX OCTET STRING (SIZE (0..16)) MacAddressNC ::= TEXTUAL-CONVENTION DISPLAY-HINT "1x:" STATUS current DESCRIPTION "Represents an 802 MAC address represented in Chen, et. al. Standards Track [Page 14] RFC 2024 DLSw MIB using SMIv2 October 1996 non-canonical format. That is, the most significant bit will be transmitted first. If this information is not available, the value is a zero length string." SYNTAX OCTET STRING (SIZE (0 | 6)) TAddress ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Denotes a transport service address. For dlswTCPDomain, a TAddress is 4 octets long, containing the IP-address in network-byte order." SYNTAX OCTET STRING (SIZE (0..255)) EndStationLocation ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Representing the location of an end station related to the managed DLSw node." SYNTAX INTEGER { other (1), internal (2), -- local virtual MAC address remote (3), -- via DLSw partner local (4) -- locally attached } DlcType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Representing the type of DLC of an end station, if applicable." SYNTAX INTEGER { other (1), -- not assigned yet na (2), -- not applicable llc (3), -- 802.2 Logical Link Control sdlc (4), -- SDLC qllc (5) -- QLLC } LFSize ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The largest size of the INFO field (including DLC header, not including any MAC-level or framing octets). 64 valid values as defined by the IEEE 802.1D Addendum are acceptable." SYNTAX INTEGER { lfs516(516), lfs635(635), lfs754(754), lfs873(873), lfs993(993), lfs1112(1112), lfs1231(1231), Chen, et. al. Standards Track [Page 15] RFC 2024 DLSw MIB using SMIv2 October 1996 lfs1350(1350), lfs1470(1470), lfs1542(1542), lfs1615(1615), lfs1688(1688), lfs1761(1761), lfs1833(1833), lfs1906(1906), lfs1979(1979), lfs2052(2052), lfs2345(2345), lfs2638(2638), lfs2932(2932), lfs3225(3225), lfs3518(3518), lfs3812(3812), lfs4105(4105), lfs4399(4399), lfs4865(4865), lfs5331(5331), lfs5798(5798), lfs6264(6264), lfs6730(6730), lfs7197(7197), lfs7663(7663), lfs8130(8130), lfs8539(8539), lfs8949(8949), lfs9358(9358), lfs9768(9768), lfs10178(10178), lfs10587(10587), lfs10997(10997), lfs11407(11407), lfs12199(12199), lfs12992(12992), lfs13785(13785), lfs14578(14578), lfs15370(15370), lfs16163(16163), lfs16956(16956), lfs17749(17749), lfs20730(20730), lfs23711(23711), lfs26693(26693), lfs29674(29674), lfs32655(32655), lfs38618(38618), lfs41600(41600), lfs44591(44591), lfs47583(47583), lfs50575(50575), lfs53567(53567), lfs56559(56559), lfs59551(59551), lfs65535(65535) } null OBJECT IDENTIFIER ::= { 0 0 } -- ******************************************************************* -- DLSw Transport Domain definitions -- ******************************************************************* -- DLSw over TCP dlswTCPDomain OBJECT IDENTIFIER ::= { dlswDomains 1 } -- for an IP address of length 4: -- -- octets contents encoding -- 1-4 IP-address network-byte order -- DlswTCPAddress ::= TEXTUAL-CONVENTION DISPLAY-HINT "1d.1d.1d.1d" STATUS current DESCRIPTION "Represents the IP address of a DLSw which uses TCP as a transport protocol." SYNTAX OCTET STRING (SIZE (4)) -- ******************************************************************* -- DLSw MIB Definition -- ******************************************************************* Chen, et. al. Standards Track [Page 16] RFC 2024 DLSw MIB using SMIv2 October 1996 -- The DLSw MIB module contains an object part and a conformance part. -- Object part is organized in the following groups: -- (1) dlswNode -- information about this DLSw -- (2) dlswTConn -- about adjacent DLSw partners -- (3) dlswInterface -- about which interfaces DLSw is active on -- (4) dlswDirectory -- about any directory of local/remote resources -- (5) dlswCircuit -- about established circuits. -- (6) dlswSdlc -- about SDLC data link switched devices dlswNode OBJECT IDENTIFIER ::= { dlswMIB 1 } dlswTConn OBJECT IDENTIFIER ::= { dlswMIB 2 } dlswInterface OBJECT IDENTIFIER ::= { dlswMIB 3 } dlswDirectory OBJECT IDENTIFIER ::= { dlswMIB 4 } dlswCircuit OBJECT IDENTIFIER ::= { dlswMIB 5 } dlswSdlc OBJECT IDENTIFIER ::= { dlswMIB 6 } -- SDLC -- ******************************************************************* -- THE NODE GROUP -- ******************************************************************* -- ------------------------------------------------------------------- -- DLSw Node Identity -- ------------------------------------------------------------------- dlswNodeVersion OBJECT-TYPE SYNTAX OCTET STRING (SIZE (2)) MAX-ACCESS read-only STATUS current DESCRIPTION "This value identifies the particular version of the DLSw standard supported by this DLSw. The first octet is a hexadecimal value representing the DLSw standard Version number of this DLSw, and the second is a hexadecimal value representing the DLSw standard Release number. This information is reported in DLSw Capabilities Exchange." REFERENCE "DLSW: Switch-to-Switch Protocol RFC 1795" ::= { dlswNode 1 } dlswNodeVendorID OBJECT-TYPE SYNTAX OCTET STRING (SIZE (3)) MAX-ACCESS read-only STATUS current DESCRIPTION "The value identifies the manufacturer's IEEE-assigned organizationally Unique Identifier (OUI) of this DLSw. This information is reported in DLSw Capabilities Exchange." REFERENCE Chen, et. al. Standards Track [Page 17] RFC 2024 DLSw MIB using SMIv2 October 1996 "DLSW: Switch-to-Switch Protocol RFC 1795" ::= { dlswNode 2 } dlswNodeVersionString OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-only STATUS current DESCRIPTION "This string gives product-specific information about this DLSw (e.g., product name, code release and fix level). This flows in Capabilities Exchange messages." REFERENCE "DLSW: Switch-to-Switch Protocol RFC 1795" ::= { dlswNode 3 } -- ------------------------------------------------------------------- -- DLSw Code Capability -- ------------------------------------------------------------------- dlswNodeStdPacingSupport OBJECT-TYPE SYNTAX INTEGER { none (1), -- does not support DLSw -- Standard pacing scheme adaptiveRcvWindow (2), -- the receive window size -- varies fixedRcvWindow (3) -- the receive window size -- remains constant } MAX-ACCESS read-only STATUS current DESCRIPTION "Circuit pacing, as defined in the DLSw Standard, allows each of the two DLSw nodes on a circuit to control the amount of data the other is permitted to send to them. This object reflects the level of support the DLSw node has for this protocol. (1) means the node has no support for the standard circuit pacing flows; it may use RFC 1434+ methods only, or a proprietary flow control scheme. (2) means the node supports the standard scheme and can vary the window sizes it grants as a data receiver. (3) means the node supports the standard scheme but never varies its receive window size." ::= { dlswNode 4 } -- ------------------------------------------------------------------- -- DLSw Node Operational Objects -- ------------------------------------------------------------------- dlswNodeStatus OBJECT-TYPE SYNTAX INTEGER { active (1), Chen, et. al. Standards Track [Page 18] RFC 2024 DLSw MIB using SMIv2 October 1996 inactive (2) } MAX-ACCESS read-write STATUS current DESCRIPTION "The status of the DLSw part of the system. Changing the value from active to inactive causes DLSw to take the following actions - (1) it disconnects all circuits through all DLSw partners, (2) it disconnects all transport connections to all DLSw partners, (3) it disconnects all local DLC connections, and (4) it stops processing all DLC connection set-up traffic. Since these are destructive actions, the user should query the circuit and transport connection tables in advance to understand the effect this action will have. Changing the value from inactive to active causes DLSw to come up in its initial state, i.e., transport connections established and ready to bring up circuits." ::= { dlswNode 5 } dlswNodeUpTime OBJECT-TYPE SYNTAX TimeTicks UNITS "hundredths of a second" MAX-ACCESS read-only STATUS current DESCRIPTION "The amount of time (in hundredths of a second) since the DLSw portion of the system was last re-initialized. That is, if dlswState is in the active state, the time the dlswState entered the active state. It will remain zero if dlswState is in the inactive state." ::= { dlswNode 6 } dlswNodeVirtualSegmentLFSize OBJECT-TYPE SYNTAX LFSize MAX-ACCESS read-write STATUS current DESCRIPTION "The largest frame size (including DLC header and info field but not any MAC-level or framing octets) this DLSw can forward on any path through itself. This object can represent any box- level frame size forwarding restriction (e.g., from the use of fixed-size buffers). Some DLSw implementations will have no such restriction. This value will affect the LF size of circuits during circuit creation. The LF size of an existing circuit can be found in Chen, et. al. Standards Track [Page 19] RFC 2024 DLSw MIB using SMIv2 October 1996 the RIF (Routing Information Field)." DEFVAL { lfs65535 } ::= { dlswNode 7 } -- ................................................................... -- NETBIOS Resources -- ................................................................... dlswNodeResourceNBExclusivity OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "The value of true indicates that the NetBIOS Names configured in dlswDirNBTable are the only ones accessible via this DLSw. If a node supports sending run-time capabilities exchange messages, changes to this object should cause that action. It is up to the implementation exactly when to start the run-time capabilities exchange." ::= { dlswNode 8 } -- ................................................................... -- MAC Address List -- ................................................................... dlswNodeResourceMacExclusivity OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "The value of true indicates that the MAC addresses configured in the dlswDirMacTable are the only ones accessible via this DLSw. If a node supports sending run-time capabilities exchange messages, changes to this object should cause that action. It is up to the implementation exactly when to start the run-time capabilities exchange." ::= { dlswNode 9 } -- ******************************************************************* -- TRANSPORT CONNECTION (aka: PARTNER DLSW) -- ******************************************************************* -- ------------------------------------------------------------------- Chen, et. al. Standards Track [Page 20] RFC 2024 DLSw MIB using SMIv2 October 1996 -- Transport Connection Statistics Objects -- ------------------------------------------------------------------- dlswTConnStat OBJECT IDENTIFIER ::= { dlswTConn 1 } dlswTConnStatActiveConnections OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of transport connections that are not in `disconnected' state." ::= { dlswTConnStat 1 } dlswTConnStatCloseIdles OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times transport connections in this node exited the connected state with zero active circuits on the transport connection." ::= { dlswTConnStat 2 } dlswTConnStatCloseBusys OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times transport connections in this node exited the connected state with some non-zero number of active circuits on the transport connection. Normally this means the transport connection failed unexpectedly." ::= { dlswTConnStat 3 } -- ------------------------------------------------------------------- -- Transport Connection Configuration Table -- ------------------------------------------------------------------- dlswTConnConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF DlswTConnConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table defines the transport connections that will be initiated or accepted by this DLSw. Structure of masks allows wildcard definition for a collection of transport connections by a conceptual row. For a specific transport connection, there may Chen, et. al. Standards Track [Page 21] RFC 2024 DLSw MIB using SMIv2 October 1996 be multiple of conceptual rows match the transport address. The `best' match will the one to determine the characteristics of the transport connection." ::= { dlswTConn 2 } dlswTConnConfigEntry OBJECT-TYPE SYNTAX DlswTConnConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each conceptual row defines a collection of transport connections." INDEX { dlswTConnConfigIndex } ::= { dlswTConnConfigTable 1 } DlswTConnConfigEntry ::= SEQUENCE { dlswTConnConfigIndex INTEGER, dlswTConnConfigTDomain OBJECT IDENTIFIER, dlswTConnConfigLocalTAddr TAddress, dlswTConnConfigRemoteTAddr TAddress, dlswTConnConfigLastModifyTime TimeTicks, dlswTConnConfigEntryType INTEGER, dlswTConnConfigGroupDefinition RowPointer, dlswTConnConfigSetupType INTEGER, dlswTConnConfigSapList OCTET STRING, dlswTConnConfigAdvertiseMacNB TruthValue, dlswTConnConfigInitCirRecvWndw INTEGER, dlswTConnConfigOpens Counter32, dlswTConnConfigRowStatus RowStatus } dlswTConnConfigIndex OBJECT-TYPE SYNTAX INTEGER (0..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index to the conceptual row of the table. Negative numbers are not allowed. There are objects defined that point to conceptual rows of this table with this index value. Zero is used to denote that no corresponding row exists. Index values are assigned by the agent, and should not be reused but should continue to increase in value." ::= { dlswTConnConfigEntry 1 } Chen, et. al. Standards Track [Page 22] RFC 2024 DLSw MIB using SMIv2 October 1996 dlswTConnConfigTDomain OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current DESCRIPTION "The object identifier which indicates the transport domain of this conceptual row." ::= { dlswTConnConfigEntry 2 } dlswTConnConfigLocalTAddr OBJECT-TYPE SYNTAX TAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The local transport address for this conceptual row of the transport connection definition." ::= { dlswTConnConfigEntry 3 } dlswTConnConfigRemoteTAddr OBJECT-TYPE SYNTAX TAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The remote transport address. Together with dlswTConnConfigEntryType and dlswTConnConfigGroupDefinition, the object instance of this