G. Watson, N. McKeown, M. Casado, “NetFPGA: A Tool for Network Research and Education,” 2nd Workshop on Architecture Research using FPGA Platforms (WARFP), (February, 2006). [PDF]
Summary
Building custom hardware systems for conducting network experiments as well as for educational purposes is complex and expensive. On the other end of the spectrum, software routers like Click provide easy development interface but fail to achieve hardware-comparable performance. NetFPGA takes the middle ground by providing an easy-programmable hardware platform for developing network devices (e.g., NICs, switches, routers etc.) with reasonable performance and flexibility.
User interaction with NetFPGA was initially designed to be remote; users would design, simulate, and debug their intended hardware logic using Verilog, upload them using a simple web interface to configure FPGAs on remote devices, and then download and observe the results. The initial configuration of NetFPGA, designed on PCB boards, did not have on-board CPU; controller software would run on remote computers connected through the Internet. All communication with the board was via the Ethernet ports. Later NetFPGA was redesigned using PCI boards and an on-board CPU was added.
The authors also mention use of NetFPGA in designing RCP-capable routers and in implementing shunting to enable high-speed layer 7 intrusion detection and prevention system (IDS) by providing a controllable bridge which the IDS can use to manage the traffic.
Any thoughts on the implementation speed, performance, complexity of NetFPGA versus other approaches?
I am learning using Click right now for the course project, and I think its pretty easy to implement stuff using Click. As for the performance of software routers, recent SOSP paper RouteBricks have shown that parallelization can take software routers up to 30-35Gbps speed.
Real hardware implementation using ASICs (even though FPGA is more common nowadays) should be hard and expensive; but anything in hardware normally gives high performance, albeit sometimes at the cost of flexibility.
No clear idea on where NetFPGA should fall in the middle of the other two approaches. My guess would be faster implementation, less complexity, more flexibility, and lower performance than real hardware, but slower implementation, more complexity, and less flexibility than software routers.