Receipt of this message results in normal circuit setup as described
in RFC1795 (and the SNA case described above). That is to say that
the CANUREACH_cs messages etc. are sent on a TCP connection to the
appropriate DLSw peer. If no such TCP connection exists, one is
brought up.
9.4 Example NetBIOS SSP Message Sequence
The following diagram provides an example sequence of flows
associated with a NetBIOS circuit setup. All flows and states
described below correspond precisely with those defined in RFC1795.
The only exception is the addition of a TCP connection setup and DLSw
capabilities exchange that occurs when the origin DLSw must send a
CANUREACH_cs and no TCP connection yet exists to the target DLSw
peer.
====== ___ ======
| | --------- __/ \__ --------- | |
| | __| _|_ |__ / 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
In the case of NetBIOS, many more packets are being sent via UDP than
in the SNA case. Therefore, the exposure to the unreliability of
these services is greater than that of SNA. For address resolution
frames, such as NAME_QUERY, etc., successful message delivery is an
issue. In addition, the retry interval for these types of frames is
considerably shorter than SNA with the defaults being: retry interval
= 0.5 seconds and retry count = 6. Once again, neither RFC1795 nor
this paper attempt to address the issue of LAN frame filtering
optimizations. This issue is outside the scope of this paper. But it
is important for implementers to recognize the inherent unreliable
nature of UDP transport services for frames of this type and to
implement retry schemes that are appropriate to successful operation.
Again, it is only appropriate to consider retry of non-response type
packets. Specific NetBIOS messages where successful message delivery
is considered important (and retries possibly necessary) are
indicated in the table above with an 揧es?in the 揜etry?column.
10. Sequencing
It is important to note that UDP transport services do not provide
guaranteed packet sequencing like TCP does for RFC1795. In a steady
state network, in order packet delivery can be generally assumed.
But in the presence of network outages and topology changes, packets
may take alternate routes to the destination and arrive out of
sequence with respect to their original transmission order. For SNA
address resolution this should not be a problem given that there is
no inherent significance to the order of packets being transmitted
via UDP.
In the case of NetBIOS, in order delivery is not guaranteed in the
normal case (e.g., LANs). This is because LAN broadcasting
mechanisms suffer the same problems of packet sequencing as do WAN
multicast mechanisms. But one might argue the greater likelihood of
topology related changes in the WAN environment and thus a greater
level of concern. The vast majority of NetBIOS UI frames (being
handled via UDP and Multicast) have correlator values and do not rely
upon packet sequencing.
The only NetBIOS frames of special note would be: DATAGRAM,
DATAGRAM_BROADCAST, and STATUS_RESPONSE. In the case of DATAGRAM and
DATAGRAM_BROADCAST it is generally assumed that datagrams do not
provide any guarantee of in order packet delivery. Thus applications
utilizing this NetBIOS service are assumed to have no dependency on
in order packet delivery. STATUS_RESPONSE can actually be sent as a
sequence of STATUS_RESPONSE messages. In cases where this occurs,
the STATUS_RESPONSE will be exposed to potential out of sequence
delivery.
11. Frame Formats
11.1 Multicast Capabilities Control Vector
This control vector is carried in the Capabilities Exchange Request.
When present, it must be accompanied by a TCP Connections Control
Vector indicating support for 1 TCP/IP connection and a DLSw version
CV indicating support for version 2 release 0. Like all control
vectors in this SSP message, it is an LT structure. LT structures
consist of a 1 byte length field followed by a 1 byte type field.
The length field includes itself as well as 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 intended use of this CV for Multicast support is to detect when
the multicast CANUREACH_ex flows will suffice between partners. If
this CV is present in a CAPEX from a partner, that partner is also
multicast capable and therefore does not need to receive CANUREACH_ex
messages over the TCP link that exists between them (and there must
be one or else the CAPEX would not have flowed) because it will
receive the multicast copies.
A DLSw includes this control vector on a peer-wise basis. That is to
say, that a DLSw implementation may support multicast services but
choose not to indicate this in its capabilities exchange to all
partners. Therefore, a DLSw may include this capabilities CV with
some DLSw peers and not with others. Not including this vector can
be used to force TCP connections with other multicast capable nodes
and degrade to normal RFC1795 operations. This capability is
allowed to provide greater 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 must provide support for both
multicast version 1 and single TCP connections. This means that the
capabilities exchange request must contain a DLSw Version ID control
vector (x'82') indicating support for version 2 release 0, a
Multicast Capabilities control vector, and the TCP Connections
control vector indicating support for 1 TCP connection within a given
capabilities exchange. If a multicast capable DLSw receives a
capabilities exchange with a Multicast Capabilities, but either a
missing or inappropriate TCP Connections CV (i.e., connections not
equal to one)or DLSw Version control vector, then the inbound
capabilities exchange should be rejected with a DLSw capabilities
exchange negative response (see RFC1795) using the following new
reason code:
x'000D'Inconsistent DLSw Version, Multicast Capabilities, and TCP
Connections CV received on the inbound Capabilities exchange
11.2 UDP Packets
SSP frame formats are defined in RFC1795. Multicast protocol
enhancements do not change these formats in any way. The multicast
protocol enhancements, however, do introduce the notion of SSP packet
transport via UDP. In this case, standard UDP services and headers
are used to transport SSP packets.
The following section describes 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
In order to accommodate the addition of vendor specific functions
over UDP transport, a new SSP packet header has been defined. As
described above, it is possible to receive these packets over both
UDP and TCP (when a TCP connection already exists).
It is important to note that the first 4 bytes of this packet match
the format of existing RFC1795 SSP packets. This is done so that
implementations in the future can expect that the DLSw 揤ersion
Number?is found in byte one and that the following bytes describe
the packet header and message length.
Furthermore, to assist DLSws in detecting 'out-of-sync' conditions
whereby packet or parsing errors lead to improper length
interpretations in the TCP datastream, valid DLSw version numbers
will be restricted to the range of x'31' through x'3F' inclusive.
DLSw multicast Vendor Specific frame format differs from existing RFC
1795 packets in the following ways:
1) The 揤ersion Number?field is set to x'32' (ASCII '2') and now
represents a packet type more than a DLSw version number. More
precisely, it is permitted and expected that DLSw may send packets of
both types (x'31' and x'32').
2) The message length field is followed by a new 3 byte field that
contains the specific vendor's IEEE Organizationally Unique
Identifier (OUI).
3) All fields following the new OUI field are arbitrary and defined
by implementers.
The following section defines this 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 owner
12. Compliance Statement
All DLSw v2.0 implementations must support
- Halt reason codes
- the Multicast Capabilities control vector in the DLSw
capabilities exchanges messages.
The presence of the Multicast Capabilities control vector in a
capabilities exchange message implies that the DLSw that issued the
message supports all the scalability enhancements defined in this
document. These are:
- use of multicast IP (if it is 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 addresses only scalability problems in RFC1795. No
attempt is made to define any additional security mechanisms. Note
that, as in RFC1795, a given implementation may still choose to
refuse TCP connections from DLSw peers that have not been configured
by the user. The mechanism by which the user configures this
behavior is not specified in this document.
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)
Many thanks also to all those who participated in the DLSw RIG
sessions and mail exploder discussions.
If you would like to participate in future DLSw discussions, please
subscribe to the DLSw RIG mailing lists by sending a mail to
majordomo@raleigh.ibm.com specifying 'subscribe aiw-dlsw' as the body
of the message.
If you would like further information on the activities of the AIW,
please refer to 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.uk
Much 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.com
16. Appendix - Clarifications to RFC1795
This appendix attempts to clarify the areas of RFC1795 that have
proven to be ambiguous or hard to understand in the implementation
experience to- date. These clarifications should be read in
conjunction with RFC1795 as this document does not reproduce the
complete text of that RFC.
The clarifications are ordered by the section number in RFC1795 to
which they apply. Where one point applies to more than one place in
RFC1795, it is listed below by the first relevant section.
If any implementers encounter further difficulties in understanding
RFC1795 or these clarifications, they are encouraged to query the
DLSw mail exploder (see section 1.1) for assistance.
3. Send Port
It is not permitted for a DLSw implementation to check that the send
port used by a partner is 2067. All implementations must accept
connections from partners that do not use this port.
3 TCP Tunnel bringup
The paragraph below the figure should read as follows:
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 received from the LAN must be set to
zero before forwarding in the source or destination address field in
a SSP message header. This requirement aims to avoid ambiguity of
circuit IDs. It is 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 varying the
Transport ID up to and including when the ICR_cs message flows, and
at all times reflect the most recent TID received from the partner in
any SSP messages sent. The TID cannot vary once the ICR_cs message
has flowed.
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).
3.5 KEEPALIVE messages
The SSP KEEPALIVE message (x1D) uses the short ("infoframe") version
of the SSP header. All DLSw implementation must support receipt and
quiet ignore of this message, but there is not requirement to send
it. There is no response to a KEEPALIVE message.
3.5 MAC header for Netbios SSP frames
The MAC header is included in forwarded SSP Netbios frames in the
format described below:
- 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.
5.4 Use of CUR-cs/CUR-ex
The SSAP and DSAP numbers in CUR_ex messages should reflect those
actually used in the TEST (or equivalent) frame that caused the
CUR_ex message to flow. This would mean that the SAP numbers in a
'typical' CUR_ex frame for SNA traffic switched from a LAN 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 a XID specifying the (non-
zero) DSAP is received.
Note that this does not mean that an implementation can assume that
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 a situation where the CUR_ex may flow with a non-zero
DSAP is when there is 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. This would then be passed on 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
that uses 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.
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 does not support any of the options specified on a CAPEX
received 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.
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.