SNA-Systems Network Architecture

2 Feb 1995

Summary: In the early 1970s, IBM discovered that large customers were reluctant to trust unreliable communications networks to properly automate important transactions. In response, IBM developed Systems Network Architecture (SNA). "Anything that can go wrong will go wrong," and SNA may be unique in trying to identify literally everything that could possibly go wrong in order to specify the proper response. Certain types of expected errors (such as a phone line or modem failure) are handled automatically. Other errors (software problems, configuration tables, etc.) are isolated, logged, and reported to the central technical staff for analysis and response. This SNA design worked well as long as communications equipment was formally installed by a professional staff. It became less useful in environments when any PC simply plugs in and joins the LAN. Two forms of SNA developed: Subareas (SNA Classic) managed by mainframes, and APPN (New SNA) based on networks of minicomputers.

In the original design of SNA, a network is built out of expensive, dedicated switching minicomputers managed by a central mainframe. The dedicated minicomputers run a special system called NCP. No user programs run on these machines. Each NCP manages communications on behalf of all the terminals, workstations, and PCs connected to it. In a banking network, the NCP might manage all the terminals and machines in branch offices in a particular metropolitan area. Traffic is routed between the NCP machines and eventually into the central mainframe.

The mainframe runs an IBM product called VTAM, which controls the network. Although individual messages will flow from one NCP to another over a phone line, VTAM maintains a table of all the machines and phone links in the network. It selects the routes and the alternate paths that messages can take between different NCP nodes.

A subarea is the collection of terminals, workstations, and phone lines managed by an NCP. Generally, the NCP is responsible for managing ordinary traffic flow within the subarea, and VTAM manages the connections and links between subareas. Any subarea network must have a mainframe.

The rapid growth in minicomputers, workstations, and personal computers forced IBM to develop a second kind of SNA. Customers were building networks using AS/400 minicomputers that had no mainframe or VTAM to provide control. The new SNA is called APPN (Advanced Peer to Peer Networking). APPN and subarea SNA have entirely different strategies for routing and network management. Their only common characteristic is support for applications or devices using the APPC (LU 6.2) protocol. Although IBM continues the fiction that SNA is one architecture, a more accurate picture holds that it is two compatible architectures that can exchange data.

It is difficult to understand something unless you have an alternative with which to compare it. Anyone reading this document has found it from the PC Lube and Tune server on the Internet. This suggests the obvious comparison: SNA is not TCP/IP. This applies at every level in the design of the two network architectures. Whenever the IBM designers went right, the TCP/IP designers went left. As a result, instead of the two network protocols being incompatible, they turn out to be complimentary. An organization running both SNA and TCP/IP can probably solve any type of communications problem.

An IP network routes individual packets of data. The network delivers each packed based on an address number that identifies the destination machine. The network has no view of a "session". When PC Lube and Tune sends this document through the network to your computer, different pieces can end up routed through different cities. TCP is responsible for reassembling the pieces after they have been received.

In the SNA network, a client and server cannot exchange messages unless they first establish a session. In a Subarea network, the VTAM program on the mainframe gets involved in creating every session. Furthermore, there are control blocks describing the session in the NCP to which the client talks and the NCP to which the server talks. Intermediate NCPs have no control blocks for the session. In APPN SNA, there are control blocks for the session in all of the intermediate nodes through which the message passes.

Every design has advantages and limitations. The IP design (without fixed sessions) works well in experimental networks built out of spare parts and lab computers. It also works well for its sponsor (the Department of Defense) when network components are being blown up by enemy fire. In exchange, errors in the IP network often go unreported and uncorrected, because the intermediate equipment reroutes subsequent messages through a different path. The SNA design works well to build reliable commercial networks out of dedicated, centrally managed devices. SNA, however, requires a technically trained central staff ready and able to respond to problems as they are reported by the network equipment.

The mainframe-managed subarea network was originally designed so that every terminal, printer, or application program was configured by name on the mainframe before it could use the network. This worked when 3270 terminals were installed by professional staff and were cabled back to centrally managed control units. Today, when ordinary users buy a PC and connect through a LAN, this central configuration has become unwieldy. One solution is to create a "pool" of dummy device names managed by a gateway computer. PC's then power up and borrow an unused name from the pool. Recent releases allow VTAM to define a "prototype" PC and dynamically add new names to the configuration when devices matching the prototype appear on the network.

A more formal solution, however, is provided by the APPN architecture designed originally for minicomputers. APPN has two kinds of nodes. An End Node (EN) contains client and server programs. Data flows in or out of an End Node, but does not go through it. A Network Node (NN) also contains clients and servers, but it also provides routing and network management. When an End Node starts up, it connects to one Network Node that will provide its access to the rest of the network. It transmits to that NN a list of the LUNAMEs that the End Node contains. The NN ends up with a table of its own LUNAMEs and those of all the EN's that it manages.

When an EN client wants to connect to a server somewhere in the network, its sends a BIND message with the LUNAME of the server to the NN. The NN checks its own table, and if the name is not matched broadcasts a query that ultimately passes through every NN in the network. When some NN recognizes the LUNAME, it sends back a response that establishes both a session and a route through the NN's between the client and the server program.

Most of APPN is the set of queries and replies that manage names, routes, and sessions. Like the rest of SNA, it is a fairly complicated and exhaustively documented body of code.

Obviously workstations cannot maintain a dynamic table that spans massive networks or long distances. The solution to this problem is to break the APPN network into smaller local units each with a Network ID (NETID). In common use, a NETID identifies a cluster of workstations that are close to each other (in a building, on a campus, or in the same city). The dynamic exchange of LUNAMEs does not occur between clusters with different NETIDs. Instead, traffic to a remote network is routed based on the NETID, and traffic within the local cluster is routed based on the LUNAME. The combination of NETID and LUNAME uniquely identifies any server in the system, but the same LUNAME may appear in different NETID groups associated with different local machines. After all, one has little difficulty confusing "CHICAGO.PRINTER" from "NEWYORK.PRINTER" even though the LUNAME "PRINTER" is found in each city.

TCP/IP is a rather simple protocol. The source code for programs is widely available. SNA is astonishing complex, and only IBM has the complete set of programs. It is built into the AS/400. Other important workstation products include:

• NS/DOS for DOS and Windows
• Communications Manager for OS/2
• SNA Services for AIX
• SNA Server for Windows NT [from Microsoft]

The native programming interface for modern SNA networks is the Common Programming Interface for Communications (CPIC). This provides a common set of subroutines, services, and return codes for programs written in COBOL, C, or REXX. It is documented in the IBM paper publication SC26-4399, but it is also widely available in softcopy on CD-ROM.

Under the IBM Communications Blueprint, SNA becomes one of several interchangeable "transport" options. It is a peer of TCP/IP. The Blueprint is being rolled out in products carrying the "Anynet" title. This allows CPIC programs to run over TCP/IP, or programs written to use the Unix "socket" interface can run over SNA networks. Choice of network then depends more on management characteristics.

The traditional SNA network has been installed and managed by a central technical staff in a large corporation. If the network goes down, a company like Aetna Insurance is temporarily out of business. TCP/IP is designed to be casual about errors and to simply discard undeliverable messages.

The Internet is formed of a few dozen central service providers and 10,000 connected private networks. Things change all the time. It is not rational to try to centrally control every change or immediately respond to every problem. It would not be possible to build the Internet at all using SNA, but IP delivers fairly good service most of the time.

Additional PCLT topics include:

• XID (Defining Nodes and Connections)
• NETID (Organizing Large Peer Networks)
• PU 2.1
• Link Stations, SDLC, IEEE 802.2
• Modename, Session Limits, Class of Service
• ILLogical Units
• Introduction to APPC

Additional information is available in self-study courses from SRA (1-800-SRA-1277)

• SNA Features and Architecture [34604]

Copyright 1995 PCLT -- Introduction to SNA -- H. Gilbert