As per Relevance of the word multicast, we have this rfc below:
Network Working Group D.
Request for Comments: 2166 3Com
Category: Informational P.
Data Connection Ltd
June 1997
APPN Implementer's
Closed Pages
DLSw v2.0
Status of this
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
This document
- a set of extensions to RFC 1795 designed to improve the
of
- clarifications to RFC 1795 in the light of the
experience to-date
It is assumed that the reader is familiar with DLSw and RFC 1795.
effort has been made to explain these existing protocols
associated terminology
This document was developed in the DLSw Related Interest Group (RIG
of the APPN Implementers Workshop (AIW). If you would like
participate in future DLSw discussions, please subscribe to the
RIG mailing lists by sending a mail to majordomo@raleigh.ibm.
specifying 'subscribe aiw-dlsw' as the body of the message
Table of
1. INTRODUCTION ................................................ 3
2. HALT REASON CODES............................................ 3
3. SCOPE OF SCALABILITY ENHANCEMENTS............................ 4
4. OVERVIEW OF SCALABILITY ENHANCEMENTS......................... 6
5. MULTICAST GROUPS AND ADDRESSING.............................. 7
5.1 USING MULTICAST GROUPS...................................... 8
5.2 DLSW MULTICAST ADDRESSES.................................... 8
6. DLSW MESSAGE TRANSPORTS...................................... 8
6.1 TCP/IP CONNECTIONS ON DEMAND................................ 9
6.1.1 TCP CONNECTIONS ON DEMAND RACE CONDITIONS................ 9
Bryant & Brittain Informational [Page 1]
RFC 2166 APPN Implementer's Workshop June 1997
6.2 SINGLE SESSION TCP/IP CONNECTIONS........................... 9
6.2.1 EXPEDITED SINGLE SESSION TCP/IP CONNECTIONS.............. 10
6.2.1.1 TCP PORT NUMBERS...................................... 10
6.2.1.2 TCP CONNECTION SETUP.................................. 10
6.2.1.3 SINGLE SESSION SETUP RACE CONDITIONS.................. 10
6.2.1.4 TCP CONNECTIONS WITH NON-MULTICAST CAPABLE DLSW PEERS. 11
6.3 UDP DATAGRAMS............................................... 12
6.3.1 VENDOR SPECIFIC FUNCTIONS OVER UDP....................... 12
6.3.2 UNICAST UDP DATAGRAMS.................................... 12
6.3.3 MULTICAST UDP DATAGRAMS.................................. 13
6.4 UNICAST UDP DATAGRAMS IN LIEU OF IP MULTICAST............... 13
6.5 TCP TRANSPORT............................................... 14
7. MIGRATION SUPPORT............................................ 14
7.1 CAPABILITIES EXCHANGE....................................... 14
7.2 CONNECTING TO NON-MULTICAST CAPABLE NODES................... 15
7.3 COMMUNICATING WITH MULTICAST CAPABLE NODES.................. 15
8. SNA SUPPORT.................................................. 16
8.1 ADDRESS RESOLUTION.......................................... 16
8.2 EXPLORER FRAMES............................................. 16
8.3 CIRCUIT SETUP............................................... 17
8.4 EXAMPLE SNA SSP MESSAGE SEQUENCE............................ 17
8.5 UDP RELIABILITY............................................. 19
8.5.1 RETRIES.................................................. 19
9. NETBIOS...................................................... 20
9.1 ADDRESS RESOLUTION.......................................... 21
9.2 EXPLORER FRAMES............................................. 21
9.3 CIRCUIT SETUP............................................... 21
9.4 EXAMPLE NETBIOS SSP MESSAGE SEQUENCE........................ 22
9.5 MULTICAST RELIABILITY AND RETRIES........................... 24
10. SEQUENCING.................................................. 24
11. FRAME FORMATS............................................... 25
11.1 MULTICAST CAPABILITIES CONTROL VECTOR...................... 25
11.1.1 DLSW CAPABILITIES NEGATIVE RESPONSE..................... 26
11.2 UDP PACKETS................................................ 26
11.3 VENDOR SPECIFIC UDP PACKETS................................ 27
12. COMPLIANCE STATEMENT........................................ 28
13. SECURITY CONSIDERATIONS..................................... 29
14. ACKNOWLEDGEMENTS............................................ 29
15. AUTHORS' ADDRESSES.......................................... 30
16. APPENDIX - CLARIFICATIONS TO RFC 1795....................... 31
Bryant & Brittain Informational [Page 2]
RFC 2166 APPN Implementer's Workshop June 1997
1.
This document defines v2.0 of Data Link Switching (DLSw) in the
of a set of enhancements to RFC 1795. These enhancements are
to be fully backward compatible with existing RFC 1795
implementations. As a compatible set of enhancements to RFC 1795,
this document does not replace or supersede RFC 1795.
The bulk of these enhancements address scalability issues in
v1.0. Reason codes have also been added to the HALT_DL
HALT_DL_NOACK SSP messages in order to improve the
information available
Finally, the appendix to this document lists a number
clarifications to RFC 1795 where the implementation experience to
date has shown that the original RFC was ambiguous or unclear.
clarifications should be read alongside RFC 1795 to obtain a
specification of the base v1.0 DLSw standard
2. HALT Reason
RFC 1795 provides no mechanism for a DLSw to communicate to its
the reason for dropping a circuit. DLSw v2.0 adds reason code
to the HALT_DL and HALT_DL_NOACK SSP messages to carry
information
The reason code is carried as 6 bytes of data after the existing
header. The format of these bytes is as shown below
Byte
0-1 Generic HALT reason code in byte normal
2-5 Vendor-specific detailed reason
The generic HALT reason code takes one of the following
values (which are chosen to match the disconnect reason
specified in the DLSw MIB).
1 - Unknown
2 - Received DISC from end-
3 - Detected DLC error with end-
4 - Circuit-level protocol error (e.g., pacing
5 - Operator-initiated (mgt station or local console
The vendor-specific detailed reason code may take any value
Bryant & Brittain Informational [Page 3]
RFC 2166 APPN Implementer's Workshop June 1997
All V2.0 DLSws must include this information on all HALT_DL
HALT_DL_NOACK messages sent to v2.0 DLSw peers. For
compatibility with RFC 1795, DLSw V2.0 implementations must
accept a HALT_DL or HALT_DL_NOACK message received from a DLSw
that does not carry this information (i.e. RFC 1795 format for
SSP messages).
3. Scope of Scalability
The DLSw Scalability group of the AIW identified a number
scalability issues associated with existing DLSw protocols as
in RFC 1795:
-
RFC 1795 implies the need to define the transport address of
DLSw peers at each DLSw. In highly meshed situations (such
those often found in NetBIOS networks), the
administrative burden is undesirable
- Address
RFC 1795 defines point to point TCP (or other reliable
protocol) connections between DLSw peers. When attempting
discover the location of an unknown resource, a DLSw sends
address resolution packet to each DLSw peer over these connections
In highly meshed configurations, this can result in a very
number of packets in the transport network. Although each
is sent individually to each DLSw peer, they are each identical
nature. Thus the transport network is burdened with
numbers of identical packets. Since the transport network is
commonly a wide area network, where bandwidth is considered
precious resource, this packet duplication is undesirable
- Broadcast
In addition to the address resolution packets described above,
1795 also propagates NetBIOS broadcast packets into the
network. The UI frames of NetBIOS are sent as LAN
packets. RFC 1795 propagates these packets over the point to
transport connections to each DLSw peer. In the same manner
above, this creates a large number of identical packets in
transport network, and hence is undesirable. Since NetBIOS
frames can be sent by applications, it is difficult to predict
control the rate and quantity of such traffic. This compounds
undesirability of the existing RFC 1795 propagation method
these packets
Bryant & Brittain Informational [Page 4]
RFC 2166 APPN Implementer's Workshop June 1997
- TCP (transport connection)
As defined in RFC 1795, each DLSw maintains a transport
to its DLSw peers. Each transport connection guarantees in
packet delivery. This is accomplished using acknowledgment
sequencing algorithms which require both CPU and memory at the
endpoints in direct proportion to the number transport connections
The DLSw Scalability group has identified two scenarios where
number of transport connections can become significant resulting
excessive overhead and corresponding equipment costs (memory
CPU). The first scenario is found in highly meshed
configurations where the number of transport
approximates n2 (where n is the number of DLSw peers). This
typically found in DLSw networks supporting NetBIOS. The
scenario is found in networks where many remote
communicate to few central sites. In this case, the central
must support n transport connections (where n is the number
remote sites). In both scenarios the resultant
connection overhead is considered undesirable depending upon
value of n
- LLC2
RFC 1795 specifies that each DLSw provides local termination
the LLC2 (SDLC or other SNA reliable data link protocol)
traversing the SSP. Because these reliable data links
guaranteed in order packet delivery, the memory and CPU overhead
maintaining these connections can also become significant.
is particularly undesirable in the second scenario described above
because the number of reliable connections maintained at
central site is the aggregate of the connections maintained at
remote site
It is not the intent of this document to address all the
scalability issues associated with RFC 1795. This paper
protocol enhancements to RFC 1795 using the inherent
capabilities of the underlying transport network to improve
scalability of RFC 1795. It is believed that the
defined, herein, address many of the issues identified above, such
administration, address resolution, broadcast packets, and, to
lesser extent, transport overhead. This paper does not address LLC
overhead. Subsequent efforts by the AIW and/or DLSw
group may address the unresolved scalability issues
Bryant & Brittain Informational [Page 5]
RFC 2166 APPN Implementer's Workshop June 1997
While it is the intent of this paper to accommodate all
protocols as best as is possible, it is recognized that the
capabilities of many protocols is not yet well defined, understood
or implemented. Since TCP is the most prevalent DLSw
protocol in use today, the DLSw Scalability group has chosen to
its definition around IP based multicast services. This document
addresses the implementation detail of IP based multicast services
This proposal does not consider the impacts of IPv6 as this
considered too far from widespread use at the time of writing
4. Overview of Scalability
This paper describes the use of multicast services within
transport network to improve the scalability of DLSw
networking. There are only a few main components of this proposal
- Single session TCP
RFC 1795 defines a negotiation protocol for DLSw peers to
either two unidirectional or one bi-directional TCP connection
DLSws implementing the enhancements described in this document
support and use(whenever required and possible)a single bi
directional TCP connection between DLSw peers. That is to say
the single tunnel negotiation support of RFC 1795 is a
function to this set of enhancements. Use of two unidirectional
connections is only allowed (and required)for migration
when communicating with DLSw peers that do not implement
enhancements
This document also specifies a faster method for bringing up
single TCP connection between two DLSw peers than the
used in RFC 1795. This faster method, detailed in section 6.2.1,
must be used where both peers are known to support DLSw v2.0.
- TCP connections on
Two DLSw peers using these enhancements will only establish a
connection when necessary. SSP connections to DLSw peers which
not implement these enhancements are assumed to be established
the means defined in RFC 1795. DLSws implementing v2.0 utilize
based transport services to send address resolution
(CANUREACH_ex, NETBIOS_NQ_ex, etc.). If a positive response
received, then a TCP connection is only established to
associated DLSw peer if one does not already exist
Correspondingly, TCP connections are brought down when there are
circuits to a DLSw peer for an implementation defined period
time
Bryant & Brittain Informational [Page 6]
RFC 2166 APPN Implementer's Workshop June 1997
- Address resolution through
The main thrust of this paper is to utilize non-reliable
and the inherent efficiencies of multicast protocols
possible and applicable to reduce network overhead. Accordingly
the address resolution protocols of SNA and NetBIOS are sent
the non-reliable transport of IP, namely UDP. In addition,
multicast/unicast services are used whenever address
packets must be sent to multiple destinations. This avoids the
to maintain TCP SSP connections between two DLSw peers when
circuits are active. CANUREACH_ex and ICANREACH_ex packets can
sent to all the appropriate DLSw peers without the need for pre
configured peers or pre-established TCP/IP connections.
addition, most multicast services (including TCP's MOSPF, DVMRP
MIP, etc.) replicate and propagate messages only as necessary
deliver to all multicast members. This avoids duplication
excessive bandwidth consumption in the transport network
To further optimize the use of WAN resources, address
responses are sent in a directed fashion (i.e., unicast) via
transport whenever possible. This avoids the need to setup
maintain TCP connections when they are not required. It
avoids the bandwidth costs associated with broadcasting
Note: It is also permitted to send some address resolution
over existing TCP connections. The conditions under which this
permitted are detailed in section 7.
- NetBIOS broadcasts over
In the same manner as above, NetBIOS broadcast packets are sent
UDP (unicast and multicast) whenever possible and appropriate.
avoids the need to establish TCP connections between DLSw
when there are no circuits required. In addition, bandwidth
the transport network is conserved by utilizing the
inherent to multicast service implementation. Details
identification of these packets and proper propagation methods
described in section 10.
5. Multicast Groups and
IP multicast services provides an unreliable datagram
delivery service to multiple parties. Communication is
by sending and/or listening to specific 'multicast' addresses.
a given node sends a packet to a specific address (defined to
within the multicast address range), the IP network (unreliably
delivers the packet to every node listening on that address
Bryant & Brittain Informational [Page 7]
RFC 2166 APPN Implementer's Workshop June 1997
Thus, DLSws can make use of this service by simply sending
receiving (i.e., listening for) packets on the appropriate
addresses. With careful planning and implementation, networks can
effectively partitioned and network overhead controlled by
and listening on different addresses groups. It is not the intent
this paper to define or describe the techniques by which this can
accomplished. It is expected that the networking industry (
and end users alike) will determine the most appropriate ways to
use of the functions provided by use of DLSw multicast
services
5.1 Using Multicast
The multicast addressing as described above can be effectively
to limit the amount of broadcast/multicast traffic in the network
It is not the intent of this document to describe how
DLSw/SSP implementations would assign or choose group addresses.
specifics of how this is done and exposed to the end user is an
for the specific implementor. In order to provide for
interoperability and simplicity of configuration, however, this
defines a single IP multicast address, 224.0.10.000, to be used as
default DLSw multicast address. If a given implementation chooses
provide a default multicast address, it is recommended this
be used. In addition, this address should be used for
transmitting and receiving of multicast SSP messages.
of a default multicast address is not, however, required
5.2 DLSw Multicast
For the purpose of long term interoperability, the AIW has secured
block of IP multicast addresses to be used with DLSw.
addresses are listed below
Address Range
--------------------------------------------------------------------
224.0.10.000 Default multicast
224.0.10.001-191 User defined DLSw multicast
224.0.10.192-255 Reserved for future use by the DLSw RIG in
6. DLSw Message
With the introduction of DLSw Multicast Protocols, SSP messages
now sent over two distinct transport mechanisms: TCP/IP
and UDP services. Furthermore, the UDP datagrams can be sent to
different kinds of IP addresses: unique IP addresses (
associated with a specific DLSw), and multicast IP
(generally associated with a group of DLSw peers).
Bryant & Brittain Informational [Page 8]
RFC 2166 APPN Implementer's Workshop June 1997
6.1 TCP/IP Connections on
As is the case in RFC 1795, TCP/IP connections are
between DLSw peers. Unlike RFC 1795, however, TCP/IP connections
only established to carry reliable circuit data (i.e., LLC2
circuits). Accordingly, a TCP/IP connection is only established to
given DLSw peer when the first circuit to that DLSw is
(i.e., the origin DLSw must send a CANUREACH_CS to a target DLSw
and there is no existing TCP connection between the two).
addition, the TCP/IP connection is brought down an
defined amount of time after the last active (not pending)
has terminated. In this way, the overhead associated
maintaining TCP connections is minimized
With the advent of TCP connections on demand, the activation
deactivation of TCP connections becomes a normal occurrence
opposed to the exception event it constitutes in RFC 1795. For
reason, it is recommended that implementations carefully consider
value of SNMP traps for this condition
6.1.1 TCP Connections on Demand Race
Non-circuit based SSP packetsn (e.g.,CANUREACH_ex, etc.) may still
sent/received over TCP connections after all circuits have
terminated. Taking this into account implementations should
gracefully terminate these TCP connections once the connection is
longer supporting circuits. This may require an implementation
retransmit request frames over UDP when no response to a TCP
unicast request is received and the TCP connection is brought down
This is not required in the case of multicast requests as these
received over the multicast transport mechanism
6.2 Single Session TCP/IP
RFC 1795 defines the use of two unidirectional TCP/IP
between any pair of DLSw peers using read port number 2065 and
port number 2067. Additionally, RFC 1795 allows for
to optionally use only one bi-directional TCP/IP session. Using
TCP/IP session between DLSw peers is believed to
improve the performance and scalability of DLSw protocols
Performance is improved because TCP/IP acknowledgments are much
likely to be piggy-backed on real data when TCP/IP sessions are
bi-directionally. Scalability is improved because fewer TCP
blocks, state machines, and associated message buffers are required
For these reasons, the DLSw enhancements defined in this
REQUIRE the use of single session TCP/IP sessions
Bryant & Brittain Informational [Page 9]
RFC 2166 APPN Implementer's Workshop June 1997
Accordingly, DLSws implementing these enhancements must carry the
Connections Control Vector in their Capabilities Exchange.
addition, the TCP Connections Control Vector must indicate
for 1 connection
6.2.1 Expedited Single Session TCP/IP
In RFC 1795, single session TCP/IP connections are accomplished
first establishing two uni-directional TCP connections,
capabilities, and then bringing down one of the connections.
order to avoid the unnecessary flows and time delays associated
this process, a new single session bi-directional TCP/IP
establishment algorithm is defined
6.2.1.1 TCP Port
DLSws implementing these enhancements will use a TCP destination
of 2067 (as opposed to RFC 1795 which uses 2065) for single
TCP connections. The source port will be a random port number
the established TCP norms which exclude the possibility of
2065 or 2067.
6.2.1.2 TCP Connection
DLSw peers implementing these enhancements will establish a
session TCP connection whenever the associated peer is known
support this capability. To do this, the initiating DLSw
sends a TCP setup request to destination port 2067. The
DLSw responds accordingly and the TCP three way handshake ensues
Once this handshake has completed, each DLSw is notified and the
capabilities exchange ensues. As in RFC 1795, no flows may
place until the capabilities exchange completes
6.2.1.3 Single Session Setup Race
The new expedited single session setup procedure described
opens up the possibility of a race condition that occurs when
DLSw peers attempt to setup single session TCP connections to
other at the same time. To avoid the establishment of two
connections, the following rules are applied when
expedited single session TCP connections
1.If an inbound TCP connect indication is received on port 2067
an outbound TCP connect request (on port 2067) to the same DLSw (
address) is in process or outstanding, the DLSw with the higher
address will close or reject the connection from the DLSw with
lower IP address
Bryant & Brittain Informational [Page 10]
RFC 2166 APPN Implementer's Workshop June 1997
2.To further expedite the process, the DLSw with the lower IP
may choose (implementation option) to close its connection
to the DLSw with the higher address when this condition
detected
3.If the DLSw with the lower IP address has already sent
capabilities exchange request on its connection to the DLSw
the higher IP address, it must resend its capabilities
request over the remaining TCP connection from its DLSw peer (
the higher IP address).
4.The DLSw with the higher IP address must ignore any
exchange request received over the TCP connection to be
(the one from the DLSw with the lower IP address).
6.2.1.4 TCP Connections with Non-Multicast Capable DLSw
During periods of migration, it is possible that TCP
between multicast capable and non-multicast capable DLSw peers
occur. It is also possible that multicast capable DLSws may
to establish TCP connections with partners of unknown
(e.g., statically defined peers). To handle these conditions
following additional rules apply to expedited single session
connection setup
1.If the capability of a DLSw peer is not known, an
may choose to send the initial TCP connect request to either
2067 (expedited single session setup) or port 2065 (standard
1795 TCP setup).
2.If a multicast capable DLSw receives an inbound TCP connect
on port 2065 while processing an outbound request on 2067 to
same DLSw, the sending DLSw will terminate its 2067 request
respond as defined in RFC 1795 with an outbound 2065
(standard RFC 1795 TCP setup).
3.If a multicast capable DLSw receives an indication that the
peer is not multicast capable (the port 2067 setup request
out or a port not recognized rejection is received), it will
another connection request using port 2065 and the standard
1795 session setup protocol
Bryant & Brittain Informational [Page 11]
RFC 2166 APPN Implementer's Workshop June 1997
6.3 UDP
As mentioned above, UDP datagrams can be sent two different ways
unicast (e.g., sent to a single unique IP address) or
(i.e., sent to an IP multicast address). Throughout this document
the term UDP datagram will be used to refer to SSP messages sent
UDP, while unicast and multicast SSP messages will refer to
specific type/method of UDP packet transport. In either case
standard UDP services are used to transport these packets. In
to properly parse the inbound UDP packets and deliver them to the
state machines, all DLSw UDP packets will use the destination port
2067.
In addition, the checksum function of UDP remains optional for
SSP messages. It is believed that the inherent CRC capabilities
all data link transports will adequately protect SSP packets
transmission. And the incremental exposure to intermediate
data corruption is negligible. For further information on UDP
formats see the ŸFrame Formats÷ section
6.3.1 Vendor Specific Functions over
In order to accommodate vendor specific capabilities over
transport, a new SSP packet format has been defined. This new
format is required because message traffic of this type is
necessarily preceded by a capabilities exchange. Accordingly, DLSw'
wishing to invoke a vendor specific function may send out this
SSP packet format over UDP
Because this packet can be sent over TCP connections and non
multicast capable nodes may not be able to recognize it
implementations may only send this packet over TCP to DLSw
known to understand this packet format (i.e., multicast capable).
avoid this situation in the future, DLSws implementing
enhancements must ignore SSP packets with an unrecognized
version number in the range of x'31' to x'3F'. Further
and the precise format for this new packet type is described below
the ŸFrame Formats÷ section
6.3.2 Unicast UDP
Generically speaking, a unicast UDP datagram is utilized whenever
SSP message (not requiring reliable transport) must be sent to
unique set (not all) of DLSw peers. This avoids the overhead
having to establish and maintain TCP connections when they are
required for reliable data transport
Bryant & Brittain Informational [Page 12]
RFC 2166 APPN Implementer's Workshop June 1997
A typical example of when unicast UDP might be used would be
ICANREACH_ex response from a peer DLSw (with which no TCP
currently exists). In this case, the sending DLSw knows the
address of the intended receiver and can simply send the response
unicast UDP. In addition, there are a number of NetBIOS cases
unicast UDP is used to handle UI frames directed to a specific
(e.g., NetBIOS STATUS_RESPONSE). Further detail is provided in
NetBIOS section of this document
6.3.3 Multicast UDP
In a broad sense, multicast UDP datagrams are used whenever a
SSP message must be sent to multiple DLSw peers. In the case of SNA
this is primarily the CANUREACH_ex packets. In the case of NetBIOS
multicast datagrams are used to send broadcast UI frames such
NetBIOS user datagrams and broadcast datagrams
Note, however, it is sometimes possible to avoid broadcasting
NetBIOS frames that would otherwise be broadcast in the
environment. This is typically accomplished using name
techniques not described in this paper. In cases of this type when
single destination DLSw can be determined, unicast transport can
used to send the 'broadcast' NetBIOS frame to a single destination
A more detailed listing of NetBIOS SSP packets and transport
can be found in the NetBIOS section of this document
6.4 Unicast UDP Datagrams in Lieu of IP
Because the use of IP multicast services is actually a function of
itself and not DLSw proper, it is possible for implementations
simply make use of the UDP transport mechanisms described in
paper without making direct use of the IP multicast function.
this is not considered to be as efficient as using
transport mechanisms, this practice is not explicitly prohibited
Implementations which choose to make use of UDP transport in
manner must first know the IP address of all the potential
DLSw peers and send individual unicast packets to each. How
information is obtained and/or maintained is outside the scope
this paper
As a matter of compliance, implementers need not send SSP
outbound over UDP as there are some conditions where this may not
necessary or desirable. It is, however, required that
provide an option to receive SSP packets over UDP
Bryant & Brittain Informational [Page 13]
RFC 2166 APPN Implementer's Workshop June 1997
6.5 TCP
Despite the addition of UDP based packet transport, TCP remains
fundamental form of communications between DLSw peers.
particular, TCP is still used to carry all LLC2 based circuit data
Throughout this document wherever UDP unicast (not multicast)
discussed, the reader should be aware that TCP may be used instead
Moreover, it is strongly recommended that TCP be used in
to UDP whenever a TCP connection to the destination already exists
Implementations, however, should be prepared to receive SSP
from either transport (TCP or UDP).
7. Migration
It is anticipated that some networks will experience a
stage where both RFC 1795 (referred to as 'non-multicast' DLSws)
It will be important for these two DLSw node types to
and thus the following accommodations for non-multicast DLSws
required
7.1 Capabilities
In order to guarantee both backward and forward capability,
which implement these multicast enhancements will carry a Ÿ
Capabilities÷ Control Vector in their capabilities exchange (see
1795 for an explanation of capabilities exchange protocols).
Presence of the Multicast Capabilities control vector
support for the protocols defined in this document on a per DLSw
basis. Conversely, lack of the Multicast Capabilities control
indicates no support for these extensions on a per DLSw peer basis
Additionally, nodes implementing these enhancement will carry
modified DLSw Version control vector (x'82') indicating support
version 2 release 0.
Lastly, presence of these control vectors mandates a TCP
Control Vector indicating support for 1 TCP connection in the
Capabilities exchange
If a multicast capable DLSw receives a Capabilities Exchange CV
includes the Multicast Capabilites CV but does not meet the
criteria, it must reject the capabilities exchange by sending
negative response as described in section 11.1.1.
Bryant & Brittain Informational [Page 14]
RFC 2166 APPN Implementer's Workshop June 1997
7.2 Connecting to Non-Multicast Capable
It is assumed that TCP connections to DLSw peers which do not
multicast services are established by some means outside the scope
this paper (i.e., non-multicast partner addresses are configured
the customer). TCP connections must be established and maintained
down level nodes in the exact same manner as RFC 1795 requires
establishes, and maintains them. And because non-multicast
peers will not indicate support for multicast services in
capabilities exchange, a multicast capable DLSw will know all
non-multicast peers
7.3 Communicating with Multicast Capable
Because non-multicast nodes will not receive SSP frames via
(unicast or multicast) transmission, SSP messages to these DLSw
must be sent over TCP connections. Therefore, nodes which
the multicast protocol enhancements must keep track of which
peers do not support multicast extensions (as indicated in
capabilities exchange). When a given packet is sent out
multicast services, it must also be sent over multicast UDP(to
other multicast capable DLSw peers) and over the TCP connection
each non-multicast node. And although the multicast service
periodic retransmissions (for reliability reasons), this is not
case with TCP connections to non-multicast nodes. Therefore
multicast capable DLSws should not resend SSP packets over
transport connection but rather, rely upon TCP to recover any
packets. Furthermore, communications with non-multicast nodes
be in exact compliance with RFC 1795 protocols
When sending a unicast UDP message, it is important to know that
destination DLSw supports multicast services. This knowledge can
obtained from previous TCP connections/capabilities exchanges
inferred from a previously received UDP message, but how
information is obtained is outside the scope of this paper. In
latter case, if the DLSw is non-multicast, then there would be a
connection to it and it would be known to be non-multicast. If it
multicast capable and a TCP connection is in existence, then
level is known (via the prior capabilities exchange). If
capabilities are not known and there is not an existing
connection, then it can be implied to be multicast capable by
of a cached entry but no active TCP connection (e.g., TCP peer
demand support). This inference, however, could be erroneous
cases where the TCP connection (to a non-multicast DLSw) has
for some reason. But normal UDP based unicast verification
will detect no active path to the destination and circuit setup
proceed correctly (i.e., succeed or fail in accordance with
connectivity).
Bryant & Brittain Informational [Page 15]
RFC 2166 APPN Implementer's Workshop June 1997
8. SNA
Note: This paper does not attempt to address the unique
presented by SNA/HPR and its non-ERP data
In SNA protocols the generalized packet sequence of interest is
test frame exchange followed by an XID exchange. In all cases,
uses the CANUREACH_ex and ICANREACH_ex SSP packets to
address resolution and circuit establishment. The following
describes how these packets are transported via UDP between
multicast capable DLSw peers
Message Event Action Mechanism
--------------------------------------------------------------------
TEST SEND CANUREACH_ex Multicast/Unicast
TEST RESPONSE SEND ICANREACH_ex Unicast
The following paragraphs provide more detail on how UDP transport
multicast protocol enhancements are used to establish SNA data links
8.1 Address
When a DLSw receives an incoming test frame from an attached
link, the assumption is that this is an exploratory frame
preparation for an XID exchange and link activation. The DLSw
determine a correlation between the destination LSAP (mac and
pairing) and some other DLSw in the transport network. This
generically refers to this process as Ÿaddress resolution÷.
8.2 Explorer
Address resolution messages may be sent over a TCP connection to
multicast capable DLSw peer if such a connection already exists
order that they take advantage of the guaranteed delivery of TCP
This is particularly recommended for ICANREACH_ex frames
Bryant & Brittain Informational [Page 16]
RFC 2166 APPN Implementer's Workshop June 1997
8.3 Circuit
Circuit setup is accomplished in the same manner as described in
1795. More specifically, CANUREACH_cs, ICANREACH_cs, REACH_ACK
XIDFRAME, etc. are all sent over the TCP connection to
appropriate DLSw. This, of course, assumes the existence of a
connection between the DLSw peers. If the sending DLSw (sending
CANUREACH_cs ) detects no active TCP connection to the DLSw peer
then a TCP connection setup is initiated and the packet sent.
other circuit setup (and takedown) related sequences are now
over the TCP connection
8.4 Example SNA SSP Message
The following diagram provides an example sequence of
associated with an SNA LLC circuit setup. All flows and
described below correspond precisely with those defined in RFC 1795.
The only exception is the addition of a TCP connection setup and
capabilities exchange that occurs when the origin DLSw must send
CANUREACH_CS and no TCP connection yet exists to the target
peer
Bryant & Brittain Informational [Page 17]
RFC 2166 APPN Implementer's Workshop June 1997
====== ___ ======
| | --------- __/ \__ --------- | |
| | __| _|_ |__ / IP \ __| _|_ |__ | |
====== | | | < Network > | | | ======
/______\ --------- \__ __/ --------- /______\
Origin Origin DLSw \___/ Target DLSw
Station partner partner
disconnected
TEST_cmd DLC_RESOLVE_C CANUREACH_ex TEST_
-----------> -----------> -----------> ---------->
TEST_rsp DLC_RESOLVE_R ICANREACH_ex TEST_
<--------- <----------- <----------- <----------
null XID DLC_
-----------> ----------->
circuit_
TCP Connection
<------------->
Capabilities Exch
<------------->
CANUREACH_cs DLC_START_
-----------> ----------->
resolve_
ICANREACH_cs DLC_DL_
<----------- <-------------
circuit_established circuit_
REACH_
-----------> circuit_
XIDFRAME DLC_XID null
-----------> ---------> -------->
XID DLC_XID XIDFRAME DLC_XID
<-------- <----------- <----------- <----------- <--------
XIDs DLC_XIDs XIDFRAMEs DLC_XIDs
<----------> <----------> <------------> <------------> <--------->
SABME DLC_CONTACTED CONTACT DLC_CONTACT
-----------> -----------> -----------> -----------> -------->
connect_pending contact_
UA DLC_CONTACT CONTACTED DLC_CONTACTED
<--------- <----------- <----------- <----------- <--------
connected
IFRAMEs DLC_INFOs IFRAMEs DLC_INFOs
<----------> <-----------> <------------> <------------> <-------->
Bryant & Brittain Informational [Page 18]
RFC 2166 APPN Implementer's Workshop June 1997
8.5 UDP
It is important to note, that UDP (unicast and multicast)
services do not provide a reliable means of delivery. Existing
1795 protocols guarantee the delivery (or failure notification)
CANUREACH_ex and ICANREACH_ex messages. UDP will not provide
same level of reliability. It is, therefore, possible that
messages may be lost in the network and (CANUREACH_ex) retries
be necessary
8.5.1
Test Frames are generally initiated by end stations every
seconds. Many existing RFC 1795 DLSw implementations take
of the reliable SSP TCP connections and filter out end station
frame retries when a CANUREACH_ex is outstanding. Given
unreliable nature of UDP transport for these messages, however,
filtering technique may not be advisable. Neither RFC 1795 nor
paper address this issue specifically. It is simply noted that
UDP transport mechanism is unreliable and implementations should
this into account when determining a scheme for Test frame
and explorer retries. Accordingly, the ŸRetry÷ section in the
above only serves as an indicator of situations where retries may
desirable and/or necessary, but does not imply any requirement
implement retries. Also note, that retry logic only applies to non
response type packets. It is not appropriate to retry response
SSP packets (i.e., ICANREACH_ex) as there is no way of knowing if
original response was ever received (and whether retry is necessary).
So in the case of SNA, CANUREACH_ex messages may need retry logic
ICANREACH_ex messages do not
Bryant & Brittain Informational [Page 19]
RFC 2166 APPN Implementer's Workshop June 1997
9.
With the introduction of DLSw Multicast transport, all
NetBIOS UI frames are carried outside the TCP connections
DLSw peers (i.e., via UDP datagrams). The following table
the various NetBIOS UI frames and how they are transported via
between multicast capable DLSw peers
Message Event Action Mechanism
---------------------------------------------------------------------------
ADD_GROUP_NAME_QUERY SEND DATAFRAME Multicast
ADD_NAME_QUERY SEND NETBIOS_ANQ Multicast
ADD_NAME_RESPONSE SEND NETBIOS_ANR Unicast1
NAME_IN_CONFLICT SEND DATAFRAME Multicast
STATUS_QUERY SEND DATAFRAME Unicast/Multicast(2)
STATUS_RESPONSE SEND DATAFRAME Multicast(5)
TERMINATE_TRACE (x'07') SEND DATAFRAME Multicast
TERMINATE_TRACE (X'13') SEND DATAFRAME Multicast
DATAGRAM SEND DATAFRAME(3) Unicast/Multicast(2)
DATAGRAM_BROADCAST SEND DATAFRAME Multicast
NAME_QUERY SEND NETBIOS_NQ_ex Unicast/Multicast(2)
NAME_RECOGNIZED SEND NETBIOS_NR_ex Unicast(4)
Note 1:
Upon receipt of an ADD_NAME_RESPONSE frame, a NETBIOS_ANR SSP
is returned via unicast UDP to the originator of the NETBIOS_
message
Note 2:
These frames may be sent either Unicast or Multicast UDP. If
implementation has sufficient cached information to resolve
NetBIOS datagram destination to a single DLSw peer, then the
message can and should be sent via unicast. If the cache does
contain such information then the resultant SSP message must be
via multicast UDP
Note 3:
Note that this frame is sent as either a DATAFRAME or
according to the rules as specified in RFC 1795.
Note 4:
Upon receipt of a NAME_RECOGNIZED frame, a NETBIOS_NR_ex SSP
is returned via unicast UDP to the originator of the NETBIOS_NQ_
frame. Notice that although the NAME_RECOGNIZED frame is sent as
All Routes Explorer (source routing LANs only) frame, the
NETBIOS_NR_ex is sent as a unicast UDP directed response to the
originating the NETBIOS_NQ_ex. This is because there is no value
Bryant & Brittain Informational [Page 20]
RFC 2166 APPN Implementer's Workshop June 1997
sending NETBIOS_NR_ex as a multicast packet in the transport network
The use of ARE transmission in the LAN environment is to
some form of load sharing in the source routed LAN environment
Since no analogous capability exists in the (TCP) transport network
it is not necessary to emulate this function there. It is
to note, however, that when converting a received NETBIOS_NR_ex to
NAME_RECOGNIZED frame, the DLSw sends the NAME_RECOGNIZED frame
the LAN as an ARE (source routing LANs only) frame. This
the source route load sharing in the LAN environments on either
of the DLSw transport network
Note 5:
Although RFC 1795 does not attempt to optimize STATUS_
processing, it is possible to send a STATUS_RESPONSE as a unicast
response. To do this, DLSws receiving an incoming SSP
containing a STATUS_QUERY must remember the originating DLSw'
address and STATUS_QUERY correlator. Then upon receipt of
corresponding STATUS_RESPONSE, the DLSw responds via unicast UDP
the originating DLSw(using the remembered originating DLSw address).
Note, however, that in order to determine whether a frame is
STATUS_QUERY, all multicast capable DLSw implementations will need
parse the contents of frames that would normally be sent as
SSP messages
All other multicast frames are sent into the transport network
the appropriate multicast group address
9.1 Address
Typical NetBIOS circuit setup using multicast services is
the same as specified in RFC 1795. The only significant
is that NETBIOS_NQ_ex messages are sent via UDP to the
unicast/multicast IP address and the NETBIOS_NR_ex is sent
unicast UDP to the DLSw originating the NETBIOS_NQ_ex
9.2 Explorer
Address resolution messages may be sent over a TCP connection to
multicast capable partner if such a connection already exists
order that they take advantage of the guaranteed delivery of TCP
This is particularly recommended for NETBIOS_NR_ex frames
9.3 Circuit
Following successful address resolution, a NetBIOS end
typically sends a SABME frame to initiate a formal LLC2 connection
Receipt of this message results in normal circuit setup as
in RFC 1795 (and the SNA case described above). That is to say
Bryant & Brittain Informational [Page 21]
RFC 2166 APPN Implementer's Workshop June 1997
the CANUREACH_cs messages etc. are sent on a TCP connection to
appropriate DLSw peer. If no such TCP connection exists, one
brought up
9.4 Example NetBIOS SSP Message
The following diagram provides an example sequence of
associated with a NetBIOS circuit setup. All flows and
described below correspond precisely with those defined in RFC 1795.
The only exception is the addition of a TCP connection setup and
capabilities exchange that occurs when the origin DLSw must send
CANUREACH_cs and no TCP connection yet exists to the target
peer
Bryant & Brittain Informational [Page 22]
RFC 2166 APPN Implementer's Workshop June 1997
====== ___ ======
| | --------- __/ \__ --------- | |
| | __| _|_ |__ / IP \ __| _|_ |__ | |
====== | | | < Network > | | | ======
/______\ --------- \__ __/ --------- /______\
Origin Origin DLSw \___/ Target DLSw
Station partner partner
disconnected
NAME_QUERY DLC_DGRM NETBIOS_NQ_ex DLC_DGRM NAME_
-----------> -----------> -----------> -----------> --------->
NAME_RECOG DLC_DGRM NETBIOS_NR_ex DLC_DGRM NAME_
<----------- <------------ <----------- <----------- <---------
SABME DLC_
-----------> ----------->
circuit_
TCP Connection
<------------->
Capabilities Exch
<------------->
CANUREACH_cs DLC_START_
-----------> ----------->
resolve_
ICANREACH_cs DLC_DL_
<----------- <-----------
circuit_established circuit_
REACH_
-----------> circuit_
CONTACT DLC_CONTACT
-----------> -----------> --------->
connect_pending contact_
UA DLC_CONTACT CONTACTED DLC_CONTACTED
<--------- <----------- <----------- <----------- <---------
connected
IFRAMEs DLC_INFOs IFRAMEs DLC_INFOs
<------------> <------------> <------------> <------------> <-------->
Bryant & Brittain Informational [Page 23]
RFC 2166 APPN Implementer's Workshop June 1997
9.5 Multicast Reliability and
In the case of NetBIOS, many more packets are being sent via UDP
in the SNA case. Therefore, the exposure to the unreliability
these services is greater than that of SNA. For address
frames, such as NAME_QUERY, etc., successful message delivery is
issue. In addition, the retry interval for these types of frames
considerably shorter than SNA with the defaults being: retry
= 0.5 seconds and retry count = 6. Once again, neither RFC 1795
this paper attempt to address the issue of LAN frame
optimizations. This issue is outside the scope of this paper. But
is important for implementers to recognize the inherent
nature of UDP transport services for frames of this type and
implement retry schemes that are appropriate to successful operation
Again, it is only appropriate to consider retry of non-response
packets. Specific NetBIOS messages where successful message
is considered important (and retries possibly necessary)
indicated in the table above with an ŸYes÷ in the ŸRetry÷ column
10.
It is important to note that UDP transport services do not
guaranteed packet sequencing like TCP does for RFC 1795. In a
state network, in order packet delivery can be generally assumed
But in the presence of network outages and topology changes,
may take alternate routes to the destination and arrive out
sequence with respect to their original transmission order. For
address resolution this should not be a problem given that there
no inherent significance to the order of packets being
via UDP
In the case of NetBIOS, in order delivery is not guaranteed in
normal case (e.g., LANs). This is because LAN
mechanisms suffer the same problems of packet sequencing as do
multicast mechanisms. But one might argue the greater likelihood
topology related changes in the WAN environment and thus a
level of concern. The vast majority of NetBIOS UI frames (
handled via UDP and Multicast) have correlator values and do not
upon packet sequencing
Bryant & Brittain Informational [Page 24]
RFC 2166 APPN Implementer's Workshop June 1997
The only NetBIOS frames of special note would be: DATAGRAM
DATAGRAM_BROADCAST, and STATUS_RESPONSE. In the case of DATAGRAM
DATAGRAM_BROADCAST it is generally assumed that datagrams do
provide any guarantee of in order packet delivery. Thus
utilizing this NetBIOS service are assumed to have no dependency
in order packet delivery. STATUS_RESPONSE can actually be sent as
sequence of STATUS_RESPONSE messages. In cases where this occurs
the STATUS_RESPONSE will be exposed to potential out of
delivery
11. Frame
11.1 Multicast Capabilities Control
This control vector is carried in the Capabilities Exchange Request
When present, it must be accompanied by a TCP Connections
Vector indicating support for 1 TCP/IP connection and a DLSw
CV indicating support for version 2 release 0. Like all
vectors in this SSP message, it is an LT structure. LT
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
0 0-7 Length, in binary, of the Multicast Capabilities
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
multicast services provided. The protocols as
in this document constitute version one. Accordingly
x'01' is encoded in this field. Any subsequent
must provide the services of all previous versions
The intended use of this CV for Multicast support is to detect
the multicast CANUREACH_ex flows will suffice between partners.
this CV is present in a CAPEX from a partner, that partner is
multicast capable and therefore does not need to receive CANUREACH_
messages over the TCP link that exists between them (and there
be one or else the CAPEX would not have flowed) because it
receive the multicast copies
A DLSw includes this control vector on a peer-wise basis. That is
say, that a DLSw implementation may support multicast services
choose not to indicate this in its capabilities exchange to
partners. Therefore, a DLSw may include this capabilities CV
some DLSw peers and not with others. Not including this vector
Bryant & Brittain Informational [Page 25]
RFC 2166 APPN Implementer's Workshop June 1997
be used to force TCP connections with other multicast capable
and degrade to normal RFC 1795 operations. This capability
allowed to provide greater network design flexibility
When sending this capabilities exchange control vector, the
rules apply
Required Allowed @
ID @ Startup Length Repeatable* Runtime Order
==== ========= ====== ========== ======= ===== ===============
0x8C Y 0x03 N N 5+
*Note: "Repeatable" means a Control Vector is repeatable within a
message
11.1.1 DLSw Capabilities Negative
DLSws that implement these enhancements must provide support for
multicast version 1 and single TCP connections. This means that
capabilities exchange request must contain a DLSw Version ID
vector (x'82') indicating support for version 2 release 0,
Multicast Capabilities control vector, and the TCP
control vector indicating support for 1 TCP connection within a
capabilities exchange. If a multicast capable DLSw receives
capabilities exchange with a Multicast Capabilities, but either
missing or inappropriate TCP Connections CV (i.e., connections
equal to one)or DLSw Version control vector, then the
capabilities exchange should be rejected with a DLSw
exchange negative response (see RFC 1795) using the following
reason code
x'000D'Inconsistent DLSw Version, Multicast Capabilities, and
Connections CV received on the inbound Capabilities
11.2 UDP
SSP frame formats are defined in RFC 1795. Multicast
enhancements do not change these formats in any way. The
protocol enhancements, however, do introduce the notion of SSP
transport via UDP. In this case, standard UDP services and
are used to transport SSP packets
Bryant & Brittain Informational [Page 26]
RFC 2166 APPN Implementer's Workshop June 1997
The following section describes the proper UDP header for DLSw
packets
Byte
0-1 Source Port
In DLSw multicast protocols, this particular field is
relevant. It may be set to any value
2-3 Destination Port
Always set to 2067
4-5
6-7
The standard UDP checksum value. Use of the UDP
function is optional
11.3 Vendor Specific UDP
In order to accommodate the addition of vendor specific
over UDP transport, a new SSP packet header has been defined.
described above, it is possible to receive these packets over
UDP and TCP (when a TCP connection already exists).
It is important to note that the first 4 bytes of this packet
the format of existing RFC 1795 SSP packets. This is done so
implementations in the future can expect that the DLSw Ÿ
Number÷ is found in byte one and that the following bytes
the packet header and message length
Furthermore, to assist DLSws in detecting 'out-of-sync'
whereby packet or parsing errors lead to improper
interpretations in the TCP datastream, valid DLSw version
will be restricted to the range of x'31' through x'3F' inclusive
DLSw multicast Vendor Specific frame format differs from existing
1795 packets in the following ways
1) The ŸVersion Number÷ field is set to x'32' (ASCII '2') and
represents a packet type more than a DLSw version number.
precisely, it is permitted and expected that DLSw may send packets
both types (x'31' and x'32').
2) The message length field is followed by a new 3 byte field
contains the specific vendor's IEEE Organizationally
Identifier (OUI).
Bryant & Brittain Informational [Page 27]
RFC 2166 APPN Implementer's Workshop June 1997
3) All fields following the new OUI field are arbitrary and
by implementers
The following section defines this new packet format
Byte
0 DLSw packet type, Always set to x'32'
1 Header
Always 7 or
2-3 Message
Number of bytes within the data field following
header
4-6 Vendor specific
The IEEE Organizationally Unique Identifier (OUI
associated with the vendor specific function
question
7-n Defined by the OUI
12. Compliance
All DLSw v2.0 implementations must
- Halt reason
- the Multicast Capabilities control vector in the
capabilities exchanges messages
The presence of the Multicast Capabilities control vector in
capabilities exchange message implies that the DLSw that issued
message supports all the scalability enhancements defined in
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
- single tunnel bring-up of TCP connections to DLSw
- peer-on-
- quiet ignor