|
| About Us | Products | Solutions | Resources | Support |
| Home : Resources : Newsletters | |||||||||||||
|
An SNA/VTAM OverviewOriginally published: Winter 2002
SNA was developed by IBM in the 1970s as a proprietary protocol for telecommunications networks, to deliver the airtight security and superior throughput demanded by large enterprises who were wary of the services provided by existing telecommunications networks. It quickly became the de facto network topology, responsible at its peak for handling 90% of the world's business data. For the next 30 years, SNA reigned as the undisputed King of the networking World. Now, however, it seems that SNA has disappeared from the networking horizons, only to be glimpsed canoodling with the likes of open and distributed architectures, TCP/IP, and other Internet-oriented technologies. The trend has raised the question of whether SNA is destined for "where are they now?" status. In the following article, we discuss some of the main SNA concepts, key differences between SNA and TCP/IP, and how and why enterprises are currently using SNA. BackgroundAccording to IBM, SNA is one of several interchangeable transport options that include TCP/IP. And while both protocols address the same basic problem of 'How to transmit data from point A to point B for processing or display' they were developed from different backgrounds and with different design goals in mind. Thus, they maintain very different architectures, along with their own strengths and weaknesses. Subarea SNA (Traditional SNA)As mentioned before, SNA was developed in the 1970's to address the business needs of enterprises. As the needs of these enterprises were addressed, the standard that emerged depended on large, powerful processing computers. This initial version, now dubbed "subarea SNA", is hierarchical: All of the data in the network is processed and stored in a central mainframe computer, which acts as the hub of the network in conjunction with VTAM and a data link layer called Synchronous Data Link Control (SDLC). Furthermore, one entity keeps track of all system changes by way of a central Configuration Management process. Special machines called communication controllers running a program called Network Control Program (NCP) direct network traffic and route data to and from the mainframe. (For example, Bank One would use one communication controller to manage all of the traffic for all of the bank branches in Anytown, USA. They would use another communication controller to manage all of the traffic for Anothertown, USA.) Each NCP is considered to be a network node and manages a subarea, which is a connected group of PCs, terminals, and workstations. Subarea SNA is session oriented, where each terminal either is or is not in session with an application (contrasted with TCP/IP which is point-to-point and sessions are considered open all of the time). An application program interface running on the mainframe called Virtual Telecommunications Access Method (VTAM) controls the network by keeping track of messages between all of the NCPs and selecting the communication routes for the thousands of different sessions. While subarea SNA's centralized architecture offers excellent network control, it is not dynamic by nature and every resource must be coded. The desire of many IBM customers to implement more dynamic functions greatly spurred the development and usage of APPN, although more recent versions of SNA/VTAM provide some dynamic configuration. APPN (New SNA)In the 1980's and 1990's, IBM began full-force development of Advanced Peer-to-Peer Networking (APPN) as the next generation of SNA. APPN addresses the deficiencies of traditional SNA and allows enterprises to capitalize on the benefits of peer-based networking entities like routers and AS/400s, which do not rely on VTAM or mainframes as the network hub. Instead, communications are dispersed amongst various machines, such as AS/400s, creating various connected, but independently operating local networks. Along with peer-based communications, APPN supports directory services and routing between two or more Advanced Program to Program Communication (APPC) systems that are not directly attached. These attributes provide SNA with easier configuration, automatic route selection, and the ability to move servers around the network without reconfiguring clients [IBM]. Dynamic node capabilities and other technologies help SNA/APPN to implement any type of network topology, including meshed, hub, and/or hierarchal. Working within APPN, High Performance Routing (HPR) provides enterprise-class networking, supports e-business, and delivers cost-effective networking solutions. HPR adds end-to-end nondisruptive rerouting and rate-based congestion control (via ARB). If a link or node along the session path fails, HPR rapidly and automatically reroutes session without interruption. It proactively anticipates network problems in order to prevent congestion, the main cause of delay and packet loss. Selective transmission lets HPR drive fast links near capacity. In contrast, TCP/IP DLSw and LAN 802.2 LLC Type 2 (remote source route bridging) performance degrades at high speeds because of their frequent responses. Adaptive Rate Based (ARB) congestion avoidance keeps HPR networks from succumbing to congestion, unlike IP-based routers. [IBM] Subarea SNA and APPN actually have very little in common, other than their ability to support APPC and exchange data. APPC, an open communications protocol often called LU 6.2, is software that enables high-speed communications between programs in different computers, from portables and workstations to midrange and mainframe computers. APPN and APPC help provide continued support and connectivity to subarea SNA configurations and software, increasing the capacity and interoperability of existing networks. TCP/IPIn the 1950's, the Department of Defense (DoD) began plans to create a network of networks in order to prevent an enemy attack from wiping out their current single computer system in one fell swoop. In the late 1960's and early 1970's in conjunction with Advanced Research Projects Agency (ARPA) and UCLA, the DoD went to work to build a packet-switching network. The goal was to build a network, where if one point of transmission failed, the data would simply route along a different path. In the process, they developed TCP/IP (Transmission Control Protocol/Internet Protocol), which transmits data by dividing a message sent from one computer to another into data units or packets, each labeled with its destination address. Each packet would travel different routes across the network but end up at the same destination. The packets would then be reassembled at the final destination. [Winter 1999 HyperNews Forum] TCP/IP is a two-layer protocol: The IP layer delivers data messages in individual packets, which are divided, numbered, dispersed and routed for maximum efficiency, so that each packet may take a different route through the network. Each packet contains an address that identifies the destination of the data. The TCP layer tracks and reassembles the packets when they reach their destination. Error checking is minimal. Because of its connectability and relatively low, up-front costs, TCP/IP has gained great popularity as the premier Internet protocol. Main DifferencesTCP/IP is mainly point-to-point, where each communication is from one point in the network to another point. TCP/IP and the higher-level applications that use it are often called "stateless" because each client request is considered a new request unrelated to any previous one. Being stateless frees network paths for continual usage by everyone. SNA, on the other hand, is session oriented: it requires that a session be established before a client and server can exchange information. In SNA, every measure is taken beforehand to ensure that errors do not occur. Control blocks (either in the NCP or the APPN nodes) carefully track every move in an SNA network, so if an error occurs, it is immediately noted, logged, and can be searched and analyzed by network management staff. Current UsageSNA and TCP/IP are the world's most popular networking protocols. However, over the last ten years, reports have continually stated that SNA will die out within the next three to five years. Contrary to this belief, while SNA networks have not been growing rapidly, they have not been declining either. Rather, the current trends indicate that many enterprises are looking for ways to get the two protocols to "work together". TCP/IP, on the other hand, has gained rapid popularity over the last decade due to its status as the premier Internet protocol, as well as a communications protocol for private networks (intranets or extranets). With IBM announcing plans to support TCP/IP end-to-end and push S/390 as a web server platform - it seems inevitable that it will become THE premier network protocol. However, what's spoken of on paper, and what organizations are actually implementing are often two different things. The use of products that incorporate both TCP/IP and SNA, for example, has grown rapidly over the last few years. SNA vs. TCP/IPPresently, IBM and other third-party vendors are developing and providing ways to make SNA compatible with multi-enterprise network computing and open network architectures like TCP/IP. However, the choice of protocols (or tools) should be dependent upon the requirements of the business task that is being addressed. Vendors, of course, tend to promote the solutions that they have and denigrate the solutions of their competitors (when in most cases they may need both). For example, IBM reacting to the conditions of the market place has co-opted much of the technology (e.g. Unix, TCP/IP, etc.) of the Open Systems/Internet arena. They have done this to promote the idea that mainframes may be superior platforms for use as Servers (they have not yet or may never win this battle. Choices of hardware/software tend to be religious decisions based upon one's biases, training and background) Pros of supporting TCP/IP include the following:
And yet SNA continues to hold on - and rather strongly, we might add - with most statistics showing that while SNA networks may not be growing very much, they are not shrinking by any means either. Why? For one, SNA provides services and qualities that are integral to business communications and transactions where downtime, security breaches, and lost data are simply NOT acceptable - think banks and stock markets. These enterprises rely on SNA, which provides an incredible track record in reliability, security, availability, tenability, scalability, extensibility, guaranteed Quality of Service (QoS) and manageability. TCP/IP by nature does not make any guarantees of delivery and lacks in CoS and congestion control as well. Other reasons for SNA's continued support are equally viable [Vedacom]:
Moving Toward Multi-protocol TeamworkAlthough TCP/IP and SNA offer different benefits, the right tools can make them complimentary counterparts to an overall networking strategy - a little bit like the infield/outfield relationship of a baseball team. However, even with the two protocols covering their respective bases and field space, many enterprises would like a team - the ability to share and exchange data between the two protocols: enter the myriad of product offerings, theories, and plans to make that teamwork possible. BCI Access magazine points out that "Most enterprises now run both TCP/IP and SNA, both within the network infrastructure, as well as into the heart of Application Program Interfaces (APIs). Their interrelations within an enterprise range from complete separation to full integration. Corporate utilization of products that integrate SNA and TCP/IP is increasing dramatically." BCI Access also notes "A significant degree of integration has taken place already. Most enterprises that have moved toward more TCP/IP in their SNA network have also decided to maintain their mainframe (S/390 server) environment. Their convergence/migration plans are being developed and implemented in stages. TN3270 is an example of using TCP/IP to SNA in the data center. Data Link Switching (DLSw) and Enterprise Extender are examples of carrying SNA over the IP backbone." Approaches to Using Both TCP/IP and SNAThe desire to support both TCP/IP and SNA has led to many solutions. The solutions that each enterprise chooses, of course, should depend on their needs, current equipment and software, and overall goals. SeparationMany networks choose to run separate SNA and TCP/IP networks, in this case, the networks may be duplicated or both networks may perform distinct functions. Coexistence and IntegrationMany enterprises attempt to capitalize on both SNA and TCP/IP by helping them work together. With coexistence, each network's workstations and applications remain transparent and unavailable to the other unless otherwise designated. Solutions for this type of networking includes sharing resources like LAN segments, wide area links, bridges, routers, switches, servers, and/or storage devices. Integration is basically the same as coexistence, with the exception that users on one network (let's say TCP/IP) can access resources of another network type (for example, SNA applications). Further, a network segment may connect users to diverse protocols - for example, a single workstation that can access users and resources on multiple networks. There are many ways and degrees of providing integration, with more integration equaling fewer redundant resources. Classical SNA-TCP/IP integration approaches employ encapsulation or conversion techniques. In encapsulation, SNA is encapsulated and sent over TCP/IP. (With connection-oriented protocols like SNA, a path is set up through the network (a session) before any data is sent. With connectionless-oriented protocols, like TCP/IP, packets progress node by node. For this reason, SNA is considered un-routable and TCP/IP is considered routable.) There are many encapsulation and conversion technologies available:
ConclusionsIn all likelihood most businesses will use and support both protocols so that they can address all of their business needs. There is increasing support for the co-existence of both SNA/VTAM and TCP/IP protocols. Moreover, migration from SNA to TCP/IP takes time-the planning at large installations can take three to five years, with another three to five years required to implement. This process includes changes at the desktop, network, host interface and application, as well as training all affected staff and, as is often needed, reengineering business processes [Vedacom]. When considering these current and past trends, we here at North Ridge Software, Inc., feel it's safe to say that SNA will still be a viable application protocol for the foreseeable future. While TCP/IP will continue to grow in capabilities and services, SNA natively provides superior mission- and business-critical capabilities. Thus SNA, like mainframes, are here to stay in spite of rumors of their demise. | ||||||||||||
| |||||||||||||
It may come as a surprise, but the title of "world's most enduring and popular network protocol" does not belong to the e-business standard TCP/IP, but to the old standby Systems Network Architecture (SNA).
