SNA: A Technological Overview and Assessment
Introduction
The demand for
centralized data processing in the early-1970s resulted in the building of the
IBM Systems Network Architecture (SNA). In September 1974 IBM began releasing
the first products that conformed to the SNA specifications.
Although most industry sources agree with the declining trend of SNA, they disagree in the rate of the decline and the appropriate transition strategy. By one estimate, 65% of existing IBM SNA applications will be around 10 years from now and 30% of mainframe shops will be using APPN by the end of 1995 (source: Xephon PLC). However, a recent survey [Forrester Research], cites that while in April 1991, 48% of 50 Fortune 1000 believed their SNA networks were growing, only 16% of them thought so by May 1993. Despite its relative immaturity and instability, major corporations [Gaffin, 1994] have begun migrating their backbones to TCP/IP. Additional evidence from industry surveys [Cooneyd], concurs that SNA/SDLC will become extinct in less than five years.
This paper offers a technical overview of the SNA technology and attempts an assessment of its future. It is organized in three sections: the first covers SNA and its inseparable partner, Token Ring, the second section takes a look at its successor, APPN and he third, concluding, section assesses and summarizes the industry's perceptions about the technology and its future.
Terminology
User: end-users
or an application program that uses the SNA network; it can be located at
different points in the network (e.g. terminal, terminal controller, host,
etc.)
SNA model
The SNA hierarchical
architecture as defined by IBM as "a set of network addressable units
interconnected by an inner path control network." Given that models are a "best
attempt" to describe emerging theories or systems, but not necessarily an
accurate representation of reality, IBM has been attempting for almost a decade
to adjust SNA so that it can fit into the Open Systems Interconnect (OSI)
reference model. Despite the fact that during its existence SNA has been
modified a number of times to accomplish this, the following is represents its
latest attempt in doing so. Fig 1. SNA and TCP/IP correspondence to the OSI
reference model
* Physical: Undefined for SNA (although practically, for a number of years, Token Ring specifications were exclusively serving this purpose)
* Path control Network: consists of lower level components that control the routing and data flow through the network; it is further subdivided into (fig 1):
* Network Addressable Unit (NAU) : a partner of a session, identifiable by network address as either origin or destination. It consists of the LU, PU and SSCP that reside in a single network device. Its services include configuration, session, management, directory, topology, routing services, the session and resources managers. Further subdivided into:
* Application: Transaction Services
Token Ring
Until recently,Token Ring (TR), IEEE
802.5, was the preferred LAN contention scheme; now nearly all platforms are
supported over Ethernet IEEE 802.3. Some basic TR characteristics include:
* Differential Manchester DC encoding
* maximum theoretical throughput of 4 or 16 Mbps (with more than 1 token)
* physical topology is a "star", with the Multi-station Access Unit (MAU) at the "hub"; logical implementation is, of course, that of a ring Fig 2. The two basic Token Ring frame formats: the Token itself and a regular frame.
* supports two basic frame format (fig 2) [ICM, 1991]
* The control method for token ring is called Token Access. The token rotates clockwise or downstream in a ring from one workstation to the next. The design of TR guarantees that each station on the network has an opportunity to transmit at regular intervals by accessing the Token.
* Active Monitor (AM): monitors the token status by maintaining a master clock. If the token has been passed on for certain specific time, the AM will generate a new token, T, to continue the communications.
* Nearest Active Upstream Neighbor (NAUN): is the workstation that transmits the token when a hardware error occurs in a ring. * Beaconing: is a TR communication process that occurs when a ring station generates a warning signal onto the ring if it sees a hard error occur with itself or its NAUN.
* SNA routing: native routing scheme is fixed-path with manually predefined routes. It occurs among 37xx, between 37xx and mainframes, or among mainframes. Unlike typical routing, which occurs at the OSI Network Layer, SNA routing occurs in Layers 4 and 5 of the SNA stack [Special Issue-Network World].
In terms of the TR's future, there are currently four upgrade options [Guruge, 1994]:
* TR enhancements, such as switching or full duplex TR
* Fast Ethernet
* IEEE 802.12 100Base-VG/AnyLAN
* Asynchronous Transfer Mode (ATM)
SNA components
* NAU: Consists of the LU, PU and SSCP
that reside in a single network device.
* System Service Control Point (SSCP): provides the services needed to manage an SNA network and to establish and control the interconnections that are necessary to allow network users to communicate with one another; one per domain (fig 3). Fig 3. SNA's hierarchical relationship between SSCP, PU and LU
* Physical Unit (PU): is used to represent the actual devices of the SNA network (e.g. controllers, terminals, etc.). A PU is implemented with some combination of hardware, software and firmware within the particular device that the physical unit represents; one per node. There four different types of PUs:
* Logical Unit (LU): provides points of access through which users interact with the SNA network, similar in concept to a port or socket which a user plugs into. An LU is thus considered a virtual connection and each LU represents a single user. LUs are implemented in software or firmware; there are 7 types, each providing different transmission capabilities and a different set of services; one per end-user (fig 4). There are seven basic type of LUs:
Session types
* SSCP-to-SSCP: apply only to multiple
domains SNA network; are used to initiate and terminate cross-domain LU-to-LU
sessions.
* SSCP-to-PU : are used to transfer load and dump information.
* SSCP-to-LU : established for each LU when the network is initialized are used to establish an LU-to-LU session initiation and termination information
* LU-to-LU : are established dynamically; allow users to network and communication to each other.
* PU-to-PU: established to exchange network control information
Mainframe Links
* For close physical proximity, the link can be connected by an IBM cable of the FEP's I/O channels.
* For remote communication links, the link is implemented via a circuit using SDLC (Synchronous Data Link Control) protocols. The link could be point-to-point or multi-point. SDLC was described first by IBM in 1973, and is today compatible with the subset of ISO's High-level Data Link Control (HDLC).
Altogether there are five alternatives for implementing distributed processing in an SNA environment. Four of them involve some combination of SNA and TCP/IP; the fifth, APPN, is covered in a separate section.
i) IP Encapsulation: places SNA traffic in IP format.
ii) Enterprise Gateway: full 7-layer protocol conversion between SNA and TCP/IP.
iii) Native TCP/IP: Adds TCP/IP protocol stack to the mainframe.
iv) AnyNet: IBM-developed middle-ware that implements TCP/IP sockets applications over SNA and vice-versa.
Up until recently, each vendor's routers were using a different method of encapsulation, making multi-vendor compatibility impossible. This is about to change, with the emerging Data Link Switching (DLS, which is the result of RFC 1494). DLS establishes a standard method for making a router appear as an FEP to the SDLC line. In addition, its latest release due this month adds support for remote management via SNMP.
IBM also recently announced a licensing agreement with CNT/Brixton Systems, Inc. to provide AIX-based SNA servers that support both SNA and TCP/IP. One of the products, CNT/Brixton BrxPU2.1, will act as a gateway between TCP/IP and SNA backbone, by emulating a 3174 cluster controller to the SNA host and a TCP/IP host to the devices attached to the IP network. The other, BrxPU5, emulates a subset of VTAM and SNA host communication features, enabling the IBM 6000 to look like a mainframe.
In another effort to reduce the cost of its AIX OS (IBM's version of Unix), recently offered AIX v4.1. It now comes in separate client and server packages, with the client package requiring only half the RAM the server need [Cooneyc].
It is the proclaimed SNA successor, with an ever more elusive target market. It uses LU6.2 (with peer-to-peer capabilities), but has not been met with success because of the TCP/IP factor. Other detrimental factors cited to the widespread deployment of APPN include high cost per node and security [Cooneyd]. Consists of Network Nodes and End Nodes (fig 4). Network nodes perform the following basic functions:
* Dynamic network topology
* Distributed directory
* Dynamic route selection
Fig 4. Typical APPN network is made of End Nodes and Network Nodes Source: IBM ITSO. The IBM 6611 Network Processor as a SNA/APPN Router
Also, an enhancement to the existing APPN routing is the already delayed High-Performance Routing (HPR), which IBM claims, can route around failures, has improved prioritization and increases performance by 30%. Recent lab tests showed APPN routers configured as Network Nodes achieved satisfactory results, (70-98% utilization of a T1 circuit, depending on frame size), provided the devices are properly configured [Cooneye].
Conclusion
To date, $20
trillion has been invested in SNA, worldwide. In the early 90's, IBM was
marketing itself as an OSI and TCP/IP integrator. However, OSI products from IBM
never materialized, and then markets and customers quickly switched over to
TCP/IP as the internetworking protocol of choice (greatly dictated by Internet
connectivity). IBM first tried SAA, APPN's predecessor, that never caught on.
Then, almost too late, and under customer pressure, begun actually offering
TCP/IP connectivity, while continue marketing the SNA successor, APPN.
In addition, IBM's most influential users' group (1,712 user organizations, including 98% of the Fortune 50), Share, Inc., began voicing their demands for improved multi-protocol, enterprise-wide systems management; increased recoverability, availability and serviceability of LAN-based products and improved security with single login and authentication check.
Those repeated failures to even follow the pace of the changing marketplace, were not lost on Wall Street. In the fall of '91 it decided that Big Blue's stock was overpriced and sent its price tumbling for $125 to about $80 and it has not recovered since (close 11/4: 701/8). The company has been forced through two major re-organizations, layoffs of tens of thousands of its employees, a CEO change and still unable -with the exception of a couple business units- to demonstrate improved financial discipline.
Today, almost unanimously, industry analysts agree with the assessment that SNA has entered critical crossroads. Despite its current widespread use among medium and large companies, its popularity and market share are declining fast, mainly due to proprietary technology and high life-cycle cost. Meanwhile, its designated successor, APPN, has been met with little success, as most companies are unwilling to invest in another similar technology to built their distributed systems; instead they prefer to extend SNA's life by running it over TCP/IP networks. The next two years will reveal how much clout IBM still maintains in the industry.
Cooneya, M. "IBM Users Call for Enterprise Management Tools, Survey Shows.", Network World, Vol 11, No 33, Aug 15, 1994, p 64
Cooneyb, M. "APPN Group Moves Technology Closer to Reality." Network World, Vol 11, No 28, July 11, 1994, p 13
Cooneyc, M. "IBM Brings AIX to Mainstream." Network World, Vol 11, No 31, Aug. 1, 1994, p 8
Cooneyd, M. "Aging SNA Faces a Fight for its Survival" Network World, Vol 11, No 36, Sep. 5, 1994, p 1
Cooneye, M. "APPN Technology Passes Initial Performance Tests." Network World, Vol 11, No 25, June 20, 1994, p 8
Cooneyf, M. "IBM Forges Unix Links to SNA Networks" Network World, Vol 11, No 38, Sept 19, 1994, p 6
Guruge, A. "More Than Token Solutions for User's LAN Blues.", Network World, Vol 11, No 37, Sept 22, 1994, p 66
Special Issue: "IBM Networking Update." Network World, Vol 11, No 24, June 13, 1994, p 49
Gaffin, A. "Internet's in and SNA's out" Network World, Vol 11, No 40, Oct 10, 1994, p 1
Higgins, K. J. "When Networking Worlds Collide." Open Systems Today, October 3, 1994, p 52
Castaldo, A., Flynn S. "Having Designs on SNA". LAN, September 1993, Vol 8, No 9, p 38.
Martin, J., Leben, J. Data Communication Technology. Englewood Cliffs , NJ: Prentice Hall. 1988
IBM International Technical Support Centers. The IBM 6611 Network Processor as a SNA/APPN Router. Research Triangle Park, NC: IBM ITSO. 1994 p 45.
IBM International Technical Support Centers. The Library for Systems Solutions, Open Networking Reference: A Business and Technical Perspective. Research Triangle Park, NC: IBM ITSO. 1994.
International Communcations Management, Inc. Data Communications II. Redmond, WA: ICM. 1991 (presentation material for Security Pacific)
Fitzgerald, J. Business Data Communications. NY, NY: John Wiley & Sons,
Inc. 1993