History
In the early 1970s,
IBM discovered that large customers were reluctant to trust unreliable communications
networks to properly automate important transactions. There was also a need
for IBM to rationalise the diverse communications protocols developed for
its many data communications products. In response to this demand, in 1975,
IBM developed Systems Network Architecture (SNA) - an architecture
designed on the premise of "anything that can go wrong will go wrong."
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 and centrally controlled
(i.e. a host-centric environment). But this traditional approach became
less useful when open system environments (e.g. PC/LAN, desktop and client/server
applications) began to appear in the 1980s. SNA lacked the flexibility demanded
by the new distributed computing systems and IBM needed to respond
to the challenges posed by the new network protocols (particularly to add
enhanced network functionality to the, then new, AS/400 platform). In 1988
IBM announced Advanced Peer-to-Peer Networking (APPN) to address these issues.
Therefore there are now two forms of SNA:
- SNA (sometimes
referred to as Classic SNA) - subareas managed by mainframes,
via a front end processor(s), where a network hierarchy is created.
- APPN
(sometimes referred to as New SNA) - based on networks
of minicomputers, where nodes can contact each other independent of a central
point.
To clarify one
common point of confusion, rather than a specific product, SNA is an architecture
and standard to which all subsequent IBM communications products have been
compliant with. So you cannot purchase SNA from IBM, only SNA-compliant devices
and software.
"Classic"
SNA
In the original
design of SNA, a network is built out of dedicated switching minicomputers
(also known as front end processors or FEPs) managed
by a central mainframe. The front end processors run a special system called
NCP (Network Control Program) via a 3725 or 3745 IBM hardware
box (if they are, indeed, running on IBM hardware, which is not mandatory).
The 3745 is the newer hardware, the latest version is a 3746 which can run
APPN. No user programs run on these machines, they simply manage the network.
Each NCP manages communications on behalf of all the terminals, workstations,
and PCs connected to it and the network under each NCP is referred to as a
subarea. In a banking network the NCP might manage all the terminals,
printers and assorted devices in branch offices in a particular city. Traffic
is routed between the NCP machines (if there is more than one in the network)
and eventually into the central mainframe. Such a network topography might
look like this -
The mainframe
itself runs an IBM software product called Virtual Telecommunications Access
Method (VTAM) or ACF/VTAM (ACF stands for Advanced Communication
Function), which controls the network from the host side. Although individual
messages will flow from one NCP to another over a telecommunications line,
VTAM maintains a table of all the machines and telecommunications lines in
the network. It selects the routes and the alternate paths that messages can
take between different NCP nodes and generally controls communications between
different NCPs (if there are multiple NCPs in the network). Therefore,
users cannot communicate to each other without their data travelling through
the entire network hierarchy (including the VTAM program running on the mainframe)
to reach a user that may be physically located a few metres from them as there
is no way to route data directly between them. Taking the example of
the diagram above; if one of the users under the cluster controller (shown
on the right) wants to reach a user under the very same cluster controller
the routing would be as follows -
All the above requires
dedicated software and hardware at every step, and creates several points
of failure that may (individually) cause the user to lose contact with the
host. The downside to SNA is clearly seen when failures occur, however the
upside is that those events (good and bad) are clearly seen.
Within VTAM is
Systems Services Control Point (SSCP) which controls all the
resource managers in that sub-area (i.e. all the equipment controlled by that
NCP). This sub-area can also be called a domain; when there is only
one SSCP in a network it is called a single-domain network and when
there is more than one we have a multiple-domain network. In a multiple-domain
network a further product called SNI will handle connections from one
VTAM sub-area to another.
The components
that constitute a network are the SSCP and Logical Units (LUs) and
Physical Units (PUs). Any SSCP, LU or PU that can receive messages
is called a Network Addressable Unit (known as a NAU - although, over
the years Network Accessible Unit has also become accepted usage). Via a combination
of the LUs and Pus sessions are created with the SSCP and communications established.
Find out more about LUs and Pus here.
Confused? Don't
give up now. Read on and find out about "new" SNA (which is not
that new anymore), you may find it a bit easier to follow.
APPN
- The
New SNA
As we have said,
the hierarchical topology of the original SNA lacked the flexibility to address
varying network geographies, workgroup relationships and sizes. SNA-based
networks began to lose ground (in the early 1980s) to Local area networks
(LANs), most notably Token Ring. In response IBM introduced
Advanced Peer-to-Peer Networking (APPN) to meet peer-to-peer
network needs for the AS/400 (among other systems) in SNA networks independent
of any SSCP. APPN quickly grew in acceptance.
APPN and Classic
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 APPN and SNA are presented
as one architecture, a more accurate picture would be that it is two compatible
architectures that can exchange data.
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 recognises 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. In this way one has little
difficulty confusing "AMSTERDAM.PRINTER" from "UTRECHT.PRINTER" even though
the LUNAME "PRINTER" is found in each city.
In support of these
non-hierarchical network structures, the new capabilities themselves raised
new (but variations of the same old) problems. The problems confronting LAN
users are found in small standalone networks, and on LANs interconnected with
other networks. Foremost among these problems are addressing and routing:
how to address messages knowing only network partner names but not their hardware
addresses (i.e. the address found in the adapter card/IEEE MAC layer); how
to set up virtual circuits for connection-oriented sessions, or to send datagrams
in connectionless sessions. Two capabilities solved these problems, NetBIOS
and Advanced Program-to-Program Communications (APPC). Software
developers of applications accessed these capabilities via defined Applications
Programming Interfaces (APIs) provided by IBM.
Below you can find
a quick summary of NetBIOS and APPC, as well as Low Entry Networking (which
is another element of APPN).
NetBIOS
NetBIOS was introduced
by IBM in 1984 for use with LANs. It was originally implemented on the PC
Network, an early IBM Ethernet LAN. Initially the NetBIOS functions were implemented
in Read-Only-Memory on adapter cards that connected the workstations (PCs)
to the LAN bus or cable. Later, when IBM introduced Token Ring, NetBIOS functions
were implemented in software (i.e. in the workstation software). Today's equivalent
functionality is included in the OS/2 Extended Edition Communications Manager.
As can be seen by the following table, NetBIOS provides OSI Layer 5 session-oriented
services for DOS, UNIX or OS/2.
| DOS |
UNIX |
OS/2 |
DOS |
UNIX |
OS/2 |
DOS |
UNIX |
OS/2 |
| NetBIOS |
NetBIOS |
NetBIOS |
| OSI |
TCP/IP |
Proprietary |
| 802.3 |
802.4 |
802.5 |
802.3 |
802.4 |
802.5 |
802.3 |
802.4 |
802.5 |
NetBIOS supports three services: Name, Session and Datagram
-
Name Services
- here users assign convenient names to different entities (which would be
seen as LUs under the old SNA) within an individual station. Each hardware
network adapter responds to a unique hardware address, the six byte IEEE-assigned
address. The latter is a Media Access Control (MAC) address. NetBIOS's Name
Service equates a convenient user nominated name to this hardware address
and each station maintains a table of registered names (including directories
and sub-directories). Name Services gives the user a set of commands whereby
he can add (checking first for duplicate names), delete and lookup names.
When determining locations of specified names the returned information includes
MAC addresses and routing info.
Session Services
- this is concerned with establishing a reliable data interchange via sessions
between two nodes. This allows an application to conduct a reliable, sequenced
exchange of messages with another application.
Datagram Services
- this allows an application to exchange datagrams with a specific application
or to broadcast datagrams to a group and receive datagrams from the group.
Datagrams allow applications to communicate without establishing a session.
When a NetBIOS application wants to send information that does not require
acknowledgement from the destination application, the application can transmit
a NetBIOS datagram.
LU6.2
or APPC/LU6.2
Different types
of SNA Logical Units are listed in the LU table here.
The most significant of these is LU6.2 as this type figures prominently in
program-to-program sessions. Advanced Program-to-Program Communication
is the formal name for LU6.2 (or APPC or APPC/LU6.2). As an
Application Program Interface (API) it is platform independent, running on
everything from PS/2 PCs to big mainframe computers. Like NetBIOS, APPC/LU6.2
provides name services and establishes sessions linking two applications.
Among the remaining
LUs in the table, LU2 is used for host communication sessions with workstations
such as 3270s. LU 3 is defined for host sessions driving line printers.
Low
Entry Networking
Since the early
1980s IBM has offered a capability enabling two nodes to communicate with
each other as peers. Low Entry Networking (LEN) nodes are Type
2.1 nodes that do not need the services of an SSCP. LEN is an element of APPN.
The RISC System/6000 (RS/6k) is an example of a product that implements LEN
functionality. Many non-IBM vendors manufacture equipment that emulates PU
2.1 (DEC, Apple, HP and Sun, among others).
Comparing SNA
to OSI
The OSI (Open Standards
Interconnect) Reference Model provides the foundation for IP-based protocols.
While parallels may be drawn between the architecture of SNA and that of OSI's
Reference Model, the OSI goal was for interconnectivity (connecting
products and systems from different vendors) between networks Whenever the
IBM designers went right, the TCP/IP designers went left. But the result was,
instead of the two network protocols being incompatible, they turn out to
be highly complimentary. Having said that, there is a strong similarity between
the OSI model and SNA - particularly in the "layering" of their structures.
In this way SNA can be seen as having influenced the OSI model. An example
of this influence can be seen at the Data Link Layer. In the design of the
of it's own High Level Data Link Control (HDLC), OSI inherited
and adopted in large measure the features of IBM's Synchronous Data Link
Control (SDLC). This table summarises the SNA architecture in layer
form -
|
Number
|
Application
Layer
|
Description
|
|
7
|
Transaction
|
Network
access for applications: Document Interchange Architecture; SNADS
"asynchronous distribution service."
|
|
6
|
Presentation
|
Data
formats; co-ordination of resource sharing.
|
|
5
|
Data
Flow Control
|
Synchronisation
of data flow; checkpoint restart; chaining of group data into long
messages.
|
|
4
|
Transmission
Control
|
Message
pacing & sequencing; encryption.
|
|
3
|
Path
Control
|
Routing
& network traffic control.
|
|
2
|
Data
Link Control
|
Node-to-node
integrity; SDLC.
|
|
1
|
Physical
|
Electrical
& mechanical; e.g. modems and DSUs.
|
Fig.
1 SNA "Layered"
An IP network
routes individual packets of data. The network delivers each packet based
on an address number that identifies the destination machine. The network
has no view of a "session". When we browse a web page the document routes
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 contrast, 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 Defence, the boys who
built the "original internet" called DARPAnet) 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 re-routes
subsequent messages through a different path. TCP/IP is designed to
be casual about errors and to simply discard undeliverable messages. 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.
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
(i.e. the source code). It is built into the AS/400 and other important products
such as Communications Manager for OS/2, SNA Services for AIX and SNA Server
for Windows NT.
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.
The clear contrast
between the two types of network means that the user requirements usually
dictate which network is employed.
Sending SNA
over TCP/IP
SNA traffic can
run over frame relay - RFC 1490 defines the way FRADs (frame relay access
devices) and routers can send SNA datagrams in between frame relay headers.
The only problem with all these developments is that, sometimes, you can end
up with the worst of both worlds, i.e. the SNA problems of non-routability
(lose the SNA bits and there is no dynamic re-routing), while IP addressing
may just decide that your clients cash-point transaction request was just
too much bother to complete. In April 1998, IBM renamed VTAM to SNA Services
(which now runs via an eNetwork Communications Server).
