When congestion clogs a freeway or interstate highway, the typical response is to add more lanes. But that usually provides only temporary relief; drivers adjust to the additional capacity by changing their driving habits to take advantage of the new concrete. The all-too-familiar result: The highway rapidly becomes congested again.
Networks aren't much different. It seems whenever new capacity - bandwidth - is added, users quickly learn how to exploit it; soon, as a practical matter, it disappears. This seems to be especially true for Internet/intranet services, where new multimedia applications are creating a virtually insatiable demand for bandwidth.
Just as our freeway designers are establishing special carpool and bus lanes to minimize the contention for space along our highways, network designers are showing considerable interest in creating separate "lanes" for communications. To create these lanes, techniques like traffic prioritization, bandwidth reservation and multiple service levels are being implemented.
But in networking, it is not enough to just get the traffic to its destination; the quality of the delivery matters. The network must provide the right end-to-end delay, delay variation (jitter), error rate and, of course, bandwidth, for each type of data. A number of alternatives exist to support multiple service levels within enterprise networks, and they have a major influence on the type of network architecture that should be deployed.
Service Quality Mechanisms
As multiple types of applications and data traffic - like Web browsing, transaction processing, large file transfers and messaging - contend for bandwidth, there's a growing recognition that different levels of service are going to be required. Otherwise, the performance of critical business applications will be adversely affected by Web downloads, advertising broadcasts (e.g., Point-cast) or other "less essential" traffic that will "steal" bandwidth.
This situation will become worse as browsers like Netscape Navigator and Microsoft Internet Explorer incorporate desktop voice, video or other collaboration technologies (like Microsoft's NetMeeting). These capabilities will create major bandwidth and/or latency demands.
As a result, the debate regarding what technology to use within the enterprise backbone - IP frame switching vs. ATM cell-based transmission - has become more heated. The alternatives are being compared based on how each delivers multiple levels of network service, and while both support quality of service, there are important differences in how the support is provided.
ATM Quality of Service (QOS) capabilities and standards have been championed by the ATM Forum. The ATM standard's inherent QOS feature, found on ATM switches and Network Interface Cards (NICs), can deliver multiple network service levels. Depending on the device, the list includes CBR (constant-bit-rate), VBR (variable-bit-rate), ABR (available-bit-rate) and UBR (un-specified-bit-rate) services.
For IP-based networks - e.g., Fast Ethernet backbones the Resource Reservation Protocol (RSVP) may be used. RSVP is a Level 3 protocol implemented in routers or Level 3 IP switches, and applications use it to request special handling for certain types of traffic. Hosts use RSVP to tell routers to reserve the necessary resources for each traffic "flow." RSVP is being championed by the Internet Engineering Task Force (IETF).
Frame switch and router vendors are promoting RSVP so users won't be forced to implement cell-switching-based ATM to obtain multiple service levels. There is an RSVP implementation in the latest version of Cisco's IOS, and all of the major router vendors are expected to include RSVP in products by late 1997.
However, there are some limitations that RSVP products will contend with for some time. The RSVP standard includes three types of service - Guaranteed, Predictive Delay and Controlled Delay - in addition to the familiar "best effort" service. But initially, many vendors will support only RSVP's Guaranteed service, which provides static allocation of bandwidth analogous to how time-division multiplexers operate.
How They Stack Up
RSVP and ATM QOS differ in how each establishes a particular quality of service. RSVP can create a quality level anytime, once a traffic flow has been established. It also periodically refreshes (or reconfirms) the service level during the call, which makes it possible for a host to change a service level without reestablishing the flow. In contrast, ATM defines the quality level at call setup, and retains that level for the duration of the call.
There are also concerns that RSVP will not scale to Gigabit Ethernet switch speeds and throughput levels. The basis for this concern is that RSVP requires that Level 3 IP packet headers be processed, a task normally performed by routers, which are typically much slower than switches.
In contrast, the high efficiency of ATM's Level 2, connection-oriented switching lets ATM QOS scale to much higher speeds. While many proponents of Gigabit Ethernet argue that multiple service levels aren't important at the gigabit level - there's enough bandwidth to make contention unlikely - experience shows otherwise; traffic loads quickly rise to capacity in most networks.
It is also notable that RSVP's service level "guarantees" may be difficult to achieve, due to IP's "best effort" connectionless service. RSVP lacks ATM's flow control and feedback mechanisms. More important, because IP networks use connectionless datagram routing, changes in routes could cause a change in the quality of service experienced by a particular flow. It will take time for RSVP flows to be "refreshed," and there is no guarantee the new route can provide the needed service quality. Unlike connection-oriented ATM, which can optimize QOS on a "global" basis across multiple hops, each router with RSVP must operate in an uncoordinated, independent fashion.
Thus there is skepticism that vendors will ever be able to "fine-tune" RSVP enough to reliably support isochronous traffic like voice or video with high quality in busy networks. Vendors and the IETF are working hard on this issue and, based on their track record, it's probably not wise to bet against them. But its hard to find people who predict that RSVP router/switch implementations will deliver close to the service level performance of ATM QOS any time soon.
That said, however, it is worth noting that there are very few products that can, as yet, use either standard. Since applications must request the appropriate service levels, a task typically performed at the time connections are established, a standardized network services API is needed that an application can use to signal the network.
Until recently, that API wasn't available, but Microsoft now supports both RSVP and ATM QOS in its latest version of Windows NT. The application can request a service level from the operating system using the Winsock 2.0 API. Moreover, Winsock 2.0 is expected to be added to all future versions of Windows, but before it can become widely used on workstations and servers, developers need to write applications that can take advantage of Winsock 2.0.
Architecture Impact
The choice of RSVP vs. ATM QOS will have a significantly affect network architecture. It will dictate, for example, whether campus or building LANs should be based on Fast/Gigabit Ethernet or ATM switching, and define the role of routing in the network.
Clearly, Ethernet has won the battle for desktop and most server access to the network. Dedicated, switched access eliminates Ethernet collisions, permits full-duplex operation and eliminates contention for bandwidth between the single desktop/server computer and any other devices.
But Ethernet trunks are different - traffic from multiple users must always contend for bandwidth on these links. There is no question that Fast Ethernet trunks are far less expensive than ATM's 155-Mbps trunks; similarly, Gigabit Ethernet trunks promise to cost half or less as much as ATM 622-Mbps trunks.
But trunk cost may be only a small portion of total network cost (relative to access), and may be less important to meeting business objectives than quality of service concerns. Particularly as real-time voice and video migrate to the data communications infrastructure over the next five years, enterprises may require "industrial-strength" QOS capabilities that only ATM can provide. If today' s separate voice wiring and switching infrastructure is eventually eliminated in favor of a multiservice network, a consolidated LAN ATM backbone will become less expensive.
Marrying dedicated switched Ethernet access with ATM backbone trunking can provide end-to-end quality of service. This configuration relies on ATM QOS for backbone services, but uses RSVP as a signaling protocol at the network edge. Workstations and servers issue RSVP service requests over dedicated Ethernet access links to workgroup switches. Based on the RSVP request, the switches forward Ethernet traffic with the right ATM QOS onto the appropriate ATM virtual circuits.
Many vendors offer Ethernet workgroup switches that can support ATM trunks - what's missing is the capability to map RSVP into ATM QOS. Such capabilities can be expected in 1998, once vendors and standards bodies complete their work determining how to convert RSVP service levels into the appropriate ATM QOS levels.
Conclusion
The cost advantages of combining multiple applications onto a single network are well established, but the technology to let SNA, voice, video and Internet traffic to effectively coexist has not been available. Improvements to IP and ATM bring us much closer, but work remains to implement the full capabilities of RSVP and QOS, as well as to permit service mapping between these standards.
If your organization doesn't: need guaranteed quality of service levels, Ethernet backbones and RSVP-based frame switching may be good enough and less costly to implement. However, for those needing guaranteed service levels for mission-critical or time-sensitive applications, ATM-based backbones are actually the more conservative approach.
David Passmore is president and cofounder of Decisys, Inc. (Sterling, VA), a consulting firm specializing in networking strategies for vendors and end users. He previously ran Gartner Group's networking services, was a partner with Ernst & Young and was a principal and cofounder of Network Strategies and can be reached at passmore@decisys.com.
No comments:
Post a Comment