Rethinking Packet Forwarding Hardware

Martin Casado∗§ Teemu Koponen† Daekyeong Moon‡ Scott Shenker‡§

1 Introduction should not be tied to particular networking hardware, For routers and switches to handle ever-increasing band- and networking hardware should not be restricted width requirements, the packet “fast-path” must be to particular protocols. General-purpose network handled with specialized hardware. There have been two processors have largely failed the first requirement, approaches to building such packet forwarding hardware. while the current generation of commodity network- The first is to embed particular algorithms in hardware; ing chips fail the second requirement. this is what most commodity forwarding chips do (e.g., • Hardware simplicity: In order to scale to increasing those from Broadcom, Marvell, and Fulcrum). These speeds, the hardware functionality should be of chips have led to amazing increases in performance and very limited complexity. Again, both current reductions in cost; for instance, one can now get 24 ports approaches to hardware acceleration fail to satisfy of gigabit ethernet for under $1000. this requirement. Unfortunately, this approach offers only very rigid func- • Flexible and efficient functionality: The resulting tionality; one can’t change protocols or add new features software-hardware combination should be capable that require hardware acceleration without redoing the of realizing a wide variety of networking functions chip. This forces network forwarding enhancements to at high-speed and low-cost, while having short evolve on hardware design timescales, which are glacially development cycles. Commodity chips work at slow compared to the rate at which network applications high-speed and low-cost, but have long development and requirements are changing. cycles for new functionality. General-purpose To counter this inflexibility, several vendors have network processors are not yet competitive on speed taken a different approach by introducing more flexible or cost. “network processors”. These have not been as successful In this paper we propose a different approach to as anticipated, for at least two reasons. First, designers hardware packet forwarding that has the potential to were never able to find a sweet-spot in the tradeoff realize all of these goals. Our approach assigns a between hardware simplicity and flexible functionality, completely different role to hardware. Traditionally, so the performance/price ratios have lagged well behind hardware implementations have embodied the logic commodity networking chips. For another, the interface required for packet forwarding. That is, the hardware provided to software has proven hard to use, requiring had to capture all the complexity inherent in a packet protocol implementors to painstakingly contort their forwarding decision. code to the idiosyncrasies of the particular underlying In contrast, in our approach all forwarding decisions hardware to achieve reasonable performance. These two are done first in software, and then the hardware merely problems (among others) have prevented general-purpose mimics these decisions for subsequent packets to which network processors from dislodging the more narrowly that decision applies (e.g., all packets destined for the targeted commodity packet forwarding hardware that same prefix). Thus, the hardware does not need to dominates the market today. understand the logic of packet forwarding, it merely In this paper, we step back from these two well-known caches the results of previous forwarding decisions (taken approaches and ask more fundamentally: what would we by software) and applies them to packets with the want from packet forwarding hardware, how might we same headers. The key task is to match incoming achieve it, and what burden does that place on networking packets to previous decisions, so the required hardware software? is nothing more than a glorified TCAM, which is simple Ideally, hardware