As per Relevance of the word exchange, we have this rfc below:
Network Working Group L. Wells,
Request for Comments: 1795 Internetwork Technology
Obsoletes: 1434 A. Bartky,
Category: Informational Sync Research, Inc
April 1995
Data Link Switching: Switch-to-Switch
AIW DLSw RIG: DLSw Closed Pages, DLSw Standard Version 1.0
Status of this
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
This RFC describes use of Data Link Switching over TCP/IP. The RFC
being distributed to members of the Internet community in order
solicit their reactions to the proposals contained in it. While
issues discussed may not be directly relevant to the
problems of the Internet, they may be interesting to a number
researchers and Implementers
This RFC was created as a joint effort of the Advanced Peer-to-
Networking (APPN) Implementers Workshop (AIW) Data Link
(DLSw) Related Interest Group (RIG). The APPN Implementers
is a group sponsored by IBM and consists of representatives of
companies implementing current and future IBM
interoperable products. The DLSw Related Interest Group was formed
this forum in order to produce a single version of the Switch
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
and features
This document is based on RFC 1434. This document
significant changes to RFC 1434 and therefore obsoletes
document
Any questions or comments relative to the contents of this RFC
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
this address will be sent to all members of the DLSw mailing list
For specific questions relating to subscribing to the AIW and any
Wells & Bartky [Page 1]
RFC 1795 Data Link Switching April 1995
it's working groups send email to: appn@vnet.ibm.
Information regarding all of the AIW working groups and the work
are producing can be obtained by copying, via anonymous ftp, the
aiwinfo.psbin or aiwinfo.txt from the Internet
networking.raleigh.ibm.com, located in directory aiw
NOTE 2: These mailing lists and addresses are subject to change
1.
Data Link Switching (DLSw) is a forwarding mechanism for the IBM
(Systems Network Architecture) and IBM NetBIOS (Network Basic
Output Services) protocols. This memo documents the Switch-to-
Protocol (SSP) that is used between Data Link Switches.
protocol does not provide full routing, but instead
switching at the SNA Data Link layer (i.e., layer 2 in the
architecture) and encapsulation in TCP/IP for transport over
Internet. This RFC documents the frame formats and protocols
multiplexing data between Data Link Switches. The
implementation of SSP uses TCP as the reliable transport between
Link Switches. However, other transport connections such as OSI TP
could be used in the future
A Data Link Switch (abbreviated also as DLSw in this document)
support SNA (Physical Unit (PU) 2, PU 2.1 and PU 4) systems
optionally NetBIOS systems attached to IEEE 802.2 compliant
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
LAN appearance within the Data Link Switch (each SDLC PU is
to the SSP protocol as a unique MAC/SAP address pair). For
Token-Ring LAN attached systems, the Data Link Switch appears as
source-routing bridge. Token-Ring Remote systems that are
through the Data Link Switch appear as systems attached to
adjacent ring. This ring is a virtual ring that is manifested
each Data Link Switch
1.1 Backwards Compatibility with RFC 1434
This document defines significant changes to RFC 1434 and does
state details on how to interoperate with RFC 1434 or "enhanced
implementations (e.g., those that added enter and exit busy
control). It is up to the implementer to refer to RFC 1434 and/
any other vendor's documentation in order to interoperate with
given vendor's implementation, if interoperability with pre-AIW
RIG standards is desired
Wells & Bartky [Page 2]
RFC 1795 Data Link Switching April 1995
2.
Data Link Switching was developed to provide support for SNA
NetBIOS in multi-protocol routers. Since SNA and NetBIOS
basically connection oriented protocols, the Data Link
procedure that they use on the LAN is IEEE 802.2 Logical Link
(LLC) Type 2. Data Link Switching also accommodates SNA
over WAN (Wide Area Network) links via the SDLC protocol
IEEE 802.2 LLC Type 2 was designed with the assumption that
network transit delay would be predictable (i.e., a local LAN).
Therefore the LLC Type 2 elements of procedure use a fixed timer
detecting lost frames. When remote bridging is used over wide
lines (especially at lower speeds), the network delay is larger
it can vary greatly based upon congestion. When the delay
the time-out value LLC Type 2 attempts to retransmit. If the
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
eventually taken down if the delay exceeds the T1 timer times N
retry count
Given the use of LLC Type 2 services, Data Link Switching
the following bridging problems
DLC Time-
DLC Acknowledgments over the
Flow and Congestion
Broadcast Control of Search
Source-Route Bridging Hop Count
NetBIOS also makes extensive use of datagram services that
connectionless LLC Type 1 service. In this case, Data Link
addresses the last two problems in the above list
The principal difference between Data Link Switching and bridging
that for connection-oriented data DLSw terminates the Data Link
whereas bridging does not. The following figure illustrates
difference based upon two end systems operating with LLC Type 2
services
Wells & Bartky [Page 3]
RFC 1795 Data Link Switching April 1995
--------
Bridge
+------+ +----+ +----+ +------+
| End | +-----+ | +-----/ | | +-----+ | End |
|System+-+ LAN +-+ | /------+ +-+ LAN +-+System
| | +-----+ | | TCP/IP | | +-----+ | |
+------+ +----+ +----+ +------+
Info----------------------------------------------->
<-----------------------------------------------
Data Link
-------------------
+------+ +----+ +----+ +------+
| End | +-----+ | +-----/ | | +-----+ | End |
|System+-+ LAN +-+DLSw| /------+DLSw+-+ LAN +-+System
| | +-----+ | | TCP/IP | | +-----+ | |
+------+ +----+ +----+ +------+
Info---------------> ------------->
<---------------RR ------------>
<------------
In traditional bridging, the Data Link Control is end-to-end.
Link Switching terminates the LLC Type 2 connection at the switch
This means that the LLC Type 2 connections do not cross the wide
network. The DLSw multiplexes LLC connections onto a TCP
to another DLSw. Therefore, the LLC connections at each end
totally independent of each other. It is the responsibility of
Data Link Switch to deliver frames that it has received from a
connection to the other end. TCP is used between the Data
Switches to guarantee delivery of frames
As a result of this design, LLC time-outs are limited to the
LAN (i.e., they do not traverse the wide area). Also, the LLC Type 2
acknowledgments (RR's) do not traverse the WAN, thereby
traffic across the wide area links. For SDLC links, polling and
response occurs locally, not over the WAN. Broadcast of
frames is controlled by the Data Link Switches once the location of
target system is discovered. Finally, the switches can now
back pressure to the end systems to provide flow and
control
Only one copy of an Link Protocol Data Unit (LPDU) is sent
Data Link Switches in SSP messages (XIDFRAME and INFOFRAME).
of the LPDU are absorbed by Data Link Switch that receives it.
Wells & Bartky [Page 4]
RFC 1795 Data Link Switching April 1995
Data Link Switch that transmits the LPDU received in an SSP
to a local DLC, will perform retries in a manner appropriate for
local DLC. This may involve running a reply timer and maintaining
poll retry count. The length of the timer and the number of
is an implementation choice based on user configuration
and the DLC type
Data Link Switching uses LAN addressing to set up connections
SNA systems. SDLC attached devices are defined with MAC and
addresses to enable them to communicate with LAN attached devices
For NetBIOS systems, Data Link Switching uses the NetBIOS name
forward datagrams and to set up connections for NetBIOS sessions
For LLC type 2 connection establishment, SNA systems send TEST (or
some cases, XID) frames to the null (0x00) SAP. NetBIOS systems
an address resolution procedure, based upon the Name Query and
Recognized frames, that is used to establish an end-to-end circuit
Since Data Link Switching may be implemented in multi-
routers, there may be situations where both bridging and
are enabled. SNA frames can be identified by their link SAP.
SAP values for SNA are 0x04, 0x08, and 0x0C. NetBIOS always uses
link SAP value of 0xF0.
Wells & Bartky [Page 5]
RFC 1795 Data Link Switching April 1995
3. Transport
Data Link Switches can be in used in pairs or by themselves
A Single DLSw internally switches one data link to another
using TCP (DLC(1) to DLC(2) in the figure below). This RFC does
go into details on how to implement this feature and it is not
requirement to support this RFC
A paired DLSw multiplexes data links over a reliable transport
a Switch-to-Switch Protocol (SSP).
+-------------------------------------------+Switch-to-
| DLC Interfaces | Protocol (SSP
|+-----------+ DLC Request +-----------+ |
|| Data |<---------------| | |Send SSP
|| Link | DLC Indication | | |-------------->
|| Control 1 |--------------->| | |
|+-----------+ | Data Link | |
|+-----------+ DLC Request | Switch | |
|| Data |<-------------- | | |Rec. SSP
|| Link | DLC Indication | | |<-------------
|| Control 2 | -------------->| | |
|+-----------+ +-----------+ |
| Multi-Protocol Router |
+-------------------------------------------+
Before Data Link Switching can occur between two routers, they
establish two TCP connections between them. Each Data Link
will maintain a list of DLSw capable routers and their
(active/inactive). After the TCP connection is established,
messages are exchanged to establish the capabilities of the two
Link Switches. Once the exchange is complete, the DLSw will
SSP control messages to establish end-to-end circuits over
transport connection. Within the transport connection, DLSw
messages are exchanged. The message formats and types for these
messages are documented in the following sections
The default parameters associated with the TCP connections
Data Link Switches are as follows
Socket Family AF_INET (Internet protocols
Socket Type SOCK_STREAM (stream socket
Read Port Number 2065
Write Port Number 2067
Wells & Bartky [Page 6]
RFC 1795 Data Link Switching April 1995
Two or more Data Link Switches may be attached to the same LAN
consisting of a number of token-ring segments interconnected
source-routing bridges. In this case, a TCP connection is
defined between bridges attached to the same LAN. This will
using systems to select one of the possible Data Link Switches in
similar manner to the selection of a bridge path through a source
routed bridged network. The virtual ring segment in each Data
Switch attached to a common LAN must be configured with the same
number. This will prevent LAN frames sent by one Data Link
from being propagated through the other Data Link Switches
Wells & Bartky [Page 7]
RFC 1795 Data Link Switching April 1995
3.1 SSP Frame
The following diagrams show the two message header formats
between Data Link Switches, Control and Information. The
message header is used for all messages except Information
(INFOFRAME) and Independent Flow Control Messages (IFCM), which
sent in Information header format. The INFOFRAME, KEEPALIVE and
message headers are 16 bytes long, and the control message header
72 bytes long. The fields in the first sixteen bytes of all
headers are the same
CONTROL MESSAGES (72 Bytes
(zero based offsets below shown in decimal (xx) )
+-----------------------------+-----------------------------+
| (00) Version Number | (01) Header Length (= 72) |
+-----------------------------+-----------------------------+
| (02) Message Length |
+-----------------------------+-----------------------------+
| (04) Remote Data Link Correlator |
+- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
| |
+-----------------------------+-----------------------------+
| (08) Remote DLC Port ID |
+- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
| |
+-----------------------------+-----------------------------+
| (12) Reserved Field |
+-----------------------------+-----------------------------+
| (14) Message Type | (15) Flow Control Byte |
+-----------------------------+-----------------------------+
| (16) Protocol ID | (17) Header Number |
+-----------------------------+-----------------------------+
| (18) Reserved |
+-----------------------------+-----------------------------+
| (20) Largest Frame Size | (21) SSP Flags |
+-----------------------------+-----------------------------+
| (22) Circuit Priority | (23) Message Type (see note)|
+-----------------------------+-----------------------------+
| (24) Target MAC Address (non-canonical format) |
+- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -|
| |
+- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
| |
+-----------------------------+-----------------------------+
| (30) Origin MAC Address (non-canonical format) |
+- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -|
Wells & Bartky [Page 8]
RFC 1795 Data Link Switching April 1995
| |
+- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
| . . |
+-----------------------------+-----------------------------+
| (36) Origin Link SAP | (37) Target Link SAP |
+-----------------------------+-----------------------------+
| (38) Frame Direction | (39) Reserved |
+-----------------------------+-----------------------------+
| (40) Reserved |
+-----------------------------+-----------------------------+
| (42) DLC Header Length |
+-----------------------------+-----------------------------+
| (44) Origin DLC Port ID |
+- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
| |
+-----------------------------+-----------------------------+
| (48) Origin Data Link Correlator |
+- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
| |
+-----------------------------+-----------------------------+
| (52) Origin Transport ID |
+- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
| |
+-----------------------------+-----------------------------+
| (56) Target DLC Port ID |
+- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
| |
+-----------------------------+-----------------------------+
| (60) Target Data Link Correlator |
+- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
| |
+-----------------------------+-----------------------------+
| (64) Target Transport ID |
+- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
| |
+-----------------------------+-----------------------------+
| (68) Reserved Field |
+-----------------------------+-----------------------------+
| (70) Reserved Field |
+-----------------------------+-----------------------------+
(Even Byte) (Odd Byte
Wells & Bartky [Page 9]
RFC 1795 Data Link Switching April 1995
INFORMATION MESSAGE (16 Bytes
+-----------------------------+-----------------------------+
| (00) Version Number | (01) Header Length (= 16) |
+-----------------------------+-----------------------------+
| (02) Message Length |
+-----------------------------+-----------------------------+
| (04) Remote Data Link Correlator |
+- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
| |
+-----------------------------+-----------------------------+
| (08) Remote DLC Port ID |
+- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
| |
+-----------------------------+-----------------------------+
| (12) Reserved Field |
+-----------------------------+-----------------------------+
| (14) Message Type | (15) Flow Control Byte |
+-----------------------------+-----------------------------+
(Even Byte) (Odd Byte
The first sixteen bytes of control and information message
contain identical fields. A brief description of some of the
in an SSP message are shown below (if not defined below, the
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
version 1.
The Header Length field (offset 1) is 0x48 for control messages
indicating a decimal value of 72 bytes, and 0x10 for information
Independent Flow Control messages, indicating a decimal value of 16
bytes
The Message Length field (offset 2) defines the number of
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
one
The Circuit Priority field (offset 22) is described in section 4.
The Frame Direction field (offset 38) is set to 0x01 for frames
from the origin DLSw to the target DLSw, and is set to 0x02
frames sent from the target DLSw to the origin DLSw
Wells & Bartky [Page 10]
RFC 1795 Data Link Switching April 1995
Note: The Remote Data Link Correlator and Remote DLC Port ID are
equal to the Target Data Link Correlator and Target DLC Port ID
the Frame Direction field is set to 0x01, and are set equal to
Origin Data Link Correlator and Origin DLC Port ID if the
Field is set to 0x02.
The Protocol ID field is set to 0x42, indicating a decimal value
66.
The DLC Header Length is set to zero for SNA and is set to 0x23
NetBIOS datagrams, indicating a length of 35 bytes. This
the Access Control (AC) field, the Frame Control (FC) field
Destination MAC Address (DA), the Source MAC Address (SA),
Routing Information (RI) field (padded to 18 bytes), the
link SAP (DSAP), the Source link SAP (SSAP), and the LLC
field (UI).
NOTE: The values for the Message Type field are defined in
3.5. Note that this value is specified in two different
(offset 14 and 23 decimal) of the control message header. Only
first field is to be used when parsing a received SSP message.
second field is to be ignored by new implementations on reception
The second field was left in for backwards compatibility with
1434 implementations and this field may be used in future versions
needed
The SSP Flags field contains additional information related to
SSP message. The flags are defined as follows (bit 7 being the
significant bit and bit 0 the least significant bit of the octet):
Bit(s
76543210 Name
--------- ----- -------
x....... SSPex 1 = explorer message (CANUREACH and ICANREACH
Reserved fields are set to zero upon transmission and should
ignored upon receipt
3.2 Address
A data link is defined as a logical association between the two
stations using Data Link Switching. It is identified by a Data
ID (14 bytes) consisting of the pair of attachment
associated with each end system. Each attachment address
represented by the concatenation of the MAC address (6 bytes) and
LLC address (1 byte). Each attachment address is classified
either "Target" in the context of the Destination MAC/SAP
of an explorer frame sent in the first frame used to establish
Wells & Bartky [Page 11]
RFC 1795 Data Link Switching April 1995
circuit, or "Origin" in the context of the Source MAC/SAP addresses
All MAC addresses are expressed in non-canonical (Token-Ring) format
DATA LINK ID (14 Bytes @ Control message offset 24 decimal
+-----------------------------+-----------------------------+
| Target MAC Address |
+- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
| |
+- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
| |
+-----------------------------+-----------------------------+
| Origin MAC Address |
+- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
| |
+- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
| |
+-----------------------------+-----------------------------+
| Origin Link SAP | Target Link SAP |
+-----------------------------+-----------------------------+
An end-to-end circuit is identified by a pair of Circuit ID's.
Circuit ID is a 64 bit number that identifies the DLC circuit
a single DLSw. It consists of a DLC Port ID (4 bytes), and a
Link Correlator (4 bytes). The Circuit ID must be unique in a
DLSw and is assigned locally. The pair of Circuit ID's along
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
local end of the circuit and the other for the remote end of
circuit. In order to identify which Data Link Switch originated
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
message header are used to identify the individual TCP/IP port on
Data Link Switch. The values have only local significance. However
each Data Link Switch is required to reflect the values contained
Wells & Bartky [Page 12]
RFC 1795 Data Link Switching April 1995
these two fields, along with the associated values for DLC Port
and the Data Link Correlator, when returning a message to the
Data Link Switch
The following figure shows the use of the addressing
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
end stations. The CANUREACH and ICANREACH messages are qualified
the SSPex flag into CANUREACH_ex, ICANREACH_ex (explorer messages
and CANUREACH_cs, ICANREACH_cs (circuit start). The CANUREACH_ex
used to find a remote MAC and Link SAP address without
an SSP circuit. Upon receipt of a CANUREACH_cs message, the
DLSw starts a data link for each port, thereby obtaining a Data
Correlator. If the target station can be reached, an ICANREACH_
message is returned to the origin DLSw containing the Target
ID parameter. Upon receipt, the origin DLSw starts a data link
returns the Origin Circuit ID to the target DLSw within the REACH_
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
along with the DATA LINK ID parameter. Once the connection has
Wells & Bartky [Page 13]
RFC 1795 Data Link Switching April 1995
established, the INFOFRAME messages are exchanged with the
header. This header contains only the Circuit ID associated with
remote DLSw. The Remote Data Link Correlator and the Remote DLC
ID are set equal to the Data Link Correlator and the DLC Port ID
are associated with the origin or target Data Link Switch,
upon the direction of the packet
3.3
The local use, and contents of the Data Link Correlator, Port ID
Transport ID fields in SSP messages is an implementation choice
These fields have local significance only. The values received
a partner DLSw must not be interpreted by the DLSw that receives
and should be echoed "as is" to a partner DLSw in
messages. All implementations must obey the following rules in
section (3.3) on the assignment and fixing of these correlator
for each transport connection or circuit
The Transport ID fields are learned from the first SSP
exchanged with a DLSw partner (the Capabilities exchange).
field should not be varied by a DLSw after the capabilities
and must be reflected to the partner DLSw in every SSP
message
The Target Data Link Correlator, Target Port ID and Target
ID must remain the same once the Target DLSw has sent
ICANREACH_cs for a given circuit. The Origin DLSw must store
values specified in the ICANREACH_cs and use these on all
SSP messages for this circuit
The Origin DLSw must allow these fields to vary until
ICANREACH_cs is received. Each SSP message issued for a circuit
reflect the values specified by the Target DLSw in the last
message for this circuit received by the Origin DLSw. Binary
should be used if no such message has yet been received for a
circuit (apart from the Target Transport ID which will have
learnt as specified above).
The Origin Data Link Correlator, Origin Port ID and Origin
ID must remain the same once the Origin DLSw has issued the REACH_
for a given circuit. The Target DLSw must store the values
in the REACH_ACK and use these on all subsequent SSP messages
this circuit
The Target DLSw must allow these fields to vary until the REACH_
is received. Each SSP message issued for a circuit must reflect
values specified by the Origin DLSw in the last SSP message for
circuit received by the Target DLSw. Binary zero should be used
Wells & Bartky [Page 14]
RFC 1795 Data Link Switching April 1995
no such message has yet been received for a given circuit (apart
the Origin Transport ID which will have been learnt as
above).
For the purposes of correlator exchange, explorer messages form
separate circuit. Both DLSw partners must reflect the last
correlator values as specified above. However correlators learned
explorer messages need not be carried over to a subsequent
setup attempt. In particular, the Origin DLSw may elect to use
same values for the Origin Data Link Correlator and Origin Port
when it issues a CANUREACH_cs after receiving an ICANREACH_ex
NETBIOS_NR_ex. However the Target DLSw must not assume that
CANUREACH_cs will specify any of the Target Data Link Correlator
Target Port ID that were exchanged on the explorer messages
Received SSP messages that require a valid Remote Circuit ID
cannot be associated with an existing circuit should be rejected
a HALT_DL_NOACK message. This is done to prevent a situation
one DLSw partner has a circuit defined while the other partner
not. The exception would be a HALT_DL_NOACK message with an
Remote Circuit ID. The HALT_DL_NOACK message is typically used
error situations where a response is not appropriate
The SSP messages requiring a valid Remote Circuit ID are all
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
The Largest Frame Size (LF Size) field in the SSP Control Header
used to carry the LF Size bits across the DLSw connection.
should be used to ensure that the two end-stations always negotiate
frame size to be used on a circuit that does not require the
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.
contents of this field should be ignored on all other frames
Every DLSw forwarding a SSP frame to its DLSw partner must
that the contents of this frame reflect the minimum capability of
route to its local end-station or any limit imposed by the
itself
The bit-wise definition of this field is as follows (bit 7 is
most significant bit, bit 0 is the least significant bit):
Wells & Bartky [Page 15]
RFC 1795 Data Link Switching April 1995
7 6 5 4 3 2 1 0
+-------------------------------+
| c | r | b | b | b | e | e | e |
+-------------------------------+
c . . . . . . . LF Size Control
(significant on
from Origin to
DLSw only
0=fail circuit if
obtained requires
smaller LF
1=don't fail the
but return the LF
obtained even if it
. r . . . . . .
. . b . . . . . Largest Frame Bit
. . . b . . . . Largest Frame Bit
. . . . b . . . Largest Frame Bit
. . . . . e . . Largest Frame Bit
. . . . . . e . Largest Frame Bit
. . . . . . . e Largest Frame Bit
<----- LF Bits ----->
Refer to IEEE 802.1D Standard, Annex C for encoding of Largest
base and extended bit values
The Origin DLSw "Size Control" flag informs a Target DLSw
chooses to reply to *_cs messages on the basis of cached
that it may safely return a smaller LF Size on the ICANREACH_cs
if it has had to choose an alternative route on which to
the circuit. If this bit is set to 1, the Origin DLSw
responsibility for ensuring that the end-stations negotiate
suitable frame size for the circuit. If this bit is set to 0,
Target DLSw must not reply to the CANUREACH_cs if it cannot obtain
route to the Target end station that support an LF Size at least
large as that specified in the CANUREACH_cs frame
3.5 Message
The following table lists the protocol data units that are
between Data Link Switches. All values not listed are reserved
potential use in follow-on releases
Wells & Bartky [Page 16]
RFC 1795 Data Link Switching April 1995
Command Description Type flags/
------- -------- ------ -----------
CANUREACH_ex Can U Reach Station-explorer 0x03
CANUREACH_cs Can U Reach Station-circuit start 0x03
ICANREACH_ex I Can Reach Station-explorer 0x04
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 0x0
HALT_DL Halt Data Link 0x0
DL_HALTED Data Link Halted 0x0
NETBIOS_NQ_ex NETBIOS Name Query-explorer 0x12
NETBIOS_NQ_cs NETBIOS Name Query-circuit setup 0x12 (note 3)
NETBIOS_NR_ex NETBIOS Name Recognized-explorer 0x13
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 0x1
NETBIOS_ANR NETBIOS Add Name Response 0x1
KEEPALIVE Transport Keepalive Message 0x1D (note 4)
CAP_EXCHANGE Capabilities Exchange 0x20
IFCM Independent Flow Control Message 0x21
TEST_CIRCUIT_REQ Test Circuit Request 0x7
TEST_CIRCUIT_RSP Test Circuit Response 0x7
Note 1: Both the DGRMFRAME and DATAFRAME messages are used to
information received by the DLC entity within UI frames.
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
addresses. The latter is employed prior to the establishment of
end-to-end circuit when Circuit IDs have yet to be established
during circuit restart when Data Links are reset
Note 2: These messages are not used for the DLSw Standard but may
used by older DLSw implementations. They are listed here
informational purposes. These messages were added after
of RFC 1434 and were deleted in this standard (adaptive pacing is
used instead).
Wells & Bartky [Page 17]
RFC 1795 Data Link Switching April 1995
Note 3: These messages are not normally issued by a Standard DLSw
which uses the NB_*_ex messages as shown in section 5.4. However
a Standard DLSw attempts to interoperate with older
implementations, these messages correspond to the NETBIOS_NQ
NETBIOS_NR messages used in RFC1434 both to locate the resource
to setup a circuit. This document does not attempt to provide
complete specification of the use of these messages
Note 4: A KEEPALIVE message may be sent by a DLSw to a partner
in order to verify the TCP connection (or other future SSP
protocol) is still functioning. If received by a DLSw, this
is discarded and ignored. Use of this message is optional
For the exchange of NetBIOS control messages, the entire DLC
is carried as part of the message unit. This includes the
header, with the routing information field padded to 18 bytes,
the LLC header. The following message types are affected
NETBIOS_NQ, NETBIOS_NR, NETBIOS_ANQ, NETBIOS_ANR, and DATAFRAME
being used by NetBIOS systems. The routing information in the
header is not used by the remote Data Link Switch upon receiving
above five messages
Any SSP message types not defined above if received by a DLSw are
be ignored (i.e., no error action is to be performed). A Data
Switch should quietly drop any SSP message with a Message Type
is not recognized or not supported. Receipt of such a message
not cause the termination of the transport connection to the
sender
4. Circuit
At circuit start time, each circuit end point will provide
information to its circuit partner. The initiator of the
will choose which circuit priority will be effective for the life
the circuit. If Priority is not implemented by the Data Link Switch
then "Unsupported" priority is used
4.1 Frame
Circuit priority will be valid in the CANUREACH_cs, ICANREACH_cs,
REACH_ACK frames only. The relevant header field is shown below.
Circuit Priority value is a byte value at offset 22 in an SSP
Message
Wells & Bartky [Page 18]
RFC 1795 Data Link Switching April 1995
The following describes the format of the Circuit Priority byte
7 6 5 4 3 2 1 0
+-------------------+-----------+
| reserved | CP |
+-------------------+-----------+
CP: Circuit Priority
000 - Unsupported (note 1)
001 - Low
010 - Medium
011 - High
100 - Highest
101 to 111 are reserved for future
Note 1: Unsupported means that the Data Link Switch that
the circuit does not implement priority. Actions taken
Unsupported priority are vendor specific
4.2 Circuit
The sender of a CANUREACH_cs is responsible for setting the CP
to reflect the priority it would like to use for the circuit
requested. The mechanism for choosing an appropriate value
implementation dependent. The sender of an ICANREACH_cs frame
set the CP bits to reflect the priority it would like to use for
circuit being requested, with the mechanism for choosing
appropriate value being implementation dependent. The receiver
the ICANREACH_cs will select from the priorities in the CANUREACH_
and ICANREACH_cs frames, and will set the value in the CP field
the REACH_ACK frame that follows to the value to be used for
circuit. This priority will be used for the life of the circuit.
CANUREACH_cs or ICANREACH_cs with the circuit priority value set
Unsupported (CP=000) indicates that the sender does not support
circuit priority function
Wells & Bartky [Page 19]
RFC 1795 Data Link Switching April 1995
Flow
DLSw A DLSw
CANUREACH_cs (CP=011) -----> Circuit initiator
high Priority
<--------- ICANREACH_cs (CP=010) Circuit target
medium priority
REACH_ACK (CP=010) --------> Circuit initiator
the priority for
circuit to medium.
circuit initiator
choose either high
medium in this example
5. DLSw State
The following state tables describe the states for a single
through the Data Link Switch. State information is kept for
connection. The initial state for a connection is DISCONNECTED.
steady state is either CIRCUIT_ESTABLISHED or CONNECTED. In the
state, an end-to-end circuit has been established allowing the
of Type 1 LLC between the end systems. The latter state exists when
end-to-end connection has been established for the support of Type 2
services between the end systems
For SNA, LLC type 2 connection establishment is via the use of
802.2 Test or XID frames. SNA devices send these frames to the
SAP in order to determine the source route information in support
bridging. Normally SNA devices use SAP 0x04, 0x08, or 0x0C (most
LLC2 devices that have a single PU per MAC address use a default
0x04). Typically the SAP would be used to determine if the Test
should be sent to the DLSw code in the router. If both bridging
DLSw are enabled, this allows the product to ensure that SNA frames
not both bridged and switched. Note that although typically SNA uses
DSAP and SSAP of 0x04, it allows for other SAPs to be configured
supports unequal SAPs. This allows multiple PUs to share
between two given MAC addresses (each PU to PU session uses one LLC
connection).
For NetBIOS, LLC type 2 connection establishment is via the Name
and Name Recognized frames. These frames are used for both
resolution and source route determination. NetBIOS devices use
0xF0.
Wells & Bartky [Page 20]
RFC 1795 Data Link Switching April 1995
5.1 Data Link Switch
The Switch-to-Switch Protocol is formally defined through the
machines described in this chapter. The following table lists
thirteen possible states for the main circuit FSM. A separate
machine instance is employed for each end-to-end circuit that
maintained by the Data Link Switch
State Name
---------- -----------
CIRCUIT_ESTABLISHED The end-to-end circuit has
established. At this time LLC Type 1
services are available from end-to-end
CIRCUIT_PENDING The target DLSw is awaiting a REACH_
response to an ICANREACH_cs message
CIRCUIT_RESTART The DLSw that originated the reset
awaiting the restart of the data
and the DL_RESTARTED response to
RESTART_DL message
CIRCUIT_START The origin DLSw is awaiting
ICANREACH_cs in response to
CANUREACH_cs message
CONNECTED The end-to-end connection
been established thereby
LLC Type 2 services from end-to-
in addition to LLC Type 1 services
CONNECT_PENDING The origin DLSw is awaiting
CONTACTED response to a
message
CONTACT_PENDING The target DLSw is awaiting
DLC_CONTACTED confirmation to
DLC_CONTACT signal (i.e.,
is waiting for a UA response
an SABME command).
DISCONNECTED The initial state with no
or connection established,
DLSw is awaiting either
CANUREACH_cs, or an ICANREACH_cs
DISCONNECT_PENDING The DLSw that originated
disconnect is awaiting the DL_
Wells & Bartky [Page 21]
RFC 1795 Data Link Switching April 1995
response to a HALT_DL message
HALT_PENDING The remote DLSw is awaiting
DLC_DL_HALTED indication
the DLC_HALT_DL request (i.e.,
is waiting for a UA response to
DISC command), due to receiving
HALT_DL message
HALT_PENDING_NOACK The remote DLSw is awaiting
DLC_DL_HALTED indication
the DLC_HALT_DL request (i.e.,
is waiting for a UA response to
DISC command), due to receiving
HALT_DL_NOACK message
RESTART_PENDING The remote DLSw is awaiting
DLC_DL_HALTED indication
the DLC_HALT_DL request (i.e.,
is waiting for a UA response to
DISC command), and the restart
the data link
RESOLVE_PENDING The target DLSw is
the DLC_DL_STARTED
following the DLC_START_DL
(i.e., DLC is waiting for a
response as a result of sending
Test command).
The DISCONNECTED state is the initial state for a new circuit.
end station starts the connection via an XID or SABME command (i.e.,
DLC_XID or DLC_CONTACTED). Upon receipt, the Data Link
exchange a set of CANUREACH_cs, ICANREACH_cs and REACH_ACK messages
Upon completion of this three-legged exchange both Data Link
will be in the CIRCUIT_ESTABLISHED state. Three pending states
exist during this exchange. The CIRCUIT_START state is entered
the origin Data Link Switch after it has sent the CANUREACH_
message. The RESOLVE_PENDING state is entered by the target
Link Switch awaiting a Test response to a Test Command. And lastly
the CIRCUIT_PENDING state is entered by the target DLSw awaiting
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
prior to the establishment of a connection. Also, datagram
(i.e., UI frames) may be sent and received between the end stations
These exchanges use the XIDFRAME and DGRMFRAME messages sent
Wells & Bartky [Page 22]
RFC 1795 Data Link Switching April 1995
the Data Link Switches
In the CIRCUIT_ESTABLISHED state, the receipt of a SABME
(i.e., DLC_CONTACTED) causes the origin DLSw to issue a
message, to send an RNR supervisory frame (i.e., DLC_ENTER_BUSY)
the origin station, and to enter the CONNECT_PENDING state awaiting
CONTACTED message. The target DLSw, upon the receipt of a
message, will issue a SABME command (i.e., DLC_CONTACT) and enter
Contact Pending state. Once the UA response is received (i.e.,
DLC_CONTACTED), the target DLSw sends a CONTACTED message and
the CONNECTED state. When received, the origin DLSw enters
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
connection has been established. Information frames (i.e.,
messages) are simply sent back and forth between the end points
the connection. This is the path that should be optimized
performance
The connection is terminated upon the receipt of a DISC frame
under some other error condition detected by DLC (i.e., DLC_ERROR).
Upon receipt of this indication, the DLSw will halt the local
link, send a HALT_DL message to the remote DLSw, and enter
DISCONNECT_PENDING State. When the HALT_DL frame is received by
other DLSw, the local DLC is halted for this data link, a DL_
message is returned, and the DISCONNECTED state is entered.
of this DL_HALTED message causes the other DLSw to also enter
DISCONNECTED state
The CIRCUIT_RESTART state is entered if one of the Data Link
receives a SABME command (i.e., DLC_RESET) after data transfer
in the CONNECTED state. This causes a DM command to be returned
the origin station and a RESTART_DL message to be sent to the
Data Link Switch. This causes the remote data link to be halted
then restarted. The remote DLSw will then send a DL_
message back to the first DLSw. The receipt of the DL_
message causes the first DLSw to issue a new CONTACT message
assuming that the local DLC has been contacted (i.e., the
station has resent the SABME command). This is eventually
to by a CONTACTED message. Following this exchange, both Data
Switches will return to the CONNECTED state. If the local DLC
not been contacted, the receipt of a DL_RESTARTED command causes
Data Link Switch to enter the CIRCUIT_ESTABLISHED state awaiting
receipt of a SABME command (i.e., DLC_CONTACTED signal).
The HALT_PENDING, HALT_PENDING_NOACK and RESTART_PENDING
correspond to the cases when the Data Link Switch is
Wells & Bartky [Page 23]
RFC 1795 Data Link Switching April 1995
responses from the local station on the adjacent LAN (e.g., a
response to a DISC command). Also in the RESTART_PENDING state,
Data Link Switch will attempt to restart the data link prior
sending a DL_RESTARTED message. For some implementations, the
of a data link involves the exchange of a Test command/response
the adjacent LAN (i.e., DLC_START_DL). For other implementations
this additional exchange may not be required
5.2 State Transition
This section provides a detailed representation of the Data
Switch, as documented by a single state machine. Many of
transitions are dependent upon local signals between the Data
Switch entity and one of the DLC entities. These signals and
definitions are given in the following tables
DLC Events
Event Name
---------- -----------
DLC_CONTACTED Contact Indication: DLC has received an
command or DLC has received a UA response as
result of sending an SABME command
DLC_DGRM Datagram Indication: DLC has received a UI frame
DLC_ERROR Error condition indicated by DLC: Such
condition occurs when a DISC command is
or when DLC experiences an unrecoverable error
DLC_INFO Information Indication: DLC has received
Information (I) frame
DLC_DL_HALTED Data Link Halted Indication: DLC
received a UA response to a DISC command
DLC_DL_STARTED Data Link Started Indication: DLC
received a Test response from the null SAP
DLC_RESET Reset Indication: DLC has received an
command during the time a connection
currently active and has responded with DM
DLC_RESOLVE_C Resolve Command Indication: DLC has
a Test command addressed to the null SAP, or
XID command addressed to the null SAP
Wells & Bartky [Page 24]
RFC 1795 Data Link Switching April 1995
DLC_RESOLVED Resolve request: DLC has received a TEST
frame (or equivalent for non-LAN DLCs) but has
reserved the resources required for a circuit yet
DLC_XID XID Indication: DLC has received an XID
or response to a non-null SAP
Other Events
Event Name
---------- -----------
XPORT_FAILURE Failure of the transport connection used by
circuit
CS_TIMER_EXP The CIRCUIT_START timer (started when the
went into CIRCUIT_START state) has expired
DLC Actions
Action Name
----------- -----------
DLC_CONTACT Contact Station Request: DLC will send a
command or a UA response to an outstanding
command
DLC_DGRM Datagram Request: DLC will send a UI frame
DLC_ENTER_BUSY Enter Link Station Busy: DLC will send
RNR supervisory frame
DLC_EXIT_BUSY Exit Link Station Busy: DLC will send an
supervisory frame
DLC_HALT_DL Halt Data Link Request: DLC will send a
command
DLC_INFO Information Request: DLC will send an I frame
DLC_RESOLVE Resolve request: DLC should issue a TEST (
appropriate equivalent for non-LAN DLCs) but
not reserve the resources required for a circuit yet
DLC_RESOLVE_R Resolve Response Request: DLC will send
Test response or XID response from the null SAP
DLC_START_DL Start Data Link Request: DLC will send a
command to the null SAP
Wells & Bartky [Page 25]
RFC 1795 Data Link Switching April 1995
DLC_XID XID Request: DLC will send an XID command or
XID response
Other Actions
Action Name
---------- -----------
START_CS_TIMER Start the CIRCUIT_START timer
DLC_RESOLVE_R and DLC_START_DL actions require the DLC to reserve
resources necessary for a link station as they are used only when
circuit is about to be started. The DLC_RESOLVE action is used
topology explorer traffic and does not require such resources to
reserved, though a DLC implementation may choose not to
this from the DLC_START_DL action. See section 5.4 for details
the actions and events for explorer frames
The Data Link Switch is described by a state transition table
documented in the following sections. Each of the states
described below in terms of the events, actions, and next state
each transition. If a particular event is not listed for a
state, no action and no state transition should occur for that event
Any significant comments concerning the transitions within a
state are given immediately following the table representing
state
A separate state machine instance is maintained by the Data
Switch for each end-to-end circuit. The number of circuits that
be supported by each Data Link Switch is a local
option
The CANUREACH_ex, ICANREACH_ex, NETBIOS_NQ_ex, and NETBIOS_NR_ex
SSP messages that are not associated with a particular circuit.
processing of these messages is covered in section 5.4.
Wells & Bartky [Page 26]
RFC 1795 Data Link Switching April 1995
5.2.1 DISCONNECTED
+----------------------+---------------------+----------------------+
| 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
tables giving the identity of each Data Link Switch that can reach
specific MAC address or a specific NetBIOS name. This table can
built using the explorer frames, as per the Explorer FSM in
5.4. As a consequence, the amount of search traffic can be kept to
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/
or NetBIOS name. If there is no matching entry in the table,
Data Link Switch uses the explorer FSMs in section 5.4 to locate
target MAC/SAP or NetBIOS name
When the first non-broadcast XID or SABME flows, the Data
Switch issues a CANUREACH_cs to attempt to start a circuit.
CANUREACH_cs message is sent to only those Data Link Switches
are known to be able to reach the given MAC address. The
by which a topology table entry is determined to be out-of-date
is deleted from the table is implementation specific
The DISCONNECTED state is exited upon the sending of a CANUREACH_
by the origin DLSw or the receipt of a CANUREACH_cs message by
Wells & Bartky [Page 27]
RFC 1795 Data Link Switching April 1995
prospective target Data Link Switch. In the latter case, the
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
+-------------------+-----------------------+-----------------------+
| 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_
message by the target DLSw. A data link is started, causing a
command to be sent by the DLC
Several CANUREACH_cs messages can be received in the RESOLVE_
state. The Data Link Switch may update its topology
based upon the origin MAC address information in each CANUREACH_
message
Upon the receipt of a DLC_DL_STARTED signal in the RESOLVE_
state, the Data Link Switch may update its topology table base
the remote MAC address information. The ICANREACH_cs message must
returned to the first partner DLSw from which a CANUREACH_cs
received for this circuit, or an implementation may optionally
to all partners from which the CANUREACH_cs was received
The RESOLVE_PENDING state is exited once the data link has
started (i.e., a DLC_DL_STARTED signal is received as a result of
Test response received by the DLC). The target Data Link Switch
enters the CIRCUIT_PENDING state
Wells & Bartky [Page 28]
RFC 1795 Data Link Switching April 1995
5.2.3 CIRCUIT_START
+----------------------+---------------------+----------------------+
| 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
when a DLC_XID or DLC_CONTACTED signal has been received from
DLC
The CIRCUIT_START state is exited upon receipt of an ICANREACH_
message. A REACH_ACK message is returned to the target Data
Switch. If the CIRCUIT_START state was entered due to a DLC_
signal, an XIDFRAME message containing the XID is sent to the
Data Link Switch. If the CIRCUIT_START state was entered due to
DLC_CONTACTED signal, a CONTACT message is sent to the target
Link Switch
Wells & Bartky [Page 29]
RFC 1795 Data Link Switching April 1995
5.2.4 CIRCUIT_PENDING
+----------------------+---------------------+----------------------+
| 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
following the sending of an ICANREACH_cs message. In this state
is awaiting the reception of a REACH_ACK message from the origin
Link Switch
If the target Data Link Switch happens to receive a SABME
from the target station while in the CIRCUIT_PENDING state (i.e.,
DLC_CONTACTED signal received from the DLC), the reception of
REACH_ACK message causes the target Data Link Switch to enter
CONNECT_PENDING state and to send a CONTACT message to the
Wells & Bartky [Page 30]
RFC 1795 Data Link Switching April 1995
Data Link Switch
If no such SABME is received, the receipt of the REACH_ACK causes
Data Link Switch to enter CIRCUIT_ESTABLISHED state
5.2.5 CONNECT_PENDING
+----------------------+---------------------+----------------------+
| 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
been received from the DLC (i.e., a SABME command has been received).
A CONTACT message it then issued. The state is exited upon
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
the remote DLSw
An ICANREACH_cs received after the transition to CONNECT_
state indicates that more than one CANUREACH_cs was sent at
establishment time and the target station was found by more than
Data Link Switch partner. A HALT_DL_NOACK is sent to halt
circuit started by the Data Link Switch partner that originated
such ICANREACH_cs
Wells & Bartky [Page 31]
RFC 1795 Data Link Switching April 1995
Note: Some implementations will also send a Test command in order
restart the data link to the station that sent the SABME
(i.e., a DLC_START_DL will be issued).
5.2.6 CIRCUIT_ESTABLISHED
+----------------------+---------------------+----------------------+
| 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
Switch from the CIRCUIT_START state, and by the target Data
Switch from the CIRCUIT_PENDING state. The state is exited when
connection is started (i.e., DLC receives a SABME command) or
is received. The next state is CONTACT_PENDING or CONNECT_PENDING
An ICANREACH_cs received after the transition to CIRCUIT_
state indicates that more than one CANUREACH_cs was sent at
establishment time and the target station was found by more than
Wells & Bartky [Page 32]
RFC 1795 Data Link Switching April 1995
Data Link Switch partner. A HALT_DL_NOACK is sent to halt
circuit started by the Data Link Switch partner that originated
such ICANREACH_cs
5.2.7 CONTACT_PENDING
+----------------------+---------------------+----------------------+
| 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 | Sen