Jump to content

Systems Network Architecture

From Alfawiki
Systems Network Architecture
Company typeNetworking architecture
IndustryComputer networking
Founded1974
FounderIBM
ProductsSNA protocol stack, VTAM, NCP, SDLC
ParentIBM

Systems Network Architecture (SNA) represents IBM's exclusive networking framework, developed in 1974. It constitutes a comprehensive protocol stack designed to link computer systems and their resources, specifying communication protocols and data formats without providing the actual software. Implementations of SNA include communication software such as Virtual Telecommunications Access Method (VTAM), which serves as the mainframe component for SNA-based communications.

History

IBM unveiled SNA within its "Advanced Function for Communications" announcement in September 1974, introducing SNA/SDLC (Synchronous Data Link Control) protocols alongside new hardware products like:

These were supported by IBM 3704/3705 controllers running Network Control Program (NCP), together with System/370 software including VTAM, CICS, and IMS. A subsequent announcement in July 1975 expanded the lineup with the IBM 3760 data entry station, IBM 3790 communication system, and additional IBM 3270 display terminals.

At a time when layered communication models were not yet standardized, SNA integrated application processing, database access, and communication protocols into a single architecture, which introduced complexity in management. The architecture was primarily developed by IBM's Systems Development Division based in Research Triangle Park, NC, with other IBM laboratories contributing to the implementation of SNA/SDLC protocols. IBM later documented these technologies extensively in its System Reference Library manuals and the IBM Systems Journal.

SNA continues to be extensively utilized within sectors such as banking, financial transaction networks, and government institutions. By 1999, approximately 3,500 organizations operated around 11,000 SNA mainframes. The principal hardware components—the 3745 and 3746 communications controllers—have been discontinued by IBM but remain under maintenance support from IBM as well as third-party vendors providing spare parts and extended functionalities. Software support for VTAM and NCP persists through IBM.

In 2008, IBM acknowledged that due to the widespread adoption of TCP/IP, SNA had evolved from a full network architecture into more of an "application and application access architecture," wherein SNA protocols are transmitted over IP networks.

Objectives of SNA

During the mid-1970s, IBM’s primary identity was that of a hardware supplier, with innovation efforts centered on stimulating hardware sales. The purpose behind SNA was to reduce operational expenses associated with managing numerous terminals, thereby motivating clients to adopt interactive terminal-based systems rather than relying on batch processing. This transition aimed to increase demand for terminals, mainframes, and peripheral devices by raising the computational load per transaction.

SNA sought to minimize both non-computing costs and operational difficulties inherent in large-scale networks that used earlier communication protocols. Among the main challenges were:

  • Communication lines often lacked flexibility because different terminal types used incompatible protocol variants or "dialects." Terminals contained fixed communication cards designed for a single protocol type only, limiting interoperability.
  • Early communication protocols were inefficient and consumed excessive transmission time.
  • Telecommunications infrastructure was of low quality; dial-up connections rarely exceeded speeds of 19,200 bits per second due to frequent errors, while leased lines typically operated at around 2,400 bits per second—far slower than contemporary standards.

As a result, supporting many terminals necessitated numerous dedicated communication lines, especially when multiple terminal types or applications (such as CICS or TSO) coexisted at one site. From a financial perspective, SNA aimed to boost customer investment in terminal-based systems and expand IBM’s share of the market—largely at the expense of telecommunications providers.

Additionally, SNA addressed a limitation inherited from System/360 in the System/370 architecture: each CPU could connect up to only 16 I/O channels, each channel supporting a maximum of 256 peripheral devices—capping total peripheral connections per CPU at 4,096. Since each communication line counted as one peripheral device, this restriction limited the number of terminals that could be attached to mainframes.

Core components and technologies

Progress in computer hardware facilitated the development of terminals equipped with more advanced communications cards capable of supporting a single standardized communications protocol, replacing earlier terminal-specific, limited protocols. During the 1970s, multiple multi-layer communications protocols appeared, with IBM's SNA and the ITU-T standard X.25 emerging as the leading solutions.

Important aspects of SNA include:

  • IBM Network Control Program (NCP), which operates on the 3705 and later 37xx communications processors, implements the packet switching protocol defined by SNA. It fulfills two primary roles:
    • Packet forwarding, functioning similarly to contemporary switches by directing data packets to the next destination—whether a mainframe, terminal, or another 3705 processor. Unlike modern routers that support peer-to-peer networking, these processors were designed for hierarchical networks centered around a mainframe.
    • Combining multiple terminals onto a single communication line connected to the CPU, thereby reducing limitations on the number of communication lines per CPU. A 3705 could manage numerous lines (initially up to 352), yet it was counted as one peripheral device by CPUs and channels. IBM later introduced enhanced communications processors, with the latest model being the 3745.
  • Synchronous Data Link Control (SDLC), a protocol that greatly improved data transfer efficiency over single communication links:
    • Utilizing a sliding window protocol, it allowed terminals and 3705 processors to transmit several frames consecutively without waiting for acknowledgments. Communications cards contained memory to track the last seven frames sent or received, request retransmission only for corrupted frames, and reorder frames correctly prior to forwarding.
    • Frames shared a consistent envelope (header and trailer), permitting diverse terminal data packets to travel over the same line while delegating formatting and dialog control to the mainframe.
Remote terminals and 3705 processors employed communications cards compatible with SDLC.
SDLC served as a forerunner to modern packet communication protocols such as TCP/IP and evolved into HDLC, which became fundamental for dedicated telecommunication circuits.
  • VTAM, a software suite responsible for log-in procedures, session management, and routing within the mainframe environment. Terminal users accessed specific applications or environments (e.g., CICS, IMS, DB2, or TSO/ISPF) through VTAM. It managed data routing between terminals and applications until logout. Initially, IBM hardware supported only one session per terminal; however, during the 1980s, third-party software enabled concurrent sessions across multiple applications or environments.

Benefits

  • Troubleshooting telecommunications issues was simplified due to centralized link control software within NCP, which was supported by a unified error reporting framework.
  • Embedding communication functionalities into applications became more straightforward because complex link control tasks were managed by system software alongside the IBM Network Control Program (NCP).
  • With Advanced Peer-to-Peer Networking (APPN), routing responsibilities transitioned from routers to computers themselves, allowing dynamic session routing across various node types. APPN removed the dependency on static routing tables, enhancing network adaptability. APPN (PU2.1) accommodated protocols such as APPC (LU6.2), chiefly utilized in CICS and database contexts for two-phase commit operations. Physical Units like PU5 (VTAM) served as primary controllers overseeing connections for secondary PU devices.

Drawbacks

  • Establishing connections with non-SNA networks posed significant difficulties; prior to IBM's integration of X.25 compatibility, linking to X.25 systems necessitated complex protocol translation through either modifications to NCP or the use of external converters.
  • SNA relied on preconfigured, centrally maintained alternate routes between nodes, featuring inflexible routing that did not adapt dynamically to current network traffic conditions.
  • Deploying and maintaining the network involved considerable complexity and expense—VTAM licenses could cost up to $10,000 per month on premium hardware, while IBM 3745 Communications Controllers often surpassed $100,000 in price. Efforts to streamline SNA via APPN encountered resistance due to migration challenges and limited immediate benefits. Meanwhile, TCP/IP gained widespread adoption during the 1990s owing to its decentralized, packet-switching design.
  • The connection-oriented architecture of SNA required elaborate state machine implementations; APPN introduced further intricacies through multiple node classifications. Despite enhancements over time, initial APPN shortcomings prompted many enterprises to discontinue its use, accelerating TCP/IP’s dominance and contributing to SNA’s gradual obsolescence.

Network Addressable Units

Network Addressable Units (NAUs) within SNA refer to addressable components responsible for sending and receiving data, divided into categories as follows:

  • System Services Control Point (SSCP): oversees resource management and session services such as directory handling within a subarea network;
  • Physical Unit: hardware and software entities that manage link connections to other nodes;
  • Logical Unit: serves as an intermediary layer between users and the network infrastructure.

Logical Unit (LU)

SNA enables seamless communication among LUs but differentiates LU types based on terminal capabilities (for example, display size). Three primary data streams facilitate interaction between local terminals and printers:

  • SNA Character String (SCS), used by LU1 terminals and network logins through Unformatted System Services (USS);
  • IBM 3270 data stream designed for mainframe environments like System/370 and zSeries;
  • IBM 5250 data stream applied in minicomputers or servers such as System/34, AS/400, and IBM Power Systems operating IBM i.

SNA categorizes LU device types as follows:

  • LU0: supports undefined or custom protocols; also used for non-SNA 3270 devices via TCAM or VTAM;
  • LU1: designated for printers or combined keyboard-printer units;
  • LU2: corresponds to IBM 3270 display terminals;
  • LU3: printers utilizing 3270 communication protocols;
  • LU4: batch processing terminals;
  • LU5: undefined category;
  • LU6: facilitates application-to-application communication protocols;
  • LU7: sessions involving IBM 5250 terminals.

The most prevalent types include LU1, LU2, and LU6.2—the latter being a sophisticated protocol designed for application-level interaction.

Physical Unit (PU)

The 37xx series comprises IBM SNA communications controllers: the 3745 supports up to eight high-speed T1 lines; the 3725 functions as a large-scale node and front-end processor; while the 3720 serves as a remote concentrator and routing device.

SNA over Token-Ring

VTAM/NCP PU4 nodes connected to IBM Token Ring networks utilize a shared LAN environment alongside workstations and servers. The 3745 manages the encapsulation of SNA packets into Token-Ring frames, facilitating session communication across Token-Ring infrastructures.

SNA over IP

During the mid-1990s, IBM collaborated with Cisco to create Data Link Switching (DLSw), a technology that wraps SNA packets inside IP datagrams for transport over IP networks. This encapsulation takes place within Cisco routers positioned at both ends of a DLSw peer link. At mainframe locations, these routers interface directly with VTAM through Token Ring configurations. Remote users typically connect via PU type 2 emulators—such as SNA gateway servers—attached to router LAN ports, with end-user devices often being PCs running 3270 emulation software configured to communicate with the SNA gateway. VTAM/NCP PU type 2 nodes are defined as Switched Major Nodes local to VTAM, supporting line connections through a variety of interfaces including Token Ring on the 3745 or Cisco ESCON-compatible Channel Interface Processors.

Competitors

Honeywell Bull mainframes implemented the proprietary Distributed Systems Architecture (DSA) featuring VIP terminal communication protocols, which have since been superseded by TCP/IP-based solutions like TNVIP terminal emulators (GLink, Winsurf) and Mainway translation tools. The GCOS 8 platform supports TNVIP SE over TCP/IP.

Univac mainframes utilized the Distributed Computing Architecture (DCA), while Burroughs systems employed Burroughs Network Architecture (BNA); both architectures became obsolete following their consolidation into Unisys by 2012. International Computers Limited (ICL) developed Information Processing Architecture (IPA).

DECnet, introduced by Digital Equipment Corporation in 1975 to interconnect PDP-11 minicomputers, evolved into an early peer-to-peer networking model that positioned DEC as a prominent network technology provider during the 1980s.

SNA also faced competition from the ISO Open Systems Interconnection (OSI) framework, designed as a vendor-neutral standard but impeded by its complexity and challenges in achieving interoperability due to its broad flexibility.

For many years, IBM regarded TCP/IP as a nonviable alternative, partly because of intellectual property concerns. Nevertheless, the 1988 release of by Yakov Rekhter, which defined IBM 3270 sessions over Telnet, reflected growing customer demand for interoperability. Subsequent RFCs formalized TN3270, enabling direct client-server connections to mainframes with minimal modifications to VTAM applications such as CICS and TSO by supporting traditional 3270 protocols over TCP/IP. TN3270 has become a favored approach for replacing legacy SNA links compared to alternatives like DLSw. A comparable protocol, TN5250, serves the IBM 5250 environment.

Non-IBM SNA implementations

Third-party SNA software allowed non-IBM platforms to communicate with IBM mainframes and AS/400 midrange systems using SNA protocols.

Unix vendors such as Sun Microsystems provided SunLink SNA products, including PU2.1 Server, while Hewlett-Packard/Hewlett Packard Enterprise offered the SNAplus2 solution. In 1993, Microsoft introduced SNA Server for Windows, now known as Microsoft Host Integration Server. Digital Equipment Corporation developed VMS/SNA for VMS, complemented by third-party options like Systems Strategies, Inc.'s VAX Link.

Hewlett-Packard also supplied SNA Server and SNA Access products for its HP 3000 systems. Brixton Systems marketed several SNA software packages under the "Brixton" brand—such as BrxPU21, BrxPU5, BrxLU62, and BrxAPPC—supporting workstations from vendors including Hewlett-Packard and Sun Microsystems.

IBM endorsed multiple non-IBM APPC/PU2.1/LU6.2 solutions for connectivity with z/OS, including HP’s SNAplus2, Brixton 4.1 SNA for Sun Solaris, and SunLink SNA 9.1 Support for Sun Solaris.

See also

References

External links

Retrieved from "https://www.alfawiki.org/index.php?title=Systems_Network_Architecture&oldid=28565"