1. Floodlight Overview &
Performance Comparison
Speaker: Patrick Huang
Advisor: H.P. Wen

2. Outline
0 Flashlight Overview
0 A Flexible OpenFlow-Controller Benchmark
0 Comparing OpenFlow Controller Paradigms
Scalability: Reactive and Proactive

3. Outline
0 Flashlight Overview
0 Reference list:
0 Project Floodlight,
http://www.projectfloodlight.org/floodlight/
0 Slideshare
0Big Switch
0 A Flexible OpenFlow-Controller Benchmark
0 Comparing OpenFlow Controller Paradigms
Scalability: Reactive and Proactive

4. Why Floodlight?
0 Openflow
0 Work with phy- and vir- switches that speak openflow protocol
0 Apache Licensed
0 Use floodlight for any purpose
0 Open community
0 Developed by open community
0 Easy to use
0 Floodlight is drop dead simple to build and run.
0 enterprise-class

5. OpenFlow implemented by
Floodlight0 Application Tier
0 Control Plane Tier
0 Data plane Tier
0 Indigo Data Plane Interface
0 an open source project
0 aimed at enabling support for
OpenFlow on physical and
hypervisor switches.

6. OpenFlow implemented by
Floodlight
0 Floodlight
0 An Openflow controller ,and
0 A collection of applications
built on top the floodlight
controller
0 Applications on top of it
0 solve different user needs
over the network

7. OpenFlow implemented by
Floodlight0 Flood light controller
0 Core service of common interest to SDN applications
0 Module Application
0 Applications with higher bandwidth communication with controller
0 REST Application
0 Application in any language leveraging service via REST API exposed by
controller modules and module applicaitons

8. Floodlight Architecture
Topology - Tracks links between hosts and
switches
Device Manager - Tracks devices in the
network (MACs, IPs, etc.)
Storage - Abstraction layer for storing
controller storage. Memory is used.
Counter Store – Openflow + Floodlight stats
Routing / Forwarding – Core engine for
storing, calculating paths and installing flows.
Web UI- Rest APIs
Topology
Device
Manager
Learning
Switch
Hub
Web
Storage
Counter
Store
Floodlight Controller
Routing /
Forward
Static
FlowPusher
REST APIs
Module App

9. Floodlight Architecture
Learning Switch - Can replace Routing /
Forwarding(v)
Hub - Can replace routing / forwarding(x)
Main difference: REST API provider
Topology
Device
Manager
Learning
Switch
Hub
Web
Storage
Counter
Store
Floodlight Controller
Routing /
Forward
Static
FlowPusher
REST APIs
Module App

10. Open Controllers
11
Name Lang Platform
(s)
License Original
Author
Notes
OpenFlow
Reference
C Linux OpenFlow
License
Stanford/Nicir
a
not designed for extensibility
NOX Python,
C++
Linux GPL Nicira actively developed
Beacon Java Win, Mac,
Linux,
Android
GPL (core),
FOSS Licenses
for your code
David Erickson
(Stanford)
runtime modular, web UI framework,
regression test framework
Maestro Java Win, Mac,
Linux
LGPL Zheng Cai
(Rice)
Trema Ruby, C Linux GPL NEC includes emulator, regression test
framework
Floodlight Java Win, Mac,
Linux
Apache Big Switch Apache licensed, actively developed

11. Learning More?
0 Check out the website:
0 http://floodlight.openflowhub.org
0 Join the mailing list:
0 http://groups.google.com/a/openflowhub.org/group/fl
oodlight-dev/topics
0 Get the code:
0 http://floodlight.openflowhub.org/display/Floodlight/F
loodlight+Downloads

12. Outline
0 Flashlight Overview
0 A Flexible OpenFlow-Controller Benchmark
0 Soft Defined Networking(EWSDN), 2012 Euro Workshop on
0 Univ. of Wurzburg, Wurzburg, Germany
0 Comparing OpenFlow Controller Paradigms
Scalability: Reactive and Proactive

13. A Flexible OpenFlow-Controller Benchmark
0 Goal
0 Introduce a tool to achieve a flexible Openflow Controller
benchmark
0 Methods
0 The Benchmark creates a set of message-generating virtual
switches

14. Related work
0 Measure OF switching performance
0 OF switches not designed as flow switches
Often performance bottlenecks
0 Cbench

15. Result: Mean Round Trip Time
0 RTT: Interval of
0 Packet-In message is dispatched from the virtual switch to the
controller
0 Packet-Out or FlowMod message is received by the switch.

16. Result: RTT
0 Flood light and Nox
Behave similarly
0 Increase rapidly from
0 200ms, 1 switch
0 6 seconds, 30
switches
0 Both controllers are
under heavy load at
the point
0 Due to weak
hardware

17. Result: RTT
0 Maestro start at RTT
6ms
0 Larger the no. of
switches, larger RTT
0 But, far steady than two
others

18. Result: Send and ReceptionRate
0 The rate is accepts packets
0 Provide insights into rate control and polling strategies
0 No. of packets sent from switches to the controller

19. Virtual Switch Packet-in Send-
rate0 Send rate: From switches to
controller through OF secure
channel
0 Floodlight
0 do not increase obviously
with the no. of switches
0 Start at 10000 pps, one
switch
0 Increase to 38000 pps
0 NOX
0 10000-70000
0 Maestro
0 5000-140000

20. Virtual Switch Packet-in Send-
rate0 Suggestion:
0 NOX and Floodlight
0 Implementation of rate control
mechanism
0 Maestro
0 Accept packet in a best effort
manner

21. Virtual Switch Packet-out Reception-
rate
0 The no. of responses
the switches recieves
0 No increase for
floodlight and NOX
0 Stable at 10000 pps
0 Maestro
0 From 5000-135000
0 Outstanding packets
0 No. of unanserwed
messages by
controller

22. Virtual Switch Packet-out Reception-
rate
0 Outstanding packets
0 No. of unanserwed
messages by
controller
0 140000-135000

23. Outline
0 Flashlight Overview
0 A Flexible OpenFlow-Controller Benchmark
0 Comparing OpenFlow Controller Paradigms
Scalability: Reactive and Proactive
0 Advanced Information Networking and Applications (AINA),
2013
0 Univ. Estadual do Ceara (UECE), Fortaleza, Brazil
0 Citation: 1

24. Comparing OpenFlow Controller Paradigms
Scalability: Reactive and Proactive
0 Analysis
0 Demo the flaw of reactive approach
0 Conclusion
0 Indicate the effectiveness of a hybrid approach to improve the
efficiency and scalability of OF architecture

25. Introduction
0 Issue: Scalability
0 Only one controller
0 As the no. of OpenFlow switches increases
0 Control messages to the centralized controller grows
0 With increase of network diameter, switches have longer setup
delay
0 Bounded by controller’s processor power

26. Related Work
0 Hyperfolw:
0 To provide scalability
Use as many controllers as necessary
But keep network control logically centralized
0 DevoFlow, to provide scalability
0 devolve network control to switch
0 Introduce two new mechanisms to be imple. On swtich
Rule cloning
Local actions

27. Related Work
• Source-Flow, to reduce no. of flow entries
– Try to reduce no. of flow entries
• Use MPLS-like tunneling approach to reduce Ternary Content
Addressable Memory used space

28. OF architecture
• Reactive
– First packets of flow triggers controller to insert flow table
– Pros
efficient use of flow table memory
– Cons
Cause setup time
Hard dependency, connection must retain

29. OF architecture
• Proactive
– Controller pre-populate flow table in switches
– Pros
zero setup time
Soft dependency
– Cons
Hard management

30. Evaluating OpenFlow controller’s
Parafigm

31. Evaluating OpenFlow controller’s
Parafigm
• Run Cbench to stress the controller’s capacity
• The benchmarking measurement
– flows per sec that can be processed by controller

32. Result: Real network&Mininet

33. Thank You