Believe it or not, most of the networking concepts in this book are not new. Most networking issues were resolved in concept long ago when the same types of problems cropped up in the mainframe world. In fact, it is ironic that the trend towards web-based applications revives technologies similar to mainframe 3270 terminal applications.
IBM’s mainframe-network infrastructure is referred to as Systems Network Architecture (SNA, pronounced “snah”). SNA was the prevailing enterprise network infrastructure. It was developed in the 1970s at IBM with an overall architecture similar to the Open System Interconnection (OSI) reference model. A mainframe running Advanced Communication Facility/Virtual Telecommunication Access Method (ACF/VTAM) serves as the center of an SNA network. ACF/VTAM is responsible for establishing all network sessions and for activating and deactivating network resources. SNA explicitly defines all resources, which eliminates the need for broadcast traffic and reduces header size.
As Transmission Control Protocol/Internet Protocol (TCP/IP) (and other desktop protocols such as the Novell Internetwork Packet Exchange (IPX)) gained acceptance in enterprise networks, companies faced having to support multiple network infrastructures. The desire for a common set of protocols grew. TCP/IP eventually became the protocol of choice for convergence mainly due to certain technical benefits and the open nature of the protocols, which facilitated support from multiple vendors. Additionally, with the wide acceptance of the Internet and corporate intranets, companies wanted their traditional non-IP infrastructure devices to communicate with the new IP devices.
Larger companies had, and continue to have, large investments in SNA equipment. Although the maintenance and annual upkeep for these devices is relatively more expensive as they grow older, companies want to bridge the two worlds of SNA and TCP/IP together.
It is the convergence of these two worlds that is relevant to Cisco networking. The three components of interest are the following:
Line consolidation—. With a single network infrastructure based on TCP/IP, you can collapse multiple single-protocol lines to remote locations into a single line.
Front-end processor (FEP) replacement—. Channel-attached routers can replace considerably more expensive FEPs (and other special-purpose mainframe channel-attached equipment).
Desktop consolidation—. Desktop computers required multiple protocol stacks (one for 3270 mainframe connectivity, one for TCP/IP, and one for a file-and print-sharing service such as Novell’s NetWare). Multiple protocol stacks are expensive and difficult to support. Instead, TCP/IP can serve as the single transport for terminal emulation as well as the other services.
Until recently, all midsize and large corporations, government institutions, and educational organizations ran their applications on IBM (and compatible) mainframes and midrange systems that ran primarily on SNA networks. SNA networks provided the following benefits:
High availability—. Well-designed SNA networks provided services around the clock and experienced little disruption in service: 99.99 percent or better availability.
Predictable response times—. Built around high transaction rates, SNA networks could provide predictable and consistent response times.
Secure—. SNA networks, by design, were difficult to hack into, thus providing secure access to mission-critical applications.
Despite these benefits, TCP/IP, which was considerably weaker in the preceding SNA characteristics, became popular because it addressed the following SNA weaknesses:
Lack of dynamic definition and configuration of resources—. You had to predefine everything in an SNA network. Although IBM addressed these issues later with its Advanced Peer-to-Peer Networking (APPN), TCP/IP had already taken hold with its more flexible and dynamic nature.
Proprietary protocols—. IBM defined, owned, and managed SNA. At the end of the 1980s, IBM customers began demanding support for protocols based on open standards. Rather than adopt an existing open standard, IBM attempted to introduce its own protocols into the public domain (APPN). However, APPN was more expensive and available on fewer platforms than TCP/IP.
Eventually, IBM’s attempt to provide its own standards lost out to TCP/IP.
Corporations could not migrate to IP in one sitting. Instead, they needed to take a methodical multistep approach to making the switch.
The first step to migration was the tunneling of existing SNA protocols across IP networks. As corporations began considering their migration, they discovered that they were managing at least two network infrastructures: TCP/IP and SNA. Companies had a choice: Run the IP traffic across an SNA backbone or vice versa.
For reasons stated earlier, SNA as a backbone didn’t make sense. As a result, routers, which formed the core of IP internetworks, began supporting the encapsulation (tunneling) of SNA-related protocols. Some advantages realized with SNA encapsulation include the following:
Dynamic rerouting—. You can route IP-encapsulated SNA traffic around a failure using the inherently dynamic IP routing protocols.
Flexible encapsulation schemes—. SNA encapsulation allows for more flexible SNA device configurations and reduced polling across the backbone.
Cisco Systems introduced remote source-route bridging (RSRB) as a proprietary solution for SNA encapsulation. The industry has since adopted the data-link switching (DLSw) standard, which is widely accepted and implemented. Routers also provide the capability to encapsulate other types of legacy traffic, such as async and bisync.
The final step in the migration is a complete conversion to IP-based mainframe connectivity. You achieve this step through IP-based client applications and IP connectivity direct to the mainframe.