openflowswitch.org openflow guru parulkar [email protected] stanford openflow team: nick...
TRANSCRIPT
OpenFlowSwitch.org
OpenFlow
Guru [email protected]
Stanford OpenFlow team: Nick McKeown, Guido Appenzeller, Glen Gibb, David Underhill, David Erickson, Adam Covington, Brandon Heller, Rob Sherwood,
Masayoshi Kobayashi, Srinivasan Seetharaman, Yiannis Yiakoumis
Agenda
High Level Rationale OpenFlow Basics OpenFlow Demo Generalization of Flow Separation of Data and Control Paths Virtualized OpenFlow Infrastructure OpenFlow Deployment and Trials
Big Changes on the Horizon Proliferation of mobile wireless
devices, networks, and services
Computing and storage moving into the cloud
Emergence of sensor networks and services
Society’s increasing dependence
Architectural limitations of current network requires change
Each individually can lead to a very different type of
Future Internet infrastructure and services
4
The Big Picture
Handheld
Energy efficient Secure OS
Secure mobile browser
UI
HW Platform
ApplicationsPocketSchool, Virtual Worlds, Augmented Reality
ApplicationsPocketSchool, Virtual Worlds, Augmented Reality
Data SubstratePRPL Virtual Data System
Data SubstratePRPL Virtual Data System
WEB/Computing SubstrateNetwork of VMs, Mobile VMs
WEB/Computing SubstrateNetwork of VMs, Mobile VMs
Network SubstrateOpenFlow
Network SubstrateOpenFlow
Radio technologyMulti-Gb/s, 99% coverage
Radio technologyMulti-Gb/s, 99% coverage
Econom
icsE
conomics
5
Key Networking Infrastructures: Problems
Cellular infrastructure -- supports mobility well
Designed for voice and circuit
Too many vertically integrated complex protocol stacks
Closed for (third party) innovations
With proliferation of data services, needs to converge with Internet
Internet -- the default data network infrastructure
Not designed for mobility, security, manageability, …
Supports innovations at the edges but not within the network itself
WiFi networks -- higher data rate at short range
Not designed for cellular style mobility
Allows easier experimentation -- unlicensed band and less expensive
6
Internet Ossification
Not a conspiracy -- just a fact of life Research community has been staring at this problem for several years
ArchWeaknesses
HighBarrier to
EntryIndustry, IETF, …
Add complexity to addressweaknesses
Resistant to changeLack of data& controlpath sep
Increasinglycomplex
data path
Complex ASICsMassive sw
7
IP
Diverse physical layers
Diverse transport layers
Flow layerX Y Z
Diverse applications
Ethernet
Diverse link layers
Routing, Mobility, Naming/Addressing,
Access Control, Management,Monitoring…
Allow lots of innovation
OpenFlow Model
OpenFlowSwitch.org
Staged Approach
1. Define OpenFlow feature2. Add OpenFlow to commercial switches and APs3. Deploy at Stanford4. 2009: Run NSF-funded trials on 6 college campuses5. 2010: Deploy on many college campus networks
6. Community creates lots of open-source software so researchers can build on each other’s work
(We’re part-way into Stage 2)
Agenda
High Level Rationale OpenFlow Basics OpenFlow Demo Generalization of Flow Separation of Data and Control Paths Virtualized OpenFlow Infrastructure OpenFlow Deployment and Trials
OpenFlowSwitch.org
OpenFlow Basics (1)
Rule(exact & wildcard)
Action Statistics
Rule(exact & wildcard)
Action Statistics
Rule(exact & wildcard)
Action Statistics
Rule(exact & wildcard)
Default Action Statistics
Exploit the flow table in switches, routers, and chipsets
Flow 1.
Flow 2.
Flow 3.
Flow N.
OpenFlowSwitch.org
OpenFlow Basics (2)
Rule(exact & wildcard)
Action Statistics
Small number of fixed actionse.g. unicast, mcast, map-to-queue, drop
Extended via virtual portse.g. tunnels, encapsulate, encrypt
As general as possiblee.g. Port, VLAN ID, L2, L3, L4, …
As wide as possible
Count packets & bytesExpiration time/count
12
OpenFlow Switch specification
Controller
OpenFlow Switch
FlowTableFlowTable
SecureChannelSecure
Channel
PC
OpenFlow
Protocol
SSL
hw
sw
OpenFlow Basics
• Add/delete flow entries• Encapsulated packets• Controller discovery
API
Net Services
OpenFlowSwitch.org
Controller
OpenFlow Switch
PC
OpenFlow UsageDedicated OpenFlow Network
OpenFlow Switch
OpenFlow Switch
OpenFlowProtocol
Chip’s code
Rule Action Statistics
Rule Action Statistics Rule Action Statistics
Chip
OpenFlowSwitch.org
Usage examples
Chip’s code: Static “VLANs” His own new routing protocol: unicast, multicast,
multipath, load-balancing Network access control Home network manager Mobility manager Energy manager Packet processor (in controller) IPvChip Network measurement and visualization …
15
OpenFlow and Mobility
Lots of interesting questions
• Management of flows• Control of switches• Access control of users and devices• Tracking user location and motion
Lots of interesting questions
• Management of flows• Control of switches• Access control of users and devices• Tracking user location and motion
• Lots of radio networks:WiFi, WiMax, LTE, …• Dumb access points • User choice
• Lots of radio networks:WiFi, WiMax, LTE, …• Dumb access points • User choice
16
Deployment on Stanford campus
• 100 of WiFi APs in 4 buildings & outdoor locations
• A few Mobile WiMAX femto-cellbase stations
• Deployed in this autumn• All are OpenFlow enabled
& connected by OpenFlow switches
• Plan to have a project class in this autumn/winter quarter
WiFi AP (two radios/box)
Mobile WiMAX AP
We are ready for innovation in our network!
17
OpenFlow Target Domains
Enterprise Original target
Data Center Growing and looking for OpenFlow like solution
Mobile Cellular Convergence of cellular and IP
Backbone Unification of L1-L3 and Circuit and Packet
OpenFlowSwitch.org
OpenFlow Demo
SIGCOMM 2008 Demo
Agenda
High Level Rationale OpenFlow Basics OpenFlow Demo Generalization of Flow Separation of Data and Control Paths Virtualized OpenFlow Infrastructure OpenFlow Deployment and Trials
What is a flow?
Application flow All http John’s traffic All packets to China …
Types of action
Allow/deny flow Route & re-route flow Isolate flow Make flow private Remove flow
We need flexible definitions of a flow We don’t need many types of actionSpecific actions should easily evolve
1.
Unicast
2.Multicast
4.
Waypoints Middleware Intrusion detection …
3.Multipath Load-balancing Redundancy
Separation of Controlfrom Datapath
1. Simpler Control & Management
2. Easy evolution Rapid innovation Open-source? Thousands of developers
3. Scales with Moore’s Law
4. Choose ratio of control to datapath
1. Simpler Control & Management
2. Easy evolution Rapid innovation Open-source? Thousands of developers
3. Scales with Moore’s Law
4. Choose ratio of control to datapath
New function!
Operators, users, 3rd party developers, researchers, …
Allow or deny flow?Whose flow is it?
How to route flow?
DPI
PassiveMeasurement
Try doing this in your network :-)
Agenda
High Level Rationale OpenFlow Basics OpenFlow Demo Generalization of Flow Separation of Data and Control Paths Virtualized OpenFlow Infrastructure OpenFlow Deployment and Trials
OpenFlowSwitch.org
Step 1: Separate VLANs for Production and Research Traffic
Normal L2/L3 Processing
Flow Table
Production VLANs
Research VLANs
Controller
OpenFlowSwitch.org
Step 2: Virtualize OpenFlow Switch
Normal L2/L3 Processing
Flow Table
Flow Table
Flow TableResearcher A VLANs
Researcher B VLANs
Researcher C VLANs
Production VLANs
Controller A
Controller B
Controller C
OpenFlowSwitch.org
Virtualizing Control
OpenFlow Switch
OpenFlow Switch
OpenFlow Switch
OpenFlowProtocolOpenFlowProtocol
OpenFlowHypervisor & Policy Control
Craig’sController
Heidi’sControllerAaron’s
Controller
OpenFlowProtocolOpenFlowProtocol
32
Virtualized OpenFlow Substrate
OpenFlow Switch
OpenFlow Switch
OpenFlow Switch
OpenFlowProtocol
Hypervisor & Policy Control
Aaron’sController
API
Net ServicesHeidi’sController
OpenFlowProtocol
API
Net Services Craig’sController
API
Net Services
OpenFlowSwitch.org
Many Open Questions!
Scalability of a controller Load-balancing over redundant controllers Federation, hierarchy and aggregation Protecting the controller against DDOS
Our goal is to enable the research community to explore all these questions
Agenda High Level Rationale OpenFlow Basics OpenFlow Demo Generalization of Flow Separation of Data and Control Paths Virtualized OpenFlow Infrastructure OpenFlow Deployment and Trials
Path to Broader Impact: Networking Substrate Easy to enable this capability on existing products
Don’t need to build our own boxes which is a major barrier
Eight switch vendors enabling this capability Cisco, HP, NEC, Juniper, and others
We are starting to demonstrate the key capabilities ACM SIGCOMM08 GENI Engineering Conference Supercomputing…
We plan to deploy or are deploying on our campus: two buildings at Stanford (HP/Cisco) on other campuses in US and Japan in national nets: US (Internet2, NLR), Japan (JGN2plus), Europe, …
And enable researchers and network operators to innovate on top
Hope OpenFlow takes off -- on a path of no return
Value of OpenFlow to Researchers and CIOs
Experiment with your network ideas at scale in your own network
By developing a network service
In a production network with real users and applications
Something you haven’t been able to do
Try new network management and control ideas in a production network with real users and applications
Liberate yourself from the grips of the vendor
Goals of OpenFlow Trials Empower researchers and CIOs to create innovative network
services
Trials are less about OpenFlow and more about network services
Innovative network services represent significant opportunities for making contributions and creating value
An opportunity that haven’t existed for many years before
NSF wants to empower its researchers to take advantage of this opportunity
NICT may want to do the same for Japanese researchers
Stanford will be happy to support Japanese trials
37
OpenFlow Trial Interest
20 Universities already shown interest And the number is growing
T-Labs in CA and Berlin
DoCoMo Labs in CA
Research networks in Europe
A few campuses in Europe
A few universities from Japan and Korea
NSF Funded Trials in US: 1st Phase
Six out of 20 campuses interested
Support from CIO and strong research interest
Commitment to deploy in production networks
NSF to provide $300k of seed funding
For equipment and support of network admin in CIO office
Equipment vendors to provide support and subsidiary
NEC and HP committed; Juniper and Cisco are likely too
Stanford to provide reference implementations and support of these reference implementations
Stanford will submit proposal to NSF in January
Trials to begin in April 2009 for 18 months
OpenFlowSwitch.org
http://OpenFlowSwitch.orghttp://OpenFlowSwitch.org
OpenFlowSwitch.org
Thanks…
(It takes a village)
OpenFlowSwitch.org
Juniper
OpenFlow added to Junos SDK First platform: MX-480 carrier class Ethernet 24-ports 10GE or 240-ports 1GE Hardware forwarding Deployed in Internet2 in NY and at Stanford
Umesh Krishnaswamy
MichaelaMezo
ParagBajaria
JamesKelly
BobbyVandalore
OpenFlowSwitch.org
HP
Experimental feature on ProCurve 5400-series 144-ports of 1GE, hardware forwarding OpenFlow added by HP Labs and ProCurve group In 23 wiring closets in CS Building at Stanford
Praveen Yalagandula
Jean Tourrilhes
SujataBanerjee
Rick McGeer
CharlesClark
OpenFlowSwitch.org
NEC
Experimental feature on IP8800 series router 24-ports of 1GE, 2-ports of 10GE, hardware
forwarding OpenFlow added by NEC team in Japan NEC announced plans for OpenFlow products Deployed at Stanford and in JGN2plus in Tokyo
HideyukiShimonishi
JunSuzuki
MasanoriTakashima
NobuyukiEnomoto
PhilavongMinaxay
ShuichiSaito
TatsuyaYabe
YoshihikoKanaumi
NEC/NICT NEC/NICT
AtsushiIwata
OpenFlowSwitch.org
Cisco
Experimental feature on Catalyst 6509 Software forwarding Deployed at Stanford
QuickTime™ and a decompressor
are needed to see this picture.
QuickTime™ and a decompressor
are needed to see this picture.
FlavioBonomi
SaileshKumar
PereMonclus
OpenFlowSwitch.org
Nicira
MartinCasado
ScottShenker
TeemuKoponen
NatashaGude
JustinPettit
Created NOX controller Available at http://NOXrepo.org (GPL) Deployed at Stanford
Controller
OpenFlowSwitch.org
Internet2 Team
Chris Small Matt Zekauskas Installing Juniper MX-480 in NY
OpenFlowSwitch.orgStanford Team