SDN Switch Inference and Control Plane Optimization Daniel Tahara

Traditional network routing is decentralized, with entities generally using BGP to exchange routing information between autonomous systems and then some form of other routing protocol such as OSPF or RIP to exchange routing information within. Although this approach works well for public routing, it does not allow enough control for a network controller to implement various security and quality-of-service (QoS) policies within their own private network. OpenFlow (OF) defines a protocol by which a centralized software controller can fill the routing tables of OF-enabled switches with forwarding rules defined by the network administrator. Specifically, these forwarding rules comprise sets of 12-tuples called flow entries, which support exact and wildcarding matching on the following fields: ingress port, ethernet src/dest/type, VLAN id/priority, IP src/dest/protocol/ToS bits, and TCP/UDP src/dest. Wildcard rules introduce two fundamental design challeges in the OF API and switches. Because incoming packets can match multiple wildcarded rules, there needs to be some way for the OF switch to decide the correct forwarding action. The OF API reconciles this issue by requiring the controller to assign a priority value to each match condition. The switch then selects the matching rule with the highest priority. An important consequence of this is that hardware-based forwarding tables must have their entries sorted physically by priority in order to retain (software forwarding does not face this limitation since it can apply a logical filter to the rules after the fact). The second design challenge occurs on the switch hardware level, since matching wildcarded rules on a hardware level requires customized hardware. OF switches typically rely on ternary content addressable memory (TCAM), which allows matching on 0, 1, or X (don’t care) for each bit. Although TCAM exists for normal forwarding tables, OF presents a significant challenge because the match conditions are about 250 bits wide1. Since TCAM takes up significantly more space than traditional CAM, this creates a severe limitation on the number of hardware entries a switch can support. As a result, most switches add a software-based flow table to handle more rules but at a significant performance cost. As a result of the two challenges mentioned above (among others), there is tremendous variation in hardware TCAM size, caching policies (which rules to include in the TCAM), and general performance of each of the hardware and software layers (before we even introduce software-based, Open vSwitch (OVS) controllers). Although firewalls and other simple ‘policy’ controllers are unaffected by this diversity, controllers that cater to end applications