Characterising the Limits of the OpenFlow Slow-Path Richard Sanger Brad Cowie Matthew Luckie Richard Nelson University of Waikato University of Waikato University of Waikato University of Waikato
[email protected] [email protected] [email protected] [email protected] Abstract—The OpenFlow standard accommodates network whole network. Their paper identified issues that still needed control traffic by providing packet in and out messages for investigating, including the scalability of the slow-path and the sending packets between the network and controller. We conduct need for additional performance profiling. comprehensive measurements of the performance of this control architecture in different configurations across five hardware The exact requirements on control traffic will vary depend- switches, each from a different vendor, representing a broad ing on the mix protocols used, so we use the requirements range of OpenFlow offerings, from implementations built on of Bidirectional Forwarding Detection (BFD) [3] to illustrate legacy ASIC architectures, to those implemented solely with challenging requirements on both latency and bandwidth. OpenFlow in mind. The best performing switch achieved a BFD is a technique used to detect failure of the forwarding- maximum mean packet-in rate of 5,145 messages per second, representing less than 3Mbps of traffic. Additionally, all switches plane quickly. BFD is usually implemented in hardware by tested failed to maintain control traffic latency under 50ms in the switch, but an SDN controller may provide a practical one or more tests. We find the slow-path performance of these alternative if a switch does not support BFD. A typical failure hardware switches is easily overloaded and is insufficient for detection time of 50ms requires 60 packets per second [3] modern network control architectures.