The document discusses the history and progress of OpenFlow and SDN. It traces OpenFlow from its origins in academia in 2007 to its growing adoption by major tech companies and standardization through the Open Networking Foundation by 2011. It outlines how OpenFlow allows centralized control of network traffic through software-defined controllers that programmatically configure flow-based forwarding using the OpenFlow protocol in switches.

1. OpenFlow History & Progress
Telcos, System
Vendors
Open Networking
Foundation
Nox, Open
Start-ups vSwitch
(Nicira, BigS
Interest
witch)
OpenFlo
OpenFlow 1.0 Spec w 1.1
Academia
Board: Deutsche Telekom, Facebook, Google
(Chair), Microsoft, Verizon, Yahoo!
Members: Big Switch
OpenFlow Networks, Broadcom, Brocade, Ciena, Cisco, Citrix, C
Consortium omcast, Dell, Ericsson, Extreme Networks, Force10
Networks, HP, IBM, IP Infusion, Juniper
Networks, Marvell, Mellanox
Technologies, Metaswitch
Silicon Vendors, Networks, NEC, Netgear, Netronome, Nicira
Early adopters Networks, Nokia Siemens Networks, NTT, Plexxi
Ethane (NEC, Google) Inc., Riverbed Technology, Vello Systems, Vmware
…Growing all the time
1 2007 2008 2009 2010 2011

2. OpenFlow Usage Models
1. Experiments at the flow level
 User-defined routing protocols
 Network access control
 Network management
 Energy management
 VOIP mobility and handoff
2. Experiments at the packet level
 Slow: Controller handles packet processing
 Fast: Redirect flows through programmable hardware
 Modified routers, firewalls, NAT, congestion control…
3. Alternatives to IP
 Flow-table is Layer-2 based
 e.g. new naming and addressing schemes

3. Experiments at the packet level
Controller
PC
OpenFlow-enabled
Commercial Switch
Normal Secure
Software Channel
Normal Flow
Datapath Table
Laboratory
NetFPGA

4. Open Flow components

5. Available controllers and switches
NOX (http://noxrepo.org/, GNU GPLv3)

 Provides network-wide view of the topology
 C++ and Python modules make decisions
 OpenVSwitch (http://openvswitch.org/, Apache 2)
 Soft-switch, replaces Linux bridge
 Designed to be used with VM's
 Hardware switches:
 Quanta LB4G (Broadcom), NetFPGA
5

6. Analysis – The Potential
• “SDN will open up networking”
– Do for networking what Linux did for the server – break the
proprietary lock
– Vendors and DC Operators will be able to take control of their
network without being limited to what switch vendors will
give them
• Do-it-yourself rather than waiting 12 months to work it’s way
through a vendor roadmap
– Create an open platform for innovation
• “Centralization of Control will yield better solutions”
– Global view of data -> more efficient
• Processing will be done once (rather than in multiple devices per
traditional distributed protocols)
– Smaller, simpler code
6

7. Analysis – The Potential
• “Workstations offer better platforms for processing
large distributed datasets”
– “Comp Science is years ahead of embedded in this
respect” – e.g. Hadoop
– Better, richer, more productive programming environment
– Larger, more accessible body of engineering skills
• “OpenFlow will result in lots of cheap switches!”
– “White box” unbranded switches, possibly Open Source
• No vendor premium for the heavyweight software load
• No vendor lock-in
– Small, cheap CPUs
7

8. FlowVisor Message Handling
Alice Bob Cathy Rule
Controller Controller Controller
OpenFlow
Policy Check: Policy Check:
Is this rule FlowVisor Who controls
allowed? this packet?
OpenFlow
Full Line Rate OpenFlow Exception
Forwarding Firmware
Packet
Packet Data Path

9. Analysis – The Potential – Use Cases
• ElasticTree: Reducing Energy in Data Center
Networks
– Today data centers are provisioned for peak
traffic running at peak power
– Improve the energy efficiency of a data center
network
– Dynamically adjust network elements - links
and switches.
– ElasticTree uses OpenFlow to measure traffic
statistics and control flow routes
– Upto 60% savings demonstrated.
10

10. Analysis – The Potential – Some Use
Cases
• Aster*x: Load-Balancing as a Network Primitive
– Traditionally Load Balancing is done with an
expensive Box, sitting in the Data path.
– Load Balancing is a just smart routing.
– Transform an existing network into a distributed
load-balancing system.
– Demonstrated one such OpenFlow-based load-
balancer called Aster*x
– Load Balancing became a Control plane solution
– http://www.youtube.com/watch?v=Sfqofxdk1gE
11

11. Analysis – The Potential – Some Use
Cases
• Using All Wireless Networks Around Me
– This demo shows how we can exploit all the wireless
networks around us to achieve better connectivity
and hence better video streaming from a moving
vehicle.
– simultaneous use of multiple wireless networks.
– Uses OpenFlow Wireless-enabled WiFi and WiMAX
networks.
– http://www.youtube.com/watch?v=ov1DZYINg3Y
12

12. •
Analysis – The Challenges
“OpenFlow is too limited”
– How can you solve all networking problems with such a narrow set of
primitives?
– All solutions will require lots of network services outside of OpenFlow in
order to function, so does the “openness story” really hang together?
• “You cannot replace all the traditional switch/routing functions”
– Need to maintain Controller connectivity across a network
– Local processing required for HA/Fast failover
– So will the switches really be any cheaper/simpler, or does OpenFlow
support become yet another switch feature?
• “SDN doesn’t scale”
– Today switches do a lot of local processing (and need complex software and
big CPUs for a reason!) – they have a lot of dynamic, event-driven
processing to-do
• Yes you can simplify this, but can you replace or export it?
– If you put all that up on a remote station, the both processing throughput
and event latency will become big issues
13

13. Analysis – The Challenges
• “Is it really that new? What can you do with
OpenFlow that we can’t already do with
existing configuration methods?”
• “Solutions may move from being Switch
vendor to Controller vendor dependent”
– Where’s the interoperability?
– Industry-hardened multi-vendor standards have
been available in traditional networks for years.
14

14. Predictions
• SDN will supplement rather than completely replace traditional switch
features
– Will still need much of traditional switching and routing for the foreseeable
future
– See OpenFlow as a value-add feature
• SDN will create an innovation platform that will attract a lot of
interesting solutions
– OpenFlow Controllers will look more like OS’s – platforms not solutions
– The Networking “App Store” will arrive!
– However many solutions will require optional and proprietary features in
the switch
• SDN will create opportunities for silicon innovation
– The richer the “instruction set”, the more powerful the solutions!
• Overall, this is a key trend that will happen, and will energize our
industry
15

15. Thank You – Q&A

16. How OpenFlow works
(Simplified)
Config
APP1 to App2
App3 to App1
Config
Web to DB
APP1 to App2 Config
Config App1
Etc. to
App3
APP1to DB
Web to App2
APP1 to App2
Config App1
App3
Etc. to App2
APP1to DB App3 to App1
Web to
Config App1
App3
Etc. to App2
APP1to DB
Web to Web to DB
App3
Etc. to App1
Web to DB Etc.
Etc.
App1 App1
App2 App2
App3 App3
 Applications flows are preprovisioned throughout the network
 Topology/application changes are reflected
 APIs allow application to instruct network behavior
17

17. SDN/OpenFlow Customer Use Case 1-
Trevela
Provider of a market-leading distributed fabric for global trading, risk
analysis and e-commerce
Validated networking based upon OpenFlow, for predictable
performance for complex and demanding applications
Fast
Line Rate Convergence
Performance
Fast Packet Forwarding Intelligent path
using OpenFlow selection
Predictable
performance
18 OpenFlow based traffic
segregation

18. SDN/OpenFlow customer use case 2:
Selerity
Provider of ultralow-latency realtime financial information
• Delivers machine-readable event data immediately as events are breaking which relies on
the fastest possible network performance
OF API OF API
OF API OF API OF API OF API
Closed network elements forced
Used OpenFlow to get complete
the customer to a server to do
control of the network
the packet processing needed
Network based upon OpenFlow
Performance impact provided an order of magnitude
Not an ideal solution (1000 times) better performance
19

19. SDN/OpenFlow Customer Use Case 3 –
SPAN and Tap
Compliance
Diagnostic Auditing
Monitoring
Parallel network for
diagnostics, compliance, auditing
Open, standards-based cost- Move flows from SPAN or TAP to
effective solution OpenFlow switches
Cost-effective alternative to special-
purpose devices
20

20. Real World Deployments
Scalable isolation Alice Bob Cathy Inserting and managing
domains and network network services, such as
slicing. load
FlowVisor Isolation balancing, firewall, IDS/IPS
Policy
, QoS, etc.
Example:Flowvisor
Example: FlowScale
Network Virtualization Platform for Network Services
Flexible mobility of Lower cost, high-
virtual machines performance
networks
Example: Stanford
WAN VM Migration Example: non-
blocking CLOS
architectures
Virtual Machine Management CLOS Fabrics
Simplified data Networks spanning
vibility and traffic public / private DCs
monitoring
Example: Amazon
VPC
Data Analysis / Monitoring Hybrid Clouds
21

21. OpenFlow as a strawman flow-
based substrate

22. Our Approach
1. Define the substrate
• OpenFlow is an open external API to a flow-table
• Version 1.0
– Defined to be easy to add to existing hardware
switches, routers, APs, …
– Timeframe: Now
• Version 2.0
– OpenFlow-optimized hardware
– General “flowspace”
– Timeframe: 2011

23. OpenFlow Deployments
• Stanford Deployments
– Wired: CS Gates building, EE CIS building, EE Packard
building
– WiFi: 100 OpenFlow APs across SoE
– WiMAX: OpenFlow service in SoE
• Other deployments
– Internet2 (NetFPGA switches)
– JGN2plus, Japan (NEC switches)
– 10-15 research groups have switches

24. OpenFlow Deployments
Plans in 2009-10
• Campus deployments
– Lab + production use
– “Enterprise GENI” (NSF/GPO)
• Backbone deployments
– National research backbones
– Research + Production use