Caspian Comes Out

April 9th is now officially IP Core Router Coming Out Day. [Ed. note: It's also Hugh Hefner's birthday... coincidence?] Today two stealthy startups, Caspian Networks and Procket Networks Inc., made announcements about their products (see Caspian Intros Router and Procket Announces Routers).

While the two companies are competing for the same business, they have taken different approaches in terms of which features they’ve emphasized.

Procket’s announcement is all about high-availability routing and programmable hardware (see Procket Gets Unstealthy). But Caspian’s schtick is slightly different. It says its Apeiro router can route traffic based on flows to provide ATM-like quality of service (QOS) over IP. Caspian’s message asserts that making IP more deterministic will allow service providers to make more money through premium end-to-end services like toll-quality voice and streaming video. The company claims this feature also allows carriers to have better control over broadband networks and ultimately enables consolidation of disparate networks.

Like Procket, Caspian claims that its product is based on an architecture dramatically different from that of traditional core routers -- architecture it says will help carriers reduce capital expenditure and operational costs in the future. But unlike Avici Systems Inc. (Nasdaq: AVCI; Frankfurt: BVC7), Nexabit, and Pluris -- startups that all came out during the Internet bubble -- Caspian and Procket are talking less about multichassis scaleability and more about differentiated software and hardware features.

“Scaleability is something that Juniper has already solved with the T640 and its best-effort approach to handling traffic,” says Faizel Lakhani, vice president of marketing for Caspian. “But how do they offer ATM-quality service over an IP network? They can’t.”

Caspian’s high-end QOS mechanism is all about flow-based routing, says Lakhani. Unlike most routers that forward packets individually, the Apeiro router forwards packets based on flows. This means that Apeiro routes the first packet in the microflow, and subsequent packets in the same flow are then switched to the proper destination. This cuts down significantly on the time it takes for each packet to be identified and appropriately routed.

Using an RSVP-like mechanism, the Apeiro router can supposedly guarantee how the traffic is handled throughout the network. This ensures predictable delay, jitter (delay variation), packet order, and fairness, according to Caspian. Lakhani also claims Apeiro is able to sustain millions of new microflows per 10-Gbit/s interface per second in hardware, much faster than the fastest ATM switch. All this functionality is burned into custom ASICs developed by the Caspian team and now being fabricated by IBM Corp. (NYSE: IBM).

The putative benefit is that with improved QOS carriers can feel more comfortable about sending their Asynchronous Transfer Mode (ATM) and Frame Relay traffic over an Internet Protocol (IP) or Multiprotocol Label Switching (MPLS) backbone. It’s clear that carriers are moving in this direction already. For example, Qwest Communications International Inc. (NYSE: Q) says it plans to migrate all of its ATM, Frame Relay, and private-line services over an IP/MPLS core. Other carriers -- including BellSouth Corp. (NYSE: BLS), SBC Communications Inc. (NYSE: SBC), and Verizon Communications Inc. (NYSE: VZ) -- have announced plans to use MPLS as a convergence technology, as well.

But the question remains. Who will carriers choose to build out their infrastructures? Clearly, the market leaders, Cisco Systems Inc. (Nasdaq: CSCO) and Juniper Networks Inc. (Nasdaq: JNPR), will win a significant amount of this business, especially in North America. Many of the interexchange carriers that have deployed IP backbones have installed generations of Cisco and Juniper gear in their networks. It’s also clear that the regional Bells are already laying their bets with these incumbents.

“Caspian has staked a claim on this flow-based hardware architecture,” says Michael Howard co-founder and principal analyst at Infonetics Research Inc. “They’re the only ones I know doing it. It seems like a good approach, but now we have to see if anyone wants to buy it.”

Caspian says it is in a total of 35 carrier trials right now, though it has not yet generated any revenue. The company was supposedly working closely with Cable & Wireless (NYSE: CWP), but analysts question how helpful this will be, given C&W’s financial and organizational issues right now (see C&W Puts New Duo in Charge).

The Asian market is likely to be where both Caspian and Procket find success first. China, Korea, and Japan have all seen an explosion in IP traffic growth as a result of broadband deployments in metro networks. Procket has already announced it is focused on the Japanese market.

The success of these startups may come down to cash in the bank. Caspian has raised about $262 million, Procket roughly $272 million. Both companies have trimmed their workforce and are conservatively managing their cash.

“I don’t think there is a private company out there without cash concerns,” says Erik Suppiger, an analyst with Pacific Growth Equities Inc. “I can’t say for sure if either of them will run out of money, but I’m sure they are monitoring it very carefully.”

— Marguerite Reardon, Senior Editor, Light Reading

Want a deeper understanding of MPLS? Check out the first module of Light Reading University's course on the topic. Click on this link to check it out for free!

Page 1 / 9   >   >>
ARBoy 12/5/2012 | 12:15:46 AM
re: Caspian Comes Out skeptic is on the money here. Caspian let more than 40% of their workforce go including many sales people. The C&W deal fell through a long time ago. Old news and the inevitable end of Caspian is only a matter of time.
skeptic 12/5/2012 | 12:15:46 AM
re: Caspian Comes Out
- I dont see why you bought into this "caspian
comes out" nonsense. They have been out in the
open for a very long time. This is almost a
re-launch. They re-did all the graphics on their
web-page, but there is little or no new content.
They promised an IPO. They promised customers.
They launched the product. And now they claim
to be coming out of stealth?

- The micro-flows are maintained through a
passive mechanism. Its not like RSVP. Its like
they try to watch packets going by and assign
them to flows as the scheduler thinks best.
Any passive state mechanism like this is very
open to DOS attacks. You can change the
core router's traffic handling behavior by
throwing the right packets at it.

- There is a tradeoff in how much the system
knows about a microflow vs. how many microflows
can be supported at any given time. Saying you
can handle "millions of flows" sounds nice, but
the memory requirements for doing it don't
seem to add up.

- C&W is a dead issue. C&W isn't going to be
buying anything from them for a long time. They
bet alot on C&W and its not going to happen.

- They can talk about trials and asia, but they
didn't mention a single name today.

mu-law 12/5/2012 | 12:15:45 AM
re: Caspian Comes Out There are a number of existence proofs illustrating that a flow-based scheduler is difficult or impossible to implement for real world internet applications...and I don't get the impression that cold fusion has occured here.

In public network applications, the number of flows can scale with the volume of packets you are forwarding... and it tends toward infinity with time; the horizon at which flows are aged, and speed with which they can be created or destroyed determines whether this will be successful.

If at any point, you box should happen to fall behind, then all of Skeptic's predictions manifest themselves, even without malice in the equation.

This would be why vendors with great ideas like this have either evolved their architecutre, or evaporated... remember Ipsilon?

bulwark 12/5/2012 | 12:15:44 AM
re: Caspian Comes Out And how do you really test box like this? If the box is supposed to handle millions of micro-flows, they have to maintain the state of those flows in the memory as Sceptic pointed out (micro-flow maintenance and cleaning mechanisms – each flow must have an expiration time after the last packet of the flow if received so the flow state can be deleted and memory freed). I’m not aware of any test equipment that can continuously generate new flows at oc-192 rate to simulate real Internet traffic. So there is a possibility that the box chokes up when put in a real production network where the real Internet traffic consisting of millions of micro-flows is present.
IP_freely 12/5/2012 | 12:15:43 AM
re: Caspian Comes Out Isn't it ironic that this announcement is all timed to respond to Prockets release.

I can say that skeptic knows what he is talking about. Assigning a flow to every packet without valid Call Acceptance proceedures makes a router open to simple randomized source DOS attacks. Even common occurences of route flaps will change huge amounts of flow state that will negate any benifits of caching routes. If Caspian were to implement their chips without a programmable front end header parser, it would be very difficult to change any linerate classification mechanisms. It is just very expensive in compute time and memory resources to keep too much state.

The Diff-serv model of router design for emerging services, scalability and QoS makes even more sense today when we have the technology of doing line rate route lookup and classification, which only further diminish any benifit of keeping huge amounts of router state. (think hot, expensive, and monolithic, not like a cloud of cheap simple routers implementing a behaviour)

As to 40% layoff: how mush of an ASIC team does Caspian have, and haven't they been losing talent for a while...

Plus, where did the Bronze head of Larry go?
wainflete 12/5/2012 | 12:15:42 AM
re: Caspian Comes Out The platform does appear to have an enormous amount of features, but somewhere, surely somebody has to provision them? I found it ironic, but not surprising that they have an 18-page "Executive Summary" to explain just the basics of the platform, but only 2 pages in their datasheet for the management product. Or is the assumption that Larry will personally be provisioning each box that is sold?
cyber_techy 12/5/2012 | 12:15:42 AM
re: Caspian Comes Out There are a number of existence proofs illustrating that a flow-based scheduler is difficult or impossible to implement for real world internet applications

This seems to be Cisco like marketing once again. If Cisco can't do something they would comeup with story that the feature is impossible while working to deliver the same after a year or two.

ps: I don't work for Caspian
digerato 12/5/2012 | 12:15:42 AM
re: Caspian Comes Out Flow-based switching? Wasn't that the Ipsilon story?

Also, I don't see why a properly traffic engineered MPLS network can't deliver ATM QoS -- or indeed any other predictable QoS you care to dream up. You only have to have an aggregate traffic trunk for each of the ATM QoSes. Each flow doesn't have to have its own special treatment -- if two flows need the same treatment, you can aggregate them.

What are these people on?


indianajones 12/5/2012 | 12:15:41 AM
re: Caspian Comes Out I agree. Let us say they have solved the per-flow problem, there is no need for it. Just because Larry solved some problem doesn't mean there is a business need for the solution. Anyone remember Lucent Packetstar router whose claim to fame was gazillion queues!!

aggregate QoS is adequate in the core. per-flow QoS is neither necessary nor manageable. If this is their only differentiation, God help them.
skeptic 12/5/2012 | 12:15:36 AM
re: Caspian Comes Out Also, I don't see why a properly traffic engineered MPLS network can't deliver ATM QoS -- or indeed any other predictable QoS you care to dream up. You only have to have an aggregate traffic trunk for each of the ATM QoSes. Each flow doesn't have to have its own special treatment -- if two flows need the same treatment, you can aggregate them.

What are these people on?

1) They convinced themselves that the only way
to build a router past a certain size was to
build a distributed packet processing system.

2) When you build a system like that and try
to scale it, you end up having to solve
mesh utilization issues. And the way they
solved the mesh utilization issues was to
micro-schedule everything across the complex on
a flow basis.

3) Many people who started down that road gave
up early. The problem with the distributed
mesh architecture as scalable router is that
the "router" starts to take on the characteristics
and the problems associated with a pile of
routers. You start trying to build routers
inside the router. And when you reach that point,
you end up questioning the whole concept.

When I get to a point where I have a "router"
that is actually several routers internally
running propritary routing protocols (which
in caspian's case look like MPLS), what is
the value vs. having several routers?

The unique value I see is that the flow
management is adaptive. Its supposed to
automatically identify the flows as opposed to
ATM or MPLS where the flows have to manually
be determined. But its only of value if it
works. Testing/debugging/validating anything
that makes assumptions about micro-flows and
traffic behavior in the internet would seem
really difficult.

Page 1 / 9   >   >>
Sign In