Branch-Based SNA Gateway Deployment

Figure 2.2 SOGA encompasses the traditional way to deploy SNA gateways in branch offices, via SDLC leased-lines and X.25 connections to the host.

The branch-based model is the traditional way to deploy SNA gateways. In a branch-based configuration, the SNA Server computers are located remotely in the branch offices near the end users. Clients use LAN protocols to communicate with a local SNA Server computer. The SNA Server computers use SNA protocols to communicate with the host systems, which are generally centrally located. In a large enterprise, host systems could reside at multiple central locations. See Figure 2 for a depiction of a traditional branch-based deployment.

Traditionally, the connection between a branch-based SNA Server computer and a host system is across SDLC leased lines. SNA gateways are often used as replacements for remote control units, such as the IBM 3174 or IBM 5294. Clearly, the trend is towards bridging and tunneling DLC across a multiprotocol LAN using DLSw, RFC 1490, or ATM. However, not all organizations are ready to rely on a single interconnected WAN supporting both SNA and non-SNA traffic. Many organizations have invested in leased SDLC lines or X.25 connections between remote and central sites. These organizations find it advantageous to continue using these SNA-only data links. In the majority of cases, the reasons for staying with SDLC and X.25 involve not only cost but also an aversion to risk. SNA Server supports SDLC and X.25 connections, making use of existing SNA infrastructure where appropriate.

Advantages of a Branch-based Strategy

There are many advantages to following a branch-based SNA gateway deployment strategy. These include a better use of limited bandwidth on dedicated SNA-only data links and WAN; a step toward migrating to a TCP/IP or other single-protocol WAN; installation and use of multipurpose server computers in branch offices; and management of host access needs locally in the branch office.

Better use of limited bandwidth on dedicated
SNA-only data links and WAN

A branch-based SNA Server computer consolidates SNA session traffic, effectively providing physical unit (PU) concentration. When compared to directly connected DLC or SDLC workstations, a branch-based approach is more cost-effective. If an organization has implemented a TCP/IP or other open WAN, then isolating the SNA traffic to traditional SNA-only links reserves the WAN bandwidth for non-SNA purposes.

A step toward migrating to a TCP/IP or other single-protocol WAN

Figure 2.3 A branch-based deployment can use an existing
or future DLSw, Frame Relay or ATM WAN.

One of the advantages of deploying an SNA gateway is to make better use of current investments in SNA data links while allowing for a migration to either a single TCP/IP or other open-protocol WAN environment. As organizations migrate towards an SNA-free wide area network, they can tunnel the SNA protocols (DLC and SDLC) from the branch office LAN to the central site LAN by deploying routers or Frame Relay Access Devices (FRADs) supporting DLSw, frame relay (RFC 1490), or ATM.

Installing and Using Multipurpose Server Computers in Branch Offices

A single Windows NT® Server computer located in a branch office can use the Windows NT Server operating system's scalability to function as a multiapplication departmental server. The branch-based server can assume a number of roles, from SNA gateway platform to file and print server. Additionally, this computer can perform duties as e-mail server, database server, systems management server, and intranet server.

Managing Host Access Needs Locally in the Branch Office

A branch-based deployment has the added benefit of locating the SNA gateways near the clients requesting the host access services. This allows for local administration of SNA Server. Local SNA Server administrators can add or remove local users as needed, often resulting in more responsiveness to users' needs than relying on a central MIS group. However, this option requires SNA-speaking administrators on-site. Fortunately, local administration of SNA Server is optional. SNA Server supports full remote configuration and management across LAN, WAN, and Windows NT Server Remote Access Service (RAS) links. This lets organizations more flexibly administer branch-based SNA gateways using local or remote personnel.

Disadvantages of a Branch-based Strategy

The disadvantages of following a branch-based SNA gateway deployment strategy including difficulty in sharing host access resources across branch offices, and inability to provide high-speed host connections.

Difficulty in Sharing Host Access Resources Across Branch Offices

It is not easy to share resources across multiple SNA Server computers unless the servers are at the same location. For example, if Branch1 and Branch2 are connected by a WAN that allows the clients to connect to remote SNA Server computers (Client1 in Branch1 can connect to SNA Server in Branch2; Client2 in Branch2 can connect to SNA Server in Branch1), then it is possible that the client startup will be slow and the WAN bandwidth will be used poorly. ..The following are some suggestions for avoiding the above problem:

SNA Client Startup. The SNA Server client-server architecture includes an application-specific name service that operates over all supported client-server transports. The client maintains a "sponsor" connection to any one SNA Server computer in the subdomain. Over the sponsor connection, it gets the names and IP addresses (or other transport-dependent address) of all the other SNA Server computers in the subdomain. Then, when the client wants to open an SNA session, it goes through the list of server addresses in random order, looking first for an active connection with available session capacity, or, failing that, session capacity on a backup connection that could be activated on demand. Also, the "other servers" optional parameter can be used to cause the client to try one or more SNA Servers located outside of the subdomain. However, this is not advisable if the WAN bandwidth cannot support client-to-server connections between branch sites. Since the client tries the servers in random order, there may be a delay during initial client session startup if there are many servers in the subdomain but only a few servers supporting the LUs being requested, or if the servers are accessed across slow-bandwidth routed or bridged networks. To minimize initial client session startup time, the number of SNA Servers in a subdomain should be limited.
Server-to-Server Communications. It is not advisable to implement an SNA Server subdomain across branch sites using slow bridges or routers. This is because multiple SNA Server computers in a single subdomain can produce server-to-server communication activity that creates unwanted traffic on the wide-area network. By implementing a branch configuration with a local subdomain for each branch, this problem is avoided. These subdomains can still be part of a larger Windows NT domain spanning multiple remote sites to allow for centralized management of user and group accounts and permissions.

Providing High-Speed Host Connections is Not an Option

With a branch-based deployment, you cannot use channel attachment options or other high-speed links to the host. A direct channel attachment is the most efficient way to connect an SNA Server computer to a mainframe. There are two channel-attachment technologies: Bus & Tag, and ESCON® (Enterprise System Connection). Bus & Tag is a copper parallel-wire attachment that runs at 4.5 megabytes per second (MBytes/sec). The maximum distance is limited to a few hundred feet; therefore, a branch-based SNA Server computer cannot use Bus & Tag. ESCON is fiber cable-based, running at 17 MBytes/sec, and can be extended to around 10 miles using standard fiber repeaters. Even in the case of ESCON, a channel attachment solution is not easily provided to a branch site. High-speed token-ring or Ethernet connections are also rare in a branch-based configuration, because of limitations in most existing SNA-over-WAN technologies. See "Integrating IBM Mainframes with TCP/IP Networks" on Microsoft's World Wide Web site at http://www.microsoft.com/sna. See also "TCP/IP Connectivity in an AS/400 Environment" on Duke Communications World Wide Web site at http://www.news400.com/Education/WhitePapers/tcpip/tcpip.htm.

Most branch-based SNA gateways employ a traditional SDLC leased-line connection. SDLC is generally limited to supporting only one PU per host adapter, providing up to 254 LUs per connection. However, in the case of DLC and channel attachment connections, multiple PUs per adapter are commonplace, supporting thousands of LUs.

Primarily because of the limitations of branch-based deployment, many organizations have moved to a centralized model. On the following pages, we will look at the advantages and disadvantages of a centralized approach.