The decision to be made is a business decision, not a technical decision. Is it more economical to develop and test new applications, replace all the peripheral processes and procedures, and retrain the corporate staff or to simply permit Communications Server to securely and reliably transport your tried-and-trusted SNA applications over your IP network? The answer seems clear. It becomes even clearer when you recognize that your business applications are fully enabled to exploit the most current IP networking technology. The best of both situations can be realized; that is, the stable, reliable and time-tested business logic exploiting the latest IP networking technology and sharing the IP infrastructure with Web-based offerings.
Sleep better tonight! There is no need to scrap your applications to move your networking to the latest IP technology. At this point, it should be clear that there is ample reason for you to strongly consider maintaining your applications and consolidate and simplify your network infrastructure. So, now let’s take a look at how to do this.
If you decide to keep your SNA application, what’s the best way to transport the data? Before the rise of IP as a transport technology, this was a fairly simple decision. You would use Network Control Program (NCP) running on an FEP to build your network. The FEP was connected to the mainframe via ESCON channels and the end users via a token-ring LAN. TCP/IP started changing this by allowing new alternatives. Over the years, many transport protocols have been delivered. Space does not permit us to discuss them all, so instead, we will focus on two that are significant today: data link switching (DLSw) and Enterprise Extender (EE). We will also examine mainframe network connectivity choices.
For many years, the high speed and reliability of ESCON made it an important piece of mainframe-based networking. However, high speed is relative. In the early days of SNA, 9600 baud links were considered high speed. This led to the development of concise data flows. The movement toward Web services and on demand computing requires significantly larger bandwidth. The ESCON connections that were once more than ample for host access may no longer cut it. In order to meet this demand for increased bandwidth, IBM developed the Open System Adapter Express (OSA Express or OSA-E). OSA-E is available in a variety of protocols; the most common is gigabit Ethernet. This adapter provides significantly more bandwidth and is optimized for network traffic. The chart in Figure 1 provides a quick comparison between ESCON and OSA-E bandwidth.
The next consideration is transporting the data across the network. Today, many networks are a hybrid of FEPbased SNA and router-based TCP/IP. The FEP provides host-to-network connectivity and DLSw transports the data across the TCP/IP network. This technology has worked well, but does create some issues. FEP-to-host connectivity uses ESCON. This means any traffic flowing across this part of the network cannot utilize the high-bandwidth capabilities of OSA-E. Additionally, since IBM has announced end of marketing for the 3745, the FEP solution has a limited life.
For years, DLSw has been a popular method of transporting SNA traffic across TCP/IP networks. However, DLSw has limitations in the areas of scalability, performance, and availability. DLSw encapsulates SNA traffic and then transports it through the network via TCP/IP. Performing this encapsulation is processor-intensive, often resulting in banks of DLSw routers in the data center to support all the downstream users. Since these routers are so busy performing encapsulation, they are usually dedicated to this purpose. An entirely different set of switches and routers is needed to actually handle the TCP/IP traffic. When the encapsulated SNA data is sent across the TCP/IP network, it is usually done with one priority. This means the SNA class of service is lost, resulting in mixing batch and interactive traffic. DLSw also introduces into the network single points of failure. If one of the endpoint DLSw routers fails, all the sessions through that router fail. This is similar to the limitations of the subarea SNA VR outages.
EE is an alternative technology for transporting SNA across an IP network. EE utilizes advanced peer-to-peer networking (APPN), high-performance routing (HPR) to send SNA data across an IP network. The data is encapsulated in user datagram protocol (UDP) packets for efficient IP routing. If a packet is lost, the EE endpoint will handle the retransmission. Embraced by many vendors, including IBM and Cisco, EE has become a great choice for consolidating your network to a single IP infrastructure. If you decide to use EE to transport your SNA data, which will simplify your network by removing SNA hardware such as FEPs and DLSw routers, the next question you need to consider is on what platform(s) should you implement EE? Since EE is included as part of Communications Server for z/OS and Linux on zSeries, the mainframe is an obvious choice, allowing you to benefit from the high-speed connectivity of OSA-E.
Deciding which platform to place at the other end of the EE connection is a bit more complicated. For connections between mainframes, the solution is obvious—on the other mainframe. In the distributed environment, two solutions are widely used: IBM Communications Server (available on Windows, AIX, and Linux) or PCOMM, and Cisco SNA Switch (SNASw). These endpoints can be placed in the data center, in a regional center, or even in the branch office. In a later section, we will focus on the actual location. For now, let’s look at some of the things to consider when choosing a specific platform.