Morten I'm sorry this is so late. I dipped into a successor thread and have been tracking back to whence the spotted contagion originated. A change in subject might have helped I guess.
> ... and SNA didn't have real internetworking. And the fact that it had *two* internetworking architectures, the conversion of the older to the newer exercising the brains of very many system programmers these days, is a fact which does not disturb your ignorance! > So, in the start the existing hardware of ... X.25, Frame Relay, ethernet ... could be used more or less as is, even if they were never designed with tcp/ip in mind. "So, in the start the existing hardware of ... X.25, Frame Relay, ethernet, ... could be used more or less as is, even if they were never designed with SNA in mind." Please examine those two sentences and see if you can spot a difference. I've left in only those - in effect - data link control protocols which I know about extensively and which extraordinarily easily support SNA. > Then came a next generation of "tcp/ip aware" networks, like ATM, ... "Then came a next generation of "SNA aware" networks, like ATM, ..." Same trick although it might apply only to the ATM case I have left in. The anti-SNA bigotry had probably been all that has prevented there being an SNA use for these more recent innovations. > Still, 0.4% of the exchange traffic we have measured is X.25. Nearly 2% is frame relay. And your point is? These protocols operate at the data link control level for both SNA and IP. > SNA never embraced TCP/IP. Many others did, and the protocols survive on top of the Internet. Nonsense! SNA has embraced, is embracing and will very probably continue to embrace IP - although there's a smidgen of correctness in your assertion in that SNA implementations have abandoned using TCP. First there were the AnyNet products implementing the Multiprotocol Transport Networking architecture which was an universal approach to making protocol A (above) run over or concatenate with protocol B (below). The most well known of these AnyNet implementations was AnyNet SNA over IP, indeed so well known that it tended to eclipse all the others so that often when folk spoke of AnyNet they actually meant just AnyNet SNA over IP. AnyNet SNA over IP employed TCP as a way of transporting SNA traffic where the TCP connection was made to appear to be an SNA logical link. AnyNet implementations including AnyNet SNA over IP have now been withdrawn. A more efficient approach to the same idea is Enterprise Extender where the SNA logical link uses UDP in conjunction with APPN/HPR. Note that AnyNet SNA over IP required TCP to simulate a LEN link - even exceptionally allowing DLUR- DLUS for SSCP-dependent sessions. Enterprise Extender is fully supported by IBM product offerings on Intel, pSeries, iSeries and zSeries platforms. It is partially supported on Cisco's SNASw and Microsoft's HIS. > And the legacy networks run happily on top of the Internet. I'm not quite sure what you are on about here. IBM introduced MPTN specifically to provide a framework for the concept of running one communications protocol's applications in conjunction with another communications protocol for transport. If I have guessed at what you mean correctly, I could say "And the legacy networks run happily on top of SNA." - Incidentally your post does not appear in the IBM-MAIN archives. I discovered it only because there was a reference in an archived post and I found it in Google Groups. I also discovered there were many more posters not showing up in the archives but yours was the only one with a modicum of usefulness about it - even if completely wrong! Chris Mason >Morten Reistad <[email protected]> writes: >> SNA never embraced TCP/IP. Many others did, and the protocols survive >> on top of the Internet. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
