whna@cgcha.uucp (Heinz Naef) (01/09/89)
I'm wondering if there is an RFC for the IP-over-SNA connectivity feature of
both the existing IBM VM/SP TCP/IP Rel. 1.2 Program Product (5798-FAL) and the
future IBM MVS TCP/IP Product. I would expect a public domain specification
similar to RFC 877 ("Describes a standard for the transmission of IP Datagrams
over Public Data Networks").
The only vague information which can be obtained from the IBM literature is
that LU type 0 is used; but LU type 0 is defined to be application specific.
In the manuals there is no reference at all to related publications which
would describe implementation details of this particular encapsulation method.
To allow implementers of independent network hardware to include this
connectivity option in their products, an Internet Request For Comments (RFC)
which describes the formats and protocols used for IP-over-SNA encapsulation
is required.
Heinz Naef, c/o CIBA-GEIGY AG, R-1032.5.58, P.O.Box, CH-4002 Basel, Switzerland
Internet: whna%cgch.uucp@uunet.uu.net - Phone: (+41) 61 697 26 75
BITNET: whna%cgch.uucp@cernvax.bitnet - Fax: (+41) 61 697 32 88
UUCP: cgch!whnaGILBERT@YALEVM.BITNET (Howard Gilbert) (01/17/89)
Re: The question of an RFC for IP-over-SNA (which the current IBM TCP/IP product supports.) This is forwarded from the Bitnet-based discussion list for the IBM TCP/IP product. Mark Bodenstein Cornell University ----------------------------Original message---------------------------- The current IBM LU 0 version of IP over SNA is not a suitable basis for standardization. It supports only mainframe to mainframe connections and is based on what is now obsolete protocol. What is needed is an RFC for IP over LU 6.2 SNA based on a PU 2.1, APPN, or subarea routing. This would then define a protocol which every IBM device from the PC to midrange to mainframe could use with or without the presence of a mainframe. The current LU 0 connection on the mainframe would then migrate to APPCCMD or Common Program Interface-Communications (CPI-C of SAA) to conform to this standard. The transport of IP over APPC is fairly trivial. Since there is no broadcast in SNA, it is necessary to translate the subnet portion of the IP address into an LU name. Since APPC is half-duplex, it may be necessary to run two parallel sessions. Presumably you would flush the buffer with every IP packet and never confirm. Mapped conversations look appropriate. I see no need for PIP data. The rest is fill-in-the-blanks. Adding the SNA network as a supported subnet protocol to IP would make TCP/IP more accessable in large commercial shops. However, most such organizations may not need internet access. They need to connect widely scattered internal non-IBM equipment across their existing SNA wide area network which already ties all corporate locations together. As such they need a PC based SNA router in the remote location which LU 0 cannot supply. They probably cannot afford and do not require a separate IP based communications link to the mainframe or between the remote nodes given that the SNA links are already in place and connect everyone.