|
|
|
| Home | Products & services | Support & downloads | My account | ||
|
| ||
 |
IBM networking experts answer questions about HPR and its industry acceptance
In fact, HPR has been generally available for over three years and is already successfully deployed in many company networks. A panel of networking experts from IBM recently addressed the issues raised in the article, and their responses follow. Q: Have customers successfully deployed HPR technology in production networks? A: A number of large IBM customers have already deployed HPR networks—iT-AUSTRIA and GAD, for example. Another customer spoke at the SHARE conference and at the Networking Systems Technical Conference (NSTC) more than a year ago about its positive experiences with a production HPR network. Today, companies are migrating SNA networks towards HPR because IBM hardware and software products allow sessions to cross networks that contain a combination of subarea, APPN, and HPR nodes and links. Many configurations—including SNA Network Interconnect (SNI) configurations—enable sessions to traverse subarea networks and then directly utilize HPR nodes and links. In some networks, sessions traverse a combination of APPN, HPR, and subarea connections. And planned future enhancements to OS/390 will allow the routing of SNI traffic directly to HPR-only connections through a gateway VTAM®. IBM customers are currently using HPR with ARB flow control in high-availability, high-performance networks. As deployment of HPR continues in networks with a wide variety of configurations, data link controls, and new technologies such as Enterprise Extender, IBM is enhancing ARB to better support these evolving environments. In fact, the design of a new algorithm has already been proposed to the AIW. Q: What are the facts about ARB congestion control and the proposal that was recently presented at the AIW? A: The specific AIW submission is called Responsive Mode ARB. This is an improved algorithm designed to work with Enterprise Extender, the IBM technology that allows HPR data to flow over an IP network. An evolutionary enhancement to HPR, Responsive Mode ARB addresses environments in which SNA and IP share bandwidth on the same backbone. It was developed by IBM with the help of Data Connection Ltd. (DCL), a leading supplier of core system software to major vendors in the networking industry. Some people have misinterpreted the fact that the AIW did not approve the submission immediately. Historically, it is rare for new proposals to be approved by the AIW on initial submission. AIW rules require a period of time for members to have a reasonable chance to review any new submission for standardization. Proposals that are clearly trivial can get immediate approval. Since the AIW meeting in September of 1998, Responsive Mode ARB has received "Approved Direction" status—the first step on the road to standardization. This means that all AIW members agree on the requirements and on the direction for addressing them. In addition, Responsive Mode ARB has been thoroughly and successfully tested for interoperability and performance among Communications Server for both OS/390 and Windows NT®, the IBM 2210 Nways™ Multiprotocol Router, the 2216 Nways Multiaccess Connector, and networking software from DCL. Responsive Mode ARB is included in all of these products as part of the IBM Enterprise Extender function. Enterprise Extender was shipped disabled with OS/390 Version 2.6 in September 1998, so that IBM could investigate and correct an anomaly discovered during final testing. Because the problem was identified and corrected, a PTF was made available on December 31, 1998—enabling full Enterprise Extender function in OS/390 2.6. Enterprise Extender is already available in the 2210 router, in the 2216 connector, and in Communications Server for Windows NT. To summarize, ARB is not "broken" either in architecture or in IBM product implementations. It is meeting its objectives very well, as is the rest of the Enterprise Extender technology. Q: What testing has been done to ensure the scalability and performance of HPR in large networks? A: IBM has tested configurations with a large number of HPR connections, sometimes referred to as RTP connections. For the initial HPR release (VTAM Version 4.3), HPR performance was successfully tested with 1,000 RTP connections. IBM's design and performance group carefully analyzed the behavior of key scalability factors such as CPU utilization, timer support, and storage utilization. They were pleased to find that the behavior for these factors in the HPR tests was very similar to the results of earlier APPN/VTAM tests that successfully benchmarked tens of thousands of connections. The test team concluded that HPR scalability should be on par with that of APPN/VTAM, which is known to be excellent. Moreover, IBM customers are currently running single OS/390 systems that support large numbers of HPR connections in their production environments. Thus far, HPR has been stress-tested extensively both in IBM's labs and in IBM customers’ production environments, with no apparent scaling problems. Current customer experiences—as well as IBM testing and modeling—clearly demonstrate that HPR can improve performance and availability for customer networks today. The current feature set is ideally suited for most customer environments, and new features such as Responsive Mode ARB and Enterprise Extender demonstrate IBM's continued commitment to evolve HPR to additional user environments. For More Information
Visit: |
|
|
TECHNOLOGY: IBM SETS THE RECORD STRAIGHT ON HPR
Claims made by a non-IBM source in a recent article—in which network owners were advised to delay deployment of High-Performance Routing (HPR) technology—were a reaction to an IBM submission to the APPN Implementers Workshop (AIW) in September of 1998 for additional improvements to HPR. The article in question contains a number of misstatements about HPR—claiming, for example, that the Adaptive Rate-Based (ARB) congestion-control algorithm is broken, that Enterprise Extender function is not currently available, that companies cannot deploy combined HPR/subarea networks, and that insufficient testing has been done.
