Slashdot Mirror
Shining Light On (And Through) MEMS
An unnamed correspondent pointed out this story at Red Herring about the small-but-not-nanotech devices known as MEMS (microelectromechanical systems). The article focuses on the use that these devices can have in the form of switches enabling optical routing. At present, despite the huge carrying capacity of fiber optics, routing their signals is slower to accomplish and less developed in general than that for data sent as electrical signals. (But on what planet are devices 1-10 millimeters in size "smaller than the width of a human hair"?)
It's pretty obvious when you think about it...
--
You are not alone. This is not normal. None of this is normal.
I see, sort of a laymen's metric system...
1 Megatruck = Texas
1 human hair = 1 pico Texas
It all makes sense to me now...
Because IP has (about) 40 bytes of header on 0-1500 bytes of data (on most media - as little as 500ish bytes or as much as almost 64K on others), you want to use a 16 byte cell that is 33% header?
Did you know the really big ISPs are switcing away from ATM? Because nobody can make SARs fast enough? Not "they can't make enough SARs per month (which is a problem with lasers for OC48 or 192 now)", but "damm, we can't assemble packts fast enough!".
You are right that nobody wants to route IP thorough a whole big network. Older designs used Frame Relay or ATM to carry the traffic on most hops (making only a few routing choices). There is great hope that MPLS can be used in the future, with IP at the edges still of corse (MPLS is still variable sized packets, almost nobody advocates fixed size packets, the closest I have seen is an ATM like system with two sizes of packets (like 64 bytes and 512 bytes).
Most of your issues with IP are non-issues. Everything but the routed vs. switched, and there are hacks around that.
P.S. my ATM info is about a year old, it may have changed since then, but MPLS still seems to be the trend. Ask Juniper...
Anime hair is thicker than 10 mm :)
Nigecha Dame Da! (Mustn't run away)
Where all of the data starts to branch up into the bigger pipes you eventually reach the biggest ones. Switching data among these pipes can be quite a task consider the large volumes of data and of course speed.
The problem boils down to being able to decipher the destination of the packets as they're coming through. That means "opening" each packet and understanding its destination before you can send it on its way. That "inspection" is time consuming and is the main bottleneck.
Their goal is to use optical equipment at the lesser pipes to encode the data destined for specific other pipes into a colored light (i.e. red for destA, green for destB and blue for destC, etc.). At this level there is less data, so it is feasible.
All of these are then merged into a quasi-white light that is sent though the big pipes. The switches can then simply "filter" the light without having to examine the packets. The red filter sends data bound for destA to destA without even "opening" the packets. The other data is similar filtered for their destinations without being "opened".
Thus, switching at the highest most intensive level is accomplished without mechanical switching or logical understanding of the data.
Have you checked your grandfather's ears lately?
<shiver/>
I'll explain - The primitives most of us are familiar with are AND, OR, and NOT. A NAND gate is an AND gate with its output wired to a NOT gate. Two 1 (on) inputs and you get a 0 output. Any other combination results in a 1 output. Using this gate, we can use the following scenarios:
From these primitives (all from a NAND gate) we can build virtually every logic curcuit needed.
How does this pertain to the story? Optical switching is limited by the inability to look at an IP packet and determine its destination interface because the light cannot be processed (currently) without converting it to electricity, running that through a CPU, and then re-converting it back to optical light. Before optical switches/routers/computers/etc. become redily available at a cheap price (a few percent more than today's equipment), we must have a complete computer foundation based on an optical NAND gate. Of course the technology could be enhanced in the future, but that level could be reached in a short period of time. Does anyone know if such a beast exists today? If not, it would probably drive costs down quickly. If they do exist, why are they not in use today?
JMTC (Just my two cents)
The moving-mirror MEMS devices are inherently more
difficult to implement. You have to have some
beefy control systems to aim the things at your
fibre.
A better way to do it is a Grating Light Valve,
where the MEMS device is a configurable
diffraction grating. This way when you actuate
the GLV, at full deflection you know exactly where
that light beam is going to be. Sony is using
this stuff in all their new theatre projectors.
Silicon Light Machines
They're the GLV people, recently acquired by
Cypress Semiconductor.
Only after the HST was in orbit, and it turned out to have a bad case of spherical aberration, did anyone think to review the manufacturing history. Luckily, our intrepid engineers, astronauts, and optics geeks were able to squeeze in a set of corrective mirrors during HST's first maintenance visit a few year later.
Oh, well, its like they always say. Hindsight is 20/20.
"The only good windmill is a tilted windmill."
It is very common to see rebel flags and racist groups.. that's not a melting pot. Only in metropolitan areas is there any degree of cultural diversity from my experience.
Dacels Jewelers can't be trusted.
I know about MEMS, and they're obviously not millimeters in size. I'm guessing that the person who wrote this article thought m were mm.
Silly mistake.
Perhaps because the focus of the article was on optical switching, whereas TI DLP developers focus on display technologies & color printing. Although there could be some overlap between these approaches (why not just shoot a video image down a fiber pipe w/DLP repeaters?), right now there isn't really any.
... is in the range of 10 to 20 microseconds [50-100 kHz!]. This would mean that a DMD pulsewidth modulation system delivering full light efficiency could achieve over 10 bits of dynamic range.
Here are some basic theoretical bandwidth calculations for DLP / DMD (cribbed from some TI whitepapers - but any lousy math is my fault):
theoretical minimum frame time
In particular, pulsewidth modulated SLMs can have bandwidth constraints that limit the system's ability to display the number of bits necessary to eliminate these contours. This limit is set by the switching speed of the mirrors (nearly 18 microseconds) and the data input structure of the DMD. With the current input structure and memory-multi-plexed DMD architecture, the DMD can display 8 bits per color in a 60 Hz sequential color system. In three-DMD configurations, more than 10 bits are possible. One can only determine the number of bits or grayshades necessary when considering the resolution, brightness, and contrast ratio of the display.
2048 x 1152 mirror resolution has been demonstrated. Thus peak throughput bandwidth would be:
2,359,296 bits ~= 2 Mbit(assuming each mirror is one bit)
x
10 bits (dynamic range via pulse width modulation - most current single-DLP systems are in the 8 bit realm; three-DLP systems obviously get 24 bit color)
x
100 kHz (note most current DLP systems work at 50-60 Hz)
~=
2 Gbits throughput (plus error checking, overhead etc.)
Not exactly ready to switch OC-192's and up. I think the real problem is detection on the other end - how do you recognize the subtle color shifts in real time with this kind of bandwidth (our parallel-processing wetware is pretty good at this, admittedly).
#include "disclaim.h"
"All the best people in life seem to like LINUX." - Steve Wozniak
#include "disclaim.h"
"All the best people in life seem to like LINUX." - Steve Wozniak
1024 bytes will suck for carrying an IP packet that is just a TCP ACK (and about 30% of TCP traffic is dataless ACKs). It also sucks for carrying interactave voice traffic (i.e. phones). The duel sized ATM-varient actually has almost all the advantages of ATM at the hardware level. It is *almost* as easy to support two sizes as just one, and a far bit simpler then supporting true variable size packets.
It was simpler to ignore "something like" then to guess how much like ATM you wanted.
It is really a stright forward attempt to get the advantages of IP over Frame Relay without all that complex Frame Relay stuff. And it is simpler then Frame Relay, and ATM, at least if you compair them fairly. At the packet level it is series of 16 bit tags followed by data (over ethernet this lives where the data normally lives, and there is a MPLS protocall number). Each MPLS switch pops off the first tag, and sends the packet out that interface. Simple enough to do cut through routing all in an ASIC without even a CAM involved. ATM needs a small CAM, or a large (but managable) lookup table. Same for Frame Relay. Both have extra fields to mostly ignore.
If you had an ethernet design in VHDL you could probbbly make a (non cut through) MPLS switch in less then 200 lines of VHDL, and definitly fewer gates then 802.1Q (or whatever the VLAN spec is); of corse it would be a MPLS that doesn't let anything else assign it's tags, but hay, what do you want for an hour's work?
All three have complex "call setup" schemes, and fallback schemes for dealing with link failure. The MPLS ones are several orders of magnitude simpler if you take statments like "use BGP to find a normal IP route, and do a trivial conversion to MPLS tags" at face value. Otherwise the MPLS ones are only somewhat less complex. ATM and Frame Relay have the notable advantage of being out there and tested for quite some time now. MPLS isn't over it's teething problems.
The biggest issue that MPLS haddn't fully grappled with as of the, um 1998 or early 1999 MPLS confrence was dealing with circuit failure. As far as I could tell they wanted something that delt faster then an ATM re-route, but without "waisting" half the bandwidth like a protect circuit, or a SONET ring. The big issue is if it takes 30 seconds while routing reconverges and they have to throw away a lambda of data, well, that is just a whole crap load of data to drop.
Oh, and of corse the "until there is a large scale deployment, nobody knows for sure it won't have nasty problems in a large scale deployment" problem. Of corse it's not like a faster ATM scheme wouldn't also have that problem. I mean the first UUNET ATM backbone had serious teething problems, and ATM switches should have been a well tested technology in 1993 (or was it '94?), right?
Granted my networking experence is mostly limited to IP, things you can run on top of IP, and things IP can run on top of. But I'm pretty damm sure of all the statments I've made.
There's some confusion over two concepts here: the time to switch SONET frames, which most people refer to as switching speed, and the time to fail over to another SONET fibre ring when one fibre fails (known as automatic protection switching).
If SONET cross-connects took 50-100ms to forward frames they would be slower than routers, of course.
Most people care about the per node latency - establishing new paths through the network is often done by management systems only, and can take tens of milliseconds upwards, particularly if it's not required for resilience to failure.
Human, n.: Silly looking earth based creature
Through deductive reasoning, I conclude that the answer to this question is ... Earth!. Seeing that Earth is the only planet that has humans. This could help you
Dacels Jewelers can't be trusted.
But on what planet are devices 1-10 millimeters in size "smaller than the width of a human hair"?
You obviously havent seen this guy.
-----
If Bill Gates had a nickel for every time Windows crashed...
How could they leave out Texas Instruments DLP? Over half a million in the field, each with hundreds of thousands of moving parts. See www.ti.com/dlp for more info.
>And - and optical-eletrical-optical switch is not really that slow.
>If you are talking about switching Sonet signals (aka TDM streams - not
>packet streams) then your latency through a node is measure in nano-seconds. Not really "slow"
Actually, more typically latency through a SONET node is 32 microseconds; which doesn't have much to do with switching time.
Switching time is more like 50ms in SONET land, although several times faster than that is a more typical value, and the standards allow for 100ms in some situations.
-WolfWithoutAClause
"Gravity is only a theory, not a fact!"One way of pushing the intelligence to the edges is to use MPLS to control optical networks - the edge MPLS label-switch router assigns an MPLS label in the form of a wavelength, while the core optical switches know nothing about IP and can perform pure optical switching.
Fine, but reliable ATM has ACKs, so a ATM with 1024 byte packets would have 1024 byte ACKs. And would not have TCP ACK compression (which can send half as many ACKs, or less, if traffic is moving fast enough), and will miss many of the other fine TCP features.
My only dirrect experiance with a reliable ATM product was wholey negitave. It managed to carry about 2Mbits over a 16Mbit pipe. It was a disaster. Replacment with Frame Relay was a wonderful success, carrying almost 16Mbits within two hours of being turned up. Part of this was assuradly the hand-off media (but no more then 8Mbits loss could reasonable be attributed to that), and part was assuradly the poor hardware implmenting reliable ATM, but a large part was the poor reliable ATM itself, and the complexity which made it hard to have a good implmentation!
I know ATM was designed to carry voice phone traffic, but an ATM with 1024 byte headers would not be useful. Too much data would be in it. You can't buffer 1K byte (8K bits) of a 56Kbit voice stream without introducing audable latency. Existing 46 (or is it 36?) byte cells sometimes go unfilled in voice applications.
In other words a fixed 1024 byte ATM cell size will make ATM extreamly unwealdy. Far worse then existing ATM which is widly cratisized for throwing away ~33% of the banswidth.
Big deal. Optically switched IP would switch at the speed of light as well. Neither are likely to happen soon. The only thing that switches at the speed of light is the extreamly unflexable lambda switching, and that is all we are likely to have for quite some time.
It is a way to run IP over X, and I don't think it can run anything but IP. However X is a lot more then ATM or Frame Relay. It includes Packet over Sonet (which is basically a no-overhead no-service protocall), there is also a MPLS over PPP. I think there is a MPLS over ethernet as well. In practice there can be MPLS over anything. In reality it works better with things that can send either variable sized packets (with a large minimum size), or continous streams of data.
MPLS over ATM or Frame Relay is there more to get experaince with MPLS then to actually be used. You are right if you have allready payed for ATM or Frame Relay there seems to be little point in slapping MPLS onto of it before going for IP. MPLS was intended to be run very close to the wire, not on top of a complex protocall that does everything MPLS does and more. MPLS was a reaction to the loss of ATM and Frame Relay at higher speed interfaces.
I had no hand in deigning MPLS, I was merely on the same floor as some of the people that did. But, I have talke to them a bit. (I have only slightly more to blame for PPP over Ethernet)
There is some small chance that if MPLS is wildly succesful, one might want to run it over ATM or Frame Relay just because MPLS links are simpler to mangage. However I think chances of that are slim. I don't expect MPLS to be signifigantly more managable then Frame Relay or ATM, dispite being designed in large part by those that will have to manage it!
ATM is still around but is increasingly used only within the core of large telcos (to deliver Frame Relay, leased line emulation, and so on, which are still very profitable) and for ADSL (I'm posting this over an ATM 25 Mbps connection from my ADSL router).
:). In particular, the issue of voice packet overhead is addressed through:
IP has its challenges but, when combined with MPLS, can do much of what ATM can do - QoS (with some limitations but much more scalable than ATM), traffic engineering (balancing utilisation of circuits all over the network to meet QoS goals or reduce costs), and closed user groups (aka IP VPNs).
There's absolutely no need to ditch IP for other protocols (except for the upgrade to IPv6 of course
- RTP compression (compresses the IP+UDP+RTP header of VoIP packets quite significantly)
- Voice over MPLS (VoMPLS) - puts the RTP payload into an MPLS encapsulation (just 4 bytes of overhead), stripping off the IP and UDP on ingress to the MPLS domain and adding it back on egress.
Also, the much discussed small size of ATM cells is only really of benefit on low speed links - if you have a 1 Gbps link, there is probably no need to pre-empt the transmission of large file transfer packets to squeeze in a VoIP packet ASAP. The IP world has link-level fragmentation techniques (LFI on Cisco's, PPP options on everything else) that mean you get tiny link-level fragments, rather like ATM cells, on low speed links, but avoid the overhead of cells on high speed links.
>Most people care about the per node latency - establishing new paths through the
>network is often done by management systems only, and can take tens of milliseconds
>upwards, particularly if it's not required for resilience to failure.
You, in turn, seem to be confusing two concepts in one sentence here: setting up new paths through the network (which doesn't have to be particularly fast at the moment for SONET- tens of SECONDS is possibly acceptable although not desirable) and the 'switching time' of 32 microseconds or less per node which seems adequate bearing in mind the approximately fractal nature of the internet tends to restrict the hop count.
-WolfWithoutAClause
"Gravity is only a theory, not a fact!""A microprocessor... is a terrible thing to waste." --
"A microprocessor... is a terrible thing to waste." --
GeneralEmergency
It's always been this way -- just depends on what your focus is... I'd say the ISS is focusing on big.
And here's a dose of irony -- The Large Hadron Collider and other such particle smashers : Really Big Things built to look at Really Small Things...
Ask an Astronomer about focusing on small things and he'll point you across the hall to the particle physicist he works with.
-k
Scientific American's current issue contains several articles on optical networks and prospects for switching and routing them without electronics.
--
IP however is really not a high performance protocol. It is routed rather than switched, it has variable size packets, It has a relativly high header to payload ratio, and its dependant on the concept of packet broadcast. It was originally designed as a way to tie together a bunch of ethernet LAN's, and its really not suitable for a low latency, full planet network.
I think something similiar to ATM would make a real 'information superhighway', in contrast to the information dirt trail we have now. I mean video on demand, streaming virtual reality, video conferencing, etc.
One problem is that IP is so deeply embedded into all unix variants. Another is creating a switched optical fiber protocol that would also be suitable for use over a home LAN. With the rise of 100megabit and gigabit LAN's however hubs are essentially gone and replaced by switches anyway- so having one's home network use a switched protocol instead of IP is the logical extension to that.
Taking into account optical packet switching of an asynchronous fixed size packet WAN, contious signal amplification (with erbium or something similiar), and bluetooth wireless gadgets; then we would have our futuristic network.
I can only hope that people realize that IP as it is today, or even IPv6 with its complexity is just not up to the task we have in mind for it. It will be a long process of rewriting, and I would like to see a clear standard for a new non-proprietary protocol emerge.
It's being used already, but only using Red, Green, Blue, would be "not too dense" ;-)
Okay... I'll do the stupid things first, then you shy people follow.
Okay... I'll do the stupid things first, then you shy people follow.
[Zappa]
Can someone explain to be why the human hair is the default unit of smallness? Why not a grain of sand? These are common, small, and relatively uniform. Or perhaps the thickness of a sheet of paper?
-josh
The slowness of fiber optic switching is due to the fact that it is currently done by converting the signal to electrical, switching it, then converting back to optical. There are many technologies currently in development to take care of many of the problems with optical switching. The problem with them is that they have been in development for a while now. I was working on opto-electronic modulator research at Bell Labs in 1996 and the technology is still not widely used. Like most really cool technology, it will be a while before we see any of this in wide spread use.
Ummm, Jon, aren't you supposed to be dead...? - Otter(3800)