Over its evolution, mainframe access has changed substantially from the dumb terminal (3270) and cluster controller days. Gateways once provided the connections between PCs and the mainframe, allowing corporations to remove the dumb terminals from the desktop. As this technology evolved, companies began providing gateway services through Web browsers to reduce the costs and maintenance associated with client installations. The mainframe administrator would create a sysgen, or system generation macro. This defined the Token Ring gateway as a switched major node. Depending on the configuration, the gateway could be configured as a PU Type 2 device or as an LU.

In addition, software and hardware for the PC also allowed the elimination of the gateway—the PC could directly connect to the host. While this added administration tasks for the administrator, it also improved the performance of the 3270 connection—the gateway and the necessary conversions were no longer a bottleneck. This solution was better suited for advanced users with a demand for more complex services than the gateway and thin-client approach. Many companies (who have not converted to TCP/ IP-based hosts) still provide gateway services, which are a suitable compromise for the majority of users, providing reasonable performance with simplified client administration.

As SNA evolved, numerous protocols have been developed to transport it across modern networks. These technologies include SDLC tunneling (STUN, or serial tunneling), remote source-route bridging, data-link switching, and SDLC-to-LLC2 conversions. LLC2 stands for Logical Link Control, version 2, and is a common framing transport. In addition, Cisco has announced a new technology—SNASw (Systems Network Architecture Switching Services). This continuing development toward support for SNA is a likely indication that the protocol will remain significant in the near term.

	It is important to remember that SNA is not a routable protocol (OSI definition), even though the term “SNA routing” is scattered throughout this text and the IBM documentation. Through the use of the Routing Information Field and other techniques, the source station can control the bridged paths used by Token Ring.

The Routing Information Field

The Routing Information Field, or RIF, is a Token Ring-specific function that allows the workstation to find a single path through the bridged network. You may recall from previous texts that there are numerous types of bridging, the most common of which is transparent bridging. Transparent bridging relies on each bridge to maintain a table showing which MAC addresses are available for each interface.

Token Ring frames provide for a field to store the path information— removing the need for the bridges in the network to store this information. Workstations (or other source devices) begin sessions by sending an explorer packet into the network. This packet is flooded throughout the network, and each bridge will append routing information to the RIF of the packet. The first packet received by the destination will be returned with the populated RIF—providing step-by-step instructions for future packets. This mechanism not only provides for routing in a bridged environment, but also can provide limited load balancing because the first packet received likely took the shortest path with the least delay.

One of the negatives of source-route bridging is the mechanism that populates the RIF. This is provided by the explorer packet, which is the flood referred to in the previous paragraph. This packet is replicated to traverse every ring in the network for each new connection between two stations. On a large network, this may result in a substantial amount of multicast traffic, and many designers rely on proxy services to populate the RIF without the need to flood the network. Proxy explorer functions are provided on Cisco routers and operate by remembering previous RIF information—the first connection to a station still floods, but all subsequent connections from that ring can use the proxy information to provide the route.

The RIF is stored in the format ring-bridge-ring, where each ring and bridge is assigned a unique number. These numbers can augment troubleshooting since the administrator can look at the RIF to help find the troublesome component.

It is important to note that Ethernet and other protocols do not support the concept of a RIF. When transiting these topologies, the network will either encapsulate the frame or rely on transparent bridging.

Network Design with SDLC Tunneling

SDLC tunneling (STUN) provides for the encapsulation of SNA traffic in three different configurations. The first is called serial direct, wherein the serial ports on the router are directly connected to local controllers. The controllers then connect to terminals. The other two configurations, HDLC and TCP/IP, are considerably more advanced than serial direct.

HDLC (High-Level Data Link Control) encapsulation is used between routers and offers the best performance for traffic over a serial connection.

The third encapsulation method uses TCP/IP to provide a reliable connection between two routers. However, this requires a substantial amount of over-head in comparison. The trade-off is that local acknowledgements are available to the designer, when so configured. Local acknowledgements effectively trick the SNA connection into thinking that the destination is on the same ring—at least in terms of performance. This prevents session timeouts and disconnects due to congested or slow WAN links, and performance is increased because the end station can transmit before the destination receives and acknowledges the frame.

A common theme in the design of SNA networks is delay and latency. At a high level, SNA cannot tolerate substantial amounts of delay—delay that poses little difficulty for other protocols. The next sections of this chapter describe ways to merge complex networks with SNA.