Transcript The Stanford Clean Slate Program: An Overview

OpenFlow
Guru Parulkar
[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
OpenFlowSwitch.org
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
The Big Picture
Applications
PocketSchool, Virtual Worlds, Augmented Reality
Handheld
UI
Energy efficient
Secure OS
HW Platform
Network of VMs, Mobile VMs
Data Substrate
PRPL Virtual Data System
Network Substrate
OpenFlow
Radio technology
Multi-Gb/s, 99% coverage
Economics
Secure mobile browser
WEB/Computing Substrate
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
5
Internet Ossification
Lack of data
& control
path sep
Complex ASICs
Massive sw
Resistant to change
Arch
Weaknesses
Industry, IETF, …
High
Barrier to
Entry
Increasingly
complex
data path
Add complexity to address
weaknesses
 Not a conspiracy -- just a fact of life
Research community has been staring at this problem
for several years

6
OpenFlow Model
Allow lots of innovation
Diverse applications
Routing,
Mobility,
Diverse
transport layers
Naming/Addressing,
Ethernet
IP X Y Z
Access Control,
Flow layer
Management,
Monitoring…
Diverse link layers
Diverse physical layers
7
Staged Approach
1.
2.
3.
4.
5.
Define OpenFlow feature
Add OpenFlow to commercial switches and APs
Deploy at Stanford
2009: Run NSF-funded trials on 6 college campuses
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)
OpenFlowSwitch.org
Agenda
 High
Level Rationale
 OpenFlow Basics
 OpenFlow Demo
 Generalization of Flow
 Separation of Data and Control Paths
 Virtualized OpenFlow Infrastructure
 OpenFlow Deployment and Trials
OpenFlow Basics (1)
Exploit the flow table in switches, routers, and chipsets
Flow 1.
Rule
(exact & wildcard)
Action
Statistics
Flow 2.
Rule
(exact & wildcard)
Action
Statistics
Flow 3.
Rule
(exact & wildcard)
Action
Statistics
Rule
(exact & wildcard)
Default Action
Statistics
Flow N.
OpenFlowSwitch.org
OpenFlow Basics (2)
Rule
(exact & wildcard)
Action
As general as possible
e.g. Port, VLAN ID, L2, L3, L4, …
As wide as possible
Statistics
Count packets & bytes
Expiration time/count
Small number of fixed actions
e.g. unicast, mcast, map-to-queue, drop
Extended via virtual ports
e.g. tunnels, encapsulate, encrypt
OpenFlowSwitch.org
OpenFlow Basics
OpenFlow Switch specification
PC
Net Services
OpenFlow
Switch
sw
hw
Secure
Channel
Flow
Table
Controller
• Add/delete flow entries
• Encapsulated packets
• Controller discovery
API
OpenFlow Usage
Dedicated OpenFlow Network
Controller
Chip’s code
Rule
PC
OpenFlow
Action
Statistics
Switch
OpenFlow
Protocol
Rule
OpenFlow
Action
Statistics
Switch
OpenFlowSwitch.org
Rule
OpenFlow
Action
Statistics
Switch
Chip
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
 …
OpenFlowSwitch.org
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 radio networks:
WiFi, WiMax, LTE, …
• Dumb access points
• User choice
15
Deployment on Stanford campus
• 100 of WiFi APs in 4 buildings
& outdoor locations
• A few Mobile WiMAX femtocell
base 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)
We are ready for
innovation in our network!
Mobile
16 WiMAX AP
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
17
OpenFlow Demo
OpenFlowSwitch.org
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?
Types of action
 Application flow
 All http
 John’s traffic
 All packets to China
…
 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 action
Specific actions should easily evolve
Unicast
1.
Multicast
2.
Multipath
3.
 Load-balancing
 Redundancy
Waypoints
4.
 Middleware
 Intrusion detection
 …
Separation of Control
from Datapath
Operators, users, 3rd party developers, researchers, …
New function!
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
Allow or deny flow?
Whose flow is it?
How to route flow?
DPI
Passive
Measurement
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
Step 1: Separate VLANs for
Production and Research Traffic
Controller
Research VLANs
Flow Table
Production VLANs
OpenFlowSwitch.org
Normal L2/L3 Processing
Step 2:
Virtualize OpenFlow Switch
Controller A
Controller B
Researcher A VLANs
Flow Table
Researcher B VLANs
Controller C
Flow Table
Researcher C VLANs
Flow Table
Production VLANs
Normal L2/L3 Processing
OpenFlowSwitch.org
Virtualizing Control
Heidi’s
Controller
Aaron’s
Controller
Craig’s
Controller
OpenFlow
Protocol
OpenFlow
Switch
OpenFlow
Hypervisor & Policy Control
OpenFlow
Protocol
OpenFlow
Switch
OpenFlowSwitch.org
OpenFlow
Switch
Virtualized OpenFlow Substrate
Net Services
Aaron’s
Controller
Net Services
Heidi’s
Controller
Craig’s
Controller
API
API
API
Net Services
OpenFlow
Protocol
OpenFlow
Switch
Hypervisor & Policy Control
OpenFlow
Protocol
OpenFlow
Switch
OpenFlow
Switch
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
OpenFlowSwitch.org
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


Eight switch vendors enabling this capability


Don’t need to build our own boxes which is a major barrier
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
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
http://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
OpenFlowSwitch.org
Michaela
Mezo
Parag
Bajaria
James
Kelly
Bobby
Vandalore
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
OpenFlowSwitch.org
Jean
Tourrilhes
Sujata
Banerjee
Rick
McGeer
Charles
Clark
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
Atsushi
Iwata
Hideyuki
Shimonishi
Jun
Suzuki
OpenFlowSwitch.org
Masanori Nobuyuki Philavong
Takashima Enomoto Minaxay
Shuichi
Saito
NEC/NICT
Tatsuya
Yabe
Yoshihiko
Kanaumi
NEC/NICT
Cisco
 Experimental feature on Catalyst 6509
 Software forwarding
 Deployed at Stanford
QuickTime™ and a
decompressor
are needed to see this picture.
Pere
Monclus
OpenFlowSwitch.org
Sailesh
Kumar
Flavio
Bonomi
Controller
Nicira
 Created NOX controller
 Available at http://NOXrepo.org (GPL)
 Deployed at Stanford
Martin
Casado
Scott
Shenker
OpenFlowSwitch.org
Teemu
Koponen
Natasha
Gude
Justin
Pettit
Internet2 Team
Chris Small
Matt Zekauskas
Installing Juniper MX-480 in NY
OpenFlowSwitch.org
Stanford Team
OpenFlowSwitch.org