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.
7.6.6 SAP List Support (0x86) Control Vector
The SAP List Support control vector identifies support for Logical
Link Control SAPs (DSAPs and SSAPs) by the sending Data Link Switch.
This is used by the DLSw that sent the SAP List Support control
vector to indicate which SAPs can be used to support SNA and
optionally NetBIOS traffic. This may be used by the DLSw that
receives the SAP list to filter explorer traffic (TEST, XID, or
NetBIOS UI frames) from the DLSw state machine. For SNA, a DLSw
should set bits for all SAP values (SSAP or DSAP) that may be used
for SNA traffic. For NetBIOS support, the bit for SAP 0xF0 should be
set (if not supported then the same bit should be cleared).
Each bit in the SAP control vector data field represents a SAP as
defined below. This vector is required and must follow the Initial
Pacing Window Control Vector.
Offset Length Value Contents
------ ------ ----- --------
0 1 0x12 Length of the Supported SAP List structured
subfield
1 1 0x86 key = 0x86 that identifies this as the
Supported SAP List structured subfield
2-17 16 the 16-byte bit vector describing all
even numbered SAPs enabled.
Each Bit within the 16 byte bit vector will
indicate whether an even numbered SAP is
enabled (b'1') or disabled (b'0').
Each Byte within the 16 byte bit vector
will be numbered from 0 - F. (Most
significant byte first).
Byte 0 1 2 3 ... F
XX XX XX XX ... XX
The bits in each byte indicate whether an
even numbered SAP is enabled (b'1') or
disabled (b'0'). (Most significant bit first)
Bits 7 6 5 4 ... 0
SAP 0 2 4 6 ... E
By combining the byte label with the enabled
bits, all supported SAPs can be determined.
In the following diagram, 'n' would equal 0
through F depending on which byte was being
interpreted.
Bit ordering is shown below with bit
7 being the most significant bit and bit
0 the least significant bit.
7654 3210
bbbb bbbb....
|||| ||||
|||| |||SAP 0xnE enabled or not
|||| |||
|||| ||SAP 0xnC enabled or not
|||| ||
|||| |SAP 0xnA enabled or not
|||| |
|||| SAP 0xn8 enabled or not
||||
|||SAP 0xn6 enabled or not
|||
||SAP 0xn4 enabled or not
||
|SAP 0xn2 enabled or not
|
SAP 0xn0 enabled or not
An example of using all User Definable SAPs of 0x04 to 0xEC for SNA
Data Link Switching and SAP 0xF0 for NetBIOS Data Link Switching
would be as follows:
Offset SAPs Binary Hex
0 4,8,C 0010 1010 0x2A
1 10,14,18,1C 1010 1010 0xAA
2 20,24,28,2C 1010 1010 0xAA
3 30,34,38,3C 1010 1010 0xAA
4 40,44,48,4C 1010 1010 0xAA
5 50,54,58,5C 1010 1010 0xAA
6 60,64,68,6C 1010 1010 0xAA
7 70,74,78,7C 1010 1010 0xAA
8 80,84,88,8C 1010 1010 0xAA
9 90,94,98,9C 1010 1010 0xAA
A A0,A4,A8,AC 1010 1010 0xAA
B B0,B4,B8,BC 1010 1010 0xAA
C C0,C4,C8,CC 1010 1010 0xAA
D D0,D4,D8,DC 1010 1010 0xAA
E E0,E4,E8,EC 1010 1010 0xAA
F F0 1000 0000 0x80
7.6.7 TCP Connections (0x87) Control Vector
The TCP Connections control vector indicates the support of an
alternate number of TCP Connections for the Data Link Switching
traffic. The base implementation of Data Link Switching supports two
TCP Connections, one for each direction of data traffic.
This control vector is optional. If it is omitted in a DLSw
Capabilities Exchange, then two TCP Connections are assumed. It is
further assumed that if a Data Link Switch can support one TCP
Connection, it can support two TCP Connections.
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.
The format of the TCP Connections Control Vector is shown below:
Offset Length Value Contents
------ ------ ----- --------
0 1 0x03 Length of the TCP Connections structured
subfield
1 1 0x87 key = 0x87 that identifies this as the
TCP Connections structured subfield
2 1 an indicator of the support for an
alternate number of TCP Connections by
the sending Data Link Switch.
0x01 the number of TCP Connections
may be brought down to one
after Capabilities Exchange
is completed.
0x02 the number of TCP Connections
will remain at two for
the duration of the DLSw
connection.
7.6.8 NetBIOS Name Exclusivity (0x88) Control Vector
The NetBIOS Name Exclusivity control vector identifies how the
NetBIOS Name List control vector data is to be interpreted.
Specifically, this control vector identifies whether the NetBIOS
Names in the NetBIOS Name List control vectors are the only ones
accessible via the sending Data Link Switch.
If a NetBIOS Name List control vector is specified and the NetBIOS
Name Exclusivity control vector is missing, then the NetBIOS Names
are not assumed to be the only ones accessible via this switch.
A node may specify that it supports no local NetBIOS names by
including in its capabilities the NetBIOS Name List Exclusivity CV
(with byte 2 == 0x01), and not including any instances of the NetBIOS
Name List CV.
Offset Length Value Contents
------ ------ ----- --------
0 1 0x03 Length of the Exclusivity structured
subfield
1 1 0x88 key = 0x88 that identifies this as the
NetBIOS Name Exclusivity structured
subfield
2 1 an indicator of the relationship of the
NetBIOS Names to the sending Data Link
Switch.
0x00 the NetBIOS Names 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 NetBIOS Names specified in
this Capabilities Exchange
are the only ones accessible
via this switch.
7.6.9 MAC Address List (0x89) Control Vector
The MAC Address List control vector identifies one or more MAC
addresses that are accessible through the sending Data Link Switch.
This control vector specifies a single MAC address value and MAC
address mask value to identify the MAC address or range of MAC
addresses. MAC addresses and masks are in non-canonical (Token-Ring)
format in this control vector.
This control vector is optional and can be repeated if necessary.
Note 1: If a particular MAC address, <mac-addr>, satisfies the
following algorithm, then <mac-addr> is assumed to be accessible via
the sending Data Link Switch:
<mac-addr> & <mac-addr-mask> == <mac-addr-value>
where: <mac-addr-value> is the MAC Address
Value specified in
this control vector
<mac-addr-mask> is the MAC Address
Mask specified in
this control vector
Note 2: If an individual MAC Address is desired, then <mac-addr-
value> should be the individual MAC address and <mac-addr-mask>
should be 0xFFFFFFFFFFFF.
Offset Length Value Contents
------ ------ ----- --------
0 1 0x0E Length of the MAC Address List
structured subfield
1 1 0x89 key = 0x89 that identifies this as the
MAC Address List structured subfield
2-7 6 the 6-byte MAC Address Value,
<mac-addr-value> in the above formula
8-13 6 the 6-byte MAC Address Mask,
<mac-addr-mask> in the above formula
7.6.10 NetBIOS Name List (0x8A) Control Vector
The NetBIOS Name List control vector identifies one or more NetBIOS
names that are accessible through the sending Data Link Switch. This
control vector specifies a single NetBIOS name in ASCII. However,
the NetBIOS name can consist of "don't care" and "wildcard"
characters to match on a number of NetBIOS names. If an individual
character position in the NetBIOS name in this control vector
contains a '?', then the corresponding character position in real
NetBIOS name is a "don't care". If a NetBIOS name in this control
vector ends in '*', then the remainder of real NetBIOS names is a
"don't care". '*' is only considered a wildcard if it appears at the
end of a name.
All blanks or nulls at the end of NetBIOS names in this control
vector are ignored. NetBIOS names which have fewer than 16 bytes
and which do not end with '*' are not assumed to have a trailing
'*'; the "wildcard" character must be explicit.
NetBIOS group names can exist across several LANs/networks. As such,
NetBIOS group names received in a NetBIOS Name List Control Vector
can not be treated the same as NetBIOS individual names. The
Individual/Group Flag allows Data Link Switches to distinguish
between the two.
This control vector is optional and can be repeated if necessary.
Offset Length Value Contents
------ ------ ----- --------
0 1 0xn Length of the NetBIOS Name List
structured subfield (maximum = 0x13)
1 1 0x8A key = 0x8A that identifies this as the
NetBIOS Name List structured subfield
2 1 Individual/Group Flag
0x00 - Individual NetBIOS Name
0x01 - Group NetBIOS Name
3-n n-3 the NetBIOS name with possible embedded
'?' and terminating '*'.
7.6.11 Vendor Context (0x8B) Control Vector
The Vendor Context 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 optional and is used to provide the context
for any Vendor Specific control vectors that follow in the
Capabilities Exchange. 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.
Offset Length Value Contents
------ ------ ----- --------
0 1 0x05 Length of the Vendor Context structured
subfield
1 1 0x8B key = 0x8B that identifies this as the
Vendor Context structured subfield
2-4 3 the 3-byte Organizationally Unique
Identifier (OUI) for the vendor
(non-canonical format)
7.7 Capabilities Exchange Responses
There are two kinds of DLSw Capabilities Exchange Responses: positive
and negative. A positive response is returned to the sending Data
Link Switch if there were no errors encountered in the DLSw
Capabilities Exchange Request. A negative response is returned if
there is at least one error encountered.
A positive DLSw Capabilities Exchange Response has the following
overall format:
+----+----+
| LL | ID |
+----+----+
0-1 Length, in binary, of the DLSw Capabilities
Exchange Response GDS Variable. The value of
LL in this case is 0x0004.
2-3 GDS Id: 0x1521
A negative DLSw Capabilities Exchange Response has the following
overall format:
+----+----+--------+--------+
| LL | ID | Offset | Reason |
+----+----+--------+--------+
0-1 Length, in binary, of the DLSw Capabilities Exchange
Response 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 Offsets/Reasons).
2-3 GDS Id: 0x1522
4-5 Offset into the DLSw Capabilities Exchange Request of the
error. Offset should always point to the start of the
GDS Variable or a specific control vector.
6-7 Reason code that uniquely identifies the error. Specific
values for the reason code are:
0x0001 invalid GDS length for a DLSw Capabilities
Exchange Request. (The value of Offset
is ignored.)
0x0002 invalid GDS id for a DLSw Capabilities
Exchange Request. (The value of Offset
is ignored.)
0x0003 Vendor Id control vector is missing. (The
value of Offset is ignored.)
0x0004 DLSw Version control vector is missing. (The
value of Offset is ignored.)
0x0005 Initial Pacing Window control vector is
missing. (The value of Offset is ignored.)
0x0006 length of control vectors doesn't correlate
to the length of the GDS variable
0x0007 invalid control vector id
0x0008 length of control vector invalid
0x0009 invalid control vector data value
0x000A duplicate control vector (for non-repeating
control vectors)
0x000B out-of-sequence control vector (for
repeating control vector)
0x000C DLSw Supported SAP List control vector is
missing.
(The value of Offset is ignored.)
Note: Multiple Offset, Reason pairs can be returned with one pair
for each error encountered.
8. Pacing/Flow Control
This section describes the required Pacing and Flow Control
mechanisms used by a Data Link Switch.
While it is beyond the scope of this document to specify a policy for
how an implementation maps SSP flow control to the native data link
flow control at the edges, the following paragraphs describe a
general philosophical overview of how the mechanism is to be applied.
There are two types of flows which are covered by the flow control
mechanism: connection-oriented and connectionless. In the first,
connection-oriented flows, the implementer is to map the native flow
control mechanism of the two data links at the boundaries to the SSP
flow control mechanism thus presenting an end-to-end flow control
mechanism which "pushes back" all the way to the originating station
in either direction.
However, in the case of connectionless traffic, this is not possible
at the data link level because there is no native flow control
mechanism for connectionless data links. At first glance it is
tempting to allow connectionless traffic to flow the DLSw cloud
unthrottled. However, the rationale for subjecting these flows to
flow control within the DLSw cloud is to "push" the discarding of
frames (should this become necessary) back to the ingress of the DLSw
cloud. This "early discarding" of excessive DATAGRAMs should allow
the cloud to remain deterministic without wasting network bandwidth.
8.1 Basic Overview
Each circuit consists of two data flows, one in each direction. Each
data flow has its own independent flow control mechanism. For each
data flow there is an entity that originates traffic, referred to as
the sender, and a target entity which receives the traffic, referred
to as the receiver.
A sender may only send data when its receiver has granted explicit
permission to send a discrete number of data units. Data units are
defined as either a DGRMFRAME or an INFOFRAME.
The receiver grants permission to send data units by sending a Flow
Control Indicator (FCIND- defined later). The sender must
acknowledge all FCINDs by sending a Flow Control Acknowledgment
(FCACK- defined later).
A sending implementation must maintain these values:
1. GrantedUnits - The number of units (frames) which the sender
currently has permission to send.
2. CurrentWindow - This is a discrete number of units, controlled by
the receiver, which is basis for granting additional units.
3. InitialWindowSize - Global for all circuits on a transport
connection. Learned in capabilities exchange when the transport
connection is established. It specifies an initial value for
CurrentWindow when each circuit is established.
A receiving implementation must maintain these values:
1. CurrentWindow - This is a discrete number of units, controlled by
the receiver, which is basis for granting additional units.
2. InitialWindowSize - Global for all circuits on a transport
connection. Sent in capabilities exchange when the transport
connection is established. It specifies an initial value for
CurrentWindow when each circuit is established.
3. FCACKOwed - The sender owes an FCACK. If true, no FCIND may be
sent.
8.2 Frame Format
The Flow control Byte is contained at offset 15 in both the
Information and Control SSP messages. From a flow control
perspective, the flow control information in the two frames are
handled identically.
The following diagram describes the format of the Flow Control Byte
(Bit 7 is the most significant and Bit 0 is the Least significant bit
of the octet):
bit 7 6 5 4 3 2 1 0
+---+---+---+---+---+---+---+---+
|FCI|FCA| reserved | FCO |
+---+---+---+---+---+---+---+---+
FCI : Flow Control Indicator
FCA : Flow Control Ack
FCO : Flow Control Operator Bits
000 - Repeat Window Operator
001 - Increment Window Operator
010 - Decrement Window Operator
011 - Reset Window Operator
100 - Halve Window Operator
101 - Reserved
110 - Reserved
111 - Reserved
A frame with the FCI bit set is referred to as a Flow Control
Indication (FCIND). An FCIND is used to manage the flow in the
opposite direction of the frame which bears it.
A frame with the FCA bit set is referred to as a Flow Control
Acknowledgment (FCACK). An FCACK is used to manage the flow in the
same direction of the frame which bears it.
NOTE: A frame may be both a FCIND and an FCACK.
A frame bearing an FCIND or FCACK may also contain data for the flow
in the direction it is traveling. In such a frame, the FCIND or
FCACK are said to be piggy-backed. A non-piggy-backed FCIND is
called an Independent Flow Control Indication (IFCIND) and a non-
piggy-backed FCACK is called an Independent Flow Control
Acknowledgment (IFCACK). IFCIND and IFCACK messages are sent in a
Independent Flow Control SSP message (type 0x21).
NOTE: A frame may be both an IFCIND and an IFCACK.
It is desirable to carry information in control messages so as to