SNA and LU6.2 Connectivity

When IBM introduced Systems Network Architecture (SNA), its strategic wide area networking product family, in 1974, mainframes dominated computer environments. Because they were ruled by mainframes, the computer networks in use were hierarchical, or tree-structured, with the mainframe at the top of the inverted tree. This arrangement required lower-level systems on the network to communicate with each other through the mainframe rather than directly with each other, which was a tremendous waste of host-based resources.

The popularity of personal computers in the 1980s changed the structure of corporate computing, however. No longer were computing resources located in or controlled from a centralized location; they were now distributed throughout an organization, in dozens (even hundreds) of PCs as well as the mainframe.

The growth of PC-based networks further strengthened this distributed environment. With hundreds of PCs connected to networksall needing to communicate with each otherit became intolerable for most organizations to rely solely on the traditional SNA-type network. No longer could they allocate host resources to managing communication among the dozens of computers on the network.

In 1982, IBM responded by adding a protocol called Logical Unit (LU) 6.2 to SNA. LU6.2 makes all computers peers on an SNA network, including hosts . With LU6.2, the mainframe no longer plays dictator to its "slave" counterparts on the network. LU6.2 brought other changes to SNA as well. Rather than forcing devices connected to SNA to act as dumb terminals incapable of handling processing, LU6.2 permits cooperative processing. Each processor on the network can do what it does best rather than rely on the mainframe. It also allows the dynamic allocation and tuning of SNA networks, substantially reducing the need for operator intervention.

SNA's Structure

SNA, with IBM's market presence behind it, has been a de facto data processing and networking standard for many years . IBM has developed and installed sufficient hardware and software to make SNA the world's most widely installed network topology, with more than 22,000 sites.

As a protocol suite, SNA offers functionality similar (and is an alternative) to the Transmission Control Protocol/Internet Protocol (TCP/IP) and Open Systems Interconnection (OSI) protocols. Like these protocols, SNA offers a layered approach to communications. From the top down, SNA's seven layers are: end- user , network-addressable unit services, data flow control, transmission flow control, path control, data link control, and physical layers. Together, they provide services that are more or less synonymous with those of OSI and TCP/IP. However, the layers' functions do not completely correspond from one protocol to another.

These layers handle the following tasks . The physical layer (layer 1) moves data between computers on a network. The data-link layer (layer 2) uses the Synchronous Data Link Control (SDLC) protocol to pass data across the physical interface. The path control layer (layer 3) manages routing and traffic control, packing data together to increase throughput. The transmission control layer (layer 4) initiates, manages , and concludes transport connections or sessions, controlling the data-flow rate between layers 3 and 5. The data-flow control layer (layer 5) determines which LU can transmit next and helps manage error recovery. The NAU services layer (layer 6) handles presentation services to layer 7. The end-user layer (layer 7) provides the user interface.

In practice, SNA and LU6.2 use only layers 4 through 6. In this tutorial, we'll describe the functions and features these layers provide.

Definitions Of Physical And Logical Units
Physical Units	Logical Units
No.	What it defines	No.	What it defines
PU1	Terminals	LU0	Application presentation services
PU2	Controllers	LU1	3287 emulation, network & remote job
PU2.1	Enhances	LU2.0	Entry
PU3	Not defined	LU2 3278/9	Terminal emulation
PU4	Front-end processors	LU3	3270 Printer connections
PU5	Mainframe hosts	LU6.2	Peer-to-peer communication

LU, PU Functions

Before continuing, let's define logical unit, and its hardware-specific counterpart , the physical unit. Logical units (or LUs) and physical units (PUs) are the two primary functional entities in an SNA network. Both LUs and PUs are also referred to as network-addressable units (NAUs). (For a breakdown on LUs and PUs, see "Definitions of Physical and Logical Units.")

In SNA parlance, PUs are physical systems or nodes connected to each other via cabling. PUs are also known as Node Types, or NTs. IBM has defined five node types, including hosts (PU5) and terminals (PU2), and left a sixth available for future definition. For the sake of simplicity, we'll refer to node types/physical units only with the PU designationsuch as PU2.0although it's just as accurate to label PU2.0 as NT2.0.

Logical units are electronic entities connected by sessions. Just as there are five PUs, there are five LUs, including LU6.2, that make SNA network resources, including disk files and processing cycles, available for application software. A node on an SNA network can be a physical unit (such as hardware) as well as a logical unit (such as a logical session connection).

In essence, LU6.2 acts as an interface, or protocol boundary, between SNA and an end user's application. Closely associated with LU6.2 is PU (or node type) 2.1, which is an enhancement to PU2.0 for cluster controllers. PU2.0, also known as 3270 terminal emulation, is the protocol most often used to connect personal computers into an SNA network. PU2.0 also lets other devices on an SNA network access a mainframe by emulating a cluster controller.

PU2.0 has some limitations, however. Most importantly, it allows devices to access only a host, not other peer nodes. And it requires one or more System Service Control Points (SSCP), which start and stop sessions. PU2.1 remedies these shortcomings.

PU2.1 includes all the features of PU2.0, with major upgrades. It allows SNA devices to connect to peer nodes without mainframe assistance, and it permits running multiple sessions simultaneously . And while PU2.0 permits only peripheral node connections, PU2.1 provides peer-to-peer connectivity. PU2.1 also requires no central control point to manage session services.

LU And PU Types

There are five LUs and an identical number of PUs. We've described one of each already. The table provides a brief description of the full set of physical and logical units.

Of the logical and physical units listed in the table, LU3 is outdated . LU6.2, which can be considered a subset of SNA, consists of a base set of features plus 41 options. IBM implements LU6.2 across its entire product line, although the specifics vary from product to product. In its most popular form, users know LU6.2 as Advanced Program-to-Program Communication (APPC).

Users purchase APPC in the form of a developer's toolkit, which allows them to create transaction programs capable of using entities called APPC verbs. These APPC verbs are used within the transaction program to get LU6.2/APPC to perform functions the program needs carried out. Although APPC and LU6.2 are synonymous, their verb names differ slightly. With a few exceptionsfor example, APPC/PC does not support some of the more obscure features of LU6.2APPC functionality is virtually identical to that of LU6.2.

LU6.2/APPC functions primarily as a resource allocator and controller. This means that LU6.2/APPC ensures that programs have access to network resources when they need them, and that network resources are not corrupted, such as when two users attempt to make simultaneous updates to the same file.

IBM has made APPC its preferred LU6.2 implementation in a variety of its systems, including its PCs, System/38/36, AS/400, and 9370 mainframe. IBM has said that APPC is its strategic product for distributed processing in the minicomputer and PC environments. IBM sees APPC as one way of taking PC-to-mainframe market share away from terminal emulation applications.

On The PC Side

APPC/PC is IBM's offering at the low end of the LU6.2 market. Two versions are available. Version 1.1 is designed for IBM's Token Ring and PC LAN Program networks and standalone micros. The OS/2 Extended Edition APPC is part of the Communications Manager for OS/2.

While backed by IBM, the memory-resident APPC/PC program has met resistance from end users. It consumes 164 KB of RAM, which is too much for most PC users to spare. With only 640 KB of DOS-addressable memory, many users don't have enough RAM to run DOS, APPC/PC, and applications software on a network. This is not an issue for end users running OS/2, which can access up to 16MB of memory; however, only a small percentage of users in the PC environment are using OS/2.

Because of the memory limitation, third-party applications developers have been slow to release software that takes advantage of APPC/PC. If more users migrate to OS/2, developers are likely to release more applications written to APPC/PC.

Another of IBM's LU6.2 implementations is Advanced Peer-to-Peer Networking (APPN). APPN adds network management capabilities to LU6.2 peer-to-peer communications services. APPN also includes a routing capability that can create new routes between nodes on a network dynamically.

This tutorial, number 31, by Jim Carr, was originally published in the February 1991 issue of LAN Magazine/Network Magazine.