SNA and OSI: three strategies for interconnection.
SNA has met some of its user needs with the advent of Systems Applications Architecture (SAA), but SNA's future may hinge on its ability to conform products to the Open Systems Interconnection Reference Model (OSI) specifications . The rise of the OSI model in international markets and now in the United States is proof that users are driving vendors (such as IBM) to offer connectivity solutions. IBM, initially slow in responding to the OSI model, is now making the adjustments and product announcements that network integrators and managers have been waiting for .
This article will examine the areas where SNA and OSI connectivity have and will possibly occur. The first part of the article will discuss the concept and components of both SNA and OSI. The second part will explain common interconnection devices such as:
(6) device emulation
(7) internet transmission (X.25 packet-switching), and
(8) interstation transmission.
The third part will discuss the major characteristics, pros & cons, and some specialized equipment necessary for three SNA/OSI integration techniques, direct (SNA-OSI), indirect (SNA-non-SNA-OSI), and mixed (portions of direct and indirect). The fourth part will discuss the success of the three integration techniques in both local area network (LAN) and wide area network (WAN) environments, in relation to cost, transmission speeds, flexibility, and connectivity features. The fifth part will discuss current, OSI-complaint IBM product announcements and assess possible areas for future SNA/OSI connectivity.
SNA AND OSI
Systems network Architecture entered the market in 1974 as a hierarchical, single-host network structure . Since then, SNA has developed steadily in two directions. The first direction involved tying together mainframes and unintelligent terminals in a master-to-slave relationship . The second direction transformed the SNA architecture to support a cooperative-processing environment, whereby remote terminals link up with mainframes as well as each other in a peer-to-peer relationship (termed Low Entry Networking (LEN) by IBM) . LEN depends on the implementation of two protocols: Logical Unit 6.2, also known as APPC, and Physical Unit 2.1 which affords point-to-point connectivity between peer nodes without requiring host computer control .
The SNA model is concerned with both logical and physical units. Logical units (LUs) serve as points of access by which users can utilize the network. LUs can be viewed as terminals that provide users access to application programs and other services on the network . Physical units (PUs) like LUs are not defined within SNA architecture, but instead, are representations of the devices and communication links of the network . Physical units are comprised of four main hardware types:
* terminal devices
* cluster controllers
* Front-End Processors (FEP), and
* host computer(s).
Terminal devices and cluster controllers generally are considered peripheral nodes in an SNA network. A peripheral node directly communicates with the subarea node to which it is attached . Therefore, peripheral nodes must communicate and exchange data through the subarea node if they wish to speak with one another. Peripheral nodes are found in a variety of IBM systems including the 3270 family, the 5250 workstation, and the 3730 distributed office systems .
FEPs and host computers are generally considered two different types of subarea nodes. Subarea nodes can communicate with their own peripheral nodes, as well as with other subarea nodes in the network . Host computers (also known as type 5 nodes) are generally found within general purposes systems, such as IBM 30XX, 4300, System/36 or 38 . FEPs (also known as type 4 nodes) are generally communications controllers such as an IBM 3705, 3725, or 3745 . Figure 1 shows the various nodes of an SNA network.
The SNA model is composed of seven architectural layers. The lowest layer, the physical control layer, addresses the transmission of bit streams over a physical connection or circuit [20, 23]. The next layer, the data link control layer, is responsible for the transmission of data between two or more network components (nodes) via specific physical linkages. The data link control layer detects errors that occur in data transmission and maps out a recovery strategy for the network [20, 23].
The third layer is the path control layer which is concerned with the routing of data through the network . The fourth layer is the transmission control layer, which monitors the status of factors associated with current session messages such as data flow, exchange, sequence, size, and encryption/decryption . The fifth layer is termed the data flow control layer and is concerned with the collective integrity of the data flow during a session . The data flow control layer correlates data exchange and synchronized data flow, ensures the use of chaining and brackets protocols, assembles chaining responses, and assigns session sequence numbers [23, 31]. The sixth layer, or presentation services layer, serves to format data for end user representation and is responsible for network services such as maintenance, management, measurement, and configuration [23, 31]. The seventh layer is the transactions services layer which provides end user interfaces to IBM's distributed transaction architectures (Systems Network Architecture Distribution Services, SNADS, Document Interchange Architecture, DIA, and Distributed Data Management, DDM) [21, 31].
The Open Systems Interconnection Reference Model was formally initiated by the International Organization for Standardization (ISO) in March, 1977, in response to the international need for an open set of communications standards . OSI's objectives are:
(1) to provide an architectural reference point for developing standardized procedures;
(2) to allow internetworking between networks of the same type;
(3) to serve as a common framework for the development of services and protocols consistent with the OSI model;
(4) to expedite the offering of interoperable, multi-vendor products and services [9, 23].
The model is similar in structure to that of SNA. It consists of seven architectural layers: the physical layer; the data link layer, the network layer; the transport layer; the session layer; the presentation layer; the application layer.
The physical and data link layers provide the same functions as their SNA counterparts (physical control and data link control layers) . The network layer selects routing services, segments blocks and messages, and provides error detection, recovery, and notification. The transport layer controls point-to-point information interchange, data packet size determination and transfer, and the connection/disconnection of session entities. The session layer serves to organize and synchronize the application process dialog between presentation entities, manage the exchange of data (normal and expedited) during the session, and monitor the establishment/release of transport connections as requested by session entities [23, 31]. The presentation layer is responsible for the meaningful display of information to application entities.
More specifically, the presentation layer identifies and negotiates the choice of communications transfer syntax and the subsequent data conversion or transormation as required [23, 31]. The application layer affords the interfacing of application processes to system interconnection facilities to assist with information exchange. The application layer is also responsible for the management of application processes including initialization, maintenance and termination of communications, allocation of costs and resources, prevention of deadlocks, and transmission security .
The SNA architectural layers (starting with the top layer) and their OSI functional counterparts are compared in Figure 2, and the advantages/disadvantages of each protocol suite are described in Table I. As Figure 2 shows, SNA's transaction services and presentation services layers correspond with the OSI application and presentation layers. SNA's data flow control layer correlates with the OSI session layer, and the SNA transmission control layer corresponds to the OSI transport layer [23, 31]. SNA's path control and data link layers relate to the OSI network and data link layers. The OSI physical layer does not have a direct SNA counterpart and is defined outside the SNA architecture .
Generally, for both architectures, the top three layers are largely responsible for the processing of information, and the middle layer ensures that the information sent is delivered to the proper receiving system . The bottom three layers are concerned with basic communication--providing a vehicle for the transfer of information from one system to another .
There are eight common interconnection devices/methods used by systems integrators to connect OSI and SNA. These methods are:
(6) device emulation
(7) internet transmission (X.25 packet-switching), and
(8) intersection transmission.
Repeaters are transparent devices used to interconnect segments of an extended network with identical protocols and speeds at the physical layer (OSI layer 1) . An example of a repeater connection would be the linkage of two carrier sense multiple access/collision detection (CSMA/CD) segments within a network .
Bridges are devices that connect similar and dissimilar LANs at the data link layer (layer 2), regardless of the physical layer protocols or media being used [14, 20]. Bridges require that the networks have consistent addressing schemes and packet frame sizes . Current introductions have been termed learning bridges since they are capable of updating node address (tracking) tables as well as overseeing the transmission of data between two Ethernet LANs .
Trying to connect an Ethernet LAN with a TokenRing LAN, however, is not an easy task. This is mainly due to the incompatible bridge architecture that exists between the aforementioned two types of LANs. These incompatibilities include: different frame format, different protocol design (Byte-counted vs. Bit-counted), and even different operating concepts (e.g., token-passing vs. CSMA/CD).
Currently, an IEEE 802.1 document incorporating spanning tree (e.g., an algorithm with a frame-forwarding mechanism that will avoid the source-routing situation) tries to provide some new solution, yet it still fails to define a way to link an Ethernet and a token-ring [20, 22, 31].
Routers connect networks at layer 3. Routers interpret packet contents according to specified protocol sets, serving to connect networks with the same protocols (DECnet to DECnet, TCP/IP (Transmission Control Protocol/Internet Protocol) to TCP/IP) [14, 20]. Routers are protocol-dependent; therefore, one router is needed for each protocol used by the network. Routers are also responsible for the determination of the best path for data packets by routing them around failed segments of the network .
Brouters are bridge/router hybrid devices that offer the best capabilities of both devices in one unit . Brouters are actually bridges capable of intelligent routing and therefore are used as generic components to integrate workgroup networks [20, 22]. The bridge function filters information that remains internal to the network and is capable of supporting multiple higher-level protocols at once . The router component maps out the optimal paths for the movement of datafrom one point on the network to another . Since the brouter can handle the functions of both bridges and routers, as well as bypass the need for the translation across application protocols with gateways, the device offers significant cost reductions in network development and integration [20, 22].
Gateways provide functional bridges between networks by receiving protocol transactions on a layer-by-layer basis from one protocol (SNA) and transforming them into comparable functions for the other protocol (OSI) . In short, the gateway provides a connection with protocol translation between networks that use different protocols. Interestingly enough, gateways, unlike the bridge, do not require that the networks have consistent addressing schemes and packet frame sizes. Most proprietary gateways (such as IBM SNA gateways) provide protocol converter functions up through layer six of the OSI, while OSI gateways perform protocol translations up through OSI layer seven .
In addition, several PBXs can offer gateways to public data networks such as Tymnet and Telenet. These gateways are usually implemented with an X.25 interface. Further, current CCITT recommendation X.75 discusses the way to interconnect different X.25 packet switching networks by implementing gateways.
Device emulation is a simple method for allowing devices, specific to one network, to talk with devices on a foreign network. Most micro-to-mainframe communications are dominated by PCs emulating IBM 327X (synchronous) and DEC VT-100-type (asynchronous) devices, affording connection across leased, switched, and X.25 lines [1, 2, 18]. The linkage occurs by the transmission of protocols through a gateway server which sends the message via a linkage protocol to the mainframe .
Internet transmission occurs when one protocol acts as a transmission service (layers 1 and 2) for the other, such as in the case when SNA operates across X.25 packet-switched networks [1, 2]. In other words, the routing function will be handled by the client network (SNA), and X.25, in this case, only acts as a transmission agent. Consequently, packet switching offers significant cost reductions by the efficient use of bandwidths and the concentration of multiple user transmissions over the same line [1, 16].
Interstation transmission occurs when network segments with differing protocols reside together on the same local are network . Interstation transmission focuses more on rendering services between LANs while the internet transmission concentrates on the services between networks [2, 16]. An example would be a common lawyer 3 client residing on any of the IEEE 802 protocol standards, such as CSMA/CD (802.3), token bus (802.4), and token-ring (802.5) . With full blending of layers 1 and 2, SNA and OSI upper layers can be mixed with all IEEE 802 standards .
SNA/OSI INTEGRATION STRATEGIES
IBM has predominantly used three SNA/OSI integration strategies:
(1) direct (proprietary)
(2) indirect (open systems), and
(3) mixed (selective layering).
IBM has approached conformance to OSI standards in a fashion similar to that use dby Digital Equipment Corporation (DEC) with its networking solution, DECnet. DEC sought conformance to the OSI model directly on a layer-by-layer basis while retaining DECnet's proprietary architectural nature . IBM has used a layer-by-layer (direct integration) approach too, but has also used its interconnectability with other networks (indirect integration) to provide links to OSI. IBM's third integration technique (mixed integration) has been to use the lower layers of OSI as transmission service for SNA sessions. This approach (also termed selective layering) has predominantly occurred with X.25 packet-switched networks and OSI-based IEEE 802 data link standards such as Boeing's technical and office protocol (TOP) which is based on 802.3--CSMA/CD, GM's manufacturing automation protocl (MAP) which is based on IEEE 802.4--Token-passing bus standard and IBM's token-ring technology (802.5) [1, 2, 27].
The direct strategy is a layer-to-layer approach of connecting SNA to OSI as Figure 3 shows. The direct integration of SNA products to OSI standards has been handled for the most part from the OSI-to-SNA perspective. As of late 1987, IBM held 85 percent of the installed base of the SNA front-end processor (FEP) market . Its FEP dominance combined with its large installed base for SNA networks, overall, made IBM a strategic choice by ISO members for integration with OSI standards. Therefore, in the first years of OSI-SNA integration, IBM kept its architecture separate, insisting that OSI meet SNA on its own ground.
Direct integration greatly depends on on-site protocol converters or gateway processors to provide the protocol transformations necessary between SNA and OSI suites. Protocol converters are generally FEPs outfitted with specialized protocol translation applications. Two approaches are possible with gateway processors. One approach uses the gateway to perform a layer-by-layer transformation of one protocol into the comparable functions on the other .
The second approach utilizes an application process resident on both SNA and OSI protocol stacks to conduct layer-by-layer transformations . Gateway processors provide transparent linkages between the two protocols but require the use of dedicated hardware and are limited by the compatibility of the features for each layer. Terminal emulation is another technique used by OSI networks to access IBM host-based applications. In most microcomputer to mainframe hookups, personal computers are emulating 327X terminals to communicate with IBM mainframes.
Advantages of Direct Integration
The relative advantages of this integration strategy are:
(1) transparency of the linkages--end users are not aware of the physical connections and data transformations occurring in the transfer of information between SNA and OSI, since the gateway acts as a functional bridge performing all necessary data conversions ;
(2) the capability of end-to-end connections--this strategy allows for host-to-host connections, which is important for long-distance communications.
Disadvantages of Direct Integration
The relative disadvantages of the direct integration approach are:
(1) high cost--due to the need for supporting hardware and software such as PC synchronous boards, host-based software, and on-site protocol converters ;
(2) limited interoperability of layers--the bottom three layers of SNA and OSI are far more compatible with one another than the upper layers of SNA and OSI (responsible for user services such as presentation and transaction services) which have little interoperability ;
(3) separation of architectures--direct integration of SNA to OSI implies that the two architectures are kept separate on their proprietary protocol stacks, duplicating hardware needs and providing a non-coherent view of the network .
Indirect integration is an SNA-to-OSI interconnection strategy whereby a non-SNA, OSI-compliant node serves to connect the two protocols as shown in Figure 4. For example, Intermediate nodes could be vendor-provided gateway products connecting an SNA network with that vendor's proprietary network.
DEC is one vendor committed to full compatibility with OSI standards. The fifth generation (Phase V) of DEC's Digital Network Architecture (DNA) is intended to bring about total OSI compliance of all DECnet products . Currently, Phase V products use OSI protocols up through the transport layer (layer 4) while maintaining prior proprietary protocols for compatibility with DNA phases I through IV .
Digital's goal with DECnet has been to afford the sharing of resources through a generalized interconnection of multi-vendor equipment in point-to-point, multipoint, and switched networks . One aspect of this goal has been realized with the DEC net/SNA gateway, which is a dedicated communications processor with supporting software to link IBM and DEC operating environments [9, 16]. The gateway allows users of either DEC or IBM workstations to utilize the capabilities of both systems. Yet this does not necessitate a technical understanding of the differences between the two architectures .
Advantages of Indirect Integration
The relative advantages of this integration strategy are:
(1) wide range of connectivity--a wide variety of vendors (IBM, DEC, Data General, Tymnet, Maxess) are offering proprietary or third-party products in conformation with OSI standards. This provides system integrations a variety of interconnectin solutions [10, 15-17, 32];
(2) law development costs--it is usually less expensive to conform products to existing proprietary networks than to start from scratch with OSI. Some of the development costs associated with these interfaces can be shared by vendors (DEC/IBM) ;
(3) transparency to users--to the user the sessions with other proprietary networks appears as if a point-to-point link exists by having a dedicated router or gateway handle the protocol conversions [5, 9].
Disadvantages of Indirect Integration
The disadvantages of this approach are:
(1) higher processing time--the interconnection to existing OSI compliant networks requires dedicated hardware (usually a router or gateway) which combined with hardware and software modifications for the new network, could result in performance slipage in the host computer [5, 27];
(2) loss of network management control--proprietary network management control is lost when interconnecting with other proprietary networks that have their own network management systems;
(3) reliability--overall network reliablity will decrease due to the increased overhead in software and hardware in the development of the SNA-non-SNA-OSI interconnections. That is, greater numbers of components involved in interconnection increase the probability of a failure occurring somewhere in the network .
A mixed integration strategy incorporates both direct layer-to-layer and indirect via intermediate, non-SNA node interoperability. Mixed integration occurs when a few lower layers are fully compatible. The SNA-to-OSI crossover occurs at an interface between the compatible lower layers and the upper layers which remain in client networks as shown in Figure 5 . One example of the mixed approach is selective layering, when OSI networks and SNA networks run their upper level protocols independently while sharing an X.25 packet-switched network .
Since 1976, SNA and X.25 have coexisted as separate network architectures: X.25 recognized as the international standard for packet transmission and SNA acknowledged as the de facto standard for domestic data communication . Systems intergrators can bridge the two networks by using: X.25 PADs to bridge at the link level [1, 5]; IBM XI (X.25 SNA Interconnect)--enabling devices with X.25 interfaces to use SNA as a transport mechanism for X.25 packets ; and IBM's Network Packet Switch Interface--a protocol converter which resides in the 3745 communications processor (an FEP) to expedite the transmission of X.25 packets between the two networks at the transport layer [1, 9].
Advantages of Mixed Integration
The advantages of this integration strategy are:
(1) high interoperability between layers--by adhering to its logical link control (LLC) interface of the token-ring network typology, IBM can interconnect with OSI layers three through seven, and SNA protocols can reside on both token-bus or Ethernet networks [2, 14];
(2) SNA retains network control--it maintains network control by treating X.25 packet-switched networks as mere transmission linkages, therefore controlling all routing to subarea nodes ;
(3) uniform treatment of any two devices on each end of the transmission--the use of IBM's Advanced Program-to-Program Communications (APPC) affords peer-to-peer transmissions between a wide variety of network devices (from mainframes to PCs), where the host (usually a 370 mainframe) is not required to manage the conservation [2, 35].
Disadvantages of Mixed Integration
The relative disadvantages of this integration strategy are:
(1) Cost--compatibility is attained by installing OSI lower-layer protocols on all nodes of the SNA network, or (as with most X.25 envinronment) by purchasing and fitting a front-end processor with the appropriate protocols to serve as the communications controller ;
(2) Low availability--only a few of the layers for the OSI model have been fully defined, leaving systems integrators limited options for SNA/OSI blending [3, 13];
(3) Security--the use of public packet-switching services often makes it tougher to limit access to the network and to ensure the safe passage f information along the network .
SNA/OSI NETWORK ENVIRONMENTS
We now will evaluate the suitability of the three integration techniques in local area network (LAN) and wide area network (WAN) environments, in relation to their cost effectiveness, transmission speed, flexibility, and connectivity features (network management, security, error protection/detection). The advantages/disadvantages for each integration strategy in the LAN and WAN environments are summarized in Table II and Table III respectively.
Direct Integration in the LAN Environment
Direct integration of OSI-to-SNA protocols works well in the LAN environment. The high use of the bridge and router, as opposed to the more costly and computationally intensive gateway, has afforded a good cost/performance trade-off, high transmission speeds, high flexibility, and adequate connectivity features in the LAN environment. Bridges do their connecting at the Data Link Layer (layer 2) and are capable of linking similar and dissimilar LANs such as Ethernet (baseband or broadband) to token-ring LANs and token bus LANs to token-ring LANs . Bridges also provide network management functions such as traffic filtering and LAN segmentation which help to avoid overloading the network with too much traffic and possibly cause a session failure . Routers connect networks at layer three and unlike bridges are protocol dependent. Routers assist in the integrity of LAN to WAN connections by matching higher LAN transmission speeds with lower WAN speeds, minimizing accidental data packet loss .
Indirect Integration in the LAN Environment
Indirect integration offers excellent flexibility, good cost effectiveness, but mixed reviews in terms of transmission speeds and connectivity features. Due to the multiplicity of vendors offering OSI compatible products, SNA network managers have a variety of inter-connection routes with OSI. Since some of the development costs can be shared by vendors participating in joint efforts, the costs associated with this form of integration are low [9, 10]. Due to the high use of gateways in this integration technique, processing and transmission speeds are slower than with direct integration . Connectivity features such as security and network management are more difficult due to the varying operating systems between differing proprietary networks.
Mixed Integration in the LAN Environment
Mixed integration in LANs has great potential. Already SNA/OSI integration has occurred by the use of X.25 packet assembler/disassembler (PAD) bridges at the OSI link level . Several vendors offer PADs that support IBM's synchronous data link control protocol (SDLC), offering both virtual and switched-virtual circuits for more flexible network connections [1, 2, 7]. SNA and non-SNA terminals attached to an X.25 network can hook-up with an SNA host computer via IBM's Network Packet Switch Interface (NPSI), a protocol converter illustrated in Figure 6. Mixed integration via X.25/SNA connections offers efficient network management, effective resource utilization, and overall lower costs .
Direct Integration in the WAN Environment
The WAN environment is not as promising as the LAN environment for direct integration. Because of their complex topologies and long communication distances, WAN transmission speeds are slower . The WAN environment requires the use of dedicated machines such as gateways and FEPs which significantly add to the network's hardware and software overhead. Network security, management, and error detection all pose a problem in the WAN environment. The flexibility of linkages between WANs is provided mainly by X.25 packet switching. Some peer-to-peer connectivity is provided through the use of IBM's midrange Application System/400 (AS/400) computer and supporting software [1, 5, 11, 13, 24, 25].
Indirect Integration in the WAN Environment
Indirect integration in the WAN environment offers more promise than direct integration does, due to the high-installed base of proprietary networks. DEC, HP, and others all have products in the marketplace that connect SNA hosts to OSI-based networks [9, 19]. Indirect integration shares the same problems of low transmission speeds and low connectivity features as direct in the WAN environment, but offers more flexible migration paths.
Mixed Integration in the WAN Environment
Mixed integration offers many wide area networking solutions, largely due to the large-installed base of packet-switching technology. The CSI-X.25 multi-protocol controller (Microtronix Systems Ltd.) connects X.25 public and private networks to IBM 370 host computers, as well as asynchronous terminals and IBM SNA/SDLC controllers . Figure 7 shows the connection among different components. X.25 multi-protocol converters offer excellent network throughout rates and access speeds for the WAN environment .
The three SNA/OSI integration strategies have assisted IBM in its quest for full OSI compliance and support of open system networks. The direct strategy, although requiring increased dependence on IBM for product announcements and significant use of processing intensive technologies, affords SNA network managers a viable and sustained migration path toward OSI. The direct approach is better adapted for the LAN rather than the WAN environment where cost-effective bridges, routers, and brouters can be utilized to connect similar and dissimilar nodes on the network.
The indirect strategy provides excellent flexibility due to multi-vendor and third-party networking solutions and good cost effectiveness through the use of existing systems equipment and software. The indirect strategy works well in both LAN and WAN environments but offers more flexible migration paths in the WAN environment due to the high-installed base of proprietary networks.
The mixed approach to SNA/OSI interconnection offers great promise for future communications between SNA and OSI networks, despite the limited operability of SNA and OSI model upper layers. The WAN environment is ideally suited for this integration technique due to the proliferation of X.25 packet-switching networks and the use of multi-protocol controllers. The future use of packet switching by IBM looks secure since IBM has forged strong links domestically with central office switch manufacturers and regional Bell operating companies and internationally with siemens (IBM's partner in Rolm) in an effort to push SNA into the intelligent public network arena [8, 29].
Originally, IBM took a look-and-see posture toward OSI, resulting in only a few directly integrative products being developed in Europe. Currently IBM has committed itself to OSI, conducting OSI development work on layers three through six in Palo Alto, CA., on layer seven in Rome, Italy, and on most of the upper-level layers in Heidelberg, West Germany .
Recent product announcement which will assist in the future of direct-, indirect-, and mixed-integration strategies are:
(1) IBM Open Systems Message Exchange (OSI/OSME) (9/88)--an OSI application for exchaning X.400 electronic message applications [1, 4];
(2) IBM OSI Communications Subsystem (OSI/CS) (9/88)--which permits the connection of IBM and non-IBM nodes over an OSI protocol, as well as the interconnection SAA applications, equipment, and networks [1, 4];
(3) IBM OSI/File Services (9/88)--a licensed program overseeing the transfer and management of data over IBM and non-IBM systems .
OSI/CS and OSI/File Services will not be widely available until 1990, but OSME message-exchange products were already in service by the end of 1988.
In the immediate future, SNA and OSI interconnection will be a more prominent issue. Close attention should be paid to these trends in order to gain competitive advantage.
 Axner, D. H. Packet switching offers improved connectivity, TPT, (Dec. 1988), 40-44.
 Bass, C. Data networks' endangered and protected species. Data Commun. 30, 10 (Oct. 1987), 293-304.
 Belitsos, B. Users unsure about OSI. Comput. (Decis., (Aug. 1988), 38-41.
 Booker, E. Latest IBM product avalanche embraces OSI compatiblity. Telephony, (Sept. 1988), 8.
 Brown, D., and Olivier H. Private networks offer added benefits. TPT, (May, 1988), 75-78.
 Cohn, M. IBM's blueprint for centralized net management. TPT, (Aug. 1988), 34-38.
 Controller links to SNA/SDLC, X.25 networks. TPT, (Apr. 1988), 62.
 Dunn, A. IBM and Telecom: Glimmer of a grand design. Datamation, (Feb 1988), 77-81.
 Edwards, M. OSI standards are guiding computer vendors to compatibility of components and systems. Commun. News, (Apr. 1988), 50-53.
 Greenstein, I. IBM moves to build a DEC link. MIS Week, (Aug 1988), 12.
 Halper, M. Rivals join to boost OSI networking. Telephony, (Aug. 1988), 13.
 Harrison, B. OSI standards: To wait or not to wait? TPT, (Jan. 1988), 51-53.
 IBM computers serve as distributed processors. TPT, (Aug. 1988), 66.
 IBM's great communicator. Mini-micro Syst. (Oct. 1988), 72-75.
 Iida, J. New products emphasize standards. MIS Week, (Feb. 1989), 10.
 Interface Links DEC, SNA networks. TPT, (Dec. 1988), 48.
 LAN gateway supports APPC protocol. TPT, (June 1988), 56.
 Lew, K. H., and Jong, C. Getting there from here: Mapping from TCP/IP to OSI. Data Commun., (Aug. 1988), 161-175.
 Livingston, D. Will IBM's AS/400 lure system integrators? Mini-Micro Syst., (Jan. 1989), 46-51.
 Livingston, D. OSI strategy: Making the right moves. Mini-Micro Syst., (Sept. 1988), 74-80.
 Livingston, D. Software links multivendor networks. Mini-Micro Syst., (Mar. 1988), 43-54.
 Lowe, S. J. At OSI layer 2, the learning curve of bridges keeps rising. Data Commun., (Feb. 1988), 62-64.
 Martin, J. SNA: IBM's Networking Solution. Prentice-Hall, Englewood Cliffs, N.J., 1987.
 McConnell, J. Stepping off the OSI standards bandwagon. Data Commun., (June 1988), 133-145.
 Moran, R. Soat, J., and Rymer, J. IBM's midrange chameleon. Comput. Decis., (Aug 1988), 82-84.
 Moskowitz, R. A. IBM's grand design. Comput. Decis., (Apr. 1985), 82-90.
 Moulton, J. OSI: An open door for systems intergrators. Mini-Micro Syst., (Oct. 1988), 80-89.
 Pickens, J. R. Which way is SNA going? Comput. Decis., (Jan. 1987), 45-46.
 Robinson, T. Hancock reaffirms IBM comm strategy. MIS Week, (Feb. 1989), 15, 19.
 Routt, T. J. SNA network management: What makes IBM'S Netview tick? Data Commun., (June 1988), 203-277.
 Routt, T. J. SNA to OSI: IBM building upper-level gateways. Data Commun., (May 1987), 120-142.
 Software links IBM micros, mainframes over Tymnet. TPT, (Dec. 1988), 47.
 Stix, G. Heeding a call to distribute. Comput. Decis., (Jan. 1987), 24-28.
 Valovic, T. An interview with George Colony. Telecommun., (Apr. 1988), 38-47.
 Walsh, M. SNA has arrived. Now let's help SAA. Infosyst., (Mar. 1988), 60-61.
 Wood L. Where IBM reigns: The front-end market. Datamation, (Nov. 1987), 105-112.
CR Categories and Subject Descriptions: C.2.0 [Computer-Communication Networks]: General
Additional Key Words and Phrases: Bridges, brouters, gateways, interoperability, Open Systems Interconnection, Systems Network Architecture, X.25 packet-switched networks
ABOUT THE AUTHORS:
MATTHEW A. TILLMAN is currently a staff consultant at Andersen Consulting, Arthur Andersen & Company. His research interests include telecommunications, expert systems, and database. Author's Present Address: Arthur Andersen & Co., 1666 K. Street, Washington, D. C. 20006.
DAVID (CHI-CHUNG) YEN is currently an associate professor of MIS of the Department of Decision Sciences at Miami University, Oxford Ohio. His reseach interests include telecommunications, expert systems, database, and system analysis and design. Author's Present Address: Department of Decision Sciences, Miami University, Oxford, OH. 45056.
|Printer friendly Cite/link Email Feedback|
|Title Annotation:||Systems Network Architecture, Open Systems Interconnection|
|Author:||Tillman, Matthew A.; Yen, David (Chi-Chung)|
|Publication:||Communications of the ACM|
|Date:||Feb 1, 1990|
|Previous Article:||Post implementation evaluation of computer-based information systems: current practices.|
|Next Article:||N-fold inspection: a requirements analysis technique.|