As per Relevance of the word advanced, we have this rfc below:
Network Working Group W.
Request for Comments: 1538 McDATA
Category: Informational B.
McDATA
W.
I/O
October 1993
Advanced SNA/IP : A Simple SNA Transport
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard. Distribution of this memo
unlimited
This RFC provides information for the Internet community about
method for establishing and maintaining SNA sessions over an
internet. While the issues discussed may not be directly relevant
the research problems of the Internet, they may be interesting to
number of researchers and implementors. Any questions or
relative to the contents of this RFC may be sent to the
Internet address: snaip@mcdata.com
Table of
1. Introduction.................................................. 2
2. Motivation and Rationale...................................... 2
3. SNA/IP Protocol Specification................................. 3
3.1 Glossary..................................................... 3
3.2 Conventions and Assumptions.................................. 3
3.3 The Protocol................................................. 3
3.3.1 Connection Establishment................................... 3
3.3.2 Data Transfer.............................................. 5
3.3.3 Connection Termination and Loss............................ 6
3.3.4 Session Data Flow.......................................... 7
3.3.5 State Transition Table for the Initiating Node............. 8
4. LLC to SNA/IP Conversion...................................... 8
5. Performance................................................... 8
6. VTAM Definition............................................... 9
7. Acknowledgments............................................... 9
8. References.................................................... 9
9. Security Considerations....................................... 10
10. Authors' Addresses........................................... 10
11. Disclaimer................................................... 10
Behl, Sterling & Teskey [Page 1]
RFC 1538 Advanced SNA/IP October 1993
1.
Advanced SNA/IP suggests a method for the transmission of SNA
data over an IP network. This memo documents the SNA/IP protocol
implemented in the McDATA LinkMaster(R) 6200 Network Gateway,
LinkMaster(R) 7100 Network Controller, and I/O Concepts X-
TN3270 Server
Advanced SNA/IP differs from other protocols designed to
routing of SNA session traffic over an IP network. SNA/IP
originally designed for implementation in peripheral network
like SNA gateways and downstream nodes (DSNs). It is the authors
view, however, that SNA/IP could also be implemented in
network nodes like routers as the base for an LLC to IP
gateway or data link switch function
2. Motivation and
The token-ring media access control (MAC) protocol 802.5 and
link control (LLC) protocol 802.2 were the first set of LAN
used to provide a reliable and connection-oriented data link
for SNA sessions in a LAN environment
McDATA's experience with transporting SNA over 802.5 networks led
an 802.3/802.2 (Ethernet) based variation. As prospective
were introduced to these Ethernet products, the question
routability arose. Network administrators, accustomed to
with Ethernet networks and the IP-based protocols, required an
routable solution. McDATA's "SNA over Ethernet" products
bridgeable, but were not routable
SNA sessions require a reliable and connection-oriented data link
TCP running over IP provides a reliable and connection-
transport service and has the added benefit of being routable.
seemed the UDP and TCP protocols could be used in place of 802.2
I and Type II levels of service used in traditional SNA token-
implementations. Advanced SNA/IP was created as a result of
observations
Behl, Sterling & Teskey [Page 2]
RFC 1538 Advanced SNA/IP October 1993
3. SNA/IP Protocol
3.1.
Data Link Switching (DLSw) - This is best described as a
protocol used for the conversion of LLC-based SNA sessions to an
form. The initial version of the DLSw protocol is documented in
informational RFC 1434 [1].
Downstream Node (DSN) - An SNA Physical Unit (PU) type 2.0 or 2.1
device connected to the SNA network via a LAN (802.5, 802.3, etc.)
opposed to an SDLC, X.25, or channel connection
SNA Gateway - A device that provides a data link control (DLC
conversion function for SNA PU type 5 (host) devices and LAN
attached DSNs
Subnet SNA Gateway - A device connected to both a traditional
token-ring segment and an IP network that performs local
of the LLC connections, a mapping function of source address
destination IP address, and a conversion (switching) function of
to IP
3.2. Conventions and
Frame formats are shown starting with the IP header. Other
will, of course, appear in the actual frames sent, but these headers
and the numbers of them, will vary across MAC types
It is assumed the reader is familiar with both the standard
protocol (to the extent it applies to SNA Gateway and DSN functions
and the base set of TCP/IP protocols. Where practical, the reader
asked to refer to appropriate SNA and TCP/IP documentation
3.3. The
Conceptually, there are three phases to the Advanced SNA/IP protocol
the Connection Establishment phase, the Data Transfer phase, and
Connection Termination phase
3.3.1. Connection
Connection Establishment involves the exchange of logical XID
between the connecting end nodes and culminates in the
of a TCP connection. This process is similar to the IBM-
Test, XID, SABME and UA exchange used to establish a Type II 802.2
connection for SNA traffic [2]. In place of the 802.2 Type
messages, SNA/IP defines the following set of UDP datagrams
Behl, Sterling & Teskey [Page 3]
RFC 1538 Advanced SNA/IP October 1993
Logical Null
Use: Sent by an initiating node (such as a DSN) when
connection to another SNA node is desired
The Logical Null XID communicates the sending node'
desire to negotiate connection parameters. Once
parameters are established, the Logical Null
communicates the sender's TCP port to which a
is to be made
Format
------------------------------------
| IP Header | UDP Header | 0xBF |
------------------------------------
Source IP address: The IP address of the
node
Destination IP address: The IP address of the partner
node
Source UDP Port: Must match the TCP port number to
used in the eventual TCP connection
Destination UDP Port: A known port on the partner
that expects SNA/IP datagrams
XID
Use: Sent in response to a Logical Null XID and requests
receiving node to send a Logical SNA XID datagram
Format
------------------------------------
| IP Header | UDP Header | 0xBF |
------------------------------------
The source and destination IP and UDP port numbers follow
logically, from those provided in the Logical Null
datagram
The format of the XID Request and Logical Null XID are
same. The two types are distinguished by the roles assumed
the two nodes. In current implementations, the DSN
the XID exchange by sending the Logical Null XID. The
Gateway responds with the XID request
Behl, Sterling & Teskey [Page 4]
RFC 1538 Advanced SNA/IP October 1993
Logical SNA
Use: Sent in response to an XID Request and in the context
SNA XID negotiation
Format
----------------------------------------------------
| IP Header | UDP Header | 0xBF | SNA XID data |
----------------------------------------------------
For PU 2.0 nodes, the SNA XID data consists of a Format 0
[3].
For PU 2.1 nodes, the SNA XID data consists of a Format 3
[3].
A typical Connection Establishment data flow appears below
Node 1 Node 2
Logical Null XID ------------------------->
<------------------------ XID
Logical SNA XID -------------------------->
<------------------------ TCP
TCP SYN ACK ----------------------------->
<------------------------ TCP
Note: The source UDP port of the Logical Null XID equals
destination TCP port of the TCP SYN segment
Retries of the Logical Null XID by the initiating node should
periodically until an XID Request is received in reply. The
of the retries is left up to the implementor. The lower bound on
retry timer should be more than the expected round trip time for
packet on the network
3.3.2. Data
There are no special packets defined for the Data Transfer phase
Once the TCP connection is established, SNA Request Units (RUs)
be exchanged between the two end nodes. The SNA session data
as TCP segment data. The only added SNA/IP requirement is that
SNA message consisting of a Transmission Header (TH),
Request/Response Header (RH) and an optional Request/Response
Unit (RU) be preceded by a two octet length field. Examples of
Behl, Sterling & Teskey [Page 5]
RFC 1538 Advanced SNA/IP October 1993
Transfer frames are shown below
-------------------------------------------------------
| IP Header | TCP Header | SNA Msg 1 len | SNA Msg 1 |
-------------------------------------------------------
----------------------------------------------
| IP Header | TCP Header | SNA Msg 1 cont'd ->
----------------------------------------------
--------------------------------
| SNA Msg 2 len | SNA Msg 2 |
--------------------------------
The length field is passed in big endian format. 0 is a valid
value
The format of the SNA Message pieces are as defined by SNA [3].
Reliable and sequential delivery of data is provided by the
protocol [5,6].
3.3.3. Connection Termination and
Either SNA node may, at any time, terminate the logical
connection by issuing a TCP-level FIN segment. Dictates of the
protocol apply to this termination process [5,6].
A connection is also terminated, though not as cleanly, if a
Reset segment is sent by either SNA node
Once a connection is terminated, a new connection may be
by the process outlined in the Connection Establishment section.
reconnections made to the LinkMaster 6200 gateway, the same
source port must be used by the initiating node. This implies
the same TCP port is used. This requirement stems from the fact
gateway may not always be aware that a TCP connection has
terminated. This would happen if the DSN became disabled prior
sending a FIN or Reset segment. Under these circumstances, SNA
resources remain allocated and a reconnection from a DSN, which
host believes to already be in session, is not allowed. By
the DSN to use the same port when reestablishing a connection,
LinkMaster 6200 is able to recognize when a reset of the
connection is required
Behl, Sterling & Teskey [Page 6]
RFC 1538 Advanced SNA/IP October 1993
3.3.4. Complete Session Data
Node 1 Node 2
Logical Null XID ------------------------->
(UDP Datagram
Logical Null XID ------------------------->
(UDP Datagram
<------------------------ XID
(UDP Datagram
Logical SNA XID -------------------------->
(UDP Datagram
<------------------------ TCP
(TCP Message
TCP SYN ACK ----------------------------->
(TCP Message
<------------------------ TCP
(TCP Message
****************** Connection Established *******************
<------------------------ SNA
(TCP Message
SNA ACTPU Response --------------------->
(TCP Message
<------------------------ SNA
(TCP Message
SNA ACTLU Response --------------------->
(TCP Message
.
.
.
<------------------------ TCP
(TCP Message
TCP FIN ACK ------------------------>
(TCP Message
<------------------------ TCP
(TCP Message
******************** Connection Closed *********************
Logical Null XID ----------------------->
(UDP Datagram
.
.
.
.
Behl, Sterling & Teskey [Page 7]
RFC 1538 Advanced SNA/IP October 1993
3.3.5. State Transition Table for the Initiating
Transition
Given State | No Conn | Null XID Sent | SNA XID Sent | Conn
------------+---------+---------------+--------------+-----------
No | | Internal Act. | |
Connection | | Stimulus | |
| | ---> Sends | |
| | 1st Null XID | |
------------+---------+---------------+--------------+-----------
Null XID | | Internal | XID Request |
Sent | | Timer Event | Received |
| | ----> Resend | ----> Sends |
| | Null XID | SNA XID |
------------+---------+---------------+--------------+-----------
SNA XID | | Internal | SNA XID |
Sent | | Timer Event | Received | that
| | ----> Resend | ----> Send |
| | Null XID | SNA XID | is estb
| | | |
------------+---------+---------------+--------------+-----------
Connection | Indica- | | |
Established | tion | | |
| that | | |
| TCP conn| | |
| term. | | |
A gateway state transition table is not provided here because
state transitions are dependent on the nature of the SNA
interface (3172 Channel Protocol, 3174 Channel Protocol, SDLC, etc.).
4. LLC to SNA/IP
The use of Advanced SNA/IP to convert conventional token ring-
SNA traffic to a routable form is both conceivable and practical
While interesting, a discussion of this application falls outside
context of this RFC. Very briefly, it can be said that an SNA/IP
based "subnet SNA gateway" application could do many of the
being discussed in the context of the DLSw specification [1].
5.
The performance of SNA sessions running over an SNA/IP
will be affected by the bandwidth available on the network and by
much traffic is on the network. SNA/IP is poised to take
advantage of the prioritization and class of service
promised in the next generation of IP. Today, SNA/IP can
Behl, Sterling & Teskey [Page 8]
RFC 1538 Advanced SNA/IP October 1993
advantage of router packet prioritization schemes based on
number. SNA/IP also leaves intact the standard SNA class of
prioritization protocol
Performance measures taken at McDATA comparing the throughput
SNA/IP and LLC across a single token-ring segment
approximately a 15 percent decrease in the maximum transactions
hour (1500 bytes to the DSN, 50 bytes out to the host) for SNA/IP
This decrease is well within the expected levels given the
processing requirements of TCP/IP over LLC in the LinkMaster 6200
LinkMaster 7100 operating environments
6. VTAM
The host VTAM definition of SNA/IP downstream nodes is dependent
the gateway implementation. Downstream nodes may appear as
major nodes connected to an XCA or as downstream nodes connected to
PU 2.0 controller [4].
7.
The authors wish to acknowledge that the definition of SNA/IP was
collaborative effort involving many individuals ranging
customers to sales and marketing personnel to engineers.
thanks go to David Beal, Steve Cartwright, Tracey Floming,
McEwen, Mark Platte, Paul Schroeder, Chuck Weil, and Marty Wright
who all played key roles in the development and testing of
protocol and also in the editing of this RFC
8.
[1] Dixon, R., and D. Kushi, "Data Link Switching: Switch-to-
Protocol", RFC 1434, IBM, March 1993.
[2] "Token-Ring Network Architecture Reference", IBM document #SC30-
3374-02.
[3] "Systems Network Architecture Formats", IBM document #GA27-3136-
12.
[4] "VTAM Resource Definition Reference", IBM document #SC31-6438-1.
[5] Comer, D., "Internetworking with TCP/IP Volume I", Prentice
1991.
[6] Postel, J., "Transmission Control Protocol - DARPA
Program Protocol Specification", STD 7, RFC 793, USC/
Sciences Institute, September 1981.
Behl, Sterling & Teskey [Page 9]
RFC 1538 Advanced SNA/IP October 1993
9. Security
This RFC does not address issues of security. SNA level
procedures and protocols apply when SNA/IP is used as the transport
10. Authors'
Wilfred
310 Interlocken
Broomfield, Colorado 80021
Phone: 303-460-4142
Email: wil@mcdata.
Barbara
310 Interlocken
Broomfield, Colorado 80021
Phone: 303-460-4211
Email: bjs@mcdata.
William
2125 112th Ave. North
Suite 303
Bellevue, WA 98004
Phone: 206-450-0650
Email: wct@ioc-sea.
Note: Any questions or comments relative to the contents of this
should be sent to snaip@mcdata.com. This address will be used
coordinate the handling of responses
11.
McDATA, the McDATA logo, and LinkMaster are registered trademarks
McDATA Corporation. All other product names and identifications
trademarks of their respective manufacturers, who are not
with McDATA Corporation
Behl, Sterling & Teskey [Page 10]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
