rfc2024.txt

<VC++网络游戏建摸与实现>源代码

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.