summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1538.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1538.txt')
-rw-r--r--doc/rfc/rfc1538.txt563
1 files changed, 563 insertions, 0 deletions
diff --git a/doc/rfc/rfc1538.txt b/doc/rfc/rfc1538.txt
new file mode 100644
index 0000000..b234866
--- /dev/null
+++ b/doc/rfc/rfc1538.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group W. Behl
+Request for Comments: 1538 McDATA Corporation
+Category: Informational B. Sterling
+ McDATA Corporation
+ W. Teskey
+ I/O Concepts
+ October 1993
+
+
+ Advanced SNA/IP : A Simple SNA Transport Protocol
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard. Distribution of this memo is
+ unlimited.
+
+Abstract
+
+ This RFC provides information for the Internet community about a
+ method for establishing and maintaining SNA sessions over an IP
+ internet. While the issues discussed may not be directly relevant to
+ the research problems of the Internet, they may be interesting to a
+ number of researchers and implementors. Any questions or comments
+ relative to the contents of this RFC may be sent to the following
+ Internet address: snaip@mcdata.com.
+
+Table of Contents
+
+ 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. Introduction
+
+ Advanced SNA/IP suggests a method for the transmission of SNA session
+ data over an IP network. This memo documents the SNA/IP protocol as
+ implemented in the McDATA LinkMaster(R) 6200 Network Gateway, McDATA
+ LinkMaster(R) 7100 Network Controller, and I/O Concepts X-Direct
+ TN3270 Server.
+
+ Advanced SNA/IP differs from other protocols designed to enable
+ routing of SNA session traffic over an IP network. SNA/IP was
+ originally designed for implementation in peripheral network nodes
+ like SNA gateways and downstream nodes (DSNs). It is the authors'
+ view, however, that SNA/IP could also be implemented in intermediate
+ network nodes like routers as the base for an LLC to IP subnet
+ gateway or data link switch function.
+
+2. Motivation and Rationale
+
+ The token-ring media access control (MAC) protocol 802.5 and logical
+ link control (LLC) protocol 802.2 were the first set of LAN protocols
+ used to provide a reliable and connection-oriented data link service
+ for SNA sessions in a LAN environment.
+
+ McDATA's experience with transporting SNA over 802.5 networks led to
+ an 802.3/802.2 (Ethernet) based variation. As prospective customers
+ were introduced to these Ethernet products, the question of
+ routability arose. Network administrators, accustomed to working
+ with Ethernet networks and the IP-based protocols, required an IP
+ routable solution. McDATA's "SNA over Ethernet" products were
+ bridgeable, but were not routable.
+
+ SNA sessions require a reliable and connection-oriented data link.
+ TCP running over IP provides a reliable and connection-oriented
+ transport service and has the added benefit of being routable. It
+ seemed the UDP and TCP protocols could be used in place of 802.2 Type
+ I and Type II levels of service used in traditional SNA token-ring
+ implementations. Advanced SNA/IP was created as a result of these
+ observations.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Behl, Sterling & Teskey [Page 2]
+
+RFC 1538 Advanced SNA/IP October 1993
+
+
+3. SNA/IP Protocol Specification
+
+3.1. Glossary
+
+ Data Link Switching (DLSw) - This is best described as a routing
+ protocol used for the conversion of LLC-based SNA sessions to an IP
+ form. The initial version of the DLSw protocol is documented in the
+ 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.) as
+ 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 SNA
+ token-ring segment and an IP network that performs local termination
+ of the LLC connections, a mapping function of source address to
+ destination IP address, and a conversion (switching) function of LLC
+ to IP.
+
+3.2. Conventions and Assumptions
+
+ Frame formats are shown starting with the IP header. Other headers
+ 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 SNA
+ protocol (to the extent it applies to SNA Gateway and DSN functions)
+ and the base set of TCP/IP protocols. Where practical, the reader is
+ asked to refer to appropriate SNA and TCP/IP documentation.
+
+3.3. The Protocol
+
+ Conceptually, there are three phases to the Advanced SNA/IP protocol:
+ the Connection Establishment phase, the Data Transfer phase, and the
+ Connection Termination phase.
+
+3.3.1. Connection Establishment
+
+ Connection Establishment involves the exchange of logical XID packets
+ between the connecting end nodes and culminates in the establishment
+ of a TCP connection. This process is similar to the IBM-specified
+ 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 I
+ messages, SNA/IP defines the following set of UDP datagrams:
+
+
+
+Behl, Sterling & Teskey [Page 3]
+
+RFC 1538 Advanced SNA/IP October 1993
+
+
+ Logical Null XID
+
+ Use: Sent by an initiating node (such as a DSN) when the
+ connection to another SNA node is desired.
+
+ The Logical Null XID communicates the sending node's
+ desire to negotiate connection parameters. Once those
+ parameters are established, the Logical Null XID
+ communicates the sender's TCP port to which a connection
+ is to be made.
+
+ Format:
+
+ ------------------------------------
+ | IP Header | UDP Header | 0xBF |
+ ------------------------------------
+
+ Source IP address: The IP address of the initiating
+ node.
+ Destination IP address: The IP address of the partner SNA
+ node.
+ Source UDP Port: Must match the TCP port number to be
+ used in the eventual TCP connection.
+ Destination UDP Port: A known port on the partner node
+ that expects SNA/IP datagrams.
+
+
+ XID Request
+
+ Use: Sent in response to a Logical Null XID and requests the
+ 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 XID
+ datagram.
+
+ The format of the XID Request and Logical Null XID are the
+ same. The two types are distinguished by the roles assumed by
+ the two nodes. In current implementations, the DSN initiates
+ the XID exchange by sending the Logical Null XID. The SNA
+ Gateway responds with the XID request.
+
+
+
+
+Behl, Sterling & Teskey [Page 4]
+
+RFC 1538 Advanced SNA/IP October 1993
+
+
+
+ Logical SNA XID
+
+ Use: Sent in response to an XID Request and in the context of
+ 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 XID
+ [3].
+ For PU 2.1 nodes, the SNA XID data consists of a Format 3 XID
+ [3].
+
+
+ A typical Connection Establishment data flow appears below.
+
+
+ Node 1 Node 2
+
+ Logical Null XID ------------------------->
+ <------------------------ XID Request
+ Logical SNA XID -------------------------->
+ <------------------------ TCP SYN
+ TCP SYN ACK ----------------------------->
+ <------------------------ TCP ACK
+
+ Note: The source UDP port of the Logical Null XID equals the
+ destination TCP port of the TCP SYN segment.
+
+ Retries of the Logical Null XID by the initiating node should occur
+ periodically until an XID Request is received in reply. The frequency
+ of the retries is left up to the implementor. The lower bound on the
+ retry timer should be more than the expected round trip time for a
+ packet on the network.
+
+3.3.2. Data Transfer
+
+ There are no special packets defined for the Data Transfer phase.
+ Once the TCP connection is established, SNA Request Units (RUs) may
+ be exchanged between the two end nodes. The SNA session data appears
+ as TCP segment data. The only added SNA/IP requirement is that each
+ SNA message consisting of a Transmission Header (TH),
+ Request/Response Header (RH) and an optional Request/Response Request
+ Unit (RU) be preceded by a two octet length field. Examples of Data
+
+
+
+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 length
+ value.
+
+ The format of the SNA Message pieces are as defined by SNA [3].
+
+ Reliable and sequential delivery of data is provided by the TCP
+ protocol [5,6].
+
+3.3.3. Connection Termination and Loss
+
+ Either SNA node may, at any time, terminate the logical SNA
+ connection by issuing a TCP-level FIN segment. Dictates of the TCP
+ protocol apply to this termination process [5,6].
+
+ A connection is also terminated, though not as cleanly, if a TCP
+ Reset segment is sent by either SNA node.
+
+ Once a connection is terminated, a new connection may be established
+ by the process outlined in the Connection Establishment section. For
+ reconnections made to the LinkMaster 6200 gateway, the same UDP
+ source port must be used by the initiating node. This implies that
+ the same TCP port is used. This requirement stems from the fact the
+ gateway may not always be aware that a TCP connection has been
+ terminated. This would happen if the DSN became disabled prior to
+ sending a FIN or Reset segment. Under these circumstances, SNA host
+ resources remain allocated and a reconnection from a DSN, which the
+ host believes to already be in session, is not allowed. By requiring
+ the DSN to use the same port when reestablishing a connection, the
+ LinkMaster 6200 is able to recognize when a reset of the host
+ connection is required.
+
+
+
+
+
+
+
+
+Behl, Sterling & Teskey [Page 6]
+
+RFC 1538 Advanced SNA/IP October 1993
+
+
+3.3.4. Complete Session Data Flow
+
+ Node 1 Node 2
+
+ Logical Null XID ------------------------->
+ (UDP Datagram)
+ Logical Null XID ------------------------->
+ (UDP Datagram)
+ <------------------------ XID Request
+ (UDP Datagram)
+ Logical SNA XID -------------------------->
+ (UDP Datagram)
+ <------------------------ TCP SYN
+ (TCP Message)
+ TCP SYN ACK ----------------------------->
+ (TCP Message)
+ <------------------------ TCP SYN
+ (TCP Message)
+
+ ****************** Connection Established *******************
+
+ <------------------------ SNA ACTPU
+ (TCP Message)
+ SNA ACTPU Response --------------------->
+ (TCP Message)
+ <------------------------ SNA ACTLU
+ (TCP Message)
+ SNA ACTLU Response --------------------->
+ (TCP Message)
+ .
+ .
+ .
+ <------------------------ TCP FIN
+ (TCP Message)
+ TCP FIN ACK ------------------------>
+ (TCP Message)
+ <------------------------ TCP ACK
+ (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 Node
+
+ Transition State
+ Given State | No Conn | Null XID Sent | SNA XID Sent | Conn Estb
+ ------------+---------+---------------+--------------+-----------
+ 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 | Indication
+ Sent | | Timer Event | Received | that TCP
+ | | ----> Resend | ----> Send | connection
+ | | Null XID | SNA XID | is estb.
+ | | | |
+ ------------+---------+---------------+--------------+-----------
+ Connection | Indica- | | | SNA
+ Established | tion | | | Session
+ | that | | | Data
+ | TCP conn| | |
+ | term. | | |
+
+
+ A gateway state transition table is not provided here because the
+ state transitions are dependent on the nature of the SNA host
+ interface (3172 Channel Protocol, 3174 Channel Protocol, SDLC, etc.).
+
+4. LLC to SNA/IP Conversion
+
+ The use of Advanced SNA/IP to convert conventional token ring- based
+ SNA traffic to a routable form is both conceivable and practical.
+ While interesting, a discussion of this application falls outside the
+ context of this RFC. Very briefly, it can be said that an SNA/IP-
+ based "subnet SNA gateway" application could do many of the things
+ being discussed in the context of the DLSw specification [1].
+
+5. Performance
+
+ The performance of SNA sessions running over an SNA/IP connection
+ will be affected by the bandwidth available on the network and by how
+ much traffic is on the network. SNA/IP is poised to take full
+ advantage of the prioritization and class of service enhancements
+ promised in the next generation of IP. Today, SNA/IP can take
+
+
+
+Behl, Sterling & Teskey [Page 8]
+
+RFC 1538 Advanced SNA/IP October 1993
+
+
+ advantage of router packet prioritization schemes based on port
+ number. SNA/IP also leaves intact the standard SNA class of service
+ prioritization protocol.
+
+ Performance measures taken at McDATA comparing the throughput of
+ SNA/IP and LLC across a single token-ring segment showed
+ approximately a 15 percent decrease in the maximum transactions per
+ 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 added
+ processing requirements of TCP/IP over LLC in the LinkMaster 6200 and
+ LinkMaster 7100 operating environments.
+
+6. VTAM Definition
+
+ The host VTAM definition of SNA/IP downstream nodes is dependent on
+ the gateway implementation. Downstream nodes may appear as switched
+ major nodes connected to an XCA or as downstream nodes connected to a
+ PU 2.0 controller [4].
+
+7. Acknowledgments
+
+ The authors wish to acknowledge that the definition of SNA/IP was a
+ collaborative effort involving many individuals ranging from
+ customers to sales and marketing personnel to engineers. Particular
+ thanks go to David Beal, Steve Cartwright, Tracey Floming, Audrey
+ McEwen, Mark Platte, Paul Schroeder, Chuck Weil, and Marty Wright,
+ who all played key roles in the development and testing of this
+ protocol and also in the editing of this RFC.
+
+8. References
+
+ [1] Dixon, R., and D. Kushi, "Data Link Switching: Switch-to-Switch
+ 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 Hall
+ 1991.
+
+ [6] Postel, J., "Transmission Control Protocol - DARPA Internet
+ Program Protocol Specification", STD 7, RFC 793, USC/Information
+ Sciences Institute, September 1981.
+
+
+
+Behl, Sterling & Teskey [Page 9]
+
+RFC 1538 Advanced SNA/IP October 1993
+
+
+9. Security Considerations
+
+ This RFC does not address issues of security. SNA level security
+ procedures and protocols apply when SNA/IP is used as the transport.
+
+10. Authors' Addresses
+
+ Wilfred Behl
+ 310 Interlocken Parkway
+ Broomfield, Colorado 80021
+
+ Phone: 303-460-4142
+ Email: wil@mcdata.com
+
+
+ Barbara Sterling
+ 310 Interlocken Parkway
+ Broomfield, Colorado 80021
+
+ Phone: 303-460-4211
+ Email: bjs@mcdata.com
+
+
+ William Teskey
+ 2125 112th Ave. North East
+ Suite 303
+ Bellevue, WA 98004
+
+ Phone: 206-450-0650
+ Email: wct@ioc-sea.com
+
+ Note: Any questions or comments relative to the contents of this RFC
+ should be sent to snaip@mcdata.com. This address will be used to
+ coordinate the handling of responses.
+
+11. Disclaimer
+
+ McDATA, the McDATA logo, and LinkMaster are registered trademarks of
+ McDATA Corporation. All other product names and identifications are
+ trademarks of their respective manufacturers, who are not affiliated
+ with McDATA Corporation.
+
+
+
+
+
+
+
+
+
+
+Behl, Sterling & Teskey [Page 10]
+ \ No newline at end of file