2. Million of lines
of source code
6000+ RFCs Barrier to entry
Billions of gates Bloated Power Hungry
Many complex functions baked into the infrastructure
OSPF, BGP, multicast, differentiated services,
Traffic Engineering, NAT, firewalls, MPLS, redundant layers, …
An industry with a “mainframe-mentality”, reluctant to change
The Ossified Network
Specialized Packet
Forwarding Hardware
Operating
System
Feature Feature
Routing, management, mobility management,
access control, VPNs, …
2
3. Open Systems
Performance
Fidelity
Scale Real User
Traffic?
Complexity Open
Simulation medium medium no medium yes
Emulation medium low no medium yes
Software
Switches
poor low yes medium yes
NetFPGA high low yes high yes
Network
Processors
high medium yes high yes
Vendor
Switches
high high yes low no
gap in the tool space
none have all the desired attributes!
3
4. Specialized Packet
Forwarding Hardware
App App App
Specialized Packet
Forwarding Hardware
App App App
Specialized Packet
Forwarding Hardware
App App App
Specialized Packet
Forwarding Hardware
App App App
Specialized Packet
Forwarding Hardware
Operating
System
Operating
System
Operating
System
Operating
System
Operating
System
App App App
4
Current Internet
Closed to Innovations in the Infrastructure
Closed
5. Specialized Packet
Forwarding Hardware
App App App
Specialized Packet
Forwarding Hardware
App App App
Specialized Packet
Forwarding Hardware
App App App
Specialized Packet
Forwarding Hardware
App App App
Specialized Packet
Forwarding Hardware
Operating
System
Operating
System
Operating
System
Operating
System
Operating
System
App App App
Network Operating System
App App App
“Software Defined Networking” approach
to open it
6. App
Simple Packet
Forwarding
Hardware
Simple Packet
Forwarding
Hardware
Simple Packet
Forwarding
Hardware
App App
Simple Packet
Forwarding
Hardware Simple Packet
Forwarding
Hardware
Network Operating System
1. Open interface to hardware
3. Well-defined open API
2. At least one good operating system
Extensible, possibly open-source
The “Software-defined Network”
13. OpenFlow Basics
Flow Table Entries
Switc
h
Port
MAC
src
MAC
dst
Eth
type
VLAN
ID
IP
Src
IP
Dst
IP
Prot
L4
sport
L4
dport
Rule Action Stats
1. Forward packet to zero or more ports
2. Encapsulate and forward to controller
3. Send to normal processing pipeline
4. Modify Fields
5. Any extensions you add!
+ mask what fields to match
Packet + byte counters
13
VLAN
pcp
IP
ToS
14. OpenFlow: a pragmatic compromise
• + Speed, scale, fidelity of vendor hardware
• + Flexibility and control of software and
simulation
• Vendors don’t need to expose
implementation
• Leverages hardware inside most switches
today (ACL tables)
14
17. Centralized vs Distributed Control
Both models are possible with OpenFlow
Centralized Control
OpenFlow
Switch
OpenFlow
Switch
OpenFlow
Switch
Controller
Distributed Control
OpenFlow
Switch
OpenFlow
Switch
OpenFlow
Switch
Controller
Controller
Controller
17
18. Flow Routing vs. Aggregation
Both models are possible with OpenFlow
Flow-Based
• Every flow is individually
set up by controller
• Exact-match flow entries
• Flow table contains one
entry per flow
• Good for fine grain
control, e.g. campus
networks
Aggregated
•One flow entry covers large
groups of flows
•Wildcard flow entries
•Flow table contains one entry
per category of flows
•Good for large number of
flows, e.g. backbone
18
19. Reactive vs. Proactive (pre-populated)
Both models are possible with OpenFlow
Reactive
• First packet of flow
triggers controller to insert
flow entries
• Efficient use of flow table
• Every flow incurs small
additional flow setup time
• If control connection lost,
switch has limited utility
Proactive
•Controller pre-populates flow
table in switch
•Zero additional flow setup
time
•Loss of control connection
does not disrupt traffic
•Essentially requires
aggregated (wildcard) rules
19
20. Usage examples
• Alice’s code:
– Simple learning switch
– Per Flow switching
– Network access
control/firewall
– Static “VLANs”
– Her own new routing protocol:
unicast, multicast, multipath
– Home network manager
– Packet processor (in
controller)
– IPvAlice
Stanford demonstrated
– VM migration
– Server Load balancing
– Mobility manager
– Power management
– Network monitoring
and visualization
– Network debugging
– Network slicing
… and much more you can create!
21. Quiz Time
• How do I provide control connectivity? Is it really clean slate?
• Why aren’t users complaining about time to setup flows over
OpenFlow? (Hint: What is the predominant traffic today?)
• Considering switch CPU is the major limit, how can one take
down an OpenFlow network?
• How to perform topology discovery over OpenFlow-enabled
switches?
• What happens when you have a non-OpenFlow switch
inbetween?
• What if there are two islands connected to same controller?
• How scalable is OpenFlow? How does one scale deployments?
21
22. What can you not do with OpenFlow ver1.0
• Non-flow-based (per-packet) networking
– e.g., Handling pkt 1 differently from pkt 2 of same flow
– yes, this is a fundamental limitation
– BUT OpenFlow provides the plumbing to connect devices
• New forwarding primitives
– BUT provides a nice way to integrate them through extensions
• New packet formats/field definitions
– BUT a generalized OpenFlow (2.0) is on the horizon
• Optical Circuits
– BUT efforts underway to apply OpenFlow model to circuits
• Low-setup-time individual flows
– BUT can push down flows proactively to avoid delays
23. Where it’s going
• OF v1.1: Extensions for WAN, spring 2011
– multiple tables: leverage additional tables
– tags and tunnels
– multipath forwarding
• OF v2+
– generalized matching and actions: an “instruction
set” for networking
23
25. OpenFlow building blocks
ControllerNOXNOX
Slicing
SoftwareFlowVisorFlowVisor
FlowVisor
Console
25
ApplicationsLAVILAVIENVI (GUI)ENVI (GUI) ExpedientExpedientn-Castingn-Casting
NetFPGANetFPGASoftware
Ref. Switch
Software
Ref. Switch
Broadcom
Ref. Switch
Broadcom
Ref. Switch
OpenWRTOpenWRT PCEngine
WiFi AP
PCEngine
WiFi AP
Commercial Switches Stanford Provided
OpenFlow
Switches
SNACSNAC
Stanford Provided
Monitoring/
debugging toolsoflopsoflopsoftraceoftrace openseeropenseer
OpenVSwitchOpenVSwitch
HP, NEC, Pronto,
Juniper.. and
many more
HP, NEC, Pronto,
Juniper.. and
many more
BeaconBeacon HeliosHelios MaestroMaestro
26. Ciena Coredirector
NEC IP8800
Current SDN hardware
More coming
soon...
Juniper MX-series
HP Procurve 5400
Pronto 3240/3290
WiMax (NEC)
PC EnginesNetgear 7324
26
27. Commercial Switch Vendors
Model Virtualize Notes
HP Procurve 5400zl or
6600
1 OF
instance
per VLAN
-LACP, VLAN and STP processing
before OpenFlow
-Wildcard rules or non-IP pkts
processed in s/w
-Header rewriting in s/w
-CPU protects mgmt during loop
NEC IP8800 1 OF
instance
per VLAN
-OpenFlow takes precedence
-Most actions processed in
hardware
-MAC header rewriting in h/w
Pronto 3240 or 3290
with Pica8 or Indigo
firmware
1 OF
instance
per switch
-No legacy protocols (like VLAN
and STP)
-Most actions processed in
hardware
-MAC header rewriting in h/w 27
28. Controller Vendors
Vendor Notes
Nicira’s
NOX
•Open-source GPL
•C++ and Python
•Researcher friendly
Nicira’s
ONIX
•Closed-source
•Datacenter networks
SNAC •Open-source GPL
•Code based on NOX0.4
•Enterprise network
•C++, Python and Javascript
•Currently used by campuses
Vendor Notes
Stanford’s
Beacon
•Open-source
•Researcher friendly
•Java-based
BigSwitch
controller
•Closed source
•Based on Beacon
•Enterprise network
Maestro (from
Rice Univ)
•Open-source
•Based on Java
NEC’s Helios •Open-source
•Written in C
28
29. Growing Community
Vendors and start-ups Providers and business-unit
More... More...
29
Note: Level of interest varies
32. Simple Packet
Forwarding Hardware
Network
Operating
System 1
Open interface to hardware
Virtualization or “Slicing” Layer
Network
Operating
System 2
Network
Operating
System 3
Network
Operating
System 4
App App App App App App App App
Many operating systems, or
Many versions
Open interface to hardware
Isolated “slices”
Simple Packet
Forwarding Hardware
Simple Packet
Forwarding Hardware
Simple Packet
Forwarding Hardware
Simple Packet
Forwarding Hardware
32
33. Switch Based Virtualization
Exists for NEC, HP switches but not flexible enough
Normal L2/L3 Processing
Flow Table
Production VLANs
Research VLAN 1
Controller
Research VLAN 2
Flow Table
Controller
33
35. OpenFlow
Protocol
OpenFlow
FlowVisor & Policy Control
Broadcast
Multicast
OpenFlow
Protocol
http
Load-balancer
FlowVisor-based Virtualization
OpenFlow
Switch
OpenFlow
Switch
OpenFlow
Switch
35
Separation not only
by VLANs, but any
L1-L4 pattern
Separation not only
by VLANs, but any
L1-L4 pattern
dl_dst=FFFFFFFFFFFF tp_src=80, or
tp_dst=80
37. FlowVisor Message Handling
OpenFlow
Firmware
Data Path
Alice
Controller
Bob
Controller
Cathy
Controller
FlowVisor
OpenFlow
OpenFlow
Packet
Exception
Policy Check:
Is this rule
allowed?
Policy Check:
Who controls
this packet?
Full Line Rate
Forwarding
Rule
Packet
38. Use Case: New CDN - Turbo Coral ++
Basic Idea: Build a CDN where you control the entire network
– All traffic to or from Coral IP space controlled by Experimenter
– All other traffic controlled by default routing
– Topology is entire network
– End hosts are automatically added (no opt-in)
Switch
Port
MAC
src
MAC
dst
Eth
type
VLAN
ID
IP
Src
IP
Dst
IP
Prot
TCP
sport
TCP
dport
* * * * * 84.65.* * * * *
* * * * * * 84.65.* * * *
* * * * * * * * * *
38
40. Summary
• Software-defined networking is still evolving
• OpenFlow is being deployed in over 100
organizations world-wide
– GEC9 in Nov, 2010 showcased nation-wide OF
– Internet 2 and NLR starting to serve as the GENI
Backbone
Are you innovating in your networks??
41. Credits
• Thanks to following for contributing content to the tutorial:
– Nick McKeown
– Guru Parulkar
– Brandon Heller
– Yiannis Yiakoumis
– Guido Appenzeller
– Rob Sherwood
– Masa Kobayashi
Hinweis der Redaktion
The next 3 slides are a set of animation to show how we enable innovation:
- Infrastructure is closed to innovation and only driven by vendors. Consumers have little say
- Business model makes it hard for new features to be added
How do we redefine the architecture to open up networking infrastructure and the industry!
By bring to the networking industry what we did to the computing world
Switches, routers and other middleboxes are dumbed down
The key is to have a standardized control interface that speaks directly to hardware
How the actual protocol works
Now I’ll describe the API that tries to meet these goals.
What is possible in the controller? Anything that needs intelligent routing of a flow
At Stanford, we have even shown how OpenFlow may be used for:
VM migration
Power management
Load balancing
Network monitoring and debugging
Easier network visualization
There are components at different levels that work together in making it work
The commercial switch details will follow in next slide
There are a plethora of applications possible. I only list those available at Stanford
All support ver 1.0
All have approx 1500 flow table entry limit
Hidden slide (just for backup reasons)
Shows how far along we can go in opening up the network
Experiments running on PRODUCTION infrastructure
Key to get scale, key to get traffic on the network
(e.g. can’t just do a reset...)
