doc: Add RFC documents

1 files changed, 5099 insertions, 0 deletions

diff --git a/doc/rfc/rfc1795.txt b/doc/rfc/rfc1795.txt
new file mode 100644
index 0000000..9282d14
--- /dev/null
+++ b/doc/rfc/rfc1795.txt
@@ -0,0 +1,5099 @@
+
+
+
+
+
+
+Network Working Group                                    L. Wells, Chair
+Request for Comments: 1795             Internetwork Technology Institute
+Obsoletes: 1434                                        A. Bartky, Editor
+Category: Informational                              Sync Research, Inc.
+                                                              April 1995
+
+
+             Data Link Switching: Switch-to-Switch Protocol
+       AIW DLSw RIG: DLSw Closed Pages, DLSw Standard Version 1.0
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  This memo
+   does not specify an Internet standard of any kind.  Distribution of
+   this memo is unlimited.
+
+Abstract
+
+   This RFC describes use of Data Link Switching over TCP/IP. The RFC is
+   being distributed to members of the Internet community in order to
+   solicit their reactions to the proposals contained in it.  While the
+   issues discussed may not be directly relevant to the research
+   problems of the Internet, they may be interesting to a number of
+   researchers and Implementers.
+
+   This RFC was created as a joint effort of the Advanced Peer-to-Peer
+   Networking (APPN) Implementers Workshop (AIW) Data Link Switching
+   (DLSw) Related Interest Group (RIG).  The APPN Implementers Workshop
+   is a group sponsored by IBM and consists of representatives of member
+   companies implementing current and future IBM Networking
+   interoperable products. The DLSw Related Interest Group was formed in
+   this forum in order to produce a single version of the Switch to
+   Switch Protocol (SSP) which could be implemented by all vendors,
+   which would fix documentation problems with the existing RFC 1434,
+   and which would enhance and evolve the protocol to add new functions
+   and features.
+
+   This document is based on RFC 1434.  This document contains
+   significant changes to RFC 1434 and therefore obsoletes that
+   document.
+
+   Any questions or comments relative to the contents of this RFC should
+   be sent to the following Internet address:
+   aiw-dlsw@networking.raleigh.ibm.com.
+
+   NOTE 1: This is a widely subscribed mailing list and messages sent to
+   this address will be sent to all members of the DLSw mailing list.
+   For specific questions relating to subscribing to the AIW and any of
+
+
+
+Wells & Bartky                                                  [Page 1]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+   it's working groups send email to: appn@vnet.ibm.com
+
+   Information regarding all of the AIW working groups and the work they
+   are producing can be obtained by copying, via anonymous ftp, the file
+   aiwinfo.psbin or aiwinfo.txt from the Internet host
+   networking.raleigh.ibm.com, located in directory aiw.
+
+   NOTE 2:  These mailing lists and addresses are subject to change.
+
+1.  Introduction
+
+   Data Link Switching (DLSw) is a forwarding mechanism for the IBM SNA
+   (Systems Network Architecture) and IBM NetBIOS (Network Basic Input
+   Output Services) protocols.  This memo documents the Switch-to-Switch
+   Protocol (SSP) that is used between Data Link Switches.  This
+   protocol does not provide full routing, but instead provides
+   switching at the SNA Data Link layer (i.e., layer 2 in the SNA
+   architecture) and encapsulation in TCP/IP for transport over the
+   Internet.  This RFC documents the frame formats and protocols for
+   multiplexing data between Data Link Switches. The initial
+   implementation of SSP uses TCP as the reliable transport between Data
+   Link Switches.  However, other transport connections such as OSI TP4
+   could be used in the future.
+
+   A Data Link Switch (abbreviated also as DLSw in this document) can
+   support  SNA (Physical Unit (PU) 2, PU 2.1 and PU 4) systems and
+   optionally NetBIOS systems attached to IEEE 802.2 compliant Local
+   Area Networks, as well as SNA (PU 2 (primary or secondary) and PU2.1)
+   systems attached to IBM Synchronous Data Link Control (SDLC) links.
+   For the latter case, the SDLC attached systems are provided with a
+   LAN appearance within the Data Link Switch (each SDLC PU is presented
+   to the SSP protocol as a unique MAC/SAP address pair).  For the
+   Token-Ring LAN attached systems, the Data Link Switch appears as a
+   source-routing bridge.  Token-Ring Remote systems that are accessed
+   through the Data Link Switch appear as systems attached to an
+   adjacent ring.  This ring is a virtual ring that is manifested within
+   each Data Link Switch.
+
+1.1  Backwards Compatibility with RFC 1434
+
+   This document defines significant changes to RFC 1434 and does not
+   state details on how to interoperate with RFC 1434 or "enhanced"
+   implementations (e.g., those that added enter and exit busy flow
+   control).  It is up to the implementer to refer to RFC 1434 and/or
+   any other vendor's documentation in order to interoperate with a
+   given vendor's implementation, if interoperability with pre-AIW DLSw
+   RIG standards is desired.
+
+
+
+
+Wells & Bartky                                                  [Page 2]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+2.  Overview
+
+   Data Link Switching was developed to provide support for SNA and
+   NetBIOS in multi-protocol routers.  Since SNA and NetBIOS are
+   basically connection oriented protocols, the Data Link Control
+   procedure that they use on the LAN is IEEE 802.2 Logical Link Control
+   (LLC) Type 2.  Data Link Switching also accommodates SNA protocols
+   over WAN (Wide Area Network) links via the SDLC protocol.
+
+   IEEE 802.2 LLC Type 2 was designed with the assumption that the
+   network transit delay would be predictable (i.e., a local LAN).
+   Therefore the LLC Type 2 elements of procedure use a fixed timer for
+   detecting lost frames.  When remote bridging is used over wide area
+   lines (especially at lower speeds), the network delay is larger and
+   it can vary greatly based upon congestion.  When the delay exceeds
+   the time-out value LLC Type 2 attempts to retransmit.  If the frame
+   is not actually lost, only delayed, it is possible for the LLC Type 2
+   procedures to become confused.  And as a result, the link may be
+   eventually taken down if the delay exceeds the T1 timer times N2
+   retry count.
+
+   Given the use of LLC Type 2 services, Data Link Switching addresses
+   the following bridging problems:
+
+             DLC Time-outs
+             DLC Acknowledgments over the WAN
+             Flow and Congestion Control
+             Broadcast Control of Search Packets
+             Source-Route Bridging Hop Count Limits
+
+   NetBIOS also makes extensive use of datagram services that use
+   connectionless LLC Type 1 service.  In this case, Data Link Switching
+   addresses the last two problems in the above list.
+
+   The principal difference between Data Link Switching and bridging is
+   that for connection-oriented data DLSw terminates the Data Link Control
+   whereas bridging does not. The following figure illustrates this
+   difference based upon two end systems operating with LLC Type 2
+   services.
+
+
+
+
+
+
+
+
+
+
+
+
+Wells & Bartky                                                  [Page 3]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+   Bridging
+   --------
+
+                    Bridge           Bridge
+   +------+         +----+           +----+         +------+
+   | End  | +-----+ |    +-----/     |    | +-----+ | End  |
+   |System+-+ LAN +-+    |    /------+    +-+ LAN +-+System|
+   |      | +-----+ |    |  TCP/IP   |    | +-----+ |      |
+   +------+         +----+           +----+         +------+
+      Info----------------------------------------------->
+          <-----------------------------------------------RR
+
+
+   Data Link Switching
+   -------------------
+
+   +------+         +----+           +----+         +------+
+   | End  | +-----+ |    +-----/     |    | +-----+ | End  |
+   |System+-+ LAN +-+DLSw|    /------+DLSw+-+ LAN +-+System|
+   |      | +-----+ |    |  TCP/IP   |    | +-----+ |      |
+   +------+         +----+           +----+         +------+
+    Info--------------->   -------------> Info
+      <---------------RR                 ------------>
+                                         <------------RR
+
+   In traditional bridging, the Data Link Control is end-to-end.  Data
+   Link Switching terminates the LLC Type 2 connection at the switch.
+   This means that the LLC Type 2 connections do not cross the wide area
+   network.  The DLSw multiplexes LLC connections onto a TCP connection
+   to another DLSw.  Therefore, the LLC connections at each end are
+   totally independent of each other.  It is the responsibility of the
+   Data Link Switch to deliver frames that it has received from a LLC
+   connection to the other end.  TCP is used between the Data Link
+   Switches to guarantee delivery of frames.
+
+   As a result of this design, LLC time-outs are limited to the local
+   LAN (i.e., they do not traverse the wide area).  Also, the LLC Type 2
+   acknowledgments (RR's) do not traverse the WAN, thereby reducing
+   traffic across the wide area links.  For SDLC links, polling and poll
+   response occurs locally, not over the WAN.  Broadcast of search
+   frames is controlled by the Data Link Switches once the location of a
+   target system is discovered.  Finally, the switches can now apply
+   back pressure to the end systems to provide flow and congestion
+   control.
+
+   Only one copy of an Link Protocol Data Unit (LPDU) is sent between
+   Data Link Switches in SSP messages (XIDFRAME and INFOFRAME).  Retries
+   of the LPDU are absorbed by Data Link Switch that receives it.  The
+
+
+
+Wells & Bartky                                                  [Page 4]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+   Data Link Switch that transmits the LPDU received in an SSP message
+   to a local DLC, will perform retries in a manner appropriate for the
+   local DLC. This may involve running a reply timer and maintaining a
+   poll retry count.  The length of the timer and the number of retries
+   is an implementation choice based on user configuration parameters
+   and the DLC type.
+
+   Data Link Switching uses LAN addressing to set up connections between
+   SNA systems.  SDLC attached devices are defined with MAC and SAP
+   addresses to enable them to communicate with LAN attached devices.
+   For NetBIOS systems, Data Link Switching uses the NetBIOS name to
+   forward datagrams and to set up connections for NetBIOS sessions.
+   For LLC type 2 connection establishment, SNA systems send TEST (or in
+   some cases, XID) frames to the null (0x00) SAP.  NetBIOS systems have
+   an address resolution procedure, based upon the Name Query and Name
+   Recognized frames, that is used to establish an end-to-end circuit.
+
+   Since Data Link Switching may be implemented in multi-protocol
+   routers, there may be situations where both bridging and switching
+   are enabled. SNA frames can be identified by their link SAP.  Typical
+   SAP values for SNA are 0x04, 0x08, and 0x0C.  NetBIOS always uses a
+   link SAP value of 0xF0.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wells & Bartky                                                  [Page 5]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+3.  Transport Connection
+
+   Data Link Switches can be in used in pairs or by themselves.
+
+   A Single DLSw internally switches one data link to another without
+   using TCP (DLC(1) to DLC(2) in the figure below).  This RFC does not
+   go into details on how to implement this feature and it is not a
+   requirement to support this RFC.
+
+   A paired DLSw multiplexes data links over a reliable transport using
+   a Switch-to-Switch Protocol (SSP).
+
+   +-------------------------------------------+Switch-to-Switch
+   |              DLC Interfaces               | Protocol (SSP)
+   |+-----------+   DLC Request  +-----------+ |
+   ||   Data    |<---------------|           | |Send SSP Frame
+   ||   Link    | DLC Indication |           | |-------------->
+   || Control 1 |--------------->|           | |
+   |+-----------+                | Data Link | |
+   |+-----------+   DLC Request  |  Switch   | |
+   ||   Data    |<-------------- |           | |Rec. SSP Frame
+   ||   Link    | DLC Indication |           | |<-------------
+   || Control 2 | -------------->|           | |
+   |+-----------+                +-----------+ |
+   |            Multi-Protocol Router          |
+   +-------------------------------------------+
+
+   Before Data Link Switching can occur between two routers, they must
+   establish two TCP connections between them.  Each Data Link Switch
+   will maintain a list of DLSw capable routers and their status
+   (active/inactive).  After the TCP connection is established, SSP
+   messages are exchanged to establish the capabilities of the two Data
+   Link Switches.  Once the exchange is complete,  the DLSw will employ
+   SSP control messages to establish end-to-end circuits over the
+   transport connection.  Within the transport connection, DLSw SSP
+   messages are exchanged.  The message formats and types for these SSP
+   messages are documented in the following sections.
+
+   The default parameters associated with the TCP connections between
+   Data Link Switches are as follows:
+
+   Socket Family     AF_INET        (Internet protocols)
+   Socket Type       SOCK_STREAM    (stream socket)
+   Read Port Number  2065
+   Write Port Number 2067
+
+
+
+
+
+
+Wells & Bartky                                                  [Page 6]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+   Two or more Data Link Switches may be attached to the same LAN,
+   consisting of a number of token-ring segments interconnected by
+   source-routing bridges.  In this case, a TCP connection is not
+   defined between bridges attached to the same LAN.  This will allow
+   using systems to select one of the possible Data Link Switches in a
+   similar manner to the selection of a bridge path through a source-
+   routed bridged network.  The virtual ring segment in each Data Link
+   Switch attached to a common LAN must be configured with the same ring
+   number.  This will prevent LAN frames sent by one Data Link Switch
+   from being propagated through the other Data Link Switches.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wells & Bartky                                                  [Page 7]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+3.1  SSP Frame Formats
+
+   The following diagrams show the two message header formats exchanged
+   between Data Link Switches, Control and Information.  The Control
+   message header is used for all messages except Information Frames
+   (INFOFRAME) and Independent Flow Control Messages (IFCM), which are
+   sent in Information header format.  The INFOFRAME, KEEPALIVE and IFCM
+   message headers are 16 bytes long, and the control message header is
+   72 bytes long.  The fields in the first sixteen bytes of all message
+   headers are the same.
+
+    CONTROL MESSAGES (72 Bytes)
+    (zero based offsets below shown in decimal (xx) )
+   +-----------------------------+-----------------------------+
+   | (00) Version Number         | (01) Header Length (= 72)   |
+   +-----------------------------+-----------------------------+
+   | (02) Message Length                                       |
+   +-----------------------------+-----------------------------+
+   | (04) Remote Data Link Correlator                          |
+   +- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
+   |                                                           |
+   +-----------------------------+-----------------------------+
+   | (08) Remote DLC Port ID                                   |
+   +- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
+   |                                                           |
+   +-----------------------------+-----------------------------+
+   | (12) Reserved Field                                       |
+   +-----------------------------+-----------------------------+
+   | (14) Message Type           | (15) Flow Control Byte      |
+   +-----------------------------+-----------------------------+
+   | (16) Protocol ID            | (17) Header Number          |
+   +-----------------------------+-----------------------------+
+   | (18) Reserved                                             |
+   +-----------------------------+-----------------------------+
+   | (20) Largest Frame Size     | (21) SSP Flags              |
+   +-----------------------------+-----------------------------+
+   | (22) Circuit Priority       | (23) Message Type (see note)|
+   +-----------------------------+-----------------------------+
+   | (24) Target MAC Address  (non-canonical format)           |
+   +- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -|
+   |                                                           |
+   +- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
+   |                                                           |
+   +-----------------------------+-----------------------------+
+   | (30) Origin MAC Address  (non-canonical format)           |
+   +- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -|
+
+
+
+
+
+Wells & Bartky                                                  [Page 8]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+   |                                                           |
+   +- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
+   |            .                              .               |
+   +-----------------------------+-----------------------------+
+   | (36) Origin Link SAP        | (37) Target Link SAP        |
+   +-----------------------------+-----------------------------+
+   | (38) Frame Direction        | (39) Reserved               |
+   +-----------------------------+-----------------------------+
+   | (40) Reserved                                             |
+   +-----------------------------+-----------------------------+
+   | (42) DLC Header Length                                    |
+   +-----------------------------+-----------------------------+
+   | (44) Origin DLC Port ID                                   |
+   +- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
+   |                                                           |
+   +-----------------------------+-----------------------------+
+   | (48) Origin Data Link Correlator                          |
+   +- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
+   |                                                           |
+   +-----------------------------+-----------------------------+
+   | (52) Origin Transport ID                                  |
+   +- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
+   |                                                           |
+   +-----------------------------+-----------------------------+
+   | (56) Target DLC Port ID                                   |
+   +- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
+   |                                                           |
+   +-----------------------------+-----------------------------+
+   | (60) Target Data Link Correlator                          |
+   +- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
+   |                                                           |
+   +-----------------------------+-----------------------------+
+   | (64) Target Transport ID                                  |
+   +- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
+   |                                                           |
+   +-----------------------------+-----------------------------+
+   | (68) Reserved Field                                       |
+   +-----------------------------+-----------------------------+
+   | (70) Reserved Field                                       |
+   +-----------------------------+-----------------------------+
+            (Even Byte)                     (Odd Byte)
+
+
+
+
+
+
+
+
+
+
+Wells & Bartky                                                  [Page 9]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+    INFORMATION MESSAGE (16 Bytes)
+   +-----------------------------+-----------------------------+
+   | (00) Version Number         | (01) Header Length (= 16)   |
+   +-----------------------------+-----------------------------+
+   | (02) Message Length                                       |
+   +-----------------------------+-----------------------------+
+   | (04) Remote Data Link Correlator                          |
+   +- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
+   |                                                           |
+   +-----------------------------+-----------------------------+
+   | (08) Remote DLC Port ID                                   |
+   +- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
+   |                                                           |
+   +-----------------------------+-----------------------------+
+   | (12) Reserved Field                                       |
+   +-----------------------------+-----------------------------+
+   | (14) Message Type           | (15) Flow Control Byte      |
+   +-----------------------------+-----------------------------+
+            (Even Byte)                    (Odd Byte)
+
+   The first sixteen bytes of control and information message headers
+   contain identical fields.  A brief description of some of the fields
+   in an SSP message are shown below (if not defined below, the fields
+   and/or their values are described in subsequent sections).
+
+   The Version Number field (offset 0) is set to 0x31 (ASCII '1'),
+   indicating a decimal value of 49.  This is used to indicate DLSw
+   version 1.
+
+   The Header Length field (offset 1) is 0x48 for control messages,
+   indicating a decimal value of 72 bytes, and 0x10 for information and
+   Independent Flow Control messages, indicating a decimal value of 16
+   bytes.
+
+   The Message Length field (offset 2) defines the number of bytes
+   within the data field following the header.
+
+   The Flow Control Byte field (offset 15)  is described in section 8.
+
+   The Header Number field (offset 17) is 0x01, indicating a value of
+   one.
+
+   The Circuit Priority field (offset 22) is described in section 4.
+
+   The Frame Direction field (offset 38) is set to 0x01 for frames sent
+   from the origin DLSw to the target DLSw, and is set to 0x02 for
+   frames sent from the target DLSw to the origin DLSw.
+
+
+
+
+Wells & Bartky                                                 [Page 10]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+   Note:  The Remote Data Link Correlator and Remote DLC Port ID are set
+   equal to the Target Data Link Correlator and Target DLC Port ID if
+   the Frame Direction field is set to 0x01, and are set equal to the
+   Origin Data Link Correlator and Origin DLC Port ID if the Direction
+   Field is set to 0x02.
+
+   The Protocol ID field is set to 0x42, indicating a decimal value of
+   66.
+
+   The DLC Header Length is set to zero for SNA and is set to 0x23 for
+   NetBIOS datagrams, indicating a length of 35 bytes.  This includes
+   the Access Control (AC) field, the Frame Control (FC) field,
+   Destination MAC Address (DA), the Source MAC Address (SA), the
+   Routing Information (RI) field (padded to 18 bytes), the Destination
+   link SAP (DSAP), the Source link SAP (SSAP), and the LLC control
+   field (UI).
+
+   NOTE:  The values for the Message Type field are defined in section
+   3.5. Note that this value is specified in two different fields
+   (offset 14 and 23 decimal) of the control message header.  Only the
+   first field is to be used when parsing a received SSP message.  The
+   second field is to be ignored by new implementations on reception.
+   The second field was left in for backwards compatibility with RFC
+   1434 implementations and this field may be used in future versions if
+   needed.
+
+   The SSP Flags field contains additional information related to the
+   SSP message.  The flags are defined as follows (bit 7 being the most
+   significant bit and bit 0 the least significant bit of the octet):
+
+   Bit(s)
+   76543210    Name    Meaning
+   ---------   -----   -------
+   x.......    SSPex   1 = explorer message (CANUREACH and ICANREACH)
+
+   Reserved fields are set to zero upon transmission and should be
+   ignored upon receipt.
+
+3.2  Address Parameters
+
+   A data link is defined as a logical association between the two end
+   stations using Data Link Switching.  It is identified by a Data Link
+   ID (14 bytes) consisting of the pair of attachment addresses
+   associated with each end system.  Each attachment address is
+   represented by the concatenation of the MAC address (6 bytes) and the
+   LLC address (1 byte).  Each attachment address is classified as
+   either "Target" in the context of the Destination MAC/SAP addresses
+   of an explorer frame sent in the first frame used to establish a
+
+
+
+Wells & Bartky                                                 [Page 11]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+   circuit, or "Origin" in the context of the Source MAC/SAP addresses.
+   All MAC addresses are expressed in non-canonical (Token-Ring) format.
+
+    DATA LINK ID  (14 Bytes @ Control message offset 24 decimal)
+   +-----------------------------+-----------------------------+
+   | Target MAC Address                                        |
+   +- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
+   |                                                           |
+   +- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
+   |                                                           |
+   +-----------------------------+-----------------------------+
+   | Origin MAC Address                                        |
+   +- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
+   |                                                           |
+   +- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
+   |                                                           |
+   +-----------------------------+-----------------------------+
+   | Origin Link SAP             | Target Link SAP             |
+   +-----------------------------+-----------------------------+
+
+
+   An end-to-end circuit is identified by a pair of Circuit ID's.  A
+   Circuit ID is a 64 bit number that identifies the DLC circuit within
+   a single DLSw.  It consists of a DLC Port ID (4 bytes), and a Data
+   Link Correlator (4 bytes).  The Circuit ID must be unique in a single
+   DLSw and is assigned locally.  The pair of Circuit ID's along with
+   the Data Link IDs,  uniquely identify a single end-to-end circuit.
+   Each DLSw must keep a table of these Circuit ID pairs, one for the
+   local end of the circuit and the other for the remote end of the
+   circuit.  In order to identify which Data Link Switch originated the
+   establishment of a circuit, the terms, "Origin" DLSw and "Target"
+   DLSw, will be employed in this document.
+
+    CIRCUIT ID   (8 Bytes)
+   +-----------------------------+-----------------------------+
+   | DLC Port ID                                               |
+   +- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
+   |                                                           |
+   +-----------------------------+-----------------------------+
+   | Data Link Correlator                                      |
+   +- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
+   |                                                           |
+   +-----------------------------+-----------------------------+
+
+   The Origin Transport ID and the Target Transport ID fields in the
+   message header are used to identify the individual TCP/IP port on a
+   Data Link Switch.  The values have only local significance.  However,
+   each Data Link Switch is required to reflect the values contained in
+
+
+
+Wells & Bartky                                                 [Page 12]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+   these two fields, along with the associated values for DLC Port ID
+   and the Data Link Correlator, when returning a message to the other
+   Data Link Switch.
+
+   The following figure shows the use of the addressing parameters
+   during the establishment of an end-to-end connection.  The CANUREACH,
+   ICANREACH, and REACH_ACK message types all carry the Data Link ID,
+   consisting of the MAC and Link SAP addresses associated with the two
+   end stations.  The CANUREACH and ICANREACH messages are qualified by
+   the SSPex flag into CANUREACH_ex, ICANREACH_ex (explorer messages)
+   and CANUREACH_cs, ICANREACH_cs (circuit start).  The CANUREACH_ex is
+   used to find a remote MAC and Link SAP address without establishing
+   an SSP circuit.  Upon receipt of a CANUREACH_cs message, the target
+   DLSw starts a data link for each port, thereby obtaining a Data Link
+   Correlator.  If the target station can be reached, an ICANREACH_cs
+   message is returned to the origin DLSw containing the Target Circuit
+   ID parameter.  Upon receipt, the origin DLSw starts a data link and
+   returns the Origin Circuit ID to the target DLSw within the REACH_ACK
+   message.  (Note for a full list of message types, see section 3.5.)
+
+   +------------+                                +------------+
+   |Disconnected|                                |Disconnected|
+   +------------+   CANUREACH_cs (Data Link ID)  +------------+
+       ------------------------------------------------->
+         ICANREACH_cs (Data Link ID, Target Circuit ID)
+       <------------------------------------------------
+     REACH_ACK (Data Link ID, Origin Cir ID, Target Cir ID)
+       ------------------------------------------------->
+   +------------+                                +------------+
+   |Circuit Est.|                                |Circuit Est.|
+   +------------+                                +------------+
+     XIDFRAME (Data Link ID, Origin Cir ID, Target Cir ID)
+       <------------------------------------------------>
+      CONTACT (Data Link ID, Origin Cir ID, Target Cir ID)
+       ------------------------------------------------->
+     CONTACTED (Data Link ID, Origin Cir ID, Target Cir ID)
+       <-------------------------------------------------
+   +------------+                                +------------+
+   | Connected  |                                | Connected  |
+   +------------+                                +------------+
+        INFOFRAME (Remote Circuit ID = Target Circuit ID)
+       ------------------------------------------------->
+        INFOFRAME (Remote Circuit ID = Origin Circuit ID)
+       <-------------------------------------------------
+
+   During the exchange of the XIDFRAME, CONTACT, and CONTACTED messages,
+   the pair of Circuit ID parameters is included in the message format
+   along with the DATA LINK ID parameter.  Once the connection has been
+
+
+
+Wells & Bartky                                                 [Page 13]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+   established, the INFOFRAME messages are exchanged with the shorter
+   header.  This header contains only the Circuit ID associated with the
+   remote DLSw.  The Remote Data Link Correlator and the Remote DLC Port
+   ID are set equal to the Data Link Correlator and the DLC Port ID that
+   are associated with the origin or target Data Link Switch, dependent
+   upon the direction of the packet.
+
+3.3  Correlators
+
+   The local use, and contents of the Data Link Correlator, Port ID and
+   Transport ID fields in SSP messages is an implementation choice.
+   These fields have local significance only.  The values received from
+   a partner DLSw must not be interpreted by the DLSw that receives them
+   and should be echoed "as is" to a partner DLSw in subsequent
+   messages.  All implementations must obey the following rules in this
+   section (3.3) on the assignment and fixing of these correlator fields
+   for each transport connection or circuit:
+
+   The Transport ID fields are learned from the first SSP message
+   exchanged with a DLSw partner (the Capabilities exchange).  This
+   field should not be varied by a DLSw after the capabilities exchange
+   and must be reflected to the partner DLSw in every SSP control
+   message.
+
+   The Target Data Link Correlator, Target Port ID and Target Transport
+   ID must remain the same once the Target DLSw has sent the
+   ICANREACH_cs for a given circuit.  The Origin DLSw must store the
+   values specified in the ICANREACH_cs and use these on all subsequent
+   SSP messages for this circuit.
+
+   The Origin DLSw must allow these fields to vary until the
+   ICANREACH_cs is received.  Each SSP message issued for a circuit must
+   reflect the values specified by the Target DLSw in the last SSP
+   message for this circuit received by the Origin DLSw.  Binary zero
+   should be used if no such message has yet been received for a given
+   circuit (apart from the Target Transport ID which will have been
+   learnt as specified above).
+
+   The Origin Data Link Correlator, Origin Port ID and Origin Transport
+   ID must remain the same once the Origin DLSw has issued the REACH_ACK
+   for a given circuit.  The Target DLSw must store the values specified
+   in the REACH_ACK and use these on all subsequent SSP messages for
+   this circuit.
+
+   The Target DLSw must allow these fields to vary until the REACH_ACK
+   is received.  Each SSP message issued for a circuit must reflect the
+   values specified by the Origin DLSw in the last SSP message for this
+   circuit received by the Target DLSw.  Binary zero should be used if
+
+
+
+Wells & Bartky                                                 [Page 14]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+   no such message has yet been received for a given circuit (apart from
+   the Origin Transport ID which will have been learnt as specified
+   above).
+
+   For the purposes of correlator exchange, explorer messages form a
+   separate circuit.  Both DLSw partners must reflect the last received
+   correlator values as specified above.  However correlators learned on
+   explorer messages need not be carried over to a subsequent circuit
+   setup attempt.  In particular, the Origin DLSw may elect to use the
+   same values for the Origin Data Link Correlator and Origin Port ID
+   when it issues a CANUREACH_cs after receiving an ICANREACH_ex or
+   NETBIOS_NR_ex. However the Target DLSw must not assume that the
+   CANUREACH_cs will specify any of the Target Data Link Correlator or
+   Target Port ID that were exchanged on the explorer messages.
+
+   Received SSP messages that require a valid Remote Circuit ID but
+   cannot be associated with an existing circuit should be rejected with
+   a HALT_DL_NOACK message.  This is done to prevent a situation where
+   one DLSw partner has a circuit defined while the other partner does
+   not. The exception would be a HALT_DL_NOACK message with an invalid
+   Remote Circuit ID.  The HALT_DL_NOACK message is typically used in
+   error situations where a response is not appropriate.
+
+   The SSP messages requiring a valid Remote Circuit ID are all messages
+   except the following: CANUREACH_ex, CANUREACH_cs, ICANREACH_ex,
+   ICANREACH_cs, NETBIOS_NQ_cs, NETBIOS_NR_cs, DATAFRAME, NETBIOS_ANQ,
+   NETBIOS_ANR, KEEPALIVE and CAP_EXCHANGE.
+
+3.4  Largest Frame Size Field
+
+   The Largest Frame Size (LF Size) field in the SSP Control Header is
+   used to carry the LF Size bits across the DLSw connection.  This
+   should be used to ensure that the two end-stations always negotiate a
+   frame size to be used on a circuit that does not require the Origin
+   and Target DLSw partners to re-segment frames.
+
+   This field is valid on CANUREACH_ex, CANUREACH_cs, ICANREACH_ex,
+   ICANREACH_cs, NETBIOS_NQ_ex and NETBIOS_NR_ex messages only. The
+   contents of this field should be ignored on all other frames.
+
+   Every DLSw forwarding a SSP frame to its DLSw partner must ensure
+   that the contents of this frame reflect the minimum capability of the
+   route to its local end-station or any limit imposed by the DLSw
+   itself.
+
+   The bit-wise definition of this field is as follows (bit 7 is the
+   most significant bit, bit 0 is the least significant bit):
+
+
+
+
+Wells & Bartky                                                 [Page 15]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+     7   6   5   4   3   2   1   0
+   +-------------------------------+
+   | c | r | b | b | b | e | e | e |
+   +-------------------------------+
+
+     c   .   .   .   .   .   .   .  LF Size Control flag
+                                    (significant on messages
+                                    from Origin to Target
+                                    DLSw only)
+
+                                    0=fail circuit if route
+                                      obtained requires a
+                                      smaller LF size
+                                    1=don't fail the circuit
+                                      but return the LF size
+                                      obtained even if it is
+                                      smaller
+
+     .   r   .   .   .   .   .   .  Reserved
+     .   .   b   .   .   .   .   .  Largest Frame Bit Base
+     .   .   .   b   .   .   .   .  Largest Frame Bit Base
+     .   .   .   .   b   .   .   .  Largest Frame Bit Base
+     .   .   .   .   .   e   .   .  Largest Frame Bit Extended
+     .   .   .   .   .   .   e   .  Largest Frame Bit Extended
+     .   .   .   .   .   .   .   e  Largest Frame Bit Extended
+
+             <----- LF Bits ----->
+
+   Refer to IEEE 802.1D Standard, Annex C for encoding of Largest Frame
+   base and extended bit values.
+
+   The Origin DLSw "Size Control" flag informs a Target DLSw that
+   chooses to reply to *_cs messages on the basis of cached information
+   that it may safely return a smaller LF Size on the ICANREACH_cs frame
+   if it has had to choose an alternative route on which to initialize
+   the circuit.  If this bit is set to 1, the Origin DLSw takes
+   responsibility for ensuring that the end-stations negotiate a
+   suitable frame size for the circuit. If this bit is set to 0, the
+   Target DLSw must not reply to the CANUREACH_cs if it cannot obtain a
+   route to the Target end station that support an LF Size at least as
+   large as that specified in the CANUREACH_cs frame.
+
+3.5  Message Types
+
+   The following table lists the protocol data units that are exchanged
+   between Data Link Switches.  All values not listed are reserved for
+   potential use in follow-on releases.
+
+
+
+
+Wells & Bartky                                                 [Page 16]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+   Command          Description                       Type   flags/notes
+   -------          --------                         ------  -----------
+   CANUREACH_ex     Can U Reach Station-explorer      0x03   SSPex
+   CANUREACH_cs     Can U Reach Station-circuit start 0x03
+   ICANREACH_ex     I Can Reach Station-explorer      0x04   SSPex
+   ICANREACH_cs     I Can Reach Station-circuit start 0x04
+   REACH_ACK        Reach Acknowledgment              0x05
+   DGRMFRAME        Datagram Frame                    0x06   (note 1)
+   XIDFRAME         XID Frame                         0x07
+   CONTACT          Contact Remote Station            0x08
+   CONTACTED        Remote Station Contacted          0x09
+   RESTART_DL       Restart Data Link                 0x10
+   DL_RESTARTED     Data Link Restarted               0x11
+   ENTER_BUSY       Enter Busy                        0x0C   (note 2)
+   EXIT_BUSY        Exit Busy                         0x0D   (note 2)
+   INFOFRAME        Information (I) Frame             0x0A
+   HALT_DL          Halt Data Link                    0x0E
+   DL_HALTED        Data Link Halted                  0x0F
+   NETBIOS_NQ_ex    NETBIOS Name Query-explorer       0x12   SSPex
+   NETBIOS_NQ_cs    NETBIOS Name Query-circuit setup  0x12   (note 3)
+   NETBIOS_NR_ex    NETBIOS Name Recognized-explorer  0x13   SSPex
+   NETBIOS_NR_cs    NETBIOS Name Recog-circuit setup  0x13   (note 3)
+   DATAFRAME        Data Frame                        0x14   (note 1)
+   HALT_DL_NOACK    Halt Data Link with no Ack        0x19
+   NETBIOS_ANQ      NETBIOS Add Name Query            0x1A
+   NETBIOS_ANR      NETBIOS Add Name Response         0x1B
+   KEEPALIVE        Transport Keepalive Message       0x1D   (note 4)
+   CAP_EXCHANGE     Capabilities Exchange             0x20
+   IFCM             Independent Flow Control Message  0x21
+   TEST_CIRCUIT_REQ Test Circuit Request              0x7A
+   TEST_CIRCUIT_RSP Test Circuit Response             0x7B
+
+   Note 1: Both the DGRMFRAME and DATAFRAME messages are used to carry
+   information received by the DLC entity within UI frames.  The
+   DGRMFRAME message is addressed according to a pair of Circuit IDs,
+   while the DATAFRAME message is addressed according to a Data Link ID,
+   being composed of a pair of MAC addresses and a pair of link SAP
+   addresses. The latter is employed prior to the establishment of an
+   end-to-end circuit when Circuit IDs have yet to be established or
+   during circuit restart when Data Links are reset.
+
+   Note 2: These messages are not used for the DLSw Standard but may be
+   used by older DLSw implementations.  They are listed here for
+   informational purposes.  These messages were added after publication
+   of RFC 1434 and were deleted in this standard (adaptive pacing is now
+   used instead).
+
+
+
+
+
+Wells & Bartky                                                 [Page 17]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+   Note 3: These messages are not normally issued by a Standard DLSw,
+   which uses the NB_*_ex messages as shown in section 5.4.  However if
+   a Standard DLSw attempts to interoperate with older DLSw
+   implementations, these messages correspond to the NETBIOS_NQ and
+   NETBIOS_NR messages used in RFC1434 both to locate the resource and
+   to setup a circuit.  This document does not attempt to provide a
+   complete specification of the use of these messages.
+
+   Note 4:  A KEEPALIVE message may be sent by a DLSw to a partner DLSw
+   in order to verify the TCP connection (or other future SSP carrying
+   protocol) is still functioning.  If received by a DLSw, this message
+   is discarded and ignored.  Use of this message is optional.
+
+   For the exchange of NetBIOS control messages, the entire DLC header
+   is carried as part of the message unit.  This includes the MAC
+   header, with the routing information field padded to 18 bytes, and
+   the LLC header. The following message types are affected:
+   NETBIOS_NQ, NETBIOS_NR, NETBIOS_ANQ, NETBIOS_ANR, and DATAFRAME when
+   being used by NetBIOS systems.  The routing information in the DLC
+   header is not used by the remote Data Link Switch upon receiving the
+   above five messages.
+
+   Any SSP message types not defined above if received by a DLSw are to
+   be ignored (i.e., no error action is to be performed).  A Data Link
+   Switch should quietly drop any SSP message with a Message Type that
+   is not recognized or not supported.  Receipt of such a message should
+   not cause the termination of the transport connection to the message
+   sender.
+
+4.  Circuit Priority
+
+   At circuit start time, each circuit end point will provide priority
+   information to its circuit partner.  The initiator of the circuit
+   will choose which circuit priority will be effective for the life of
+   the circuit.  If Priority is not implemented by the Data Link Switch,
+   then "Unsupported" priority is used.
+
+4.1  Frame format
+
+   Circuit priority will be valid in the CANUREACH_cs, ICANREACH_cs, and
+   REACH_ACK frames only. The relevant header field is shown below.  The
+   Circuit Priority value is a byte value at offset 22 in an SSP Control
+   Message.
+
+
+
+
+
+
+
+
+Wells & Bartky                                                 [Page 18]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+   The following describes the format of the Circuit Priority byte.
+
+     7   6   5   4   3   2   1   0
+   +-------------------+-----------+
+   |   reserved        |    CP     |
+   +-------------------+-----------+
+
+   CP: Circuit Priority bits
+           000 - Unsupported       (note 1)
+           001 - Low Priority
+           010 - Medium Priority
+           011 - High Priority
+           100 - Highest Priority
+           101 to 111 are reserved for future use
+
+   Note 1: Unsupported means that the Data Link Switch that originates
+   the circuit does not implement priority.  Actions taken on
+   Unsupported priority are vendor specific.
+
+4.2  Circuit Startup
+
+   The sender of a CANUREACH_cs is responsible for setting the CP bits
+   to reflect the priority it would like to use for the circuit being
+   requested.  The mechanism for choosing an appropriate value is
+   implementation dependent.  The sender of an ICANREACH_cs frame will
+   set the CP bits to reflect the priority it would like to use for the
+   circuit being requested, with the mechanism for choosing the
+   appropriate value being implementation dependent.  The receiver of
+   the ICANREACH_cs will select from the priorities in the CANUREACH_cs
+   and ICANREACH_cs frames, and will set the value in the CP field of
+   the REACH_ACK frame that follows to the value to be used for this
+   circuit.  This priority will be used for the life of the circuit.  A
+   CANUREACH_cs or ICANREACH_cs with the circuit priority value set to
+   Unsupported (CP=000) indicates that the sender does not support the
+   circuit priority function.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wells & Bartky                                                 [Page 19]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+   Flow:
+
+      DLSw A               DLSw B
+
+   CANUREACH_cs (CP=011) ----->           Circuit initiator requests
+                                          high Priority.
+
+        <--------- ICANREACH_cs (CP=010)  Circuit target requests
+                                          medium priority.
+
+   REACH_ACK (CP=010) -------->           Circuit initiator sets
+                                          the priority for this
+                                          circuit to medium. The
+                                          circuit initiator could
+                                          choose either high or
+                                          medium in this example.
+
+5.  DLSw State Machine
+
+   The following state tables describe the states for a single circuit
+   through the Data Link Switch.  State information is kept for each
+   connection.  The initial state for a connection is DISCONNECTED.  The
+   steady state is either CIRCUIT_ESTABLISHED or CONNECTED.  In the former
+   state, an end-to-end circuit has been established allowing the support
+   of Type 1 LLC between the end systems.  The latter state exists when an
+   end-to-end connection has been established for the support of Type 2 LLC
+   services between the end systems.
+
+   For SNA, LLC type 2 connection establishment is via the use of IEEE
+   802.2 Test or XID  frames.  SNA devices send these frames to the null
+   SAP in order to determine the source route information in support of
+   bridging.  Normally SNA devices use SAP 0x04, 0x08, or 0x0C  (most SNA
+   LLC2 devices that have a single PU per MAC address use a default of
+   0x04).  Typically the SAP would be used to determine if the Test frames
+   should be sent to the DLSw code in the router.  If both bridging and
+   DLSw are enabled, this allows the product to ensure that SNA frames are
+   not both bridged and switched.  Note that although typically SNA uses a
+   DSAP and SSAP of 0x04, it allows for other SAPs to be configured and
+   supports unequal SAPs.  This allows multiple PUs to share connections
+   between two given MAC addresses (each PU to PU session uses one LLC2
+   connection).
+
+   For NetBIOS, LLC type 2 connection establishment is via the Name Query
+   and Name Recognized frames.  These frames are used for both address
+   resolution and source route determination.  NetBIOS devices use SAP
+   0xF0.
+
+
+
+
+
+Wells & Bartky                                                 [Page 20]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+5.1  Data Link Switch States
+
+   The Switch-to-Switch Protocol is formally defined through the state
+   machines described in this chapter.  The following table lists the
+   thirteen possible states for the main circuit FSM.  A separate state
+   machine instance is employed for each end-to-end circuit that is
+   maintained by the Data Link Switch.
+
+   State Name            Description
+   ----------            -----------
+   CIRCUIT_ESTABLISHED   The end-to-end circuit has been
+                         established.  At this time LLC Type 1
+                         services are available from end-to-end.
+
+   CIRCUIT_PENDING       The target DLSw is awaiting a REACH_ACK
+                         response to an ICANREACH_cs message.
+
+   CIRCUIT_RESTART       The DLSw that originated the reset is
+                         awaiting the restart of the data link
+                         and the DL_RESTARTED response to a
+                         RESTART_DL message.
+
+   CIRCUIT_START         The origin DLSw is awaiting a
+                         ICANREACH_cs in response to a
+                         CANUREACH_cs message.
+
+   CONNECTED             The end-to-end connection has
+                         been established thereby allowing
+                         LLC Type 2 services from end-to-end
+                         in addition to LLC Type 1 services.
+
+   CONNECT_PENDING       The origin DLSw is awaiting the
+                         CONTACTED response to a CONTACT
+                         message.
+
+   CONTACT_PENDING       The target DLSw is awaiting the
+                         DLC_CONTACTED confirmation to a
+                         DLC_CONTACT signal (i.e., DLC
+                         is waiting for a UA response to
+                         an SABME command).
+
+   DISCONNECTED          The initial state with no circuit
+                         or connection established, the
+                         DLSw is awaiting either a
+                         CANUREACH_cs, or an ICANREACH_cs.
+
+   DISCONNECT_PENDING    The DLSw that originated the
+                         disconnect is awaiting the DL_HALTED
+
+
+
+Wells & Bartky                                                 [Page 21]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+                         response to a HALT_DL message.
+
+   HALT_PENDING          The remote DLSw is awaiting the
+                         DLC_DL_HALTED indication following
+                         the DLC_HALT_DL request (i.e., DLC
+                         is waiting for a UA response to a
+                         DISC command), due to receiving a
+                         HALT_DL message.
+
+   HALT_PENDING_NOACK    The remote DLSw is awaiting the
+                         DLC_DL_HALTED indication following
+                         the DLC_HALT_DL request (i.e., DLC
+                         is waiting for a UA response to a
+                         DISC command), due to receiving a
+                         HALT_DL_NOACK message.
+
+   RESTART_PENDING       The remote DLSw is awaiting the
+                         DLC_DL_HALTED indication following
+                         the DLC_HALT_DL request (i.e., DLC
+                         is waiting for a UA response to a
+                         DISC command), and the restart of
+                         the data link.
+
+   RESOLVE_PENDING       The target DLSw is awaiting
+                         the DLC_DL_STARTED indication
+                         following the DLC_START_DL request
+                         (i.e., DLC is waiting for a Test
+                         response as a result of sending a
+                         Test command).
+
+   The DISCONNECTED state is the initial state for a new circuit.  One
+   end station starts the connection via an XID or SABME command (i.e.,
+   DLC_XID or DLC_CONTACTED).  Upon receipt, the Data Link Switches
+   exchange a set of CANUREACH_cs, ICANREACH_cs and REACH_ACK messages.
+   Upon completion of this three-legged exchange both Data Link Switches
+   will be in the CIRCUIT_ESTABLISHED state.  Three pending states also
+   exist during this exchange.  The CIRCUIT_START state is entered by
+   the origin Data Link Switch after it has sent the CANUREACH_cs
+   message.  The RESOLVE_PENDING state is entered by the target Data
+   Link Switch awaiting a Test response to a Test Command.  And lastly,
+   the CIRCUIT_PENDING state is entered by the target DLSw awaiting the
+   REACH_ACK reply to an ICANREACH_cs message.
+
+   The CIRCUIT_ESTABLISHED state allows for the exchange of LLC Type 1
+   frames such as the XID exchanges between SNA stations that occurs
+   prior to the establishment of a connection.  Also, datagram traffic
+   (i.e., UI frames)  may be sent and received between the end stations.
+   These exchanges use the XIDFRAME and DGRMFRAME messages sent between
+
+
+
+Wells & Bartky                                                 [Page 22]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+   the Data Link Switches.
+
+   In the CIRCUIT_ESTABLISHED state, the receipt of a SABME command
+   (i.e., DLC_CONTACTED) causes the origin DLSw to issue a CONTACT
+   message, to send an RNR supervisory frame (i.e., DLC_ENTER_BUSY) to
+   the origin station, and to enter the CONNECT_PENDING state awaiting a
+   CONTACTED message.  The target DLSw, upon the receipt of a CONTACT
+   message, will issue a SABME command (i.e., DLC_CONTACT) and enter the
+   Contact Pending state.  Once the UA response is received (i.e.,
+   DLC_CONTACTED), the target DLSw sends a CONTACTED message and enters
+   the CONNECTED state. When received, the origin DLSw enters the
+   CONNECTED state and sends an RR supervisory frame (i.e.,
+   DLC_EXIT_BUSY).
+
+   The CONNECTED state is the steady state for normal data flow once a
+   connection has been established.  Information frames (i.e., INFOFRAME
+   messages) are simply sent back and forth between the end points of
+   the connection.  This is the path that should be optimized for
+   performance.
+
+   The connection is terminated upon the receipt of a DISC frame or
+   under some other error condition detected by DLC (i.e., DLC_ERROR).
+   Upon receipt of this indication, the DLSw will halt the local data
+   link, send a HALT_DL message to the remote DLSw, and enter the
+   DISCONNECT_PENDING State.  When the HALT_DL frame is received by the
+   other DLSw, the local DLC is halted for this data link, a DL_HALTED
+   message is returned, and the DISCONNECTED state is entered.  Receipt
+   of this DL_HALTED message causes the other DLSw to also enter the
+   DISCONNECTED state.
+
+   The CIRCUIT_RESTART state is entered if one of the Data Link Switches
+   receives a SABME command  (i.e., DLC_RESET) after data transfer while
+   in the CONNECTED state.  This causes a DM command to be returned to
+   the origin station and a RESTART_DL message to be sent to the remote
+   Data Link Switch. This causes the remote data link to be halted and
+   then restarted.  The remote DLSw will then send a DL_RESTARTED
+   message back to the first DLSw.  The receipt of the DL_RESTARTED
+   message causes the first DLSw to issue a new CONTACT message,
+   assuming that the local DLC has been contacted (i.e., the origin
+   station has resent the SABME command).  This is eventually responded
+   to by a CONTACTED message. Following this exchange, both Data Link
+   Switches will return to the CONNECTED state.  If the local DLC has
+   not been contacted, the receipt of a DL_RESTARTED command causes the
+   Data Link Switch to enter the CIRCUIT_ESTABLISHED state awaiting the
+   receipt of a SABME command (i.e., DLC_CONTACTED signal).
+
+   The HALT_PENDING, HALT_PENDING_NOACK and RESTART_PENDING states
+   correspond to the cases when the Data Link Switch is awaiting
+
+
+
+Wells & Bartky                                                 [Page 23]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+   responses from the local station on the adjacent LAN (e.g., a UA
+   response to a DISC command). Also in the RESTART_PENDING state, the
+   Data Link Switch will attempt to restart the data link prior to
+   sending a DL_RESTARTED message.  For some implementations, the start
+   of a data link involves the exchange of a Test command/response on
+   the adjacent LAN (i.e., DLC_START_DL).  For other implementations,
+   this additional exchange may not be required.
+
+5.2  State Transition Tables
+
+   This section provides a detailed representation of the Data Link
+   Switch, as documented by a single state machine.  Many of the
+   transitions are dependent upon local signals between the Data Link
+   Switch entity and one of the DLC entities.  These signals and their
+   definitions are given in the following tables.
+
+   DLC Events:
+
+   Event Name      Description
+   ----------      -----------
+   DLC_CONTACTED   Contact Indication:  DLC has received an SABME
+                   command or DLC has received a UA response as a
+                   result of sending an SABME command.
+
+   DLC_DGRM        Datagram Indication:  DLC has received a UI frame.
+
+   DLC_ERROR       Error condition indicated by DLC:  Such a
+                   condition occurs when a DISC command is received
+                   or when DLC experiences an unrecoverable error.
+
+   DLC_INFO        Information Indication:  DLC has received an
+                   Information (I) frame.
+
+   DLC_DL_HALTED   Data Link Halted Indication:  DLC has
+                   received a UA response to a DISC command.
+
+   DLC_DL_STARTED  Data Link Started Indication:  DLC has
+                   received a Test response from the null SAP.
+
+   DLC_RESET       Reset Indication:  DLC has received an SABME
+                   command during the time a connection is
+                   currently active and has responded with DM.
+
+   DLC_RESOLVE_C   Resolve Command Indication:  DLC has received
+                   a Test command addressed to the null SAP, or an
+                   XID command addressed to the null SAP.
+
+
+
+
+
+Wells & Bartky                                                 [Page 24]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+   DLC_RESOLVED    Resolve request:  DLC has received a TEST response
+                   frame (or equivalent for non-LAN DLCs) but has not
+                   reserved the resources required for a circuit yet.
+
+   DLC_XID         XID Indication:  DLC has received an XID command
+                   or response to a non-null SAP.
+
+   Other Events:
+
+   Event Name      Description
+   ----------      -----------
+   XPORT_FAILURE   Failure of the transport connection used by the
+                   circuit.
+
+   CS_TIMER_EXP    The CIRCUIT_START timer (started when the circuit
+                   went into CIRCUIT_START state) has expired.
+
+
+   DLC Actions:
+
+   Action Name     Description
+   -----------     -----------
+   DLC_CONTACT     Contact Station Request:  DLC will send a SABME
+                   command or a UA response to an outstanding SABME
+                   command.
+
+   DLC_DGRM        Datagram Request:  DLC will send a UI frame.
+
+   DLC_ENTER_BUSY  Enter Link Station Busy:  DLC will send an
+                   RNR supervisory frame.
+
+   DLC_EXIT_BUSY   Exit Link Station Busy:  DLC will send an RR
+                   supervisory frame.
+
+   DLC_HALT_DL     Halt Data Link Request:  DLC will send a DISC
+                   command.
+
+   DLC_INFO        Information Request:  DLC will send an I frame.
+
+   DLC_RESOLVE     Resolve request:  DLC should issue a TEST (or
+                   appropriate equivalent for non-LAN DLCs) but need
+                   not reserve the resources required for a circuit yet.
+
+   DLC_RESOLVE_R   Resolve Response Request:  DLC will send a
+                   Test response or XID response from the null SAP.
+
+   DLC_START_DL    Start Data Link Request:  DLC will send a Test
+                   command to the null SAP.
+
+
+
+Wells & Bartky                                                 [Page 25]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+   DLC_XID         XID Request:  DLC will send an XID command or an
+                   XID response.
+
+
+   Other Actions:
+
+   Action Name     Description
+   ----------      -----------
+   START_CS_TIMER  Start the CIRCUIT_START timer.
+
+   DLC_RESOLVE_R and DLC_START_DL actions require the DLC to reserve the
+   resources necessary for a link station as they are used only when a
+   circuit is about to be started.  The DLC_RESOLVE action is used for
+   topology explorer traffic and does not require such resources to be
+   reserved, though a DLC implementation may choose not to distinguish
+   this from the DLC_START_DL action.  See section 5.4 for details of
+   the actions and events for explorer frames.
+
+   The Data Link Switch is described by a state transition table as
+   documented in the following sections.  Each of the states is
+   described below in terms of the events, actions, and next state for
+   each transition. If a particular event is not listed for a given
+   state, no action and no state transition should occur for that event.
+   Any significant comments concerning the transitions within a given
+   state are given immediately following the table representing the
+   state.
+
+   A separate state machine instance is maintained by the Data Link
+   Switch for each end-to-end circuit.  The number of circuits that may
+   be supported by each Data Link Switch is a local implementation
+   option.
+
+   The CANUREACH_ex, ICANREACH_ex, NETBIOS_NQ_ex, and NETBIOS_NR_ex are
+   SSP messages that are not associated with a particular circuit.  The
+   processing of these messages is covered in section 5.4.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wells & Bartky                                                 [Page 26]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+5.2.1  DISCONNECTED State
+
+   +----------------------+---------------------+----------------------+
+   |        Event         |      Action(s)      |      Next State      |
+   +----------------------+---------------------+----------------------+
+   | Receive CANUREACH_cs | DLC_START_DL        | RESOLVE_PENDING      |
+   +----------------------+---------------------+----------------------+
+   | Receive DATAFRAME    | DLC_DGRM            |                      |
+   +----------------------+---------------------+----------------------+
+   | DLC_XID              | If source route     | If CANUREACH_cs was  |
+   |                      | bridged frame with  | sent:                |
+   |                      | broadcast indicated:|   CIRCUIT_START      |
+   |                      |   Send CANUREACH_ex |                      |
+   |                      | else:               |                      |
+   |                      |   Send CANUREACH_cs |                      |
+   |                      |   START_CS_TIMER    |                      |
+   +----------------------+---------------------+----------------------+
+   | DLC_DGRM             | If NETBIOS          |                      |
+   |                      | NAME_QUERY:         |                      |
+   |                      |  Send NETBIOS_NQ_ex |                      |
+   |                      | else:               |                      |
+   |                      |  Send DATAFRAME     |                      |
+   +----------------------+---------------------+----------------------+
+   | DLC_CONTACTED        | Send CANUREACH_cs   | CIRCUIT_START        |
+   +----------------------+---------------------+----------------------+
+
+   It is assumed that each Data Link Switch will build a set of topology
+   tables giving the identity of each Data Link Switch that can reach a
+   specific MAC address or a specific NetBIOS name.  This table can be
+   built  using the explorer frames, as per the Explorer FSM in section
+   5.4.  As a consequence, the amount of search traffic can be kept to a
+   minimum.
+
+   Upon receipt of a TEST command, broadcast XID or NetBIOS NAME_QUERY,
+   the Data Link Switch checks the topology table for the target MAC/SAP
+   or NetBIOS name.  If there is no matching entry in the table, the
+   Data Link Switch uses the explorer FSMs in section 5.4 to locate the
+   target MAC/SAP or NetBIOS name.
+
+   When the first non-broadcast XID or SABME flows,  the Data Link
+   Switch issues a CANUREACH_cs to attempt to start a circuit.  The
+   CANUREACH_cs message is sent to only those Data Link Switches that
+   are known to be able to reach the given MAC address.  The mechanism
+   by which a topology table entry is determined to be out-of-date and
+   is deleted from the table is implementation specific.
+
+   The DISCONNECTED state is exited upon the sending of a CANUREACH_cs
+   by the origin DLSw or the receipt of a CANUREACH_cs message by a
+
+
+
+Wells & Bartky                                                 [Page 27]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+   prospective target Data Link Switch.  In the latter case, the Data
+   Link Switch will issue a Test command to the target station (i.e.,
+   DLC_START_DL signal is presented to DLC).
+
+5.2.2  RESOLVE_PENDING State
+
+   +-------------------+-----------------------+-----------------------+
+   |        Event      |      Action(s)        |      Next State       |
+   +-------------------+-----------------------+-----------------------+
+   | Receive DATAFRAME | DLC_DGRM              |                       |
+   +-------------------+-----------------------+-----------------------+
+   | DLC_DL_STARTED    | If LF value of        | If LF value of        |
+   |                   | DLC_DL_STARTED        | DLC_DL_STARTED        |
+   |                   | is greater than or    | is greater than or    |
+   |                   | equal to LF Size of   | equal to LF Size of   |
+   |                   | CANUREACH_cs or LF    | CANUREACH_cs or LF    |
+   |                   | Size Control bit set: | Size Control bit set: |
+   |                   |   Send ICANREACH_cs   |   CIRCUIT_PENDING     |
+   |                   | else:                 | else:                 |
+   |                   |   Send DLC_HALT_DL    |   HALT_PENDING_NOACK  |
+   +-------------------+-----------------------+-----------------------+
+   | DLC_ERROR         |                       | DISCONNECTED          |
+   +-------------------+-----------------------+-----------------------+
+   | DLC_DGRM          | Send DATAFRAME        |                       |
+   +-------------------+-----------------------+-----------------------+
+
+   The RESOLVE_PENDING state is entered upon receipt of a CANUREACH_cs
+   message by the target DLSw.  A data link is started, causing a Test
+   command to be sent by the DLC.
+
+   Several CANUREACH_cs messages can be received in the RESOLVE_PENDING
+   state.  The Data Link Switch may update its topology information
+   based upon the origin MAC address information in each CANUREACH_cs
+   message.
+
+   Upon the receipt of a DLC_DL_STARTED signal in the RESOLVE_PENDING
+   state, the Data Link Switch may update its topology table base upon
+   the remote MAC address information.  The ICANREACH_cs message must be
+   returned to the first partner DLSw from which a CANUREACH_cs was
+   received for this circuit, or an implementation may optionally reply
+   to all partners from which the CANUREACH_cs was received.
+
+   The RESOLVE_PENDING state is exited once the data link has been
+   started (i.e., a DLC_DL_STARTED signal is received as a result of a
+   Test response received by the DLC).  The target Data Link Switch then
+   enters the CIRCUIT_PENDING state.
+
+
+
+
+
+Wells & Bartky                                                 [Page 28]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+5.2.3  CIRCUIT_START State
+
+   +----------------------+---------------------+----------------------+
+   |        Event         |      Action(s)      |      Next State      |
+   +----------------------+---------------------+----------------------+
+   | Receive CANUREACH_cs | If origin MAC addr  | If DLC_START_DL      |
+   | for circuit in       | in CANUREACH_cs is  | issued:              |
+   | opposite direction   | greater than origin |   RESOLVE_PENDING    |
+   |                      | MAC addr of circuit:|                      |
+   |                      |   DLC_START_DL      |                      |
+   |                      | else:               |                      |
+   |                      |   no action taken   |                      |
+   +----------------------+---------------------+----------------------+
+   | Receive ICANREACH_cs | If LF Size Control  | If LF Size Control   |
+   |                      | bit set and LF Size | bit set and LF Size  |
+   |                      | is not negotiable:  | is not negotiable:   |
+   |                      |   Send HALT_DL_NOACK|   DISCONNECTED       |
+   |                      | else:               | else if Connected:   |
+   |                      |   Send REACH_ACK,   |   CONNECT_PENDING    |
+   |                      |   Send appropriate  | else:                |
+   |                      |   SSP message based |   CIRCUIT_ESTABLISHED|
+   |                      |   on the event      |                      |
+   |                      |   that generated    |                      |
+   |                      |   CANUREACH_cs      |                      |
+   |                      |   (see Note)        |                      |
+   +----------------------+---------------------+----------------------+
+   | DLC_DGRM             | Send DATAFRAME      |                      |
+   +----------------------+---------------------+----------------------+
+   | DLC_ERROR            |                     | DISCONNECTED         |
+   +----------------------+---------------------+----------------------+
+   | CS_TIMER_EXP         |                     | DISCONNECTED         |
+   +----------------------+---------------------+----------------------+
+   | XPORT_FAILURE        |                     | DISCONNECTED         |
+   +----------------------+---------------------+----------------------+
+
+   The CIRCUIT_START state is entered by the origin Data Link Switch
+   when a DLC_XID or DLC_CONTACTED signal has been received from the
+   DLC.
+
+   The CIRCUIT_START state is exited upon receipt of an ICANREACH_cs
+   message.  A REACH_ACK message is returned to the target Data Link
+   Switch.  If the CIRCUIT_START state was entered due to a DLC_XID
+   signal, an XIDFRAME message containing the XID is sent to the target
+   Data Link Switch.  If the CIRCUIT_START state was entered due to a
+   DLC_CONTACTED signal, a CONTACT message is sent to the target Data
+   Link Switch.
+
+
+
+
+
+Wells & Bartky                                                 [Page 29]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+5.2.4  CIRCUIT_PENDING State
+
+   +----------------------+---------------------+----------------------+
+   |        Event         |      Action(s)      |      Next State      |
+   +----------------------+---------------------+----------------------+
+   | Receive CONTACT      | DLC_CONTACT         | CONTACT_PENDING      |
+   +----------------------+---------------------+----------------------+
+   | Receive HALT_DL      | DLC_HALT_DL         | HALT_PENDING         |
+   +----------------------+---------------------+----------------------+
+   | Receive HALT_DL_NOACK| DLC_HALT_DL         | HALT_PENDING_NOACK   |
+   +----------------------+---------------------+----------------------+
+   | Receive REACH_ACK    | If Connected:       | If Connected:        |
+   |                      |  Send CONTACT       |  CONNECT_PENDING,    |
+   |                      |                     | else:                |
+   |                      |                     |  CIRCUIT_ESTABLISHED |
+   +----------------------+---------------------+----------------------+
+   | Receive XIDFRAME     | DLC_XID             |                      |
+   +----------------------+---------------------+----------------------+
+   | Receive DGRMFRAME    | DLC_DGRM            |                      |
+   +----------------------+---------------------+----------------------+
+   | Receive DATAFRAME    | DLC_DGRM            |                      |
+   +----------------------+---------------------+----------------------+
+   | DLC_CONTACTED        | If UA is sent in    |                      |
+   |                      | response to SABME:  |                      |
+   |                      |   DLC_ENTER_BUSY    |                      |
+   |                      | else:               |                      |
+   |                      |   no action taken   |                      |
+   +----------------------+---------------------+----------------------+
+   | DLC_ERROR            |                     | DISCONNECTED         |
+   +----------------------+---------------------+----------------------+
+   | DLC_XID              | Drop or hold until  |                      |
+   |                      | REACH_ACK received  |                      |
+   +----------------------+---------------------+----------------------+
+   | DLC_DGRM             | Send DATAFRAME      |                      |
+   +----------------------+---------------------+----------------------+
+   | XPORT_FAILURE        | DLC_HALT_DL         | HALT_PENDING_NOACK   |
+   +----------------------+---------------------+----------------------+
+
+   The CIRCUIT_PENDING state is entered by the target Data Link Switch
+   following the sending of an ICANREACH_cs message.  In this state it
+   is awaiting the reception of a REACH_ACK message from the origin Data
+   Link Switch.
+
+   If the target Data Link Switch happens to receive a SABME command
+   from the target station while in the CIRCUIT_PENDING state (i.e., a
+   DLC_CONTACTED signal received from the DLC), the reception of the
+   REACH_ACK message causes the target Data Link Switch to enter the
+   CONNECT_PENDING state and to send a CONTACT message to the origin
+
+
+
+Wells & Bartky                                                 [Page 30]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+   Data Link Switch.
+
+   If no such SABME is received, the receipt of the REACH_ACK causes the
+   Data Link Switch to enter CIRCUIT_ESTABLISHED state.
+
+5.2.5  CONNECT_PENDING State
+
+   +----------------------+---------------------+----------------------+
+   |        Event         |      Action(s)      |      Next State      |
+   +----------------------+---------------------+----------------------+
+   | Receive CONTACTED    | If UA was sent in   | CONNECTED            |
+   |                      | response to SABME:  |                      |
+   |                      |   DLC_EXIT_BUSY     |                      |
+   |                      | else:               |                      |
+   |                      |   DLC_CONTACT       |                      |
+   +----------------------+---------------------+----------------------+
+   | Receive HALT_DL      | DLC_HALT_DL         | HALT_PENDING         |
+   +----------------------+---------------------+----------------------+
+   | Receive HALT_DL_NOACK| DLC_HALT_DL         | HALT_PENDING_NOACK   |
+   +----------------------+---------------------+----------------------+
+   | Receive DGRMFRAME    | DLC_DGRM            |                      |
+   +----------------------+---------------------+----------------------+
+   | Receive DATAFRAME    | DLC_DGRM            |                      |
+   +----------------------+---------------------+----------------------+
+   | Receive ICANREACH_cs | Send HALT_DL_NOACK  |                      |
+   +----------------------+---------------------+----------------------+
+   | DLC_RESET            | Send RESTART_DL     | CIRCUIT_RESTART      |
+   +----------------------+---------------------+----------------------+
+   | DLC_ERROR            | Send HALT_DL        | DISCONNECT_PENDING   |
+   +----------------------+---------------------+----------------------+
+   | DLC_DGRM             | Send DGRMFRAME      |                      |
+   +----------------------+---------------------+----------------------+
+   | XPORT_FAILURE        | DLC_HALT_DL         | HALT_PENDING_NOACK   |
+   +----------------------+---------------------+----------------------+
+
+   The CONNECT_PENDING state is entered when a DLC_CONTACTED signal has
+   been received from the DLC (i.e., a SABME command has been received).
+   A CONTACT message it then  issued.  The state is exited upon the
+   receipt of a CONTACTED message.  If a DLC_RESET signal is received,
+   the local data link is restarted and a RESTART_DL message is sent to
+   the remote DLSw.
+
+   An ICANREACH_cs received after the transition to CONNECT_PENDING
+   state indicates that more than one CANUREACH_cs was sent at circuit
+   establishment time and the target station was found by more than one
+   Data Link Switch partner.  A HALT_DL_NOACK is sent to halt the
+   circuit started by the Data Link Switch partner that originated each
+   such ICANREACH_cs.
+
+
+
+Wells & Bartky                                                 [Page 31]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+   Note:  Some implementations will also send a Test command in order to
+   restart the data link to the station that sent the SABME command
+   (i.e., a DLC_START_DL will be issued).
+
+5.2.6  CIRCUIT_ESTABLISHED State
+
+   +----------------------+---------------------+----------------------+
+   |        Event         |      Action(s)      |      Next State      |
+   +----------------------+---------------------+----------------------+
+   | Receive CONTACT      | DLC_CONTACT         | CONTACT_PENDING      |
+   +----------------------+---------------------+----------------------+
+   | Receive HALT_DL      | DLC_HALT_DL         | HALT_PENDING         |
+   +----------------------+---------------------+----------------------+
+   | Receive HALT_DL_NOACK| DLC_HALT_DL         | HALT_PENDING_NOACK   |
+   +----------------------+---------------------+----------------------+
+   | Receive XIDFRAME     | DLC_XID             |                      |
+   +----------------------+---------------------+----------------------+
+   | Receive DGRMFRAME    | DLC_DGRM            |                      |
+   +----------------------+---------------------+----------------------+
+   | Receive DATAFRAME    | DLC_DGRM            |                      |
+   +----------------------+---------------------+----------------------+
+   | Receive ICANREACH_cs | Send HALT_DL_NOACK  |                      |
+   +----------------------+---------------------+----------------------+
+   | DLC_CONTACTED        | Send CONTACT        | CONNECT_PENDING      |
+   |                      | If UA is sent in    |                      |
+   |                      | response to SABME:  |                      |
+   |                      |   DLC_ENTER_BUSY    |                      |
+   |                      | else:               |                      |
+   |                      |   no action taken   |                      |
+   +----------------------+---------------------+----------------------+
+   | DLC_ERROR            | Send HALT_DL        | DISCONNECT_PENDING   |
+   +----------------------+---------------------+----------------------+
+   | DLC_DGRM             | Send DGRMFRAME      |                      |
+   +----------------------+---------------------+----------------------+
+   | DLC_XID              | Send XIDFRAME       |                      |
+   +----------------------+---------------------+----------------------+
+   | XPORT_FAILURE        | DLC_HALT_DL         | HALT_PENDING_NOACK   |
+   +----------------------+---------------------+----------------------+
+
+   The CIRCUIT_ESTABLISHED state is entered by the origin Data Link
+   Switch from the CIRCUIT_START state, and by the target Data Link
+   Switch from the CIRCUIT_PENDING state.  The state is exited when a
+   connection is started (i.e., DLC receives a SABME command) or CONTACT
+   is received. The next state is CONTACT_PENDING or CONNECT_PENDING.
+
+   An ICANREACH_cs received after the transition to CIRCUIT_ESTABLISHED
+   state indicates that more than one CANUREACH_cs was sent at circuit
+   establishment time and the target station was found by more than one
+
+
+
+Wells & Bartky                                                 [Page 32]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+   Data Link Switch partner.  A HALT_DL_NOACK is sent to halt the
+   circuit started by the Data Link Switch partner that originated each
+   such ICANREACH_cs.
+
+5.2.7  CONTACT_PENDING State
+
+   +----------------------+---------------------+----------------------+
+   |        Event         |      Action(s)      |      Next State      |
+   +----------------------+---------------------+----------------------+
+   | Receive HALT_DL      | DLC_HALT_DL         | HALT_PENDING         |
+   +----------------------+---------------------+----------------------+
+   | Receive HALT_DL_NOACK| DLC_HALT_DL         | HALT_PENDING_NOACK   |
+   +----------------------+---------------------+----------------------+
+   | Receive RESTART_DL   | DLC_HALT_DL         | RESTART_PENDING      |
+   +----------------------+---------------------+----------------------+
+   | Receive DGRMFRAME    | DLC_DGRM            |                      |
+   +----------------------+---------------------+----------------------+
+   | Receive DATAFRAME    | DLC_DGRM            |                      |
+   +----------------------+---------------------+----------------------+
+   | DLC_CONTACTED        | Send CONTACTED      | CONNECTED            |
+   +----------------------+---------------------+----------------------+
+   | DLC_ERROR            | Send HALT_DL        | DISCONNECT_PENDING   |
+   +----------------------+---------------------+----------------------+
+   | DLC_DGRM             | Send DGRMFRAME      |                      |
+   +----------------------+---------------------+----------------------+
+   | XPORT_FAILURE        | DLC_HALT_DL         | HALT_PENDING_NOACK   |
+   +----------------------+---------------------+----------------------+
+
+   The CONTACT_PENDING state is entered upon the receipt of a CONTACT
+   message, which causes the Data Link Switch to issue a DLC_CONTACT
+   signal to the DLC (i.e., DLC sends a SABME command).  This state is
+   then exited upon the receipt of a DLC_CONTACTED signal from the DLC
+   (i.e., a UA response received).
+
+   If a RESTART_DL message is received, indicating that the remote Data
+   Link Switch has received a DLC_RESET signal, the local Data Link
+   Switch sends a DISC command frame on the adjacent LAN (i.e.,
+   DLC_HALT_DL signal) and enter the RESTART_PENDING state.
+
+   An ICANREACH_cs received after the transition to CONTACT_PENDING
+   state indicates that more than one CANUREACH_cs was sent at circuit
+   establishment time and the target station was found by more than one
+   Data Link Switch partner.  A HALT_DL_NOACK is sent to halt the data
+   link started by the Data Link Switch partner that originated this
+   ICANREACH_cs.
+
+
+
+
+
+
+Wells & Bartky                                                 [Page 33]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+5.2.8  CONNECTED State
+
+   +----------------------+---------------------+----------------------+
+   |        Event         |      Action(s)      |      Next State      |
+   +----------------------+---------------------+----------------------+
+   | Receive HALT_DL      | DLC_HALT_DL         | HALT_PENDING         |
+   +----------------------+---------------------+----------------------+
+   | Receive HALT_DL_NOACK| DLC_HALT_DL         | HALT_PENDING_NOACK   |
+   +----------------------+---------------------+----------------------+
+   | Receive RESTART_DL   | DLC_HALT_DL         | RESTART_PENDING      |
+   +----------------------+---------------------+----------------------+
+   | Receive DGRMFRAME    | DLC_DGRM            |                      |
+   +----------------------+---------------------+----------------------+
+   | Receive INFOFRAME    | DLC_INFO            |                      |
+   +----------------------+---------------------+----------------------+
+   | Receive DATAFRAME    | DLC_DGRM            |                      |
+   +----------------------+---------------------+----------------------+
+   | Receive XIDFRAME     | If non-activation   |                      |
+   |                      | XID3:               |                      |
+   |                      |   DLC_XID           |                      |
+   +----------------------+---------------------+----------------------+
+   | Receive ICANREACH_cs | Send HALT_DL_NOACK  |                      |
+   +----------------------+---------------------+----------------------+
+   | Receive ENTER_BUSY   | DLC_ENTER_BUSY      |                      |
+   +----------------------+---------------------+----------------------+
+   | Receive EXIT_BUSY    | DLC_EXIT_BUSY       |                      |
+   +----------------------+---------------------+----------------------+
+   | Rec TEST_CIRCUIT_REQ | Snd TEST_CIRCUIT_RSP|                      |
+   +----------------------+---------------------+----------------------+
+   | DLC_RESET            | Send RESTART_DL     | CIRCUIT_RESTART      |
+   +----------------------+---------------------+----------------------+
+   | DLC_ERROR            | Send HALT_DL        | DISCONNECT_PENDING   |
+   +----------------------+---------------------+----------------------+
+   | DLC_DGRM             | Send DGRMFRAME      |                      |
+   +----------------------+---------------------+----------------------+
+   | DLC_INFO             | Send INFOFRAME      |                      |
+   +----------------------+---------------------+----------------------+
+   | DLC_XID              | If non-activation   |                      |
+   |                      | XID3:               |                      |
+   |                      |   Send XIDFRAME     |                      |
+   +----------------------+---------------------+----------------------+
+   | XPORT_FAILURE        | DLC_HALT_DL         | HALT_PENDING_NOACK   |
+   +----------------------+---------------------+----------------------+
+
+   The CONNECTED state is entered from the CONNECT_PENDING state upon
+   the receipt of a CONTACTED message or from the CONTACT_PENDING state
+   upon the receipt of a DLC_CONTACTED signal.
+
+
+
+
+Wells & Bartky                                                 [Page 34]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+   The CONNECTED state is exited usually under one of two conditions: a
+   DLC_ERROR signal received from the DLC (e.g., a DISC command received
+   by the local DLC), or a HALT_DL message received from the other Data
+   Link Switch (e.g., a DISC command received by the remote DLC).
+
+   A SABME command (i.e., a DLC_RESET signal) received by either Data
+   Link Switch will also cause the two Data Link Switches to leave the
+   CONNECTED state and attempt to restart the circuit.  Following the
+   receipt of a SABME, the local Data Link Switch sends a RESTART_DL
+   message to the other Data Link Switch and enters the CIRCUIT_RESTART
+   state.  Upon the receipt of the RESTART_DL message, the remote Data
+   Link Switch sends a DISC command (i.e., DLC_HALT_DL signal) and
+   enters the RESTART_PENDING state.
+
+   An ICANREACH_cs received after the transition to CONNECTED state
+   indicates that more than one CANUREACH_cs was sent at circuit
+   establishment time and the target station was found by more than one
+   Data Link Switch partner.  A HALT_DL_NOACK is sent to halt the
+   circuit started by the Data Link Switch partner that originated each
+   such ICANREACH_cs.
+
+   Note:  Some implementations will also send a Test command in order to
+   restart the data link to the station that sent the SABME command
+   (i.e., a DLC_START_DL will be issued).
+
+5.2.9  CIRCUIT_RESTART State
+
+   +----------------------+---------------------+----------------------+
+   |        Event         |      Action(s)      |      Next State      |
+   +----------------------+---------------------+----------------------+
+   | Receive DL_RESTARTED | If Connected:       | If Connected:        |
+   |                      |  Send CONTACT       |  CONNECT_PENDING,    |
+   |                      |                     | else:                |
+   |                      |                     |  CIRCUIT_ESTABLISHED |
+   +----------------------+---------------------+----------------------+
+   | Receive HALT_DL_NOACK| DLC_HALT_DL         | HALT_PENDING_NOACK   |
+   +----------------------+---------------------+----------------------+
+   | Receive DGRMFRAME    | DLC_DGRM            |                      |
+   +----------------------+---------------------+----------------------+
+   | DLC_ERROR            | Send HALT_DL        | DISCONNECT_PENDING   |
+   +----------------------+---------------------+----------------------+
+   | DLC_DGRM             | Send DGRMFRAME      |                      |
+   +----------------------+---------------------+----------------------+
+   | XPORT_FAILURE        | DLC_HALT_DL         | HALT_PENDING_NOACK   |
+   +----------------------+---------------------+----------------------+
+
+
+
+
+
+
+Wells & Bartky                                                 [Page 35]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+   The CIRCUIT_RESTART state is entered if a DLC_RESET signal is
+   received from the local DLC.  This was caused by the receipt of a
+   SABME command while a connection was currently active.  A DM response
+   will be issued to the SABME command and the Data Link Switch will
+   attempt to restart the end-to-end circuit.
+
+   The CIRCUIT_RESTART state is exited through one of two transitions.
+   The next state depends upon the time the local DLC has reached the
+   contacted state (i.e., a DLC_CONTACTED signal is presented) relative
+   to the receipt of the DL_RESTARTED message.  This signal is caused by
+   the origin station resending the SABME command that initially caused
+   the Data Link Switch to enter the CIRCUIT_RESTART state.  The two
+   cases are as follows:
+
+      1) DL_RESTARTED message received before the DLC_CONTACTED signal-
+         In this case, the CIRCUIT_ESTABLISHED state is entered.
+
+      2) DL_RESTARTED message received after the DLC_CONTACTED signal-
+         In this case, the CONNECT_PENDING state is entered.
+
+5.2.10  DISCONNECT_PENDING State
+
+   +----------------------+---------------------+----------------------+
+   |        Event         |      Action(s)      |      Next State      |
+   +----------------------+---------------------+----------------------+
+   | Receive DL_HALTED    |                     | DISCONNECTED         |
+   +----------------------+---------------------+----------------------+
+   | Receive HALT_DL      | Send DL_HALTED      |                      |
+   +----------------------+---------------------+----------------------+
+   | Receive HALT_DL_NOACK|                     | DISCONNECTED         |
+   +----------------------+---------------------+----------------------+
+   | Receive DATAFRAME    | DLC_DGRM            |                      |
+   +----------------------+---------------------+----------------------+
+   | DLC_DGRM             | Send DATAFRAME      |                      |
+   +----------------------+---------------------+----------------------+
+   | XPORT_FAILURE        |                     | DISCONNECTED         |
+   +----------------------+---------------------+----------------------+
+
+   The DISCONNECT_PENDING state is entered when a DLC_ERROR signal is
+   received from the local DLC.  Upon receipt of this signal, a HALT_DL
+   message is sent.  Once an DL_HALTED message is received, the state is
+   exited, and the Data Link Switch enters the DISCONNECTED state.
+
+
+
+
+
+
+
+
+
+Wells & Bartky                                                 [Page 36]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+5.2.11  RESTART_PENDING State
+
+   +----------------------+---------------------+----------------------+
+   |        Event         |      Action(s)      |      Next State      |
+   +----------------------+---------------------+----------------------+
+   | Receive HALT_DL_NOACK|                     | HALT_PENDING_NOACK   |
+   +----------------------+---------------------+----------------------+
+   | Receive DGRMFRAME    | DLC_DGRM            |                      |
+   +----------------------+---------------------+----------------------+
+   | DLC_DL_HALTED        | Send DL_RESTARTED   | CIRCUIT_ESTABLISHED  |
+   +----------------------+---------------------+----------------------+
+   | DLC_ERROR            | Send HALT_DL        | DISCONNECT_PENDING   |
+   +----------------------+---------------------+----------------------+
+   | DLC_DGRM             | Send DGRMFRAME      |                      |
+   +----------------------+---------------------+----------------------+
+   | XPORT_FAILURE        | DLC_HALT_DL         | HALT_PENDING_NOACK   |
+   +----------------------+---------------------+----------------------+
+
+   The RESTART_PENDING state is entered upon the receipt of a RESTART_DL
+   message from the remote DLSw while the local Data Link Switch is in
+   either the CONTACT_PENDING state or the CONNECTED state, which causes
+   the local DLSw to issue a DISC command to the DLC.  Upon the receipt
+   of the UA response (DLC_DL_HALTED), the data link is restarted, a
+   DL_RESTARTED message is returned to the remote DLSw, and the
+   CIRCUIT_ESTABLISHED state is entered.
+
+   Note:  Some implementations will send a Test command in order to
+   restart the data link to the target station (i.e., a DLC_START_DL
+   will be issued) prior to sending the DL_RESTARTED message.
+
+5.2.12  HALT_PENDING State
+
+   +----------------------+---------------------+----------------------+
+   |        Event         |      Action(s)      |      Next State      |
+   +----------------------+---------------------+----------------------+
+   | Receive HALT_DL_NOACK|                     | HALT_PENDING_NOACK   |
+   +----------------------+---------------------+----------------------+
+   | Receive DATAFRAME    | DLC_DGRM            |                      |
+   +----------------------+---------------------+----------------------+
+   | DLC_DL_HALTED        | Send DL_HALTED      | DISCONNECTED         |
+   +----------------------+---------------------+----------------------+
+   | DLC_ERROR            | Send DL_HALTED      | DISCONNECTED         |
+   +----------------------+---------------------+----------------------+
+   | DLC_DGRM             | Send DATAFRAME      |                      |
+   +----------------------+---------------------+----------------------+
+   | XPORT_FAILURE        |                     | HALT_PENDING_NOACK   |
+   +----------------------+---------------------+----------------------+
+
+
+
+
+Wells & Bartky                                                 [Page 37]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+   The HALT_PENDING state is entered upon the receipt of a HALT_DL
+   message. This causes the local DLC to issue a DISC command.  Upon the
+   receipt of the UA response (DLC_DL_HALTED), a DL_HALTED message is
+   returned to the remote DLSw and the DISCONNECTED state is entered.
+
+5.2.13  HALT_PENDING_NOACK State
+
+   +----------------------+---------------------+----------------------+
+   |        Event         |      Action(s)      |      Next State      |
+   +----------------------+---------------------+----------------------+
+   | Receive DATAFRAME    | DLC_DGRM            |                      |
+   +----------------------+---------------------+----------------------+
+   | DLC_DL_HALTED        |                     | DISCONNECTED         |
+   +----------------------+---------------------+----------------------+
+   | DLC_ERROR            |                     | DISCONNECTED         |
+   +----------------------+---------------------+----------------------+
+   | DLC_DGRM             | Send DATAFRAME      |                      |
+   +----------------------+---------------------+----------------------+
+
+   The HALT_PENDING_NOACK state is entered upon the receipt of a
+   HALT_DL_NOACK message.  This causes the local DLC to issue a DISC
+   command.  Upon the receipt of the UA response (DLC_DL_HALTED), the
+   DISCONNECTED state is entered.
+
+5.3  NetBIOS Datagrams
+
+   The NetBIOS protocols use a number of UI frames for directory
+   services and the transmission of datagrams.  Most of these frames are
+   directed to a group MAC address (GA) with the routing information
+   field indicating spanning tree explorer (STE) (a.k.a. Single Route
+   Broadcast).  The NB_Add_Name_Response and NB_Name_Recognized frames
+   are directed to a specific MAC address with the routing information
+   field indicating an all routes explorer frame (ARE) (a.k.a. All
+   Routes Broadcast)  The NB_Status_Response frame, is directed to a
+   specific MAC address with the routing information field indicating a
+   specifically routed frame (SRF). The handling of these frames is
+   summarized in the following table.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wells & Bartky                                                 [Page 38]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+   +---------------------------+------------------+--------------------+
+   |          Event            |     Action(s)    |      Comment       |
+   +---------------------------+------------------+--------------------+
+   | DLC_DGRM for NETBIOS      | Send NETBIOS_ANQ | Transmitted to all |
+   |  group address:           |                  |   remote DLSw      |
+   |   NB_Add_Name_Query       |                  |                    |
+   +---------------------------+------------------+--------------------+
+   | DLC_DGRM for a specific   | Send NETBIOS_ANR | Transmitted to     |
+   |  address:                 |                  |   specific DLSw    |
+   |   NB_Add_Name_Response    |                  |                    |
+   +---------------------------+------------------+--------------------+
+   | DLC_DGRM for a specific   | Send DATAFRAME   | Transmitted to all |
+   |  address:                 |                  |   remote DLSw      |
+   |   NB_Status_Response      |                  |                    |
+   +---------------------------+------------------+--------------------+
+   | DLC_DGRM for NETBIOS      | Send DATAFRAME   | Transmitted to all |
+   |  group address:           |                  |   remote DLSw      |
+   |   NB_Name_in_Conflict     |                  |                    |
+   |   NB_Add_Group_Name_Query |                  |                    |
+   |   NB_Datagram,            |                  |                    |
+   |   NB_Datagram_Broadcast   |                  |                    |
+   |   NB_Status_Query         |                  |                    |
+   |   NB_Terminate_Trace      |                  |                    |
+   +---------------------------+------------------+--------------------+
+
+   The above actions do not apply in the following states:
+   CIRCUIT_ESTABLISHED, CONTACT_PENDING, CONNECT_PENDING, CONNECTED, and
+   CIRCUIT_PENDING.  The handling of the remaining two UI frames used by
+   NetBIOS systems, NB_Name_Query and NB_Name_Recognized, are documented
+   as part of the DLSw state machine in the previous section (i.e.,
+   DISCONNECTED and RESOLVE_PENDING states).  Furthermore, the handling
+   of NetBIOS datagrams (i.e., NB_Datagram) sent to a specific MAC
+   address is also governed by the DLSw state machine.
+
+   Note:  Some implementations also issue Test frames during the
+   exchange of the NetBIOS, NB_Name_Query and NB_Name_Recognized.  This
+   exchange of protocol data units occurs during the start of a data
+   link and is used to determine the routing information.  Most other
+   implementations of NetBIOS will use the
+   NB_Name_Query/NB_Name_Recognized exchange to determine routes in
+   conjunction with resolving the NetBIOS names. These differences are
+   not reflected in the SSP protocols.
+
+
+
+
+
+
+
+
+
+Wells & Bartky                                                 [Page 39]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+   The handling of the NetBIOS specific SSP messages is given in the
+   following table.
+
+   +---------------+-------------------------+-------------------------+
+   |     Event     |        Action(s)        |         Comment         |
+   +---------------+-------------------------+-------------------------+
+   | NETBIOS_ANQ   | DLC_DGRM:               | Routed STE              |
+   |               |    NB_Add_Name_Query    | (NETBIOS Group Address) |
+   +---------------+-------------------------+-------------------------+
+   | NETBIOS_ANR   | DLC_DGRM:               | Routed ARE              |
+   |               |    NB_Add_Name_Response | (Specific MAC Address)  |
+   +---------------+-------------------------+-------------------------+
+   | NETBIOS_NQ_ex | DLC_DGRM:               | Routed STE              |
+   |               |    NB_Name_Query        | (NETBIOS Group Address) |
+   +---------------+-------------------------+-------------------------+
+   | NETBIOS_NQ_cs | DLC_DGRM:               | Routed STE              |
+   |               |    NB_Name_Query        | (NETBIOS Group Address) |
+   +---------------+-------------------------+-------------------------+
+   | NETBIOS_NR_ex | DLC_DGRM:               | Routed ARE              |
+   |               |    NB_Name_Recognized   | (Specific MAC Address)  |
+   +---------------+-------------------------+-------------------------+
+   | NETBIOS_NR_cs | DLC_DGRM:               | Routed ARE              |
+   |               |    NB_Name_Recognized   | (Specific MAC Address)  |
+   +---------------+-------------------------+-------------------------+
+   | DATAFRAME     | DLC_DGRM                | If NB_Status_Response:  |
+   |               |                         |  Routed ARE             |
+   |               |                         |  (Specific MAC Address) |
+   |               |                         | Else:                   |
+   |               |                         |  Routed STE             |
+   |               |                         |  (NETBIOS Group Address)|
+   +---------------+-------------------------+-------------------------+
+
+   The above actions apply to all DLSw states.  The handling of NetBIOS
+   datagrams sent within DGRMFRAME messages is governed by the DLSw
+   state machine.  The DGRMFRAME message type is employed instead of the
+   DATAFRAME message type once the end-to-end circuit has been
+   established. At that time, the message is addressed according to the
+   pair of Circuit IDs in the message header instead of relying upon the
+   MAC address information in the token ring header.
+
+5.4  Explorer Traffic
+
+   The CANUREACH_ex, ICANREACH_ex, NETBIOS_NQ_ex, and NETBIOS_NR_ex SSP
+   messages explore the topology of the DLSw cloud and the networks
+   attached to it.  These explorer frames are used to determine the DLSw
+   partners through which a MAC or NetBIOS name can be accessed.  This
+   information may optionally be cached to reduce explorer traffic in
+   the DLSw cloud.
+
+
+
+Wells & Bartky                                                 [Page 40]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+   If a DLSw is aware from cached information that a given MAC address
+   or NetBIOS name is accessible through a given partner DLSw, it should
+   direct all circuit setup attempts to that partner.  If the circuit
+   setup fails, or no such data is available in the MAC or name cache
+   database, the DLSw may fallback to issuing the setup attempt to all
+   DLSw partners on the assumption that the cached data is now out of
+   date.  The mechanism for determining when to use such a fallback is
+   implementation defined.
+
+   DLSw implementations may also use a local MAC cache to enable
+   responses to CANUREACH_ex requests to be issued without the need for
+   TEST frame exchange (or equivalent) until the CANUREACH_cs is
+   received.  Again, the fallback mechanism for determining when such
+   local cache data is out-of-date is implementation defined.
+
+   The use of either cache is an optional function in DLSw.  An
+   implementation may choose to always issue explorer frames or to use
+   either or both types of cache.
+
+   The following sections describe the FSMs used for explorer frames.
+   The DLC events and actions are a subset of those described in section
+   5.2 for the main circuit FSM.
+
+5.4.1  CANUREACH/ICANREACH Explorer FSM
+
+   The FSM described below is used to handle explorer frames routed by
+   MAC address.  There is one instance of this FSM for each Data Link ID
+   (Target and Origin MAC/SAP pair) for which explorer traffic is
+   flowing. The states in this FSM are as follows.
+
+   State Name            Description
+   ----------            -----------
+   RESET                 The initial state.
+
+   SENT_EX               Local DLSw has issued an explorer message
+
+   RECEIVED_EX           Local DLSw has received an explorer message
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wells & Bartky                                                 [Page 41]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+5.4.1.1  RESET State
+
+   +----------------------+---------------------+----------------------+
+   |        Event         |      Action(s)      |      Next State      |
+   +----------------------+---------------------+----------------------+
+   | Receive CANUREACH_ex | If replying from    | If DLC_RESOLVE sent, |
+   |                      | cache, send         |   RECEIVED_EX        |
+   |                      | ICANREACH_ex        |                      |
+   |                      | else if allowed to  |                      |
+   |                      | test availability,  |                      |
+   |                      | issue DLC_RESOLVE.  |                      |
+   |                      | Optionally update   |                      |
+   |                      | cache.              |                      |
+   +----------------------+---------------------+----------------------+
+   | Receive ICANREACH_ex | Optionally update   | RESET                |
+   |                      | cache               |                      |
+   +----------------------+---------------------+----------------------+
+   | DLC_RESOLVE_C        | Send CANUREACH_ex   | SENT_EX              |
+   +----------------------+---------------------+----------------------+
+
+   RESET is the initial state for the CANUREACH/ICANREACH explorer FSM.
+   This state is exited when a DLC_RESOLVE_C request is received from
+   the DLC or a CANUREACH_ex is received from a remote DLSw.
+
+   A DLSw implementation may optionally reply from to CANUREACH_ex
+   messages on the basis of cached topology information, in which case
+   the DLC_RESOLVE exchange (i.e., TEST) is not required.  If cache is
+   not used, or no match is found, and the DLC permits the use of TEST,
+   DLC_RESOLVE is issued to locate the target MAC and the state changes
+   to RECEIVED_EX. If no cache entry is available and TEST is not
+   allowed by the DLC, a received CANUREACH_ex frame is ignored.
+
+5.4.1.2  SENT_EX State
+
+   +----------------------+---------------------+----------------------+
+   |        Event         |      Action(s)      |      Next State      |
+   +----------------------+---------------------+----------------------+
+   | Receive ICANREACH_ex | DLC_RESOLVE_R       | RESET                |
+   |                      | Optionally update   |                      |
+   |                      | cache               |                      |
+   +----------------------+---------------------+----------------------+
+   | DLC_RESOLVE_C        |                     | SENT_EX              |
+   +----------------------+---------------------+----------------------+
+
+   SENT_EX is entered when the DLSw has issued a CANUREACH_ex message to
+   locate a MAC address.  This state is exited when a remote DLSw
+   returns a matching ICANREACH_ex, or after an implementation defined
+   timeout. DLC_RESOLVE events received in this state correspond to TEST
+
+
+
+Wells & Bartky                                                 [Page 42]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+   retries by the origin DLC station and are absorbed.
+
+   An implementation may choose whether to handle explorer frame
+   crossover either by using entirely separate FSM instances and simply
+   allowing both ends to issue TEST frames, or by detecting a reverse
+   CANUREACH_ex frame here and issuing an ICANREACH_ex message and
+   DLC_RESOLVE_R action.
+
+5.4.1.3  RECEIVED_EX State
+
+   +----------------------+---------------------+----------------------+
+   |        Event         |      Action(s)      |      Next State      |
+   +----------------------+---------------------+----------------------+
+   | Receive CANUREACH_ex | Optionally update   | RECEIVED_EX          |
+   |                      | cache               |                      |
+   +----------------------+---------------------+----------------------+
+   | Receive ICANREACH_ex |                     | RECEIVED_EX          |
+   +----------------------+---------------------+----------------------+
+   | DLC_RESOLVED         | Send ICANREACH_ex   | RESET                |
+   |                      | Optionally update   |                      |
+   |                      | cache               |                      |
+   +----------------------+---------------------+----------------------+
+
+   RECEIVED_EX is entered when the DLSw has received a CANUREACH_ex from
+   a remote DLSw and has issued a DLC_RESOLVE to locate the MAC address.
+   This state is exited when the DLC_RESOLVED response is received, or
+   after an implementation defined timeout.
+
+   If the target MAC is located, the DLSw must reply to the first
+   received CANUREACH_ex that caused the move to this state.  If
+   additional CANUREACH_ex messages are received in this state from
+   other remote DLSw partners, the DLSw may optionally reply to these
+   messages too but it is not required to do so.
+
+   An implementation may choose whether to handle explorer frame
+   crossover either by using entirely separate FSM instances and simply
+   allowing both ends to issue TEST frames, or by detecting such a
+   reverse DLC_RESOLVE_C event here and issuing an ICANREACH_ex message
+   and DLC_RESOLVE_R action.
+
+
+
+
+
+
+
+
+
+
+
+
+Wells & Bartky                                                 [Page 43]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+5.4.2  NETBIOS_NQ/NR Explorer FSM
+
+   The FSM described below is used to handle explorer frames routed by
+   NetBIOS names  There is one instance of this FSM for each unique
+   combination of Source Name, Destination Name, Data 2 field and
+   Response Correlator.
+
+   State Name            Description
+   ----------            -----------
+   RESET                 The initial state.
+
+   SENT_EX               Local DLSw has issued an explorer
+                         message
+
+   RECEIVED_EX           Local DLSw has received an explorer
+                         message
+
+   SENT_REC_EX           An explorer frame has been both sent
+                         and received for the same (potential)
+                         NetBIOS circuit.
+
+5.4.2.1  RESET State
+
+   +----------------------+---------------------+----------------------+
+   |        Event         |      Action(s)      |      Next State      |
+   +----------------------+---------------------+----------------------+
+   | Receive NETBIOS_NQ_ex| DLC_DGRM(NAME_QUERY)| RECEIVED_EX          |
+   |                      | Optionally update   |                      |
+   |                      | cache.              |                      |
+   +----------------------+---------------------+----------------------+
+   | Receive NETBIOS_NR_ex| Optionally update   | RESET                |
+   |                      | cache               |                      |
+   +----------------------+---------------------+----------------------+
+   | DLC_DGRM (NAME_QUERY)| Send NETBIOS_NQ_ex  | SENT_EX              |
+   +----------------------+---------------------+----------------------+
+
+   The RESET state is the initial state for the NETBIOS_NQ/NR explorer
+   FSM. It is exited when the DLC receives either a NETBIOS_NQ_ex or a
+   DLC_DGRM containing a NetBIOS NAME_QUERY frame.  If a NETBIOS_NQ_ex
+   message is received, the NAME_QUERY is propagated to the DLC and this
+   FSM moves to state RECEIVED_EX.  If a NetBIOS NAME_QUERY frame is
+   received, the NETBIOS_NQ_ex is propagated either to the appropriate
+   DLSw partners (see below), and this FSM moves to state SENT_EX.
+
+   Unlike SNA traffic where the CANUREACH_ex/ICANREACH_ex exchange can
+   be omitted if the MAC location is already cached,
+   NETBIOS_NQ_ex/NETBIOS_NR_ex frames must always be issued during
+   NetBIOS session setup in order that the NetBIOS session numbers are
+
+
+
+Wells & Bartky                                                 [Page 44]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+   exchanged correctly between the DLC end stations.  If the location of
+   a NetBIOS name is known from cached data, the NETBIOS_NQ_ex need only
+   be issued to the cached DLSw partners.  Otherwise the NETBIOS_NQ_ex
+   should be issued to all partners that support NetBIOS.
+
+5.4.2.2  SENT_EX State
+
+   +----------------------+---------------------+----------------------+
+   |        Event         |      Action(s)      |      Next State      |
+   +----------------------+---------------------+----------------------+
+   | Receive NETBIOS_NQ_ex| DLC_DGRM(NAME_QUERY)| SENT_REC_EX          |
+   |                      | Optionally update   |                      |
+   |                      | cache               |                      |
+   +----------------------+---------------------+----------------------+
+   | Receive NETBIOS_NR_ex| DLC_DGRM(NAME_RECOG)| RESET                |
+   |                      | Optionally update   |                      |
+   |                      | cache               |                      |
+   +----------------------+---------------------+----------------------+
+   | DLC_DGRM (NAME_QUERY)| Send NETBIOS_NQ_ex  | SENT_EX              |
+   | (different local     | Optionally update   |                      |
+   |  session number than | cache               |                      |
+   |  existing searches)  |                     |                      |
+   +----------------------+---------------------+----------------------+
+
+   SENT_EX is entered when the local DLSw issues a NETBIOS_NQ_ex to its
+   remote DLSw partners.  This state is exited when a NETBIOS_NR_ex is
+   received from a remote DLSw, or if a matching NETBIOS_NQ_ex is
+   received from a remote DLSw (i.e., a NETBIOS_NQ_ex crossover case).
+   If the local NetBIOS end station issues a NAME_QUERY with a different
+   session number from any previous NAME_QUERY for this search, the
+   NAME_QUERY is propagated to the DLSw partners to ensure that the
+   exchange of NetBIOS session numbers is handled correctly.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wells & Bartky                                                 [Page 45]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+5.4.2.3  RECEIVED_EX State
+
+   +----------------------+---------------------+----------------------+
+   |        Event         |      Action(s)      |      Next State      |
+   +----------------------+---------------------+----------------------+
+   | Receive NETBIOS_NQ_ex| DLC_DGRM(NAME_QUERY)| RECEIVED_EX          |
+   |                      | Optionally update   |                      |
+   |                      | cache               |                      |
+   +----------------------+---------------------+----------------------+
+   | Receive NETBIOS_NR_ex|                     | RECEIVED_EX          |
+   +----------------------+---------------------+----------------------+
+   | DLC_DGRM (NAME_QUERY)| Send NETBIOS_NQ_ex  | SENT_REC_EX          |
+   |                      | Optionally update   |                      |
+   |                      | cache               |                      |
+   +----------------------+---------------------+----------------------+
+   | DLC_DGRM (NAME_RECOG)| Send NETBIOS_NR_ex  | RESET                |
+   |                      | Optionally update   |                      |
+   |                      | cache               |                      |
+   +----------------------+---------------------+----------------------+
+
+   RECEIVED_EX is entered when the local DLSw receives a NETBIOS_NQ_ex
+   message from a remote DLSw.  This state is exited when a
+   NAME_RECOGNIZED NetBIOS frame is received from the DLC, completing
+   the query, or when a matching NAME_QUERY is received from DLC (i.e.,
+   NAME_QUERY crossover).
+
+5.4.2.4  SENT_REC_EX State
+
+   +----------------------+---------------------+----------------------+
+   |        Event         |      Action(s)      |      Next State      |
+   +----------------------+---------------------+----------------------+
+   | Receive NETBIOS_NQ_ex| DLC_DGRM(NAME_QUERY)| SENT_REC_EX          |
+   |                      | Optionally update   |                      |
+   |                      | cache               |                      |
+   +----------------------+---------------------+----------------------+
+   | Receive NETBIOS_NR_ex| DLC_DGRM(NAME_RECOG)| RECEIVED_EX          |
+   |                      | Optionally update   |                      |
+   |                      | cache               |                      |
+   +----------------------+---------------------+----------------------+
+   | DLC_DGRM (NAME_QUERY)| Send NETBIOS_NQ_ex  | SENT_REC_EX          |
+   | (different local     | Optionally update   |                      |
+   |  session number than | cache               |                      |
+   |  existing searches)  |                     |                      |
+   +----------------------+---------------------+----------------------+
+   | DLC_DGRM (NAME_RECOG)| Send NETBIOS_NR_ex  | SENT_EX              |
+   |                      | Optionally update   |                      |
+   |                      | cache               |                      |
+   +----------------------+---------------------+----------------------+
+
+
+
+Wells & Bartky                                                 [Page 46]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+   This state is required if an implementation wishes to manage NQ/NR
+   crossover cases from a single FSM instance by detecting 'opposite'
+   NAME_QUERY attempts between the same two NetBIOS names.  If separate
+   FSM instances are used instead, this state is not required and the
+   transitions to it from other states can be removed.
+
+   SENT_RCV_EX is exited when the NAME_QUERY search in either direction
+   is resolved.  If the local NetBIOS end station issues a NAME_QUERY
+   with a different session number from any previous NAME_QUERY it has
+   issued for this search, the NAME_QUERY is propagated to the DLSw
+   partners to ensure that the exchange of NetBIOS session numbers is
+   correctly handled.
+
+5.4.2.5  NetBIOS Session Numbers
+
+   NetBIOS NAME_QUERY and NAME_RECOGNIZED frames exchange NetBIOS session
+   numbers between the end stations.  For correct NetBIOS operation over
+   DLSw, it is important that all SSP NETBIOS_NQ_ex frames received by a
+   DLSw cause NetBIOS NAME_QUERY frames to flow on the LAN with the new
+   session number from the NETBIOS_NQ_ex.  These frames cannot be replied
+   to from a cache of locally available NetBIOS names in the same way that
+   MAC addresses and CANUREACH_ex messages can be handled.
+
+   Also, NAME_QUERY messages are normally retried several times on the LAN.
+   The generation and absorption of such frames is outside the scope of the
+   FSM defined above.
+
+6.  Protocol Flow Diagrams
+
+   The Switch-to-Switch Protocol is used to setup and take down circuits
+   between a pair of Data Link Switches.  Once a circuit is established,
+   the end stations on the local networks can employ LLC Type 1
+   (connectionless UI frames) protocols end-to-end.  In addition, the end
+   systems can establish an end-to-end connection for support of LLC Type 2
+   (connection oriented I frames) protocols (Type 2 I frames go end-to-end,
+   supervisory frames are handled locally).
+
+   The term, Data Link, is used in this document to refer to both a
+   "logical data link" when supporting Type 1 LLC services, and a "data
+   link connection" when supporting Type 2 LLC services.  In both cases,
+   the Data Link is identified by the Data Link ID defined in section 3.2.
+
+   NOTE:  THIS SECTION CONTAINS EXAMPLES ONLY.  IT CANNOT AND DOES NOT SHOW
+   ALL POSSIBLE VARIATIONS AND OPTIONS ON PROTOCOL FLOWS FOR SNA/SDLC, SSP,
+   AND LLC PROTOCOLS.
+
+
+
+
+
+
+Wells & Bartky                                                 [Page 47]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+6.1  Connect Protocols
+
+   The two basic startup flows from a pure FSM perspective are shown below.
+   The first flow is a startup involving XIDs and the second is one without
+   XIDs.
+
+Flow #1 - DLSw Startup With XIDs
+ ======                            ___                           ======
+ |    |        ---------        __/   \__       ---------        |    |
+ |    |      __|  _|_  |__     /   IP    \    __|  _|_  |__      |    |
+ ======        |   |   |      <  Network  >     |   |   |        ======
+/______\       ---------       \__     __/      ---------       /______\
+ Origin       Origin DLSw         \___/        Target DLSw      Target
+ Station        partner                          partner        Station
+
+              disconnected                    disconnected
+
+              DLC_RESOLVE_C   CANUREACH_ex
+              ----------->    ----------->
+              DLC_RESOLVE_R     ICANREACH_ex
+               <-----------     <-----------
+
+              DLC_XID         CANUREACH_cs    DLC_START_DL
+              ----------->    ----------->    ----------->
+              circuit_start                   resolve_pending
+
+                                ICANREACH_cs    DLC_DL_STARTED
+                                <-----------    <-----------
+          circuit_established                 circuit_pending
+                              REACH_ACK
+                              ----------->   circuit_established
+
+                              XIDFRAME        DLC_XID
+                              ----------->    ----------->
+
+                     DLC_XID        XIDFRAME         DLC_XID
+                <-----------    <-----------    <-----------
+              DLC_XID         XIDFRAME        DLC_XID
+              ----------->    ----------->    ----------->
+
+                 DLC_XIDs       XIDFRAMEs        DLC_XIDs
+              <------------>  <------------>  <------------>
+
+              DLC_CONTACTED   CONTACT         DLC_CONTACT
+              ----------->    ----------->    ----------->
+              connect_pending                 contact_pending
+
+
+
+
+
+Wells & Bartky                                                 [Page 48]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+                 DLC_CONTACT       CONTACTED    DLC_CONTACTED
+                <-----------    <-----------    <-----------
+                 connected                       connected
+
+                DLC_INFOs        IFRAMEs        DLC_INFOs
+              <------------>  <------------>  <------------>
+
+   Mapping LAN events to the DLC events and actions on Flow #1 produces
+   the following flows shown below:
+
+ ======                            ___                           ======
+ |    |        ---------        __/   \__       ---------        |    |
+ |    |      __|  _|_  |__     /   IP    \    __|  _|_  |__      |    |
+ ======        |   |   |      <  Network  >     |   |   |        ======
+/______\       ---------       \__     __/      ---------       /______\
+ Origin       Origin DLSw         \___/        Target DLSw      Target
+ Station        partner                          partner        Station
+
+              disconnected                    disconnected
+
+TEST_cmd      DLC_RESOLVE_C    CANUREACH_ex               TEST_cmd
+----------->  ----------->     ----------->               ---------->
+   TEST_rsp   DLC_RESOLVE_R     ICANREACH_ex                 TEST_rsp
+ <---------    <-----------   <-----------             <-----------
+null XID      DLC_XID          CANUREACH_cs    DLC_START_DL
+----------->  ----------->     ----------->    ----------->
+              circuit_start                   resolve_pending
+
+                                ICANREACH_cs    DLC_DL_STARTED
+                                <-----------    <-------------
+           circuit_established                circuit_pending
+                              REACH_ACK
+                              ----------->  circuit_established
+
+                              XIDFRAME         DLC_XID       null XID
+                              ----------->     --------->    -------->
+        XID        DLC_XID        XIDFRAME         DLC_XID          XID
+  <--------   <-----------    <-----------    <-----------    <--------
+    XIDs         DLC_XIDs      XIDFRAMEs        DLC_XIDs         XIDs
+<---------->  <---------->  <------------>  <------------>  <--------->
+SABME         DLC_CONTACTED   CONTACT         DLC_CONTACT     SABME
+----------->  ----------->    ----------->    ----------->    -------->
+              connect_pending                 contact_pending
+
+          UA     DLC_CONTACT     CONTACTED    DLC_CONTACTED          UA
+  <---------   <-----------   <-----------    <-----------    <--------
+                  connected                        connected
+
+
+
+
+Wells & Bartky                                                 [Page 49]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+  IFRAMEs       DLC_INFOs        IFRAMEs        DLC_INFOs       IFRAMEs
+<---------->  <----------->  <------------>  <------------>  <-------->
+
+Those implementations that prefer to respond to the SABME immediately
+could use the same events to do that:
+
+SABME         DLC_CONTACTED   CONTACT         DLC_CONTACT     SABME
+----------->  ----------->    ----------->    ----------->    -------->
+          UA  connect_pending                 contact_pending
+  <---------
+RR
+----------->
+         RNR
+  <---------
+
+          RR    DLC_CONTACT       CONTACTED    DLC_CONTACTED          UA
+  <---------   <-----------    <-----------    <-----------    <--------
+                 connected                        connected
+
+   IFRAMEs      DLC_INFOs        IFRAMEs        DLC_INFOs      IFRAMEs
+<---------->  <------------>  <------------>  <------------>  <-------->
+
+Flow #2 - DLSw Startup Without XIDs (circuit setup)
+
+ ======                            ___                           ======
+ |    |        ---------        __/   \__       ---------        |    |
+ |    |      __|  _|_  |__     /   IP    \    __|  _|_  |__      |    |
+ ======        |   |   |      <  Network  >     |   |   |        ======
+/______\       ---------       \__     __/      ---------       /______\
+ Origin       Origin DLSw         \___/        Target DLSw      Target
+ Station        partner                          partner        Station
+
+              disconnected                    disconnected
+
+              DLC_CONTACTED   CANUREACH_cs    DLC_START_DL
+              ----------->    ----------->    ----------->
+              circuit_start                   resolve_pending
+
+                                ICANREACH_cs    DLC_DL_STARTED
+                                <-----------    <-----------
+          circuit_established                 circuit_pending
+                              REACH_ACK
+                              ----------->   circuit_established
+
+                              CONTACT         DLC_CONTACT
+                              ----------->    ----------->
+              connect_pending                 contact_pending
+
+
+
+
+Wells & Bartky                                                 [Page 50]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+                 DLC_CONTACT       CONTACTED    DLC_CONTACTED
+                <-----------    <-----------    <-----------
+                 connected                       connected
+
+                DLC_INFOs        IFRAMEs        DLC_INFOs
+              <------------>  <------------>  <------------>
+
+   Mapping LAN events to the DLC events and actions on Flow #2 (and
+   adding a NETBIOS_NQ and NETBIOS_NR_ex) produces:
+
+ ======                            ___                           ======
+ |    |        ---------        __/   \__       ---------        |    |
+ |    |      __|  _|_  |__     /   IP    \    __|  _|_  |__      |    |
+ ======        |   |   |      <  Network  >     |   |   |        ======
+/______\       ---------       \__     __/      ---------       /______\
+ Origin       Origin DLSw         \___/        Target DLSw      Target
+ Station        partner                          partner        Station
+
+              disconnected                     disconnected
+
+NAME_QUERY    DLC_DGRM        NETBIOS_NQ_ex   DLC_DGRM       NAME_QUERY
+----------->  ----------->    ----------->    ----------->   --------->
+
+   NAME_RECOG    DLC_DGRM      NETBIOS_NR_ex     DLC_DGRM    NAME_RECOG
+ <-----------  <------------   <-----------    <-----------  <---------
+
+SABME         DLC_CONTACTED   CANUREACH_cs    DLC_START_DL
+----------->  ----------->    ----------->    ----------->
+               circuit_start                 resolve_pending
+
+                                ICANREACH_cs    DLC_DL_STARTED
+                                <-----------    <-----------
+            circuit_established                circuit_pending
+                              REACH_ACK
+                              ----------->   circuit_established
+
+                              CONTACT         DLC_CONTACT     SABME
+                              ----------->    ----------->    --------->
+             connect_pending                 contact_pending
+
+          UA   DLC_CONTACT       CONTACTED    DLC_CONTACTED           UA
+  <---------  <-----------    <-----------    <-----------    <---------
+                connected                       connected
+
+   IFRAMEs       DLC_INFOs       IFRAMEs        DLC_INFOs       IFRAMEs
+<------------> <------------> <------------>  <------------>  <-------->
+
+
+
+
+
+Wells & Bartky                                                 [Page 51]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+   In keeping with a paradigm of 'DLSw is a big 802.2 LAN', all other
+   DLC types (SDLC for now, QLLC, channel, or whatever in the future)
+   would be handled by a 'DLC transformation layer' that would transform
+   the specific protocol's events into the appropriate DLSw DLC events
+   and DLSw DLC actions into the appropriate protocol actions.  The XIDs
+   that flow in the SSP XIDFRAME should stay 802.2ish (i.e., ABM bit
+   set) and leave it up to the DLC transformation layer to suit the XID
+   to its particular DLC type.
+
+   Here is an example of a leased SDLC PU 2.0 device as the origin
+   station. It should use Flow #2 since it is not known if the other
+   side is a LAN, a switched line or a leased line.
+
+ ======                            ___                           ======
+ |    |        ---------        __/   \__       ---------        |    |
+ |    |      __|  _|_  |__     /   IP    \    __|  _|_  |__      |    |
+ ======        |   |   |      <  Network  >     |   |   |        ======
+/______\       ---------       \__     __/      ---------       /______\
+ Origin       Origin DLSw         \___/        Target DLSw      Target
+ Station        partner                          partner        Station
+
+              disconnected                     disconnected
+
+implementer's  DLC_RESOLVE_C   CANUREACH_ex
+choice (power  ----------->    ----------->
+up, configuration
+change,        DLC_RESOLVE_R   ICANREACH_ex
+never,          <-----------    <-----------
+connect timer,etc.)
+
+PU 2.0 is
+configured
+in DLSw to    DLC_XID(null)   CANUREACH_cs    DLC_START_DL
+call in       ----------->    ----------->    ----------->
+              circuit_start                   resolve_pending
+
+                                ICANREACH_cs   DLC_DL_STARTED
+                                <-----------   <-----------
+           circuit_established                circuit_pending
+                                REACH_ACK
+                                ----------->   circuit_established
+
+                              XIDFRAME        DLC_XID
+                              ----------->    ----------->
+
+                    DLC_XID        XIDFRAME         DLC_XID
+respond with   <-----------    <-----------    <-----------
+XID configured
+
+
+
+Wells & Bartky                                                 [Page 52]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+for station or
+forward XID to
+station and
+send response  DLC_XID        XIDFRAME        DLC_XID
+               ----------->   ----------->    ----------->
+
+        SNRM    DLC_CONTACT       CONTACT      DLC_CONTACTED
+  <---------   <-----------    <-----------    <------------
+              contact_pending                    connect_pending
+
+UA            DLC_CONTACTED    CONTACTED       DLC_CONTACT
+---------->    ----------->    ----------->    ----------->
+                connected                       connected
+
+   IFRAMEs       DLC_INFOs        IFRAMEs        DLC_INFOs
+<----------->  <------------>  <------------>  <------------>
+
+   Here is an example of a switched SDLC PU 2.0 device as the origin
+   station.
+
+ ======                            ___                           ======
+ |    |        ---------        __/   \__       ---------        |    |
+ |    |      __|  _|_  |__     /   IP    \    __|  _|_  |__      |    |
+ ======        |   |   |      <  Network  >     |   |   |        ======
+/______\       ---------       \__     __/      ---------       /______\
+ Origin       Origin DLSw         \___/        Target DLSw      Target
+ Station        partner                          partner        Station
+
+              disconnected                     disconnected
+
+implementer's  DLC_RESOLVE_C   CANUREACH_ex
+choice (power  ----------->    ----------->
+up, configuration
+change,        DLC_RESOLVE_R   ICANREACH_ex
+never,          <-----------    <-----------
+connect timer,etc.)
+
+XID(null)     DLC_XID(null)   CANUREACH_cs    DLC_START_DL
+----------->  ----------->    ----------->    ----------->
+              circuit_start                   resolve_pending
+
+                                ICANREACH_cs    DLC_DL_STARTED
+                                <-----------    <-----------
+            circuit_established                 circuit_pending
+                                REACH_ACK
+                                ----------->   circuit_established
+
+
+
+
+
+Wells & Bartky                                                 [Page 53]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+                                XIDFRAME      DLC_XID
+                                ----------->  ----------->
+         XID        DLC_XID         XIDFRAME         DLC_XID
+  <---------   <-----------     <-----------    <-----------
+XID           DLC_XID         XIDFRAME        DLC_XID
+--------->    ----------->    ----------->    ----------->
+
+        SNRM    DLC_CONTACT       CONTACT      DLC_CONTACTED
+  <---------   <-----------    <-----------    <-----------
+              contact_pending                 connect_pending
+
+UA            DLC_CONTACTED   CONTACTED       DLC_CONTACT
+--------->    ----------->    ----------->    ----------->
+                 connected                      connected
+
+   IFRAMEs      DLC_INFOs        IFRAMEs        DLC_INFOs
+<---------->  <------------>  <------------>  <------------>
+
+   Here is an example of a leased SDLC PU 2.0 device as the target
+   station.
+
+ ======                            ___                           ======
+ |    |        ---------        __/   \__       ---------        |    |
+ |    |      __|  _|_  |__     /   IP    \    __|  _|_  |__      |    |
+ ======        |   |   |      <  Network  >     |   |   |        ======
+/______\       ---------       \__     __/      ---------       /______\
+ Origin       Origin DLSw         \___/        Target DLSw       Target
+ Station        partner                          partner         Station
+                                                                 (SDLC)
+              disconnected                    disconnected
+
+              DLC_RESOLVE_C   CANUREACH_ex
+              ----------->    ----------->   reply if virtual MAC/SAP
+                                             for SDLC station is
+                                             configured, if SDLC
+                                             station responds to
+              DLC_RESOLVE_R    ICANREACH_ex  TEST/SNRM/DISC, etc.
+               <-----------    <-----------
+              DLC_XID         CANUREACH_cs    DLC_START_DL    SNRM
+              ----------->    ----------->    ----------->    --------->
+              circuit_start                   resolve_pending
+
+                                ICANREACH_cs    DLC_DL_STARTED        UA
+                                <-----------    <-----------    <-------
+          circuit_established                 circuit_pending
+                                                              RNR
+                              REACH_ACK                       --------->
+                              ----------->   circuit_established
+
+
+
+Wells & Bartky                                                 [Page 54]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+                              XIDFRAME        DLC_XID
+                              ----------->    -----------> respond with
+                                                           XID configured
+                                                           for station
+                                                           or forward
+                                                           XID to
+                                                           station and
+                                                           send
+                   DLC_XID        XIDFRAME         DLC_XID response
+              <-----------    <-----------    <-----------
+              DLC_CONTACTED   CONTACT         DLC_CONTACT     RR
+              ----------->    ----------->    ----------->    --------->
+             connect_pending                contact_pending
+
+                 DLC_CONTACT       CONTACTED    DLC_CONTACTED
+                <-----------    <-----------    <-----------
+                connected                        connected
+
+                DLC_INFOs        IFRAMEs        DLC_INFOs       IFRAMEs
+              <------------>  <------------>  <------------>  <------->
+
+   Here is an example of a switched SDLC PU 2.0 device as the target
+   station.
+
+ ======                            ___                           ======
+ |    |        ---------        __/   \__       ---------        |    |
+ |    |      __|  _|_  |__     /   IP    \    __|  _|_  |__      |    |
+ ======        |   |   |      <  Network  >     |   |   |        ======
+/______\       ---------       \__     __/      ---------       /______\
+ Origin       Origin DLSw         \___/        Target DLSw       Target
+ Station        partner                          partner         Station
+                                                                 (SDLC)
+              disconnected                    disconnected
+
+              DLC_RESOLVE_C   CANUREACH_ex
+              ----------->    ----------->    reply if virtual MAC/SAP
+                                              for SDLC station is
+                                              configured, if SDLC
+                                              station responds to
+              DLC_RESOLVE_R     ICANREACH_ex  TEST/XID/SNRM/DISC, etc.
+               <-----------     <-----------
+              DLC_XID         CANUREACH_cs    DLC_START_DL    XID
+              ----------->    ----------->    ----------->    --------->
+              circuit_start                   resolve_pending
+
+                                ICANREACH_cs   DLC_DL_STARTED        XID
+                                <-----------   <-----------    <--------
+          circuit_established                 circuit_pending
+
+
+
+Wells & Bartky                                                 [Page 55]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+                              REACH_ACK
+                              ----------->   circuit_established
+
+                                XIDFRAME        DLC_XID
+                                ----------->    -----------> respond
+                                                             with XID
+                                                             received
+                     DLC_XID        XIDFRAME        DLC_XID  above
+                <-----------    <-----------     <---------
+             DLC_CONTACTED   CONTACT         DLC_CONTACT     SNRM
+             ----------->    ----------->    ----------->    --------->
+             connect_pending                  contact_pending
+
+                DLC_CONTACT       CONTACTED    DLC_CONTACTED          UA
+               <-----------    <-----------    <-----------    <--------
+                connected                        connected
+
+                DLC_INFOs        IFRAMEs        DLC_INFOs       IFRAMEs
+              <------------>  <------------>  <------------>  <-------->
+
+   Here is an example of an SDLC T2.1 device as the target station.
+   (SDLC T2.1 origin station would look just like the LAN T2.1 origin
+   station)
+
+ ======                            ___                           ======
+ |    |        ---------        __/   \__       ---------        |    |
+ |    |      __|  _|_  |__     /   IP    \    __|  _|_  |__      |    |
+ ======        |   |   |      <  Network  >     |   |   |        ======
+/______\       ---------       \__     __/      ---------       /______\
+ Origin       Origin DLSw         \___/        Target DLSw      Target
+ Station        partner                          partner        Station
+
+              disconnected                    disconnected
+
+              DLC_RESOLVE_C   CANUREACH_ex
+              ----------->    ----------->    implementer's choice
+                                              (virtual MAC/SAP
+                                               configured,
+                                               check to see if station
+                                               is powered up using
+              DLC_RESOLVE_R     ICANREACH_ex   TEST/XID/DISC, etc.)
+               <-----------     <-----------
+              DLC_XID         CANUREACH_cs    DLC_START_DL    null XID
+              ----------->    ----------->    ----------->    --------->
+              circuit_start                   resolve_pending
+
+                                ICANREACH_cs    DLC_DL_STARTED       XID
+                                <-----------    <-----------    <-------
+
+
+
+Wells & Bartky                                                 [Page 56]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+          circuit_established                 circuit_pending
+                              REACH_ACK
+                              ----------->   circuit_established
+                              XIDFRAME        DLC_XID
+                              ----------->    ----------->  respond with
+                                                            XID received
+                     DLC_XID        XIDFRAME        DLC_XID above
+                <-----------    <-----------    <----------
+                 DLC_XIDs       XIDFRAMEs        DLC_XIDs         XIDs
+              <------------>  <------------>  <------------>  <-------->
+              DLC_CONTACTED   CONTACT         DLC_CONTACT     SNRM
+              ----------->    ----------->    ----------->    --------->
+              connect_pending                 contact_pending
+
+                 DLC_CONTACT       CONTACTED    DLC_CONTACTED         UA
+                <-----------    <-----------    <-----------    <-------
+                connected                        connected
+
+                DLC_INFOs        IFRAMEs        DLC_INFOs       IFRAMEs
+              <------------>  <------------>  <------------>  <-------->
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wells & Bartky                                                 [Page 57]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+6.2  Link Restart Protocols
+
+   The following figure depicts the protocol flows that result from
+   restarting the end-to-end connection.  This causes the Data Link
+   Switches to terminate the existing connection and to enter the
+   Circuit Established state awaiting the start of a new connection.
+
+     Data Link   Data Link                     Data Link   Data Link
+      Control     Switch                        Switch      Control
+     ---------------------                     ---------------------
+          +-----------+                             +-----------+
+          | Connected |                             | Connected |
+    SABME +-----------+                             +-----------+
+   ----------->                 RESTART_DL
+      DM           ------------------------------------->     DISC
+   <-----------                                               -------->
+                                                               UA
+                         DL_RESTARTED (Case 1)              <--------
+                   <-------------------------------------
+          +-----------+                             +-----------+
+          |Circuit Est|                             |Circuit Est|
+          +-----------+                             +-----------+
+                        ........... or ...........
+    SABME
+   ----------->           DL_RESTARTED (Case 2)
+       UA          <-------------------------------------
+   <-----------                                     +-----------+
+                                                    |Circuit Est|
+                                CONTACT             +-----------+
+      RNR           ------------------------------------>
+   <----------
+
+              Figure 5.  DLSw Link Restart Message Protocols
+
+   Upon receipt of a SABME command from the origin station, the origin
+   DLSw will send a RESTART_DL message to the target DLSw.  A DM
+   response is also returned to the origin station and the data link is
+   restarted.
+
+   Upon receipt of the RESTART_DL message, the target DLSw will issue a
+   DISC command to the target station.  The target station is expected
+   to return a UA response.  The target DLSw will then restart its data
+   link and send an DL_RESTARTED message back to the origin DLSw.
+   During this exchange of messages, both Data Link Switches change
+   states from Connected state to Circuit Established state.
+
+   If the origin station now resends the SABME command, the origin DLSw
+   will send a CONTACT message to the target DLSw.  If the SABME command
+
+
+
+Wells & Bartky                                                 [Page 58]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+   is received prior to the receipt of the DL_RESTARTED message (case 2
+   in the figure), the CONNECT message is delayed until the DL_RESTARTED
+   message is received.  The resulting protocol flows at this point
+   parallel those given above for the connect sequence.
+
+6.3  Disconnect Protocols
+
+   The following figure depicts the protocol flows that result from the
+   end system terminating an existing connection.  Not only is the
+   connection terminated, but the circuit between the Data Link Switches
+   is taken down.
+
+     Data Link  Data Link                      Data Link  Data Link
+      Control    Switch                         Switch     Control
+     --------------------                      --------------------
+          +-----------+                             +-----------+
+          | Connected |                             | Connected |
+          +-----------+                             +-----------+
+      DISC
+   ---------->                  HALT_DL
+       UA         ------------------------------------->      DISC
+   <----------                                              --------->
+                                                               UA
+                               DL_HALTED                    <--------
+                  <-------------------------------------
+          +-----------+                             +-----------+
+          |Disconnectd|                             |Disconnectd|
+          +-----------+                             +-----------+
+
+                          ......... or ..........
+
+          +-----------+                             +-----------+
+          | Connected |                             | Connected |
+          +-----------+                             +-----------+
+       DISC              TCP Connection Failure               DISC
+   <--------     <------------------------------------>    --------->
+        UA                                                     UA
+    -------->                                               <--------
+          +-----------+                             +-----------+
+          |Disconnectd|                             |Disconnectd|
+          +-----------+                             +-----------+
+
+               Figure 6.  DLSw Disconnect Message Protocols
+
+   Upon receipt of a DISC command from the origin station, the origin
+   DLSw will reply with a UA response and issue a HALT_DL message to the
+   target DLSw.  Upon receipt of the HALT_DL message, the target DLSw
+   will send a DISC command to the target station.  The target station
+
+
+
+Wells & Bartky                                                 [Page 59]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+   will then respond with a UA response, causing the target DLSw to
+   return a DL_HALTED message to the origin DLSw.  During this exchange
+   of messages, both Data Link Switches change states from the Connected
+   state to the Disconnected state.
+
+   If the TCP connection between two Data Link Switches fails, all
+   connections that are currently multiplexed on the failed TCP
+   connection will be taken down.  This implies that both Data Link
+   Switches will send DISC commands to all the local systems that are
+   associated with the failed connections.  Upon sending the DISC
+   command, the Data Link Switch will enter the DISCONNECTED state for
+   each circuit.
+
+7.0  Capabilities Exchange Formats/Protocol
+
+   The Data Link Switching Capabilities Exchange is a special DLSw
+   Switch-to-Switch control message that describes the capabilities of
+   the sending data link switch. This control message is sent after the
+   switch-to-switch connection is established and optionally during run
+   time if certain operational parameters have changed and need to be
+   communicated to the partner switch.
+
+   The actual contents of the Capabilities Exchange is in the data field
+   following the SSP message header.  The Capabilities Exchange itself
+   is formatted as a single General Data Stream (GDS) Variable with
+   multiple type "LT" structured subfields.
+
+   The SSP Message Header has the following fields set for the
+   Capabilities Exchange:
+
+   Offset   Field                 Value
+   ------   -----                 -----
+   0x00     Version Number        0x31
+   0x01     Header Length         0x48 (decimal 72)
+   0x02     Message Length        same as LL in GDS Variable
+   0x14     Message Type          0x20 (CAP_EXCHANGE)
+   0x16     Protocol Id           0x42
+   0x17     Header Number         0x01
+   0x23     Message Type          0x20 (CAP_EXCHANGE)
+   0x38     Direction             0x01 for CapEx request
+                                  0x02 for CapEx response
+
+   Other fields in the SSP header are not referenced and should be set
+   to zero.
+
+
+
+
+
+
+
+Wells & Bartky                                                 [Page 60]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+   The DLSw Capabilities Exchange Request has the following overall
+   format:
+
+   +----+----+-----------------+
+   | LL | ID | Control Vectors |
+   +----+----+-----------------+
+
+   0-1         Length, in binary, of the DLSw Capabilities
+               Exchange
+               Request GDS Variable.  The value of LL is
+               the sum of the length of all fields in the
+               GDS Variable (i.e., length of LL + length of ID
+               + length of Control Vectors).
+
+   2-3         GDS Id: 0x1520
+
+   4-n         Control Vectors consisting of type LT structured
+               subfields (i.e., the DLSw Capabilities Exchange
+               Structured Subfields)
+
+   Type LT structured subfields consist of a 1-byte length field (the
+   "L"), a 1-byte type field (the "T") and n-bytes of data.  The length
+   field includes itself as well as the structured subfield.  The
+   structured subfield consists of the type field and data so the length
+   is n + 2. This imposes a length restriction of 253 bytes on all data
+   contained in a structured subfield.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wells & Bartky                                                 [Page 61]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+7.1  Control Vector Id Range
+
+   Control Vector identifiers (i.e., Type) in the range of 0x80 through
+   0xCF are reserved for use by the Data Link Switching standard.
+
+   Control Vector identifiers (i.e., Type) in the range of 0xD0 through
+   0xFD are used for vendor-specific purposes.
+
+   Currently defined vectors are:
+
+   Vector Description                       Hex Value
+
+   Vendor Id Control Vector                 0x81
+   DLSw Version Control Vector              0x82
+   Initial Pacing Window Control Vector     0x83
+   Version String Control Vector            0x84
+   Mac Address Exclusivity Control Vector   0x85
+   Supported SAP List Control Vector        0x86
+   TCP Connections Control Vector           0x87
+   NetBIOS Name Exclusivity Control Vector  0x88
+   MAC Address List Control Vector          0x89
+   NetBIOS Name List Control Vector         0x8A
+   Vendor Context Control Vector            0x8B
+   Reserved for future use                  0x8C - 0xCF
+   Vendor Specific                          0xD0 - 0xFD
+
+7.2  Control Vector Order and Continuity
+
+   Since their contents can greatly affect the parsing of the
+   Capabilities Exchange GDS Variable, the required control vectors must
+   occur first and appear in the following order:  Vendor Id, DLSw
+   Version Number, Initial Pacing Window, Supported SAP List. The
+   remainder of the Control Vectors can occur in any order.
+
+   Control Vectors that can be repeated within the same message (e.g.,
+   MAC Address List Control Vector and NetBIOS Name List Control Vector)
+   are not necessarily adjacent.  It is advisable, but not required, to
+   have the Exclusivity Control Vector occur prior to either of the
+   above two vectors so that the use of the individual MAC addresses or
+   NetBIOS names will be known prior to parsing them.
+
+   Both the Vendor Context and Vendor Specific control vectors can be
+   repeated.  If there are multiple instances of the Vendor Context
+   control vector, the specified context remains in effect for all
+   Vendor Specific control vectors until the next Vendor Context control
+   vector is encountered in the Capabilities Exchange.
+
+
+
+
+
+Wells & Bartky                                                 [Page 62]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+7.3  Initial Capabilities Exchange
+
+   Capabilities exchange is always the first SSP message sent on a new
+   SSP connection between two DLSw switches.  This initial Capabilities
+   Exchange is used to identify the DLSw version that each switch is
+   running and other required information, plus details of any optional
+   extensions that the switches are capable of supporting.
+
+   If a DLSw receives an initial capabilities message that is
+   incorrectly formatted or contains invalid or unsupported data that
+   prevents correct interoperation with the partner DLSw, it should
+   issue a Capabilities Exchange negative response.
+
+   If a DLSw receives a negative response to its initial capabilities
+   message, it should take down its TCP connections with the offended
+   partner.
+
+   Note:  Pre v1.0 DLSw implementations do not send or respond to
+   capabilities messages and can be identified by the lack of
+   capabilities exchange as the first message on a new SSP connnection.
+   This document does not attempt to specify how to interoperate with
+   back-level DLSw implementations.
+
+7.4  Run-Time Capabilities Exchange
+
+   Capabilities exchange always occurs when the SSP connection is
+   started between two DLSw switches.  Capabilities Exchange can also
+   occur at run-time, typically when a configuration change is made.
+
+   Support for run-time Capabilities Exchange is optional.  If a node
+   does not support receiving/using Run-Time Capabilities Exchange and
+   receives one, it should discard it quietly (not send back a negative
+   response).  If a node supports receipt of run-time capabilities, it
+   should send a positive or negative response as appropriate.  The
+   receiver of a negative response to a run-time capabilities message is
+   not required to take down its TCP connections with the offended
+   partner.
+
+   Run-time Capabilities Exchange can consist of one or more of the
+   following control vectors.  Note that the control vectors required at
+   start-up are not present in a run-time Capabilities Exchange.
+
+
+
+
+
+
+
+
+
+
+Wells & Bartky                                                 [Page 63]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+        1. MAC Address Exclusivity CV,
+        2. NetBIOS Name Exclusivity CV,
+        3. MAC Address List CV,
+        4. NetBIOS Name List CV,
+        5. Supported SAP List CV,
+        6. Vendor Context CV,
+        7. Vendor Specific CVs
+
+   A run-time capabilities exchange is a replacement operation.  As
+   such, all pertinent MAC addresses and NetBIOS names must be specified
+   in the run-time exchange. In addition, run-time changes in
+   capabilities will not effect existing link station circuits.
+
+7.5  Capabilities Exchange Filtering Responsibilities
+
+   Recipients of the SAP, MAC, and NetBIOS lists are not required to
+   actually use them to filter traffic, etc., either initially or at
+   run-time.
+
+7.6  DLSw Capabilities Exchange Structured Subfields
+
+   The Capabilities Exchange Subfields are listed in the table below and
+   are described in the following sections:
+
+         Required                      Allowed @
+    ID   @ Startup  Length  Repeatable* Runtime  Order  Content
+   ====  =========  ======  ==========  =======  =====  ===============
+   0x81     Y        0x05        N         N       1    Vendor ID
+
+   0x82     Y        0x04        N         N       2    DLSw Version
+
+   0x83     Y        0x04        N         N       3    Initial pacing
+                                                        window
+
+   0x84     N      >=0x02        N         N       5+   Version String
+
+   0x85     N        0x03        N         Y       5+   MAC Address
+                                                        Exclusivity
+
+   0x86     Y        0x12        N         Y       4    Supported SAP
+                                                        List
+
+   0x87     N        0x03        N         N       5+   TCP Connections
+
+   0x88     N        0x03        N         Y       5+   NetBIOS Name
+                                                        Exclusivity
+
+
+
+
+
+Wells & Bartky                                                 [Page 64]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+   0x89     N        0x0E        Y         Y       5+   MAC Address
+                                                        List
+
+   0x8A     N      <=0x13        Y         Y       5+   NetBIOS Name
+                                                        List
+
+   0x8B     N        0x05        Y         Y       5+   Vendor Context
+
+   0xD0     N       varies       Y         Y       5+   Vendor Specific
+
+   *Note: "Repeatable" means a Control Vector is repeatable within a single
+   message.
+
+7.6.1  Vendor Id (0x81) Control Vector
+
+   The Vendor Id control vector identifies the manufacturer's IEEE
+   assigned Organizationally Unique Identifier (OUI) of the Data Link
+   Switch sending the DLSw Capabilities Exchange.  The OUI is sent in
+   non-canonical (Token-Ring) format.  This control vector is required
+   and must be the first control vector.
+
+   Offset  Length  Value  Contents
+   ------  ------  -----  --------
+      0       1    0x05   Length of the Vendor Id structured
+                          subfield
+
+      1       1    0x81   key = 0x81  that identifies this as the
+                          Vendor Id structured subfield
+
+     2-4      3           the 3-byte Organizationally Unique
+                          Identifier (OUI) for the vendor
+                          (non-canonical format)
+
+7.6.2  DLSw Version (0x82) Control Vector
+
+   The DLSw Version control vector identifies the particular version of
+   the DLSw standard supported by the sending Data Link Switch.  This
+   control vector is required and must follow the Vendor Id Control
+   Vector.
+
+   Offset  Length  Value  Contents
+   ------  ------  -----  --------
+      0       1    0x04   Length of the Version String structured
+                          subfield
+
+      1       1    0x82   key = 0x82  that identifies this as the
+                          DLSw Version structured subfield
+
+
+
+
+Wells & Bartky                                                 [Page 65]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+      2       1           the hexadecimal value representing the
+                          DLSw standard Version number of the
+                          sending Data Link Switch.
+                            0x01 (indicates version 1 - closed pages)
+
+      3       1           the hexadecimal value representing the
+                          DLSw standard Release number of the
+                          sending Data Link Switch.
+                            0x00 (indicates release 0)
+
+7.6.3  Initial Pacing Window (0x83) Control Vector
+
+   The Initial Pacing Window control vector specifies the initial value
+   of the receive pacing window size for the sending Data Link Switch.
+   This control vector is required and must follow the DLSw Version
+   Control Vector.
+
+   Offset  Length  Value  Contents
+   ------  ------  -----  --------
+      0       1    0x04   Length of the Initial Pacing Window
+                          structured subfield
+
+      1       1    0x83   key = 0x83  that identifies this
+                          as the Initial Pacing Window
+                          structured subfield
+
+     2-3      2           the pacing window size, specified
+                          in byte normal form..
+
+   Note:  The pacing window size must be non-zero.
+
+7.6.4  Version String (0x84) Control Vector
+
+   The Version String control vector identifies the particular version
+   number of the sending Data Link Switch.  The format of the actual
+   version string is vendor-defined.  This control vector is optional.
+
+   Offset  Length  Value  Contents
+   ------  ------  -----  --------
+      0       1    0xn    Length of the Version String
+                          structured subfield
+
+      1       1    0x84   key = 0x84  that identifies
+                          this as the Version String
+                          structured subfield
+
+
+
+
+
+
+Wells & Bartky                                                 [Page 66]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+     2-n     n-2          the ASCII string that identifies
+                          the software version for the
+                          sending DLSw.
+
+7.6.5  MAC Address Exclusivity (0x85) Control Vector
+
+   The MAC Address Exclusivity control vector identifies how the MAC
+   Address List control vector data is to be interpreted.  Specifically,
+   this control vector identifies whether the MAC addresses in the MAC
+   Address List control vectors are the only ones accessible via the
+   sending Data Link Switch.
+
+   If a MAC Address List control vector is specified and the MAC Address
+   Exclusivity control vector is missing, then the MAC addresses are not
+   assumed to be the only ones accessible via this switch.
+
+   A node may specify that it supports no local MAC addresses by
+   including in its capabilities the MAC Address List Exclusivity CV
+   (with byte 2 == 0x01), and not including any instances of the MAC
+   Address List CV.
+
+   Offset  Length  Value  Contents
+   ------  ------  -----  --------
+      0       1    0x03   Length of the Exclusivity structured
+                          subfield
+
+      1       1    0x85   key = 0x85 that identifies this as the
+                          MAC address Exclusivity structured
+                          subfield
+
+      2       1           an indicator of the relationship of the
+                          MAC addresses to the sending Data Link
+                          Switch.
+                            0x00     the MAC addresses specified in
+                                     this Capabilities Exchange
+                                     can be accessed via this
+                                     switch but are not the
+                                     exclusive set (i.e., other
+                                     entities are accessible in
+                                     addition to the ones specified)
+                            0x01     the MAC addresses specified in
+                                     this Capabilities Exchange
+                                     are the only ones accessible
+                                     via this switch.
+
+
+
+
+
+
+
+Wells & Bartky                                                 [Page 67]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+7.6.6  SAP List Support (0x86) Control Vector
+
+   The SAP List Support control vector identifies support for Logical
+   Link Control SAPs (DSAPs and SSAPs) by the sending Data Link Switch.
+   This is used by the DLSw that sent the SAP List Support control
+   vector to indicate which SAPs can be used to support SNA and
+   optionally NetBIOS traffic.  This may be used by the DLSw that
+   receives the SAP list to filter explorer traffic (TEST, XID, or
+   NetBIOS UI frames) from the DLSw state machine.  For SNA, a DLSw
+   should set bits for all SAP values (SSAP or DSAP) that may be used
+   for SNA traffic.  For NetBIOS support, the bit for SAP 0xF0 should be
+   set (if not supported then the same bit should be cleared).
+
+   Each bit in the SAP control vector data field represents a SAP as
+   defined below.  This vector is required and must follow the Initial
+   Pacing Window Control Vector.
+
+   Offset  Length  Value  Contents
+   ------  ------  -----  --------
+      0       1     0x12  Length of the Supported SAP List structured
+                          subfield
+
+      1       1     0x86  key = 0x86 that identifies this as the
+                          Supported SAP List structured subfield
+
+     2-17    16           the 16-byte bit vector describing all
+                          even numbered SAPs enabled.
+
+                          Each Bit within the 16 byte bit vector will
+                          indicate whether an even numbered SAP is
+                          enabled (b'1') or disabled (b'0').
+
+                          Each Byte within the 16 byte bit vector
+                          will be numbered from 0 - F. (Most
+                          significant byte first).
+
+                          Byte 0   1   2   3   ...   F
+                               XX  XX  XX  XX  ...   XX
+
+                          The bits in each byte indicate whether an
+                          even numbered SAP is enabled (b'1') or
+                          disabled (b'0'). (Most significant bit first)
+
+                          Bits 7   6   5   4   ...   0
+                          SAP  0   2   4   6   ...   E
+
+                          By combining the byte label with the enabled
+                          bits, all supported SAPs can be determined.
+
+
+
+Wells & Bartky                                                 [Page 68]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+                          In the following diagram, 'n' would equal 0
+                          through F depending on which byte was being
+                          interpreted.
+
+                          Bit ordering is shown below with bit
+                          7 being the most significant bit and bit
+                          0 the least significant bit.
+
+                          7654 3210
+                          bbbb bbbb....
+                          |||| ||||
+                          |||| |||SAP 0xnE enabled or not
+                          |||| |||
+                          |||| ||SAP 0xnC enabled or not
+                          |||| ||
+                          |||| |SAP 0xnA enabled or not
+                          |||| |
+                          |||| SAP 0xn8 enabled or not
+                          ||||
+                          |||SAP 0xn6 enabled or not
+                          |||
+                          ||SAP 0xn4 enabled or not
+                          ||
+                          |SAP 0xn2 enabled or not
+                          |
+                          SAP 0xn0 enabled or not
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wells & Bartky                                                 [Page 69]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+   An example of using all User Definable SAPs of 0x04 to 0xEC for SNA
+   Data Link Switching and SAP 0xF0 for NetBIOS Data Link Switching
+   would be as follows:
+
+   Offset  SAPs          Binary       Hex
+
+   0       4,8,C         0010 1010    0x2A
+   1       10,14,18,1C   1010 1010    0xAA
+   2       20,24,28,2C   1010 1010    0xAA
+   3       30,34,38,3C   1010 1010    0xAA
+   4       40,44,48,4C   1010 1010    0xAA
+   5       50,54,58,5C   1010 1010    0xAA
+   6       60,64,68,6C   1010 1010    0xAA
+   7       70,74,78,7C   1010 1010    0xAA
+   8       80,84,88,8C   1010 1010    0xAA
+   9       90,94,98,9C   1010 1010    0xAA
+   A       A0,A4,A8,AC   1010 1010    0xAA
+   B       B0,B4,B8,BC   1010 1010    0xAA
+   C       C0,C4,C8,CC   1010 1010    0xAA
+   D       D0,D4,D8,DC   1010 1010    0xAA
+   E       E0,E4,E8,EC   1010 1010    0xAA
+   F       F0            1000 0000    0x80
+
+7.6.7  TCP Connections (0x87) Control Vector
+
+   The TCP Connections control vector indicates the support of an
+   alternate number of TCP Connections for the Data Link Switching
+   traffic.  The base implementation of Data Link Switching supports two
+   TCP Connections, one for each direction of data traffic.
+
+   This control vector is optional.  If it is omitted in a DLSw
+   Capabilities Exchange, then two TCP Connections are assumed.  It is
+   further assumed that if a Data Link  Switch can support one TCP
+   Connection, it can support two TCP Connections.
+
+   If TCP Connections CV values agree and the number of connections is
+   one, then the  DLSw with the higher IP address must tear down the TCP
+   connections on its local port 2065.
+
+   The format of the TCP Connections Control Vector is shown below:
+
+   Offset  Length  Value  Contents
+   ------  ------  -----  --------
+      0       1    0x03   Length of the TCP Connections structured
+                          subfield
+
+      1       1    0x87   key = 0x87  that identifies this as the
+                          TCP Connections structured subfield
+
+
+
+Wells & Bartky                                                 [Page 70]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+      2       1           an indicator of the support for an
+                          alternate number of TCP Connections by
+                          the sending Data Link Switch.
+                            0x01      the number of TCP Connections
+                                      may be brought down to one
+                                      after Capabilities Exchange
+                                      is completed.
+                            0x02      the number of TCP Connections
+                                      will remain at two for
+                                      the duration of the DLSw
+                                      connection.
+
+7.6.8  NetBIOS Name Exclusivity (0x88) Control Vector
+
+   The NetBIOS Name Exclusivity control vector identifies how the
+   NetBIOS Name List control vector data is to be interpreted.
+   Specifically, this control vector identifies whether the NetBIOS
+   Names in the NetBIOS Name List control vectors are the only ones
+   accessible via the sending Data Link Switch.
+
+   If a NetBIOS Name List control vector is specified and the NetBIOS
+   Name Exclusivity control vector is missing, then the NetBIOS Names
+   are not assumed to be the only  ones accessible via this switch.
+
+   A node may specify that it supports no local NetBIOS names by
+   including in its  capabilities the NetBIOS Name List Exclusivity CV
+   (with byte 2 == 0x01), and not including any instances of the NetBIOS
+   Name List CV.
+
+   Offset  Length  Value  Contents
+   ------  ------  -----  --------
+      0       1    0x03   Length of the Exclusivity structured
+                          subfield
+
+      1       1    0x88   key = 0x88 that identifies this as the
+                          NetBIOS Name Exclusivity structured
+                          subfield
+
+      2       1           an indicator of the relationship of the
+                          NetBIOS Names to the sending Data Link
+                          Switch.
+                            0x00     the NetBIOS Names specified in
+                                     this Capabilities Exchange
+                                     can be accessed via this
+                                     switch but are not the
+                                     exclusive set (i.e., other
+                                     entities are accessible in
+                                     addition to the ones specified)
+
+
+
+Wells & Bartky                                                 [Page 71]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+                            0x01     the NetBIOS Names specified in
+                                     this Capabilities Exchange
+                                     are the only ones accessible
+                                     via this switch.
+
+7.6.9  MAC Address List (0x89) Control Vector
+
+   The MAC Address List control vector identifies one or more MAC
+   addresses that are accessible through the sending Data Link Switch.
+   This control vector specifies a single MAC address value and MAC
+   address mask value to identify the MAC address or range of MAC
+   addresses.  MAC addresses and masks are in non-canonical (Token-Ring)
+   format in this control vector.
+
+   This control vector is optional and can be repeated if necessary.
+
+   Note 1: If a particular MAC address, <mac-addr>, satisfies the
+   following algorithm, then <mac-addr> is assumed to be accessible via
+   the sending Data Link Switch:
+
+   <mac-addr> & <mac-addr-mask> == <mac-addr-value>
+
+   where:  <mac-addr-value> is the MAC Address
+                            Value specified in
+                            this control vector
+
+           <mac-addr-mask>  is the MAC Address
+                            Mask specified in
+                            this control vector
+
+   Note 2:  If an individual MAC Address is desired, then <mac-addr-
+   value> should be the individual MAC address and <mac-addr-mask>
+   should be 0xFFFFFFFFFFFF.
+
+   Offset  Length  Value  Contents
+   ------  ------  -----  --------
+      0       1    0x0E   Length of the MAC Address List
+                          structured subfield
+
+      1       1    0x89   key = 0x89  that identifies this as the
+                          MAC Address List structured subfield
+
+     2-7      6           the 6-byte MAC Address Value,
+                          <mac-addr-value> in the above formula
+
+     8-13     6           the 6-byte MAC Address Mask,
+                          <mac-addr-mask> in the above formula
+
+
+
+
+Wells & Bartky                                                 [Page 72]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+7.6.10  NetBIOS Name List (0x8A) Control Vector
+
+   The NetBIOS Name List control vector identifies one or more NetBIOS
+   names that are accessible through the sending Data Link Switch.  This
+   control vector specifies a single NetBIOS name in ASCII.  However,
+   the NetBIOS name can consist of "don't care" and "wildcard"
+   characters to match on a number of NetBIOS names.  If an individual
+   character position in the NetBIOS name in this control vector
+   contains a '?', then the corresponding character position in real
+   NetBIOS name is a "don't care".  If a NetBIOS name in this control
+   vector ends in '*', then the remainder of real NetBIOS names is a
+   "don't care".  '*' is only considered a wildcard if it appears at the
+   end of a name.
+
+   All blanks or nulls at the end of NetBIOS names in this control
+   vector are ignored.   NetBIOS names which have fewer than 16 bytes
+   and which do not end with  '*' are not assumed to have a trailing
+   '*'; the "wildcard" character must be explicit.
+
+   NetBIOS group names can exist across several LANs/networks.  As such,
+   NetBIOS  group names received in a NetBIOS Name List Control Vector
+   can not be treated the same as NetBIOS individual names.  The
+   Individual/Group Flag allows Data  Link Switches to distinguish
+   between the two.
+
+   This control vector is optional and can be repeated if necessary.
+
+   Offset  Length  Value  Contents
+   ------  ------  -----  --------
+      0       1    0xn    Length of the NetBIOS Name List
+                          structured subfield (maximum = 0x13)
+
+      1       1    0x8A   key = 0x8A  that identifies this as the
+                          NetBIOS Name List structured subfield
+
+      2       1           Individual/Group Flag
+                            0x00 - Individual NetBIOS Name
+                            0x01 - Group NetBIOS Name
+
+     3-n     n-3          the NetBIOS name with possible embedded
+                          '?' and terminating '*'.
+
+7.6.11  Vendor Context (0x8B) Control Vector
+
+   The Vendor Context control vector identifies the manufacturer's IEEE
+   assigned Organizationally Unique Identifier (OUI) of the Data Link
+   Switch sending the DLSw Capabilities Exchange.  The OUI is sent in
+   non-canonical (Token-Ring) format.
+
+
+
+Wells & Bartky                                                 [Page 73]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+   This control vector is optional and is used to provide the context
+   for any Vendor Specific control vectors that follow in the
+   Capabilities Exchange.  If there are multiple instances of the Vendor
+   Context control vector, the specified context remains in effect for
+   all Vendor Specific control vectors until the next Vendor Context
+   control vector is encountered.
+
+      Offset  Length  Value  Contents
+      ------  ------  -----  --------
+         0       1    0x05   Length of the Vendor Context structured
+                             subfield
+
+         1       1    0x8B   key = 0x8B  that identifies this as the
+                             Vendor Context structured subfield
+
+        2-4      3           the 3-byte Organizationally Unique
+                             Identifier (OUI) for the vendor
+                             (non-canonical format)
+
+7.7  Capabilities Exchange Responses
+
+   There are two kinds of DLSw Capabilities Exchange Responses: positive
+   and negative.  A positive response is returned to the sending Data
+   Link Switch if there were no errors encountered in the DLSw
+   Capabilities Exchange Request.  A negative response is returned if
+   there is at least one error encountered.
+
+   A positive DLSw Capabilities Exchange Response has the following
+   overall format:
+
+   +----+----+
+   | LL | ID |
+   +----+----+
+
+   0-1    Length, in binary, of the DLSw Capabilities
+          Exchange Response GDS Variable.  The value of
+          LL in this case is 0x0004.
+
+   2-3    GDS Id: 0x1521
+
+   A negative DLSw Capabilities Exchange Response has the following
+   overall format:
+
+   +----+----+--------+--------+
+   | LL | ID | Offset | Reason |
+   +----+----+--------+--------+
+
+
+
+
+
+Wells & Bartky                                                 [Page 74]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+   0-1    Length, in binary, of the DLSw Capabilities Exchange
+          Response GDS Variable.  The value of LL is the sum of
+          the length of all fields in the GDS Variable (i.e.,
+          length of LL + length of ID + length of Offsets/Reasons).
+
+   2-3    GDS Id: 0x1522
+
+   4-5    Offset into the DLSw Capabilities Exchange Request of the
+          error.  Offset should always point to the start of the
+          GDS Variable or a specific control vector.
+
+   6-7    Reason code that uniquely identifies the error.  Specific
+          values for the reason code are:
+
+            0x0001        invalid GDS length for a DLSw Capabilities
+                          Exchange Request.  (The value of Offset
+                          is ignored.)
+
+            0x0002        invalid GDS id for a DLSw Capabilities
+                          Exchange Request.  (The value of Offset
+                          is ignored.)
+
+            0x0003        Vendor Id control vector is missing.  (The
+                          value of Offset is ignored.)
+
+            0x0004        DLSw Version control vector is missing. (The
+                          value of Offset is ignored.)
+
+            0x0005        Initial Pacing Window control vector is
+                          missing.  (The value of Offset is ignored.)
+
+            0x0006        length of control vectors doesn't correlate
+                          to the length of the GDS variable
+
+            0x0007        invalid control vector id
+
+            0x0008        length of control vector invalid
+
+            0x0009        invalid control vector data value
+
+            0x000A        duplicate control vector (for non-repeating
+                          control vectors)
+
+            0x000B        out-of-sequence control vector (for
+                          repeating control vector)
+
+            0x000C        DLSw Supported SAP List control vector is
+                          missing.
+
+
+
+Wells & Bartky                                                 [Page 75]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+                          (The value of Offset is ignored.)
+
+   Note:  Multiple Offset, Reason pairs can be returned with one pair
+   for each error encountered.
+
+8.  Pacing/Flow Control
+
+   This section describes the required Pacing and Flow Control
+   mechanisms used by a Data Link Switch.
+
+   While it is beyond the scope of this document to specify a policy for
+   how an implementation maps SSP flow control to the native data link
+   flow control at the edges, the following paragraphs describe a
+   general philosophical overview of how the mechanism is to be applied.
+
+   There are two types of flows which are covered by the flow control
+   mechanism: connection-oriented and connectionless.  In the first,
+   connection-oriented flows, the implementer is to map the native flow
+   control mechanism of the two data links at the boundaries to the SSP
+   flow control mechanism thus presenting an end-to-end flow control
+   mechanism which "pushes back" all the way to the originating station
+   in either direction.
+
+   However, in the case of connectionless traffic, this is not possible
+   at the data link level because there is no native flow control
+   mechanism for connectionless data links.  At first glance it is
+   tempting to allow connectionless traffic to flow the DLSw cloud
+   unthrottled.  However, the rationale for subjecting these flows to
+   flow control within the DLSw cloud is to "push" the discarding of
+   frames (should this become necessary) back to the ingress of the DLSw
+   cloud.  This "early discarding" of excessive DATAGRAMs should allow
+   the cloud to remain deterministic without wasting network bandwidth.
+
+8.1  Basic Overview
+
+   Each circuit consists of two data flows, one in each direction.  Each
+   data flow has its own independent flow control mechanism.  For each
+   data flow there is an entity that originates traffic, referred to as
+   the sender, and a target entity which receives the traffic, referred
+   to as the receiver.
+
+   A sender may only send data when its receiver has granted explicit
+   permission to send a discrete number of data units.  Data units are
+   defined as either a DGRMFRAME or an INFOFRAME.
+
+   The receiver grants permission to send data units by sending a Flow
+   Control Indicator (FCIND- defined later).  The sender must
+   acknowledge all FCINDs by sending a Flow Control Acknowledgment
+
+
+
+Wells & Bartky                                                 [Page 76]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+   (FCACK- defined later).
+
+   A sending implementation must maintain these values:
+
+   1. GrantedUnits - The number of units (frames) which the sender
+      currently has permission to send.
+
+   2. CurrentWindow - This is a discrete number of units, controlled by
+      the receiver, which is basis for granting additional units.
+
+   3. InitialWindowSize - Global for all circuits on a transport
+      connection.  Learned in capabilities exchange when the transport
+      connection is established.  It specifies an initial value for
+      CurrentWindow when each circuit is established.
+
+   A receiving implementation must maintain these values:
+
+   1. CurrentWindow - This is a discrete number of units, controlled by
+      the receiver, which is basis for granting additional units.
+
+   2. InitialWindowSize - Global for all circuits on a transport
+      connection.  Sent in capabilities exchange when the transport
+      connection is established.  It specifies an initial value for
+      CurrentWindow when each circuit is established.
+
+   3. FCACKOwed - The sender owes an FCACK.  If true, no FCIND may be
+      sent.
+
+8.2  Frame Format
+
+   The Flow control Byte is contained at offset 15 in both the
+   Information and Control SSP messages.  From a flow control
+   perspective, the flow control information in the two frames are
+   handled identically.
+
+   The following diagram describes the format of the Flow Control Byte
+   (Bit 7 is the most significant and Bit 0 is the Least significant bit
+   of the octet):
+
+      bit   7   6   5   4   3   2   1   0
+          +---+---+---+---+---+---+---+---+
+          |FCI|FCA| reserved  |    FCO    |
+          +---+---+---+---+---+---+---+---+
+
+      FCI : Flow Control Indicator
+      FCA : Flow Control Ack
+      FCO : Flow Control Operator Bits
+
+
+
+
+Wells & Bartky                                                 [Page 77]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+            000 - Repeat Window Operator
+            001 - Increment Window Operator
+            010 - Decrement Window Operator
+            011 - Reset Window Operator
+            100 - Halve Window Operator
+            101 - Reserved
+            110 - Reserved
+            111 - Reserved
+
+   A frame with the FCI bit set is referred to as a Flow Control
+   Indication (FCIND).  An FCIND is used to manage the flow in the
+   opposite direction of the frame which bears it.
+
+   A frame with the FCA bit set is referred to as a Flow Control
+   Acknowledgment (FCACK).  An FCACK is used to manage the flow in the
+   same direction of the frame which bears it.
+
+   NOTE:  A frame may be both a FCIND and an FCACK.
+
+   A frame bearing an FCIND or FCACK may also contain data for the flow
+   in the direction it is traveling.  In such a frame, the FCIND or
+   FCACK are said to be piggy-backed.  A non-piggy-backed FCIND is
+   called an Independent Flow Control Indication (IFCIND) and a non-
+   piggy-backed FCACK is called an Independent Flow Control
+   Acknowledgment (IFCACK). IFCIND and IFCACK messages are sent in a
+   Independent Flow Control SSP message (type 0x21).
+
+   NOTE:  A frame may be both an IFCIND and an IFCACK.
+
+   It is desirable to carry information in control messages so as to
+   reduce the need to send a flow control only message.  The diagram
+   below shows the messages that may carry valid flow control
+   information:
+
+ ======                            ___                           ======
+ |    |        ---------        __/   \__       ---------        |    |
+ |    |      __|  _|_  |__     /   IP    \    __|  _|_  |__      |    |
+ ======        |   |   |      <  Network  >     |   |   |        ======
+/______\       ---------       \__     __/      ---------       /______\
+ Origin       Origin DLSw         \___/        Target DLSw      Target
+ Station        partner                          partner        Station
+
+   May have valid
+    FCI/FCA/FCO    Data carrying
+
+         N             N          CANUREACH_cs
+                                  ----------->
+         Y*            N            ICANREACH_cs
+
+
+
+Wells & Bartky                                                 [Page 78]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+                                    <-----------
+         Y             N          REACH_ACK
+                                  ----------->
+         Y             Y            XIDFRAMEs
+                                  <------------>
+         Y             Y            DGRMFRAMEs
+                                  <------------>
+         Y             N          CONTACT
+                                  ----------->
+         Y             N               CONTACTED
+                                    <-----------
+         Y             Y             INFOFRAMEs
+                                  <------------>
+         Y             N          RESTART_DL
+                                  ----------->
+         Y             N               DL_RESTARTED
+                                    <-----------
+         Y             N          CONTACT
+                                  ----------->
+         Y             N               CONTACTED
+                                    <-----------
+         N             N          HALT_DL
+                                  ----------->
+         N             N               DL_HALTED
+                                    <-----------
+
+   *Note: ICANREACH_cs cannot carry FCA, as there could not be an
+   outstanding FCI.
+
+8.3  Granting Permission to Send Data
+
+   A receiver grants a sender permission to send units of data by
+   sending FCIND.  Each FCIND is further qualified by a flow control
+   operator, which is encoded in the FCO bits of the FCIND header. With
+   one exception (the Reset Window operator) all operators may be either
+   piggy-backed or carried in a IFCIND.
+
+   The five flow control operators are outlined below:
+
+8.3.1  Repeat Window Operator
+
+   This operator is processed as follows:
+
+           (CurrentWindow unchanged)
+           GrantedUnits += CurrentWindow
+
+
+
+
+
+
+Wells & Bartky                                                 [Page 79]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+8.3.2  Increment Window Operator
+
+   This operator is processed as follows:
+
+           CurrentWindow++
+           GrantedUnits += CurrentWindow
+
+8.3.3  Decrement Window Operator
+
+   This operator is processed as follows:
+
+           CurrentWindow--
+           GrantedUnits += CurrentWindow
+
+   NOTE:  This operator may only be sent if CurrentWindow is greater
+   than one.
+
+8.3.4  Reset Window Operator
+
+   This operator is processed as follows:
+
+           CurrentWindow = 0;
+           GrantedUnits  = 0;
+
+   NOTE:  This operator may only flow on an independent pacing
+   indication (may NOT be piggy-backed).
+
+   NOTE:  After sending this operator, the only legal subsequent
+   operator is Increment Window.
+
+8.3.5  Halve Window Operator
+
+   This operator shall be processed as follows:
+
+           IF CurrentWindow > 1 THEN
+               CurrentWindow = CurrentWindow / 2
+           ENDIF
+           GrantedUnits += CurrentWindow
+
+   Note:  The divide by two operation is an unsigned integer divide
+   (round down) or bit shift right operation.
+
+8.4  Acknowledging a Flow Control Operator
+
+   Each sender must acknowledge each FCIND with an FCACK which is
+   piggy-backed on the next frame in the opposite direction in all cases
+   except the Reset Window Operator.
+
+
+
+
+Wells & Bartky                                                 [Page 80]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+   The receiver may have no more than one unacknowledged FCIND
+   outstanding at any time with one exception:  A Reset Window Operator
+   may be sent while another FCIND is pending acknowledgment.
+
+   NOTE: The FCI and FCO bits of the FCACK are used independently by the
+   flow in the opposite direction
+
+8.4.1  Acknowledging a Reset Window Operator
+
+   Since this operator revokes all previously granted units, the sender
+   must acknowledge this FCIND using an IFCACK (Independent Flow Control
+   Acknowledgment).  This is the only case where IFCACK is used.
+
+   Should a sender receive a non-reset FCIND followed by a Reset Window
+   FCIND before acknowledging the first, it only acknowledges the Reset
+   Window.
+
+   NOTE: The FCI and FCO bits on these frames are used independently by
+   the flow in the opposite direction.
+
+8.5  Capabilities Exchange Initial Window Size
+
+   When two nodes establish a transport connection, they engage in a
+   capabilities exchange (this is a requirement).  Refer to the
+   Capabilities Exchange section 7 for further details.  The two nodes
+   are required to exchange the following parameter:
+
+   InitialWindowSize -  This indicates to the partner what
+                        the sending flow entity initializes
+                        its CurrentWindow value to for each
+                        multiplexed circuit subsequently
+                        established on that transport
+                        connection.  This value must be
+                        non-zero.
+
+8.6  Circuit Startup
+
+   Process as follows:
+
+          CurrentWindow = InitialWindowSize
+          GrantedUnits  = 0
+
+   NOTE: The InitialWindow Size variable has a scope of one per DLSw
+   transport connection, while CurrentWindow and Granted units are
+   maintained on a per circuit basis.  At circuit startup, a sender may
+   not send data units until the receiver grants explicit permission
+   with an FCIND message.  This grant may be an independent FCIND
+   message or the FCIND may be piggy-backed on any of the message types
+
+
+
+Wells & Bartky                                                 [Page 81]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+   listed in section 8.2.
+
+8.7  Example Receiving Implementations
+
+   The following two examples illustrate receiving implementations of
+   varying degrees of complexity.  These are not meant to be complete
+   implementations but rather serve to illustrate the protocol.
+
+   NOTE: The examples are independent of the buffering model ( buffers
+   may be deterministicly or statistically committed)
+
+   NOTE: The examples assume a process model where each event processes
+   to completion without being preempted by another event.
+
+8.7.1  Fixed Pacing Example
+
+   Consider the following variables, in addition to InitialWindowSize
+   and CurrentWindow and FCACKOwed:
+
+          GrantDelayed     - Boolean
+          GrantedUnits     - Outstanding Units
+
+   The following section describes how various events are processed in
+   this example implementation:
+
+8.7.1.1  Circuit Startup
+
+          CurrentWindow    = InitialWindowSize
+          FCACKOwed        = FALSE
+          GrantDelayed     = FALSE
+          GrantedUnits     = 0
+          Repeat Window Operator
+
+8.7.1.2  Check Buffers Available
+
+   Can my implementation afford to grant CurrentWindow just now?
+
+8.7.1.3  Buffers Become Available
+
+          IF Check Buffers Available THEN
+             Send FCIND( Repeat Window)
+             GrantDelayed = FALSE
+          ELSE
+             Wait on buffers to become available (LIFO)
+          ENDIF
+
+
+
+
+
+
+Wells & Bartky                                                 [Page 82]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+8.7.1.4  Repeat Window Operator
+
+          IF Check Buffers Available THEN
+              Send FCIND( Repeat Window)
+          ELSE
+             GrantDelayed = TRUE
+             Wait on buffers to become available (FIFO)
+          ENDIF
+
+8.7.1.5  Send FCIND( operator)
+
+          GrantedUnits += CurrentWindow
+          FCACKOwed     = TRUE
+          Encode and Transmit FCIND piggybacked or as IFCIND
+
+8.7.1.6  A Frame Arrives from Sender
+
+          GrantedUnits--;
+          IF frame is FCACK THEN
+             IF FCACKOwed THEN
+                FCACKOwed = FALSE
+             ELSE
+                Protocol Violation
+             ENDIF
+          ENDIF
+          IF NOT GrantDelayed THEN
+             IF GrantedUnits <= CurrentWindow THEN
+                 IF FCACKOwed THEN
+                   Protocol Violation
+                 ELSE
+                   Repeat Window Operator
+                 ENDIF
+             ENDIF
+          ENDIF
+
+8.7.2  Adaptive Pacing Example
+
+   The following example illustrates a receiving implementation that
+   adjusts the window size and granted units based on buffer
+   availability and transport utilization.
+
+   NOTE: This example ignores other factors which might compel the
+   receiving implementation to adjust the window size (i.e., Outbound
+   queue length, traffic priority, ...)
+
+   Consider the following variables, in addition to InitialWindowSize,
+   CurrentWindow and FCACKOwed:
+
+
+
+
+Wells & Bartky                                                 [Page 83]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+          GrantDelayed     - Boolean
+          GrantedUnits     - Outstanding Units
+
+8.7.2.1  Circuit Startup
+
+          CurrentWindow    = InitialWindowSize
+          FCACK            = FALSE
+          GrantDelayed     = FALSE
+          GrantedUnits     = 0
+          Repeat Window Operator
+
+8.7.2.2  Check Buffers Available ( X)
+
+           Can my implementation afford to grant X units just now?
+
+8.7.2.3  Buffers Become Available
+
+          IF Check Buffers Available THEN
+             CurrentWindow--;
+             Send FCIND( Decrement Window)
+             GrantDelayed = FALSE
+          ELSE
+             Wait on buffers to become available (LIFO)
+          ENDIF
+
+8.7.2.4  Repeat Window Operator
+
+          IF Check Buffers Available (CurrentWindow) THEN
+              Send FCIND( Repeat Window)
+          ELSE
+             GrantDelayed = TRUE
+             Wait on buffers to become available (FIFO)
+          ENDIF
+
+8.7.2.5  Increment Window Operator
+
+          IF Check Buffers Available ( CurrentWindow + 1) THEN
+              CurrentWindow++
+              Send FCIND( Increment Window)
+          ELSE
+              Repeat Window Operator
+          ENDIF
+
+8.7.2.6  Send FCIND( operator)
+
+          FCACKOwed     = TRUE
+          GrantedUnits += CurrentWindow
+          Encode and Transmit FCIND piggybacked or as IFCIND
+
+
+
+Wells & Bartky                                                 [Page 84]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+8.7.2.7  An FCACK Arrives from Sender
+
+          GrantedUnits--;
+          IF NOT FCACKOwed THEN
+             Protocol Violation
+          ENDIF
+          FCACKOwed = FALSE;
+          IF NOT GrantDelayed THEN
+             IF GrantedUnits < CurrentWindow THEN
+                 Increment Window Operator
+             ELSE IF GrantedUnits == CurrentWindow THEN
+                 Repeat Window Operator
+             END
+          ENDIF
+
+8.7.2.8  A Non-FCACK Frame Arrives from Sender
+
+          GrantedUnits--;
+          IF NOT GrantDelayed THEN
+             IF FCACKOwed THEN
+                IF GrantedUnits < CurrentWindow THEN
+                   Protocol Violation
+                END
+             ELSE
+                IF GrantedUnits <= CurrentWindow THEN
+                   Repeat Window Operator
+                ENDIF
+             ENDIF
+          ENDIF
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wells & Bartky                                                 [Page 85]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+8.8  Adaptive Pacing Example Flow Diagrams
+
+8.8.1  Example Flows from the Above Implementation
+
+   The following diagram illustrates the use of adaptive pacing (use of
+   Halve Window, and Reset operation are shown in subsequent diagrams).
+
+   -----SENDER-----                     ----RECEIVER----
+   Granted   Window                     Window   Granted
+     0         2   circuit established    2         0
+     2         2   <-------- FCIND(Rpt)   2         2
+     1         2   FCACK-------------->   2         1
+     4         3   <-------- FCIND(Inc)   3         4
+     3         3   FCACK-------------->   3         3
+                          +- FCIND(Rpt)   3         6
+     2         3   DATA---|----------->   3         5
+     1         3   DATA---|----------->   3         4
+     4         3   <------+
+     3         3   FCACK-------------->   3         3
+     6         3   <-------- FCIND(Rpt)   3         6
+     5         3   FCACK-------------->   3         5
+     4         3   DATA--------------->   3         4
+     3         3   DATA--------------->   3         3
+                          +- FCIND(Rpt)   3         6
+     2         3   DATA---|----------->   3         5
+     1         3   DATA---|----------->   3         4
+     0         3   DATA---|----------->   3         3
+     3         3   <------+
+     2         3   FCACK-------------->   3         2
+     6         4   <-------- FCIND(Inc)   4         6
+     5         4   FCACK-------------->   4         5
+     4         4   DATA--------------->   4         4
+                                        Waiting on Buffer
+                          +- FCIND(Dec)   3         7
+     3         4   DATA---|----------->   3         6
+     2         4   DATA---|----------->   3         5
+     1         4   DATA---|----------->   3         4
+     0         4   DATA---|----------->   3         3
+     3         3   <------+
+     2         3   FCACK-------------->   3         2
+                                        Waiting on Buffer
+                          +- FCIND(Dec)   2         4
+     1         3   DATA---|----------->   2         3
+     0         3   DATA---|----------->   2         2
+     2         2   <------+
+     1         2   FCACK-------------->   2         1
+     4         3   <-------- FCIND(Inc)   3         4
+     3         3   FCACK-------------->   3         3
+
+
+
+Wells & Bartky                                                 [Page 86]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+     6         3   <-------- FCIND(Rpt)   3         6
+     5         3   FCACK-------------->   3         5
+     4         3   DATA--------------->   3         4
+     3         3   DATA--------------->   3         3
+     6         3   <-------- FCIND(Rpt)   3         6
+
+8.8.2  Example Halve Window Flow
+
+   The following flow illustrates the use of the Halve Window Operator:
+
+      -----SENDER-----                     ----RECEIVER----
+      Granted   Window                     Window   Granted
+        0         2   circuit established    2         0
+        2         2   <-------- FCIND(Rpt)   2         2
+        1         2   FCACK-------------->   2         1
+        4         3   <-------- FCIND(Inc)   3         4
+        3         3   FCACK-------------->   3         3
+                                             Resource Shortage
+        2         3   DATA--------------->   1         2
+        1         3   DATA--------------->   1         1
+        0         3   DATA--------------->   1         0
+        1         1   <-------- FCIND(Hlv)   1         1
+        0         1   FCACK-------------->   1         0
+
+   NOTE: The Halve Window Operator could have been sent before the
+   granted units fell to zero.  The implementer may make a choice based
+   on the severity of the condition.
+
+8.8.3  Example Reset Window Flows
+
+   The following flow diagram illustrates the ResetWindow operation if
+   the receiver has no FCIND outstanding.
+
+   -----SENDER-----                     ----RECEIVER----
+   Granted   Window                     Window   Granted
+     0         2   circuit established    2         0
+     2         2   <-------- FCIND(Rpt)   2         2
+     1         2   FCACK-------------->   2         1
+     4         3   <-------- FCIND(Inc)   3         4
+     3         3   FCACK-------------->   3         3
+                          +- FCIND(Rpt)   3         6
+     2         3   DATA---|----------->   3         5
+     1         3   DATA---|----------->   3         4
+     4         3   <------+
+     3         3   FCACK-------------->   3         3
+     6         3   <-------- FCIND(Rpt)   3         6
+     5         3   FCACK-------------->   3         5
+                                          Resource shortage!
+
+
+
+Wells & Bartky                                                 [Page 87]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+     0         0   <-------- FCIND(Rst)   0         5 (note still
+   committed)
+     0         0   IFCACK------------->   0         0
+                                          Condition eases
+     1         1   <-------- FCIND(Inc)   1         1
+     0         1   FCACK-------------->   1         0
+     2         2   <-------- FCIND(Inc)   2         2
+     1         2   FCACK-------------->   3         4
+
+   The next two flows  illustrate the Reset Window operation if the
+   receiver has an outstanding FCIND.
+
+   -----SENDER-----                     ----RECEIVER----
+   Granted   Window                     Window   Granted
+     0         2   circuit established    2         0
+     2         2   <-------- FCIND(Rpt)   2         2
+     1         2   FCACK-------------->   2         1
+     4         3   <-------- FCIND(Inc)   3         4
+     3         3   FCACK-------------->   3         3
+                          +- FCIND(Rpt)   3         6
+     2         3   DATA---|----------->   3         5
+                          |               Resource shortage!
+                          |+-FCIND(Rst)   0         5
+     1         3   DATA---||---------->   0         4
+     4         3   <------+|
+     3         3   FCACK---+---------->   0         3 (Not IFCACK!)
+     2         3   DATA----|---------->   0         2
+     0         0   <-------+
+     0         0   IFCACK------------->   0         0
+                                          Condition eases
+     1         1   <-------- FCIND(Inc)   1         1
+     0         1   FCACK-------------->   1         0
+     2         2   <-------- FCIND(Inc)   2         2
+     1         2   FCACK-------------->   3         4
+
+   -----SENDER-----                     ----RECEIVER----
+   Granted   Window                     Window   Granted
+     0         2   circuit established    2         0
+     2         2   <-------- FCIND(Rpt)   2         2
+     1         2   FCACK-------------->   2         1
+     4         3   <-------- FCIND(Inc)   3         4
+     3         3   FCACK-------------->   3         3
+                          +- FCIND(Rpt)   3         6
+     2         3   DATA---|----------->   3         5
+                          |               Resource shortage!
+                          |+-FCIND(Rst)   0         5
+     1         3   DATA---||---------->   0         4
+     4         3   <------+|
+
+
+
+Wells & Bartky                                                 [Page 88]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+     0         0   <-------+
+     0         0   IFCACK------------->   0         0
+                                          Condition eases
+     1         1   <-------- FCIND(Inc)   1         1
+     0         1   FCACK-------------->   1         0
+     2         2   <-------- FCIND(Inc)   2         2
+     1         2   FCACK-------------->   3         4
+
+8.9  Other Considerations
+
+8.9.1  Protocol Violations
+
+   The following events are considered protocol violations:
+
+   1. Sender exceeds granted units or does not acknowledge FCIND on
+      first frame after its receipt (the receiver can not discern the
+      difference between the two).
+
+   2. Receiver does not follow a Reset Window Operator with an Increment
+      Window Operator.
+
+   3. Receiver has two unacknowledged FCINDs ( other than Reset Window)
+      outstanding.
+
+   4. Receiver sends Decrement Window Operator with a window size of one.
+
+   5. Receiver attempts to increment the window size beyond 0xFFFF.
+
+   Actions taken in response to protocol violations are left to the
+   implementation of the node which discovers the violation.  If an
+   implementation chooses to take down the circuit on which the
+   violation occurred, HALT_DL is the appropriate action.
+
+Acknowledgments
+
+   Original RFC 1434 Authors:
+
+      Roy C. Dixon, IBM
+      David M. Kushi, IBM
+
+   Chair of APPN Implementers Workshop Data Link Switching Related
+   Interest Group:
+
+      Louise Herndon Wells, Internetworking Technology Institute
+
+
+
+
+
+
+
+Wells & Bartky                                                 [Page 89]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+   Working Group Chairs (and significant contributors to this document):
+
+      Connect/Disconnect (State Machines): Steve Klein, IBM
+      Capabilities Exchange: Wayne Clark, Cisco Systems
+      Flow Control (Adaptive Pacing): Shannon Nix, Metaplex
+      Priority/Class of Service: Gene Cox, IBM
+
+   Other significant contributors:
+
+      Peter Gayek, IBM
+      Paul Brittain, Data Connection Limited
+
+References
+
+   1) ISO 8802-2/IEEE Std 802.2 International Standard, Information
+      Processing Systems, Local Area Networks, Part 2: Logical Link
+      Control, December 31, 1989.
+
+   2) IBM LAN Technical Reference IEEE 802.2 and NETBIOS Application
+      Program Interfaces SC30-3587-00, December 1993.
+
+   3) ISO/IEC DIS 10038 DAM 2, MAC Bridging, Source Routing Supplement,
+      December 1991.
+
+   4) ISO 8802-2/IEEE Std 802.1D International Standard, Information
+      Processing Systems, Local Area Networks, Part 2: MAC layer
+      Bridging.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wells & Bartky                                                 [Page 90]
+
+RFC 1795                  Data Link Switching                 April 1995
+
+
+Security Considerations
+
+   Security issues are not discussed in this memo.
+
+Chair's Address
+
+   Louise Wells
+   Internetwork Technology Institute
+   2021 Stratford Dr.
+   Milpitas, CA  95035
+
+   EMail: lhwells@cup.portal.com
+
+Editor's Address
+
+   Alan K. Bartky
+   Manager of Technology
+   Sync Research Inc.
+   7 Studebaker
+   Irvine, CA 91728-2013
+
+   Phone: 1-714-588-2070
+   EMail: alan@sync.com
+
+
+   Note: Any questions or comments relative to the contents of this RFC
+   should be sent to the following Internet address:
+   aiw-dlsw@networking.raleigh.ibm.com.
+
+   This address will be used to coordinate the handling of responses.
+
+   NOTE 1:  This is a widely subscribed mailing list and messages sent to
+            this address will be sent to all members of the DLSw mailing
+            list.  For specific questions relating to subscribing to the
+            AIW and any of it's working groups send email to:
+            appn@vnet.ibm.com
+
+            Information regarding all of the AIW working groups and the
+            work they are producing can be obtained by copying, via
+            anonymous ftp, the file aiwinfo.psbin or aiwinfo.txt from the
+            Internet host networking.raleigh.ibm.com, located in
+            directory aiw.
+
+   NOTE 2: These mailing lists and addresses are subject to change.
+
+
+
+
+
+
+
+Wells & Bartky                                                 [Page 91]
+