January 23, 2008. At the “Network Management” Conference Session held at the beginning of ITEXPO (News - Alert) in Miami, Florida, three speakers discussed how service providers want to deliver new and exciting voice and multimedia services on an end-to-end basis to their customers, but they soon discover that Voice-over-IP (VoIP) and other forms of IP communications can be difficult to troubleshoot if performance falters.

 

Michael Devlin (News - Alert), Director of Product Management, VPIsystems (www.vpisystems.com), said, “I was looking at a nest of fire ants with a child and I tried to draw an analogy between the fire ants and network packets. I said, ‘If we observe the number of ants emerging from the ant hill during a minute, do you think we could predict what would happen during the next minute?’ The kid thought for a second and said, ‘Yes, you could do that, until something like this happens!’ And with that he picked up a stick and shoved it into the anthill, followed by thousands of angry ants that came pouring out of the nest.”

 

“I thought to myself that, to a large extent, that’s what happens in networks,” mused Devlin. “You can look at them and you can monitor them, but there’s always going to be something unexpected happening for which you have not planned. In order to accommodate such circumstances, you’re going to need another type of tool that goes beyond monitoring and goes back into the planning area. I’m referring to planning your VoIP networks and your mission critical applications through the use of modeling. There are tools available whereby you can model the precise network, the ‘as-built’ network, and its post-configuration traffic on it, and model that network for utilization, priorities, traffic, failover, and anything you can measure such as ‘shared risk linkage’, so that you can get an idea what your network really looks like and how it really behaves.”

 

Devlin elaborated: “Now, the advantage of modeling your network is that you can test the model by inserting future traffic that, say, the marketing department projects they’ll generate, either because they’re coming out with new services – in particular, in terms of geography – or they’re expecting some subscriber behavior changes that are going to cause network utilization to increase. So those are some of the things you can do and in such a linear network you have the ability to model not only the traffic going through it but you’re also able to plan for diversity. So, for example, when you’re designing and installing a network, there’s always a situation where you might ask yourself, ‘Okay, if I have packets going from A to Z, and one of those links fails, how do I make sure that the failover path utilization doesn’t go beyond the level that’s required for producing high quality voice applications?’ Those are some of the things that you can view in advance.”

 

“Further complicating the situation is the fact that, in a service provider network, you’re really looking at multiple domains,” said Devlin, “so you’re looking at what’s going to happen in your access network, what might be happening in your Layer 3 core network and your MPLS network and what’s going to be happening in your transport network at Layer 1. So you want to do VoIP traffic modeling and forecasting at your access level where the calls come in, but you also want to be able to plan what the scenarios are in terms of such things as link failure and link failure analyses, both at Layer 3 as well as the transport layer. Things get even more complex because in the case of Layer 3, you might think you have plan for diversity at that level but maybe there are two logical links that are carried on a single fiber. So if Farmer Jones is plowing up his field and cuts that fiber, you soon realize that you don’t necessarily have link diversity all the way through the network.”

 

“What this all means in terms of planning and utilization is that you have to be cognizant of the diversity at all of these layers to ensure that when something does happen in the network and the traffic gets re-routed, the utilization of one particular branch or ring or whatever, doesn’t ‘explode’ and cause you a major problem,” said Devlin.

 

“There are many planning options available,” said Devlin. “Some of you have in-house tools. Others will buy vendor tools. No two networks are alike, so what you really want to look at is not only whether these tools can handle the domain in which they are doing their problem solving, but whether they also have some method of extensibility so that they can be mapped into your particular network and integrate with the in-house tools. That extensibility might consist of modeling a specific router that you use that the tool vendor may not provide off-the-shelf.”

 

“These tools are somewhat loosely coupled today because they come from a variety of vendors and so their integration is not quite what you’d like to have, but Telecom Management Services [TES] standards and standards for Operations Service and Support [OSS] integration in this area are evolving and I’d encourage you all to think about that and talk to the vendors about where they are in that process,” said Devlin.

 

“You’ve got to look for vendors capable of solving your domain problems, that fit your business practices today,” said Devlin. “I would not expect ‘nirvana’ today, but plan for it, because it’s coming. There are a lot of really good tools out there. Once we get them integrated, we’ll all have a really great OSS capability.”

 

“Finally, if you’re in executive management, think about your operational support system across a full spectrum, from forecasting all the way through provisioning,” said Devlin. “I’d also be conscious of what your vendor relationship is. You’re going to want diverse tools to be able to interoperate.”

 

Frank Green (News - Alert), Product Manager in the Enterprise Division of ADTRAN, Inc. (www.adtran.com) the telecom hardware maker, said, “I want to examine this issue more from an equipment standpoint, in terms of what types of features and capabilities can be built into the equipment you’re deploying into the network to ensure the capability to port back and monitor and handle real-time media applications.”

 

“In terms of enabling high-quality voice in the network, the first thing that comes to mind is Layer 1 and Layer 2,” said Green. “The first consideration is your set of physical connections, such as your cables and connection speeds. Are there cable breaks? If we’re talking about a greenfield installation, you probably have all new cables and infrastructure, so you don’t have to worry about pre-existing materials, such as whether you have Cat-3 or Cat-5 cabling. But in the case of new construction, you do have to worry about things like a person with a nail gun firing a piece of metal into your cabling, causing a break.”

 

“Your equipment should be able to gather Layer 1 and Layer 2 statistics and retrieve that information and make it available to a management solution,” said Green. “Most equipment for some years now has done a pretty good job at handling Layer 1 and 2, so this usually isn’t a problem. There are some recent products that have entered the market that do offer a bit more capability in this area. For example, TDR, or Time Domain Reflectometry. This is the ability for a device to actually determine if there’s a cable break and how many meters away the location of the break happens to be.”

 

“Moving up the OSI stack to higher level network architectures, we see that the core network must be able to handle the traffic loads and not allow network congestion to occur, which in turn causes high latency of packet deliver and hence lowers voice quality, said Green. “Quality of service is fundamental when it comes to reducing latency.”

 

“The network equipment should offer active jitter buffers that increase or decrease in size depending on the amount of latency in the network,” said Green. “As latency increases, the size of the buffer increases, so that a constant flow of packets of real-time media traffic can be maintained.”

 

“Of course, once information about the network is gathered by the equipment installed in the network, it is paramount that the information be forwarded up to a centralized management solution, because it’s not feasible for a service provider to try to individually look at 1000, 2000 or 3000 boxes,” said Green. “They really need to have an automated or semi-automated management solution that gathers all of that information so that somebody can see what’s happening on a screen and receive alerts.”

 

Shekhar Gupta, who does product development for Embarq (News - Alert) (www.embarq.com), in his presentation on “Managed Network Services” said, “When I started developing a VoIP platform for my company and then the customers, once they had email working, then regular phone lines, they soon said that, “This IP phone system appears to be nothing more than just a phone that’s plugged into a data network and it should work just fine. There’s no need to do anything. The IP packets carrying the voice will travel over the data lines carrying everythings else, and there isn’t any need for any sort of prioritization. Well, as it turned out, that really wasn’t’ the case.

 

If you’ve ever tried to put together a VoIP network, when you’re just plugging a VoIP phone into your 1.5 megabit or DSL network or your dedicated access network, the phones just don’t work that well,” said Gupta. “You experience a lot of packet jitter and delay. Now imagine having a 1.5 megabit service coming to your business. If you don’t have compression on your voice, if you’re just using the regular line, that means you’ve only got about 100 Kbps per line, so if you’ve got five or six phones and five or six computers running at the same time, and then you send out a large file to a printer, the bandwidth usage increases rapidly, and voice service suffers. You won’t necessarily know what’s going on, because you think you’ve got enough bandwidth, and so you’ll end up calling your service provider and complain that there’s something wrong with your phone line.”

 

“Keep in mind that voice services are very critical,” said Gupta. “They have to be real-time. You cannot afford to drop packets, but that’s easy to do because there’s finite bandwidth. Any application you run on a network affects voice quality. So when somebody tells you that voice is free, be very skeptical. There are various fixes to these problems. The first is to increase the amount of bandwidth, such as bonded T-1s or a T-3. That’s a temporary fix, of course. There is no ‘one size fits all’ product or one ‘silver bullet’ that solves all network problems. One of the principal things you’ve got to do is prioritize your traffic. Obviously, voice is critical, so that gets the highest priority of delivery. But what about email? What if you’re running a hosted contact center? Other things may need to be given high priority along with voice.”

 

All of the speakers stressed careful initial planning for IP Communications, followed by combined monitoring and diagnostic strategies.