RFC 2114
Data Link Switching Client Access Protocol
RFC 2114: Data Link Switching Client Access Protocol 🎀
okay bestie, RFC 2114 is giving Informational vibes 🦋 It came out in February 1997 and was written by S. Chiang and J. Lee from Cisco Systems, Inc., with H. Yasuda from Mitsubishi Electric Corp. 💅 It obsoletes RFC 2106, so this is the replacement for that one. The header doesn't list any updates. It's part of the Network Working Group series, so it's a proper Internet community doc. ✨
Status of This Memo 📜
this one is informational only 🧚 It gives the Internet community info, but it does not set an Internet standard of any kind. Distribution is unlimited, so share it with everyone 💜
Abstract 💌
this RFC is all about the Data Link Switching Client Access Protocol, which sits between workstations and routers and carries SNA/NetBIOS traffic over TCP sessions 🌈 Questions or comments go to dcap@cisco.com 📬
Table of Contents 🗂️
1. Introduction ............................................ 2
2. Overview ................................................ 2
2.1 DCAP Client/Server Model ............................... 2
2.2 Dynamic Address Resolution ............................. 3
2.3 TCP Connection ......................................... 4
2.4 Multicast and Unicast (UDP) ............................ 4
3. DCAP Format ............................................. 6
3.1 General Frame Format ................................... 6
3.2 Header Format .......................................... 6
3.3 DCAP Messages .......................................... 7
3.4 DCAP Data formats ...................................... 8
3.4.1 CAN_U_REACH, I_CAN_REACH, and I_CANNOT_REACH Frames .. 8
3.4.2 START_DL, DL_STARTED, and START_DL_FAILED Frames ..... 9
3.4.3 HALT_DL, HALT_DL_NOACK, and DL_HALTED Frames ......... 13
3.4.4 XID_FRAME, CONTACT_STN, STN_CONTACTED, INFO_FRAME,
FCM_FRAME, and DGRM_FRAME ............................ 14
3.4.5 DATA_FRAME ........................................... 15
3.4.6 CAP_XCHANGE Frame .................................... 16
3.4.7 CLOSE_PEER_REQ Frames ................................ 19
3.4.8 CLOSE_PEER_RSP, PEER_TEST_REQ, and PEER_TEST_RSP Frames 20
4. Protocol Flow Diagram ................................... 20
5. Acknowledgments ......................................... 22
6. References .............................................. 221. Introduction 🌸
okay so once RFC 1795 (the Data Link Switching Protocol) came out, some software vendors started putting DLSw on workstations 💻 Doing that on a huge number of workstations brings up some important issues that must be addressed. The big one is scalability. The number of TCP sessions to the DLSw router goes up in direct proportion to how many workstations get added 😭 Efficiency is the other worry. DLSw is a switch-to-switch protocol, so it isn't efficient when it runs on workstations.
DCAP fixes these issues ✨ It brings in a hierarchical structure to solve the scalability problems. All workstations become clients of the router (server) instead of its peers, and that creates a client/server model 👑 It also gives you a more efficient protocol between the workstation (client) and the router (server) 🫶
2. Overview 🦋
2.1. DCAP Client/Server Model 🍓
+-----------+ +-----------+ +---------+
| Mainframe | | IP Router +- ppp -+ DLSw |
+--+--------+ +-----+-----+ | Work |
| | | Station |
| | +---------+
+--+--+ +-------------+ |
| FEP +- TR -+ DLSw Router +-- IP Backbone
+-----+ +-------------+ |
|
|
+-----------+ +---------+
| IP Router +- ppp -+ DLSw |
+-----+-----+ | Work |
| Station |
+---------+
| DLSw Session |
+-------------------------------+
Figure 2-1. Running DLSw on a large number of workstations creates a
scalability problem.so Figure 2-1 shows a typical DLSw setup on a workstation 💅 The workstations hook up to the central site DLSw router over the IP network. As the network grows, scalability becomes a problem, because the number of TCP sessions goes up with every new workstation 😭
+-----------+ +--------+
| Mainframe | | DCAP |
+--+--------+ +-----+ Client |
| | +--------+
| ppp
| |
+--+--+ +--------+ +------+------+
| FEP +- TR -+ DLSw +-- IP Backbone --+ DLSw Router |
+-----+ | Router | | DCAP Server |
+--------+ +------+------+
|
ppp
| +--------+
+-----+ DCAP |
| Client |
+--------+
| DLSw Session | | DCAP Session |
+----------------------+ +--------------+
Figure 2-2. DLSw Client Access Protocol solves the scalability
problem.In a large network, DCAP solves the scalability problem by cutting way down on the number of peers that connect to the central site router ✨ The workstations (DCAP clients) and the router (DCAP server) have a Client/Server relationship. Workstations attach to a DCAP server, and each DCAP server has a single peer connection to the central site router 🎀
2.2. Dynamic Address Resolution 🧚
okay this part is my fave 😭 In a DLSw network, each workstation needs a MAC address to talk to a FEP attached to a LAN. But when DLSw runs on a workstation, it doesn't always have a MAC address defined. For example, if a workstation connects to a router through a modem over PPP, it only has an IP address. So the user has to define a virtual MAC address, and that's super admin-heavy because every workstation must have a unique MAC address 🙈
DCAP uses the Dynamic Address Resolution protocol to fix this 💖 It lets the server dynamically assign a MAC address to a client without any complicated configuration 🫶
For a client to start a session with a server, the workstation sends a direct request to the server. The request carries the destination MAC address and the destination SAP. The workstation can either specify its own MAC address or ask the server to assign one 🌈 The server's IP address must be pre-configured on the workstation. If IP addresses are set up for multiple servers at one workstation, the request can go to all of them, and the first one to respond gets used ⭐
For a server to start a session with a client, the server sends a directed request to the workstation. The workstation must pre-register its MAC address at the server. That can happen either through configuration on the server or through registration at the server, and in both cases the MAC addresses and IP addresses get registered 💜
2.3. TCP Connection ✨
okay so the transport between the client and the server is TCP 💖 and a TCP session has to be set up between them before a frame can be sent 🫶. the default TCP connection settings are:
Socket Family AF_INET (Internet protocols)
Socket Type SOCK_STREAM (stream socket)
Port Number 1973there's only one TCP connection between the client and the server, and it's used for both read and write operations 🦋.
now the race condition 🚨. if the client and server both try to set up the TCP session with each other at the exact same time, the session started by the initiator with the lower IP address is the one that gets used, and the other session gets closed 💅
2.4 Multicast and Unicast (UDP) 🌈
multicast and unicast support with UDP is optional 🎀. for the rest of this session, whenever multicast and unicast come up, UDP is what's being used. two multicast addresses are reserved for DCAP: the server should listen on 224.0.1.49, and the client should listen on 224.0.1.50. not every DCAP frame can go over multicast or unicast 🙈. the DATA_FRAME can go either way. the CAN_U_REACH frame can only go over multicast, and the I_CAN_REACH frame can only go over unicast. every other DCAP frame has to go over a TCP session.
when multicast and unicast are implemented, the client doesn't have to configure the server's IP address 🧚. instead of setting up a TCP session with a pre-configured server, the client can multicast the CAN_U_REACH frame to the 224.0.1.49 group address. when the server gets that multicast frame, it looks up the destination given in the frame. if the destination is reachable by that server, the server sends an I_CAN_REACH frame back to the sender via unicast. then the client can start a TCP connection to the server and set up a DCAP session. if I_CAN_REACH frames come back from multiple servers, the first one to reply is the one that gets used 🏃♀️💨
when the host starts a session toward the client, the client doesn't have to register its MAC address with the server ahead of time 🍓. when the server tries to reach an unknown client, it multicasts the CAN_U_REACH frame to the 224.0.10.50 group address. the client whose MAC address matches the destination address in the CAN_U_REACH frame replies with an I_CAN_REACH frame via unicast. once the server gets that I_CAN_REACH frame, it can set up a DCAP session with that client 👑.
for NetBIOS traffic, NAME_QUERY and ADD_NAME_QUERY can be encapsulated in the DATA_FRAME and sent out via multicast. NAME_RECOGNIZED and ADD_NAME_RESPONSE can be encapsulated in the DATA_FRAME but sent out via unicast. no other NetBIOS frames can be encapsulated in the DATA_FRAME to go out via multicast or unicast 🙅♀️.
when a client wants to find a name or check whether a name is already in use on the network, it can multicast a NAME_QUERY or ADD_NAME_QUERY frame encapsulated in the DATA_FRAME 🔍. when a server receives these frames, the NetBIOS NAME_QUERY or ADD_NAME_QUERY frames get forwarded to the LAN. if a NAME_RECOGNIZED or ADD_NAME_RESPONSE frame comes back from the LAN, it gets encapsulated in the DATA_FRAME and sent to the client via unicast 💌.
when a server gets a NetBIOS NAME_QUERY or ADD_NAME_QUERY from the LAN, the server encapsulates it in the DATA_FRAME and sends it to all clients via multicast 📣. when a client receives the frame and sees that the name in the DATA_FRAME matches its own name, it encapsulates a NAME_RECOGNIZED or ADD_NAME_RESPONSE frame in the DATA_FRAME and sends it back to the server via unicast 💜.
3. DCAP Format 🎀
3.1. General Frame Format
the general DCAP frame format looks like this 🦋:
+-------------+-----------+-----------+
| DCAP Header | DCAP Data | User Data |
+-------------+-----------+-----------+
Figure 3-1. DCAP Frame Formatthe DCAP protocol lives in the DCAP header, which every frame passed between the DCAP client and the server has. this header is 4 bytes long, and the next section breaks it down 🧁.
the next part is the DCAP Data. its structure and size depend on the type of message carried in the frame. the DCAP data is used to process the frame, but it is optional 🫶.
the third part is the user data, which is what the local system sends to the remote system. its size varies, and it only shows up in the frame when there's data to send to the remote system 💅.
3.2. Header Format
the DCAP header tells you the message type and the length of the frame ✨. it's a general-purpose header that every frame passed between the DCAP server and the client has. frames like CAN_U_REACH and I_CAN_REACH need more information, so that info gets passed to the peer as DCAP data instead. the structure of the DCAP data depends on the frame type, and later sections go into detail 🌸.
here's the DCAP Header:
+-------------------------------------------+
| DCAP Packet Header (Each row is one byte) |
+===========================================+
0 | Protocol ID / Version Number |
+-------------------------------------------+
1 | Message Type |
+-------------------------------------------+
2 | Packet Length |
+ - - - - - - - - - - - - - - - - - - - - - +
3 | |
+-------------------------------------------+
Figure 3-2. DCAP Header Format- the Protocol ID is the first 4 bits of this field, and it's set to
"1000"🔥 - the Version Number is the next 4 bits in this field, and it's set to
"0001"💖 - the message type is the DCAP message type 🦋
- the total packet length is the length of the whole packet, which includes the DCAP header, DCAP data, and user data. the smallest a packet can be is 4, because that's the length of the header 🧚
3.3. DCAP Messages
okay this part is giving DLSw vibes 🌈. most DCAP frames are based on existing DLSw frames, and the matching frames have similar names. the info in the matching DCAP and DLSw frames might be different, but what they do is the same. so the DLSw State Machine is used to handle these DCAP frames 🧠. some brand-new DCAP frames were made for special DCAP jobs. for example, I_CANNOT_REACH and START_DL_FAILED are new frames that give negative acknowledgments 🙅♀️. the DLSw frames that DCAP doesn't need get dropped 🗑️.
here's the full list of DCAP messages, with a short description of each 📋:
DCAP Frame Name Code Function
--------------- ---- --------
CAN_U_REACH 0x01 Find if the station given is reachable
I_CAN_REACH 0x02 Positive response to CAN_U_REACH
I_CANNOT_REACH 0x03 Negative response to CAN_U_REACH
START_DL 0x04 Setup session for given addresses
DL_STARTED 0x05 Session Started
START_DL_FAILED 0x06 Session Start failed
XID_FRAME 0x07 XID Frame
CONTACT_STN 0x08 Contact destination to establish SABME
STN_CONTACTED 0x09 Station contacted - SABME mode set
DATA_FRAME 0x0A Connectionless Data Frame for a link
INFO_FRAME 0x0B Connection oriented I-Frame
HALT_DL 0x0C Halt Data Link session
HALT_DL_NOACK 0x0D Halt Data Link session without ack
DL_HALTED 0x0E Session Halted
FCM_FRAME 0x0F Data Link Session Flow Control Message
DGRM_FRAME 0x11 Connectionless Datagram Frame for a circuit
CAP_XCHANGE 0x12 Capabilities Exchange Message
CLOSE_PEER_REQUEST 0x13 Disconnect Peer Connection Request
CLOSE_PEER_RESPONSE 0x14 Disconnect Peer Connection Response
PEER_TEST_REQ 0x1D Peer keepalive test request
PEER_TEST_RSP 0x1E Peer keepalive response
Table 3-1. DCAP Frames3.4. DCAP Data formats
the DCAP data carries the info each DCAP frame needs 📦. the Server or the Client uses this info, and it never contains any user data 🙈. the DCAP data frame types are listed in the following sections. heads up: the sender should set the reserved fields to zero, and the receiver should ignore those fields 💜.
3.4.1. CAN_U_REACH, I_CAN_REACH, and I_CANNOT_REACH Frames ✨
okay so these frames are how we find resources on the network 🔍 A CAN_U_REACH frame gets sent to the server to check if the resource is reachable. When the server gets one, it should send out an LLC explorer frame to find the destination from the CAN_U_REACH frame. If the destination is reachable, the server replies to the client with an I_CAN_REACH frame 💖
if the server doesn't get a positive acknowledgment within a recommended threshold value of 5 seconds, it should send an LLC explorer to find the destination again 🫶 and if it gets zero responses after sending out 5 explorers (that's the recommended retry value), the destination is marked not reachable and an I_CANNOT_REACH frame goes back to the client 💀 after that, the client should decide whether a retry of CAN_U_REACH is needed. it's giving client's choice 💅
when a server is already searching for a destination and gets another I_CAN_REACH for that same destination, it should not send out another LLC explorer for it. no double work, bestie 🙈
the server should not send the CAN_U_REACH frame to the clients in a TCP session. and when a server gets an LLC explorer whose destination is a known client, it should respond to it directly 🦋
+---------------+-----------------------+
| Field Name | Information |
+---------------+-----------------------+
| Message Type | 0x01, 0x02, or 0x03 |
+---------------+-----------------------+
| Packet Length | 0x0C |
+---------------+-----------------------+Figure 3-3. CAN_U_REACH, I_CAN_REACH, and I_CANNOT_REACH Header
+-----------------------------------+
| Field Name (Each row is one byte) |
+===================================+
0 | Target MAC Address |
+ - - - - - - - - - - - - - - - - - +
1 | |
+ - - - - - - - - - - - - - - - - - +
2 | |
+ - - - - - - - - - - - - - - - - - +
3 | |
+ - - - - - - - - - - - - - - - - - +
4 | |
+ - - - - - - - - - - - - - - - - - +
5 | |
+-----------------------------------+
6 | Source SAP |
+-----------------------------------+
7 | Reserved |
+-----------------------------------+Figure 3-4. CAN_U_REACH, I_CAN_REACH, and I_CANNOT_REACH Data
the MAC Address field holds the MAC address of the target workstation being searched for 🧚 it's six bytes long, and the same MAC Address comes back in both the I_CAN_REACH and the I_CANNOT_REACH frames. no mix-ups, iykyk 🎀
byte 6 is the source SAP. the destination SAP is set to zero when an explorer frame is sent to the network 🌸
3.4.2. START_DL, DL_STARTED, and START_DL_FAILED Frames 🦋
these are the frames DCAP uses to set up a link station (circuit) 🔗 the START_DL frame goes directly to the server that answered the CAN_U_REACH frame. when the server gets it, it sets up a link station using the source and destination addresses and SAPs from the START_DL frame. if the circuit gets built successfully, a DL_STARTED frame gets sent back as the response 🎉 if that attempt fails within a recommended value of 5 seconds, the server should retry again. if the server still can't build the circuit after a recommended retry value of 5 times, a START_DL_FAILED frame should be sent back to the client 😭 and if the client gets a START_DL_FAILED frame, it's up to the client to decide whether to send START_DL to the server again 👑
the server can also send START_DL frames to clients to set up circuits. main character energy 💜
+---------------+-----------------------+
| Field Name | Information |
+---------------+-----------------------+
| Message Type | 0x04, 0x05, or 0x06 |
+---------------+-----------------------+
| Packet Length | 0x18 |
+---------------+-----------------------+Figure 3-5. START_DL, DL_STARTED, and START_DL_FAILED Header
+-----------------------------------+
| Field Name (Each row is one byte) |
+===================================+
0 | Host MAC Address |
+ - - - - - - - - - - - - - - - - - +
1 | |
+ - - - - - - - - - - - - - - - - - +
2 | |
+ - - - - - - - - - - - - - - - - - +
3 | |
+ - - - - - - - - - - - - - - - - - +
4 | |
+ - - - - - - - - - - - - - - - - - +
5 | |
+-----------------------------------+
6 | Host SAP |
+-----------------------------------+
7 | Client SAP |
+-----------------------------------+
8 | Origin Session ID |
+-----------------------------------+
9 | |
+ - - - - - - - - - - - - - - - - - +
10| |
+ - - - - - - - - - - - - - - - - - +
11| |
+-----------------------------------+
12| Target Session ID |
+ - - - - - - - - - - - - - - - - - +
13| |
+ - - - - - - - - - - - - - - - - - +
14| |
+ - - - - - - - - - - - - - - - - - +
15| |
+-----------------------------------+
16| Largest Frame Size |
+-----------------------------------+
17| Initial Window size |
+-----------------------------------+
18| Reserved |
+ - - - - - - - - - - - - - - - - - +
19| |
+-----------------------------------+Figure 3-6. START_DL, DL_STARTED, and START_DL_FAILED Data
the Host MAC address is the address of the target station if the session started from the client 🌷 or it's the address of the originating station if the session started from the server.
the next two fields are the Host and Client SAPs, one byte each 🍓 the Host SAP is the SAP used by the station with the Host MAC address, and the Client SAP is the SAP used by the client.
the Origin Session ID is the ID of the originating station that starts the circuit. the originating station uses this ID to identify the newly created circuit ✨ before the START_DL frame goes to the target station, the originating station sets up a control block for the circuit. this link station info gets set up front because DCAP doesn't use a three-way handshake for link station establishment 🙈 in the DL_STARTED and START_DL_FAILED frames, the Origin Session ID comes back exactly as it was received in the START_DL frame. the Target Session ID is set by the target station and returned in the DL_STARTED frame 💜
the Target Session ID isn't valid for the START_DL and START_DL_FAILED frames, so it should be treated as a Reserved field there. in the DL_STARTED frame, it's the session ID the target station uses to set up this circuit 🫶
the Largest Frame Size field tells you the maximum frame size the client can use 🌈 it's only valid when the server sets it. the Largest Frame Size field must be set to zero when a frame is sent by the client. both START_DL and DL_STARTED use this field, and only its rightmost 6 bits are used 🔥 the format is defined in the IEEE 802.1D Standard, Annex C, Largest Frame Bits (LF). bits 3 to 5 are base bits, and bits 0 to 2 are extended bits. the Largest Frame Size field isn't used in START_DL_FAILED and must be set to zero there 💅
bit 7 6 5 4 3 2 1 0
r r b b b e e eFigure 3-7. Largest Frame Size
please note that if the client is a PU 2.1 node, it should use the maximum I-frame size negotiated in the XID3 exchange ⭐
the Initial window size in the START_DL frame specifies the receive window size on the originating side, and the target DCAP station sends back its receive window size in the DL_STARTED frame 🦋 the field is reserved in the START_DL_FAILED frame. the way the window size gets used is the same as in DLSw. please refer to RFC 1795 for details 🌸
the last two bits are reserved for future use. they must be set to zero by the sender and ignored by the receiver 🎀
3.4.3. HALT_DL, HALT_DL_NOACK, and DL_HALTED Frames ✨
okay bestie, these frame types are how DCAP hangs up a link station 📞💅 A HALT_DL frame gets sent straight to the remote workstation to basically say "hey, I'm done, let's disconnect this session" 🥺 When the receiver gets it, it tears down the session tied to the Original Session ID and the Target Session ID in that HALT_DL frame 💔 The receiver should respond with the DL_HALTED frame 🎀 DL_HALTED should use the same Session ID values as the received HALT_DL frame, without swapping them 🦋 HALT_DL_NOACK is for when no response is needed 🙈 And the TCP session between the client and server stays up after the HALT_DL/DL_HALTED/HALT_DL_NOACK exchange 🌈
+---------------+-----------------------+
| Field Name | Information |
+---------------+-----------------------+
| Message Type | 0x0C, 0x0D, or 0x0E |
+---------------+-----------------------+
| Packet Length | 0x10 |
+---------------+-----------------------+
Figure 3-8. HALT_DL, HALT_DL_NOACK, and DL_HALTED Header +-----------------------------------+
| Field Name (Each row is one byte) |
+===================================+
0 | Sender Session ID |
+ - - - - - - - - - - - - - - - - - +
1 | |
+ - - - - - - - - - - - - - - - - - +
2 | |
+ - - - - - - - - - - - - - - - - - +
3 | |
+-----------------------------------+
4 | Receiver Session ID |
+ - - - - - - - - - - - - - - - - - +
5 | |
+ - - - - - - - - - - - - - - - - - +
6 | |
+ - - - - - - - - - - - - - - - - - +
7 | |
+-----------------------------------+
8 | Reserved |
+ - - - - - - - - - - - - - - - - - +
9 | |
+ - - - - - - - - - - - - - - - - - +
10| |
+ - - - - - - - - - - - - - - - - - +
11| |
+-----------------------------------+
Figure 3-9. START_DL, DL_STARTED, and START_DL_FAILED Data3.4.4. XID_FRAME, CONTACT_STN, STN_CONTACTED, INFO_FRAME, FCM_FRAME, and DGRM_FRAME 💌
these frame types carry the end-to-end data or help set up a circuit 🧚 The Destination Session ID is the Session ID that the receiver created in the START_DL frame or the DL_STARTED frame ✨ The flow control flag works the same way it does in DLSw, so check RFC 1795 for the deets 💅
+---------------+----------------------------+
| Field Name | Information |
+---------------+----------------------------+
| Message Type | Based on Message type |
+---------------+----------------------------+
| Packet Length | 0x0C + length of user data |
+---------------+----------------------------+
Figure 3-10. Generic DCAP Header +-----------------------------------+
| Field Name (Each row is one byte) |
+===================================+
0 | Destination Session ID |
+ - - - - - - - - - - - - - - - - - +
1 | |
+ - - - - - - - - - - - - - - - - - +
2 | |
+ - - - - - - - - - - - - - - - - - +
3 | |
+-----------------------------------+
4 | Flow Control Flags |
+-----------------------------------+
5 | Reserved |
+ - - - - - - - - - - - - - - - - - +
6 | |
+ - - - - - - - - - - - - - - - - - +
7 | |
+-----------------------------------+
Figure 3-11. Generic DCAP Data Format3.4.5. DATA_FRAME 🫶
this frame type is for sending connectionless SNA and NetBIOS Datagram (UI) frames that don't have a link station tied to the source and destination MAC/SAP pair 💜 The difference between DGRM_FRAME and DATA_FRAME is kind of the main plot twist: DGRM_FRAME sends UI frames received for stations that have a link station opened, while DATA_FRAME is for frames with no link station established 🌸
+---------------+-----------------------------+
| Field Name | Information |
+---------------+-----------------------------+
| Message Type | 0x0A |
+---------------+-----------------------------+
| Packet Length | 0x10 + Length of user data |
+---------------+-----------------------------+
Figure 3-12. DATA_FRAME Header +-----------------------------------+
| Field Name (Each row is one byte) |
+===================================+
0 | Host MAC Address |
+ - - - - - - - - - - - - - - - - - +
1 | |
+ - - - - - - - - - - - - - - - - - +
2 | |
+ - - - - - - - - - - - - - - - - - +
3 | |
+ - - - - - - - - - - - - - - - - - +
4 | |
+ - - - - - - - - - - - - - - - - - +
5 | |
+-----------------------------------+
6 | Host SAP |
+-----------------------------------+
7 | Client SAP |
+-----------------------------------+
8 | Broadcast Type |
+-----------------------------------+
9 | Reserved |
+ - - - - - - - - - - - - - - - - - +
10| |
+ - - - - - - - - - - - - - - - - - +
11| |
+-----------------------------------+
Figure 3-13. DATA_FRAME Data Formatthe first 8 bytes work exactly like the START_DL frame 🧸 The Broadcast Type field tells you which kind of broadcast frames are in use: Single Route Broadcast, All Route Broadcast, or Directed 📡 The target side uses the same broadcast type, and for Directed frames, if the RIF information is known, the target peer can send a directed frame. If it isn't known, a Single Route Broadcast frame gets sent instead 🫧
3.4.6. CAP_XCHANGE Frame 🎀
Okay bestie, CAP_XCHANGE is the capability exchange frame in DCAP, and it's how a client and a server swap info about what they can do 🫶. They send these as soon as the TCP session is established. The capability exchange must be completed before the other frame types can be sent. Once it's done, CAP_XCHANGE frame should not be used again ✨
CAP_XCHANGE frame contains the clients MAC address, if a client has one. If it doesn't, the MAC address field must be set to zero. When the DCAP server receives the CAP_XCHANGE frame, it should cache the MAC address if it is non zero. The DCAP server also verifies that the MAC address is unique 💅 The server should return a CAP_XCHANGE response frame with the MAC address supplied by the client if the MAC address is accepted. If a client doesn't have its own MAC address, the server should assign one and put that address in the CAP_XCHANGE command frame. It's giving main character server energy 💖
A client should record the new MAC address assigned by the server and return a response with the assigned MAC address. If the client cannot accept the assigned MAC address, another CAP_XCHANGE command with the MAC address field set to zero should be sent to the server. The server should allocate a new MAC address for this client 🦋
During the capability exchange, both the client and the server can send command frames. The process stops when either side sends a CAP_XCHANGE response frame. When the response frame is sent, the MAC address in the CAP_XCHANGE frame should be the same as the one in the previous received command. The sender of the CAP_XCHANGE response agrees to use the MAC address defined in the previous command 🤝
The number of CAP_XCHANGE frames that need to be exchanged is determined by the client and the server independently. When the number of exchange frames has exceeded the pre-defined number set by either the server or the client, the session should be brought down. Lowkey strict, but fair 🚪
The flag is used to show the capability of the sender. The following list shows the valid flags 🌈
0x01NetBIOS support. If a client sets this bit on, the server will pass all NetBIOS explorers to this client. If this bit is not set, only SNA traffic will be sent to this client.0x02TCP Listen Mode support. If a client supports TCP listen mode, the server will keep the client's MAC and IP addresses even after the TCP session is down. The cached information will be used for server to connect out. If a client does not support TCP listen mode, the cache will be deleted as soon as the TCP session is down.0x04Command/Response. If this bit is set, it is a command, otherwise, it is a response.
The values 0x01 and 0x02 are used only by the client. When a server sends the command/response to a client, the server does not return these values 🙈
Starting with the Reserved field, implementers can optionally implement the Capability Exchange Control Vector. Each Capability Exchange Control Vector consists of three fields: Length (1 byte), Type (1 byte), and Data (Length - 2 bytes). Two types of Control Vectors are defined: SAP_LIST and VENDOR_CODE (described below). To ensure compatibility, implementers should ignore the unknown Control Vectors instead of treating them as errors. Ignoring the stuff you don't recognise is so mature 👑
0x01SAP_LIST. Length: 2+n bytes, where n ranges from 1 to 16. This control vector lists the SAPs that the client can support. The maximum number of SAPs a client can define is 16. Therefore, the length of this Control Vector ranges from 3 to 18. If the SAP_LIST is not specified in the capability exchange, the server assumes that the client can support all the SAP values. For example, if a client can only support SAP 4 and 8, then the following Control Vectors should be sent:"0x04, 0x01, 0x04, 0x08". The first byte indicates the length of 4. The second byte indicates the control vector type of SAP_LIST. The last two bytes indicate the supported SAP values; 0x04 and 0x08. This Control Vector is used only by the client. If the server accepts this Control Vector, it must return the same Control Vector to the client 🧚0x02VENDOR_CODE. Length: 3 bytes. Each vendor is assigned a vendor code that identifies the vendor. This Control Vector does not require a response 🍓
After the receiver responds to a Control Vector, if the capability exchange is not done, the sender does not have to send the same Control Vector again 💜
+---------------+-----------------------+
| Field Name | Information |
+---------------+-----------------------+
| Message Type | 0x12 |
+---------------+-----------------------+
| Packet Length | 0x1C |
+---------------+-----------------------+
Figure 3-14. CAP_XCHANGE Header
+-----------------------------------+
| Field Name (Each row is one byte) |
+===================================+
0 | MAC Address |
+ - - - - - - - - - - - - - - - - - +
1 | |
+ - - - - - - - - - - - - - - - - - +
2 | |
+ - - - - - - - - - - - - - - - - - +
3 | |
+ - - - - - - - - - - - - - - - - - +
4 | |
+ - - - - - - - - - - - - - - - - - +
5 | |
+-----------------------------------+
6 | Flag |
+-----------------------------------+
7 | Reserved |
+-----------------------------------+
Figure 3-15. CAP_XCHANGE Data Format3.4.7. CLOSE_PEER_REQ Frames 🦋
This frame is used for peer connection management and contains a reason code field. Here's the list of valid reason codes, and they're each a whole vibe 🌸
0x01System shutdown. This indicates shutdown in progress 😭0x02Suspend. This code is used when there is no traffic between the server and the client, and the server or the client wishes to suspend the TCP session. When the TCP session is suspended, all circuits should remain intact. The TCP session should be re-established when new user data needs to be sent. When the TCP session is re-established, there is no need to send the CAP_XCHANGE frame again. Pause, not dramatic exit 🌙0x03No MAC address available. This code is sent by the server when there is no MAC address is available from the MAC address pool 💀
+---------------+-----------------------+
| Field Name | Information |
+---------------+-----------------------+
| Message Type | 0x13 |
+---------------+-----------------------+
| Packet Length | 0x08 |
+---------------+-----------------------+
Figure 3-16. CLOSE_PEER_REQ Header
+-----------------------------------+
| Field Name (Each row is one byte) |
+===================================+
0 | Reason Code |
+-----------------------------------+
1 | Reserved |
+ - - - - - - - - - - - - - - - - - +
2 | |
+ - - - - - - - - - - - - - - - - - +
3 | |
+-----------------------------------+
Figure 3-17. CLOSE_PEER_REQ Data Format3.4.8. CLOSE_PEER_RSP, PEER_TEST_REQ, and PEER_TEST_RSP Frames ✨
These three frames are used for peer connection management, and there's no data attached to any of them. Simple and clean 🫧
- CLOSE_PEER_RSP
- CLOSE_PEER_RSP is the response for CLOSE_PEER_REQ.
- PEER_TEST_REQ and PEER_TEST_RSP
- PEER_TEST_REQ and PEER_TEST_RSP are used for peer level keepalive. Implementing PEER_TEST_REQ is optional, but PEER_TEST_RSP must be implemented to respond to the PEER_TEST_REQ frame. When a PEER_TEST_REQ frame is sent to the remote station, the sender expects to receive the PEER_TEST_RSP frame in a predefined time interval (the recommended value is 60 seconds). If the PEER_TEST_RSP frame is not received in the predefined time interval, the sender can send the PEER_TEST_REQ frame again. If a predefined number of PEER_TEST_REQ frames is sent to the remote station, but no PEER_TEST_RSP frame is received (the recommended number is 3), the sender should close the TCP session with this remote station and terminate all associated circuits. It's the "are you still there?" check, but make it a whole protocol 🔥
+---------------+-----------------------+
| Field Name | Information |
+---------------+-----------------------+
| Message Type | 0x14, 0x1D, or 0x1E |
+---------------+-----------------------+
| Packet Length | 0x04 |
+---------------+-----------------------+
Figure 3-18. CLOSE_PEER_RSP, PEER_TEST_REQ, and PEER_TEST_RSP DCAP4. Protocol Flow Diagram ✨
okay so this diagram is the whole vibe 🦋 It shows a normal session start up and tear down between a client and a server, step by step, from the TCP session going up to the TCP session going down. Read it top to bottom like a group chat 💬
+-----------+ +-------+
+-----------+ Token | DLSw/DCAP | | DCAP |
| Mainframe +- Ring ---+ Router +-- ip backbone--+ Client|
+-----------+ +-----------+ +-------+
TCP Session Up
<-------------
CAP_EXCHANGE (cmd)
<-------------
CAP_EXCHANGE (cmd)
------------->
CAP_EXCHANGE (rsp)
------------->
TEST(P) CAN_U_REACH
<-------- <-------------
TEST(F) I_CAN_REACH
--------> ------------->
START_DL
<-------------
DL_STARTED
------------->
XID(P) XID_FRAME
<-------- <-------------
XID(F) XID_FRAME
--------> ------------->
XID(P) XID_FRAME
<-------- <-------------
SABME CONTACT_STN
--------> ------------->
UA STN_CONTACTED
<-------- <-------------
I FRAME INFO_FRAME
<-------- <-------------
I FRAME INFO_FRAME
--------> ------------->
DISC HALT_DL
<-------- <-------------
UA DL_HALTED
--------> ------------->
CLOSE_PEER_REQ
<-------------
CLOSE_PEER_RSP
------------->
TCP session down
<-------------5. Acknowledgments 🫶
big thanks to Rodger Erickson of Wall Data, Inc. for his helpful comments and suggestions 💜 the authors really appreciated it, and it's giving good teammate energy ✨
6. References 📚
here's the reading list, bestie 🌸
- [1] AIW DLSw Related Interest Group, RFC 1795, "DLSw: Switch-to-Switch Protocol", April 1995
- [2] IBM Token Ring Network Architecture Reference SC30-3374-02, September 1989.
- [3] IBM LAN Technical Reference IEEE 802.2 and NETBIOS Application Program Interfaces SC30-3587-00, December 1993.
- [4] ISO 8802-2/IEEE Std 802.1D International Standard.
Authors' Addresses 🎀
and here are the people who wrote this, with where to find them 💖
Steve T. Chiang
InterWorks Business Unit
Cisco Systems, Inc.
170 Tasman Drive
San Jose, CA 95134
Phone: (408) 526-5189
EMail: schiang@cisco.com
Joseph S. Lee
InterWorks Business Unit
Cisco Systems, Inc.
170 Tasman Drive
San Jose, CA 95134
Phone: (408) 526-5232
EMail: jolee@cisco.com
Hideaki Yasuda
System Product Center
Network Products Department
Network Software Products Section B
Mitsubishi Electric Corp.
Information Systems Engineering Center
325, Kamimachiya Kamakura Kanagawa 247, Japan
Phone: +81-467-47-2120
EMail: yasuda@eme068.cow.melco.co.jpand that's the whole spec, bestie 👑 you made it through! 💅
📦 where this page comes from
- ietf: rfc2114 1997-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms