Network Working Group          Harold Stevenson & Steven Schwell,
     INTERNET DRAFT                      Systems Strategies, Inc.
                                    William Siddall, IBM


            A Method for the Transmission of IP Datagrams
                          Over SNA Networks
                      Using LU6.2 Conversations

                            11 May 1992
                              Rev. 1.1


     Status of this Memo

        This DRAFT proposes a method for the transmission of IP
        datagrams over SNA networks using Advanced Program to
        Program Communication (APPC) conversations, and requests
        discussion and suggestions for improvements. Distribution
        of this memo is unlimited.


     1. Introduction

        IP datagrams between two LU 6.2 nodes are transmitted as GDS
        records on a uni-directional conversation between a pair of
        sending and receiving transaction programs (TPs). The sending
        TP obtains datagrams from its IP interface and maps the
        destination address field of the IP protocol header into a
        remote Logical Unit (LU) name. Conversations are allocated
        when necessary, i.e. if a conversation does not yet exist to
        that remote LU, then one is allocated. The conversation is
        deallocated by the sending TP after some period of inactivity.
        It is recommended that this inactivity period default to five
        minutes.

        The conversation may also be deallocated based on lack of
        resources in the sending or receiving TPs or LUs.

        The complete datagram including the protocol header is placed
        in a GDS record and sent to the partner receiving TP. The
        receiving TP retrieves the GDS record on the conversation and
        forwards the received datagram to its IP interface. Failure to
        map the IP address or any allocation failures will result in
        loss of the IP datagrams. The sending TP may also optionally
        discard the datagram if previous allocation attempts to the
        same remote LU have failed repeatedly. In such cases, there
        must also be a method for determining when to retry.

     2. Proposed Standards

        2.1   Each datagram obtained from the IP interface results
              in a single GDS record being transmitted over a
              conversation. The Logical Length field of the GDS
              record is set to the Total Length (TL) field of the
              datagram protocol header plus 4. The GDS ID field of
              the GDS record is set to HEX 12FF so that the IP
              transaction programs may be implemented using mapped
              conversation verbs. The data of the GDS record
              contains the entire unaltered datagram, including
              the IP protocol header.

        2.2   The name of the receiving TP is "IPXPORT" (encoded as
              EBCDIC).

        2.3   The only verbs issued by the sending TP are
              the mapped conversation versions of Allocate,
              Send_Data, Deallocate and, optionally,
              Flush. The Flush verb is issued to force the IP
              datagram out of the local LU if the conversation is
              not going to be immediately ended with Deallocate.
              The only verbs issued by the receiving TP are
              Receive_Data and, optionally, Deallocate. Either TP
              is allowed to Deallocate the conversation due to
              error conditions or resource problems on its system.

     3. Remarks

        3.1   The method of mapping IP addresses to LU names
              is product specific. The mode name to be used in
              the Allocate request shall default to "IPMODE" (encoded
              as EBCDIC).  An implementing product may optionally
              allow the user to specify a different mode name to be
              used.

              An area for future study is the mapping of the Internet
              "Type of Service" field of the IP protocol header into
              an appropriate mode name with an SNA Class of Service
              definition which best approximates the specified IP
              Type of Service.

        3.2   Concurrent conversations between the same sending
              and receiving LUs should be allowed. This provides
              for the simultaneous transmission of multiple
              datagrams between the same IP/LU6.2 nodes if
              multiple SNA connections are allowed between these
              nodes.

        3.3   The receiving TP should be allowed to accept more
              than one incoming conversation request, but multiple
              instances of the receiving TP may be necessary if
              the local implementation of LU6.2 does not allow a
              single transaction program to accept multiple
              incoming conversation requests.

        3.4   IP packets addressed to broadcast or multicast IP
              addresses are not considered in this proposed
              standard.

        3.5   Conversation security is not addressed in this
              proposed standard. Session security is optional
              at both the BIND password and session cryptography
              level.

     Authors' Addresses

          Harold Stevenson
          Systems Strategies, Inc.
          1 Penn Plaza, Suite 4311, NY, NY 10119
          Phone: 212 279 8400
          Fax:   212 967 8368
          uunet: uunet!ssiny!hhs
          Email: hhs%ssiny.uucp@uunet.uu.net

          William Siddall
          IBM
          P.O. Box 12195
          Research Triangle Park, NC 27709
          Phone: 919 254 4384
          Fax:   919 254 5483
          Email: siddall@ralvm6.vnet.ibm.com