Systems Network Architecture (SNA)

Systems Network Architecture (SNA) was developed by IBM in the 1970s as a method to facilitate communication amongst various IBM products and technologies, but mainly between mainframes and terminal devices. Largely considered to be a legacy protocol, SNA is still is use on many networks today that require communications with mainframe and various AS/400 systems. SNA is more of a communications framework than a single protocol. In fact, its layered architecture formed the basis for the OSI model. The SNA and OSI protocol stacks are compared in the figure below for reference purposes only.

Comparison of the OSI and SNA reference models.

Legacy SNA is used in mainframe environments, such as those running IBM S/370 and S/390 systems. Mainframes are typically used in environments that require very high-end transaction processing such as aggregated billing systems, databases, and so forth. SNA traffic usually doesn’t require huge amounts of bandwidth, often working across links as slow as 9600 bps. SNA traffic also tends to be time critical, which often led companies to implement SNA traffic on its own dedicated parallel network in the past. On most networks today, however, SNA traffic is often prioritized using different traffic queuing techniques, many of which are described in Chapter 14. As a general rule, SNA traffic tends to be very lightweight. This is a function of the character-based traffic passed between terminals and mainframes by inquiry/response type applications.

Four main physical entities are found on a traditional SNA network. These are outlined below, and illustrated in the figure below.

Hosts. A host in an SNA environment is typically a large IBM mainframe such as an S/370. This system would be responsible for the centralized processing and storage of data.

Front-end Processors (FEP). A FEP is a communications controller that is used to manage the physical network and related communications links, including those connecting to remote sites.

Cluster Controllers. A cluster controller serves as the connection point for terminals in an SNA environment, handling input/output functions between the host and terminals.

Terminals. A terminal is an end-user device comprised of a keyboard and display screen in mainframe and minicomputer environments. Lacking processing power of its own, a terminal simply acts as an input and display facility, with commands carried out on the mainframe. While hardware terminals like the 3270 were commonplace in the past, these devices have largely been replaced by terminal emulation software that can run on a variety of operating systems.

SNA network environment with both a local and remote location.

SNA traffic can be transmitted over a variety of different Data Link layer technologies, but has traditionally been implemented using Token Ring on LANs, and Synchronous Data Link Control (SDLC) over WAN links. SDLC will be looked at in more detail shortly.
One important issue to keep in mind is that SNA traffic is not routable – this obviously presents an issue in large network environments. One way to help circumvent this issue is to implement Data Link Switching on network routers. This allows SNA traffic to be bridged across a routed network by creating TCP tunnels between routers defined as peers. The Cisco implementation of Data Link Switching is known as Data Link Switching Plus (DLSw+), and is only available as part of certain IOS feature sets.

Author: Dan DiNicolo

Dan DiNicolo is a freelance author, consultant, trainer, and the managing editor of 2000Trainers.com. He is the author of the CCNA Study Guide found on this site, as well as many books including the PC Magazine titles Windows XP Security Solutions and Windows Vista Security Solutions. Click here to contact Dan.