rfc1538.txt

RFC 的详细文档！

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


   Barbara Sterling
   310 Interlocken Parkway
   Broomfield, Colorado  80021

   Phone:  [phone]
   Email:  [e-mail]


   William Teskey
   2125 112th Ave. North East
   Suite 303
   Bellevue, WA  98004

   Phone:  [phone]
   Email:  [e-mail]

   Note: Any questions or comments relative to the contents of this RFC
   should be sent to [e-mail].  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]