Cisco Reroutes Traffic Management

With the planned acquisition of P-Cube Inc., Cisco Systems Inc. (Nasdaq: CSCO) appears to be moving towards bringing traffic management into routers.

Cisco announced this week that it plans to acquire P-Cube for $200 million (see Cisco Plucks P-Cube for $200M). While P-Cube's appliances would remain standalone products, Cisco officials say they're considering ways to slap parts of the functionality into routers.

The move would help Cisco, certainly, by adding features to its routers. Analysts think the idea makes sense, but P-Cube competitors aren't so sure that's wise

"If you're in a separate appliance, you're independent from the deployment of the network," says Yigal Jacoby, CEO of Allot Communications, a competitor to P-Cube. "Cisco's goal is not to be independent of the network. It's to sell routers."

P-Cube builds appliances that dig into packet headers to find out what's going on. This kind of traffic management has proven valuable in monitoring peer-to-peer traffic, which can gobble more than 80 percent of available bandwidth (see Controlling P2P Traffic). Appliances made by the likes of Allot, CacheLogic Ltd., Corvil Ltd., Ellacoya Networks Inc., and P-Cube allow service providers to isolate this traffic and act accordingly -- bill the user more, crank down the bandwidth allowed, or stop the session entirely.

Some observers figured something like that would happen eventually (see P-Cube). Those building competing appliances see potential problems, however.

Aside from the question of network independence, performance could be an issue. "History proves that every time you add functionality like that to a router, you degrade the router functionality," Jacoby says. "It is not in the best interest of the customer to have everything in one box."

Ellacoya CTO and founder Kurt Dobbins believes a standalone services-intelligence box is becoming a key element in the network. "We're seeing more and more control getting taken out of the edge devices like the B-RAS [broadband remote access server], he says. "The edge devices will become less intelligent, and more service-provider intelligence will go into the IP services control switch."

Whether integration happens depends on the future architecture of routers, Dobbins adds. Routers tend to operate in bulk fashion, controlling subnets rather than individual flows. Of course that could change; Caspian Networks Inc. and Axiowave Networks Inc. are pushing the concept of flow-aware routers (see Caspian Comes Out and Flow-Based Networking).

To some, though, integration looks inevitable. "Ultimately, it could be a software feature set -- i.e., it wouldn't require a separate hardware module" as with P-Cube, says Ron Westfall, an analyst with Current Analysis.

Some of the hesitation from appliance startups could be chalked up to self-preservation. Or, maybe they want a little longer to enjoy some success, now that the market has finally come their way.

It's been a long wait. Ellacoya and P-Cube date back to 1999, and Allot to 1997. They had the right idea early on -- find a way to distinguish the traffic types running through a router, allowing carriers to act on individual flows -- but their products got to market just as the telecom market sank. Allot survived by diving into the enterprise market. Ellacoya was supported by a "solid set of investors," Dobbins says. It revamped its box into an appliance rather than a chassis system.

Meanwhile, early attempts at the concept went on. Cisco even gave it a shot, with a product called NetFlow. But NetFlow couldn't tackle the service provider market the way P-Cube could. "There were some customers that did use NetFlow, but it wasn't a scaleable solution," Westfall says. "When you're talking about a major telco, you need to scale."

The past two years have seen a resurgence for traffic managers, driven by the spread of peer-to-peer networking. P2P eats up bandwidth, and worse, it creates enormous upload streams, contrary to the thinking of DSL and other asymmetric services, which assume downloads will be heavier than uploads.

P2P is a nice market, but the real hope for P-Cube and others is that carriers will take note and find other uses for the technology. Two examples so far include online gaming and VOIP, both of which require guaranteed shots of bandwidth to sustain real-time responses.

With the idea spreading, and Cisco nabbing P-Cube, other large vendors could be spurred to make a move. "Cisco's move may prompt other vendors to join in," Jacoby says.

Nortel Networks Ltd. (NYSE/Toronto: NT), for one, is already in the content switching space via the 2000 acquisition of Alteon WebSystems, and the company has competed with P-Cube in wireless infrastructure applications (see T-Mobile Teams Up With Nortel and P-Cube Eyes Incumbents). But Alteon doesn't really provide the same traffic-management capabilities as Allot and Ellacoya. "The root of Alteon is more in the load-balancing space," says Jacoby. "They don't know how to interpret packets."

Ultimately, traffic management companies hope to make routers as predictable as other tools. Jacoby notes with some amusement that routers are unpredictable enough to force vendors to qualify their promises. "It's always 'up to' and not 'minimum of.' There's no other service in the world that has that. When you buy a car, they don't start by telling you what you won't get."

— Craig Matsumoto, Senior Editor, Light Reading

For further education, visit the archives of related Light Reading Webinars:

cyber_techy 12/5/2012 | 1:19:54 AM
re: Cisco Reroutes Traffic Management

There's no other service in the world that has that. When you buy a car, they don't start by telling you what you won't get."

Ever read the fine print that appears with minimum contrast in car ads? "Not all buyers will qualify". Vehicle shown priced higher. Dealers set their own prices etc. Closed course, professional drivers only
slickmitzy 12/5/2012 | 1:19:49 AM
re: Cisco Reroutes Traffic Management I wonder who had the i idea to compare netflow and traffic management appliances?

Netflow was never intended to be used as an active traffic management tool. it's rather a statistical tool meant to help the network operator to get a better understanding of the traffic in the network.

claiming that netflow failed as a traffic management tool because it wasn't scalable enough for service provider show total lack of knowledge and understanding.

If there is a barrier for deploying netflow it's the complexity of the deployment (the need for a coolector and analyzer).

If netflow is such a failure then why did juniper bothered with jflow?

As far as i know the netflow/jflow features are on the standartisation track already, but i'm not sure.

Personally i can tell that we are service provider that implemented netflow.
First it was a nice toy to play with. about a month later it became a critical mission tool.

For example netflow is an excellent tool for dealing with denial of service attacks and other security related network anomality.
We have integrated it with a Riverhead (now cisco) Guard appliance and it's saving us a lot of the work related to Dos attacks.

Sign In