Convergence: Is your IP network ready?
|
|
|||
|
|
Is your IP network ready to converge with voice? Convergence. We all hear about it. Some of us even talk about doing it. But before embracing this hot concept, there are some serious considerations that need to be addressed.
You need to ask yourself questions like:
When you answer these questions, you will be in a better position to test-drive a converged network.
I have heard people say that their switches support quality of service (QoS), so they feel their network is ready to support data and voice simultaneously. If it only were that easy. QoS is an albatross. You first must address questions such as:
The Tolly Group recently performed just such a convergence evaluation to show that not all vendors are created equal when it comes to handling application flows with QoS. Moreover, we attempted to show that a best-of-breed environment is an acceptable alternative to a sole source converged network.
The Tolly Group and our test sponsor learned that with some vendor's QoS implementations, convergence is a matter of repetitious trial and error rather than an exact science.
We answered all the questions I posed above. We knew that building an environment that closely modeled a real-world scenario would be no easy task, but we also knew that building an exact replica of the traffic found would prove more beneficial than a traffic profile of wire-speed 64-byte packets.
We identified our mission-critical applications such as database transactions. We noted our latency-sensitive apps such as voice over IP, video on demand and multicast. We also wanted to make sure tasks such as checking corporate e-mail and moving code updates around via FTP took priority over traffic like Web browsing. We also did not want to forget the highest priority traffic - management - in the form of Open Shortest Path First updates and the like. We calculated we needed six priority queues.
Then it was time to test-drive the converged network infrastructure. It is here that one finds out how many of the queues the vendor supports and of those queues, how many they are processing in hardware vs. software. Hardware-based processes tend to be more efficient at processing and thus have overall better performance characteristics than software-based processes. And of course my favorite finding of all - the cost of enabling QoS. It still disturbs me that some vendor equipment takes performance hits when advanced features like QoS are enabled.
Test-drive your IP network for convergence readiness before any massive deployment. Make sure your switches are up to the task of servicing all your application flows and allocate them the bandwidth they need, when they need it.
RELATED LINKS
Tolly is a senior engineer with the Tolly Group. When he's not diving into QoS queues, he can be reached at btolly@tolly.com. Kevin Tolly is on vacation.
|
|
|
|||||
