In-Depth
SNA Applications Without SNA Networks?
Well, you're probably already asking yourself: How in the world can one have SNAapplications, yet have no SNA network? But I assure you that, yes, indeed, we can nowmaintain our SNA applications, without change, and have them interoperate over a pure IPnetwork anyone's IP network while maintaining most of the SNA qualities that we havegrown to appreciate. The beauty of what can now be done is that you can select the pointsin your network where you want SNA access points, and you can select the network designbased on your needs, and finally, you can extend the IP network all the way into the S/390itself for all of your S/390 applications, even SNA applications.
Data Link Switch The Old Way
The traditional SNA network provided SNA networking protocols from the S/390, all theway to the client machine itself. But as IP technology grew, pressures mounted to utilizeIP as a means to transport SNA protocols. Schemes such as Data Link Switch (DLSw), allowIP routers to create "pseudo connection circuits" to allow traditional SNA to becarried across IP networks. This pseudo connection is required because traditionalsub-area SNA networks assume that there is always a "heartbeat" at the data linklayer, helping to guarantee delivery of the SNA data across the link. When the hearbeatfailed, so did the connection, and the ends of the session were notified to terminate thecurrent session and re-establish it over some alternate route. In order to permit the SNAnetworks to utilize the IP transport network, the SNA network had to think that there wasa reliable connection in place, which is one of the functions that DLSw provides.
With DLSw technology, there are typically two routers involved, although in some rarecases, end stations perform one end of the DLSw function themselves. The paired DLSwpartners are responsible for creating the connection over which the SNA traffic is to becarried, and for assuring that the SNA data is delivered over this connection. Remember,that with traditional sub-area SNA networks, guaranteed delivery was assured by thenetwork itself.
While DLSw is a reliable technology for carrying traditional sub-area SNA, there aresome downsides. Two that come to mind are cost and availability. Remember, that with DLSw,I need two endpoints to provide the function. One of these typically resides in a branchrouter, and the other is located in the datacenter, typically alongside a controller, or achannel attached router doing SNA function. In most larger corporations, there are many ofthese datacenter routers doing nothing more than DLSw "catching" for branchrouters. These routers are typically high-capacity routers to provide the neededprocessing power for DLSw. In many networks, the controller is retained in theconfiguration because it provides the needed routing for traditional sub-area SNA tocontinue to be delivered into the S/390. The combination of the multiple communicationsboxes required in this case results in an increased equipment and operations cost, as wellas providing an undesirable single point of failure within the network.
DLSw is not implemented on the S/390 itself, therefore there is no means to eliminatethe datacenter DLSw router and eliminate that single point of failure. What is needed issome means to enable end-to-end high availability, and reduce the cost for maintaining theSNA apps by enabling a single network transport to be used end to end for allapplications, while enabling the high availability desired for the S/390 applications.Enterprise Extender technology provides that answer.
Parallel Sysplex The Driver of Change
As we roll out parallel sysplex, most of us are also performing a conversion ormigration from sub-area SNA to Advanced Peer- to-Peer Networking (APPN), or morespecifically to High Performance Routing (HPR).
HPR is what many people call new SNA. It provides the ability to have non-disruptivehighly efficient SNA sessions. That means that when there is a failure anywhere betweenthe endpoints of the HPR connection, there is no longer a session failure occurrence aswould have typically been the case with sub-area SNA.
HPR enables this radical change in SNA session characteristics by a very simple changein the underlying operation of SNA. Instead of requiring that there be a connection at thelink layer assuring delivery of the SNA data, HPR moves this function to the ends of theHPR connection. The ends of the connection monitor the data being sent, and if the data isnot delivered for some reason, the endpoints retransmit the missing data. Unlike thetraditional SNA model which had many link layer connections coupled to assure anend-to-end delivery, HPR eliminates these link layer connections, replacing them with asingle end-to-end logical connection, which may or may not traverse intermediatenetworking boxes. At the data link layer, HPR operates in a stateless manner, withintermediate HPR nodes being unaware of sessions, simply acting as SNA packet forwardingagents. HPR can be implemented just with the S/390 parallel sysplex, but its true value isnot recognized unless it is rolled out at least to the data center networking boxes.
Enterprise Extender The Marriage of SNA and IP
IBM's new Enterprise Extender allows the transmission of SNA data across an IP networkusing native IP transport protocols. To be more technically accurate, the SNA (HPR)packets are transmitted across the IP network using User Datagram Protocol (UDP) packets.As most of you are aware, UDP does not assure delivery of data; but SNA requiresguaranteed delivery. That is where the HPR protocol comes into play. HPR assures that theSNA data is delivered across the IP network. If HPR detects that the data was notdelivered, it simply retransmits the failing packets.
UDP was selected as the transport format because UDP packets contain port numbers and aType of Service indicator. Enterprise Extender enables one to map the four SNAtransmission priorities into four unique port numbers, enabling port number prioritizationby the IP routers. As IP Type of Service (TOS) implementations become more prevalent,Enterprise Extender enables SNA transmission priorities to be mapped to TOS settings, aswell.
Congestion control for the Enterprise Extender transmitted data is also provided byHPR. The HPR Adaptive Rate-Based (ARB) algorithm has been enhanced to provide improvedcontrol for IP networks. The algorithms monitor the end-to-end data transmission rateregulating the transmission of data into the network, minimizing the need to retransmitdata while maximizing the throughput rate.
Where Is It Implemented?
IBM has implemented the technology on many of its networking hardware products, and ispoised to ship the technology on its software products, including eNetwork CommunicationsServer for OS/390, NT, and more. IBM has also opened the technology to the industrythrough the APPN Implementor's Workshop (AIW) and through the IETF Request for Comments(RFC) process with RFC 2353 High Performance Routing over IP Networks. The text of theRFC can be located at http://info.internet.isi.edu:80/in-notes/rfc/files/rfc2353.txt.
And other leading networking vendors indicate that implementations can be expected fromthem as well.
So Why Change?
With Enterprise Extender being available on the S/390 with OS/390 Version 2 Release 6,with an enabling PTF, you now can have a pure IP transport, end to end at the networklevel. Every data packet that is transmitted from the S/390 can be an IP packet, whetherthe application is an SNA application or a TCP application. From an HPR networkperspective, your HPR network complexity is eliminated. While you can design and implementnetworks that just use Enterprise Extender technology within the wide area network,without extending it into the S/390, the true value comes when you implement thetechnology within the S/390 as well.
For example, with Enterprise Extender one can now have two SNA applications located indifferent datacenters, even different networks, communicate with each other using IP asthe transport between the S/390 images. No longer is there a requirement for SNA NetworkInterconnect (SNI) in order for these applications to communicate. Instead HPR Border Nodecapability can be used with the S/390 to interconnect the two networks, with IP being usedas the transport protocol. From the network point of view, there is no SNA an awarenessof SNA exists only on the S/390 processors that own the applications. The applicationsthemselves do not change even in the slightest. They are totally unaware that the networkhas not become an IP network.
Enterprise Extender can also be used from the S/390 in support of dependent LUs,whether these LUs are actually SNA LUs or TN3270 devices supported through a TN3270server. The only requirement is that the Dependent LU Requester function is used toprovide access for these devices to the Enterprise Extender portion of the network. If onelooks at many of today's networks, they consist of TN3270 clients communicating with anoutboard TN3270 server. The communications from the outboard TN3270 server to the SNAapplication is over a SNA network. With Enterprise Extender, one can replace the SNAcommunications between the TN3270 server and the SNA application with an EnterpriseExtender connection. Now, end to end, IP will be used for the communications protocol andfull support is enabled for the parallel sysplex functions desired for SNA applications.
For older SNA devices located within the network that cannot easily be upgraded, eitherthe Dependent LU Requester function can be colocated near the device much as is done withDLSw routers today, with Enterprise Extender used from the DLUR to the SNA application, orDLSw can be maintained for the device to carry the SNA traffic over IP to a morecentralized DLUR perhaps located in the datacenter.
Enterprise Extender also can provide a simplification of the SNA network design byreducing or even eliminating the SNA nodes on a given session path. Realize that a givenHPR-capable IP-enabled router within the network can provide services as an HPR node forcases where it must present an HPR awareness like when it provides DLUR function, while atthe same time it can act as an IP router for downstream nodes.
From an HPR perspective, the downstream HPR node may not even have an awareness thatthis node exists on the session path by simply using Enterprise Extender to select an IPconnection through this router. The logical HPR connection may be a single hop from theSNA perspective from the remote router all the way into the S/390, but actually it maytraverse any number of IP routers (which may also be HPR-enabled) as intermediate nodes.Your SNA network is simplified because your SNA "links" are really virtual linksacross an IP network. If a failure occurs along the session path, IP will attempt toreroute the packet through alternate routers, and if that fails, then HPR at the endpointsof the session will attempt to select another SNA link (physical or logical) over which tosend the data using the non-disruptive session switch capability of HPR.
Return on Investment
While enabling the full utilization of SNA applications, without change, across an IPnetwork is of significant value, the ability to take advantage of future enhancements toyou IP network by all applications has to be the upmost value.
As IP continues to mature as a networking technology, through technologies, such asQuality of Service enablement, new IP switching and routing enhancements, whatever yourSNA applications will keep chugging along without any need to rewrite them yes,finally, there truly is a free lunch!
About the Author:
Jim Fletcher is responsible of the development of networking technologies for theS/390 Enterprise Server at IBM Networking Software Products, Technology and Strategy. Hecan be reached at (919) 254-5929 or via e-mail at fletchj@us.ibm.com.
To Sidebar