CQ Support
tech@cq-comm.com
| |
|
|||
| |
CQ Support |
|||
| |
|
|||
| Productivity Connectivity Security | |
|||
| |
|
|||
|
|
|
Support Contact CQ About CQ Order | ||
| |
|
|||
| Check out CQ's Enterprise Extender solutions - CQ-3770EE®. and CQ-3270EE®. These new solutions allow SNA communications over existing IP connections through IBM's Enterprise Extender technology for the ultimate in convenient and reliable SNA connectivity. |
This technical overview discusses the Enterprise Extender (EE) technology and how it relates to the transmission of SNA data over IP networks. This overview looks at how SNA networks exist today, in what ways they can be tailored in order to be used in the future, and how the Enterprise Extender technology can be used in this endeavor.
SNA NetworksSystems Network Architecture (SNA) networks are still in place and in use today. These SNA networks were implemented decades ago and remain mission-critical components of the organizations that use them. However, more and more each year it is becoming increasingly difficult for these organizations to support and maintain their SNA networks and systems.
One reason that it is difficult to maintain SNA networks is a lack of personnel to support the applications and equipment that are a part of the SNA system. The knowledge, skills, and technical expertise that are required to manage SNA networks as they exist today is becoming increasingly scarce.
Another reason is that key SNA networking equipment has been discontinued or is now not supported. For example, the IBM 3745 and 3746 Controllers (also known as Front End Processors) form the backbone of many mission critical SNA networks by allowing remote SNA clients to connect to mainframe computers. These FEPs were withdrawn from marketing by IBM effective September 27, 2002. Since that date, only used FEP products and features have been available.
IBM states that the reason that the controllers were withdrawn from marketing is the success of IP in corporate networks. In the IBM Announcement Letter dated February 26, 2002, IBM stated that the "explosive growth of the Internet and TCP/IP traffic have resulted in a severe decline in the demand for new 3745 and 3746 Communication Controllers." In fact, it is widely accepted that IP is the strategic networking protocol of the future. IP has been around since 1969 so it is well established and also offers features such as scalability, redundancy, resiliency, openness, adaptability, and manageability.
The reasons explained above necessitate a move from "pure" SNA into a form of SNA that can be integrated with today’s technology and resources.Many organizations would agree that Internet Protocol (IP) is now the networking technology of choice. Almost all new IT deployments, including those that include mainframe connectivity, are based on IP. For many years, IP networks have been run alongside SNA networks with great success. However, the solution of running two separate networks between the same two end points has led to considerable duplication with excessive administration, management, and maintenance costs between the two networks. So, this begs the question - "Why not just run SNA traffic over the existing IP networks?". After all, there are several advantages to integrating SNA networks into existing IP networks.
The first advantage has already been explained in the previous paragraph. This advantage is that IP is the network of choice for today’s networking and communications projects so it is well supported and well maintained. There is an abundance of IP equipment that is available and that is constantly being updated to meet today’s high-speed standards. For example, through the use of the OSA-Express adapter at the mainframe end, extremely high-speeds can be achieved that otherwise would not be available over a "pure" SNA connection.
A second advantage, also previously explained, is the simplification of the network by integrating the SNA network into IP. By eliminating many of the SNA network components, there is no redundancy costs associated with the upkeep of two networks.
For many years, SNA over IP was not a possibility. Now that we’ve decided that running SNA traffic over IP is a good idea, how do we accomplish this? As a transition for SNA users, IBM developed an IP transport technology called Enterprise Extender (EE). EE allows remote SNA clients to continue to communicate with mainframes over existing IP networks in much the same way as they do over SNA Networks.
With the implementation of EE on the mainframe, remote clients can now transmit SNA traffic over their existing IP networks! EE allows for the use of SNA transport protocols (namely APPN and HPR) over an IP network. EE enables the leveraging of IP-based infrastructure network components for use in delivering SNA traffic.
The Enterprise Extender architecture carries SNA (HPR) traffic of any LU type over an IP infrastructure, without requiring changes to that infrastructure. EE essentially treats the IP network as a particular type of SNA logical connection. In this manner, these SNA protocols act as transport protocols on top of IP, as does any other transport protocol such as Transmission Control Protocol (TCP).
Enterprise Extender combines the features of SNA and IP to offer the best of both worlds when running SNA traffic over an IP backbone. Some of the advantages that the EE solution offers to its users are listed in this section.
The use of Enterprise Extender allows you to avoid costly application rewrites by providing a means of IP-enabling SNA applications (such as RJE) that cannot be migrated to "pure" IP. That is, EE allows the continued use of native SNA applications over a different network: the IP network. This allows you to eliminate the SNA infrastructure altogether. The ultimate result is the convergence to a single network infrastructure that carries both IP and SNA application data.
Enterprise Extender has been designed to run over existing IP networks without requiring any change to applications or to IP routers. SNA applications see the same SNA network interfaces as before, whereas IP routers continue to see the same IP (UDP) packets.
TCP/IP and HPR both provide their own unique, network-specific mechanisms for flow and congestion control. TCP uses a windowed technique, whereas HPR uses a technique based on data rate. Enterprise Extender introduced a new variant of the HPR flow control method known as responsive mode adaptive rate-based (ARB) flow control. Responsive mode ARB, like basic mode ARB, is designed to prevent network congestion; however, unlike basic mode ARB, it can also ensure a fair division of network capacity between the four SNA priorities and native IP traffic.
One of the biggest issues facing those who wish to transport SNA over an IP network is the question of maintaining SNA’s class of service. In SNA, the class of service specified for a particular session is used to determine both the route taken by the session and the transmission priority allotted to it.
With an IP backbone, the route is essentially unpredictable because of IP’s connectionless property. However, IP provides for a transmission priority using the precedence bits in the IP header. Many routers now support the use of these bits, but in the past they have tended to use the TCP or UDP port number as a means of assigning priorities to packets.
Enterprise Extender supports the use of both the precedence bits and the port numbers to inform the IP network of the transmission priority. Use of the precedence bits is recommended because the UDP or TCP port numbers are carried inside the IP datagram, whereas the precedence bits are in the IP header. Thus, encrypted packets have unreadable port numbers and fragmented packets have no port numbers, after the first fragment. For such encrypted or fragmented packets, intermediate routers cannot determine the appropriate priority.
TCP/IP has always had the ability to reroute packets around failing components, without disrupting the connection, by means of the connectionless property of IP. More recently SNA has implemented the same function, albeit in a rather different fashion. The high-performance routing (HPR) extension to SNA is connection-oriented as SNA has always been, but when it detects a failure, it will move an existing connection around a failing component. The use of HPR transport over an IP network provides non-disruptive rerouting around failed network components using either IP or HPR methods, depending on the location of the failure.
HPR consists of the following layers:
Enterprise Extender provides SNA users with a seamless transition to SNA over IP that is both optimal in reducing network complexity and cost while also providing strategic advantages as a sustainable long-term solution that is adaptable with the changes in the future.
CQ’s newest solutions - CQ-3770EE® and CQ-3270EE® - provide SNA connectivity over IP connections through the Enterprise Extender (EE) technology. The CQ-EE™ solution is also available as a customized solution for one of CQ's clients. For specific information on this solution, please contact CQ.