OFLOPS: An Open Framework for OpenFlow Switch Evaluation

Haris Rotsos, Andrew W. Moore, University of CambridgeNadi Sarrar, T-Labs/TU Berlin

Steve Uhlig, Queen Mary University of LondonRob 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

Nick McKeown et al, “OpenFlow, Innovation in Campus Networks”

Dynamic flow definition

Flow entry

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.

Switch CPU Flow Table size

Switch1 PowerPC 500MHz 3072 mixed flows

Switch2 PowerPC 666MHz 1500 mixed flows

Switch3 PowerPC 828MHz 2048 mixed flows

OpenVSwitch Xeon 3.6GHz 1M mixed flows

NetFPGA DualCore 2.4GHz 32K exact match & 100 wildcard flows

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

0.01

0.1

1

10

100

1000

1 10 100 1000

dela

y(m

sec)

number of flows

barrier replytransmission delayfirst packet

0.01

0.1

1

10

100

1000

1 10 100 1000

dela

y(m

sec)

number of flows

barrier replytransmission delayfirst packet

OpenVSwitch

Switch 1

Flow Insertion – Data Plane

0.1

1

10

100

1000

10000

1 10 100 1000

Inse

rtio

n tim

e (m

sec)

Number of flow entries inserted

switch1 - mod flowswitch1 - add flowswitch2 - mod flowswitch2 - add flowovs - mod flowovs - add flow

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

0

20

40

60

80

100

0.25 0.5 1 4

cpu

utliz

atio

n

flow statistics poling rate (requests/sec)

switch1switch2netfpga

ovs

1

10

100

1000

0.25 0.5 1 4

flow

sta

ts d

elay

(m

sec)

flow statistics poling rate (requests/sec)

switch1switch2switch3netfpga

ovs

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.

Protocol Interaction

10

100

1000

10000

210.330.250

inse

rtio

n d

elay

(us

ec)

flow statistics polling rate (requests/sec)

switch1switch2switch3netfpga

ovs

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