TCP/IP versus SNA-- Part of the History!!

 TCP/IP and SNA were designed from diametrically opposite standpoints: SNA once was a centrally managed architecture with predefined static routing aimed at high bandwidth utilization and optimal response time, whereas TCP/IP is a decentralized network with dynamic routing aimed at easier connectivity.

 Although the number of TCP/IP installations is growing at an exponential rate (almost any PC-based communications package includes the IP stack), not too many of 50,000+ SNA installations migrated their mission-critical applications to IP.

 The developers and users realized that, unfortunately, the bandwidth of the WAN is not sufficient for LAN-based protocols. Most of the LAN protocols (AppleTalk, network basic input/output systems [NetBIOS], internetwork packet exchange [IPX]) are too chatty and may cause so-called broadcast storms.

 The next natural step was to utilize the least expensive and most available protocol for WAN communications. However, there was no magic with TCP/IP either:

• The overhead was significantly higher than what it was with SNA. While this was not a real problem on LANs, it became a major headache on the WANs.
• An additional problem is with TCP/IP's use of congestion detection as opposed to congestion avoidance used in SNA; TCP/IP networks are more susceptible to runaway overloads at high line utilization.
• Other problems are introduced by the ancient, but still the most popular, IP routing information protocol (RIP). As a distance-vector protocol, RIP is inflexible, it introduces additional overhead, and can create loops and black holes in complex IP networks.

 So, Why didn't SNA really take off like TCP/IP did?

• The traditional (pre-APPN) SNA, commonly associated with 3270 applications, is connection-oriented protocol with routing only at the fourth transport layer of the OSI model (equivalent to the transmission control layer in SNA). The downside is this layer lacks dynamic rerouting capabilities, and high intelligence is required in all routing nodes.
• The APPN today is usually associated with application-to-application (peer-to-peer) networking. It employs a connection-oriented intermediate session routing (ISR) link state protocol. Further explanation is beyond the scope of this work!
• Each node is responsible for computing the best routes to any other node in the network. APPN network nodes are responsible for maintaining the topology database, whose integrity is preserved by using sessions between adjacent Network Nodes.
• This is different from distance-vector based protocols (i.e., RIP), where such information is periodically broadcast (every thirty seconds with RIP), regardless of whether there were any changes.
• The more advanced TCP/IP link-state based routing protocols (such as open shortest path first [OSPF]) also broadcast their routing information when a link state is changed. However, they also periodically broadcast (every thirty minutes) this information regardless of changes in the link states.
• When a session is established between two nodes in the APPN network it will live as long as the preferred route, selected during the session setup, is available. The major drawback of this method is that the preferred route, during a long-lived session setup, will not necessarily remain the optimal route for the life of the session.
• There is also no rerouting around failures (i.e. sessions have to be restarted even due to an intermediary node failure), which may potentially disrupt a client/server application.

 A vast majority of SNA shops are reluctant to convert their SNA backbones to TCP/IP, protecting performance of mission-critical applications.

 Many vendors realized the importance of consolidation of the network infrastructure and the potential savings and developed products allowing utilization of non-SNA networks for SNA traffic.

 Some solutions provide SNA based gateways and routers to allow utilization of SNA backbone for non-SNA traffic. This approach permits capitalization on investments that many corporations have already made in their SNA backbones.

 It also grants the users a better utilized and more cost-effective SNA network, supporting many new applications.

 TCP/IP is actually two protocols sandwiched one over other. IP deals exclusively with the routers and is primarily concerned with the speed of delivery rather than reliability. To combat this problem of unreliability, TCP was developed.

 The TCP/IP protocols were developed with public funding and are in the public domain. This was probably the sole reason for its popularity!!

 The TCP/IP protocol suite is a set of network standards originally developed for the Advanced Research Projects Agency (ARPA), of the US Department of Defense. This development led to the creation of the ARPANET which, in turn, led to the system of national and international networks known as the Internet.

 The formal network standards for the TCP/IP protocol suite are available as a set of documents known as Request for Comments (RFCs). The RFCs contain a wealth of material, and some RFCs are written specifically to provide tutorial information on the TCP/IP protocol suite.

 Some sites from where you can download the RFC's

0. DS.INTERNIC.NET {Username: anonymous, Password: Email address}
1. NIC.DDN.MIL {Username: anonymous, Password: guest}
2. FTP.NISC.SRI.COM {Username: anonymous, Password: guest}
3. NIS.NSF.NET {Username: anonymous, Password: guest}
4. NISC.JVNC.NET
5. VENERA.ISI.EDU {Username: anonymous, Password: guest}
6. WUARCHIVE.WUSTL.EDU
7. FTP.CONCERT.NET {Username: anonymous, Password: Email address}
8. SRC.DOC.IC.AC.UK {Username: anonymous, Password: Email address

 RFC Index search at <http://www.nexor.com/public/rfc/index/rfc.html>

 Hard Copies of the RFC's can be obtained from

I have listed some books, which I have found very useful and interesting.

Back to Main