RSS
|
||||||||||||||||
  ATM WANs: Cornering the Market on Wide Area Data April 19, 1999
The name of the game is connectivity. And for high-performance networks that increase available bandwidth without breaking the bank, ATM has long been recognized as a solid choice. The technology is built on the promise of QoS (Quality of Service) and support for voice, video and data--and, when used in the right environment, ATM has delivered. Not only have large corporations bought into ATM for enterprise solutions, but in 1995, the National Science Foundation sponsored the very-high-speed Backbone Network Service (vBNS) to interconnect the U.S. research and education communities. Implemented and operated by MCI, vBNS has successfully provided IPv4 transport services over an OC-12 ATM backbone connecting 11 POP (points of presence) and serving 71 site connections. Recently, the NSF raised the stakes. In 1997, it issued a request for solutions that could extend the interconnectivity of vBNS over the Internet to international research and education networks, such as APAN (Asian Pacific Advanced Network), whose members include Australia, Hong Kong, Indonesia, Japan, Korea, Malaysia, Singapore and Thailand (www.apan.net). In October 1998, the NSF formally approved a proposal from Indiana University (see "Network Operations Organizational Structure," page 78). Work on that trans-Pacific link began many months in advance of that approval, however, and is now largely completed. As members of an Indiana University team that helped design and build that network, we joined forces with groups from Ameritech Advanced Data Services, Argonne National Labs, APAN, AT&T, Australian National University, Japan Science and Technology Corp., Kokusai Denshin Denwa (KDD), Korea Telecom, Korea Advanced Institute for Science and Technology, and the National University of Singapore to construct the ATM WAN that extended from Chicago to Tokyo. And while it might seem that building a global network should be as simple as connecting switches and routers over the Internet, building the actual ATM WAN connection was fraught with obstacles, not the least of which was overcoming differences of time, distance and language. For example, teams from AT&T and KDD completed the first round of circuit testing in July and, after proclaiming the link clean, handed the process over to us. Much to our dismay, we experienced extreme packet loss during ping tests between the routers at each end of the link. We reasoned that the problem must lie in our equipment and/or its configuration. We checked whether the routers were shaping traffic more loosely than the telco service expected, forcing the telco traffic-policing mechanism to drop cells. This was not the culprit. And we ruled out the possibility that IP-over-ATM encapsulation was set differently at the ends of the link (aal5snap versus vcmux), but we were getting closer. We eventually discovered that payload scrambling was enabled on one side of the local DS-3 link and disabled on the other side. However, despite resolving this problem, we still encountered a 1 percent to 2 percent packet loss. Using router-to-router pings, we narrowed the packet loss to the vBNS router that interconnects the trans-Pacific network infrastructure and Indiana University. The university was connected via a VC (Virtual Circuit) on one interface while the trans-Pacific network was similarly connected but to a different interface. When MCI moved the connections to the same interface, the problem evaporated, but as of this writing we were still trying to figure out why the old configuration didn't work. Since many of the challenges we faced can occur during construction of any ATM WAN, we outline them here and discuss the solutions we developed while building the connection, which we call a Trans-Pacific Advanced Connection (see "Bonus Points: The ABCs of TransPAC," page 84).
|
Here
HerePage 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | Next Page |
