Luminous Cuts Away

Luminous Networks Inc., a startup building metro Ethernet equipment, laid off a little over 20 percent of its workforce earlier this month, according to sources close to the company.

The company confirmed the layoffs but would not divulge numbers. Sources say it's somewhere around 50 employees. This is the second layoff for Luminous in the past six months. The company had another small layoff in December. Currently, there are about 175 people working at the company, says John Hamburger, director of marketing communications.

“We’re fully funded," says Hamburger. "We have a product shipping for revenue. But we had to hedge against the continued market softness, which meant that we had to make some headcount reductions.”

To date, Luminous has raised $148 million in venture funding, $80 million of which it received last June (see Luminous Rounds Up $80M). Hamburger says this should be enough to take it through its next “financial event." And it is shipping products to China Netcom Corp. Ltd. (see Chinese Get Luminous). But Luminous may still have a tough road ahead of it.

The company’s whole value proposition is based upon the adoption of a technology called resilient packet ring (RPR). This technology, which is currently working its way through the Institute of Electrical and Electronics Engineers Inc. (IEEE) standards process, is designed to provide Sonet-like features and protection to Ethernet-based rings (see RPR in the Spotlight). With standardization still at least a year away, some argue that RPR is unnecessary for building out new Ethernet metro networks (see MPLS Spurs Metro Ethernet Debate). Companies like Atrica Inc. say that their devices can offer the same sort of Sonet-like protection in a traditional Ethernet mesh architecture.

Even if RPR takes off, there is still the big question of whether or not RPR should simply be a feature on an existing switch or router or if it requires a standalone box. Luminous seems to take the dedicated box approach, while a number of vendors see it as a feature.

At least four edge routing companies, including Cisco Systems Inc. (Nasdaq: CSCO), Crescent Networks Inc., Redback Networks Inc. (Nasdaq: RBAK), and Riverstone Networks Inc. (Nasdaq: RSTN), have already included RPR-like technology in their platforms (see Taking Routing to the Edge). Cisco reports that it has sold over 10,000 ports of Dynamic Protocol Transport (DPT), its proprietary version of an RPR-like technology.

But Luminous argues that its product is already getting traction in the market. It has announced a contract with China Telecom and claims that it has other international accounts that haven’t been announced yet. Regardless, opponents point out that Luminous still lacks the validation of a large U.S. carrier. Rumors had circulated over a year ago that Qwest Communications International Inc. (NYSE: Q) was looking to test the gear (see Luminous Close to Qwest Deal). But hopes of a Qwest contract have faded as the carrier continues to clamp down on its spending, especially with startups (see Is Qwest Shunning Startups?).

— Marguerite Reardon, Senior Editor, Light Reading
<<   <   Page 7 / 7
jshuler 12/4/2012 | 10:26:47 PM
re: Luminous Cuts Away Forward thinking carriers ARE buying RPR right now, and deploying them in live networks with real, paying customers. We have shipped over 20,000 ports of RPR services. And these carriers are anxious for more. There are just very few carriers with the guts to do this. Others seem to be waiting for someone else to take the first step. Well, someone else has. In fact, if you will identify yourself to us, we can share several names as references.

We can provide excellent savings in edge routers by aggregating traffic from multiple subscriber Ethernet ports to a single GigE router port at the core, using VLAN or MPLS tags to segregate customers and traffic classes. This is a huge savings over point-to-point router ports or even Virtual Concatenation.

Remember, when you provide a T1 VirCat service, you eat a T1 of bandwidth on your ring. With RPR, you can provide EXACTLY that same quality of service, including absolutely guaranteed CIR (but also EIR and MBS!), strictly bounded delay, and 50ms protection. But you can ALSO provide much better bandwith granularity (down to 64kbps), AND you can provide less expensive (to both you and your customer) services where latency may be somewhat higher, or where CIR is probabalistic based on traffic engineered oversubscription. Remember, for traditional data services, the customer who is concerned about delay is worried about maximum delay, not delay variation. Maximum delay is engineerable, even when assigned a lower-than-EF traffic class.

When I said I can share my STS1 with multiple users, I didn't mean just 28. I meant with as many as you want... hundreds or thousands, if the customer CIR is measured in kbps. In fact, the more customers that are sharing a single set of bandwidth, the more predicable the bandwidth loading and the easier it is to traffic engineer an oversubscribed pool of bandwidth, of whatever size.

The point is, you get MUCH better management flexibility and simplicity, MUCH better flexibility in defining and delivering services that meet the price and quality points of your customer, WITHOUT sacrificing ANYTHING that you have today in your SONET network.

If you have a specific network you are building, I'd love to have a shot at seeing if we can pay back our stuff in less than a year.

As for luck... Thanks, I'll take it!
HR_Track 12/4/2012 | 10:26:35 PM
re: Luminous Cuts Away Jay,

Your most recent post has a few interesting quotes. "We have shipped over 20,000 ports of RPR services" and "We can provide excellent savings" and "we can share several names as references".

You sent a global email last week stating that you were no longer with Luminous. Just wanted to point this out so you could correct your statements and refer to Luminous using "They". The company may have let you keep some stock but using "we" implies that you are an active employee of Luminous.
BobbyMax 12/4/2012 | 10:26:35 PM
re: Luminous Cuts Away Regardless of the merits of RPR technology, its acceptance by the carriers is very much in doubt. Selling here and there does not make it acceptable to the rest of the world.
wilecoyote 12/4/2012 | 10:26:34 PM
re: Luminous Cuts Away HR_track, just like an HR person to point something like this out. HR people add no value and you just indicted them all with this stupid post.

Jay made a nice contribution to Luminous and is still there physically. Go back to shuffling papers or whatever else it is they pay you to do.
wilecoyote 12/4/2012 | 10:26:34 PM
re: Luminous Cuts Away HR_track, just like an HR person to point something like this out. HR people add no value and you just indicted them all with this stupid post.

Jay made a nice contribution to Luminous and is still there physically. Go back to shuffling papers or whatever else it is they pay you to do.
konaboy 12/4/2012 | 10:26:13 PM
re: Luminous Cuts Away Jay,

While I certainly agree that what you say about your RPR product is true, it is blindingly apparent that your knowledge of the state of the art when it comes to products in the ethernet-over-SONET space is horribly antiquated.

You seem to believe that the only way SONET vendors can carry ethernet traffic is using point-to-point ethernet mapper cards that carve out NxVTs of bandwidth. I'm afraid that was true in 1995 (before the days of RPR) but no longer. Many vendors have built RPR-like technology right into the SONET boxes, including support for granular connections, CIR, diffserv, etc. Yes, that's THOUSANDS of connections within a single STS-1, not 28!

The other point of yours that really irked me is your statement that SONET provisioning requires manual allocation and configuration of timeslotrs node-by-node along the entire path. Again, very lame and so-1990!

While it might be advantagous for RPR vendors to pit their product up against the rudimentary data capabilities of decade old SONET products, you really ought to do your homework to see exactly why SONET is kicking-butt on RPR even for data-intensive networks these days.

This ain't no RPR bashing. Just an honest reminder that all those SONET R&D folk have not been sitting on their hands since they figu
KBred out BLSR, UPSR, OC192, etc. Yes, they saw the Internet age and they have responded.
jshuler 12/4/2012 | 10:25:49 PM
re: Luminous Cuts Away I don't know what email you are referring to. In fact, I'd like to see it so that it can be traced to the mischief-maker that sent it. I am still an employee of Luminous Networks, and I resent it when people hide behind aliases and make statements of this kind.
jshuler 12/4/2012 | 10:25:39 PM
re: Luminous Cuts Away Konaboy,

I admit that I am guilty of comparing RPR to the vast majority of SONET products that are deployed and running in today's networks, and not to the state-of-the-art stuff that has rolled out over the last few years (although I know well the state of the art 5 years ago, and the stuff you are talking about was mostly slideware at that time).

The one unalterable fact that must rise to the top is that, any time you bolt an Ethernet switch or a router or any other data device on or into a SONET ADM, you must manage your SONET bandwidth allocation separately from your data services. Anything else deviates so far from "standard" that it might as well not be SONET.

It is also a fact that when you do that, you may be able to generate thousands of flows, but how do you guarantee fair access to the bandwidth and SLAs on each of those flows? Even bolting an Ethernet device INTO a SONET ADM does not solve this problem.

Let's take an example:

We have a 4 node OC48 ring: A-B-C-D where D is the Hub node and traffic generated at B has to pass through C or A to get to D, etc. A, B, and C have many line cards providing Ethernet service, and D is the destination for those services. This is that "RPR provides no advantage" scenario that was referred to before.

All of the Ethernet services on this ring are sharing a single OC12 timeslot on the OC48 ring, meaning that this timeslot is being picked up by each node, and the ingress traffic at that node is mixed with the transit traffic and re-inserted into the OC12 for transmission to the next node. This is how most data-over-SONET nodes work today. By the way, the alternative is for each node to have dedicated bandwidth to the hub, which is wasteful because it prevents dynamic reuse of bandwidth at each node. But we digress.

The traffic engineer has two alternatives:
1) traffic limit the sum of all peak bandwidth on all ingress ports to less than OC12. This guarantees that traffic will get through, but also guarantees a very high degree of stranded bandwidth, since the traffic is bursty.
2) oversubscribe the OC12. The problem here is that there is no mechanism to ensure that any individual customer gets anything close to his SLA-guaranteed bandwidth. At best, each individual node can prioritize traffic for insertion into the ring bandwidth queue, but there is no guarantee that upstream nodes have not already filled that bandwidth. The node must then decide whether to (A) throw away ring traffic, which will be arbitrary since there is no concept of fairness that is communicated between ring nodes (unless you are RPR), or (B) throw away local traffic, which messes up your local SLAs, or (C) some combination, which messes up everyone, unless node C (say) already knows how much of the bandwidth from A and B was guaranteed to pass through C and how much was "overflow". But then, how would it know? There is no DE bit in Ethernet like there is in FR. There is no state being kept in the nodes for different traffic flows, like there is in ATM (ATM has different problems). There isn't really any concept of a flow, unless you have MPLS.

So Ethernet switches sharing SONET (or DWDM, by the way) bandwidth doesn't work, whether that switch is inside or outside the ADM.

Again, the alternative is to dedicate NxVT or NxSTS from each node to the hub. At least with this method, each node can oversubscribe that pipe locally, but this is just the same as putting an ATM or FR switch in front of an ADM. You are constantly playing with a balance of oversubscription and bandwidth efficiency. The larger the pipe that you are oversubscribing, the more efficiently you can use it AND the more closely you can set your SLA tolerances, because you are working with the law of large numbers (statistics). It makes most sense to open up the bandwidth as widely as possible -- to the Lambda level -- and share it all with every node. That is what RPR does.

There are proprietary ways to overcome some or all of these issues using MPLS and some special signaling methodology, assuming all the issues are taken into account and all of the Ethernet switches come from the same vendor. That's essentially what each of us RPR guys did. The difference is that for over 2 years we have progressed down a path to converge and standardize on how to do this in the IEEE. All those vendors that have "built RPR-like technology right into the SONET boxes, including support for granular connections, CIR, diffserv, etc" have solved only part of the problem, and in proprietary ways.

I don't mean to slam SONET or Ethernet. Each has its appropriate applications. I am simply trying to educate, here. I welcome being corrected in specific, logical (not ad hominum), non-belligerent terms, by the way.
linkv 12/4/2012 | 10:24:27 PM
re: Luminous Cuts Away ahacket2,

why do you keep posting the same message - you made your point, now you feel the need to beat that dead horse?
kelsayed 12/4/2012 | 10:17:30 PM
re: Luminous Cuts Away I have been trying to understand why RPR is of any importance. If I have an exisiting SDH/Sonet, it is easier for a carrier to use intelligent grroming switches to aggregate the traffic so RPR is not that great in this situation.

Now, if I have a dark fiber, would not it be possible to use cheap GigE switches and construct any desired topology for 1/2 or less the price?? Restoration will come automatically out of Ethernet spannning tree protocol. While, it may not match RPR/Sonet 50 ms, it is a cheap and simple solution. Also, I can see some efforts going on just for enhancing the restoration capabilities of GigE (but I am no expert), so why the bigg fuss about RPR??

<<   <   Page 7 / 7
Sign In