Feasible to implement a router on a system on a chip?

Hi,

Is it feasible, or even possible to implement a complete router on a system on a chip (i.e. on one FPGA)? The FPGA would be one of the higher-end FPGAs that exist.

The router should be able to handle BGP and OSPF (i.e. traditional router functionality).

For example, which of the following routers would be feasible/possible to implment on a system on a chip (the router should be able to forward the packets at full speed according to the interface speed) ? :

-A router with four 1 Gbps Ethernet interfaces?

-A router with ten 1 Gbps Ethernet interfaces?

-A router with four 10 Gbps Ethernet interfaces?

-A router with ten 10 Gbps Ethernet interfaces?

Or does it sound completely undoable?

Reply to
dspfun
Loading thread data ...

Google for single chip router turns some interesting results.

Scott

Reply to
Not Really Me

The logic, probably yes.

But the data buffering and even firmware are likely to require external memories implemented in technologies more suited to large scale memory than that used for the FPGA fabric - ie, DRAM of some sort, FLASH of some sort.

You may also need external PHY's.

Take a look at typical consumer router designs - you have a processor incorporating the MACs (and often wireless as well), then add external SDRAM, FLASH, and a multi-port PHY or swith IC. Only the processor ASIC is a really good candidtate for FPGA functional replacement.

Reply to
cs_posting

While I'm new to FPGA's, I'm not new to routers. I don't think this is possible. There's a reason Cisco routers are large and expensive, and it's not because there's a single chip inside. :) (of course it's because their NAME is on it!!) Cisco, or one of the other companies, would have distilled it down to one chip, if they could. I don't disagree that FPGA's and/or ASICs are used in the designs, they most certainly are -- I just think you need more supporting components (processor, big memories, interface chips, etc)

Depends on the class of router. SOHO routers most certainly don't support BGP or OSPF --- normally those routing protocols are supported in mid-to-high end routers. BGP tables can get very big, with full internet tables being 200k+ routes. Calling BGP and OSPF traditional features might be assuming a little much.

Most routers have limited processing power --- even large routers. They normally get rated in terms of packets per second. The thing most vendors play around with is this: how big are the packets that we're talking about? 64 bytes? 128 bytes? full 1500-ish byte packets? This gets complicated when you start talking about access-lists, firewalls, NAT, etc because depending on what deep-packet inspection/modification is going on can REALLY slow things down.

Many router vendors lie like dogs when it comes to performance. I'd be surprised if there are routers out there that can truly handle multiple single gig ports with any type of reasonable throughput. Outside of Internet 2, there aren't many needs for such products.

Most gigabit routing solutions end up being LOCAL routing, between multiple local LANs, and then Layer-3 switches end up picking up the task. But then, you lose many capabilities in terms of filtering, etc

--- which of course would limit the speed again.

No.

No.

Definitely no.

Are you crazy??

Yup. Undeniably undoable.

A couple 10mbps ethernet ports in a SOHO application? Maybe.

Keith

Reply to
Keith M

...

I discovered that the MIPS architecture is widely licensed and used frequently in common embedded applications. For example, the DI-525 router, hardware version C, uses a System on a Chip with the MIPS instruction set, FLASH, and RAM. Lots of flash and ram, like 16Mb RAM and 4Mb Flash (various posts cite different numbers).

Buy one on eBay (make sure it is Rev C) and open it up. There are only 4 or 5 chips. One is a switch, one is the SoC. I speculate that a switch could easily be brought into FPGA.

Reply to
aubrey

I've often thought about buying some of these devices just to have a working platform. If you buy all that stuff separately, it would cost you a fortune. Those people hacking those devices are pretty crazy in their reverse engineering skills.

Yeah 16mb of ram and 4mb of flash is a lot of memory. However, if you compare it to today's serious routers(anything even remotely close to the OP's idea), it's not nearly enough. I just recently fitted a Cisco with 64MB flash and 256MB DRAM. It doesn't have the most complete feature set either...... and if you look at Cisco's memory roadmap, it will probably need upgraded by 2009. And this was in a router designed to handle T3 speeds. 45mbps.

Keith

Reply to
Keith M

I can see how you might have use for more RAM - storing bigger routing tables, ARP caches, connection trackings, and so on, as well as doing some packet buffering. But I have difficulty seeing how you would fill

256 MB with this sort of thing unless you are switching a lot of 10 GB lines with serious congestions - your aim in the router is to pass packets through without storing them, unless it is absolutely necessary (such as because of differences in line speeds). I certainly can't imagine what you'd want with 64 MB flash - even if you run a non-specialised kernel such as Linux on your router, the kernel, all the networking, routing and filtering code, and the basic configuration tools will fit in about 2 MB. Add another 2 MB for a fancy web interface if you want.
Reply to
David Brown

Thank you all for your input!

The design I had in mind would be a system on a chip plus high-end external memories. It would look something like this:

In the SOC (i.e. the FPGA): Two PPC440 CPUs handling BGP and OSPF (i.e. control plane). The fast path/data plane is all handled in the FPGA-code, i.e. packet forwarding/routing.

The external memories would consist of something like 64 MB Flash, 128 MB QDRII+ SRAM and 1 GB of DDR3 SDRAM (maybe need to adjust some of the sizes).

A 1 Gbps interface means forwarding 64-byte packets at a rate of 2 MPPS. Four 1 Gbps interface -> 4x2 MPPS = 8 MPPS packet forwarding.

A 10 Gbps interface means forwarding 64-byte packets at a rate of 20 MPPS. Four 10 Gbps interface -> 4x20 MPPS = 80 MPPS packet forwarding.

So, how many MPPS (64-byte packets) can a FPGA forward?

As far as I have understood a high-end FPGA with fast external memories should be able to forward packets at a rate of 20 MPPS.

Having four 10 Gbps interfaces means that the FPGA would have to forward packets at a rate of 4x20 MPPS= 80 MPPS, is that not possible?

What would you estimate the highest possible packet forwarding rate (MPPS) to for a single high-end FPGA?

Reply to
dspfun

Cisco's executable images are up to 20mb a pop, and that firmware is stored in the flash. I forget whether 20mb is compressed or not -- it might be. Cisco is the big dog with lotsa features, so they might be an extreme case.

I tried like heck this morning to find the memory timeline/roadmap on Cisco's site, but no can do. However the Cisco 3845 datasheet

formatting link

and see under memory

? Default-64 MB Compact Flash; 256 MB DDR SDRAM

I honestly don't know what the breakdown of why that much is required

--- but can tell you from practical experience that 64/256mb is considered standard for low-midrange (Note I'm specifically excluding SOHO routers) full-featured routers. The Cisco 3845 maxes out around T3 speeds. The larger routers have larger requirements --- but note that memory doesn't scale with bandwidth........ you don't necessarily need more memory to support higher throughput.

However, I can tell you that having support for many different types of modules, many different WAN protocols, VPN support, firewall support, VOIP support, etc etc etc Executable image size and memory requirements can skyrocket. Memory requirements are going to hinge exactly on what features you intend on supporting.

Keith

Reply to
Keith M

You may want to investigate the products Freescale have on offer. You sound like you are trying to reinvent some of their PPC based QUICK and sort of parts.

Dimiter

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

formatting link

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

formatting link

dspfun wrote:

Reply to
Didi

formatting link

I had a little look at the link you gave - the Cisco box shown there does not look remotely like the sort of device I imagine the OP is thinking of. As far as I can tell, he is thinking of a routing packets as fast as possible between networks, not handling the packets on the system itself (except as needed for routing protocols). The Cisco box is for connecting together LANs, telephones, WLANs, WANs and VPNs, and thus needs vastly more software support. 20 MB compressed firmware still sounds a bit bloated (I have routers supporting LANs, WLANs, VPNs, WANs, NAT, firewalls, and many other TLAs, running from about 2.5 MB compressed firmware), but nearly as much in view of all the other stuff it supports.

Reply to
David Brown

(after snipping)

I really don't think anyone could possibly answer these questions. It's worse than asking how fast a race car could go if you use a really big engine. There are just too many variables:

size weight of the car aerodynamics of the car type of fuel type of tires transmission

The same idea with routers. It all depends on the architecture of the router. And what design tradeoffs you make when putting it all together. Don't underestimate the effect any type of filtering would have on the flow. Any type of access-lists, with most of the Cisco designs, require that the CPU handle each and every packet and inspect the rule-list (which can be large, depending on the application) for a matching rule. Don't even get me started on firewall packet inspection, it's much worse. And then you have NAT lookups, and routing decisions to make on potentially HUGE BGP routing tables.

And even after you've decided on how you are going to approach designing the thing, you've got to look at how efficient you are in coding the design. Maybe the particular approach is no good, or maybe the execution of the design just sucks. There are a million factors that affect router performance.

And then you make things harder by going above a 100mbps connection. Many routers don't need gig ports on them (let alone 10gig) because they simply can't handle the traffic. There's been a recent push the last couple years where routers are starting to have gig ports, but it's just because the standard chipsets are supporting 10/100/1000 --- not because they provide any performance improvement.

I've talked with customers who demand a gigabit port on their router, only to find out their WAN connection is a T1 or cable or dsl.

ymmv and hth.

Keith

Reply to
Keith M

Between networks? You mean between local LANs? Or between a LAN and WAN? 99%+ of the routers out there bridge(ahem, route) LAN to WAN. I know these terms start getting diluted when we start cable and DSL, so let's not. :)

There's a big difference between Layer 3 support on a switch (that happens to support BGP) and a router.

I can't speak for the OP, but if he needs BGP support, then he's probably doing LAN to WAN. MAYBE WAN to WAN. But who has single gig or

10gig WAN links anyways? Besides Internet2?

And the Cisco I picked is smack-dab in the middle of their product line, at least for supporting T3 links. Which I picked out of the air. T3 is pretty fast and my contention was that was larger/bigger/faster router is likely to have additional hardware required to support it.

Yeah, I don't think there's any doubt that it's bloated. My real point was that 64mb flash is actually REQUIRED, at least on the Cisco platform, for many of their IOS's. There are several other router vendors who have similar memory requirements, Nortel Networks comes to mind as well.

I fully appreciate the fact that there's a difference between what Cisco and Nortel REQUIRE, and what the APPLICATION might require.

Keith

Reply to
Keith M

I think it is pretty important to establish exactly what is meant by "router", "bridge", and "switch", since I am not sure we have the same definitions (or else I am misunderstanding what you wrote). So correct me if you think I've got something wrong here.

A "bridge" is a device that has two or more network ports, and which passes traffic between the ports (which may be of different types - e.g., WLAN, 100 MBit and 1 Gb ports). It is a Layer 2 (e.g., Ethernet) device, and has no concept of IP addresses. A bridge will typically automatically learn which Ethernet MAC addresses are attached to its ports, so that traffic is only passed to ports that have the destination MAC address attached (broadcasts are passed to all ports). Normally, no filtering or interpretation of the packets is done.

A "switch" is a type of bridge that is specialised for low-latency bridging of Ethernet packets, allowing packets to pass through different pairs of ports simultaneously. It is also possible to have purely software bridges (such as bridges in Linux, which can also have filtering tables).

A "router" has two or more network ports and passes packets between them based on their IP addresses (Layer 3), or possibly other higher layers. The router may also have virtual network ports for vpns, it may also modify the packets (such as for NAT or some kinds of vpn), and it may have filters (a firewall) for the packets.

A "layer 3 switch" is a sort of combined layer 2 switch and layer 3 router, normally with specialised hardware to do the routing as fast as possible.

Given that the OP wants to support BGP, which is used to track layer 3 IP routes, I expect that it is a layer 3 router that he wants to make. Whether it is between different LANs, or between LAN(s) and WAN(s), I don't know - presumably it's for a complex setup, since a common tree hierarchy does not need BGP as there are never alternative routes.

The typical DSL router device is actually a combination of a bridge, a switch, and a router (and is therefore a "router"). You normally get four LAN ports which are connected together by a switch, a WLAN interface which is bridged to the switch, and a router (with NAT and a firewall) connecting the LAN switch to the WAN port.

mvh.,

David

Reply to
David Brown

There is no difference between a switch and a bridge. The former is the more fashionable marketing term. Some early switches where characterised by having cut-through forwarding, but that's almost impossible to do with mixed link speeds, and the reduced latency at the faster speeds makes it a non-issue anyway.

A layer-3 switch is a router. Again, routers are (or were) pass=E9, and switches were fashionable, hence the brand extension for the marketing term switch. "Layer-3 router" is redundant and repetitive.

Devices that route some protocols and bridge other were once called brouters, but I haven't heard the term in years, and bridging is an optional function of most medium and high end routers.

NAT and VPN functions are common on non-low-end routers, although they don't necessarily require much in the way of routing function.

The typical DSL router is really several devices in one box, and is both a bridge and a router in the sense described above. As you described, it's really a switch connecting the Ethernet ports, router (when then heads out to DSL port) and access point. That differs from the prior scenario in that it cannot bridge a protocol out the DSL port (which a proper bridge/router could).

Reply to
robertwessel2

I guess a more sharp question could be, what is the fastest rate an FPGA can forward packets if: 1) No accesses to external memory is required (complete packets run through the FPGA). 2) One access to the fastest off-the-shelf SRAM memories is required. Two, three, four accesses? 3) One access to the fastest off-the-shelf SDRAM memories is required. Two, three, four accesses?

I guess the number of accesses to external memories and the access/ throughput speeds of the memories are the main thing that limits packet forwarding rate an FPGA.

For the racecar analogy, a gut feeling could be that a racecar can be built running faster than 300 km/h, but probably not faster than 600 km/h, a likely speed might be around 400-500 km/h if it is to race agains other cars on a curved track.

Reply to
dspfun

That sounds like we agree on the terms.

As for bridging protocols between the "LAN" ports and "WAN" port on a typical DSL router, the reason you can't do it is that very few people would want to do that. I can't think of any non-IP or broadcast traffic that you would want to share between the LAN and WAN on a normal setup. Once you get to the size of network where there are multiple possible routes between the LAN and external networks, you might want to make use of ICMP packets and BGP in a more flexible way, but even then it's more likely that you'll want to set up specific routes (http over ADSL, email over an SHDSL line, for example). People configuring more advanced networks with multiple WAN lines, multiple globally addressable servers, etc., do not normally by their network equipment off the shelf at their local PC World.

However, it's mostly just a matter of software - I regularly use openwrt on LinkSys WRT54GL wireless routers. The hardware is cheap and reliable, and by replacing the firmware with openwrt, I get all the flexibility I could need. Typically I want to set up more restrictions (such as separate independent LANs) rather than allowing more traffic through, but pretty much any networking setup is possible once you have low-level access to a Linux setup.

Reply to
David Brown

On at least some models, the images are compressed, and in compressed form occupy more than 20MB.

Reply to
Eric Smith

Well the definitions mostly were generic, and not specific to the "typical" DSL router. The typical DSL router does only IP out the WAN side, not least because that's all the ISP at the other end supports.

OTOH, bridges in general (and non-IP routers) are often used to move non-IP traffic across WANs. There's certainly less of that then there used to be, especially in proportionate terms, but some of use still run things like straight SNA over our WAN links (although you can tunnel SNA over IP these days), often in parallel with routable protocols like IP.

Reply to
robertwessel2

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.