Frame Relay Applications: Novell IPX & IBM SNA - Page 3

 By Cisco Press
Page 3 of 5   |  Back to Page 1
Print Article

Frame Relay and the IBM SNA Suite
IBM mainframes and SNA were the de facto standard of the networking community for many years, predominantly in the 1970s and 1980s. IP has since replaced SNA as the dominant internetworking protocol suite. SNA is still very much "at large," especially in large legacy networking systems, such as those found within the banking and financial industries.

These IBM SNA networking environments were ideally suited to the internetworking environment enabled by Frame Relay network implementations due to the lower-cost and cleaner architecture, compared to that of traditional point-to-point private line interconnections. Whereas point-to-point network architecture requires several lines and interfaces, Frame Relay networks enable a single line (serial interface) and multiple subinterfaces, one for each SNA communication session (Frame Relay VC).

Migration of a legacy SNA network from a point-to-point infrastructure to a more economical and manageable Frame Relay infrastructure is attractive; however, some challenges exist when SNA traffic is sent across Frame Relay connections. IBM SNA was designed to operate across reliable communication links that supported predictable response times. The challenge that arises with Frame Relay network implementations is that Frame Relay service tends to have unpredictable and variable response times, for which SNA was not designed to interoperate or able to manage within its traditional design.

NOTE:   Migration from SDLC to Frame Relay networking environments will require an upgrade to the communications software packages in both the FEPs and SNA controllers.

Typically, SNA controllers, routers, and FRADs encapsulate SNA traffic as multiprotocol data, as described in the Frame Relay Forum's FRF 3.1 Implementation Agreement.

Traditional IBM SNA Network Configuration
Figure 15-22 illustrates a traditional IBM SNA network configuration.

Figure 15-22: Traditional IBM SNA Network Configuration
Click image for larger view in a new window
(Click image for larger view in a new window)

An SNA network has two primary components:

  • Front-end processors (FEPs)--FEPs offload the coordination effort required to enable and support communication between IBM hosts and (potentially) thousands of remote devices.
  • Remote controllers--Remote controllers are located at remote locations and are used to interconnect LANs and low-bandwidth (typically 9.6 kbps or 56 kbps) leased lines. Remote controllers concentrate several sources of remote traffic onto one high bandwidth connection to the front-end processor.
IBM's SNA environment supports the implementation of multidrop technology, making multipoint leased line configurations more cost effective versus each SNA drop possessing its own leased line. In the multidrop environment, several devices share the same leased line with the front-end processor or remote controller, polling these devices and allowing each device a turn to communicate with the mainframe.

The IBM SNA environment relies heavily upon the FEP's polling mechanisms because the FEP controls when each of its connected remote devices can send and receive data. The SNA infrastructure is based on this polling methodology.

When the FEP polls the remote device, it expects to see a response within a preconfigured timeout period. This timeout threshold is typically a fairly small period of time, generally a few seconds. If the timeout period expires, the poll is retransmitted. Frame discards and late frame arrivals (usually caused by network congestion) can disrupt SNA communication.

Figure 15-23 illustrates a Frame Relay implementation, replacing point-to-point leased lines, supporting an IBM SNA infrastructure.

Figure 15-23: IBM SNA Implementation over Frame Relay
Click image for larger view in a new window
(Click image for larger view in a new window)

This article was originally published on Feb 1, 2002
Get the Latest Scoop with Networking Update Newsletter