Background on SNA/IP implementation

In the early 1990s, enterprises began to implement router technology in their backbone networks. At that time, enterprise networks resembled the Tower of Babel; that is, many networking protocols were proprietary and were not able to communicate with each other. Among the dominant proprietary protocols were IBM's SNA, Digital Equipment Corporation's DECNET, Novel's IPX, and Microsoft's NetBIOS.

Router vendors were enthusiastic about introducing their products, and competition concentrated on whose product supported the greatest number of protocols. This introduction of multi-protocol routers into an enterprise backbone network helped consolidate many networking protocols into one infrastructure, thus reducing the expenses related to communication lines.

But not long after implementing routers in their backbone network, network managers realized that it is not easy to control, maintain, and perform problem determination in a network that implements multiple protocols. Implementing only one protocol in the backbone network reduces the complexity of the network and the router. So, there needed to be a single protocol or set of protocols.

The decision on which protocol set to use was easy. At that time, the Internet usage was growing dramatically among home users and enterprises. Because of the Internet, IP, TCP, and UDP were the protocols of choice. Many computer and operating system vendors added IP and the application protocols to their products and allowed access to their proprietary hardware and software using TCP/IP.

Some networking protocols, including IBM subarea network, were non-routable. By non-routable is meant that, based on the protocol headers, a router cannot decide where to route the packet. Although APPN intermediate session routing and high performance routing are routable, the resources (CPU and memory) required for implementing these protocols is very high and almost impractical. To accommodate SNA in a router-based network, IBM designed and defined several protocols that allow using SNA subarea and APPN protocols in a router-based IP backbone.

Why preserve SNA applications?

Ideally, all applications use the same protocol. Because TCP is the de facto application protocol, TCP is always the best solution. Using TCP as the application protocol requires no protocol conversion or encapsulation, and runs on the IP network. This, however is rarely possible within a large organization that has a huge investment in SNA applications.

A transaction-oriented program is dependent on the underlying protocol it uses. The application programming interface is different if one uses SNA or TCP. Changing a transaction-oriented program from SNA to TCP requires a redesign of the communication part in the program and replacing the code that handles error recovery, exception processing, and many other tasks. Many computer shops are reluctant to enter into huge conversion projects, such as SNA to TCP, that fail to introduce new architectures, man-machine interfaces, and the like. Shops use their budgets to modernize the applications rather than convert SNA applications just for the sake of having a common infrastructure.

Conversion of existing SNA applications to IP-enabled applications proves to be uneconomical and very technical due to the complexity of the applications (remember, these have been developed over many years), lack of skills in converting SNA to TCP, and the time required to do such a conversion. A conversion project can have a high degree of cost and risk.

This section discusses how to preserve SNA applications and investment in endpoint hardware (PU 2.0 or 2.1, such as banking or retail branch servers), while converging onto an IP-based backbone.

SNA applications and integration methods

SNA applications can be divided into two categories: 3270-based applications, and application-to-application, as explained here.

3270-based applications
In this case, end users communicate with the mainframe using a 3270 display or a workstation that has 3270 emulation software installed. Data sent from a data communication (DC) program (like CICS, IMS, and sometimes even TSO) is displayed on the 3270 screen. The screen format is sent from the data communication transaction program and is not manipulated on its way to the 3270 screen.
Application-to-application
In this case, the remote end (branch office) has a programmable endpoint controller or server that does some local processing, sends the data using SNA to the data communication transaction program, and upon receiving the reply to an inquiry or database update, displays it on the end user's workstation.

In the early days of SNA, application-to-application communication used the LU 0 protocol, and as SNA evolved, new applications used APPC.

There are several different ways of running mixed SNA and IP protocols over single IP protocol transport networks. The technique used to integrate SNA into the IP backbone depends on the SNA application type used.

Telnet/3270: Abbreviated as "TN3270." This integration method is used for 3270-based applications. The SNA 3270 data stream is carried over TCP connections to a TN3270 server (z/OS).
Data Link Switching: Abbreviated as "DLSw." SNA traffic is encapsulated in TCP packets.
Enterprise Extender: Abbreviated as "EE." SNA/APPN (HPR) packets are encapsulated as User Datagram Protocol (UDP) packets over an IP network.

No change in the SNA application programs is required for any of the three integration methods.

Although DLSw can be used for other non-routable protocols, this information focuses on DLSw for SNA.