170 likes | 444 Views
OFLOPS: An Open Framework for OpenFlow Switch Evaluation Haris Rotsos , Andrew W. Moore, University of Cambridge Nadi Sarrar, T-Labs/TU Berlin Steve Uhlig, Queen Mary University of London Rob Sherwood,BigSwitch. SDN Revolution. Computer network evolution faces new barriers:
E N D
OFLOPS: An Open Framework for OpenFlow Switch Evaluation Haris Rotsos, Andrew W. Moore, University of Cambridge Nadi Sarrar, T-Labs/TU Berlin Steve Uhlig, Queen Mary University of London Rob Sherwood,BigSwitch
SDN Revolution • Computer network evolution faces new barriers: • Network applications develop diverse network requirements. • Internet protocol ossification makes network evolution difficult. • “Intelligence” in the network can solve the problem. • Software Defined Networking to the rescue. • Decouple Control from Forwarding plane. • Define a new flow-centric network management abstraction. • Evolution of Active Network and DCAN research. • OpenFlow protocol currently provides such an abstraction. • What is the cost of this flexibility?
OpenFlow primitives Flow entry Nick McKeown et al, “OpenFlow, Innovation in Campus Networks” Dynamic flow definition
Motivation What are the capabilities and bottlenecks of an OpenFlow switch implementation? • How do I compare OpenFlow switches from different vendors? • Rapid design evaluation. • What is the impact of a network design to the overall performance? • How slow will my switch become if there is a DoS attack while I poll for network statistics?
OFLOPS • Fast, low overhead, multi-threaded controller framework with integrated network traffic generator. • Modular event driven API. • Access to multiple input measurement channels (data/ctrl plane, SNMP). • Extensible traffic generation and traffic capturing mechanism to support heterogeneity and precision.
OFLOPS Measurements • Using OFLOPS we try understand the following functionalities: • Action processing. • Flow table update. • Traffic monitoring. • Message interactions.
Switches • Using OFLOPS we test a number of representative set of available OpenFlow switches. • OFLOPS is setted up on a 4-core PC equipped with a NetFPGA card and direct connection with the switch.
Flow Insertion Delay • How fast can you update the flow table? • 2 measurement probes: • FLOW A: UDP – 1 src to N dst. - 10Mbps/100 bytes. • FLOW B: UDP – 1 src to 1 dst – 10Mbps/100bytes.
Flow Insertion - Barrier Reply OpenVSwitch Switch 1
Traffic Monitoring • Flow stats messages allows controller defined traffic monitor • Traffic matrix estimation, large traffic aggregates • How do implementations handle these type of messages? • Insert 1000 flows. Polls for flow stats while sending 100 Mbps/100 bytes traffic on data channels.
Flow Statistics Ovs and NetFPGA powerful CPUs provide low latency with minimum CPU utilisation. Switch2 tries to reply as fast as possible to stats requests and results in high CPU utilisation. Switch1 paces its replies in order to avoid overloading its CPU.
Message interactions • Dynamically adapting application and OpenFlow • Will my load balancer app crash if I poll too fast for flow statistics? • Repeat the previous experiment and measure the delay to insert 100 flows.
What I learned using OFLOPS • OpenFlow switch implementation is not trivial. • Software switches provide excellent control channel performance, but suffer in forwarding delay. • Switch firmware are still early in their development. • Switching fabrics are not OpenFlow-optimised. Further improvement requires chip redesign or abstraction redefinition.
Conclusions • OFLOPS: framework for performing OpenFlow measurements • Advanced instrumentation: NetFPGA for packet generation / capturing, SNMP, ... • Allows to identify bottlenecks and limitations of OpenFlow implementations. • Tested a number of primitive OpenFlow functionalities and discover significant variations.
OFLOPS on the NET • Do you want to start developing your modules • http://www.openflow.org/wk/index.php/Oflops • http://github.com/crotsos/netfpga-packet-generator-c-library/ Thank you!!!! :D