x
Optical/IP

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
www.lightreading.com

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.



mrcasual 12/4/2012 | 9:20:05 PM
re: Bay's ATM Chip Heads Into Battle I can only say that the Bay Solution is extremely competitive from a power, total system cost (note: no exotic RAMS) and real estate perspective. At the risk of sounding glib it really does depend on the application's requirements

If you can, please just describe the number and types
of interfaces on the Montego. That would go a long way
to helping.

All people are looking for is something like the following.
Note: I made up the numbers.

The Montego has:

1 - SPI4.2 interface (bi-dir)
1 - PCI 32bit/66MHz
2 - DDR DRAM (36bits/200MHz bits data on each)
2 - ZBT SRAM (18 bits/133MHz)
....
mrcasual 12/4/2012 | 9:20:06 PM
re: Bay's ATM Chip Heads Into Battle Hi Mr. Casual,
Those states are not the major items in AAL5 SARing.. The main thing is that for each VCC, you need to buffer the cells until you receive the last AAL5 cells.. It is the cell buffer that required the largest amount of memory..


Yep, I did do AAL5 SAR, the first OC-12 one in the world
to my knowledge, but that's a different story.

When I was talking about data structure requirements I
was NOT counting the actual packet/cell memory. Most
(all ?) implementations I am aware of use some kind of
bulk, i.e. cheap, memory to store the cells. The "context"
type memory tends to be more expensive because it
is generally Read-Modify-Write and truly random access
so you can't easily take advantage of bursts.

Sorry for any confusion.
BayMicroPaul 12/4/2012 | 9:20:10 PM
re: Bay's ATM Chip Heads Into Battle I can only say that the Bay Solution is extremely competitive from a power, total system cost (note: no exotic RAMS) and real estate perspective. At the risk of sounding glib it really does depend on the application's requirements.


So as to keep this commercial (and vendor) - free as possible. If you have something specific please hit the website with a "request more information". We'll gladly answer any specific questions that you may have.

Paul
the_thinker 12/4/2012 | 9:20:11 PM
re: Bay's ATM Chip Heads Into Battle You say "no exotic memory". What does that mean? What memory do you use, and how much?
BayMicroPaul 12/4/2012 | 9:20:11 PM
re: Bay's ATM Chip Heads Into Battle I work for Bay and have been watching this thread with some interest. Some of the posted information is correct and some is incomplete. I am sorry for barging in on a user forum, but just wanted to provide some clarification to information that is already in the public domain.

At the risk of sounding like a commercial...

In response to what the Montego is:
The Montego performs 5 basic functions: (1) Classification, (2) Policy Controls [editing, etc] {note these first two blocks are the usual functionality of a classically defined NPU}, (3) Wire-speed packet/segment SAR [does packets, cells or segments], (4) Robust Queue Manager and (5) Traffic Engineering Manager [TM 4.1 compliant, etc. - QoS with CBR, VBR, UBR, etc.] This is on top on a high-speed switching architecture.

In response to the "smoke up my ...":
The Bay Architecture is deterministic regardless of traffic pattern or operation(s) performed. No statistical multiplexing is necessary to achieve wire-rate.

In response to "RAM types..."
No exotic RAM types are necessary to achieve this performance.

In response to "hiding the warts..."
This is not a "God-chip". It is optimized to process multiservice network traffic at wire-speed. Given that you can't program the device to play blackjack or windows. Bay has nothing to hide, if you're interested we can show you what it can and can't do.

I hope that helps. Again, please forgive the intrusion.

Paul
xinant 12/4/2012 | 9:20:12 PM
re: Bay's ATM Chip Heads Into Battle -----------------------------------------------

By talking to someone on the inside, I have confirmed that there is no QDR SRAM. We have someone going to SC2002, I keep you posted on how that goes.

_____________________________________________

This is really a surprise since I have never heard of any other NPU companies did not do that.

Usually SRAM is used for storing the linked list which contains pointers to the payload. SDRAM or DDR is used for storing payload.

If they do not use SRAM, myabe they would use RCMEM or RDMEM. However I doubt whether they can have the same performance.

broadbandboy 12/4/2012 | 9:20:12 PM
re: Bay's ATM Chip Heads Into Battle "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."

---------------------------

Question - does anybody know for sure if the Bay chip supports just AAL5/UBR traffic, or can they do the full range of ATM QoS - CBR, VBR, UBR, ABR, etc?

BBboy
CaboSanLucasBoy 12/4/2012 | 9:20:13 PM
re: Bay's ATM Chip Heads Into Battle =================================================
But given the general lack of information, I have to
be skeptical. It's not going to hurt them to show their
competitors that they are using 2/4/8/whatever DDR DRAM
busses and 2 QDR SRAM busses. (Just speculation on my
part BTW).

The chip is what it is. Don't try to hide its
warts. Your customers will find out eventually.
-----------------------------------------------

By talking to someone on the inside, I have confirmed that there is no QDR SRAM. We have someone going to SC2002, I keep you posted on how that goes.

=================================================
If it truly does all that it claims it can do, and
at wire rate no less, then the datasheet should at
least provide a simple interface picture so that
people could do a first pass analysis of the device
to see if they are legit or are blowing smoke like so
many other NPU vendors out there.
-----------------------------------------------

It appears they acheive this by constraining the problem they were trying to solve - namely wirespeed editing (transformation), metering, marking, etc. for layers 2-to-4.

You are correct many vendors seem to be blowing smoke up my harddrive (or somewhere else for that matter) when it comes to what they really can do with their devices. I know someone who was trying to do wire-speed editing and traffic engineering (~8K queues) with software. Needless to say, that vendor is now not used here for NPUs.

I can't agree with you more about over-hype in this industry that's why we're going to see the set-up at SC2002 and if it warrants it we'll go farther. I'll keep you posted.
sgan201 12/4/2012 | 9:20:13 PM
re: Bay's ATM Chip Heads Into Battle Hi Mr. Casual,
Those states are not the major items in AAL5 SARing.. The main thing is that for each VCC, you need to buffer the cells until you receive the last AAL5 cells.. It is the cell buffer that required the largest amount of memory..
Assuming maximum packet size of 65,535 bytes = 64Kilobytes..
Number of connections = 10K
Total RAM for AAL5 SARing buffer = 64K X 10K ~ 640 MBytes..
Normally, you do some level of over-subscription..
128MBytes is probably enough..
Did you really design an AAL5 SARing engine before??
Of course, if you made some assumption about the max AAL5 packet size being smaller, then , you cell buffer will be smaller...
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
article??????/
mrcasual 12/4/2012 | 9:20:14 PM
re: Bay's ATM Chip Heads Into Battle Point taken. Sorry for the Monday morning grouchiness.

Perhaps I'm a little sensitive here because when I
checked out the Montego datasheet it was very scant
in terms of real details.

If it truly does all that it claims it can do, and
at wire rate no less, then the datasheet should at
least provide a simple interface picture so that
people could do a first pass analysis of the device
to see if they are legit or are blowing smoke like so
many other NPU vendors out there.

The NPU industry suffers, in general, from over hype
by vendors. Many people have been burned by this and
it makes it harder for companies that have products that
actually do what they say they will do.

If Bay's product can do all the things they say it can
do and people are willing to buy it then kudos to them.

But given the general lack of information, I have to
be skeptical. It's not going to hurt them to show their
competitors that they are using 2/4/8/whatever DDR DRAM
busses and 2 QDR SRAM busses. (Just speculation on my
part BTW).

The chip is what it is. Don't try to hide its
warts. Your customers will find out eventually.
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 :-|
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.

Cabo
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.
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  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.


Lucifer              
Lightbearer

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"

Booby:
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).
mrcasual 12/4/2012 | 9:20:21 PM
re: Bay's ATM Chip Heads Into Battle "Clearly because as all peoplr who have worked on ATM know - ATM SAR and AAL (ATM Adaptation Layer) faster than at an OC-12/STM-4 622Mbps rate is difficult to do in hard-wired silicon. An NPU would have some advantages in this area if parallelism could be properly exploited.

This was obviously written by someone who doesn't understand
NPUs.

AAL5 reassembly, while not trivial at OC-192 speeds, is
actually relatively easy compared to NPU design. All you
need to do is keep track of linked lists of ATM cells and
manage the residual CRC-32s (so that you can reassemble
multiple packets at once) and you are pretty much done.

You can brute force an implementation very easily. If
you are trying to be very memory efficient (i.e. use
as few devices as possible) then it gets more tricky
but still not hard to do.

A "real" NPU, i.e. a fully programmable thing that does
packet lookups, edits, doesn't reorder packets, etc., now
that is much, much, much harder to do.

Whether it is 192 or 192c, since all of the framer devices
out there interleave cells on the interface it's not
really any harder to do one or the other. AAL5 SAR is
just not that hard to do.
BobbyMax 12/4/2012 | 9:20:22 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.
teng100 12/4/2012 | 9:20:25 PM
re: Bay's ATM Chip Heads Into Battle "Clearly because as all peoplr who have worked on ATM know - ATM SAR and AAL (ATM Adaptation Layer) faster than at an OC-12/STM-4 622Mbps rate is difficult to do in hard-wired silicon. An NPU would have some advantages in this area if parallelism could be properly exploited. Which I assume Bay has done. It will be interesing to see how much memory they will have on such a card for ingress and egress queuing."

ASIC and NPU are equally capable of doing parallelism.

I would assume it is channelized OC192 instead of
OC192c and it is difficult to achieve that by using so called "parallelism" of many NPU........
Any commects.......
MrLight 12/4/2012 | 9:20:26 PM
re: Bay's ATM Chip Heads Into Battle In terms of the article statement, ""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."

Clearly because as all peoplr who have worked on ATM know - ATM SAR and AAL (ATM Adaptation Layer) faster than at an OC-12/STM-4 622Mbps rate is difficult to do in hard-wired silicon. An NPU would have some advantages in this area if parallelism could be properly exploited. Which I assume Bay has done. It will be interesing to see how much memory they will have on such a card for ingress and egress queuing.

It isn't clear to me if General Dynamics Corp. is providing the proprietary security chip for ATM and it " handles encryption purely at Layer 1.", what chip will be doing the AAL, and which AAL it will be, but I am assuming variable bit rate.

Well good for Bay Microsystems that they were able to find an initial application for their NPU.

In regards to "Luckily for Bay, the legacy networks won out over the IP-based CLECs, creating unexpected demand for ATM and even Fibre Channel". Well ATM and frame relay still would haved formed the core of the telecom carrier's data private-line network for quite a while, so the "Luckily" is irrelevant when it comes to this application. 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?

MrLight :-), shedding light on ATM
fw23 12/4/2012 | 9:20:27 PM
re: Bay's ATM Chip Heads Into Battle >it really lacks adoption in the modern day world.
>I wonder apart from the Govt who else would be >interested.

Since the government is one of the few things
spending money right now, there will be a high
amount of interest.

The problem is that nobody is going to figure
out until its way too late that it would have
been better for the government to fund a new
encryption device than roll out high-speed ATM
all over the world.

indsavvy 12/4/2012 | 9:20:36 PM
re: Bay's ATM Chip Heads Into Battle you really lack an understanding of where the industry is at presently with comments like this. The modern day world is an ATM infrastructure dummy. The promise of IP-everything never materialized and won't for the foreseeable future.

Get with the program sport and do some research before posting. Your credibility is shot!

-savvy
Off_the_shelf 12/4/2012 | 9:20:37 PM
re: Bay's ATM Chip Heads Into Battle Hey walter_100,
"it really lacks adoption in the modern day world.
I wonder apart from the Govt who else would be interested."
------------------
Every carrier in the world (that counts) is looking for this technology. I doubt even Cisco really has it. If this thing really works, Hurray! Maybe there can be some life in the telecom market.
walter_100 12/4/2012 | 9:20:40 PM
re: Bay's ATM Chip Heads Into Battle it really lacks adoption in the modern day world.
I wonder apart from the Govt who else would be interested.
broadbandboy 12/4/2012 | 9:20:40 PM
re: Bay's ATM Chip Heads Into Battle walter_100 wrote: "it really lacks adoption in the modern day world. I wonder apart from the Govt who else would be interested."

Probably nobody, except maybe a few RBOCs, IXCs, Wireless operators, PTTs, etc. (grin)


BBboy
mechanic 12/4/2012 | 9:20:57 PM
re: Bay's ATM Chip Heads Into Battle Another feather in the cap of the Marconi BFS team. OC192c is such cool technology.

Way to go!

HOME
Sign In
SEARCH
CLOSE
MORE
CLOSE