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
Dynamic flow definition
Nick McKeown et al, “OpenFlow, Innovation in Campus Networks”
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, multithreaded 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.
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
• 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
delay(msec)
OpenVSwitch
barrier reply
transmission delay
first packet
1000
100
10
1
0.1
0.01
1
10
100
1000
number of flows
delay(msec)
Switch 1
1000
barrier reply
transmission delay
first packet
100
10
1
0.1
0.01
1
10
100
number of flows
1000
Flow Insertion – Data Plane
switch1 - mod flow
switch1 - add flow
switch2 - mod flow
switch2 - add flow
ovs - mod flow
ovs - add flow
Insertion time (msec)
10000
1000
100
10
1
0.1
1
10
100
Number of flow entries inserted
1000
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 stats delay (msec)
Flow Statistics
switch1
switch2
switch3
netfpga
ovs
1000
100
10
1
cpu utlization
0.25
0.5
1
4
flow statistics poling rate (requests/sec)
100
Switch1
Ovs
Switch2
and paces
tries
NetFPGA
toits
reply
replies
powerful
as fast
in
CPUs
as
order
possible
to
provide
avoid
to overloading
stats
low latency
requests
its
with results
and
CPU.
minimum
in high
CPUCPU
utilisation.
switch1
switch2
netfpga
ovs
80
60
40
20
0
0.25
0.5
1
4
flow statistics poling rate (requests/sec)
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.
insertion delay (usec)
Protocol Interaction
switch1
switch2
switch3
netfpga
ovs
10000
1000
100
10
0
0.25
0.33
1
2
flow statistics polling rate (requests/sec)
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-packetgenerator-c-library/
Thank you!!!! :D