Bay's ATM Chip Heads Into Battle

An obsession with technology is about to pay off for network processor vendor Bay Microsystems Inc., which has scored an unusual design win with the U.S. government.

Bay and its competitors tend to sell to equipment makers, not to network owners directly. But Hank Dardy, chief technical adviser for IT and computation at the U.S. Naval Research Labs, liked the fact that Bay's Montego chip incorporated a component called a SAR (Segmentation and Reassembly), something that's still a relative rarity at OC192 speeds.

The SAR isn't really as painful as it sounds. Basically, it helps take apart or put together ATM traffic streams. So it's required on either end of a transmision line. Bay's integrated network processor and high-speed SAR put it in an elite category of bulked-up, ATM-ready network chips.

The government's users -- including the Department of Defense and other agencies that Chuck Gershman, Bay CEO, was skittish about naming [ed. note: they'd have to kill him?] -- are on an ATM network that's being upgraded to OC192. Rather than switch to something like Internet Protocol (IP), the government is sticking with ATM, having enlisted General Dynamics Corp. to craft a proprietary security chip for ATM that handles encryption purely at Layer 1.

"They said they had been looking for something like this for the better part of a year. They were thinking it didn't exist," says Gershman.

Dardy confirms that he had been seeking the necessary pieces of the OC192 network. He also says that, while some companies -- like Cisco Systems Inc. (Nasdaq: CSCO) -- have their own ATM SARs at that speed, it appears no merchant chips other than Bay's fit the task.

Most network processors claim to have ATM support, but Bay looks to be on the cutting edge of OC192 capabilities. "Out of all of them, Bay has a very strong solution," says John Metz, president of consulting firm Metz International.

If Montego really is that good, it's because Bay emphasized ATM from the start, having never believed in the all-IP network. While most network processors were engineered with Internet Protocol in mind, Bay chose an approach that concentrated on multiservice networks and the existing ATM infrastructure.

"We just saw that this other model was there," Gershman says. No other network processor company seemed interested in ATM, except for Agere Systems (NYSE: AGR/A) -- the spinoff from Lucent Technologies Inc. (NYSE: LU) (see Lucent Christens Its Spinoff).

Given its goals, Bay needed to build a processor that could handle massively channelized traffic while keeping ATM circuits intact. As a result, Montego juggles thousands of queues based on destination. In contrast, Gershman says, an IP box might accommodate thousands of microflows but will send traffic to just a handful of "next-step" destinations.

Luckily for Bay, the legacy networks won out over the IP-based CLECs, creating unexpected demand for ATM and even Fibre Channel (see The New Legacy Network). That's brought ATM into the sights of larger network-processor players such as IBM Corp. (NYSE: IBM) (see S3 Adds ATM for IBM)

"Agere was one of the first ones to come out [with ATM support], and that was their strength," Metz says. "Now everybody is gunning for them."

Bay hasn't had an easy time of it. Bay missed its original target of mid-2001 (see Network Processors Proliferate), and the dramatic effort to finish its chip became the subject of a week-long feature series in the San Jose Mercury News. The first samples of Montego finally arrived last March (see Bay Joins the Big Leagues), and Bay was demonstrating OC192 capabilities by May.

Bay's win will also include a set of network-interface cards for connecting supercomputers directly to the ATM network, something that's easily crafted using the startup's existing technology, Gershman says. The government is even interested in seeing what Bay can do at OC768 (40 Gbit/s). "There is a strategic pull in certain organizations to move the technology forward, if you find the right people."

Bay will be giving a hint of its technology at SC2002, the supercomputing conference in Baltimore next week. The startup will be in the Marconi plc (Nasdaq/London: MONI) booth with an elaborate setup connecting SGI supercomputers to a Marconi ATM switch at OC192 speeds.

— Craig Matsumoto, Senior Editor, Light Reading

Want to know more? The big cheeses of the optical networking industry will be discussing multiservice switching at LightSpeed Europe. Check it out at http://www.lightspeedeurope.com.

<<   <   Page 2 / 3   >   >>
gea 12/4/2012 | 9:20:20 PM
re: Bay's ATM Chip Heads Into Battle "There are severe dispersion problem with OC-768. This makes OC-768 unusable. It is not an approprate nether for the nor the edge"

You are an ignorant, rambling, and uneducated old fool. The problem you speak of is known as Polarization Mode Dispersion, and with PMD compensating devices OC-768 is workable long haul.

But that's not why you are an idiot. The fact is that OC-768 IS going to see some heavy intra-office deployment one of these days, where PMD is a non-issue (ie, over a few hundred meters or so). This will be to reduce the number of router and switch interfaces greatly.

After that, we'll probably eventually start to see OC-768 creep out into the Metro, but I believe that's going to take a while (I'd say 5 years before we start to see real OC-768 rollout).
lucifer 12/4/2012 | 9:20:19 PM
re: Bay's ATM Chip Heads Into Battle


However, the first incremental increase I expected for ATM trunking was to OC-48 and not OC-192c, so where are the OC-48 ATM ICs in all this?

OC48, OC48c (and its SDH equivalent, STM-16(VC4-4c and VC4-16c) is commercially available in ATM switches from&nbsp; Nortel, Marconi, Alcatel, Cisco and Lucent... Has been for some time and is quite widely deployed as core network infrastructure for ATM and FR networks as wellas for IP infrastructure.


gea 12/4/2012 | 9:20:18 PM
re: Bay's ATM Chip Heads Into Battle Lightmaster:

I agree with most of your post. Actually, I also believe that Intra-office we'll probably see OC-768 over lower-speed parallel VCSEL links. This is also why I snapped on Booby...OC-768 does not equal 40Gig TDM necessarily.

As for the "traditional" progression for OC-48 and OC-192, I think this may not end up being true for OC-768, precisely because of the cost for PMD compensation (PMD is a dynamic phenomenon, so any compensation schemes would seem to inherently require PMD monitoring and dynamic compensation). This is also why I eblieve it may be a while before we see it take off. (I also believe that the thing that will cause more of a need for OC-768 will be the need for fat packet or maybe cell interfaces, and that will likely only occur after a large move towards MPLS_like broadband occurs.)

HOWEVER, apparently some of the ULH folks like Corvis and Innovance have been demonsttrating ULH 40Gig (using RZ and other "new" signal formats). SO we may see it go ULH first, then creep 'downward' a la traditional modes.
lightmaster 12/4/2012 | 9:20:18 PM
re: Bay's ATM Chip Heads Into Battle gea,

Your proposal that OC-768 will see use in short intra-office connections goes against the grain of what is being pushed in the standards both by carriers and vendors. The move seems to be towards cheap technologies like VCSEL arrays, using parallel low speed interfaces that appear to the router/switch as a single interface. It's not a matter of dispersion, it's a matter of cost. If you are arguing that the framing will be OC-768, we may be in violent agreement, but physically it will not be a 40gig signal.

If OC-768 follows the same path as OC-48 and OC-192, it will happen first in long haul. The economic case for fewwer high speed channels has more affect there, but also introduces the most challenges (channel spacing, amplifier spacing, power issues, etc.)

OC-768 has similar issues with dispersion running on newwer fibers (LEAF, truewave, etc.) that OC-192 had running on the old SMF, albeit they were primarily chromatic dispersion issues. These issues were eventually overcome with new fiber builds and better transceivers. PMD compensating devices are incredibly complex and expensive today. Even today, most carriers use high channel counts of OC-48 on fiber routes with PMD issues rather than expensive PMD compensation for OC-192.

The best way to fix the problem is with new compensating fiber, or some not-invented-yet cheap PMD compensation, and I don't see this happening for a few years.

Still waiting for OC-192 to be widely deployed in the metro... OC-48 still dominates. Hard to see a jump to OC-768 before that happens.
CaboSanLucasBoy 12/4/2012 | 9:20:17 PM
re: Bay's ATM Chip Heads Into Battle Teng100,

I think you could have answered your own questions just by visiting their website, hereGÇÖs what I found:

1) It uses a super-scalar pipeline not a "parallel" approach.

2) Based on the information on the website the device appears to be massively channelized therefore able to support from OC192c (not just channelized OC192) down to OC3 and below.

3) I donGÇÖt have the exact details, but from a slide presented in an open session at NPC they showed standard SDRAM as the payload buffer. This was used to SAR tens of thousands of VCs (or IP/FR/Eth queues)

4) Performance is not affected by protocol type or functions performed.

At least thatGÇÖs what I gleaned from their website and the NPC and NGN websites.

priam 12/4/2012 | 9:20:15 PM
re: Bay's ATM Chip Heads Into Battle I'm not an ATM expert (but when did that stop an LR post :-) My back of the envelope says that it would take memory maybe in the 100's of MB to keep the SAR state for 10000's of VCs. So their being able to do so in cheap/standard memory would probably be pretty important.

But I welcome correction...
OneMoreByte 12/4/2012 | 9:20:15 PM
re: Bay's ATM Chip Heads Into Battle > My back of the envelope says that it would take
> memory maybe in the 100's of MB to keep the SAR
> state for 10000's of VCs.

If you want to support ABR (Available Bit Rate service), then your estimate is not far off. But if only bare-bones UBR with AAL5 suport is required, then you can get by with much less state memory per VC.
MrLight 12/4/2012 | 9:20:15 PM
re: Bay's ATM Chip Heads Into Battle In response to mrcasual's post 10

My statement "An NPU would have some advantages in this area if parallelism could be properly exploited." was referring to running NPUs in parallel.

Your response of "This was obviously written by someone who doesn't understand
NPUs." is unwarranted. Pleae check some of my other posts.

But that is beside the point. I did appreciated the rest of the response and I agree with your statement "AAL5 reassembly, while not trivial at OC-192 speeds, is actually relatively easy compared to NPU design.", based on my experience with an OC-3 design.

But here with Bay Microsystems this was a case where there was an NPU looking for an application - at least that was my take on the story.

If Bay Microsystem's was specifically building an NPU for just this application than that is another story.

MrLight :-|
mrcasual 12/4/2012 | 9:20:14 PM
re: Bay's ATM Chip Heads Into Battle > My back of the envelope says that it would take
> memory maybe in the 100's of MB to keep the SAR
> state for 10000's of VCs.

If you want to support ABR (Available Bit Rate service), then your estimate is not far off. But if only bare-bones UBR with AAL5 suport is required, then you can get by with much less state memory per VC.

Dusting off my old ATM brain cells you need....

Per reassembly context:
1. The current status (1 bit for SAR in progress or not)
2. CRC-32 residual

Per VC:
1. Reassembly context ID. This assumes that you can
reassemble N packets in parallel but support M
total packets in the system. M is typically greater
than N.

Link structures for the packet memory are maintained
per cell and you will also need pointer structures
for the packets.

Plug in # of VCs, # of packets, # of active reassemblies
and you get your data size.
teng100 12/4/2012 | 9:20:14 PM
re: Bay's ATM Chip Heads Into Battle just out of curiosity, if they can do
OC192c, why they did not mention in the whole
<<   <   Page 2 / 3   >   >>
Sign In