Previous Table of Contents Next


Controlling LAN Backbone Traffic

Migrating the network from shared-access LANs and routing to switching is a prerequisite to voiceLAN implementation. However, a major challenge remains in ensuring that voice can be properly supported on the backbone links (e.g., trunk) between LAN switches.

Supporting both data and voice over a common backbone LAN infrastructure is essentially a bandwidth-contention issue — determining how to make sure that delay-sensitive voice traffic is not preempted by other data traffic traversing the same links. Various techniques for prioritizing different traffic, reserving bandwidth, or guaranteeing network-delay characteristics may be applied. Two solutions to this problem are roughly categorized as the frame-switching/IP and ATM-centric approaches.

Frame Switching/IP-based Solution Because of the rapid decline in price of Ethernet switches and the large installed base of Ethernet adapters, switched Ethernet has become the most popular solution for organizations deploying desktop switching. It is only natural for many organizations to consider Ethernet (especially Fast Ethernet) trunks for interconnecting desktop switches to each other or to LAN backbone segment switches.

However, as Ethernet frames are switched across the network, delay problems may still occur for voice. Ethernet frames are variable in length, and Ethernet has no mechanism for prioritizing one frame over another. Therefore, as network traffic increases, small frames carrying a voice payload may often have to wait in switch buffer queues behind large frames carrying data. Because voice has a delay tolerance of only 75 milliseconds, the lack of prioritization across a switched Ethernet network may degrade the quality of voice communications. Furthermore, this fundamental problem will not disappear with expanded bandwidth under Fast (or gigabit) Ethernet.

RSVP Among the most promising solutions to Ethernet’s lack of prioritization or guaranteed latency is to handle the problem at layer 3 via the RSVP. RSVP, which is under development by the IETF and leading network product vendors, operates by reserving bandwidth and router/switch buffer space for certain high-priority IP packets such as those carrying voice traffic.

In effect, RSVP enables a packet switching network to mimic certain characteristics of a circuit switching multiplexer network. However, RSVP is still only able to set up paths for high-priority traffic on a “best effort” basis; thus it cannot guarantee the delay characteristics of the network. Furthermore, as an OSI level 3 protocol, RSVP support requires that routing functionality be added to switches.

RSVP’s best-effort capability is sufficient for several delay-sensitive applications, such as non-real-time streaming video or audio. However, it is questionable whether RSVP can support real-time voice communications over the LAN to a level of quality and reliability that is acceptable in a business environment.

ATM-based Backbone Solutions An alternative solution for delivering voiceLAN over a common data infrastructure is ATM. ATM was designed specifically to support both voice and data traffic over a common infrastructure and provides multiple QoS levels.

ATM’s CBR service guarantees a virtual circuit of fixed bandwidth for high-priority traffic such as voice. In addition, ATM uses a relatively small, fixed-length cell (53 bytes) rather than a variable-length frame to transport traffic, thereby limiting the maximum delay any one cell must wait in a switch buffer queue. The use of ATM links/trunks between LAN switches neatly solves the problem of supporting both voice and data traffic for that portion of the network.

ATM to the desktop is more problematic, however. The most common standard for ATM LANs operates at 155M-bps over category 5 UTC cable or optical fiber. However, deploying 155M-bps ATM to every desktop is currently too expensive for the vast majority of organizations (although it is beginning to be deployed as a LAN backbone technology).

In order to deploy a reliable voiceLAN solution cost-effectively using ATM, a lower-cost access technology must be deployed to the desktop. However, this access technology must also be able to extend the benefits of ATM’s QoS from the ATM backbone all the way to the desktop.

An organization can choose from among several potential access solutions, including ATM25, Ethernet using IP/RSVP, or Ethernet/CIF.

ATM25 Access ATM25, as its name implies, is a 25M-bps version of ATM designed specifically for desktop connectivity to a 155M-bps ATM backbone. ATM25 provides all of the QoS benefits of higher-speed ATM and can be used to build end-to-end ATM networks. ATM25 can also operate over category 3 UTC cable, whereas 155M-bps ATM and Fast Ethernet require organizations to upgrade their UTP cabling to category 5 UTP cable.

The downside of ATM25 is that it requires replacing all legacy network adapters where voiceLAN will be deployed. In addition, ATM25 adapters and switches are still considerably more expensive than 10BaseT Ethernet adapters and switches.

Yet, if deploying voiceLAN is a top priority for your company, installing a network featuring 155M-bps ATM in the backbone and ATM25 to the desktop may be the most reliable and logical solution. Although ATM25 is a more expensive option than switched 10M-bps Ethernet, the cost of an ATM25 connection (including adapter and switch port cost) has fallen substantially in 1996, with an average street price of $400 to $450 ($US).

Ethernet RSVP/IP Access. The most popular desktop connectivity option for data networking continues to be Ethernet, and the addition of desktop switching and Fast Ethernet technology only continues this trend. The challenge is combining IP over Ethernet network access links with ATM in the backbone in such a way that voiceLAN performance requirements can be satisfied.

One solution requires Ethernet-to-ATM desktop switches to include routing and RSVP support. The desktop end station sends voice in IP packets (further encapsulated inside Ethernet frames) to the switch, using RSVP to request bandwidth to be reserved for the voice conversation. The desktop switch then terminates the IP connection and converts the voice payload to ATM cells for transmission across the backbone (or the desktop switch may forward these IP datagrams across the ATM backbone without terminating the IP connection). The desktop switch is also responsible for mapping the RSVP bandwidth reservation request (at the IP level of the architecture) to an appropriate ATM QoS for the ATM connection.

Although this approach appears to provide the best of both worlds by combining an ATM backbone with the popularity of switched Ethernet to the desktop, it has not been demonstrated to be capable of guaranteeing the necessary quality of service needed for voice communications.


Previous Table of Contents Next

Copyright © CRC Press LLC