RFC 1434
Data Link Switching: Switch-to-Switch Protocol
RFC 1434 🎀 Data Link Switching: Switch-to-Switch Protocol
Okay bestie, this one comes from the Network Working Group and is dated March 1993 🌸. The authors are R. Dixon and D. Kushi, both at IBM 💅. It's an informational memo, because the status section says it "provides information for the Internet community" and does not specify an Internet standard. The header doesn't list anything it obsoletes or updates, so no drama there 🫶.
Status of this Memo
Okay, the boring-but-important bit 🙈. This memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited ✨.
Abstract
So this RFC explains how IBM supports Data Link Switching over TCP/IP 🦋. It's being shared with the Internet community so people can react to the proposals in it 💜. The issues might not be directly related to the Internet's research problems, but a bunch of researchers and implementors might find them super interesting 👑.
If you have any questions or comments about it, send them to this address: dlsw@ralvma.vnet.ibm.com 💌.
Table of Contents
1. Introduction 2
2. Overview 2
3. Transport Connection 4
3.1. SSP Frame Formats 5
3.2. Address Parameters 8
3.3. Message Types 10
4. Protocol Specification 11
4.1. Protocol Flow Diagrams 11
4.1.1. Connect Protocols 11
4.1.2. Link Restart Protocols 13
4.1.3. Disconnect Protocols 15
4.2. DLS State Machine 16
4.2.1 Data Link Switch States 16
4.2.2 State Transition Tables 21
4.3. NetBIOS Datagrams 30
Acknowledgments 32
References 32
Security Considerations 32
Authors' Addresses 331. Introduction ✨
Okay so Data Link Switching (DLS) is a forwarding mechanism for the IBM SNA and IBM NetBIOS protocols 🧚. It doesn't do full routing. Instead, it does switching at the Data Link layer and encapsulates things in TCP/IP so they can travel over the Internet 🌈. This memo documents the Switch-to-Switch Protocol (SSP), which is used between IBM 6611 Network Processors 💖.
Today the IBM 6611 supports SNA (PU 2 and PU 4) systems and NetBIOS systems attached to token-ring networks, plus SNA (PU 2) systems attached to SDLC links 🔥. For the SDLC-attached systems, the 6611 gives them a LAN appearance. For the LAN-attached systems, the IBM 6611 looks like a source-routing bridge 🦋. Remote systems you reach through the IBM 6611 look like they're attached to an adjacent ring, and that ring is a virtual ring that exists inside each IBM 6611 ✨.
2. Overview 💅
Data Link Switching was built to support SNA and NetBIOS in multi-protocol routers 🫶. SNA and NetBIOS are basically connection-oriented protocols, so the Data Link Control procedure they use on the LAN is IEEE 802.2 Logical Link Control (LLC) Type 2 💜. Data Link Switching also handles SNA protocols over WAN links through the SDLC protocol 🌸.
Here's the tea 🍓. IEEE 802.2 LLC Type 2 was designed assuming the network transit delay would be small and predictable, aka a local LAN 🙈. So the LLC procedures use a fixed timer to detect lost frames. When bridging runs over wide area lines (especially slower ones), the delay gets bigger and can vary a lot depending on congestion 😭. When the delay goes past the timeout value, LLC tries to retransmit. If the frame wasn't actually lost, just late, LLC Type 2 can get confused 💀. And eventually the link gets taken down.
Since LLC Type 2 is involved, Data Link Switching tackles these 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 uses a lot of datagram services that run on LLC Type 1 🎀. For those, Data Link Switching handles the last two problems on that list ✨.
The big difference between Data Link Switching and bridging is that DLS terminates the Data Link Control, and bridging doesn't 👑. Figure 1 shows this with two end systems running LLC Type 2 services 🦋.
Bridging
-------- Bridge Bridge
+------+ +----+ +----+ +------+
| End | +---------+ | +-----/ | | +---------+ | End |
|System+-+ LAN +-+ | /------+ +-+ LAN +-+System|
| | +---------+ | | TCP/IP | | +---------+ | |
+------+ +----+ +----+ +------+
Info------------------------------------------------------->
<-------------------------------------------------------RR
Data Link Switching
-------------------
+------+ +----+ +----+ +------+
| End | +---------+ | +-----/ | | +---------+ | End |
|System+-+ LAN +-+DLS | /------+ DLS+-+ LAN +-+System|
| | +---------+ | | TCP/IP | | +---------+ | |
+------+ +----+ +----+ +------+
Info-------------------> -------------> Info
<-------------------RR ---------------->
<----------------RR
Figure 1. Data Link Switching Contrasted to BridgingIn traditional bridging, the Data Link Control is end-to-end 🧚. Data Link Switching terminates the LLC Type 2 connection at the switch. That means LLC Type 2 connections never cross the wide area network 🌈. DLS multiplexes LLC connections onto a TCP connection to another DLS 💖. So the LLC connections at each end are totally independent of each other 🔥. It's the Data Link Switch's job to deliver frames it got from one LLC connection to the other end 🦋. TCP is used between the Data Link Switches to guarantee frame delivery ✨.
Because of this design, LLC time-outs stay on the local LAN (they don't traverse the wide area) 👑. The LLC Type 2 acknowledgments (RRs) also don't cross the WAN, which cuts down on traffic over the wide area links 💜. For SDLC links, polling and poll response happen 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 🍓. And finally, the switches can apply back pressure to the end systems for flow and congestion control 🫶.
Data Link Switching uses LAN addressing to set up connections between SNA systems 💅. SDLC-attached devices are defined with MAC addresses so they can talk to LAN-attached devices 🎀. For NetBIOS systems, Data Link Switching uses the NetBIOS name to forward datagrams and set up connections for NetBIOS sessions ✨. For circuit establishment, SNA systems send TEST (or in some cases, XID) frames to the null (x'00') SAP 🙈. NetBIOS systems have an address resolution procedure, based on the Name Query and Name Recognized frames, that's used to establish an end-to-end circuit 🦋.
Since Data Link Switching may be implemented in multi-protocol routers, both bridging and switching might be enabled at the same time 🌈. SNA frames can be identified by their link SAP. Typical SAP values for SNA are x'04', x'08', and x'0C'. NetBIOS always uses a link SAP value of x'F0' 💖.
3. Transport Connection 🦋
Data Link Switches can be used in pairs or by themselves 🧚. A single DLS internally switches one data link to another without using TCP (DLC(1) to DLC(2) in the figure below) 💜. A paired DLS multiplexes data links over a reliable transport using a Switch-to-Switch Protocol (SSP) 🔥. This RFC documents the frame formats and protocols for that multiplexing between Data Link Switches 👑. The initial implementation of SSP uses TCP as the reliable transport between Data Link Switches. Other transport connections, such as OSI TP4, could be used too 🌸.
+-----------------------------------------------+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 |
+-----------------------------------------------+
Figure 2. DLS System DiagramBefore Data Link Switching can happen between two routers, they must establish a TCP connection between them 🍓. Each DLS keeps a list of DLS-capable routers and their status (active/inactive) 💅. Once that connection is up, the DLS uses SSP to set up end-to-end circuits over the transport connection 🫶. Inside the transport connection is a specific set of DLS message units 🎀. The message formats and types for these PDUs are documented in the following sections ✨.
The default parameters for the TCP connections between Data Link Switches are:
Socket Family AF_INET (Internet protocols)
Socket Type SOCK_STREAM (stream socket)
Read Port Number 2065
Write Port Number 2067Two or more Data Link Switches might be attached to the same LAN, made up of a bunch of token-ring segments connected by source-routing bridges 🌈. In that case, a TCP connection is not defined between bridges attached to the same LAN 🙈. This lets using systems pick one of the possible Data Link Switches, kind of like how they pick 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 💜. That stops LAN frames sent by one Data Link Switch from being propagated through the other Data Link Switches 🔥.
Part 1 of 8 💖 more parts coming, bestie, stay tuned 🧚✨
3.1. SSP Frame Formats 🎀
Okay so the next bit is all about what the headers actually look like when Data Link Switches chat with each other 💅. There are two header shapes. The control message header is used for everything except information messages. The information message header is only 16 bytes, and the control one is a chunky 72 bytes. The good news is the first sixteen bytes of the control header are literally identical to the information header, so it's giving consistency 🫶
CONTROL MESSAGES (72 Bytes)
+-----------------------------------------------------------------+
| Version Number Reserved Field |
| Message Length ----> . |
| Remote Data Link Correlator ----> . |
| . . |
| Remote DLC Port ID ----> . |
| . . |
| Reserved Field ----> . |
| Message Type Reserved Field |
| Protocol ID Header Number |
| Header Length ----> . |
| Reserved Field ----> . |
| Reserved Field Message Type |
| Target MAC Address ----> . |
| . . |
| . . |
| Origin MAC Address ----> . |
| . . |
| . . |
| Origin Link SAP Target Link SAP |
| Frame Direction Reserved Field |
| Message Length ----> . |
| DLC Header Length ----> . |
| Origin DLC Port ID ----> . |
| . . |
| Origin Data Link Correlator ----> . |
| . . |
| Origin Transport ID ----> . |
| . . |
| Target DLC Port ID ----> . |
| . . |
| Target Data Link Correlator ----> . |
| . . |
| Target Transport ID ----> . |
| . . |
| Reserved Field ----> . |
| . . |
+-----------------------------------------------------------------+
(Even Byte) (Odd Byte)
INFORMATION MESSAGE (16 Bytes)
+-----------------------------------------------------------------+
| Version Reserved Field |
| Message Length ----> . |
| Remote Data Link Correlator ----> . |
| . . |
| Remote DLC Port ID ----> . |
| . . |
| Reserved Field ----> . |
| Message Type Reserved Field |
+-----------------------------------------------------------------+
(Even Byte) (Odd Byte)Now the important fields, bestie 👑 The Version Number is x'4B', which is 75 in numbers. The Header Length is x'00 48', which means 72 bytes (main character length 🦋). The Header Number is x'01', so one. The Protocol ID is x'42', which is 66.
The Frame Direction field tells you where the frame is going. It's x'01' when it's heading from the origin DLS to the target DLS, and x'02' when it's coming back from the target DLS to the origin DLS.
Note: The Remote Data Link Correlator and Remote DLC Port ID get copied from the Target Data Link Correlator and Target DLC Port ID when the Frame Direction isx'01'. When the Direction Field isx'02', they get copied from the Origin Data Link Correlator and Origin DLC Port ID instead. It's a mirror situation 🪞✨
The Message Length field says how many bytes of data come after the header. Fun fact, this number shows up in two different fields of the header, so don't be confused when you see it twice 🙈
The DLC Header Length is zero for SNA. For NetBIOS datagrams it's x'23', which is 35 bytes. That 35 covers the Access Control (AC) field, the Frame Control (FC) field, the Destination MAC Address (DA), the Source MAC Address (SA), the Routing Information (RI) field (padded out to 18 bytes), the Destination link SAP (DSAP), the Source link SAP (SSAP), and the LLC control field (UI). Lots of pieces, but they all add up 💖
The Message Type values get defined in a later section, and this value also shows up in two spots in the header 🧚
Last but not least, reserved fields get set to zero when you send them, and you should just ignore them when you receive them. Zero drama 🌸
3.2. Address Parameters 🦋
Let's talk about who's who. A data link is a logical connection between the two end stations that are using Data Link Switching. It gets identified by a Data Link ID, which is 14 bytes long and made of the pair of attachment addresses for each end system. Each attachment address is just the MAC address (6 bytes) stuck together with the LLC address (1 byte). Cute and organized 🎀
DATA LINK ID (14 Bytes)
+-----------------------------------------------------------------+
|Target MAC Address ----> . |
| . . |
| . . |
|Origin MAC Address ----> . |
| . . |
| . . |
|Origin Link SAP Target Link SAP |
+-----------------------------------------------------------------+Now an end-to-end circuit is identified by a pair of Circuit ID's, bestie. A Circuit ID is a 64 bit number that identifies the DLC circuit inside one single DLS. It's built from a DLC Port ID (4 bytes) and a Data Link Correlator (4 bytes). It's unique within a single DLS and gets assigned locally, so no global drama 💅 The pair of Circuit ID's, plus the identifiers of the Data Link Switches, is what makes one end-to-end circuit uniquely identifiable. Each DLS has to keep a table of these Circuit ID pairs: one entry for the local end of the circuit and one for the remote end. To keep track of which Data Link Switch started the circuit, this document uses the terms origin DLS and target DLS 🔥
CIRCUIT ID (8 Bytes)
+-----------------------------------------------------------------+
|DLC Port ID ----> . |
| . . |
|Data Link Correlator ----> . |
| . . |
+-----------------------------------------------------------------+Okay, the Origin Transport ID and Target Transport ID fields in the message header are used to identify the individual TCP/IP port on a Data Link Switch. Their values only matter locally, so they're not a global thing 🌈 But every Data Link Switch is required to reflect these two fields back, along with the matching DLC Port ID and Data Link Correlator values, whenever it returns a message to the other DLS. Reflecting is a must-do vibe, just not in caps 🫶
Here's how the addressing parameters get used when an end-to-end connection is being set up. The CANUREACH, ICANREACH, and REACH_ACK messages all carry the Data Link ID, which is the MAC and Link SAP addresses for the two end stations. When the target DLS gets a CANUREACH message, it starts a data link for each port, and that's how it gets a Data Link Correlator. If the target station can be reached, an ICANREACH message goes back to the origin DLS with the Target Circuit ID parameter in it. Once the origin DLS gets that, it starts a data link and sends the Origin Circuit ID back to the target DLS inside the REACH_ACK message. Now, if the REACH_ACK message doesn't arrive successfully, the target Data Link Switch can still grab the Origin Circuit ID from a later message, which could be a CONTACT, XIDFRAME, or DGRMFRAME. Backup plan energy 🧚
+------------+ +------------+
|Disconnected| |Disconnected|
+------------+ CANUREACH (Data Link ID) +------------+
------------------------------------------------->
ICANREACH (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)
<-------------------------------------------------
Figure 3. DLS Circuits and ConnectionsWhile the XIDFRAME, CONTACT, and CONTACTED messages are going back and forth, the pair of Circuit ID parameters rides along in the message format together with the DATA LINK ID parameter 💖 Once the connection is up, the INFOFRAME messages switch over to the shorter header. That header only carries the Circuit ID for the remote DLS. The Remote Data Link Correlator and Remote DLC Port ID are set equal to the Data Link Correlator and DLC Port ID associated with either the origin or target Data Link Switch, depending on which direction the packet is traveling ✨
3.3. Message Types 💌
okay bestie, this is the full menu of SSP messages that Data Link Switches pass between each other 🫶 Anything not on this list is reserved for potential use in follow-on releases, so it's a no-go for now 🙅♀️
Command Function Hex Value
------- -------- ---------
CANUREACH Can U Reach Station x'03'
ICANREACH I Can Reach Station x'04'
REACH_ACK Reach Acknowledgment x'05'
DGRMFRAME Datagram Frame (See note) x'06'
XIDFRAME XID Frame x'07'
CONTACT Contact Remote Station x'08'
CONTACTED Remote Station Contacted x'09'
RESTART_DL Restart Data Link x'10'
DL_RESTARTED Data Link Restarted x'11'
INFOFRAME Information (I) Frame x'0A'
HALT_DL Halt Data Link x'0E'
DL_HALTED Data Link Halted x'0F'
NETBIOS_NQ NetBIOS Name Query x'12'
NETBIOS_NR NetBIOS Name Recognized x'13'
DATAFRAME Data Frame (See note) x'14'
NETBIOS_ANQ NetBIOS Add Name Query x'1A'
NETBIOS_ANR NetBIOS Add Name Response x'1B'
Table 1. SSP Message TypesQuick note on DGRMFRAME and DATAFRAME 👀 Both of them carry info that the DLC entity received inside UI frames. DGRMFRAME is addressed using a pair of Circuit IDs, while DATAFRAME is addressed using a Data Link ID, which is a pair of MAC addresses plus a pair of link SAP addresses. DATAFRAME is the one used before an end-to-end circuit exists, when Circuit IDs haven't been set up yet.
For NetBIOS control messages, the entire DLC header rides along as part of the message unit 🎁 That means the MAC header (with the routing information field padded to 18 bytes) and the LLC header. The affected message types are NETBIOS_NQ, NETBIOS_NR, NETBIOS_ANQ, NETBIOS_ANR, and DATAFRAME when it's being used by NetBIOS systems. Fun fact: the remote Data Link Switch doesn't use the routing information in the DLC header when it gets any of those five messages.
4. Protocol Specification 🎀
This section is the deep dive on the Switch-to-Switch Protocols 💅 You get a set of high-level protocol flows plus a detailed set of state transition tables. The states and protocols are described in generic terms so they work across different platforms. The real focus is making sure the IBM 6611 can operate with another vendor's implementation. Notes are dropped in wherever the IBM 6611 does something local that's specific to the AIX platform it runs on.
4.1. Protocol Flow Diagrams 🦋
The switch-to-switch protocols are how circuits get set up and taken down between a pair of Data Link Switches. Once a circuit is up, the end stations on the local networks can use LLC Type 1 (connectionless) protocols. The end systems can also set up an end-to-end connection to support LLC Type 2 (connection oriented) protocols, which is giving reliable, organized vibes ✨
Terminology time! In this document, "Data Link" refers to both a "logical data link" (when supporting Type 1 LLC services) and a "data link connection" (when supporting Type 2 LLC services). Either way, the Data Link is defined by the combination of the destination MAC address (DA), the source MAC address (SA), the destination link SAP (DSAP), and the source link SAP (SSAP).
4.1.1. Connect Protocols 💜
Here's the flow for setting up a circuit between two Data Link Switches, followed by setting up a connection between the two end systems 🔥 The figure assumes both end systems are SNA. The NetBIOS flow is covered a bit later.
Data Link Data Link Data Link Data Link
Control Switch Switch Control
-------------------- --------------------
+------------+ +------------+
|Disconnected| |Disconnected|
+------------+ +------------+
Test Command CANUREACH Test Comd.
----------> ---------------------------------------> ------->
(DSAP=Null) (DSAP=SSAP)
Test Response
ICANREACH <---------
Test Response <---------------------------------------
<---------- REACH ACK
--------------------------------------->
+------------+ +------------+
|Circuit Est.| |Circuit Est.|
+------------+ +------------+
SABME CONTACT
----------> ---------------------------------------> SABME
UA ------->
<----------
RNR UA
<---------- CONTACTED <-------
<---------------------------------------
+------------+ +------------+
| Connected | | Connected |
+------------+ +------------+
RR
<---------
Figure 4. DLS Connect Message ProtocolsHere's how the story goes 🎬 When the origin DLS gets a Test command from the origin station, it sends a CANUREACH (i.e., can you reach) message to the target DLS. If the origin DLS doesn't know about the target DLS, the CANUREACH message gets sent to all remote Data Link Switches defined to the origin DLS. When the target DLS receives CANUREACH, it sends a Test command out to look for the target station. The target station responds with a Test response, and that makes the target DLS send an ICANREACH (i.e., I can reach) message back to the origin DLS. If more than one Data Link Switch can reach the target station, the origin DLS ends up with multiple ICANREACH messages. It picks the first one and sends a REACH_ACK (i.e., reach acknowledgment) message to the selected Data Link Switch. During this exchange, both Data Link Switches move from the Disconected state to the Circuit Established state. Once the circuit is up, Type-1 frames, such as XID, may be exchanged between the origin and target stations.
Now for the connection part 🧡 To set up a connection, the origin station sends a SABME command. When the origin DLS gets that, it sends a CONTACT message to the target DLS and returns a UA response to the origin station. To hold off traffic until the connection to the remote station is ready, an RNR supervisory frame is sent to the origin station. The CONTACT message makes the target DLS send a SABME command to the target station, which replies with a UA response. When the target DLS gets that UA, it sends a CONTACTED message to the origin DLS. The origin DLS then sends an RR supervisory frame to the origin station. During this exchange, both Data Link Switches move from the Circuit Established state to the Connected state 🎉
For NetBIOS end systems, the flows look similar but use different frames and SSP messages. Instead of a Test command frame to start the circuit, a NetBIOS system uses a Name Query frame. When the Data Link Switch receives a Name Query frame, it issues a NETBIOS_NQ message instead of CANUREACH. In the same way, the Test response gets replaced with a Name Recognized frame, and ICANREACH gets replaced with a NETBIOS_NR message. Just like with the SNA flows, when the origin Data Link Switch receives a NETBIOS_NR message, it responds with a REACH_ACK message.
4.1.2. Link Restart Protocols 🌈
This one is all about restarting the end-to-end connection 🔄 The flows below cause the Data Link Switches to terminate the existing connection and enter the Circuit Established state, waiting for a new connection to start.
Data Link Data Link Data Link Data Link
Control Switch Switch Control
--------------------- ---------------------
+-----------+ +-----------+
| Connected | | Connected |
SABME +-----------+ +-----------+
-----------> RESTART_DL
DM -------------------------------------> DISC
<----------- -------->
UA
DL_RESTARTED (Case 1) <--------
<-------------------------------------
+-----------+ +-----------+
|Circuit Est| |Circuit Est|
+-----------+ +-----------+
........... or ...........
SABME
-----------> DL_RESTARTED (Case 2)
UA <-------------------------------------
<----------- +-----------+
|Circuit Est|
CONTACT +-----------+
RNR ------------------------------------>
<----------
Figure 5. DLS Link Restart Message ProtocolsHere's the play-by-play 📝 When the origin DLS gets a SABME command from the origin station, it sends a RESTART_DL message to the target DLS. It also returns a DM response to the origin station, and the data link gets restarted. When the target DLS receives RESTART_DL, it issues a DISC command to the target station. The target station is expected to return a UA response. Then the target DLS restarts its data link and sends a DL_RESTARTED message back to the origin DLS. During this exchange, both Data Link Switches move from the Connected state to the Circuit Established state.
Now, if the origin station sends the SABME command again 🙈 the origin DLS sends a CONTACT message to the target DLS. If that SABME arrives before the DL_RESTARTED message does (that's case 2 in the figure), the CONNECT message gets delayed until DL_RESTARTED is received. From that point, the protocol flows match the connect sequence we already covered above 💖
4.1.3. Disconnect Protocols ✨
okay so this part is all about how a connection gets ended 💅 The first diagram shows what happens when the end system hangs up. It's not just the connection that gets shut down, the circuit between the Data Link Switches gets taken down too 🫶
Data Link Data Link Data Link Data Link
Control Switch Switch Control
-------------------- --------------------
+-----------+ +-----------+
| Connected | | Connected |
+-----------+ +-----------+
DISC
----------> HALT_DL
UA -------------------------------------> DISC
<---------- --------->
UA
DL_HALTED <--------
<-------------------------------------
+-----------+ +-----------+
|Disconnectd| |Disconnectd|
+-----------+ +-----------+
......... or ..........
+-----------+ +-----------+
| Connected | | Connected |
+-----------+ +-----------+
DISC TCP Connection Failure DISC
<-------- <------------------------------------> --------->
UA UA
--------> <--------
+-----------+ +-----------+
|Disconnectd| |Disconnectd|
+-----------+ +-----------+
Figure 6. DLS Disconnect Message Protocolsso the play-by-play for the normal hang up 🎀 the origin DLS gets a DISC command from the origin station, and it replies with a UA response and sends a HALT_DL message over to the target DLS. when the target DLS gets that HALT_DL, it sends a DISC command to the target station. the target station answers with a UA, and that's what makes the target DLS send back a DL_HALTED message to the origin DLS 💜 during all this back and forth, both Data Link Switches move from the Connected state over to the Disconnected state. bestie, it's giving very organized goodbye 👑
the other case is when the TCP connection between two Data Link Switches dies 💀 then every connection that was multiplexed on that TCP connection gets taken down too. both Data Link Switches end up sending DISC commands to all the local systems tied to those failed connections. and once a Data Link Switch sends that DISC command, it enters the DISCONNECT state for each circuit 🦋
4.2. DLS State Machine 🌸
okay now the state tables, which describe the states for a single connection through the Data Link Switch. state info is kept for every connection separately, and every connection starts out in DISCONNECT. the steady states are either CIRCUIT_ESTABLISHED or CONNECTED 🧚 CIRCUIT_ESTABLISHED means an end-to-end circuit is up so Type 1 LLC can run between the end systems. CONNECTED means an end-to-end connection is up for Type 2 LLC services between the end systems. main character energy for both 🌈
for SNA, the circuit gets set up using IEEE 802.2 Test or XID frames. SNA devices send these to the null SAP so they can figure out the source route information for bridging ✨ normally SNA devices use SAP x'04', x'08', or x'0C'. the SAP is typically what decides whether Test frames get sent up to the DLS code in the router 💖 and if both bridging and DLS are turned on, this lets the product make sure SNA frames don't get both bridged and switched. no double dipping 💅
for NetBIOS, the circuit gets set up with Name Query and Name Recognized frames. these do double duty for address resolution and source route determination 🍓 normally NetBIOS devices use SAP x'F0'. iykyk 🙈
4.2.1. Data Link Switch States 💖
okay bestie, the Switch-to-Switch Protocols get formally defined through a single state machine 🫶 Here's the lineup: the table lists eleven possible states. Each end-to-end circuit the Data Link Switch maintains gets its own separate state machine, so it's giving organized 💅 The three steady states are DISCONNECTED, CIRCUIT_ESTABLISHED, and CONNECTED ✨
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 DLS is awaiting a REACH_ACK
response to an ICANREACH message.
CIRCUIT_RESTART The DLS that originated the reset is
awaiting the restart of the data link
and the DL_RESTARTED response to a
RESTART_DL 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 DLS is awaiting the CONTACTED
response to a CONTACT message.
CONTACT_PENDING The target DLS 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 DLS is awaiting
either a CANUREACH, an ICANREACH, a
NETBIOS_NQ, or a NETBIOS_NR message.
DISCONNECT_PENDING The DLS that originated the disconnect
is awaiting the DL_HALTED response to a
HALT_DL message.
HALT_PENDING The remote DLS 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).
RESTART_PENDING The remote DLS 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 DLS is awaiting either the
DLC_DL_STARTED indication following the
DLC_START_DL reqest (i.e., DLC is waiting
for a Test response as a result of sending a
Test command), or a NB_Name_Recognized
frame in response to a NB_Name_Query frame.Table 2. Data Link Switch States
Next up is the picture of which events kick off a transition to a new state 🦋 The resulting actions aren't drawn in, so don't go looking for them here 🙈 Also, the DISCONNECT_PENDING state gets entered whenever a DLC error condition shows up in any state except RESOLVE_PENDING, or whenever the DLC receives a DISC command. Major drama, honestly 😭
DLC_RESOLVE_C+----+ +----DLC_ERROR---+
| | \|/ |
+------------+ +>+--+---------+ CANUREACH +-+----------+
| Disconnect +--DL_HALTED-->|Disconnected|------------>| Resolve |
| Pending |<+ +------->| |<-------+ | Pending |
+---------+--+ | | +-----+------+ | +-----+------+
/|\ | HALT_DL| /|\ |/|\/|\ | |
DLC_ERROR +----+ | +----+ | | +------+ | DLC_DL_STARTED
| | | |HALT_DL(ts)| +------+ |
| | ICANREACH| | HALT_DL(ts)|
+--HALT_DL(ts)+ | | | | | |
| HALT_DL(ts) | | HALT_DL(ts) | |
| | | | | | |
| +-RESTART_DL(ts)+----+ | | | | |
| | | \|/ \|/| | | \|/
+----+---+---+ | +-------+----+ | +-+----------+
| Contact |<-CONTACT--+--+ Circuit |<-REACH_ACK--+ Circuit |
| Pending | | | Established| (DLC not | Pending |
+-----+------+ | +----------+-+ contacted)+-+------+---+
| /|\ | /|\ /|\ | | | |
| | +--+----+ | | | | |
| +-CONTACT--+--+--------+----+------+----------+ REACH_ACK
| | |RESTART_DL(ts) | (DLC contacted)
DLC_CONTACTED | +------+ | | +--------------+ |
| | | | | DLC_CONTACTED | |
+---------------+-------+ | | +-----------------+ | |
+-----DL_RESTARTED | | | | | |
| (DLC not contacted) \|/| | \|/ | \|/
+-----+------+ +---+-+------+ CONTACTED +-----+------+
| Circuit |<-DLC_RESET---+ Connected |<------------+ Connect |
| Restart | | | | Pending |
+----------+-+ +------------+ +-----+------+
/|\ | DL_RESTARTED /|\ |
| +----------------(DLC contacted)--------------+ |
| |
+-------------------------DLC_RESET--------------------+Figure 7. DLS State Transitions (ts = transitional state)
The DISCONNECT state is the starting point for a brand-new circuit 🌸 One end station kicks things off with a TEST or XID command (that's DLC_RESOLVE_C), or with a NetBIOS Name Query command (not drawn in the figure). Once that lands, the Data Link Switches swap a set of CANUREACH, ICANREACH, and REACH_ACK messages. This is the three-legged exchange, and when it wraps up, both Data Link Switches end up in CIRCUIT_ESTABLISHED 🎀 Two pending states show up during the exchange too. RESOLVE_PENDING is where the target Data Link Switch waits for a Test response to a Test command. CIRCUIT_PENDING is where the target DLS waits for the REACH_ACK reply to an ICANREACH message.
In CIRCUIT_ESTABLISHED, LLC Type 1 frames can flow, like the XID exchanges between SNA stations that happen before a connection is set up 🧚 Datagram traffic (UI frames) can also go back and forth between the end stations. All of that rides on the XIDFRAME and DGRMFRAME messages sent between the Data Link Switches.
Now, when CIRCUIT_ESTABLISHED gets a SABME command (that's DLC_CONTACTED), the origin DLS sends a CONTACT message, sends an RNR supervisory frame (DLC_ENTER_BUSY) to the origin station, and moves into CONNECT_PENDING to wait for a CONTACTED message ⭐ When the target DLS gets that CONTACT message, it issues a SABME command (DLC_CONTACT) and enters Contact Pending. Once the UA response comes back (DLC_CONTACTED), the target DLS sends a CONTACTED message and enters CONNECTED. When the origin DLS receives that CONTACTED message, it enters Connected too and sends an RR supervisory frame (DLC_EXIT_BUSY). Iconic, periodt 👑
CONNECTED is the steady state for normal data flow once a connection is up 💜 INFOFRAME messages just zip back and forth between the two endpoints. This is the path you'd want to optimize for performance, no cap 🔥
The connection ends when the DLS gets a DISC frame, or when the DLC detects some other error (DLC_ERROR). Once that happens, the DLS halts the local data link, sends a HALT_DL message to the remote DLS, and enters DISCONNECT_PENDING. When the other DLS gets that HALT_DL frame, it halts its local DLC for this data link, sends back a DL_HALTED message, and enters DISCONNECTED. Getting that DL_HALTED message makes the first DLS enter DISCONNECTED as well 💀
CIRCUIT_RESTART is entered when one of the Data Link Switches gets a SABME command (DLC_RESET) while it's in CONNECTED. That sends a DM command back to the origin station and a RESTART_DL message to the remote Data Link Switch. The remote data link gets halted and then restarted, and the remote DLS sends a DL_RESTARTED message back to the first DLS. When that DL_RESTARTED lands, the first DLS issues a new CONTACT message, but only if the local DLC has been contacted (meaning the origin station resent its SABME command). That gets answered with a CONTACTED message, eventually 🦋
After all that, both Data Link Switches head back to CONNECTED ✨ If the local DLC has NOT been contacted, getting a DL_RESTARTED command makes the Data Link Switch enter CIRCUIT_ESTABLISHED and wait for a SABME command (the DLC_CONTACTED signal). Wait, careful: that's lowercase "not" in the original, so I keep it as plain text: if the local DLC has not been contacted, the Data Link Switch enters CIRCUIT_ESTABLISHED and waits for the SABME command (DLC_CONTACTED signal).
In the figure, the transition labeled HALT_DL(ts) stands for the HALT_PENDING state, and the one labeled RESTART_DL(ts) stands for RESTART_PENDING 🌈 Both of these transitional states have exactly one input event and exactly one output action. While they're active, the Data Link Switch is waiting on responses from the local station on the adjacent LAN (like a UA response to a DISC command). In RESTART_PENDING, the Data Link Switch also tries to restart the data link before it sends a DL_RESTARTED message. For the IBM 6611 implementation, starting a data link means a Test command/response exchange on the adjacent LAN (that's DLC_START_DL). Other implementations might not need that extra exchange 🍓
4.2.2. State Transition Tables 🧁
Here we get a detailed picture of the Data Link Switch, written up as a set of state machines 📖 The first state machine covers sending and receiving SSP messages. A lot of the transitions depend on local signals passing between the Data Link Switch entity and one of the DLC entities. Those signals and what they mean are listed in the tables that follow 💖
Table 3 is the local DLC events list, and Table 4 is the matching local DLC actions list. Each event and action name has a short description.
Event Name Description
---------- -----------
DLC_CONTACTED Contact Indication: DLC has received an SABME
command and will send a UA response, 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_XID XID Indication: DLC has received an XID command
or response to a non-null SAP.
Table 3. Local DLC Events Action Name Description
----------- -----------
DLC_CONTACT Contact Station Request: DLC will send a 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_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.
Table 4. Local DLC ActionsThe Data Link Switch can be described by a state transition table with eleven states. ✨ Each state gets walked through below, covering the events, actions and next state for every transition. 💅 If an event isn't listed for a given state, then no action happens and no state transition happens for that event. Any important comments about the transitions in a state come right after the table for that state. 🫶
The Data Link Switch keeps a separate state machine for each end-to-end circuit. 🦋 How many circuits each Data Link Switch can support is a local implementation option.
4.2.2.1. DISCONNECTED State 💖
Event Action(s) Next State
----- --------- ----------
Receive CANUREACH DLC_START_DL RESOLVE_PENDING
Receive ICANREACH Send REACH_ACK, CIRCUIT_ESTABLISHED
DLC_RESOLVE_R
(See note 1)
Receive DATAFRAME DLC_DGRM
Receive NETBIOS_NQ DLC_DGRM RESOLVE_PENDING
Receive NETBIOS_NR Send REACH_ACK, CIRCUIT_ESTABLISHED
DLC_DGRM
(See note 2)
DLC_RESOLVE_C Send CANUREACH
DLC_DGRM If NB_Name_Query:
Send NETBIOS_NQ,
Else:
Send DATAFRAMEOkay so each Data Link Switch is assumed to build a set of topology tables 🗺️ that show which Data Link Switch can reach a specific MAC address or a specific NetBIOS name. The table gets built from the origin address info in the CANUREACH or NETBIOS_NQ message, plus the target address info in the ICANREACH or NETBIOS_NR message. So the amount of search traffic can be kept to a minimum. 📉✨
When a Test command or XID command comes in to the null SAP (aka a DLC_RESOLVE_C signal from DLC), the Data Link Switch checks the topology table before it sends the CANUREACH message. If the target MAC address is in the table, CANUREACH only goes to the Data Link Switches that are known to reach that MAC address. If the MAC address isn't in the table, CANUREACH goes to all known Data Link Switches. 🎯 Since the destination link SAP (DSAP) value is null, the Target Link SAP field in the CANUREACH message header is set equal to the Origin Link SAP value. 🧚
When a NB_Name_Query comes in, the Data Link Switch checks the topology table before sending the NETBIOS_NQ message. If the target NetBIOS name is in the table, NETBIOS_NQ goes only to the Data Link Switches known to reach that name. If the NetBIOS name isn't in the table, NETBIOS_NQ goes to all known Data Link Switches. 🌸
For SNA, the DISCONNECTED state is exited when a prospective target Data Link Switch gets a CANUREACH message, or when the origin Data Link Switch gets an ICANREACH message. 🔥 In the first case, the Data Link Switch issues a Test command to the target station (the DLC_START_DL signal is presented to DLC). In the second case, a Test response goes back to the origin station (DLC_RESOLVE_R gets issued), and a REACH_ACK message is returned to the target Data Link Switch. 💜
Note 1- The IBM 6611 won't send a Test response. Instead it sends a Test command to the station that started the resolve procedure (a DLC_START_DL gets issued) so it can start the data link. 🙈
For NetBIOS, the DISCONNECTED state is exited when a prospective target Data Link Switch receives a NETBIOS_NQ message, or when the origin Data Link Switch receives a NETBIOS_NR message. 👑 In the first case, the Data Link Switch sends a NB_Name_Query frame. In the second case, it sends a NB_Name_Recognized frame to the origin station, and a REACH_ACK message goes back to the target Data Link Switch. 🍓
Note 2- The IBM 6611 also sends a Test command (a DLC_START_DL gets issued) to the station that kicked off the name resolution, so it can start the data link. 💅
4.2.2.2. RESOLVE_PENDING State 🌈
Event Action(s) Next State
----- --------- ----------
Receive DATAFRAME DLC_DGRM
DLC_DL_STARTED Send ICANREACH CIRCUIT_PENDING
DLC_ERROR DISCONNECTED
DLC_DGRM If NB_Name_Recognized: If
Send NETBIOS_NR NB_Name_Recognized:
(See note), CIRCUIT_PENDING
Else:
Send DATAFRAMEThe RESOLVE_PENDING state gets entered when the target DLS receives a CANUREACH message or a NETBIOS_NQ message. 🫶 For the first, a data link gets started, which makes the DLC send a Test command. For the second, a NB_Name_Query frame gets sent. That frame is directed to a group MAC address. 🦋
Any CANUREACH messages that come in during RESOLVE_PENDING get answered once a DLC_DL_STARTED signal shows up. ✨ The Data Link Switch can also update its topology information using the origin MAC address info in each CANUREACH message. 🗺️
When a DLC_DL_STARTED signal arrives in RESOLVE_PENDING, the Data Link Switch may update its topology table based upon the remote MAC address information. The ICANREACH message should be returned to all Data Link Switches that had sent a CANUREACH message. 💖 In a similar way, the Data Link Switch may update its topology table when it gets a NB_Name_Recognized frame, and a NETBIOS_NR message is returned to all Data Link Switches that sent a NETBIOS_NQ message. 🎀
RESOLVE_PENDING gets exited once the data link has started (a DLC_DL_STARTED signal shows up because DLC got a Test response), or once a NB_Name_Recognized frame arrives (a DLC_DGRM signal comes in). 🔥 Then the target Data Link Switch moves into the CIRCUIT_PENDING state. 👑
Note: The IBM 6611 also sends a Test command to start the data link to the station that answered the Name Query frame (a DLC_START_DL gets issued). 🙈
4.2.2.3. CIRCUIT_PENDING State 🧚
Event Action(s) Next State
----- --------- ----------
Receive CONTACT DLC_CONTACT CONTACT_PENDING
Receive HALT_DL DLC_HALT_DL HALT_PENDING
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 DLC_ENTER_BUSY
DLC_ERROR Send HALT_DL DISCONNECT_PENDING
DLC_XID Send XIDFRAME
DLC_DGRM Send DGRMFRAMEThe CIRCUIT_PENDING state is entered by the target Data Link Switch after it sends an ICANREACH message or a NETBIOS_NR message. 🌸 Here it's waiting to receive a REACH_ACK message from the origin Data Link Switch. If there's no connection with the target station (the normal case), the Data Link Switch enters the CIRCUIT_ESTABLISHED state. 💅
Now here's the plot twist 😭. If the target Data Link Switch happens to get a SABME command from the target station while it's in CIRCUIT_PENDING (aka a DLC_CONTACTED signal from the DLC), then getting the REACH_ACK message makes the Data Link Switch enter CONNECT_PENDING and send a CONTACT message to the other Data Link Switch. 🔥 So the target Data Link Switch has basically taken on the role of the origin Data Link Switch. 👑
4.2.2.4. CONNECT_PENDING State 🦋
Event Action(s) Next State
----- --------- ----------
Receive CONTACTED DLC_EXIT_BUSY CONNECTED
Receive HALT_DL DLC_HALT_DL HALT_PENDING
Receive DGRMFRAME DLC_DGRM
Receive DATAFRAME DLC_DGRM
DLC_RESET Send RESTART_DL (See note) CIRCUIT_RESTART
DLC_ERROR Send HALT_DL DISCONNECT_PENDING
DLC_DGRM Send DGRMFRAMECONNECT_PENDING is entered by the origin Data Link Switch when a DLC_CONTACTED signal has come in from the DLC (meaning a SABME command was received). ✨ Then a CONTACT message gets issued. The state is exited when a CONTACTED message arrives from the target Data Link Switch. 🫶 If a DLC_RESET signal comes in, the local data link gets restarted and a RESTART_DL message is sent to the remote DLS. 🎀
The IBM 6611 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). 🧚 That's the same note from CONNECTED, so it's the same behavior, no cap.
4.2.2.5 CIRCUIT_ESTABLISHED State 🦋
Event Action(s) Next State
----- --------- ----------
Receive CONTACT DLC_CONTACT CONTACT_PENDING
Receive HALT_DL DLC_HALT_DL HALT_PENDING
Receive XIDFRAME DLC_XID
Receive DGRMFRAME DLC_DGRM
Receive DATAFRAME DLC_DGRM
DLC_CONTACTED Send CONTACT CONNECT_PENDING
DLC_ENTER_BUSY
DLC_ERROR Send HALT_DL DISCONNECT_PENDING
DLC_DGRM Send DGRMFRAME
DLC_XID Send XIDFRAMEOkay so CIRCUIT_ESTABLISHED is the chill, ready-to-go state 💅. The origin Data Link Switch gets here from DISCONNECTED, and the target Data Link Switch gets here from CIRCUIT_PENDING. You leave it when a connection starts, which means the DLC receives a SABME command 🎀. After that, the target goes to CONTACT_PENDING and the origin goes to CONNECT_PENDING. Iconic transition, honestly 😭.
4.2.2.6 CONTACT_PENDING State 🌸
Event Action(s) Next State
----- --------- ----------
Receive HALT_DL DLC_HALT_DL HALT_PENDING
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 DGRMFRAMESo the target Data Link Switch lands in CONTACT_PENDING as soon as it gets a CONTACT message 🧚. That makes it send a DLC_CONTACT signal to the DLC, which means the DLC sends a SABME command. You stay here until the DLC says DLC_CONTACTED, which happens when a UA response comes back 💖.
There's also a little plot twist. If a RESTART_DL message shows up, that means the remote Data Link Switch got a DLC_RESET signal. Then the local one sends a DISC command frame on the adjacent LAN (that's the DLC_HALT_DL signal) and moves into RESTART_PENDING 🦋. Dramatic, but it makes sense.
4.2.2.7 CONNECTED State 👑
Event Action(s) Next State
----- --------- ----------
Receive HALT_DL DLC_HALT_DL HALT_PENDING
Receive RESTART_DL DLC_HALT_DL RESTART_PENDING
Receive DGRMFRAME DLC_DGRM
Receive INFOFRAME DLC_INFO
Receive DATAFRAME DLC_DGRM
DLC_RESET Send RESTART_DL (See note) CIRCUIT_RESTART
DLC_ERROR Send HALT_DL DISCONNECT_PENDING
DLC_DGRM Send DGRMFRAME
DLC_INFO Send INFOFRAMECONNECTED is the main character moment 🌈. The origin Data Link Switch gets here from CONNECT_PENDING once it gets a CONTACTED message. The target Data Link Switch gets here from CONTACT_PENDING when it receives a DLC_CONTACTED signal, and then it sends a CONTACTED message back to the origin 🫶.
Usually you leave CONNECTED in one of two ways. Either a DLC_ERROR signal shows up from the DLC (for example, the local DLC got a DISC command), or a HALT_DL message comes from the other Data Link Switch (for example, the remote DLC got a DISC command) 😭.
A SABME command, which shows up as a DLC_RESET signal, will also make both Data Link Switches leave CONNECTED. Eventually they restart a new circuit, so it's a full reset arc 🔥.
Note: The IBM 6611 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).
When a reset signal comes in, the Data Link Switch sends a RESTART_DL message to the other Data Link Switch and enters the CIRCUIT_RESTART state 🍓. When the remote one gets that RESTART_DL message, it sends a DISC command (that's the DLC_HALT_DL signal) and enters RESTART_PENDING 💜.
4.2.2.8 CIRCUIT_RESTART State 🦋
Event Action(s) Next State
----- --------- ----------
Receive DL_RESTARTED If Connected: If Connected:
Send CONTACT CONNECT_PENDING,
else: CIRCUIT_ESTABLISHED
Receive DATAFRAME DLC_DGRM
DLC_ERROR Send HALT_DL DISCONNECT_PENDING
DLC_DGRM Send DATAFRAMECIRCUIT_RESTART shows up when the local DLC sends a DLC_RESET signal. That happens when a SABME command comes in while a connection is still active 🙈. A DM response goes out for that SABME command, and the Data Link Switch tries to restart the end-to-end circuit ✨.
There are two possible ways out, and which one you get depends on timing. The question is whether the local DLC reached the contacted state (so a DLC_CONTACTED signal showed up) before or after the DL_RESTARTED message arrived. The origin station causes this by resending the SABME command that first pushed the Data Link Switch into CIRCUIT_RESTART. Here are the two cases:
- DL_RESTARTED message received before the DLC_CONTACTED signal. In this case, the CIRCUIT_ESTABLISHED state is entered.
- DL_RESTARTED message received after the DLC_CONTACTED signal. In this case, the CONNECT_PENDING state is entered.
4.2.2.9 DISCONNECT_PENDING State 💀
Event Action(s) Next State
----- --------- ----------
Receive DL_HALTED DISCONNECTED
Receive HALT_DL Send DL_HALTED
Receive DATAFRAME DLC_DGRM
DLC_DGRM Send DATAFRAMEDISCONNECT_PENDING is the "we're wrapping up" state 🥲. You get here when the local DLC sends a DLC_ERROR signal. As soon as that happens, a HALT message goes out. When a DL_HALTED message comes back, you leave the state and the Data Link Switch moves into DISCONNECTED 🌸.
4.2.2.10 RESTART_PENDING State 🧚
Event Action(s) Next State
----- --------- ----------
Receive DATAFRAME DLC_DGRM
DLC_DL_HALTED (See note) Send DL_RESTARTED CIRCUIT_ESTABLISHED
DLC_ERROR Send HALT_DL DISCONNECT_PENDING
DLC_DGRM Send DATAFRAMERESTART_PENDING happens when a RESTART_DL message arrives from the remote DLS while the local Data Link Switch is in either CONTACT_PENDING or CONNECTED. Both of those make the local DLC issue a DISC command 💅. When the UA response comes back (that's DLC_DL_HALTED), the data link restarts, a DL_RESTARTED message goes back to the remote DLS, and the Data Link Switch enters CIRCUIT_ESTABLISHED 🎀.
Note: The IBM 6611 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.
4.2.2.11 HALT_PENDING State 🌈
Event Action(s) Next State
----- --------- ----------
Receive DATAFRAME DLC_DGRM
DLC_DL_HALTED Send DL_HALTED DISCONNECTED
DLC_ERROR Send DL_HALTED DISCONNECTED
DLC_DGRM Send DATAFRAMEHALT_PENDING starts when a HALT_DL message comes in. That makes the local DLC issue a DISC command 😭. When the UA response (DLC_DL_HALTED) arrives, a DL_HALTED message goes back to the remote DLS and the Data Link Switch enters DISCONNECTED 👑. Clean exit, no drama ✨.
4.3. NetBIOS Datagrams ✨
okay so NetBIOS is out here using a bunch of UI frames for directory services and sending datagrams 💅 Most of them go to a group MAC address (GA), and the routing information field says spanning tree explorer (STE) 🌸 Two of them, NB_Add_Name_Response and NB_Status_Response, go to one specific MAC address instead, with the routing info field saying specifically routed frame (SRF) 🦋 Here's the whole vibe in one table:
Event Action(s) Comment
----- --------- -------
DLC_DGRM (NB Group Address): Send NETBIOS_ANQ Transmitted to all
NB_Add_Name_Query remote DLS
DLC_DGRM (Specific Address): Send NETBIOS_ANR Transmitted to
NB_Add_Name_Response specific DLS
DLC_DGRM (Specific Address): Send DATAFRAME Transmitted to all
NB_Status_Response remote DLS
DLC_DGRM (NB Group Address): Send DATAFRAME Transmitted to all
NB_Name_in_Conflict, remote DLS
NB_Add_Group_Name_Query,
NB_Datagram,
NB_Datagram_Broadcast,
NB_Status_Query,
NB_Terminate_Trace
Table 5. NetBIOS DLC FramesJust so we're clear 🫶 the above actions do not apply in these states: CIRCUIT_ESTABLISHED, CONTACT_PENDING, CONNECT_PENDING, CONNECTED, and CIRCUIT_PENDING. The last two UI frames NetBIOS uses, NB_Name_Query and NB_Name_Recognized, are handled as part of the DLS state machine in the previous section (the DISCONNECTED and RESOLVE_PENDING states, ya know) 🧚 Also, the handling of NetBIOS datagrams (NB_Datagram) sent to a specific MAC address is governed by the DLS state machine too 👑
🙈 Note: The IBM 6611 will 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 NetBIOS specific SSP messages are handled like this 💖
Event Action(s) Comment
----- --------- -------
NETBIOS_ANQ DLC_DGRM: Routed STE
NB_Add_Name_Query (NB Group Address)
NETBIOS_ANR DLC_DGRM: Routed SRF
NB_Add_Name_Response (Specific MAC Address)
NETBIOS_NQ DLC_DGRM: Routed STE
NB_Name_Query (NB Group Address)
NETBIOS_NR DLC_DGRM: Routed SRF
NB_Name_Recognized (Specific MAC Address)
DATAFRAME DLC_DGRM Routed STE
(If NB_Status_Response:
Specific MAC Address
Else: NB Group Address)
Table 6. NetBIOS SSP MessagesThe above actions apply to all DLS states 🌈 The handling of NetBIOS datagrams sent within DGRMFRAME messages is governed by the DLS state machine. The DGRMFRAME message type is used instead of the DATAFRAME message type once the end-to-end circuit has been established. At that point, the message is addressed according to the pair of Circuit IDs in the message header, instead of relying on the MAC address information in the token ring header. That's the glow-up 🦋✨
Acknowledgments 💌
Randall Campbell, David Miller, Gene Cox, Ravi Periasamy, and The Ghost of Christmas Past. 👻🎀
References 📚
- ISO 8802-2/IEEE Std 802.2 International Standard, Information Processing Systems, Local Area Networks, Part 2: Logical Link Control, December 31, 1989
- The NETBIOS Frames Protocol, IBM Local Area Technical Reference, SC30-3383-03, Chapter 5, December 1990
- ISO/IEC DIS 10038 DAM 2, MAC Bridging, Source Routing Supplement, December 1991
Security Considerations 🔐
Security issues are not discussed in this memo. 💀 Plot twist, but this one is serious: the document doesn't cover security at all, so keep that in mind before you build anything on top of it, bestie 🙈
Authors' Addresses 🎀
Roy C. Dixon
IBM Networking Systems
Department B57, Building 060
P.O. Box 12195
Research Triangle Park, NC 27709
Phone: (919) 543-3380
EMail: rcdixon@ralvmg.vnet.ibm.com
David M. Kushi
IBM Research Division
T. J. Watson Research Center
Room H0-C07
30 Saw Mill River Road
Hawthorne, NY 10532
Phone: (914) 784-7815
EMail: kushi@watson.ibm.comNote: Any questions or comments relative to the contents of this RFC should be sent to the following Internet address: dlsw@ralvma.vnet.ibm.com. This address will be used to coordinate the handling of responses. 🦋💜
📦 where this page comes from
- ietf: rfc1434 1993-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms