QoS: Creating Inequality In An Equal World
By Chris Lewis
By design, Ethernet creates all nodes on the network equal in terms of their access to resources--a good thing for data-oriented networks. Increasingly, however, organizations are looking to leverage the investment made in Ethernet networks to deliver multimedia audio and video applications. These sophisticated multimedia applications require a
guaranteed amount of bandwidth and fixed latency to operate well, presenting some significant challenges to the basic Ethernet protocol.
To ensure low latency to specific traffic streams, you must dedicate some network resources to those streams. This makes those resources unavailable to other network t
raffic and creates inequality.
We will outline the challenges presented to Ethernet quality of service (QoS), introduce potential solutions and provide information on configuring Cisco Systems' equipment to accommodate Ethernet QoS.
Challenges to Delivering Ethernet QoS
An Ethernet network does
not distinguish among packets carrying a videoconference, providing access to a critical database, game data or Internet information.
Currently, Ethernet cannot deliver service guarantees for two reasons. First, the only restriction on any node seeking to gain full access to Ethernet's 10-Mbps throughput is that no other node can be using the network at that time. If a node transmitting noncritical data wants to launch a large file transfer that will funnel resources from critical network traffic, it can. Second, Ethernet packets are of varying lengths--it takes anywhere from 51.2 microseconds to 1.2 milliseconds (ms) to transmit an Ethernet frame onto a network cable. As a result, critical data
will face uncertain delays.
Proponents of ATM say these challenges to delivering QoS on Ethernet are so fundamental to the way Ethernet operates that it is not feasible to use Ethernet for QoS operation. The Ethernet crowd counters this by noting improvements in Ethernet bandwidth and other advances--such as the Resource Reservation Protocol (RSVP), the Real-time Transport Protocol (RTP) and IP Multicast. There is plenty of life left in Ethernet, they say.
In practice, most engineering decisions are a compromise. In this case, the pluses for Ethernet are that it has a huge installed base, most network administrators understand its operation, and it is significantly cheaper than competing technologies. Grafting QoS capabilities onto Ethernet produces a theoretically suboptimal solution, but one that is good enough for most users.
On a theoretical level, ATM has two features that make it a more QoS-friendly technology. First, ATM uses a fixed cell length, which reduces latency in switches and reduc
es variable delays in the network. Second, ATM is most commonly a connection-oriented technology that uses a call setup procedure for every conversation, guaranteeing QoS levels during call initiation. Calling ATM a connection-oriented technology does not mean that it is a reliable delivery mechanism like the LAP-B da
ta-link protocol: There are no cell-recovery procedures because ATM leaves retransmission to higher-layer protocols.
ATM QoS is managed by a traffic contract that is negotiated during call setup between the network and the device requesting the connection. The device requesting connection will ask for one of four classes of service, and the network either will agree to this service level and permit the connection or the connection will be denied. The traffic contract places demands on the call-initiating device--if it tries to send more traffic than originally stated, the excess traffic may be discarded by the network.
Delivering high-quality audio and video over Ethernet networks requir
es QoS facilities, which are provided by a combination of the RSVP, RTP and IP Multicast capabilities.
RSVP reserves a specific bandwidth for a stream of data on the network. RTP minimizes the effects of packet loss and latency (packet delay) on audio and video content. IP Multicast enables the machine originating the traffic flow for audio or video content to send the stream only once--no matter the number of receivers.
|
REPORTS
ANALYTICS
Follow 
