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 (RFC1573) [8] . . . . . . . . . 2
2.2 Relation to Underlying DLC Layer . . . . . . . . . . . . . 3
2.3 Relation to SDLC MIB (RFC1747) . . . . . . . . . . . . . 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:
RFC1902 [2] which defines the SMI, the mechanisms used for
describing and naming objects for the purpose of management.
STD 17, RFC1213 [4] defines MIB-II, the core set of managed
objects for the Internet suite of protocols.
STD 15, RFC1157 [5] and RFC1905 [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 (RFC1573) [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 (RFC1747)
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 RFC1747 [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 RFC1747. 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'.
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
-- |
-- *******************************************************************
-- *******************************************************************
-- 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 RFC1795 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
-- "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
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
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),
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
-- *******************************************************************
-- 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 RFC1795"
::= { 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
"DLSW: Switch-to-Switch Protocol RFC1795"
::= { 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 RFC1795"
::= { 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 RFC1434+ 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),
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
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)
-- *******************************************************************
-- -------------------------------------------------------------------
-- 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
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 }
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 conceptual row identifies a
collection of the transport connections that will be
either initiated by this DLSw or initiated by a partner
DLSw and accepted by this DLSw."
::= { dlswTConnConfigEntry 4 }
dlswTConnConfigLastModifyTime OBJECT-TYPE
SYNTAX TimeTicks
UNITS "hundredths of a second"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The time (in hundredths of a second) since the value of
any object in this conceptual row except for
dlswTConnConfigOpens was last changed. This value
may be compared to dlswTConnOperConnectTime to
determine whether values in this row are completely
valid for a transport connection created using
this row definition."
::= { dlswTConnConfigEntry 5 }
dlswTConnConfigEntryType OBJECT-TYPE
SYNTAX INTEGER {
individual (1),
global (2),
group (3)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The object instance signifies the type of entry in the
associated conceptual row. The value of `individual'
means that the entry applies to a specific partner DLSw
node as identified by dlswTConnConfigRemoteTAddr and
dlswTConnConfigTDomain. The value of `global'
means that the entry applies to all partner DLSw nodes
of the TDomain. The value of 'group' means that the entry
applies to a specific set of DLSw nodes in the TDomain.
Any group definitions are enterprise-specific and are pointed
to by dlswTConnConfigGroupDefinition. In the cases of
`global' and `group', the value in dlswTConnConfigRemoteTAddr
may not have any significance."
::= { dlswTConnConfigEntry 6 }
dlswTConnConfigGroupDefinition OBJECT-TYPE
SYNTAX RowPointer
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"For conceptual rows of `individual' and `global' as
specified in dlswTConnConfigEntryType, the instance
of this object is `0.0'. For conceptual rows of
`group', the instance points to the specific
group definition."
::= { dlswTConnConfigEntry 7 }
dlswTConnConfigSetupType OBJECT-TYPE
SYNTAX INTEGER {
other (1),
activePersistent (2),
activeOnDemand (3),
passive (4),
excluded (5)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This value of the instance of a conceptual row
identifies the behavior of the collection of
transport connections that this conceptual row
defines. The value of activePersistent, activeOnDemand
and passive means this DLSw will accept any transport
connections, initiated by partner DLSw nodes, which
are defined by this conceptual row. The value of
activePersistent means this DLSw will also initiate
the transport connections of this conceptual row and
retry periodically if necessary. The value of
activeOnDemand means this DLSw will initiate a
transport connection of this conceptual row, if
there is a directory cache hits. The value of
other is implementation specific. The value of exclude
means that the specified node is not allowed to be
a partner to this DLSw node. To take a certain
conceptual row definition out of service, a value of
notInService for dlswTConnConfigRowStatus should be
used."
DEFVAL { passive }
::= { dlswTConnConfigEntry 8 }
dlswTConnConfigSapList OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(16))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The SAP list indicates which SAPs are advertised to
the transport connection defined by this conceptual
row. Only SAPs with even numbers are represented,
in the form of the most significant bit of the first
octet representing the SAP 0, the next most significant
bit representing the SAP 2, to the least significant
bit of the last octet representing the SAP 254. Data
link switching is allowed for those SAPs which have
one in its corresponding bit, not allowed otherwise.
The whole SAP list has to be changed together. Changing
the SAP list affects only new circuit establishments
and has no effect on established circuits.
This list can be used to restrict specific partners
from knowing about all the SAPs used by DLSw on all its
interfaces (these are represented in dlswIfSapList for
each interface). For instance, one may want to run NetBIOS
with some partners but not others.
If a node supports sending run-time capabilities exchange
messages, changes to this object should cause that action.
When to start the run-time capabilities exchange is
implementation-specific.
The DEFVAL below indicates support for SAPs 0, 4, 8, and C."
DEFVAL { 'AA000000000000000000000000000000'H }
::= { dlswTConnConfigEntry 9 }
dlswTConnConfigAdvertiseMacNB OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The value of true indicates that any defined local MAC
addresses and NetBIOS names will be advertised to a
partner node via initial and (if supported) run-time
capabilities exchange messages. The DLSw node should send
the appropriate exclusivity control vector to accompany
each list it sends, or to represent that the node is
explicitly configured to have a null list.
The value of false indicates that the DLSw node should not
send a MAC address list or NetBIOS name list, and should
also not send their corresponding exclusivity control
vectors."
DEFVAL { true }
::= { dlswTConnConfigEntry 10 }
dlswTConnConfigInitCirRecvWndw OBJECT-TYPE
SYNTAX INTEGER (0..65535)
UNITS "SSP messages"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The initial circuit receive pacing window size, in the unit
of SSP messages, to be used for future transport connections
activated using this table row. The managed node sends this
value as its initial receive pacing window in its initial