Marrying SNA Data with TCP/IP
As the development of TCP/IP continues to progress, the technology grows as an appealing protocol to handle more and more network traffic. Understanding this shifting network topography, Bay Networks (Santa Clara, Calif.) has devised a strategy to help businesses migrate to an IP backbone while preserving investments in existing SNA technology.
Businesses maintain huge investments in legacy code, and yet about 60 percent of all midrange and mainframe systems today ship with, and rely upon, IP, according to Don McGinley, senior product manager of SNA for Bay Networks, a Northern Telecom company. Based upon SNA’s capacity to continue producing at a high level of reliability, availability and serviceability (RAS) and the ease with which enterprises can migrate to an IP backbone using Data Link Switching (DLSw), Bay has developed a strategy for converging SNA and IP, he says.
DLSw allows for the termination of SNA sessions at the access device, encapsulation of SNA data into TCP/IP packets and transmission on TCP/IP connections over a WAN. Despite the encapsulation process, SNA over IP (SNAoIP) actually achieves a quicker response time due to priority queuing, according to McGinley. "The replacement of leased lines with higher-performing pipe, which allow for greater bandwidth, also contributes to the faster response time," he says.
The initial phase of Bay Networks’ strategy for transporting mission-critical SNA data over TCP/IP, announced in mid-September, facilitates migration to IP backbones while ensuring that SNA traffic maintains "uncompromised levels of [RAS]," McGinley says.
The first phase of the SNAoIP strategy features RSVP for DLSw, APPN/boundary function for DLSw, IP Multicast with DLSw and backup peers. A priority queuing feature is expected to be available next year. Still another feature – high performance routing over IP – has no scheduled release date at this time.
RSVP for DLSw addresses end-to-end quality of service (QoS), according to McGinley. This feature allows network administrators to reserve bandwidth based on time of day, by device or at system start-up for SNA/DLSw traffic across an IP backbone.
APPN/boundary function for DLSw addresses IP convergence, allowing users to traverse an IP network while still having access to enterprise level applications via an APPN/HPR (High Performance Routing) backbone network. DLSw traffic is terminated within the router, allowing a single DLSw/APPN network to exist.
IP multicast with DLSw reduces network traffic as companies migrate away from point-to-point peer configuration. This feature is designed to improve performance while eliminating overhead.
Backup peers helps ensure redundancy for mission-critical applications, guaranteeing session availability by providing secondary communications paths, where sessions are automatically transferred to a designated backup peer – for example, a dial backup connection.
Though a large portion of Bay’s efforts are directed at mainframe, McGinley is quick to acknowledge the AS/400 as an important mission-critical platform. "The AS/400 is one of the most open systems on the face of the earth, based upon the number of applications available," he says.
SNA and IP have evolved over the years, according to Jim Markov, senior product marketing manager at Northern Telecom (Nortel). "Although SNA met with much success more quickly in its history as an enterprise protocol, IP has grown slowly, but with a much broader potential user base," he says. The simultaneous maturation of SNA and IP has led to the emergence of parallel networks, where the two protocols work side-by-side. Though these networks will eventually migrate to IP, SNA’s reliability will enable it to remain a factor for many years to come.
"Everyone is looking for a way to marry their SNA and TCP/IP networks," agrees Deb Mielke, a director with TeleChoice (Boston). "People will end up having native IP networks," she predicts, adding that reduced costs will play a major role in IP’s continued development. "It’s too expensive to run both."