Internet RFC/STD/FYI/BCP Archives
Powered By Arogo.Net Web Hosting
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
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.
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.
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
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.
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
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.
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) |
+- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -|
| |
+- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
| . . |
+-----------------------------+-----------------------------+
| (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)
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.
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
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
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
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
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):
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.
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).
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.
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.
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.
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
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
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
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.
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.
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.
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
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.
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.
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
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.
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
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.
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.
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 |
+----------------------+---------------------+----------------------+
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.
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 |
+----------------------+---------------------+----------------------+
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.
+---------------------------+------------------+--------------------+
| 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.
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.
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
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
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.
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
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.
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 | |
+----------------------+---------------------+----------------------+
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.
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
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
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
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
<------------> <------------> <------------> <------------> <-------->
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 <-