rfc1538.txt

RFC 的详细文档！

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: [e-mail].

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]