RFC 2166
APPN Implementer's Workshop Closed Pages Document DLSw v2.0 Enhancements
RFC 2166: DLSw v2.0 Enhancements 🎀
Okay bestie, this one is from June 1997, and it's a closed-pages document from the APPN Implementer's Workshop. Here's the title block:
- Network Working Group
- Authors: D. Bryant (3Com Corp) and P. Brittain (Data Connection Ltd.)
- Category: Informational 🌸
- Date: June 1997
- Obsoletes / Updates: the header doesn't list either. It's a set of enhancements to RFC 1795, and it doesn't replace or supersede RFC 1795 🦋
Status of this Memo 💅
This memo gives information to the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited ✨
Abstract 🧚
This document does two main things:
- it adds a set of extensions to RFC 1795 that improve the scalability of DLSw 🚀
- it adds clarifications to RFC 1795, based on what implementers have learned so far 💜
It assumes you already know DLSw and RFC 1795. There's no attempt to explain those existing protocols or their terminology, so brush up first 🙈
This document came out of the DLSw Related Interest Group (RIG) of the APPN Implementers Workshop (AIW). If you want to join future DLSw discussions, subscribe to the DLSw RIG mailing lists by sending an email to majordomo@raleigh.ibm.com with subscribe aiw-dlsw as the body of the message 💌
Table of Contents 📚
1. INTRODUCTION ................................................ 3
2. HALT REASON CODES............................................ 3
3. SCOPE OF SCALABILITY ENHANCEMENTS............................ 4
4. OVERVIEW OF SCALABILITY ENHANCEMENTS......................... 6
5. MULTICAST GROUPS AND ADDRESSING.............................. 7
5.1 USING MULTICAST GROUPS...................................... 8
5.2 DLSW MULTICAST ADDRESSES.................................... 8
6. DLSW MESSAGE TRANSPORTS...................................... 8
6.1 TCP/IP CONNECTIONS ON DEMAND................................ 9
6.1.1 TCP CONNECTIONS ON DEMAND RACE CONDITIONS................ 9
6.2 SINGLE SESSION TCP/IP CONNECTIONS........................... 9
6.2.1 EXPEDITED SINGLE SESSION TCP/IP CONNECTIONS.............. 10
6.2.1.1 TCP PORT NUMBERS...................................... 10
6.2.1.2 TCP CONNECTION SETUP.................................. 10
6.2.1.3 SINGLE SESSION SETUP RACE CONDITIONS.................. 10
6.2.1.4 TCP CONNECTIONS WITH NON-MULTICAST CAPABLE DLSW PEERS. 11
6.3 UDP DATAGRAMS............................................... 12
6.3.1 VENDOR SPECIFIC FUNCTIONS OVER UDP....................... 12
6.3.2 UNICAST UDP DATAGRAMS.................................... 12
6.3.3 MULTICAST UDP DATAGRAMS.................................. 13
6.4 UNICAST UDP DATAGRAMS IN LIEU OF IP MULTICAST............... 13
6.5 TCP TRANSPORT............................................... 14
7. MIGRATION SUPPORT............................................ 14
7.1 CAPABILITIES EXCHANGE....................................... 14
7.2 CONNECTING TO NON-MULTICAST CAPABLE NODES................... 15
7.3 COMMUNICATING WITH MULTICAST CAPABLE NODES.................. 15
8. SNA SUPPORT.................................................. 16
8.1 ADDRESS RESOLUTION.......................................... 16
8.2 EXPLORER FRAMES............................................. 16
8.3 CIRCUIT SETUP............................................... 17
8.4 EXAMPLE SNA SSP MESSAGE SEQUENCE............................ 17
8.5 UDP RELIABILITY............................................. 19
8.5.1 RETRIES.................................................. 19
9. NETBIOS...................................................... 20
9.1 ADDRESS RESOLUTION.......................................... 21
9.2 EXPLORER FRAMES............................................. 21
9.3 CIRCUIT SETUP............................................... 21
9.4 EXAMPLE NETBIOS SSP MESSAGE SEQUENCE........................ 22
9.5 MULTICAST RELIABILITY AND RETRIES........................... 24
10. SEQUENCING.................................................. 24
11. FRAME FORMATS............................................... 25
11.1 MULTICAST CAPABILITIES CONTROL VECTOR...................... 25
11.1.1 DLSW CAPABILITIES NEGATIVE RESPONSE..................... 26
11.2 UDP PACKETS................................................ 26
11.3 VENDOR SPECIFIC UDP PACKETS................................ 27
12. COMPLIANCE STATEMENT........................................ 28
13. SECURITY CONSIDERATIONS..................................... 29
14. ACKNOWLEDGEMENTS............................................ 29
15. AUTHORS' ADDRESSES.......................................... 30
16. APPENDIX - CLARIFICATIONS TO RFC 1795....................... 311. Introduction ✨
This document defines v2.0 of Data Link Switching (DLSw) as a set of enhancements to RFC 1795. These enhancements are designed to be fully backward compatible with existing RFC 1795 implementations. Because they're a compatible add-on, this document does not replace or supersede RFC 1795 🫶
Most of the enhancements tackle scalability problems in DLSw v1.0. Reason codes were also added to the HALT_DL and HALT_DL_NOACK SSP messages so you get better diagnostic info 🔥
The appendix lists a bunch of clarifications to RFC 1795. Implementers found that the original RFC was ambiguous or unclear in some places, so these clarifications should be read alongside RFC 1795 to get the full spec of the base v1.0 DLSw standard 📖
2. HALT Reason codes 🎀
RFC 1795 has no way for a DLSw to tell its peer why it dropped a circuit. DLSw v2.0 fixes that by adding reason code fields to the HALT_DL and HALT_DL_NOACK SSP messages 💀
The reason code rides along as 6 bytes of data right after the existing SSP header. Here's how those bytes are laid out:
Byte Description
0-1 Generic HALT reason code in byte normal format
2-5 Vendor-specific detailed reason codeThe generic HALT reason code is one of these decimal values. They were picked to match the disconnect reason codes in the DLSw MIB 👑
1 - Unknown error
2 - Received DISC from end-station
3 - Detected DLC error with end-station
4 - Circuit-level protocol error (e.g., pacing)
5 - Operator-initiated (mgt station or local console)The vendor-specific detailed reason code can take any value 🌈
Every v2.0 DLSw has to include this info on allHALT_DLandHALT_DL_NOACKmessages it sends to v2.0 DLSw peers 🚨
For backwards compatibility with RFC 1795, DLSw V2.0 implementations also have to accept a HALT_DL or HALT_DL_NOACK message from a DLSw peer that doesn't carry this info. That means they accept the RFC 1795 format for these SSP messages 🫶
3. Scope of Scalability Enhancements 🦋
Okay so the DLSw Scalability group of the AIW found a bunch of scalability issues with the existing DLSw protocols defined in RFC 1795. Let's get into the tea 🫖
- Administration
RFC 1795 implies the need to define the transport address of all DLSw peers at each DLSw. In highly meshed situations (such as those often found in NetBIOS networks), the resultant administrative burden is undesirable 😩
- Address Resolution
RFC 1795 defines point to point TCP (or other reliable transport protocol) connections between DLSw peers. When a DLSw tries to find the location of an unknown resource, it sends an address resolution packet to each DLSw peer over these connections. In highly meshed configurations, this can result in a very large number of packets in the transport network. Each packet is sent individually to each DLSw peer, but they're all identical, so the transport network gets buried in identical packets. The transport network is most commonly a wide area network, where bandwidth is a precious resource, so this packet duplication is undesirable 💀
- Broadcast Packets
On top of the address resolution packets above, RFC 1795 also pushes NetBIOS broadcast packets into the transport network. NetBIOS UI frames are sent as LAN broadcast packets, and RFC 1795 propagates them over the point to point transport connections to each DLSw peer. Same story as before: this creates a large number of identical packets in the transport network, which is undesirable. And since applications can send NetBIOS UI frames, it's hard to predict or control how much of this traffic there is. That makes the RFC 1795 propagation method for these packets even more of a problem 🙃
- TCP (transport connection) Overhead
As defined in RFC 1795, each DLSw keeps a transport connection to its DLSw peers. Each transport connection guarantees in order packet delivery. That's done with acknowledgment and sequencing algorithms, which need CPU and memory at the DLSw endpoints in direct proportion to the number of transport connections. The DLSw Scalability group found two scenarios where the number of transport connections can get significant, leading to excessive overhead and corresponding equipment costs (memory and CPU). The first is highly meshed DLSw configurations, where the number of transport connections approximates n2 (where n is the number of DLSw peers). This is typically found in DLSw networks supporting NetBIOS. The second is networks where many remote locations communicate with a few central sites. In this case, the central sites must support n transport connections (where n is the number of remote sites). In both scenarios, the resulting transport connection overhead is considered undesirable depending on the value of n 🥺
- LLC2 overhead
RFC 1795 specifies that each DLSw provides local termination for the LLC2 (SDLC or other SNA reliable data link protocol) sessions traversing the SSP. Because these reliable data links guarantee in order packet delivery, the memory and CPU overhead of maintaining these connections can also get significant. This is especially undesirable in the second scenario above, because the number of reliable connections at the central site is the total of the connections maintained at each remote site 📈
It is not the intent of this document to address all the undesirable scalability issues associated with RFC 1795. This paper identifies protocol enhancements to RFC 1795 that use the inherent multicast capabilities of the underlying transport network to improve its scalability. The enhancements defined here are believed to address many of the issues above, such as administration, address resolution, broadcast packets, and, to a lesser extent, transport overhead. This paper does not address LLC2 overhead. Subsequent efforts by the AIW and/or DLSw Scalability group may address the unresolved scalability issues ✨
While it is the intent of this paper to accommodate all transport protocols as well as possible, the multicast capabilities of many protocols aren't yet well defined, understood, or implemented. Since TCP is the most prevalent DLSw transport protocol in use today, the DLSw Scalability group chose to focus its definition around IP based multicast services. This document only addresses the implementation detail of IP based multicast services 🎀
This proposal does not consider the impacts of IPv6, since IPv6 was considered too far from widespread use at the time of writing 🌸
4. Overview of Scalability Enhancements 💜
This paper describes the use of multicast services within the transport network to improve the scalability of DLSw based networking. There are only a few main components to this proposal:
- Single session TCP connections
RFC 1795 defines a negotiation protocol for DLSw peers to choose either two unidirectional or one bi-directional TCP connection. DLSws implementing the enhancements in this document must support and use (whenever required and possible) a single bi-directional TCP connection between DLSw peers. In other words, the single tunnel negotiation support of RFC 1795 is a prerequisite for this set of enhancements. Use of two unidirectional TCP connections is only allowed (and required) for migration purposes, when communicating with DLSw peers that do not implement these enhancements 🔁
This document also specifies a faster method for bringing up a single TCP connection between two DLSw peers than the negotiation used in RFC 1795. This faster method, detailed in section 6.2.1, must be used where both peers are known to support DLSw v2.0 ⚡
- TCP connections on demand
Two DLSw peers using these enhancements will only establish a TCP connection when it's necessary. SSP connections to DLSw peers that don't implement these enhancements are assumed to be established by the means defined in RFC 1795. DLSws implementing v2.0 use UDP based transport services to send address resolution packets (CANUREACH_ex, NETBIOS_NQ_ex, etc.). If a positive response is received, a TCP connection is only established to the associated DLSw peer if one doesn't already exist. Correspondingly, TCP connections are brought down when there are no circuits to a DLSw peer for an implementation defined period of time 🦋
- Address resolution through UDP
The main thrust of this paper is to use non-reliable transport and the inherent efficiencies of multicast protocols whenever possible and applicable, to reduce network overhead. So the address resolution protocols of SNA and NetBIOS are sent over the non-reliable transport of IP, namely UDP. IP multicast/unicast services are also used whenever address resolution packets must go to multiple destinations. This avoids the need to maintain TCP SSP connections between two DLSw peers when no circuits are active. CANUREACH_ex and ICANREACH_ex packets can be sent to all the appropriate DLSw peers without pre-configured peers or pre-established TCP/IP connections. Most multicast services (including TCP's MOSPF, DVMRP, MIP, etc.) replicate and propagate messages only as necessary to deliver to all multicast members. That avoids duplication and excessive bandwidth consumption in the transport network 🌈
To further optimize WAN resources, address resolution responses are sent in a directed fashion (i.e., unicast) via UDP transport whenever possible. This avoids the need to set up or maintain TCP connections when they aren't required, and it also avoids the bandwidth costs of broadcasting 💅
Note: It is also permitted to send some address resolution traffic over existing TCP connections. The conditions under which this is permitted are detailed in section 7 🫶
- NetBIOS broadcasts over UDP
Same vibe as above: NetBIOS broadcast packets are sent via UDP (unicast and multicast) whenever possible and appropriate. This avoids the need to establish TCP connections between DLSw peers when no circuits are required. Bandwidth in the transport network is also conserved by using the efficiencies inherent to multicast service implementation. Details on identifying these packets and proper propagation methods are in section 10 🙈
5. Multicast Groups and Addressing 🧚
IP multicast services provide an unreliable datagram oriented delivery service to multiple parties. Communication happens by sending to and/or listening on specific 'multicast' addresses. When a given node sends a packet to a specific address (defined to be within the multicast address range), the IP network (unreliably) delivers the packet to every node listening on that address.
So DLSws can use this service by simply sending and receiving (i.e., listening for) packets on the appropriate multicast addresses. With careful planning and implementation, networks can be effectively partitioned and network overhead controlled by sending and listening on different address groups. It is not the intent of this paper to define or describe the techniques by which this can be accomplished. It's expected that the networking industry (vendors and end users alike) will work out the most appropriate ways to use the functions provided by DLSw multicast transport services 👑
5.1 Using Multicast Groups 🍓
The multicast addressing described above can be used to limit the amount of broadcast/multicast traffic in the network. It is not the intent of this document to describe how individual DLSw/SSP implementations assign or choose group addresses. How this is done, and whether it's exposed to the end user, is up to the specific implementor. However, to provide for multivendor interoperability and simplicity of configuration, this paper defines a single IP multicast address, 224.0.10.000, to be used as a default DLSw multicast address. If a given implementation chooses to provide a default multicast address, it is recommended that this address be used. In addition, this address should be used for both transmitting and receiving multicast SSP messages. Implementing a default multicast address is not, however, required 💖
5.2 DLSw Multicast Addresses 💫
For the purpose of long term interoperability, the AIW has secured a block of IP multicast addresses to be used with DLSw. These addresses are listed below:
Address Range Purpose
--------------------------------------------------------------------
224.0.10.000 Default multicast address
224.0.10.001-191 User defined DLSw multicast groups
224.0.10.192-255 Reserved for future use by the DLSw RIG in DLSw
enhancements6. DLSw Message Transports ✨
Okay so, with the new DLSw Multicast Protocols, SSP messages now travel over two transports: TCP/IP connections and UDP services 🦋. And the UDP datagrams can be sent to two different kinds of IP addresses: unique IP addresses (usually tied to one specific DLSw) and multicast IP addresses (usually tied to a whole group of DLSw peers) 💅.
6.1 TCP/IP Connections on Demand 🔌
Same as RFC 1795, TCP/IP connections get set up between DLSw peers. BUT, unlike RFC 1795, these connections are only set up to carry reliable circuit data (aka LLC2 based circuits) 🎀. So a TCP/IP connection only gets opened to a given DLSw peer when the first circuit to that DLSw is actually needed. Like, the origin DLSw has to send a CANUREACH_CS to a target DLSw peer, and there's no TCP connection between the two yet 🌸. Then the TCP/IP connection gets brought down an implementation-defined amount of time after the last active (not pending) circuit has terminated. This keeps the overhead of maintaining TCP connections super low, which is iconic ✨.
Because TCP connections are now on demand, activating and deactivating them becomes a totally normal thing 💀. In RFC 1795 it was the exception, but now it's the everyday vibe. So for this reason, it is recommended that implementations carefully consider the value of SNMP traps for this condition 🙈.
6.1.1 TCP Connections on Demand Race Conditions 🏃♀️
Non-circuit based SSP packets (e.g., CANUREACH_ex, etc.) can still be sent and received over TCP connections even after all the circuits have been terminated 👀. Keeping that in mind, implementations should still gracefully terminate these TCP connections once the connection is no longer supporting circuits 🫶. This might mean an implementation has to retransmit request frames over UDP when no response to a TCP based unicast request comes back and the TCP connection is brought down. This is not required for multicast requests, since those are received over the multicast transport mechanism 🦋.
6.2 Single Session TCP/IP Connections 👑
RFC 1795 defines using two unidirectional TCP/IP sessions between any pair of DLSw peers, with read port number 2065 and write port number 2067 🍓. RFC 1795 also lets implementations optionally use just one bi-directional TCP/IP session. Using one TCP/IP session between DLSw peers is believed to significantly improve the performance and scalability of DLSw protocols 🔥. Performance gets a boost because TCP/IP acknowledgments are way more likely to be piggy-backed on real data when the session is bi-directional. Scalability gets a boost because fewer TCP control blocks, state machines, and associated message buffers are needed 💖. For these reasons, the DLSw enhancements defined in this paper REQUIRE the use of single session TCP/IP sessions 😭.
So, DLSws implementing these enhancements must carry the TCP Connections Control Vector in their Capabilities Exchange 🧚. On top of that, the TCP Connections Control Vector must indicate support for 1 connection 💜.
6.2.1 Expedited Single Session TCP/IP Connections 🚀
In RFC 1795, single session TCP/IP connections are made by first opening two uni-directional TCP connections, exchanging capabilities, and then bringing one of them down. Ugh, so many unnecessary flows and time delays 🙄. To avoid all that, a new single session bi-directional TCP/IP connection establishment algorithm is defined ✨.
6.2.1.1 TCP Port Numbers 🔢
DLSws implementing these enhancements will use TCP destination port 2067 (as opposed to RFC 1795, which uses 2065) for single session TCP connections 🎀. The source port will be a random port number using the established TCP norms, which exclude the possibility of either 2065 or 2067 🌈.
6.2.1.2 TCP Connection Setup 🤝
DLSw peers implementing these enhancements will set up a single session TCP connection whenever the associated peer is known to support this capability 💅. To do that, the initiating DLSw simply sends a TCP setup request to destination port 2067. The receiving DLSw responds accordingly, and then the TCP three way handshake happens ✨. Once the handshake is done, each DLSw is notified and the DLSw capabilities exchange kicks off. As in RFC 1795, no flows may take place until the capabilities exchange completes 🫶.
6.2.1.3 Single Session Setup Race Conditions 🥊
The new expedited single session setup procedure described above opens up the possibility of a race condition. This happens when two DLSw peers try to set up single session TCP connections to each other at the same time 😱. To avoid ending up with two TCP connections, the following rules are applied when establishing expedited single session TCP connections:
- If an inbound TCP connect indication is received on port
2067while an outbound TCP connect request (on port2067) to the same DLSw (IP address) is in process or outstanding, the DLSw with the higher IP address will close or reject the connection from the DLSw with the lower IP address 👑. - To speed things up even more, the DLSw with the lower IP address may choose (implementation option) to close its connection request to the DLSw with the higher address when this condition is detected ⚡.
- If the DLSw with the lower IP address has already sent its capabilities exchange request on its connection to the DLSw with the higher IP address, it must resend its capabilities exchange request over the remaining TCP connection from its DLSw peer (with the higher IP address) 🔁.
- The DLSw with the higher IP address must ignore any capabilities exchange request received over the TCP connection that's about to be terminated (the one from the DLSw with the lower IP address) 🙈.
6.2.1.4 TCP Connections with Non-Multicast Capable DLSw Peers 🕰️
During periods of migration, it's possible that TCP connections will happen between multicast capable and non-multicast capable DLSw peers 🌷. It's also possible that multicast capable DLSws may try to set up TCP connections with partners of unknown capabilities (e.g., statically defined peers) 🤔. To handle these situations, the following additional rules apply to expedited single session TCP connection setup:
- If the capability of a DLSw peer is not known, an implementation may choose to send the initial TCP connect request to either port
2067(expedited single session setup) or port2065(standard RFC 1795 TCP setup) 🦋. - If a multicast capable DLSw receives an inbound TCP connect request on port
2065while it's processing an outbound request on2067to the same DLSw, the sending DLSw will terminate its2067request and respond as defined in RFC 1795 with an outbound2065request (standard RFC 1795 TCP setup) 💖. - If a multicast capable DLSw receives an indication that the DLSw peer is not multicast capable (the port
2067setup request times out, or a port not recognized rejection is received), it will send another connection request using port2065and the standard RFC 1795 session setup protocol 🧚♀️.
6.3 UDP Datagrams 📦
As mentioned above, UDP datagrams can be sent two different ways: unicast (e.g., sent to a single unique IP address) or multicast (i.e., sent to an IP multicast address) 🌸. Throughout this document, the term UDP datagram is used to mean SSP messages sent over UDP, while unicast and multicast SSP messages refer to the specific type or method of UDP packet transport 🎀. Either way, standard UDP services are used to carry these packets. To properly parse the inbound UDP packets and deliver them to the SSP state machines, all DLSw UDP packets will use destination port 2067 💅.
Also, the checksum function of UDP stays optional for DLSw SSP messages 🤷♀️. It's believed that the inherent CRC capabilities of all data link transports will adequately protect SSP packets during transmission. And the incremental exposure to intermediate nodal data corruption is negligible 🌈. For more info on UDP packet formats, check out the "Frame Formats" section 📖.
6.3.1 Vendor Specific Functions over UDP 🏷️
To accommodate vendor specific capabilities over UDP transport, a new SSP packet format has been defined ✨. This new packet format is required because message traffic of this type isn't necessarily preceded by a capabilities exchange 🙌. So DLSws wishing to invoke a vendor specific function may send out this new SSP packet format over UDP 💜.
Because this packet can be sent over TCP connections, and non-multicast capable nodes may not be able to recognize it, implementations may only send this packet over TCP to DLSw peers known to understand this packet format (i.e., multicast capable) 🫣. To avoid this situation in the future, DLSws implementing these enhancements must ignore SSP packets with an unrecognized DLSw version number in the range of x'31' to x'3F' 🛡️. More info and the precise format for this new packet type is described below in the "Frame Formats" section 📖.
6.3.2 Unicast UDP Datagrams 🎯
Generally speaking, a unicast UDP datagram is used whenever an SSP message (not requiring reliable transport) must be sent to a unique set (not all) of DLSw peers 💖. This skips the overhead of having to set up and maintain TCP connections when they aren't required for reliable data transport 🌷.
A typical example is an ICANREACH_ex response from a peer DLSw (with which no TCP connection currently exists) 🦋. The sending DLSw knows the IP address of the intended receiver, so it can simply send the response via unicast UDP 💅. There are also a number of NetBIOS cases where unicast UDP handles UI frames directed to a specific DLSw (e.g., NetBIOS STATUS_RESPONSE) 🌈. More detail is in the NetBIOS section of this document 📖.
6.3.3 Multicast UDP Datagrams 📣
In a broad sense, multicast UDP datagrams are used whenever a given SSP message must be sent to multiple DLSw peers 🫶. For SNA, this is mainly the CANUREACH_ex packets 🧚. For NetBIOS, multicast datagrams are used to send broadcast UI frames, such as NetBIOS user datagrams and broadcast datagrams 💜.
Note, however, that it's sometimes possible to avoid broadcasting certain NetBIOS frames that would otherwise be broadcast in the LAN environment 👀. This is typically done using name caching techniques that aren't described in this paper. In cases like this, when a single destination DLSw can be determined, unicast transport can be used to send the 'broadcast' NetBIOS frame to that one destination 🎯. A more detailed listing of NetBIOS SSP packets and transport methods can be found in the NetBIOS section of this document 🌸.
6.4 Unicast UDP Datagrams in Lieu of IP Multicast 💌
okay so IP multicast is actually a thing IP does by itself, not something DLSw does on its own 🦋 which means an implementation can just use the UDP transport from this doc without touching IP multicast directly. ngl it's not as efficient as multicast, but it's not explicitly prohibited either, so it's allowed 💅
if you go this route, you must first know the IP address of every potential target DLSw peer, and then send each one its own unicast packet 🎀 how you get and keep that list is outside the scope of this paper, so that's a you-problem (not a me-problem 🙈)
and for compliance, implementers need not send SSP packets outbound over UDP, because there are some situations where that's not needed or just isn't a good idea 🌸 BUT implementers are required to provide an option to receive SSP packets over UDP ✨ non-negotiable bestie
6.5 TCP Transport 🫶
okay plot twist: even with UDP now in the mix, TCP is still the main event 👑 it's still what carries all the LLC2 based circuit data, no exceptions
whenever this doc talks about UDP unicast (not multicast), just know TCP might be used instead 🧚 also, it is strongly recommended that TCP be used over UDP whenever a TCP connection to the destination already exists, because it's giving reliable 💜 and implementations should be prepared to receive SSP packets from either transport, TCP or UDP 🌈
7. Migration Support ✨
so some networks are gonna be in a transition phase where both RFC 1795 DLSws (the ones called 'non-multicast' DLSws) and It will be important for these two DLSw node types to interoperate 🍓 which is why the following accommodations for non-multicast DLSws are required 🔥
7.1 Capabilities Exchange 💖
to guarantee both backward and forward capability, DLSws that implement these multicast enhancements will carry a "Multicast Capabilities" Control Vector in their capabilities exchange 🦋 (see RFC 1795 if you want the full explainer on how capabilities exchange works)
having that CV means the peer supports the protocols in this doc, on a per-DLSw-peer basis ✨ and not having it means no support for these extensions, also per peer 💅
also, nodes implementing these enhancements will carry a modified DLSw Version control vector (x'82') that indicates support for version 2 release 0 🎀
and lastly, having these control vectors mandates a TCP Connections Control Vector that indicates support for 1 TCP connection in the same Capabilities exchange 👑
if a multicast capable DLSw gets a Capabilities Exchange CV that includes the Multicast Capabilites CV but doesn't meet the criteria above, it must reject the capabilities exchange by sending a negative response, as described in section 11.1.1 💀 no vibes, just rules
7.2 Connecting to Non-Multicast Capable Nodes 🌸
it's assumed that TCP connections to DLSw peers which don't support multicast services get set up by some means outside this paper's scope (aka the customer configures the non-multicast partner addresses 🍓) TCP connections must be established and maintained to down level nodes in the exact same manner that RFC 1795 requires, establishes, and maintains them 🫶
and because non-multicast DLSw peers won't indicate multicast support in their capabilities exchange, a multicast capable DLSw will still know all of its non-multicast peers 🧚
7.3 Communicating with Multicast Capable Nodes 🦋
okay this one is a lot but it's so good 😭 non-multicast nodes won't receive SSP frames via UDP (unicast OR multicast), so SSP messages to them must be sent over TCP connections 💜 which means nodes implementing the multicast enhancements must keep track of which DLSw peers don't support multicast extensions (as shown in the capabilities exchange) 🔥
when a packet goes out via multicast services, it must also be sent over multicast UDP (to reach the other multicast capable DLSw peers) AND over the TCP connection to each non-multicast node 🎀 multicast needs periodic retransmissions for reliability, but that's NOT the case with TCP connections to non-multicast nodes, so multicast capable DLSws should not resend SSP packets over the TCP transport connection 🌈 instead they rely on TCP to recover any lost packets, which is iconic 👑 and communications with non-multicast nodes should be in exact compliance with RFC 1795 protocols ✨
when you send a unicast UDP message, it's important to know that the destination DLSw supports multicast services 💅 you can get that info from earlier TCP connections and capabilities exchanges, or infer it from a UDP message you already received, but how that info gets obtained is outside this paper's scope 🙈
if you're inferring it from a received UDP message: if the DLSw is non-multicast, there'd be a TCP connection to it and you'd know it's non-multicast 💀 if it's multicast capable and a TCP connection exists, its level is known from the prior capabilities exchange 🌸 and if its capabilities aren't known and there's no existing TCP connection, it can be implied to be multicast capable because of a cached entry with no active TCP connection (like TCP peer on demand support) 🧚
this inference could be wrong, though, in cases where the TCP connection to a non-multicast DLSw has failed for some reason 😭 but normal UDP based unicast verification mechanisms will detect no active path to the destination, and circuit setup will proceed correctly, meaning it succeeds or fails based on true connectivity 🫶
8. SNA Support 🌈
Note: This paper does not attempt to address the unique issues presented by SNA/HPR and its non-ERP data links 🙈
okay so in SNA protocols, the main packet sequence we care about is a test frame exchange followed by an XID exchange 🦋 in every case, DLSw uses the CANUREACH_ex and ICANREACH_ex SSP packets to finish address resolution and circuit establishment 💖 the table below shows how these packets get transported via UDP between two multicast capable DLSw peers 👑
Transport
Message Event Action Mechanism Retry
--------------------------------------------------------------------
TEST SEND CANUREACH_ex Multicast/Unicast Yes
TEST RESPONSE SEND ICANREACH_ex Unicast Nothe next paragraphs go deeper on how UDP transport and the multicast protocol enhancements get used to set up SNA data links 🧚
8.1 Address Resolution 🔥
when a DLSw gets an incoming test frame from an attached data link, the assumption is that it's an exploratory frame getting ready for an XID exchange and link activation 💅 the DLSw must work out a correlation between the destination LSAP (the mac and sap pairing) and some other DLSw in the transport network 🎀 this paper just calls that whole process "address resolution" 🌸
8.2 Explorer frames 🦋
address resolution messages may be sent over a TCP connection to a multicast capable DLSw peer, as long as that connection already exists, so they can take advantage of TCP's guaranteed delivery ✨ this is particularly recommended for ICANREACH_ex frames 💜
8.3 Circuit Setup 💖
circuit setup works the same way as described in RFC 1795 🫶 more specifically, CANUREACH_cs, ICANREACH_cs, REACH_ACK, XIDFRAME, etc. are all sent over the TCP connection to the appropriate DLSw 🧚 this of course assumes a TCP connection already exists between the DLSw peers 🌈 if the sending DLSw (the one sending a CANUREACH_cs) detects no active TCP connection to the DLSw peer, then a TCP connection setup gets initiated and the packet is sent 👑 all other circuit setup (and takedown) related sequences now pass over the TCP connection ✨
8.4 Example SNA SSP Message Sequence 💅
this diagram shows an example sequence of flows for an SNA LLC circuit setup 🎀 all the flows and states here line up exactly with the ones defined in RFC 1795 🍓 the only exception is the extra TCP connection setup and DLSw capabilities exchange that happens when the origin DLSw has to send a CANUREACH_CS and there's no TCP connection to the target DLSw peer yet 😭
====== ___ ======
| | --------- __/ \__ --------- | |
| | __| _|_ |__ / IP \ __| _|_ |__ | |
====== | | | < Network > | | | ======
/______\ --------- \__ __/ --------- /______\
Origin Origin DLSw \___/ Target DLSw Target
Station partner partner Station
disconnected disconnected
TEST_cmd DLC_RESOLVE_C CANUREACH_ex TEST_cmd
-----------> -----------> -----------> ---------->
TEST_rsp DLC_RESOLVE_R ICANREACH_ex TEST_rsp
<--------- <----------- <----------- <----------
null XID DLC_XID
-----------> ----------->
circuit_start
TCP Connection Setup
<------------->
Capabilities Exch.
<------------->
CANUREACH_cs DLC_START_DL
-----------> ----------->
resolve_pending
ICANREACH_cs DLC_DL_STARTED
<----------- <-------------
circuit_established circuit_pending
REACH_ACK
-----------> circuit_established
XIDFRAME DLC_XID null XID
-----------> ---------> -------->
XID DLC_XID XIDFRAME DLC_XID XID
<-------- <----------- <----------- <----------- <--------
XIDs DLC_XIDs XIDFRAMEs DLC_XIDs XIDs
<----------> <----------> <------------> <------------> <--------->
SABME DLC_CONTACTED CONTACT DLC_CONTACT SABME
-----------> -----------> -----------> -----------> -------->
connect_pending contact_pending
UA DLC_CONTACT CONTACTED DLC_CONTACTED UA
<--------- <----------- <----------- <----------- <--------
connected connected
IFRAMEs DLC_INFOs IFRAMEs DLC_INFOs IFRAMEs
<----------> <-----------> <------------> <------------> <-------->8.5 UDP Reliability 😭
heads up, this one's important 🚨 UDP (unicast and multicast) transport services do NOT provide a reliable means of delivery 💀 the existing RFC 1795 protocols guarantee delivery (or failure notification) of CANUREACH_ex and ICANREACH_ex messages, but UDP won't give the same level of reliability 🙈 so these messages may be lost in the network, and (CANUREACH_ex) retries will be necessary 🫶
8.5.1 Retries
okay so test frames are usually sent by end stations every few seconds 🫶 Lots of existing RFC 1795 DLSw implementations are smart about it. They use the reliable SSP TCP connections and filter out the end station's Test frame retries while a CANUREACH_ex is still outstanding. But UDP is unreliable, so that filtering trick may not be advisable anymore 🥺 RFC 1795 and this paper don't really address that, so just know that UDP is flaky and implementations should take it into account when they pick a scheme for Test frame filtering and explorer retries.
So the "Retry" column in the table above is just a hint about where retries might be desirable or necessary. It does not mean you have to implement retries 💅 Also, retry logic only applies to non-response type packets. Retrying response type SSP packets (like ICANREACH_ex) is not appropriate, because there's no way to know if the original response ever arrived (or whether a retry is even needed) 🙈 So for SNA, CANUREACH_ex messages may need retry logic, but ICANREACH_ex messages don't.
9. NetBIOS ✨
with the intro of DLSw Multicast transport, all multicast NetBIOS UI frames get carried outside the TCP connections between DLSw peers. they go over UDP datagrams instead 🦋 The table below lays out the different NetBIOS UI frames and how they travel over UDP between multicast capable DLSw peers:
Transport
Message Event Action Mechanism Retry
---------------------------------------------------------------------------
ADD_GROUP_NAME_QUERY SEND DATAFRAME Multicast Yes
ADD_NAME_QUERY SEND NETBIOS_ANQ Multicast Yes
ADD_NAME_RESPONSE SEND NETBIOS_ANR Unicast1 No
NAME_IN_CONFLICT SEND DATAFRAME Multicast No
STATUS_QUERY SEND DATAFRAME Unicast/Multicast(2) Yes
STATUS_RESPONSE SEND DATAFRAME Multicast(5) No
TERMINATE_TRACE (x'07') SEND DATAFRAME Multicast No
TERMINATE_TRACE (X'13') SEND DATAFRAME Multicast No
DATAGRAM SEND DATAFRAME(3) Unicast/Multicast(2) No
DATAGRAM_BROADCAST SEND DATAFRAME Multicast No
NAME_QUERY SEND NETBIOS_NQ_ex Unicast/Multicast(2) Yes
NAME_RECOGNIZED SEND NETBIOS_NR_ex Unicast(4) NoNote 1: when an ADD_NAME_RESPONSE frame comes in, a NETBIOS_ANR SSP message gets sent back over unicast UDP to whoever originated the NETBIOS_ANQ message 💌
Note 2: these frames can go out as either Unicast or Multicast UDP. If the implementation has enough cached info to resolve the NetBIOS datagram destination to one single DLSw peer, then the SSP message can and should be sent via unicast ✨ If the cache doesn't have that info, the resulting SSP message must be sent via multicast UDP.
Note 3: this frame gets sent as either a DATAFRAME or a DGRMFRAME, following the rules in RFC 1795 🧚
Note 4: when a NAME_RECOGNIZED frame comes in, a NETBIOS_NR_ex SSP message goes back over unicast UDP to whoever originated the NETBIOS_NQ_ex frame. Here's the lowkey wild part: even though NAME_RECOGNIZED is sent as an All Routes Explorer frame (source routing LANs only), the NETBIOS_NR_ex is sent as a unicast UDP directed response to the DLSw that originated the NETBIOS_NQ_ex 🔥 That's because there's zero value in sending NETBIOS_NR_ex as a multicast packet in the transport network. ARE transmission on the LAN side exists to do some kind of load sharing in source routed LANs, and there's no analogous thing in the (TCP) transport network, so there's no need to copy that behavior there. It's important to note, though, that when a received NETBIOS_NR_ex gets converted back into a NAME_RECOGNIZED frame, the DLSw puts that NAME_RECOGNIZED frame onto the LAN as an ARE (source routing LANs only) frame. That keeps the source route load sharing working on both LAN sides of the DLSw transport network 🌈
Note 5: even though RFC 1795 doesn't try to optimize STATUS_RESPONSE processing, a STATUS_RESPONSE can be sent as a unicast UDP response. For that to work, DLSws that receive an incoming SSP DATAFRAME containing a STATUS_QUERY have to remember the originating DLSw's address and the STATUS_QUERY correlator 🧠 Then, when the matching STATUS_RESPONSE shows up, the DLSw replies via unicast UDP to the originating DLSw, using the address it saved. Heads up though: to figure out whether a frame is a STATUS_QUERY, all multicast capable DLSw implementations will need to parse the contents of frames that would normally go out as DATAFRAME SSP messages 👀
All other multicast frames get sent into the transport network using the appropriate multicast group address 🦋
9.1 Address Resolution
typical NetBIOS circuit setup using multicast services is basically the same as what RFC 1795 specifies 💖 The only big difference is that NETBIOS_NQ_ex messages get sent via UDP to the appropriate unicast/multicast IP address, and NETBIOS_NR_ex gets sent via unicast UDP to the DLSw that originated the NETBIOS_NQ_ex.
9.2 Explorer Frames
address resolution messages can be sent over a TCP connection to a multicast capable partner, as long as one already exists 🫶 That way they get to use the guaranteed delivery of TCP. This is especially recommended for NETBIOS_NR_ex frames.
9.3 Circuit Setup
after address resolution works out, a NetBIOS end station usually sends a SABME frame to start a formal LLC2 connection 🌸 When that message arrives, normal circuit setup kicks in, just like RFC 1795 describes (and like the SNA case we covered above). Basically, the CANUREACH_cs messages and so on get sent on a TCP connection to the right DLSw peer. If there isn't one yet, one gets brought up.
9.4 Example NetBIOS SSP Message Sequence
here's a diagram showing an example sequence of flows for a NetBIOS circuit setup 📊 All the flows and states below match up exactly with the ones RFC 1795 defines. The only exception is the TCP connection setup and the DLSw capabilities exchange, which happen when the origin DLSw has to send a CANUREACH_cs and there's no TCP connection to the target DLSw peer yet 🙌
====== ___ ======
| | --------- __/ \__ --------- | |
| | __| _|_ |__ / IP \ __| _|_ |__ | |
====== | | | < Network > | | | ======
/______\ --------- \__ __/ --------- /______\
Origin Origin DLSw \___/ Target DLSw Target
Station partner partner Station
disconnected disconnected
NAME_QUERY DLC_DGRM NETBIOS_NQ_ex DLC_DGRM NAME_QUERY
-----------> -----------> -----------> -----------> --------->
NAME_RECOG DLC_DGRM NETBIOS_NR_ex DLC_DGRM NAME_RECOG
<----------- <------------ <----------- <----------- <---------
SABME DLC_CONTACTED
-----------> ----------->
circuit_start
TCP Connection Setup
<------------->
Capabilities Exch.
<------------->
CANUREACH_cs DLC_START_DL
-----------> ----------->
resolve_pending
ICANREACH_cs DLC_DL_STARTED
<----------- <-----------
circuit_established circuit_pending
REACH_ACK
-----------> circuit_established
CONTACT DLC_CONTACT SABME
-----------> -----------> --------->
connect_pending contact_pending
UA DLC_CONTACT CONTACTED DLC_CONTACTED UA
<--------- <----------- <----------- <----------- <---------
connected connected
IFRAMEs DLC_INFOs IFRAMEs DLC_INFOs IFRAMEs
<------------> <------------> <------------> <------------> <-------->9.5 Multicast Reliability and Retries
okay, so with NetBIOS there are way more packets flying over UDP than in the SNA case 😭 That means the exposure to the unreliability of these services is bigger than it is for SNA. For address resolution frames like NAME_QUERY, getting successful delivery is the main concern. The retry interval for these frames is also a lot shorter than for SNA. The defaults are: retry interval = 0.5 seconds and retry count = 6 ⏱️
Neither RFC 1795 nor this paper tries to deal with LAN frame filtering optimizations. That's outside the scope here. But implementers really need to recognize how inherently unreliable UDP transport is for these frames, and they need to implement retry schemes that actually work for successful operation 💪 Again, retries only make sense for non-response type packets. The NetBIOS messages where successful delivery matters (and retries might be needed) are marked with a "Yes" in the "Retry" column of the table above 🍓
10. Sequencing 🎀
it's important to note that UDP transport services don't guarantee packet sequencing the way TCP does for RFC 1795 💭 In a steady state network, in order delivery can generally be assumed. But when there are network outages or topology changes, packets might take alternate routes to the destination and show up out of sequence compared to the order they were sent in. For SNA address resolution, this shouldn't be a problem, since the order of packets sent via UDP doesn't inherently matter.
For NetBIOS, in order delivery isn't guaranteed in the normal case (like on LANs). That's because LAN broadcasting has the same packet sequencing problems as WAN multicast does. You could argue that topology changes are way more likely in the WAN environment, so there's a bigger concern there 🌍 The vast majority of NetBIOS UI frames (the ones handled via UDP and Multicast) have correlator values and don't rely on packet sequencing ✨
The only NetBIOS frames that are specially worth noting are DATAGRAM, DATAGRAM_BROADCAST, and STATUS_RESPONSE. For DATAGRAM and DATAGRAM_BROADCAST, it's generally assumed that datagrams don't guarantee in order packet delivery, so applications using this NetBIOS service are assumed to have no dependency on in order delivery 🙈 STATUS_RESPONSE can actually be sent as a sequence of STATUS_RESPONSE messages. When that happens, the STATUS_RESPONSE will be exposed to potential out of sequence delivery.
11. Frame Formats 🦋
11.1 Multicast Capabilities Control Vector ✨
Okay bestie, this control vector rides along in the Capabilities Exchange Request 💌. When it shows up, it has to come with a TCP Connections Control Vector saying there's support for 1 TCP/IP connection, and a DLSw version CV saying there's support for version 2 release 0 🎀. Like every control vector in this SSP message, it's an LT structure, which means a 1 byte length field followed by a 1 byte type field. The length field counts itself plus the type and data fields 🧚.
Byte Bit Description
0 0-7 Length, in binary, of the Multicast Capabilities control
vector (inclusive of this byte, always 3)
1 0-7 Type: x'8C'
2 0-7 Multicast Version Number:
A binary numerical representation of the level of
multicast services provided. The protocols as identified
in this document constitute version one. Accordingly,
x'01' is encoded in this field. Any subsequent version
must provide the services of all previous versions.The version number is the level of multicast services being offered 💜. This document's protocols are version one, so that's where x'01' goes. Any later version has to keep providing everything the earlier ones did, no exceptions 🙅♀️.
The big purpose of this CV is spotting when CANUREACH_ex flows are enough between two partners 🦋. If a CAPEX from a partner has this CV in it, that partner is multicast capable too. So it doesn't need CANUREACH_ex messages over the TCP link between them (and there has to be a TCP link, or the CAPEX wouldn't have flowed at all), because it'll get the multicast copies instead 🌈.
This CV is sent on a peer-by-peer basis, which is so cute 🥰. A DLSw might support multicast but decide not to mention it in its capabilities exchange with every partner. So one DLSw could include this CV with some peers and skip it with others. Leaving it out can be used to force TCP connections with other multicast capable nodes and fall back to normal RFC 1795 operations. This is allowed so you get more network design flexibility ⭐.
When sending this capabilities exchange control vector, the following rules apply:
Required Allowed @
ID @ Startup Length Repeatable* Runtime Order Content
==== ========= ====== ========== ======= ===== ===============
0x8C Y 0x03 N N 5+ Multicast
Capabilities
*Note: "Repeatable" means a Control Vector is repeatable within a single
message.11.1.1 DLSw Capabilities Negative Response 🙈
DLSws that implement these enhancements have to support both multicast version 1 and single TCP connections 💅. So the capabilities exchange request must include a DLSw Version ID control vector (x'82') that says version 2 release 0 is supported, a Multicast Capabilities control vector, and a TCP Connections control vector that says 1 TCP connection is supported within that capabilities exchange. If a multicast capable DLSw gets a capabilities exchange with a Multicast Capabilities CV, but the TCP Connections CV is missing or wrong (connections not equal to one) or the DLSw Version control vector is missing or wrong, the inbound capabilities exchange should be rejected. The rejection is a DLSw capabilities exchange negative response (see RFC 1795), using this brand new reason code 😭:
x'000D'Inconsistent DLSw Version, Multicast Capabilities, and TCP
Connections CV received on the inbound Capabilities exchange11.2 UDP Packets 🦋
SSP frame formats are defined in RFC 1795, and the multicast protocol enhancements don't change those formats in any way 🫶. What the multicast enhancements do add is the idea of carrying SSP packets over UDP 🚀. When that happens, standard UDP services and headers are used to transport the SSP packets.
Here's the proper UDP header for DLSw SSP packets:
Byte Description
0-1 Source Port address
In DLSw multicast protocols, this particular field is not
relevant. It may be set to any value.
2-3 Destination Port address
Always set to 2067
4-5 Length
6-7 Checksum
The standard UDP checksum value. Use of the UDP checksum
function is optional.11.3 Vendor Specific UDP Packets 🧁
To make room for vendor specific functions over UDP transport, there's a brand new SSP packet header 🎁. Like we said above, these packets can come in over both UDP and TCP (as long as a TCP connection already exists).
The first 4 bytes of this packet match the format of the existing RFC 1795 SSP packets, and that's on purpose 🥹. It means future implementations can count on the DLSw "Version Number" sitting in byte one, with the bytes after it describing the packet header and message length.
There's also a safety feature here for DLSws trying to notice 'out-of-sync' conditions 🚨. Packet or parsing errors can lead to wrong length interpretations in the TCP datastream, so valid DLSw version numbers are limited to x'31' through x'3F' inclusive.
The DLSw multicast Vendor Specific frame format is different from the RFC 1795 packets in these ways:
- The "Version Number" field is set to x'32' (ASCII '2') and now stands for a packet type more than a DLSw version number. To be exact, DLSw is permitted and expected to send packets of both types (x'31' and x'32') 🌸.
- The message length field is followed by a new 3 byte field holding the specific vendor's IEEE Organizationally Unique Identifier (OUI) 🏷️.
- Everything after the new OUI field is arbitrary and up to the implementers 💜.
Here's the new packet format:
Byte Description
0 DLSw packet type, Always set to x'32'
1 Header Length
Always 7 or higher
2-3 Message Length
Number of bytes within the data field following the
header.
4-6 Vendor specific OUI
The IEEE Organizationally Unique Identifier (OUI)
associated with the vendor specific function in
question.
7-n Defined by the OUI owner12. Compliance Statement 💖
All DLSw v2.0 implementations have to support these two things:
- Halt reason codes
- the Multicast Capabilities control vector in the DLSw capabilities exchange messages
Including the Multicast Capabilities control vector in a capabilities exchange message means the DLSw that sent it supports all the scalability enhancements defined in this document 🤩. Those are:
- use of multicast IP (if it's available in the underlying network) 🌐
- use of 2067 as the destination port for UDP and TCP connections 🔌
- single tunnel bring-up of TCP connections to DLSw peers 🚇
- peer-on-demand 🙋♀️
- quiet ignore of all unrecognized vendor-specific UDP/TCP packets 🤫
13. Security Considerations 💀
This document only addresses scalability problems in RFC 1795, and no attempt is made to define any additional security mechanisms. Be aware, though, that just like in RFC 1795, a given implementation can still choose to refuse TCP connections from DLSw peers the user hasn't configured 🛑. How the user sets that behaviour up isn't specified in this document. Not a thing we're covering here, so go check your own config, bestie 🔐.
14. Acknowledgements 🫶
This specification was developed in the DLSw Related Interest Group (RIG) of the APPN Implementers Workshop 🌟. This RIG is chaired by Louise Herndon- Wells (lhwells@cup.portal.com) and edited by Paul Brittain (pjb@datcon.co.uk) 👑.
Much of the work on the scalability enhancements for v2.0 was developed by Dave Bryant (3COM) 🙌.
Other significant contributors to this document include:
Frank Bordonaro (Cisco)
Jon Houghton (IBM)
Steve Klein (IBM)
Ravi Periasamy (Cisco)
Mike Redden (Proteon)
Doug Wolff (3COM)Huge thanks also to everyone who joined the DLSw RIG sessions and mail exploder discussions 💜.
If you want to join future DLSw discussions, subscribe to the DLSw RIG mailing lists by sending a mail to majordomo@raleigh.ibm.com with 'subscribe aiw-dlsw' as the body of the message 📬.
If you want more info on the AIW's activities, check out the AIW web site at http://www.raleigh.ibm.com/app/aiwhome.htm 🦋.
15. Authors' Addresses 🎀
The editor of this document is:
Paul Brittain
Data Connection Ltd
Windsor House
Pepper Street
Chester
CH1 1DF
UK
tel: +44 1244 313440
email: pjb@datcon.co.ukMuch of the work on this document was created by:
David Bryant
3Com Corporation
5400 Bayfront Plaza MS 2418
Santa Clara, CA 95052
tel: (408) 764-5272
email: David_Bryant@3mail.3com.com16. Appendix - Clarifications to RFC 1795 💅🎀
okay so this appendix is basically the "wait, what did they mean by that?" section for RFC 1795 🙈 people kept getting confused and tripping over the same bits, so these are the fixes, sorted by section number. ngl this doc doesn't copy all of 1795, so you SHOULD read these alongside the real thing 📖
if an implementer is still stuck after that, they can ask the DLSw mail exploder (see section 1.1) for help. bestie, that's what it's for 🫶
3. Send Port 🦋
it is not permitted for a DLSw implementation to check that the send port used by a partner is 2067. like, not allowed 🙅♀️ every implementation MUST accept connections from partners that don't use this port. no gatekeeping ports, periodt 💖
3 TCP Tunnel bringup 🌈
the paragraph under the figure SHOULD read like this:
Each Data Link Switch will maintain a list of DLSw capable routers
and their status (active/inactive). Before Data Link Switching can
occur between two routers, they MUST establish two TCP connections
between them. These connections are treated as half duplex data
pipes. A Data Link Switch will listen for incoming connections on
its Read Port (2065), and initiate outgoing connections on its
Write Port (2067). Each Switch is responsible for initiating one
of the two TCP connections. After the TCP connections are
established, SSP messages are exchanged to establish the
capabilities of the two Data Link Switches. Once the exchange is
complete, the DLSw will employ SSP control messages to establish
end-to-end circuits over the transport connection. Within the
transport connection, DLSw SSP messages are exchanged. The
message formats and types for these SSP messages are documented in
the following sections.3.2 RII bit in SSP header MAC addresses 🧩
the RII bit in MAC addresses that come in from the LAN MUST be set to zero before you forward them into the source or destination address field of an SSP message header. the point is to stop circuit IDs from getting ambiguous, which is so important 😭 it's also RECOMMENDED that all implementations ignore this bit in received SSP message headers.
3.3 Transport IDs 🔥
all implementations MUST allow for the DLSw peer changing the Transport ID up until the ICR_cs message flows. and at all times, they need to reflect the most recent TID they got from the partner in any SSP messages they send. once the ICR_cs message has flowed, the TID cannot change, so lock it in 🔒
3.4 LF bits 🍓
LF-bits SHOULD be propagated from LAN to SSP to LAN (and back) as per a bridge (i.e. they can only be revised downwards at each step if required). basically they only ever go down, never up 📉
3.5 KEEPALIVE messages 💜
the SSP KEEPALIVE message (x1D) uses the short ("infoframe") version of the SSP header. all DLSw implementations MUST support receiving this message and quietly ignoring it, but there is not requirement to send it. and there is no response to a KEEPALIVE message, so don't wait around for one 🙃
3.5 MAC header for Netbios SSP frames 🎀
the MAC header is included in forwarded SSP Netbios frames in the format below, and honestly it's giving very specific vibes:
- addresses are always in non-canonical format
- src/dest addresses are as per the LLC frame
- AC/FC bits MAY be reset and MUST be ignored
- SSAP, DSAP and command fields are included
- RII bit in src address is copied from the LLC frame
- the RIF length is not extended to include padding
- all RIFs are padded to 18 bytes so that the data is in a consistent place.
3.5.7 Unrecognized control vectors 🧚
all implementations SHOULD quietly ignore unrecognized control vectors in any SSP messages. in particular, unrecognized SSP frames or unrecognized fields in a CAPEX message SHOULD be quietly ignored without dropping the TCP connection. don't be dramatic and tear the whole connection down over a little mystery field 💀
5.4 Use of CUR-cs/CUR-ex 🌸
the SSAP and DSAP numbers in CUR_ex messages SHOULD reflect the ones actually used in the TEST (or equivalent) frame that caused the CUR_ex message to flow. so for a 'typical' CUR_ex frame for SNA traffic switched from a LAN, the SAP numbers will be a source SAP of x04 and a destination SAP of x00 ✨
the CUR_cs frame SHOULD only be sent when the DSAP is known. specifically, CUR_ex SHOULD be used when a NULL XID is received that is targeted at DSAP zero, and CUR_cs when an XID specifying the (non-zero) DSAP is received.
BUT (and this is the important part 👀) this does not mean you can assume the DSAP on a CUR_ex will always be zero. the ICR_ex MUST always reflect the SSAP and DSAP values sent on the CUR_ex. this is still true even if an implementation always sends a TEST with DSAP = x00 on its local LAN(s) in response to a CUR_ex to any SAP.
an example of when the CUR_ex might flow with a non-zero DSAP is when there's an APPN stack local to the DLSw node. the APPN stack MAY then issue a connection request specifying the DSAP as a non-zero value, and that gets passed on in the CUR_ex message. 💅
7.6.1 Vendor IDs 🦋
the Vendor ID field in a CAPEX MAY be zero. however, a zero Vendor Context ID is not permitted, which implies that an implementation using a zero ID cannot send any vendor-specific CVs (other than those specified by other vendors that do have a non-zero ID) 🙈
7.6.3 Initial Pacing Window 🌈
the initial pacing window MAY be 1. there is no requirement on an implementation to use any minimum value for the initial pacing window, so no pressure ✨
7.6.7 TCP Tunnel bringup 🔥
the third paragraph SHOULD read:
If TCP Connections CV values agree and the number of connections
is one, then the DLSw with the higher IP address MUST tear down
the TCP connections on its local port 2065. This connection is
torn down after a CAPEX response has been both sent and received.
After this point, the remaining TCP connection is used to exchange
data in both directions.7.7 CAPEX negative responses 🚫
if a DLSw doesn't support any of the options on a CAPEX it gets from a partner, or if it thinks the CAPEX is malformed, it MUST send a CAPEX negative response to the partner. the receiver of a CAPEX negative response is then responsible for dropping the connection. it is not permitted to drop the link instead of sending a CAPEX negative response. no ghosting, bestie 👻
8.2 Flow Control ACKs 🍓
the first flow-control ack (FCACK) does not have to be returned on the REACH_ACK, even if the ICR_cs carried the FCIND bit. however, it SHOULD be returned on the first SSP frame flowing for that circuit after the REACH_ACK. and that's the tea ☕🫶
📦 where this page comes from
- ietf: rfc2166 1997-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms