Ciena's Optical Switch Fiesta

Today Ciena Corp. (Nasdaq: CIEN) announced a major contract win with Telefonos de Mexico (Mexico:TELMEXL.MX - News; NYSE:TMX), Mexico’s largest telephone network (see Telmex Picks Ciena). Although details of the deal were not disclosed, some analysts say it could be worth between $20 million and $40 million.

“The value is tough to qualify, but this is definitely good news for these guys,” said Rick Schafer, an analyst with CIBC World Markets. “Everybody in telecom is scrambling to find stability on the top line. Ciena, Tellabs, they’re all really beating bushes to find business.”

The news about Telmex was expected: analysts such as Simon Leopold from Merrill Lynch & Co. Inc. say they have already baked the figures into their models. Deployments of Ciena’s gear have already begun, but the company says it likely won’t book revenue on any of it until Q4 of this year.

Still, the win is noteworthy for a couple of reasons. For one, Telmex is the number-one carrier in Mexico and is considered one of the healthiest telecoms in the world -- it is essentially the national phone company of Mexico. Gary Smith, Ciena's CEO, stated a few months ago that Ciena was going to focus on winning incumbent business. This win, in addition to the AT&T Corp. (NYSE: T) contract announced in February, are examples of this strategy at work.

Second, the contract is specifically for Ciena’s optical switching products. This is a major shift from what incumbents in the U.S. have been buying from the company. BellSouth Corp. (NYSE: BLS) and Verizon Communications Inc. (NYSE: VZ), both Ciena customers, have only bought optical transport gear from Ciena so far. The Qwest Communications International Inc. (NYSE: Q) contract, which was signed in 2000, also started out as a transport win but has evolved to include some switching products. Until Telmex, AT&T was the only incumbent carrier building a next-generation optical network with Ciena’s gear. In fact, the Telmex network is supposed to be very similar in scope to that of AT&T, says Leopold. Furthermore, this news validates Leopold’s thesis that roughly 50 percent of Ciena’s sales will soon come from optical switching.

The Telmex deal also highlights a trend toward border-hopping. The international market for optical transport and switching looks much better for business than North America's does, at least for this year, say analysts. Interexchange carriers such as Sprint Corp. (NYSE: FON), WorldCom Inc. (Nasdaq: WCOM), and AT&T Corp. (NYSE: T) already have too much capacity in their networks. These carriers are also loaded with debt and are likely to cut capital spending yet again this year. On the other hand, the regional Bell operating companies (RBOCs) have plenty of money, but they aren’t ready to deploy new technology. Analysts don’t expect them to start deploying optical switching until 2003 at the earliest.

“I think there is dark cloud over North America,” says CIBC’s Schafer. “China and other international markets are going to be where most of the action is this year.”

Ciena isn’t the only telecom equipment company to announce new contracts recently. Juniper Networks Inc. (Nasdaq: JNPR) and Cisco Systems Inc. (Nasdaq: CSCO) have both recently announced contract wins for their core routing gear (see COLT Deutschland Picks Cisco and Juniper Wins in China, Europe). Service providers like Yipes Communications Inc. are coming out of bankruptcy ready to do battle (see Yipes Reborn – Amid Accusations. And others such as Level 3 Communications Inc. (Nasdaq: LVLT) are getting cash infusions to keep them afloat (see Buffett Boosts Level 3). But analysts say not to get too excited.

“Are things turning around?” said Merrill Lynch’s Leopold. “Right now I don’t see enough indicators to suggest that we are coming off a bottom. I want to be able to say yes, but this isn’t over yet.”

Ciena’s stock was up 0.38 (7.97%) to $5.15 today.

— Marguerite Reardon, Senior Editor, Light Reading
Page 1 / 2   >   >>
Raymand 12/5/2012 | 12:45:11 AM
re: Ciena's Optical Switch Fiesta GMPLS is simply a standard for providing label switched paths through networks that include both routers and wavelength routed switches (i.e. slow MEMS or other optical switching technology).

These paths are set up prior to data being transported and are recorded in forwarding tables within routers and switches. Thus GMPLS is a tool for traffic engineering, not routing. A router will prefer to use GMPLS or LDP determined paths within its forwarding tables since label switching is far faster than algorithmic routing.

As labeled packets arrive, the router/switch forwards the packet via a simple table lookup and label swap. No connections have been set up or torn down - only logical paths have been used, like driving directions.

If the box which is using GMPLS has a forwarding engine to process incoming packets, then it will forward labeled packets exactly as a router does -since - switching them to the various output ports on a packet-by-packet basis. If the box only has a wavelength cross-connect, then it will forward the packets based only on their incoming wavelength and incoming port.

Things get interesting when the box which is using GMPLS has both a forwarding engine and a fast (nsec) switching wavelength cross connect. You are combining two key components of what makes up the holy grail, an optical packet switch (OPS). Unfortunately, in real router/switches, the data gets held in memory while the label swap/route is done. Optical buffer memory is impossible today and may not ever be solved in a practical manner.

A way out of this dilema is to look at Optical Burst Switching (OBS) or more properly its GMPLS compliant embodiment Labeled Optical Burst Switching (LOBS). In both OBS and LOBS, a new protocol called JET (just enough time) organizes the headers to travel on a single OEO wavelength so that normal electronic processing & routing can occur. The data (aggregated into bursts when multiple packets have the same Forwarding Equivalence Class, FEC) then travels via the same fiber but on other wavelengths that are then transparently switched paths by the fast optical cross connect. The switching configurations are set up by the headers traveling ahead of their respective data bursts and last from the time the burst is due to arrive at a particular switch, until the burst is do to have past + guardbands.

This approach allows one to contstruct packet/burst switching networks that have hundreds of wavelenghts with only one wavelength being OEO. Burst assembly also has the benefits of lowering the header processing load on the OEO channel as well as lowering the burst collision probablility so that an OBS or LOBS network is more efficient than even an IP or OPS network.

Some posters have said that Optical Burst Switching has been tried but they are incorrectly referring to either Flow Switching or to OBS attemps using protocols other then JET. Globally OBS researchers are converging on JET. OBS & LOBS seem like the best solution for converging both packets and circuits switching into a single transparent and bandwidth efficient network layer.

I see a lot of missinformation posted on this topic so I hope this helps.


Everybody Loves Raymand
skeptic 12/5/2012 | 12:45:09 AM
re: Ciena's Optical Switch Fiesta Some posters have said that Optical Burst Switching has been tried but they are incorrectly referring to either Flow Switching or to OBS attemps using protocols other then JET. Globally OBS researchers are converging on JET. OBS & LOBS seem like the best solution for converging both packets and circuits switching into a single transparent and bandwidth efficient network layer.

Except that every attempt at OBS so far has
ended in failure. You can call it by a new
name, but its still the same old idea. The
efficency in building the bursts is still bad.
The increases in latency due to buffering bursts
are bad.

And in the end, what your giving people with
burst switching is less than they can
get by directly linking every major core router
together with fixed optical paths. Wavelengths
are cheap thanks to DWDM. And you don't
necessarly need optical switching to eliminate
transit OEO events in the network.

Raymand 12/5/2012 | 12:44:47 AM
re: Ciena's Optical Switch Fiesta I failed to address your point about wavelengths being cheap.

Yes wavelengths are cheap but to directly connect via wavelengths, i.e. wavelength route, makes connections very expensive if the connection is not filling the wavelength. This approach quickly becomes untenable as you scale the number of connections -- (so in the real world, people re-introduced OEO -- which for a 10Gbps line card is $125K each -- hardly cheap)

NOTE: If I have missunderstood and instead you simply want to point-to-point connect routers, then you have an extraodinarily expensive OEO network.

Back to Wavelength Routing (which helps bypass some line cards) but still doesn't scale:

Essentially, you are saying that concrete is cheap enough to build a separate road (wavelength) from my house (enterprise or CO) to every other destination I may ever wish to visit. No one else shall ever share any of my roads unless they are on the path from (or to) my house and the destination I specifically built the road to. Thats what wavelength routing is.

Its far cheaper to build highways where cars can share the lane (wavelength) without all of them having to have started at the same point and be headed to the same point.

Now as for OEO, when I get to a highway interchange, I think it is far more efficient for me to individually decide to turn right or left or go straight (i.e. switch) without having to exit the highway, pay a toll (OEO), ask for directions (route) and re-enter the highway. In OBS, I leave my house with a set of Mapquest driving instructions that tells me when to turn. I don't have to stop and pay OEO tolls and direction asking packet processing delays at every highway intersection.

Instead, I pay for all of my packet processing delays up front (and no more) as I get Mapquest to print out my driving directions before leaving home. I don't have a guarentee that I wont hit traffic or suffer a horrible roadside accident, but so far our highways have been a reliable mode of transportation. If I am a VIP, I can always get a police escort to guarentee my arrival on time.

Everybody Loves Raymand
Raymand 12/5/2012 | 12:44:47 AM
re: Ciena's Optical Switch Fiesta Somehow I lost my earlier partial response... so I begin again.

If you claim that Flow Switching and other earlier burst/flow efforts are close enough (for government work) to be called OBS and thereby support a conclusion that OBS does not (much less cannot) work then your opinion is................ difficult to support.

To that point, I would be very interested in your listing of "all the attempts" at a concept that was only just invented in 1997.

To my knowledge, only Johnathan Turner has attempted to build and OBS test bed and his approach was to do it using off-the-shelf technology. Unfortunately, no off-the-shelf fast optical switching fabrics exist. In addition, Turner used his JIT protocol and not JET. He in later publications began to modify JIT to incorporate JET like behavior.

Now some companies have produced fast switching fabrics: Accelight, Trellis, Photonami, Chairo... (some with greater technical success than others), but they were not building OBS equipment. Typically they were trying to build switching fabrics that could scale better than electronic approaches. In the case of Accelight and Chiaro, their internal fabrics are mono-chromatic and are surrounded by OEO.

Photonami tried to pursue a variation of OBS which was single hop capable but it was certainly not JET or multi-hop capable. They closed their system efforts very shortly after announcing that they were doing OBS.

As regards latency...flow switching and burst switching approaches which require explicit acknowledgement prior to burst launch DO SUFFER excessive latency due to the round trip time of the path set up. OBS HOWEVER, does not.

OBS launches bursts without prior acknowledgement of a path being successfully set up. Its paths are set up on the fly by a burst control packet that leaves early (via the one OEO control wavelength) while the burst catches up. At the egress node, the burst catches up to the control packet so that the LATENCY MATCHES packet switching.

In any new networking method, a number of issues must be addressed in order to implement the method in a practical and robust manner (networking is an NP complete problem afterall). Some of these issues are: Scheduling, Recovery,
Quality of Service, Class of Service, Packet Processing, etceteras.....

As most of this fundemental work is only just now being published in academic journals, it seems hard to believe that your claim that every attempt at OBS so far has failed is valuable since it is clearly based on a data set of perhaps 1.

"I flap my arms but cannot fly,... thus man cannot nor ever shall fly by any means."


Everybody Loves Raymand

road__runner 12/5/2012 | 12:44:42 AM
re: Ciena's Optical Switch Fiesta Raymand

These analogies are nice but perhaps a more
accurate comparison would be to a
special kind of trains system as follows ?

The train has to wait until there are enough
passengers aboard to make the trip cost
effective for the train company (alternately
there is the whole concept of making global
time tables for the train system which I don't
think you want to emulate in a packet network).
If trains don't leave frequently enough and you
don't know how long after you reach the station
the train would leave, you feel it might have
been better to just drive on your own.
Alternately if they have trains going to every
possible destination every 5 minutes the train
company loses money.

Further in this special system a train has to send a special little engine ahead of itself once it looks like it is getting ready to leave
and hope that the engine can clear the tracks
in time when the actual train comes along.
So there had better be plenty of tracks
(sitting idle most of the time) to make
sure there aren't collisions and reaching
every popular destination.

The train system makes sense in some
parts of the world and individual cars in
other parts. Equivalently you could build scenarios where OBS type stuff makes sense
and where it doesn't.
Raymand 12/5/2012 | 12:44:33 AM
re: Ciena's Optical Switch Fiesta Road

I like accurate analogies since they help people apply knowledge from their own experiences. Innaccurate ones drive false understandings.

I like highways with variable length cars since trains typically don't have multiple parallel tracks. In using trains though, the train will switch directions only when they come into stations at full speed if they are only passing through. They don't have to have a separate track to each possible destination station. (From Phila, I can take a train through New York on my way to Boston...I don't have to have an entirely separate track.)

In looking at your trains analogy however, some points:

In OBS, the train doesn't have to wait for sufficient traffic to arrive to make it cost effective. The train delay criteria typically is a combination of criteria such as 1) what is the much delay can an arriving passenger tolerate (typically 10 usec to perhaps 1 msec) or when does the variable length train length beyond a threashold length (say 1 Mb).

Once ANY passenger's delay limit or the train length limit is reached, the train launches. Note: different classes of passengers may have different delay tolerances etceteras.

There is no additional cost to running a train with just one passenger and OBS supports this perfectly well. When traffic is zero, no trains leave and your financial backers ask questions as to why you built a network with no customers.

When traffic is scarce, trains leave with one passenger and the efficiency is similar to packet switching. When traffic increases, trains leave with more than one passenger and the efficiency is better than packet switching (and the packet drop probability is lower). An OBS network can operate with negligible packet drop probabilities at loads that are 2X that of packet networks (with similar drop probabilities).

OBS also allows for you to establish repeating deterministic train departures (SONET) and guarentee that these trains will never encounter traffic as they travel (by applying an explicit set up and acknowledgement of a periodic circuit prior to launching the first train.) In such a QoS guarenteed case, the set up is similar to SONET or wavelength circuit switching (WCS). However, the efficiency is better (than WCS) since you still are only setting up a sub-wavelength periodic circuit and are not wasting the entire wavelength to carry the one synchronous sequence of trains. In the dead track space between each of the SONET trains, you still can efficiently multiplex other trains onto and off of the tracks.

Note: Relative to circuit switching, statistical multiplexing of data allows you to gain a 3 to 6X increase in bandwidth efficiency when transporting bursty data. If your data is very smooth and Poisson, then circuit switching is extremely efficient (Voice circuits are efficient at carrying voice). OBS can adapt to carry voice efficiently (by setting up a circuit) or bursty data efficiently (by statistically multiplexing).

As regards global synchronization, you are absolutely correct.....its a b*tch....and OBS avoids it like the plague. OBS is strictly based on local, asynchronous clocks. The bandwidth scheduling mechanisms, recovery, QoS, CoS and other operating methods are also strictly local and asynchronous.

NOW...We cannot use our transportation analogy on how to signal with optical fibers as a plan for a real world transortation system since the cars and trains are only light! The network cost is in the lasers at the edge and not the photons. To apply this to physical transportation we would need car or train factories at the edge. I cannot fit such a factory into my garage.


Everybody Loves Raymand
skeptic 12/5/2012 | 12:44:29 AM
re: Ciena's Optical Switch Fiesta Ok. As a start, I was familar in particular
with Turner's work and the work of a couple
startups, research effots and people seeking
money for startups that were trying
to commercialize what were in fact Turner's
ideas. 1997 was six years ago (a lifetime in
this industry) and there have been several
attempts at OBS, particularly at the peak
of optical-mania a few years ago.

Certain of the attempts disappeared without
a trace. Certain of them were never funded.
Many of them were motivated (in my opinion) by
a desire to create something they could
call an "optical router" of some
sort. They were almost all involving MEMS or
some other inappropriate switching technology.
As you say, many of the fast switching people
were off doing OEO's around the fast
switches or building components.

I agree that fast switches probably solve
the worst of the previous problems. In fact,
if you have fast (nanosecond) switching, the
requirement for the "burst" in burst switching
isn't clear anymore. If the switching time
reaches a certain point, you can get rid of the
(bad) notion of building up bursts totally and
are at OPS (optical packet switching).

As far as the rest of it, the scheme does
introduce extra latency in that the control
packet has to leave before the data does. I
totally disagree with your notions about
latency not being an issue. If you seperate
the control from the data and send the control
before you send the data, you are introducing
end-to-end latency in the path. How much
latency depends on what your time budget is along
the control path.

if your doing all the scheduling on the fly,
I'm not sure how you deal with collisions.
Since its optical, once the data starts to move,
it really can't be stopped or slowed. You
also end up with a variable end-to-end budget
(time) for processing the control channel.

As far as issues, I would add to your list a
need for someone to do reasonable simulation work
(particularly if you stay with the burst notion)
to see what effect bursts have on TCP and
on existing equipment mixed in.
Latencies in the earlier schemes appeared to
have horrible effects, but certain researchers
(some of whom didn't understand TCP) preferred
to ignore the issue.

I dont have any problem with OBS as research
as long as the researchers are honest about the
state of their work and don't start seeking money
again for companies/projects before their work
supports doing it.

I personally think that the direction now should
be away from burst switching toward packet
switching using the same concepts. But thats
just an opinion.

Raymand 12/5/2012 | 12:44:25 AM
re: Ciena's Optical Switch Fiesta Somehow I again lost my earlier partial response... so I begin again again. This sucks. One unfortunate misstype and your dead.


Thanks for your post and good points. Let me acknowledge and comment.

Yes, six years is a long time but technology development typically takes longer than product development cycle times. Most technology development time takes place before people ever hear about a topic (unless they are active researchers in the topic). In addition, since we are talking about a new system many things have to mature....fast switching, scheduling, QoS schemes, analog impairments management, recovery.....etceteras.

EXAMPLES: Optical impairment management has not yet matured for transparent optical circuit switching yet - but its getting better. Optical integrated circuits (research basis more than 15 years old) have not reached anything close to deep commercial maturity.

You are correct that many companies were driven by the desire to inaccurately claim "optical router". Many companies were similarly driven to inaccurately claim "booked revenues". Terms like "Photonic Burst Switching" were easily misunderstood perhaps purposfully so. Anyone using MEMS and "optical router" or "optical switch" in my opinion was knowingly letting marketing promote fraud. Perhaps it all does depend on what the meaning of the word "is" is.

An aside: Similar fraud was knowingly being pursued when IP traffic was being claimed to be growing 400%/yr. It was perfectly clear at that time to any layman (me) who looked (again me) that it was 100% and that those saying 400% were purposfully taking advantage of a spike. The press simply parrots so.....they get the whip and not the rope.

Fast Switches are essential but bursts are also very useful. The process of assembling bursts reduces the short range order in a packet stream and thereby lowers the contention probability. Networks such as OBS which are bufferless (i.e. analog) allow you to agnostically carry packets, circuits and analog (i.e. RF) signal traffic (military radar uses?).

Fast nsec switching alone however is not sufficient to enable anyone to build an optical packet switch (OPS). You also need optical synchronization, optical header processing, and optical random access memory.

For synchronization you need to be able to sense a packet syncronize to it, grab its header (while the data keeps moving), process the header, update the header and then stick the header back onto the still moving data packet. This is expensive but doable. If your going to support synchronous traffic, you then also need to be able to resyncronize (speed up or slow down) the packet to the spacial clock tick. A more difficult problem than the header pick off.

For optical header processing you need to be able to read the header optically and then write the new header. If you do this with OEO, then you might as well OEO the whole channel and go back to electronic packet switching. Also, optics are not known for their logical processing power. This is a very expensive and difficult task though it has been demonstrated in various experiments.

NOTE: Since headers represent only about 1/1000th of the bandwidth on the network, OBS simply collects them into a single channel and uses essentially traditional OEO processing. If you keep the header attached, you force OEO onto every wavelength at every node. There is a tremendous economic incentive to decouple headers from data.

O-RAM: For optical random access memory there is no existant solution....light does not like to stay still. Many have used FDL's to let a data packet loop around while a header is processed, however, FDL's are not random access. They are strictly discrete time access and so are not as flexible as electronic memory. In addition, if a second packet arrives while a first is in the buffer, you have collision or buffer overflow. You can add FDL's but in todays routers, buffer memories are hundreds of megabytes deep and they are not getting shorter. FDL's are an expensive, unscalable and fundementally less flexible substitution than real O-RAM. OPS solutions which rely on FDL's very rapidly end up dropping packets under load. Thousands of FDL's on each channels seems economically challenged and is functionally challenged. (Random access lets you much better resolve contention problems by precisely delaying one packet until an earlier packet has left.)

Latency -- OBS has exactly the same end-to-end latency as packet switching (or better). The burst delay is equal to the sum of the packet header processing times along the path (plus a jitter guardband). In OBS, the front of the data burst arrives at the destination at the same time as the front of the first data packet. The other data packets in the burst even arrive before they would have arrived in a packet switched network. Where the data burst is in time prior to arrival is not relevant.

Collisions, CoS, QoS,.... These are critical topics that must be addressed before one could contemplate pursuing OBS. I believe that they have been.

Packet Drop Probabilities: Many simulations have shown that at the threshold where packet dropping becomes non-negligible, an OBS network is carrying twice the load of a packet switching network. This result has been attributed to being due to the act of burst assembly reducing the short range order in the traffic.

Contention Resolution: When bursts do collide, even though it is less frequent than packet collisions in a packet network, you can resolve the conflict by a number of methods such as deflection routing, FDL's if they are available, and partial burst dropping. Certainly even with these steps, at high loads, bursts will start to drop just like on todays packet networks BUT the load threshold is higher. In addition, there are also methods of proactively performing contention avoidance by managing how you launch bursts in the first place and resulting in further gain.

WHEN you absolutely must guarentee arrival then you can reserve a periodic circuit, and back up path, and you will exactly have SONET QoS for that time slot and the back up periodic circuit as well. The rest of the network resources will continue to statistically multiplex and perform with burst network efficiency.

There is always more to talk about and I agree with you that researchers who are seeking money should be absolutely straight forward about where their technology is and what it can really do.

At the same time, it does take money to perform analysis on real network traffic traces and model real networks to prove robust behavior and economic benefits in a real customer's topology.

I think a bigger danger today is to say no one needs any money for anything since networks today are overbuilt. This situation will change since IP traffic is continuing to grow at roughly 100%/yr. In addition revenues per bit are still declining but cost per bit are not keeping up. When carriers start having to spend capital again to add capacity, their income statements will look even worse than they do today.

We all still need to plan for the future.


Everybody Loves Raymand
LightSwitch 12/4/2012 | 10:08:07 PM
re: Ciena's Optical Switch Fiesta 20 to 40 million? You must be joking. Multiply by a factor of 10 or 20 and I'll think we're heading in the right direction. This deal is small potatoes.
jamesbond 12/4/2012 | 10:08:06 PM
re: Ciena's Optical Switch Fiesta 20 to 40 million? You must be joking. Multiply by a factor of 10 or 20 and I'll think we're heading in the right direction. This deal is small potatoes.


Why are public companies not required to make
this sort of information public? Shareholders
have a right to know.
Page 1 / 2   >   >>
Sign In