Path: utzoo!attcan!uunet!lll-winken!ames!mailrus!csd4.milw.wisc.edu!bionet!agate!ucbvax!YALEVM.BITNET!GILBERT From: GILBERT@YALEVM.BITNET (Howard Gilbert) Newsgroups: comp.protocols.tcp-ip Subject: Re: Standard (RFC) for IP-over-SNA Message-ID: <8901171147.AA17947@ucbvax.Berkeley.EDU> Date: 16 Jan 89 16:35:18 GMT References: Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: IBM TCP/IP For VM List Organization: The Internet Lines: 36 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.