OFLOPS: An Open Framework for OpenFlow Switch Evaluation

1
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
2
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?

3
OpenFlow primitives
Flow entry
Dynamic flow definition

• Nick McKeown et al, OpenFlow, Innovation in
  Campus Networks

4
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?

5
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.

6
OFLOPS Measurements

• Using OFLOPS we try understand the following
  functionalities
• Action processing.
• Flow table update.
• Traffic monitoring.
• Message interactions.

7
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
8
OpenFlow Actions

• OpenFlow provides a wide range of actions
• DL_DST, DL_SRC
• NW_SRC, NW_DST, NW_TOS
• VLAN_ID, VLAN_PCP, VLAN_STRIP
• TP_SRC, TP_DST
• OUTPUT, FLOOD, ALL
• What is the impact of each action in switching
  delay?
• Using a 100 Mbps/100 bytes packet probe measure
  the processing delay of each action.

9
OF Packet modifications
Actions kept in hardware path have low processing
latency.
Software switches delay is driven by the PCI bus
latency
Implementing unsupported actions on the slow path
incurs high latency and packet loss.
Flows containing unsupported actions will
silently be discarded.
Time to perform individual packet
modifications (microseconds).
10
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.

11
Flow Insertion - Barrier Reply
OpenVSwitch
Switch 1
12
Flow Insertion Data Plane
13
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.

14
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.
15
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.

16
Protocol Interaction
17
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.

18
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.

19
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
20
Future development

• Improve h/w design.
• Test more switches.
• Extend scenarios evaluate each possible
  interaction.
• Include any potential new SDN-enabling protocols.

21
OpenFlow Applications

• Ethane Network security.
• FlowVisor Network virtualization.
• NOX Network OS.
• Asterx Network load balancer.
• FIBIUM High performance, low cost programmable
  router.
• HomeWork home network management.

22
firmware bugs

• Switch2 drops silently bad checksumed pkts.
• Switch1 during big flow update batches, reorders
  packets.
• Switch2 resets control channel if an of_ping
  arrives after an of_packet_out.
• NetFPGA bug on flow_stats handling code.

23
Packet Out Delay
24
Packet Switching Delay
25
Timestamp Capturing Precision
Comparing the precision of timestamps received
from pcap and NetFPGA against the timestamps
26
Traffic Model

• Throughput performance is more important that
  realistic traffic.
• Constant rate probes.
• Provide value ranges for each header field
  stochastic packet generation.
• Ensure each packet is a self contained
  measurement.
• Include in the payload a custom header with
  packet generation details.

27
OpenFlow switch