~ Introduction toSNA
SNA TODAY AND TOMORROW
The evolution of SNA has already allowed it to support increasingly com-plex networks; this trend is expected to continue well into this decade (see Figure 6-4). First-generation SNA networks were simple, hierarchical, mainframe-controlled communications networks; later multisystem network-ing facility enhancements supported distributed networks of IBM mainframes.
Current SNA networks can support interconnection of remote computing systems to these networks, using multiple communications channels with alternate routing. The evolution of SNA has mainly provided the software tools that support communications in these complex networks. Emphasis is now shifting toward providing tools to assist programmers in developing distributed processing and data base systems while insulating them from the problems of coordinating operations among several computer systems. IBM is now identifying application-to-application services as part of the network-addressable unit services layer, the highest described in current SNA product literature. These services allow application programs to communicate without concern for the details of the network; in some cases, an application program will be allowed to access a data base without knowing its location in the network. Such capabilities are provided through enhancements to SNA's ap-plication interface and support programs (e.g., CICS/vS, IMS/VS).
Network Operations Management
Network operations management has also evolved significantly. Current SNA software products assist in managing complex SNA networks, helping to:
• Control daily operations
• Identify data transmission problems
• Measure and report network performance
• Track the resolution of network problems
• Coordinate implementation of network changes
These products must be viewed as the first step toward centralized network operations control. Much remains to be done, particularly in the area of identifying and isolating data transmission problems, before true network operations management is achieved.
IBM 370 370x
Other Domains
Remote Batch IBM 3770
Domain 1
IBM 370 303x
Domain 2
MSNF/ACFIVTAM MSNF/ACF/TCAM
IBM 8775 Domain 3 Current SNA Networks
Figure 6-4. (cont)
Domain 4
o
~>
8
3:3: c
z 6
~
o
z
UJI
m 3: mz
-IReference Model
The International Standards Organization proposed its Open Systems Inter-connection reference model for a telecommunications system architecture, with the goal of making such systems compatible. Because of its architectuml similarity to this model, SNA can be adapted to conform to the proposed standards (see Figure 6-5). The lower levels of the OSI architecture, for example, map directly into SNA, and SDLC is a subset of the OSI link-control-level HDLC protocol. Conforming to the architectuml model will not necessar-ily eliminate the difficulty of telecommunications system compatibility. Inter-faces with adjacent and/or equivalent levels must be explicitly and clearly defined to ensure true compatibility. A considerable amount of work must be completed to define the interfaces in both hardware and software.
CCITTX.25
The CCITT X.25 recommendation for the interface to packet-switched networks implements the first three levels of the OSI model. Although X.25 and SNA have similar features (both can use the V.24 interface for the physical control layer and a bit-synchronous protocol for the link control layer), direct
7
6
5
4
3
2
OSI Model Application
Presentation
Session Transport End-to-End Control Network
{
Link Physical - Ad"acent La er y s(levels)
SNA (circa 1980) End User
Presentation Transportation and Data Flow
Path Control
Link
Physical
L--- EqUivalent Layers (levels)
Figure 6·5. ISO OSI/SNA Comparison
compatibility does not exist. The incompatibilities arise in part because X.25 is a 3-layer interface between data terminal equipment (OTE) and a packet network, while SNA ensures information exchange in six architectural layers between two ends of a network (e.g., two OTEs or an application program and a terminal). mM does provide (as a separate unit) an X.25-to-SNA interface that maps SNA links into X.25 virtual circuits at the network layer (Layer 3) and uses a link access procedure (LAP) variation of the HOLC protocol for the link control layer (Layer 2). The V.24 interface is used for the physical layer (Layer 1). As both X.25 and SNA mature, this interface will change as well, with the link access procedure balanced (LAPB) and the X.21 physical interface likely to be used in Layers 2 and 1, respectively.
CONCLUSION
mM's SNA represents the comprehensive and cohesive approach of the world's largest mainframe manufacturer to the design and implementation of teleprocessing and distributed OP networks. SNA supports the construction of large and expensive networks; the cost of implementation (with its increased resource requirements) keeps many of SNA's technically advanced features beyond the reach of small- and medium-sized OP installations. Regardless of installation size, however, SNA will still provide some benefits. For example, data transmission using SOLC is more efficient than it is using BSC. In addition, mM's commitment to the continuing evolution of SNA will cause many users to add SNA products selectively to their mM-mainframe-based networks; few will totally embrace SNA.
SNA's translation from design to hardware and software products is still incomplete and in many cases leaves much to be desired in performance and simplicity. Although many SNA products complexities may be unwarranted, mM has the ability and apparently the desire to correct these design and implementation deficiencies. As SNA matures and continues to evolve, its current problems will likely be replaced by new problems. With any problem, old or new, users have a choice: to correct the problem through modifications to mM equipment (or other means) or to await a solution from mM.
Several management strategies, such as the following, can be pursued when upgrading an existing system or building and implementing a new distributed system.
Strategy 1. This strategy involves using all mM SNA components for the system and AT&T channels for communications. This is a good strategy for a new application and system; however, for upgrading an existing system, whether mM or non-mM based, it can be expensive.
Strategy 2. In this strategy, the mM SNA components would be selec-tively replaced with equivalent components offered by independent manufac-turers, thus providing increased performance, reduced cost, and greater reli-ability. mM components would be retained only if no suitable replacements could be found. This is a difficult strategy for implementing a new system and
upgrading a non-IBM-based system; it is a good strategy for users upgrading an existing IBM-based system.
Strategy 3. No IBM equipment is used in this strategy; implementation uses a minicomputer manufacturer's architecture. This is a good strategy for a new system and for a non-IBM system upgrade; it is possible to use it for upgrading an IBM-based system.
Strategy 4. This involves doing nothing but waiting. As a strategy for a new application and system, it is bad; it is, however, a possible strategy for upgrading both IBM- and non-IBM-based systems.
Depending upon the user and the environment, one of these strategies may prove best in terms of cost, performance, ease of use, and reliability.
I I I
I I I I
I I I I
I I I I I