RFC 1795
Data Link Switching: Switch-to-Switch Protocol AIW DLSw RIG: DLSw Closed Pages, DLSw Standard Version 1
5.4.2 NETBIOS_NQ/NR Explorer FSM The FSM described below is used to handle explorer frames routed by NetBIOS names There is one instance of this FSM for each unique combination of Source Name, Destination Name, Data 2 field and Response Correlator. State Name Description ---------- ----------- RESET The initial state. SENT_EX Local DLSw has issued an explorer message RECEIVED_EX Local DLSw has received an explorer message SENT_REC_EX An explorer frame has been both sent and received for the same (potential) NetBIOS circuit. 5.4.2.1 RESET State +----------------------+---------------------+----------------------+ | Event | Action(s) | Next State | +----------------------+---------------------+----------------------+ | Receive NETBIOS_NQ_ex| DLC_DGRM(NAME_QUERY)| RECEIVED_EX | | | Optionally update | | | | cache. | | +----------------------+---------------------+----------------------+ | Receive NETBIOS_NR_ex| Optionally update | RESET | | | cache | | +----------------------+---------------------+----------------------+ | DLC_DGRM (NAME_QUERY)| Send NETBIOS_NQ_ex | SENT_EX | +----------------------+---------------------+----------------------+ The RESET state is the initial state for the NETBIOS_NQ/NR explorer FSM. It is exited when the DLC receives either a NETBIOS_NQ_ex or a DLC_DGRM containing a NetBIOS NAME_QUERY frame. If a NETBIOS_NQ_ex message is received, the NAME_QUERY is propagated to the DLC and this FSM moves to state RECEIVED_EX. If a NetBIOS NAME_QUERY frame is received, the NETBIOS_NQ_ex is propagated either to the appropriate DLSw partners (see below), and this FSM moves to state SENT_EX. Unlike SNA traffic where the CANUREACH_ex/ICANREACH_ex exchange can be omitted if the MAC location is already cached, NETBIOS_NQ_ex/NETBIOS_NR_ex frames must always be issued during NetBIOS session setup in order that the NetBIOS session numbers are
exchanged correctly between the DLC end stations. If the location of a NetBIOS name is known from cached data, the NETBIOS_NQ_ex need only be issued to the cached DLSw partners. Otherwise the NETBIOS_NQ_ex should be issued to all partners that support NetBIOS. 5.4.2.2 SENT_EX State +----------------------+---------------------+----------------------+ | Event | Action(s) | Next State | +----------------------+---------------------+----------------------+ | Receive NETBIOS_NQ_ex| DLC_DGRM(NAME_QUERY)| SENT_REC_EX | | | Optionally update | | | | cache | | +----------------------+---------------------+----------------------+ | Receive NETBIOS_NR_ex| DLC_DGRM(NAME_RECOG)| RESET | | | Optionally update | | | | cache | | +----------------------+---------------------+----------------------+ | DLC_DGRM (NAME_QUERY)| Send NETBIOS_NQ_ex | SENT_EX | | (different local | Optionally update | | | session number than | cache | | | existing searches) | | | +----------------------+---------------------+----------------------+ SENT_EX is entered when the local DLSw issues a NETBIOS_NQ_ex to its remote DLSw partners. This state is exited when a NETBIOS_NR_ex is received from a remote DLSw, or if a matching NETBIOS_NQ_ex is received from a remote DLSw (i.e., a NETBIOS_NQ_ex crossover case). If the local NetBIOS end station issues a NAME_QUERY with a different session number from any previous NAME_QUERY for this search, the NAME_QUERY is propagated to the DLSw partners to ensure that the exchange of NetBIOS session numbers is handled correctly.
5.4.2.3 RECEIVED_EX State +----------------------+---------------------+----------------------+ | Event | Action(s) | Next State | +----------------------+---------------------+----------------------+ | Receive NETBIOS_NQ_ex| DLC_DGRM(NAME_QUERY)| RECEIVED_EX | | | Optionally update | | | | cache | | +----------------------+---------------------+----------------------+ | Receive NETBIOS_NR_ex| | RECEIVED_EX | +----------------------+---------------------+----------------------+ | DLC_DGRM (NAME_QUERY)| Send NETBIOS_NQ_ex | SENT_REC_EX | | | Optionally update | | | | cache | | +----------------------+---------------------+----------------------+ | DLC_DGRM (NAME_RECOG)| Send NETBIOS_NR_ex | RESET | | | Optionally update | | | | cache | | +----------------------+---------------------+----------------------+ RECEIVED_EX is entered when the local DLSw receives a NETBIOS_NQ_ex message from a remote DLSw. This state is exited when a NAME_RECOGNIZED NetBIOS frame is received from the DLC, completing the query, or when a matching NAME_QUERY is received from DLC (i.e., NAME_QUERY crossover). 5.4.2.4 SENT_REC_EX State +----------------------+---------------------+----------------------+ | Event | Action(s) | Next State | +----------------------+---------------------+----------------------+ | Receive NETBIOS_NQ_ex| DLC_DGRM(NAME_QUERY)| SENT_REC_EX | | | Optionally update | | | | cache | | +----------------------+---------------------+----------------------+ | Receive NETBIOS_NR_ex| DLC_DGRM(NAME_RECOG)| RECEIVED_EX | | | Optionally update | | | | cache | | +----------------------+---------------------+----------------------+ | DLC_DGRM (NAME_QUERY)| Send NETBIOS_NQ_ex | SENT_REC_EX | | (different local | Optionally update | | | session number than | cache | | | existing searches) | | | +----------------------+---------------------+----------------------+ | DLC_DGRM (NAME_RECOG)| Send NETBIOS_NR_ex | SENT_EX | | | Optionally update | | | | cache | | +----------------------+---------------------+----------------------+
This state is required if an implementation wishes to manage NQ/NR crossover cases from a single FSM instance by detecting 'opposite' NAME_QUERY attempts between the same two NetBIOS names. If separate FSM instances are used instead, this state is not required and the transitions to it from other states can be removed. SENT_RCV_EX is exited when the NAME_QUERY search in either direction is resolved. If the local NetBIOS end station issues a NAME_QUERY with a different session number from any previous NAME_QUERY it has issued for this search, the NAME_QUERY is propagated to the DLSw partners to ensure that the exchange of NetBIOS session numbers is correctly handled. 5.4.2.5 NetBIOS Session Numbers NetBIOS NAME_QUERY and NAME_RECOGNIZED frames exchange NetBIOS session numbers between the end stations. For correct NetBIOS operation over DLSw, it is important that all SSP NETBIOS_NQ_ex frames received by a DLSw cause NetBIOS NAME_QUERY frames to flow on the LAN with the new session number from the NETBIOS_NQ_ex. These frames cannot be replied to from a cache of locally available NetBIOS names in the same way that MAC addresses and CANUREACH_ex messages can be handled. Also, NAME_QUERY messages are normally retried several times on the LAN. The generation and absorption of such frames is outside the scope of the FSM defined above. 6. Protocol Flow Diagrams The Switch-to-Switch Protocol is used to setup and take down circuits between a pair of Data Link Switches. Once a circuit is established, the end stations on the local networks can employ LLC Type 1 (connectionless UI frames) protocols end-to-end. In addition, the end systems can establish an end-to-end connection for support of LLC Type 2 (connection oriented I frames) protocols (Type 2 I frames go end-to-end, supervisory frames are handled locally). The term, Data Link, is used in this document to refer to both a "logical data link" when supporting Type 1 LLC services, and a "data link connection" when supporting Type 2 LLC services. In both cases, the Data Link is identified by the Data Link ID defined in section 3.2. NOTE: THIS SECTION CONTAINS EXAMPLES ONLY. IT CANNOT AND DOES NOT SHOW ALL POSSIBLE VARIATIONS AND OPTIONS ON PROTOCOL FLOWS FOR SNA/SDLC, SSP, AND LLC PROTOCOLS.
6.1 Connect Protocols The two basic startup flows from a pure FSM perspective are shown below. The first flow is a startup involving XIDs and the second is one without XIDs. Flow #1 - DLSw Startup With XIDs ====== ___ ====== | | --------- __/ \__ --------- | | | | __| _|_ |__ / IP \ __| _|_ |__ | | ====== | | | < Network > | | | ====== /______\ --------- \__ __/ --------- /______\ Origin Origin DLSw \___/ Target DLSw Target Station partner partner Station disconnected disconnected DLC_RESOLVE_C CANUREACH_ex -----------> -----------> DLC_RESOLVE_R ICANREACH_ex <----------- <----------- DLC_XID CANUREACH_cs DLC_START_DL -----------> -----------> -----------> circuit_start resolve_pending ICANREACH_cs DLC_DL_STARTED <----------- <----------- circuit_established circuit_pending REACH_ACK -----------> circuit_established XIDFRAME DLC_XID -----------> -----------> DLC_XID XIDFRAME DLC_XID <----------- <----------- <----------- DLC_XID XIDFRAME DLC_XID -----------> -----------> -----------> DLC_XIDs XIDFRAMEs DLC_XIDs <------------> <------------> <------------> DLC_CONTACTED CONTACT DLC_CONTACT -----------> -----------> -----------> connect_pending contact_pending
DLC_CONTACT CONTACTED DLC_CONTACTED
<----------- <----------- <-----------
connected connected
DLC_INFOs IFRAMEs DLC_INFOs
<------------> <------------> <------------>
Mapping LAN events to the DLC events and actions on Flow #1 produces
the following flows shown below:
====== ___ ======
| | --------- __/ \__ --------- | |
| | __| _|_ |__ / IP \ __| _|_ |__ | |
====== | | | < Network > | | | ======
/______\ --------- \__ __/ --------- /______\
Origin Origin DLSw \___/ Target DLSw Target
Station partner partner Station
disconnected disconnected
TEST_cmd DLC_RESOLVE_C CANUREACH_ex TEST_cmd
-----------> -----------> -----------> ---------->
TEST_rsp DLC_RESOLVE_R ICANREACH_ex TEST_rsp
<--------- <----------- <----------- <-----------
null XID DLC_XID CANUREACH_cs DLC_START_DL
-----------> -----------> -----------> ----------->
circuit_start resolve_pending
ICANREACH_cs DLC_DL_STARTED
<----------- <-------------
circuit_established circuit_pending
REACH_ACK
-----------> circuit_established
XIDFRAME DLC_XID null XID
-----------> ---------> -------->
XID DLC_XID XIDFRAME DLC_XID XID
<-------- <----------- <----------- <----------- <--------
XIDs DLC_XIDs XIDFRAMEs DLC_XIDs XIDs
<----------> <----------> <------------> <------------> <--------->
SABME DLC_CONTACTED CONTACT DLC_CONTACT SABME
-----------> -----------> -----------> -----------> -------->
connect_pending contact_pending
UA DLC_CONTACT CONTACTED DLC_CONTACTED UA
<--------- <----------- <----------- <----------- <--------
connected connected
IFRAMEs DLC_INFOs IFRAMEs DLC_INFOs IFRAMEs
<----------> <-----------> <------------> <------------> <-------->
Those implementations that prefer to respond to the SABME immediately
could use the same events to do that:
SABME DLC_CONTACTED CONTACT DLC_CONTACT SABME
-----------> -----------> -----------> -----------> -------->
UA connect_pending contact_pending
<---------
RR
----------->
RNR
<---------
RR DLC_CONTACT CONTACTED DLC_CONTACTED UA
<--------- <----------- <----------- <----------- <--------
connected connected
IFRAMEs DLC_INFOs IFRAMEs DLC_INFOs IFRAMEs
<----------> <------------> <------------> <------------> <-------->
Flow #2 - DLSw Startup Without XIDs (circuit setup)
====== ___ ======
| | --------- __/ \__ --------- | |
| | __| _|_ |__ / IP \ __| _|_ |__ | |
====== | | | < Network > | | | ======
/______\ --------- \__ __/ --------- /______\
Origin Origin DLSw \___/ Target DLSw Target
Station partner partner Station
disconnected disconnected
DLC_CONTACTED CANUREACH_cs DLC_START_DL
-----------> -----------> ----------->
circuit_start resolve_pending
ICANREACH_cs DLC_DL_STARTED
<----------- <-----------
circuit_established circuit_pending
REACH_ACK
-----------> circuit_established
CONTACT DLC_CONTACT
-----------> ----------->
connect_pending contact_pending
DLC_CONTACT CONTACTED DLC_CONTACTED
<----------- <----------- <-----------
connected connected
DLC_INFOs IFRAMEs DLC_INFOs
<------------> <------------> <------------>
Mapping LAN events to the DLC events and actions on Flow #2 (and
adding a NETBIOS_NQ and NETBIOS_NR_ex) produces:
====== ___ ======
| | --------- __/ \__ --------- | |
| | __| _|_ |__ / IP \ __| _|_ |__ | |
====== | | | < Network > | | | ======
/______\ --------- \__ __/ --------- /______\
Origin Origin DLSw \___/ Target DLSw Target
Station partner partner Station
disconnected disconnected
NAME_QUERY DLC_DGRM NETBIOS_NQ_ex DLC_DGRM NAME_QUERY
-----------> -----------> -----------> -----------> --------->
NAME_RECOG DLC_DGRM NETBIOS_NR_ex DLC_DGRM NAME_RECOG
<----------- <------------ <----------- <----------- <---------
SABME DLC_CONTACTED CANUREACH_cs DLC_START_DL
-----------> -----------> -----------> ----------->
circuit_start resolve_pending
ICANREACH_cs DLC_DL_STARTED
<----------- <-----------
circuit_established circuit_pending
REACH_ACK
-----------> circuit_established
CONTACT DLC_CONTACT SABME
-----------> -----------> --------->
connect_pending contact_pending
UA DLC_CONTACT CONTACTED DLC_CONTACTED UA
<--------- <----------- <----------- <----------- <---------
connected connected
IFRAMEs DLC_INFOs IFRAMEs DLC_INFOs IFRAMEs
<------------> <------------> <------------> <------------> <-------->
In keeping with a paradigm of 'DLSw is a big 802.2 LAN', all other
DLC types (SDLC for now, QLLC, channel, or whatever in the future)
would be handled by a 'DLC transformation layer' that would transform
the specific protocol's events into the appropriate DLSw DLC events
and DLSw DLC actions into the appropriate protocol actions. The XIDs
that flow in the SSP XIDFRAME should stay 802.2ish (i.e., ABM bit
set) and leave it up to the DLC transformation layer to suit the XID
to its particular DLC type.
Here is an example of a leased SDLC PU 2.0 device as the origin
station. It should use Flow #2 since it is not known if the other
side is a LAN, a switched line or a leased line.
====== ___ ======
| | --------- __/ \__ --------- | |
| | __| _|_ |__ / IP \ __| _|_ |__ | |
====== | | | < Network > | | | ======
/______\ --------- \__ __/ --------- /______\
Origin Origin DLSw \___/ Target DLSw Target
Station partner partner Station
disconnected disconnected
implementer's DLC_RESOLVE_C CANUREACH_ex
choice (power -----------> ----------->
up, configuration
change, DLC_RESOLVE_R ICANREACH_ex
never, <----------- <-----------
connect timer,etc.)
PU 2.0 is
configured
in DLSw to DLC_XID(null) CANUREACH_cs DLC_START_DL
call in -----------> -----------> ----------->
circuit_start resolve_pending
ICANREACH_cs DLC_DL_STARTED
<----------- <-----------
circuit_established circuit_pending
REACH_ACK
-----------> circuit_established
XIDFRAME DLC_XID
-----------> ----------->
DLC_XID XIDFRAME DLC_XID
respond with <----------- <----------- <-----------
XID configured
for station or
forward XID to
station and
send response DLC_XID XIDFRAME DLC_XID
-----------> -----------> ----------->
SNRM DLC_CONTACT CONTACT DLC_CONTACTED
<--------- <----------- <----------- <------------
contact_pending connect_pending
UA DLC_CONTACTED CONTACTED DLC_CONTACT
----------> -----------> -----------> ----------->
connected connected
IFRAMEs DLC_INFOs IFRAMEs DLC_INFOs
<-----------> <------------> <------------> <------------>
Here is an example of a switched SDLC PU 2.0 device as the origin
station.
====== ___ ======
| | --------- __/ \__ --------- | |
| | __| _|_ |__ / IP \ __| _|_ |__ | |
====== | | | < Network > | | | ======
/______\ --------- \__ __/ --------- /______\
Origin Origin DLSw \___/ Target DLSw Target
Station partner partner Station
disconnected disconnected
implementer's DLC_RESOLVE_C CANUREACH_ex
choice (power -----------> ----------->
up, configuration
change, DLC_RESOLVE_R ICANREACH_ex
never, <----------- <-----------
connect timer,etc.)
XID(null) DLC_XID(null) CANUREACH_cs DLC_START_DL
-----------> -----------> -----------> ----------->
circuit_start resolve_pending
ICANREACH_cs DLC_DL_STARTED
<----------- <-----------
circuit_established circuit_pending
REACH_ACK
-----------> circuit_established
XIDFRAME DLC_XID
-----------> ----------->
XID DLC_XID XIDFRAME DLC_XID
<--------- <----------- <----------- <-----------
XID DLC_XID XIDFRAME DLC_XID
---------> -----------> -----------> ----------->
SNRM DLC_CONTACT CONTACT DLC_CONTACTED
<--------- <----------- <----------- <-----------
contact_pending connect_pending
UA DLC_CONTACTED CONTACTED DLC_CONTACT
---------> -----------> -----------> ----------->
connected connected
IFRAMEs DLC_INFOs IFRAMEs DLC_INFOs
<----------> <------------> <------------> <------------>
Here is an example of a leased SDLC PU 2.0 device as the target
station.
====== ___ ======
| | --------- __/ \__ --------- | |
| | __| _|_ |__ / IP \ __| _|_ |__ | |
====== | | | < Network > | | | ======
/______\ --------- \__ __/ --------- /______\
Origin Origin DLSw \___/ Target DLSw Target
Station partner partner Station
(SDLC)
disconnected disconnected
DLC_RESOLVE_C CANUREACH_ex
-----------> -----------> reply if virtual MAC/SAP
for SDLC station is
configured, if SDLC
station responds to
DLC_RESOLVE_R ICANREACH_ex TEST/SNRM/DISC, etc.
<----------- <-----------
DLC_XID CANUREACH_cs DLC_START_DL SNRM
-----------> -----------> -----------> --------->
circuit_start resolve_pending
ICANREACH_cs DLC_DL_STARTED UA
<----------- <----------- <-------
circuit_established circuit_pending
RNR
REACH_ACK --------->
-----------> circuit_established
XIDFRAME DLC_XID
-----------> -----------> respond with
XID configured
for station
or forward
XID to
station and
send
DLC_XID XIDFRAME DLC_XID response
<----------- <----------- <-----------
DLC_CONTACTED CONTACT DLC_CONTACT RR
-----------> -----------> -----------> --------->
connect_pending contact_pending
DLC_CONTACT CONTACTED DLC_CONTACTED
<----------- <----------- <-----------
connected connected
DLC_INFOs IFRAMEs DLC_INFOs IFRAMEs
<------------> <------------> <------------> <------->
Here is an example of a switched SDLC PU 2.0 device as the target
station.
====== ___ ======
| | --------- __/ \__ --------- | |
| | __| _|_ |__ / IP \ __| _|_ |__ | |
====== | | | < Network > | | | ======
/______\ --------- \__ __/ --------- /______\
Origin Origin DLSw \___/ Target DLSw Target
Station partner partner Station
(SDLC)
disconnected disconnected
DLC_RESOLVE_C CANUREACH_ex
-----------> -----------> reply if virtual MAC/SAP
for SDLC station is
configured, if SDLC
station responds to
DLC_RESOLVE_R ICANREACH_ex TEST/XID/SNRM/DISC, etc.
<----------- <-----------
DLC_XID CANUREACH_cs DLC_START_DL XID
-----------> -----------> -----------> --------->
circuit_start resolve_pending
ICANREACH_cs DLC_DL_STARTED XID
<----------- <----------- <--------
circuit_established circuit_pending
REACH_ACK
-----------> circuit_established
XIDFRAME DLC_XID
-----------> -----------> respond
with XID
received
DLC_XID XIDFRAME DLC_XID above
<----------- <----------- <---------
DLC_CONTACTED CONTACT DLC_CONTACT SNRM
-----------> -----------> -----------> --------->
connect_pending contact_pending
DLC_CONTACT CONTACTED DLC_CONTACTED UA
<----------- <----------- <----------- <--------
connected connected
DLC_INFOs IFRAMEs DLC_INFOs IFRAMEs
<------------> <------------> <------------> <-------->
Here is an example of an SDLC T2.1 device as the target station.
(SDLC T2.1 origin station would look just like the LAN T2.1 origin
station)
====== ___ ======
| | --------- __/ \__ --------- | |
| | __| _|_ |__ / IP \ __| _|_ |__ | |
====== | | | < Network > | | | ======
/______\ --------- \__ __/ --------- /______\
Origin Origin DLSw \___/ Target DLSw Target
Station partner partner Station
disconnected disconnected
DLC_RESOLVE_C CANUREACH_ex
-----------> -----------> implementer's choice
(virtual MAC/SAP
configured,
check to see if station
is powered up using
DLC_RESOLVE_R ICANREACH_ex TEST/XID/DISC, etc.)
<----------- <-----------
DLC_XID CANUREACH_cs DLC_START_DL null XID
-----------> -----------> -----------> --------->
circuit_start resolve_pending
ICANREACH_cs DLC_DL_STARTED XID
<----------- <----------- <-------
circuit_established circuit_pending
REACH_ACK
-----------> circuit_established
XIDFRAME DLC_XID
-----------> -----------> respond with
XID received
DLC_XID XIDFRAME DLC_XID above
<----------- <----------- <----------
DLC_XIDs XIDFRAMEs DLC_XIDs XIDs
<------------> <------------> <------------> <-------->
DLC_CONTACTED CONTACT DLC_CONTACT SNRM
-----------> -----------> -----------> --------->
connect_pending contact_pending
DLC_CONTACT CONTACTED DLC_CONTACTED UA
<----------- <----------- <----------- <-------
connected connected
DLC_INFOs IFRAMEs DLC_INFOs IFRAMEs
<------------> <------------> <------------> <-------->
6.2 Link Restart Protocols The following figure depicts the protocol flows that result from restarting the end-to-end connection. This causes the Data Link Switches to terminate the existing connection and to enter the Circuit Established state awaiting the start of a new connection. Data Link Data Link Data Link Data Link Control Switch Switch Control --------------------- --------------------- +-----------+ +-----------+ | Connected | | Connected | SABME +-----------+ +-----------+ -----------> RESTART_DL DM -------------------------------------> DISC <----------- --------> UA DL_RESTARTED (Case 1) <-------- <------------------------------------- +-----------+ +-----------+ |Circuit Est| |Circuit Est| +-----------+ +-----------+ ........... or ........... SABME -----------> DL_RESTARTED (Case 2) UA <------------------------------------- <----------- +-----------+ |Circuit Est| CONTACT +-----------+ RNR ------------------------------------> <---------- Figure 5. DLSw Link Restart Message Protocols Upon receipt of a SABME command from the origin station, the origin DLSw will send a RESTART_DL message to the target DLSw. A DM response is also returned to the origin station and the data link is restarted. Upon receipt of the RESTART_DL message, the target DLSw will issue a DISC command to the target station. The target station is expected to return a UA response. The target DLSw will then restart its data link and send an DL_RESTARTED message back to the origin DLSw. During this exchange of messages, both Data Link Switches change states from Connected state to Circuit Established state. If the origin station now resends the SABME command, the origin DLSw will send a CONTACT message to the target DLSw. If the SABME command
is received prior to the receipt of the DL_RESTARTED message (case 2 in the figure), the CONNECT message is delayed until the DL_RESTARTED message is received. The resulting protocol flows at this point parallel those given above for the connect sequence. 6.3 Disconnect Protocols The following figure depicts the protocol flows that result from the end system terminating an existing connection. Not only is the connection terminated, but the circuit between the Data Link Switches is taken down. Data Link Data Link Data Link Data Link Control Switch Switch Control -------------------- -------------------- +-----------+ +-----------+ | Connected | | Connected | +-----------+ +-----------+ DISC ----------> HALT_DL UA -------------------------------------> DISC <---------- ---------> UA DL_HALTED <-------- <------------------------------------- +-----------+ +-----------+ |Disconnectd| |Disconnectd| +-----------+ +-----------+ ......... or .......... +-----------+ +-----------+ | Connected | | Connected | +-----------+ +-----------+ DISC TCP Connection Failure DISC <-------- <------------------------------------> ---------> UA UA --------> <-------- +-----------+ +-----------+ |Disconnectd| |Disconnectd| +-----------+ +-----------+ Figure 6. DLSw Disconnect Message Protocols Upon receipt of a DISC command from the origin station, the origin DLSw will reply with a UA response and issue a HALT_DL message to the target DLSw. Upon receipt of the HALT_DL message, the target DLSw will send a DISC command to the target station. The target station
will then respond with a UA response, causing the target DLSw to return a DL_HALTED message to the origin DLSw. During this exchange of messages, both Data Link Switches change states from the Connected state to the Disconnected state. If the TCP connection between two Data Link Switches fails, all connections that are currently multiplexed on the failed TCP connection will be taken down. This implies that both Data Link Switches will send DISC commands to all the local systems that are associated with the failed connections. Upon sending the DISC command, the Data Link Switch will enter the DISCONNECTED state for each circuit. 7.0 Capabilities Exchange Formats/Protocol The Data Link Switching Capabilities Exchange is a special DLSw Switch-to-Switch control message that describes the capabilities of the sending data link switch. This control message is sent after the switch-to-switch connection is established and optionally during run time if certain operational parameters have changed and need to be communicated to the partner switch. The actual contents of the Capabilities Exchange is in the data field following the SSP message header. The Capabilities Exchange itself is formatted as a single General Data Stream (GDS) Variable with multiple type "LT" structured subfields. The SSP Message Header has the following fields set for the Capabilities Exchange: Offset Field Value ------ ----- ----- 0x00 Version Number 0x31 0x01 Header Length 0x48 (decimal 72) 0x02 Message Length same as LL in GDS Variable 0x14 Message Type 0x20 (CAP_EXCHANGE) 0x16 Protocol Id 0x42 0x17 Header Number 0x01 0x23 Message Type 0x20 (CAP_EXCHANGE) 0x38 Direction 0x01 for CapEx request 0x02 for CapEx response Other fields in the SSP header are not referenced and should be set to zero.
The DLSw Capabilities Exchange Request has the following overall
format:
+----+----+-----------------+
| LL | ID | Control Vectors |
+----+----+-----------------+
0-1 Length, in binary, of the DLSw Capabilities
Exchange
Request GDS Variable. The value of LL is
the sum of the length of all fields in the
GDS Variable (i.e., length of LL + length of ID
+ length of Control Vectors).
2-3 GDS Id: 0x1520
4-n Control Vectors consisting of type LT structured
subfields (i.e., the DLSw Capabilities Exchange
Structured Subfields)
Type LT structured subfields consist of a 1-byte length field (the
"L"), a 1-byte type field (the "T") and n-bytes of data. The length
field includes itself as well as the structured subfield. The
structured subfield consists of the type field and data so the length
is n + 2. This imposes a length restriction of 253 bytes on all data
contained in a structured subfield.
7.1 Control Vector Id Range Control Vector identifiers (i.e., Type) in the range of 0x80 through 0xCF are reserved for use by the Data Link Switching standard. Control Vector identifiers (i.e., Type) in the range of 0xD0 through 0xFD are used for vendor-specific purposes. Currently defined vectors are: Vector Description Hex Value Vendor Id Control Vector 0x81 DLSw Version Control Vector 0x82 Initial Pacing Window Control Vector 0x83 Version String Control Vector 0x84 Mac Address Exclusivity Control Vector 0x85 Supported SAP List Control Vector 0x86 TCP Connections Control Vector 0x87 NetBIOS Name Exclusivity Control Vector 0x88 MAC Address List Control Vector 0x89 NetBIOS Name List Control Vector 0x8A Vendor Context Control Vector 0x8B Reserved for future use 0x8C - 0xCF Vendor Specific 0xD0 - 0xFD 7.2 Control Vector Order and Continuity Since their contents can greatly affect the parsing of the Capabilities Exchange GDS Variable, the required control vectors must occur first and appear in the following order: Vendor Id, DLSw Version Number, Initial Pacing Window, Supported SAP List. The remainder of the Control Vectors can occur in any order. Control Vectors that can be repeated within the same message (e.g., MAC Address List Control Vector and NetBIOS Name List Control Vector) are not necessarily adjacent. It is advisable, but not required, to have the Exclusivity Control Vector occur prior to either of the above two vectors so that the use of the individual MAC addresses or NetBIOS names will be known prior to parsing them. Both the Vendor Context and Vendor Specific control vectors can be repeated. If there are multiple instances of the Vendor Context control vector, the specified context remains in effect for all Vendor Specific control vectors until the next Vendor Context control vector is encountered in the Capabilities Exchange.
7.3 Initial Capabilities Exchange Capabilities exchange is always the first SSP message sent on a new SSP connection between two DLSw switches. This initial Capabilities Exchange is used to identify the DLSw version that each switch is running and other required information, plus details of any optional extensions that the switches are capable of supporting. If a DLSw receives an initial capabilities message that is incorrectly formatted or contains invalid or unsupported data that prevents correct interoperation with the partner DLSw, it should issue a Capabilities Exchange negative response. If a DLSw receives a negative response to its initial capabilities message, it should take down its TCP connections with the offended partner. Note: Pre v1.0 DLSw implementations do not send or respond to capabilities messages and can be identified by the lack of capabilities exchange as the first message on a new SSP connnection. This document does not attempt to specify how to interoperate with back-level DLSw implementations. 7.4 Run-Time Capabilities Exchange Capabilities exchange always occurs when the SSP connection is started between two DLSw switches. Capabilities Exchange can also occur at run-time, typically when a configuration change is made. Support for run-time Capabilities Exchange is optional. If a node does not support receiving/using Run-Time Capabilities Exchange and receives one, it should discard it quietly (not send back a negative response). If a node supports receipt of run-time capabilities, it should send a positive or negative response as appropriate. The receiver of a negative response to a run-time capabilities message is not required to take down its TCP connections with the offended partner. Run-time Capabilities Exchange can consist of one or more of the following control vectors. Note that the control vectors required at start-up are not present in a run-time Capabilities Exchange.
1. MAC Address Exclusivity CV,
2. NetBIOS Name Exclusivity CV,
3. MAC Address List CV,
4. NetBIOS Name List CV,
5. Supported SAP List CV,
6. Vendor Context CV,
7. Vendor Specific CVs
A run-time capabilities exchange is a replacement operation. As
such, all pertinent MAC addresses and NetBIOS names must be specified
in the run-time exchange. In addition, run-time changes in
capabilities will not effect existing link station circuits.
7.5 Capabilities Exchange Filtering Responsibilities
Recipients of the SAP, MAC, and NetBIOS lists are not required to
actually use them to filter traffic, etc., either initially or at
run-time.
7.6 DLSw Capabilities Exchange Structured Subfields
The Capabilities Exchange Subfields are listed in the table below and
are described in the following sections:
Required Allowed @
ID @ Startup Length Repeatable* Runtime Order Content
==== ========= ====== ========== ======= ===== ===============
0x81 Y 0x05 N N 1 Vendor ID
0x82 Y 0x04 N N 2 DLSw Version
0x83 Y 0x04 N N 3 Initial pacing
window
0x84 N >=0x02 N N 5+ Version String
0x85 N 0x03 N Y 5+ MAC Address
Exclusivity
0x86 Y 0x12 N Y 4 Supported SAP
List
0x87 N 0x03 N N 5+ TCP Connections
0x88 N 0x03 N Y 5+ NetBIOS Name
Exclusivity
0x89 N 0x0E Y Y 5+ MAC Address
List
0x8A N <=0x13 Y Y 5+ NetBIOS Name
List
0x8B N 0x05 Y Y 5+ Vendor Context
0xD0 N varies Y Y 5+ Vendor Specific
*Note: "Repeatable" means a Control Vector is repeatable within a single
message.
7.6.1 Vendor Id (0x81) Control Vector
The Vendor Id control vector identifies the manufacturer's IEEE
assigned Organizationally Unique Identifier (OUI) of the Data Link
Switch sending the DLSw Capabilities Exchange. The OUI is sent in
non-canonical (Token-Ring) format. This control vector is required
and must be the first control vector.
Offset Length Value Contents
------ ------ ----- --------
0 1 0x05 Length of the Vendor Id structured
subfield
1 1 0x81 key = 0x81 that identifies this as the
Vendor Id structured subfield
2-4 3 the 3-byte Organizationally Unique
Identifier (OUI) for the vendor
(non-canonical format)
7.6.2 DLSw Version (0x82) Control Vector
The DLSw Version control vector identifies the particular version of
the DLSw standard supported by the sending Data Link Switch. This
control vector is required and must follow the Vendor Id Control
Vector.
Offset Length Value Contents
------ ------ ----- --------
0 1 0x04 Length of the Version String structured
subfield
1 1 0x82 key = 0x82 that identifies this as the
DLSw Version structured subfield
2 1 the hexadecimal value representing the
DLSw standard Version number of the
sending Data Link Switch.
0x01 (indicates version 1 - closed pages)
3 1 the hexadecimal value representing the
DLSw standard Release number of the
sending Data Link Switch.
0x00 (indicates release 0)
7.6.3 Initial Pacing Window (0x83) Control Vector
The Initial Pacing Window control vector specifies the initial value
of the receive pacing window size for the sending Data Link Switch.
This control vector is required and must follow the DLSw Version
Control Vector.
Offset Length Value Contents
------ ------ ----- --------
0 1 0x04 Length of the Initial Pacing Window
structured subfield
1 1 0x83 key = 0x83 that identifies this
as the Initial Pacing Window
structured subfield
2-3 2 the pacing window size, specified
in byte normal form..
Note: The pacing window size must be non-zero.
7.6.4 Version String (0x84) Control Vector
The Version String control vector identifies the particular version
number of the sending Data Link Switch. The format of the actual
version string is vendor-defined. This control vector is optional.
Offset Length Value Contents
------ ------ ----- --------
0 1 0xn Length of the Version String
structured subfield
1 1 0x84 key = 0x84 that identifies
this as the Version String
structured subfield
2-n n-2 the ASCII string that identifies
the software version for the
sending DLSw.
7.6.5 MAC Address Exclusivity (0x85) Control Vector
The MAC Address Exclusivity control vector identifies how the MAC
Address List control vector data is to be interpreted. Specifically,
this control vector identifies whether the MAC addresses in the MAC
Address List control vectors are the only ones accessible via the
sending Data Link Switch.
If a MAC Address List control vector is specified and the MAC Address
Exclusivity control vector is missing, then the MAC addresses are not
assumed to be the only ones accessible via this switch.
A node may specify that it supports no local MAC addresses by
including in its capabilities the MAC Address List Exclusivity CV
(with byte 2 == 0x01), and not including any instances of the MAC
Address List CV.
Offset Length Value Contents
------ ------ ----- --------
0 1 0x03 Length of the Exclusivity structured
subfield
1 1 0x85 key = 0x85 that identifies this as the
MAC address Exclusivity structured
subfield
2 1 an indicator of the relationship of the
MAC addresses to the sending Data Link
Switch.
0x00 the MAC addresses specified in
this Capabilities Exchange
can be accessed via this
switch but are not the
exclusive set (i.e., other
entities are accessible in
addition to the ones specified)
0x01 the MAC addresses specified in
this Capabilities Exchange
are the only ones accessible
via this switch.
(next page on part 4)
