This paper was originally presented at the Fifth International Conference on Computer Communication, Atlanta 1980. It was published in the proceedings pp. 578-585.

SNA'S First Six Years: 1974-1980

R.J. Sundstrom and G.D. Schultz


In the six years following its announcement, IBM's Systems Network Architecture (SNA) has evolved in stages, corresponding to successive releases of groups of SNA product implementations. This paper traces the evolution of SNA as an architecture and as the set of products that. release by release, have incorporated significant functional enhancements to the architecture. Techniques for formally describing and validating the architecture and for controlling its orderly implementation and extension are also described.


The announcement in September 1974 of Systems Network Architecture (SNA) ushered in a new era within IBM by establishing an evolving framework to efficiently control distributed data processing among diverse processors and terminals within networks. In the six years following its announcement, a maturing SNA has been successively enhanced in numerous ways:

In this paper, we trace the evolution of SNA along these lines, and the successive SNA product-set releases that have implemented specific advances.


Sussenguth [9] has discussed the origin of SNA as a uniform strategy in response to technological advances that could not be dealt with in the piecemeal and divergent fashion characterizing previous teleprocessing support. Proliferation of access methods, data link controls, incompatible terminals had been commonplace prior to SNA.

The advent of large-scale integration (LSI) design manufacturing techniques, as well as improved offerings by the communications industry, meant that distribution of processing capabilities in diverse products within works would be greatly enhanced. With this would come the need to support distributed, higher-level processing functions and to coordinate much more complex network configurations.

SNA is an architecture that defines the message formats and interaction protocols among a large family of compatible products. By defining a comprehensive set of structured protocols, from low-level data link control to high-level, user-oriented data-presentation services, SNA has controlled the proliferation of private protocols that would, if unchecked, lead to reduced interconnection capability among IBM products.

The family of SNA products has evolved in an orderly fashion. Beginning with fundamental services and a basic structure, SNA has steadily incorporated additional requirements of user-application networks and included advances shaped by experience from past offerings.


In this section, we describe the various levels of control defined in SNA, and the general architectural abstractions to different products. In the next section, we discuss the release-to-release increase of configurational and functional capability within the structure described here.

Figure 1 shows the general configuration model of an SNA network. This model shows how product nodes can be interconnected by links, and illustrates various hierarchical control structures that are defined.

End users--terminal operators, application programs, and various device media--are represented within nodes by logical units (LUs). These are ports through which users can access services of the network and can be interconnected by sessions to other users. System services control points (SSCPs) offer directory services for establishing LU-LU sessions, as well as other network services, such as for configuration management. Physical units (PUs) are subordinate, local representatives of the SSCPs within nodes; they provide control of node resources, in response to commands from one or more SSCPs. Each node has a PU.

An SNA network can consist of one or more domains, according to customer-installation options. A domain comprises an SSCP and the PUs, LUs, and other node resources (such as links) that the SSCP can directly control. Multiple SSCPs can concurrently share control of some resources (such as some PUs and links) and can sequentially share others (LUs); hence, domains can overlap. This is useful to allow back-up and some SSCP-specialization, or partitioning of function, e.g., for statistics gathering for problem determination.

Directory services are performed on a domain basis. An end user requesting an active session with another end user designates that end user by an LU name. This is resolved by an SSCP to a network address within a domain, or with the aid of other SSCPs across domains.

Network addresses are used for routing within the network, and have a subarea and an element component. Within certain nodes, such as cluster controllers and terminals, only short-form addresses local to the node are used. These nodes are known as peripheral nodes, because they do not participate in intermediate routing, but are strictly sources and sinks for message traffic. Subarea nodes provide general routing based on network addresses, and can be sources and sinks as well.

The network is divided into subareas, each subarea consisting of a subarea node and any peripheral nodes attached to it. Changes to the network address space are coordinated only among subarea nodes. Peripheral nodes are unaffected by reconfiguration of network subareas; they are shielded by address-transformation services within their adjacent subarea node. (Such services in subarea nodes are referred to as boundary function support for peripheral nodes.)

A general design principle of SNA is to limit dependence on the physical configuration as much as possible. This principle is manifested, for example, by the provision of translation services at the network periphery: end users identify components or services by name; peripheral nodes are unaware of the global network address space and of intermediate routing services. In each case, translation services provide transparent mapping between identifiers, used locally by end users or peripheral nodes, and globally unique ones, used within the network.

Functions within SNA nodes are organised into layers, as illustrated in Figure 2 for LU-LU sessions. (SSCPs and PUs have a similar structure.) Session services in the LU services manager coordinate log-on, or LU-LU session-initiation, requests from the end user, with the help of the SSCP in the domain. Presentation services provide data-stream mapping services, as well as data compression and compaction, and device selection. Data flow control provides send/receive concurrency control, message sequence numbering, request/response correlation, logical chaining of related user data, and multiplexing of the session into finer interaction units called brackets--typically used for serial transactions, such as data-base updating. Transmission control supports session-level traffic pacing, message-size control, and enciphering and deciphering of user data. Presentation services, data flow control, and transmission control are grouped into half-sessions, which are sensitive to interactions between specific end-user pairs. Path control performs network routing and flow control, based on packet switching, priority classes, and adaptive congestion-control mechanisms. Data link control schedules and controls traffic between adjacent nodes. Path control and data link control components throughout the network comprise the path control network.

Various options are selectable at session-activation time. These are defined in terms of specific subsets of option selections, called LU-LU session types [6]. LU-LU session types 1, 2, 3, 4, and 6 are defined, which constrain the data-stream, function-management header, and other session protocols (data flow control and transmission control profiles [7]) that may be used between two end users. A class of service that determines the transmission priority and route selection within the path control network may also be selected on a session basis.

The following section describes the SNA product-set releases as they progressed to this general structure, and defines the functional enhancements of each release.


Figures 3 and 4 provide a summary of the IBM products and configurations supported in successive SNA releases. SNA releases correspond to major releases of Virtual Telecommunications Access Method (VTAM). For example. ACF/VTAM Release 1 provides support for SNA 3; Release 2, for SNA 4.1 and Release 3, for SNA 4.2. Other products are listed in the release that was current at the time they became available. The remainder of this section provides more detail on the functions introduced with each SNA release by nondisruptive extensions to the base architecture.

2.1 SNA 0

The original set of functions supported single-host networks, and was shipped in a series of three releases that were referred to as SNA 0, SNA 1, and SNA 2. The first release SNA 0, was already available at the time of the original announcement in September 1974; SNA 1 was available in March 1975, and SNA 2 was available in September of that year.

The first release of SNA consisted of a telecommunications access method, VTAM, the network control program (NCP) in the 3704 or 3705 Communications Controller, and the 3600 Finance Communication System-consisting of a programmable controller, the 3601, and a variety of terminal devices. The basic function provided was communication from application programs in System/370 processors to application programs in the 3601 cluster controller. The 3600 was the first in a series of systems designed specifically for particular industries. Later industry systems included the 3650 for retail stores, the 3660 for supermarkets, and the 3630 for manufacturing plants.

All the base SNA components were provided in this first release: VTAM and NCP implemented subarea nodes--VTAM with an SSCP and LUs, and NCP with a boundary function; the 3601 implemented a peripheral node. Each node contained a PU, and path control and data link control components. The NCP communicated with VTAM via the System/370 channel, and with the 3601 via the first implementation of Synchronous Data Link Control (SDLC). This release also provided migration support for BSC- and channel-attached 3270 displays.

SNA networks provide a number of services to users, many of which were introduced in the first release; later releases enhanced these services and provided new ones. A primary SNA service is the sharing of network resources--for example, allowing multiple terminals on a single link to interact with multiple applications. Sharing is key to reducing network costs and providing flexible services.

Gray [2] has classified SNA services into transmission services, configuration management services, and application services. In SNA 0, many transmission services were provided through the use of SDLC, which provided performance and reliability improvements over earlier link controls. The use of a pause-and-retry error recovery algorithm in NCP also improved availability by allowing links to automatically recover from transient link problems without requiring operator intervention. Configuration management services were provided by the SSCP in VTAM, through which the network operator could activate and deactivate links and nodes, and receive notification of failures. Application services provided the connection between applications in the System/370 and those in the 3601. These application connections (sessions) were requested using LU names rather than network addresses, thus allowing the LUs to be insensitive to the network's physical configuration.

2.2 SNA 1

SNA 1 added the capability to attach remote communication controllers via SDLC links (Figure 3). Data concentration provided by remote communication controllers can reduce communication costs. The new SNA product support included TCAM and CICS, both of which used the VTAM application's program interface. TCAM provided high-level macro language and multi-threading control facilities for message processing and queuing; CICS provided a high-level process-multiplexing interface for data-base; transaction-processing applications. The advantages that SNA provides CICS are described in [10].

2.3 SNA 2

SNA 2 added the capability to attach cluster controllers via switched (dial) links, and added support for additional program products, terminals, and cluster-controllers. This included support for SDLC-attached 3270 displays, for the System/32 processor, and for the 3767 and 3770 terminals, which, unlike the 3601, contained no customer-programmable application program interface--all the application code being provided by the terminal. The 3767 and 3770 also provided the first implementations of an LU-LU session type: type 1. To the primary LU (host application), LU-LU session type 1 causes the secondary LU to appear as a generic keyboard printer that may provide alternate destinations such as diskettes, punches, and extra printers. Session type 1 uses the SNA character string (SCS) data stream; SCS consists of a set of EBCDIC control codes, such as new line, form feed, and backspace, giving the application full control over how the information (coded as EBCDIC graphic characters) is presented at the terminal.

Remote job entry support for the operating systems MVS, DOS, and VS1 was provided through the application subsystems JES2, POWER, and RES, respectively. Additional data-base/data-communication support was provided by IMS.

Attachment of SNA networks to public packet-switched networks via the CCITT recommendation X.25 interface was introduced, in a limited form, in February 1977. The released product adaptations permit certain products to use X-25-based services in Canada, the Federal Republic of Germany, France, and The Netherlands. The SNA relationship to various communication facilities is discussed in [9].

2.4 SNA 3

SNA 3 introduced multiple-host networks, a major extension of SNA. This support allowed multiple single-host tree configurations of the type supported by SNA 2 to be connected by links between System/370 channel-attached 3705s and by host-shared 3705s. With SNA 3, a terminal controlled by one host could access an application in any host in the network, and host-to-host sessions could also be established. SNA 3 was announced in November 1976, and shipped in December 1977.

The architectural extensions necessary for SNA 3 were conceptually simple: multiple SSCPs, acting in concert, control the network. Prior to SNA 3, all LUs in specific network were controlled by the same SSCP. To activate an LU-LU session, an LU sent an Initiate request to the SSCP. The SSCP resolved LU names carried on the Initiate into network addresses and sent a Control Initiate (CINIT) request to the primary LU. CINIT contains all the information necessary for the PLU to activate the LU-LU session by sending Bind Session to the secondary LU. In SNA 3, this sequence remains unchanged from the perspective of the LUs. However, LUs in separate domains are controlled by different SSCPs, so the controlling SSCPs communicate directory information and session parameters via new commands sent over SSCP-SSCP sessions, in this way, without changing the interface to the LUs, the SSCPs provide enhanced session establishment services. In a sense, the multiple SSCPs in an SNA 3 network can be viewed as a single, distributed SSCP.

To help manage the multiple-host networks provided by SNA 3, a new program product, the Network Operator Support Program (NOSP), was introduced for use with VTAM. NOSP allowed 3270 displays anywhere in the network to act as network operator consoles. From these consoles, operators could activate and deactivate nodes and links, start and stop link traces, collect tuning statistics, display status information about network resources, test links, and communicate with other network operators. With NOSP, a single operator could control the entire network, or multiple operators could share this responsibility, each controlling all or a portion of the network. Through the use of authorization facilities, each operator's span of control could be limited to a portion of the network. NOSP also permitted network operation control at program-execution speeds through the support of user-defined command lists.

LU-LU session types 2, 3, 4, and 6 were introduced in SNA 3. Session type 2 presents the appearance of a keyboard display that supports the SNA 3270 data stream, session type 3 is a (virtual) printer that accepts this data stream. The SNA 3270 data stream is oriented towards writing graphic characters and their associated attributes (e.g., intensity) into a buffer, where each character in the buffer corresponds to a character position on a display screen. It uses EBCDIC coded controls and positionally defined commands to address locations in the buffer and enter characters and attributes. Like the SCS data stream the 3270 data stream gives the application comprehensive control over the presentation of information at the terminal.

Session type 4, like type 1, presents the appearance of a keyboard printer. However, unlike type 1, type 4 was designed for terminal-to-terminal sessions, in addition to (host) application-to-terminal sessions. Session type 6 was first introduced in CICS, for CICS-to-CICS communication; it is especially suited to a transaction-processing environment. More will be said about session type 6 later.

SNA remote job entry support was extended with a network job entry application available with JES2. With this application, jobs submitted to any system with JES2 could be routed to any other system with JESS for execution [11].

Prior to the SNA 3 announcement, TCAM Direct was introduced as an independent SNA access method. TCAM Direct, having its own SSCP, PU, path control, and other SNA node components, no longer had to run on VTAM. With the introduction of multiple-system networks in SNA 3, TCAM and VTAM could communicate as peers and share control of the network.

Support for session-level cryptography was introduced in the interval between SNA 3 and SNA 4.1. A 6-byte-block chaining algorithm and an eight-byte key (changed on a session-basis in SNA) are used for enciphering, in accordance with the National Bureau of Standards' Data Encryption Standard (DES) algorithm [12-13]. Key distribution is managed by the SSCPs; session keys are distributed (enciphered under LU-owned "master" keys) using the session initiation requests discussed earlier. Prior to the integration of session-level cryptography into SNA, link-level cryptography could be used for the protection of sensitive data; this is still supported.

2.5 SNA 4.1

The focus of SNA 4.1 was on network management aids and on support of start-stop terminals. SNA 4.1 was announced in November 1978, and was initially available in June 1979.

To help operators further manage SNA networks from specific, distributed points of control, two new program products were introduced: the Network Communication Control Facility (NCCF) and the Network Problem Determination Application (NPDA). NCCF replaces NOSP on VTAM, extends operator control functions to TCAM, and provides facilities to collect, store, and retrieve network error data in support of NPDA. NPDA helps the NCCF operator (at any authorized 3270 display) to determine the cause and location of problems, by providing interactive display of error statistics associated with links, peripheral nodes, and subarea nodes, and by displaying a probable cause for each error. The error data for each node and its attached links is acquired by in the PU in the node and is sent on the SSCP-PU sessions to the controlling SSCPs, each of which then forwards the data to its associated NCCF. Ease of network operation was also simplified by the incorporation of dynamic reconfiguration, whereby a network operator can invoke SSCP-to-PU protocols to add, delete, or move peripheral nodes without disrupting the remainder of the network.

Two families of intermediate-sized processors, with accompanying SNA software, were introduced in SNA 4.1: the 4300 series with entry-level VTAM-VTAME-and the 8100 series with the operating systems, DPPX and DPCX. Both processors support directly attached SDLC links, eliminating the need for channel-attached communication controllers for small SNA networks. VTAME can also participate in networks as a peer with VTAM and TCAM. The 8100, with DPPX or DPCX, can act as a peripheral node to NCP, and as a subarea node (with an SSCP) to its attached terminals and cluster controllers. Direct 8100-to-8100 communication is also possible.

Another new program product, the Network Terminal Option (NTO), provides migration support for teletypewriters and other start-stop terminals (e.g., the 2741). NTO runs in the 3705 Communications Controller in conjunction with NCP. It converts the control protocols for the non-SNA terminals into SNA protocols, so that these terminals appear to the rest of the network as SNA peripheral nodes, and can be provided most of the same multiple-host network capabilities.

Initially, SNA allowed only one concurrently active session between a given pair of LUs; each LU had a single network address, and sessions were identified by address pairs. However, allowing multiple concurrent conversations between users can improve performance and increase flexibility by allowing many pairs of programs-for example, in two transaction processing systems--to be simultaneously and independently connected. This was achieved by the addition of parallel-session support in SNA 4.1. Parallel sessions are provided by initially assigning one network address to an LU, and later assigning additional addresses, as required, to support additional active sessions.

Intersystem communication (ISC) between CICS and IMS was announced in the fall of 1979. It provides for CICS-to-CICS, CICS-to-IMS, and IMS-to-IMS communication using LU-LU session type 6 and parallel sessions. Intersystem communication allows transaction processing to be distributed between systems by routing transaction message units to the appropriate transaction processor, based, for example, on a transaction code contained within the message unit. For CICS-to-CICS communication, distributed data bases are supported by masking the actual location of data from the using application programs. In the announcement letter for ISC, IBM's direction to support intersystem communication on DPPX-based systems was also stated.

2.6 SNA 4.2

The most recent major SNA announcement, SNA 4.2, extends the path control network capabilities of SNA by providing functions such as parallel links between adjacent subarea nodes, as well as different transmission priorities, and multiple active routes between two, not necessarily adjacent, nodes within the subarea node portion of the network. Three new modems, with unique, on-line, processor-controlled diagnostic capabilities, were also introduced. SNA 4.2 was announced in June 1979, for first shipment to customers in November 1980.

Multiple, or parallel, links between adjacent subarea nodes of a network can be used to provide additions bandwidth and increased reliability through redundancy. SNA 4.2 allows parallel links to be logically grouped, and provides a transmission group protocol, which automatically distributes traffic across the links of group. This protocol compensates for degradation resulting from errors on any of the links in transmission group; sessions using a transmission group are disrupted only if the last remaining link in the group fails. The receiving transmission group component reorders traffic that may have arrived out of order because of message units having different lengths or as a consequence of retransmissions resulting from link errors.

Network availability can also be increased by providing multiple routes between the same two points (subarea nodes) in a network, so that disrupted sessions can be reconnected and traffic rerouted to avoid failing intermediate nodes as well as failing links. Multiple routes can also be useful for traffic load-leveling. SNA 4.2 uses a form of routing called explicit routing, wherein a session, when activated, is assigned to a particular route. Explicit routing was first defined by Jueneman and Kerr [14-15]; its use in SNA 4.2 is further described in [3-5]. Explicit routing allows the user to have control over the selection of the physical path used for session traffic between subarea nodes. For example, low-delay routes can be chosen for interactive sessions and secure routes for sensitive data. Routing schemes that allow routing decisions on individual messages) based solely on congestion conditions, do not provide this level of control.

Transmission groups are used to move data between adjacent subarea nodes; explicit routes provide routing between two, not necessarily adjacent, subarea nodes. In both instances all traffic is kept in FIFO order. Transmission priorities and adaptive flow control are also provided by the SNA 4.2 path control network. These functions, which are independent of the details of the explicit node-by-node routing mechanism, use a virtual route protocol that is built on top of the explicit route protocol. End-to-end message integrity within the subarea node portion of the network is achieved by assigning a sequence number to each message unit flowing on a virtual route. (Session-level sequencing is independent, being used primarily for request-response correlation and for resynchronization after session failure.) Flow control is provided by pacing the traffic on each virtual route in both directions--more about this later.

Transmission priority is accomplished through priority enqueuing on the transmission group send-queues based on priority indicators carried in the message-unit header. The transmission priority, and the physical route to be used, together form the class of service provided for a session. Recall that the Initiate request carries the names of the LUs to be connected via a session. Another parameter of this command, the mode name, is used to specify the session parameters (e.g., the LU-LU session type to be used). In SNA 4.2, this symbolic name can also be used to specify the class of service, thus allowing the new path control network capabilities to be selected without changing the interface to the LUs.

To save costs, networks are normally designed so that the peak rate of traffic into the network may, at times, exceed the maximum network throughput. Queues in the network help smooth the peak loads, but flow-control mechanisms are necessary to prevent substantial throughput degradation, or even deadlock, as the offered load increases beyond the network's capacity [16]. Flow control operates by limiting the rate at which traffic is accepted into the network. SNA uses a flow-control mechanism based on virtual-route pacing, described in [3-5]. Geria and Kleinrock [17] discuss virtual-route pacing in the general context of network flow-control mechanisms.

Virtual-route pacing operates in each direction by allowing a specific number of message units to be sent from one end of a virtual route, after a pacing response is received from the other end. This number is dynamically adjusted by an origin node based on the collective feedback from destination and intermediate nodes, which check queue depths all along the virtual route; dynamically adjusted pacing values can provide greater throughput than statically defined values [18]. Performance analysis [19] has shown that in networks that experience high loads, explicit route selection with virtual route pacing may provide better performance than routing schemes that allow routing decisions on every message. SNA also provides a separate mechanism for pacing session-level traffic in each direction, this prevents one end of a session from sending data more quickly than the other end can receive it. Session-level pacing for traffic directed to peripheral nodes was introduced in SNA 0; session-level pacing for traffic directed to subarea nodes (i.e., two-way pacing) was introduced in SNA 3.

SNA 4.2 also improved the operational aspects of SSCP backup. When a subarea node detects the failure of a session with an owning SSCP, it informs all other SSCPs sharing control of that node. This notification is transformed into a signal to the network operators of SSCPs with resource takeover responsibilities, one of them may then assume control of the resources, such as links and terminals, that were previously controlled by the lost SSCP. This backup of control is performed without disruption of currently active end-user sessions.

There are cases in any network where disruption of session traffic cannot be avoided. In SNA this can occur when the last remaining link in a transmission group fails. When this occurs, both ends of the sessions affected by the failure are notified, thereby avoiding hanging sessions. In SNA 4.2, this notification takes place using messages that flow along the affected session path, with the result that both LUs are notified if one or more failures occur. When sessions are restarted, possibly on another route, a session resynchronization protocol may be invoked. Sessions using this protocol roll back to the most recently completed synchronization point when notified of a failure processing can then be restarted from specific well-defined points.

While SNA 4.2 consists largely of path control improvements to existing products, it also introduces a noteworthy family of products into the SNA family: the 3663, 3864, and 3665 microprocessor-based modems. They offer enhanced modem functions-in particular, modem testing and diagnostic capabilities that for the first ttire are fully integrated into the network problem determination facilities. Information provided by these modems to NCP and NPDA can help to pinpoint errors in terms of data terminal or communication facilities, or to identify incident or quality trends. An operator using NCCF and NPDA can initiate tests of modem pairs and the line quality between them; the tests intersperse diagnostic sequences with user data in an orderly way, without disrupting on-going sessions.

The LU-LU session type 2 was extended in SNA 4.2 to provide multiple partitioning of the display screen, and scrolling, permitting an operator to scroll within a screen partition without interaction with the host. These extensions were provided on the 8775 display terminal.

SNA support for the CCITT Recommendation X.21 interface was announced in December 1979, for use in Japan. X.21 provides a general-purpose interface that allows its users to choose any data link control and higher-level protocol. The compatibility of SNA and X.21 is discussed in [20]. In a recent statement of direction, IBM stated its objective to provide the capability of attaching selected products to public data networks with X.21 or X.25 interfaces.

Subsequent to the SNA 4.2 announcement, additions to the architecture and product set have continued:

The remaining sections describe the techniques developed to specify the architecture and control its evolution.


The clear and unambiguous specification of SNA, a large-scale architecture being implemented by groups located world-wide throughout IBMi presented new challenges for the architects. Earlier techniques for defining data link controls, such as IBM's Binary Synchronous Communications (BSC), had involved specification of all possible sequences of commands and responses, using graphic techniques and supplementary commentary. This sequence-description approach, epitomized by the American Standard version of BSC [21], was not adequate for an architecture as comprehensive as SNA. The approach was graphically complex and left too much to the implementers' imaginations. Each implementation group was forced to independently invent its own product control structure based on a design entirely deduced from the defined sequences.

The architects adopted the perspective of implementers and focused on defining SNA in terms of nodes, having archetypal control structures and common architectural abstractions. Hierarchical control was defined among different types of nodes, e.g., a subarea node having an SSCP controls a domain.

The node was successively refined, using decomposition techniques, into subcomponents, within layers, that generate and receive specific sequences. This sequence-generator approach [22] eliminated the prohibitive task of defining elaborate sequence graphs for SNA. The node specification, itself, developed into a meta-implementation--a form resembling an actual implementation and providing a model for implementers to follow in designing their own products.

A new approach, using classical finite-state machine (FSM) theory [23], was applied to the meta- implementation: state-oriented specification and synchronization of communicating components. The routing logic and sequence generators within a node were defined as FSMs, depicted by flow charts, state-transition graphs, and other formal notational devices [24]. The first edition (1976) of the SNA Format and Protocol Reference Manual [7] used these techniques. Similar techniques have been independently developed elsewhere [25].

With the proven success of this approach, the architects took the next logical step. A PL/I-like language, Format and Protocol Language (FAPL), was defined. The previous notational methods were replaced by procedures and state-transition matrices having rigorous semantics and machine-readable syntax, as defined in the second edition (1978) of [7]. The meta-implementation has become compilable and executable, and has been subjected to automated validation techniques [8].

The validation technique involves an automated, state-reachability analysis [26], developed at the IBM Zurich Research Laboratory. It can detect deadlocks and erroneous or incomplete design within an architecture. Used for SNA initially to validate the data flow control layer, it is now a standard tool in the architectural development process.

The future prospects for these formal techniques seem very promising. Already, one shipped product has included code manually adapted from selected meta-implementation code. Other groups within IBM are exploring similar uses of the meta-implementation, not only for direct product implementation, but also as a base for new automated testing vehicles. In the long term, we expect the formal techniques to help reduce development costs and improve system reliability.


It is a commonplace for authors of SNA articles to acknowledge the contributions by "numerous groups throughout IBM" to the architecture development. This is not an exaggerated claim.

Nearly every IBM division and numerous product groups, located world-wide, participate in the SNA development process. Requirements for SNA modifications and extensions are received both from outside IBM (e.g., the SHARE and GUIDE user-groups) and from within (marketing, product development, field engineering, IBM corporate-network designers). Product designers, research groups, and others aid the architects in rendering requirements into algorithmic and control-structure solutions. These eventually are added as rigorously defined formats and protocols within the programmed meta- implementation.

An architecture maintenance board (or AMB), patterned somewhat after that defined for the System/360 and 370 architectures [27], exists to control and extend SNA. The AMB has a general networking section and a section dedicated to LU-LU presentation services and function management for end-user interaction. Each section is chaired by an architecture manager and has members representing all SNA products and other interested groups. The AMB meets about every five weeks to discuss and resolve architectural and implementation matters. Formal minutes of the meetings, with various proposals or architecture changes appended, are widely circulated within IBM for information and review.

The AMB is the forum in which architects, product designers, and others reach consensus on extending SNA. One important product of the AMB process is the updating of the formal meta- implementation specifications, which are published externally [6-7], based on SNA product releases. Updating of the formal specifications by architects is closely controlled by iterative phase reviews and exhaustive walkthroughs, supplemented by compilation, execution, and validation checking. Formal "closure" of specification changes is effected by AMB approval. Newly closed specifications are circulated world-wide to IBM design groups to keep them fully synchronized with the evolving architecture.


SNA has evolved in many ways in the six years following its announcement. The family of SNA products and application subsystems has mushroomed. Intermediate-level processors have been added to the high-level processors, cluster controllers, and lower-level terminals that characterized its beginnings. Distribution of control has taken various forms, from centralized (network operator control) to peer-distributed (session services, congestion control) to local (link recovery), depending on the degree of coordination required by customer option.

Increasing emphasis has been placed on flexible configuration and on the dynamic and adaptive aspects of network management and control. Network topology has progressed from tree-structures to general mesh structures. Protocols have been developed for dynamic reconfiguration within the network. Adaptive flow control and classes service have been added to path control.

End-user services have been enhanced to take advantage of technological advances in distributing processing and data-base capabilities.

SNA products have incorporated migration support for pre-SNA data link controls. Standard protocols such as SDLC and DES cryptography have been incorporated into SNA. SDLC conforms to both national (ADCCP) and international (HDLC) data link control standards. Support for X.21 and X.25 has also been provided; IBM encourages the use of such international standards and continues to participate and contribute to efforts to develop and enhance them.

Formal techniques, to describe, test, and control the architecture, have been developed. These should result in more efficient, cost-effective, and reliable implementations.

We look forward to the next six years.


  1. V. L. Hoberecht, "SNA Function Management," IEEE Transactions on Communications, Vol. COM-28, No.4, pp. 594-603, April 1930.
  2. J. P. Gray, "Services Provided to Users of SNA Networks" Proceeding's of the Sixth Data Communications Symposium, Pacific Grove, Calif., pp. 52-62, Nov. 1979
  3. V. Ahuja, "Routing and Flow Control in Systems Network Architecture" IBM Systems Journal, Vol. 18, No. 2, pp. 298-314, 1979.
  4. J. P. Gray and T. B. McNeill, "SNA Multiple-System Networking," IBM Systems Journal, Vol. 18, No. 2, pp. 263-297 (1979).
  5. J. D. Atkins, "Path Control: The Transport Network of SNA," IEEE Transactions on Communications, Vol. COM-28, No. 4, pp. 527-538, April 1980.
  6. IBM Corp., Systems Network Architecture: Logical Unit Types, IBM Form No. GC20-1868-1 (1979).
  7. IBM Corp., Systems Network Architecture Format and Protocol Reference Manual: Architecture Logic, IBM Form No. SC30-3112-1 (1978).
  8. G. D. Schultz, D. B. Rose, C. H. West, and J. P. Gray, "Executable Description and Validation of SNA," IEEE Transactions on Communications, Vol. COM-28, No. 4, pp. 661-677, April 1980.
  9. E. H. Sussenguth, "Systems Network Architecture: A Perspective," Proceedings ICCC 78, Kyoto, Japan, pp. 353-358, Sept. 1978.
  10. D. J. Eade, P. Homan, and J. H. Jones, "CICS/VS and Its Role in Systems Network Architecture," IBM Systems Journal, Vol. 16, No. 3, pp. 258-286, 1977.
  11. R. O. Simpson and G. H. Phillips, "Network Job Entry Facility for JES2," IBM Systems Journal, Vol. 17," No. 3, pp. 221-240, 1978.
  12. Data Encryption Standard, Federal Information Processing Standard (FIPS) Publication 46, National Bureau of Standards, U. S. Department of Commerce, Washington, D.C., Jan. 1977.
  13. R. E. Lennon, "Cryptography Architecture for Information Security," IBM Systems Journal, Vol. 17, No. 2, pp. 138-150, 1978.
  14. R. R. Jueneman and G. S. Kerr, "Explicit Path Routing for Switching Networks," IBM Technical Disclosure Bulletin 18, No. 9, pp. 3054-3062, February 1976.
  15. R. R. Jueneman and G. S. Kerr, "Explicit Path Routing in Communication Networks," Proceedings of Third International Conference on Computer Communications, Toronto, pp. 340-342, August 1976.
  16. G. A. Deaton and D. J. Franse, "A Computer Network Flow Control Study," Proceedings of Fourth International Conference on Computer Communications, Kyoto, Japan, 1978. pp. 135-140
  17. M. Geria and L. Kleinrock, "Flow Control: A Comparative Survey," IEEE Transactions on Communications, Vol. COM-28, No. 4, pp. 553-574, April 1980.
  18. G. A. Deaton, "Flow Control in Packet-Switched Networks with Explicit Path Routing," Proceedings of the International Symposium on Flow Control in Computer Networks, Versailles, France, Feb. 12-14, 1979.
  19. H. Rudin and H. Muller, "On Routing and Flow Control," Proceedings of the International Symposium on Flow Control in Computer Networks, Versailles, France, Feb. 12-14, 1979.
  20. V. Ahuja and A. S. Barclay, "Compatibility of Systems Network Architecture and the CCITT X.21 Interface," Conference Record Vol. 1, National Telecommunications Conference Nov. 1979, pp. 3.4.1-3.4.7.
  21. "Proposed USA Standard, Data Communication Control Procedures for the USA Standard Code for Information Interchange,". Communications of the ACM, Vol. 12, No. 3, March 1969, pp. 166-178.
  22. R. J. Sundstrom, "Formal Definition of IBM'S Systems Network Architecture," NTC '77 Conference Record, Vol. 1, pp. 03A: 1-1 to 1-7, December 1977.
  23. A. Gill, Introduction to the Theory of Finite-State Machines, McGraw-Hill, N. Y. (1962)
  24. T. F. Piatkowski, "Finite-State Architecture," Proceedings of the 7th Annua1 Southeastern Symposium on System Theory, March 1975, Auburn University, Auburn, At, and Tuskegee Institute, Tuskegee, AL, IEEE Cat. No. 75 CH0968-8C.
  25. C. Sunshine, "Formal Techniques for Protocol Specification and Verification," Computer, Vol. 12, No. 9, September 1979, pp. 20-27.
  26. P. Zafiropulo, C. H. West, H. Rudin, D. D. Cowan, and D. Brand, "Towards Analyzing and Synthesizing Protocols," IEEE Transactions on Communications, Vol. COM-28, No. 4, pp. 651-660, April 1980.
  27. R. P. Case and A. Padegs, "Architecture of the IBM System/370," Communications of. the ACM, Vol. 21, No. 1, pp. 73-96, Jan. 1978.

Robert J. Sundstrom is currently Manager of Network Architecture in IBM's System Communications Division, and chairs the general networking section of the SNA architecture maintenance board.

Dr. Sundstrom received the B.S. degree in applied mathematics, and the M.S.E. and Ph.D. degrees in computer, information, and control engineering from the University of Michigan, Ann Arbor, in 1970, 1971, and 1974, respectively.

In 1974, he joined IBM at Research Triangle Pack, N.C. where he has been working on the development and formal description of SNA.

He is member of the IEEE Computer Society, ACM, and Sigma Xi.

Gary D. Schultz joined IBM in 1965. He participated in the programming, documentation, and design of BSC products and in the formal, sequence description of the BSC architecture. After a two-year educational leave, during which he designed a time-sharing system (CHAT) that is still in daily use at the University of North Carolina, he rejoined IBM in 1970 as a research staff member in a Raleigh research group. He did mathematical modelling of buffering techniques and worked on some cooperative research/development projects. In 1972 he joined SCD's Communication Systems Architecture and since 1973 has been working on SNA; he is currently the editor of the SNA Format and Protocol Reference Manual.

He received a B.S. in statistics from the University of Chicago and an M.S. in computer science from UNC at Chapel Hill. He is a member of AAAS.