×

SUBSCRIBE TO TMCnet
TMCnet - World's Largest Communications and Technology Community

CHANNEL BY TOPICS


QUICK LINKS




 

horizon.GIF (9417 bytes)
April 2000

Brough Turner Simplifying The WAN Equation

BY BROUGH TURNER


Local area networks are relatively simple because one technology -- Ethernet -- won dominant market share in the late 80s and has sustained LAN development since then. Yes, there are some token ring systems. And yes, there have been occasional challenges -- FDDI and then ATM for some campus backbones. But they all pale in the face of Ethernet, as it has scaled from 10 Mbps to 100 Mbps to Gigabit. The result is simplification for the IT director -- many potential vendors but only one technology, and thus the ability to select only one or two vendors if desired.

In the past three years, a similar simplification has happened to data protocols for new applications. IP (Internet Protocol) has won. As recently as four years ago, developers dealt with a profusion of protocols -- SPX/IPX for Novell applications, SNA for IBM applications, DECnet for DEC applications, and so on. Today, IP is the only protocol that an applications developer would consider for a new data communications application. This vastly simplifies everyone's lives.

However, when you turn to wide area networks (WANs), there are myriad services and protocols in use. New applications may run on IP, but old applications are still widely deployed. In addition, IP needs a transport layer, and many transports are deployed. So we see a variety of leased lines and public network services, using a profusion of protocols: PPP, X.25, frame relay, ATM, packets-over-SONET, and completely proprietary protocols. But there is hope. Simplification in the WAN will take a few years to emerge, but it's coming, and early signs should be visible this year.

TODAY'S LEGACY
The first wide area networks were built on leased lines carrying data at 1,200 bps, 9,600 bps, or 56 Kbps, and eventually at T1 and higher speeds. The choice of protocols was typically dictated by the equipment vendor. As the need for remote access to IBM mainframes grew dramatically, the WAN protocols were based on IBM's System Network Architecture (SNA). DEC equipment focused on DECnet, and so on.

In due course, shared public data services emerged, first using the X.25 protocol, then frame relay, and (more recently) ATM protocols. In each case, these public data services provide private "virtual" circuits that reproduce leased line behavior, at least in part. In other words, to carry SNA, DECnet, or IP traffic from one site to another, an IT director leases a virtual circuit instead of a real physical connection. Among such shared data services, frame relay is the leader. But private (non-shared) leased lines still dominate most large corporations' WANs. To further complicate things, most frame relay virtual circuits are actually carried on ATM backbones.

Today, an IT director with multiple locations is likely to run a mixture of leased-line facilities and frame relay circuits with separate networks for the historic SNA traffic and for newer IP applications, and an entirely separate solution for voice communications. There are some exceptions -- the integration of all services onto an ATM network, for example -- but typically an IT director will be running multiple semi-independent networks. And when choosing WAN services, he or she faces a profusion of offerings, and a confusion of metrics: committed information rate, peak rate, burst rate, sustained rate, drop rate, latency, delay, etc. What's needed is significant simplification, and there is some hope that this will happen, albeit a bit more slowly than most IT directors would like.

CLASSES OF SERVICE
Perhaps the most pervasive legacy application protocol is SNA. Most large corporations have multiple mainframe applications that communicate with simple terminals using SNA. Many of these applications are considered mission-critical. And, many of them require specific network performance guarantees to deliver acceptable results. Consider a call center where agents are accepting orders. What would happen to the efficiency of that call center, for example, if the agents had to wait many seconds for a screen pop? After installing CTI equipment to shave a few seconds off of each call, we'd obviously like our agents to be able to access mainframe data in a fraction of a second, not in 8 to 10 seconds. With a "best-effort" service like IP, a screen refresh can be delayed by a large file transfer. SNA on the other hand, is able to reserve bandwidth and provide the needed delivery guarantees.

Voice telephony has different requirements -- notably, very low latency, much lower than that of traditional data communications applications. Without it, voice quality degrades and the service becomes unusable. So today, high-quality voice over IP (VoIP) services use dedicated IP networks, but most voice traffic remains on traditional voice networks.

Even totally IP-centric applications such as Web browsing and e-mail benefit from separate classes of service, for example, giving priority to Web browsing. After all, e-mail and bulk file transfers can wait seconds or even minutes if necessary, but Web browsing is interactive.

ATM supports different classes of service today, so ATM can support multiple applications on one WAN. However, from the IT director's point of view, it's done by running separate networks over separate virtual circuits from one ATM WAN provider. What's needed are application-level quality of service (QoS) choices on the one network where all new applications are deployed -- the IP network. What's needed are differential services at the IP level.

DIFFERENTIAL SERVICES AND VIRTUAL CIRCUITS FOR IP
The good news is that working groups within the IETF (Internet Engineering Task Force) have defined both differential services (DiffServ) and a form of virtual circuits. Multi-protocol label switching (MPLS) provides paths that are secure "tunnels" through a public IP network, from one corporate site to another, for example, similar to virtual circuits in a frame relay or an ATM cloud. And with IP DiffServ and appropriate traffic engineering, carriers will be able to offer service guarantees for these MPLS paths.

When deployed, MPLS paths will allow an IT director to order wide area IP services from a single vendor if desired, where specific classes of IP traffic (that is, specific IP applications) receive specific service guarantees. This technology will roll out over the next few years and result in a major simplification for the WAN.

In addition to supporting classes of service, MPLS paths also provide security. IP networks have an image problem because of security problems with the public Internet, the most well known IP network. But using MPLS, traffic on the label-switched path is isolated from the rest of the traffic on the IP network. Of course, encryption is also available and is being deployed, but just the act of separating traffic goes a long way towards addressing security concerns.

SIMPLER AND LESS EXPENSIVE
Combining all applications on a single network will also save IT directors money in the most expensive part of their network -- the access loop. Since deregulation, there are innumerable carriers deploying new fiber. And, with the advent of dense wavelength division multiplexing, an enormous amount of bandwidth is coming on-line, at least in the long-distance network.

But the access loop is a different story. Here there is a dearth of fiber, and the copper cables are owned by entrenched monopolies. So, access bandwidth remains the most expensive part of a WAN. Indeed, some WAN service providers bill only for access bandwidth, providing long-distance transport for zero incremental cost. With further competition in the local loop, this situation should improve. And at least there is more than one local monopoly -- the telephone company owns the copper and the cable company owns the coax. However, cost cutting in this area remains slower than in any other part of the network.

Clearly, combining voice and mission-critical data with e-mail and file transfers on a single access loop is a major cost savings. Once this is possible, IT directors need only sign up for an IP access service for each of their locations. Within that access pipe, they'll specify applications that require special services, and they'll specify a given amount of bandwidth per special service. It's the special services that will cost money.

The remaining access bandwidth will be available for best-efforts traffic, between corporate sites and to and from the public Internet. If you sign up for enough premium services, it's likely the best-efforts services will be free. The carrier will take care of provisioning multiple label-switched paths between the regional offices and corporate headquarters unless the IT director wants to retain control of this function.

While it will be possible to offer many different classes of service (and smart marketeers can put many fancy names on even a single service), it's likely that only three or four classes of service will be needed to meet most needs. Examples might be a low-latency service for VoIP traffic, a guaranteed bandwidth allocation for mission-critical applications, Internet access with some preferences (for Web browsing), and best efforts (for e-mail and non-critical file transfer, and everything else).

Simplifying customers' needs to this level allows carriers to provide corporations with an IP-only network that supports their applications. Corporations only pay for the contracted access and for those QoS guarantees they desire. Most likely, the corporate IT department will provision their desired services themselves using a Web browser and the carrier's secure Web server. Then they can also reconfigure services as needed.

Of course, legacy SNA networks won't change immediately, but when they have to change for other reasons, they'll migrate to IP as well. And meanwhile, IT directors can tunnel their legacy SNA traffic through an IP service with response-time guarantees. With VoIP gateways, or an IP-PBX, voice can also be supported by a service that guarantees less than 70 ms latency and less than 0.01 percent packet drop -- more than adequate for toll-quality voice performance.

A REALITY TODAY
Since MPLS is not yet widely deployed, and since the traffic engineering for IP differential services is still in development, interim techniques are emerging. An immediate approach to differential IP services has appeared in the form of bandwidth management equipment that maps IP QoS to ATM virtual circuits. ATM QoS and ATM traffic engineering are well understood, and ATM networks are widely available today. By automatically mapping IP applications to ATM virtual circuits, a service provider can provide differential IP services today -- the carrier deals with the ATM details, the customer sees only IP services with performance guarantees.

As MPLS and DiffServ become more widely deployed and traffic engineering is refined, IP QoS will migrate from being delivered using ATM technology, to being delivered using MPLS and DiffServ technology. But either way, wide area differential IP services will emerge this year. WAN simplification is underway.

Brough Turner is senior vice president of technology at Natural MicroSystems, a leading provider of hardware and software technologies for developers of high-value telecommunications solutions. For more information, call Natural MicroSystems at 508-620-9300, or visit the company's Web site at www.nmss.com. E-mail to the author (addressed to [email protected]) is also welcome.







Technology Marketing Corporation

2 Trap Falls Road Suite 106, Shelton, CT 06484 USA
Ph: +1-203-852-6800, 800-243-6002

General comments: [email protected].
Comments about this site: [email protected].

STAY CURRENT YOUR WAY

© 2026 Technology Marketing Corporation. All rights reserved | Privacy Policy