Transcript Network Substrate: Software Defined Networks and

Stanford University
POMI2020: Network
Substrate
Software-defined Networks, and OpenFlow
NSF Site Visit, June 2010
Nick McKeown
Sachin Katti
Monica Lam
Ramesh Johari
Guru Parulkar
POMI
2020
POMI Research Agenda
Infrastructure
Applications
Handheld
Secure mobile
browser
Cinder: Energy
aware, secure OS
HW Platform
Data & Computing Substrate
PrPl, Junction and Concierge
Network Substrate
Software Defined Network & OpenFlow
Radio technology
Economics
UI
Outline
We set out to address two “barriers to innovation”
in the network…
Barrier 3: There is abundant capacity available,
but it is closed and unavailable
Barrier 4: The network infrastructure is closed
and will remain ossified
3
What do we mean when we say the
network is “closed and ossified”?
4
The Ossified Network
Routing, management, mobility management,
access control, VPNs, …
Feature
Feature
Operating
System
Specialized Packet
Forwarding Hardware
Million of lines
of source code
5400 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
5
Glacial process of innovation made worse
by captive standards process
Deployment
Idea
Standardize
Wait 10 years
1.
2.
3.
4.
Driven by vendors
Owners/operators largely locked out
Lowest common denominator features
Glacial innovation
Unlikely to change without external help
6
Example where change is needed
Cellular industry
– Recently made transition to IP
– Billions of mobile users
– Need to securely extract payments and hold users
accountable
– IP is dreadful at both, yet hard to change
7
Telco Operators
e.g. AT&T, DT, NTT, …
• Global IP traffic will grow 5x by 2013
• End-customer monthly bill remains unchanged
• Therefore, CAPEX and OPEX need to be
reduced 5x by 2013
• But in practice, reduces by <20% per year
Q: How can operators reduce cost?
Q: How can they differentiate their service?
8
The SDN Approach*
Separate control from the datapath
– i.e. separate policy from mechanism
Datapath: Define minimal network instruction set
– A set of “plumbling primitives”
– A vendor-agnostic interface: OpenFlow
Control: Define a network-wide OS
– An API that others can develop on
* With Scott Shenker, Martin Casado and many others
9
Restructured Network
Feature
Feature
Network OS
Feature
Feature
Operating
System
Feature
Specialized Packet
Forwarding Hardware
Feature
Feature
Operating
System
Feature
Specialized Packet
Forwarding Hardware
Operating
System
Feature
Specialized Packet
Forwarding Hardware
Feature
Operating
System
Feature
Feature
Specialized Packet
Forwarding Hardware
Operating
System
Specialized Packet
Forwarding Hardware
10
The “Software-defined Network”
3. Well-defined open API
Feature
Feature
2. At least one Network OS
probably many.
Open- and closed-source
Network OS
1. Open interface to hardware
OpenFlow
Simple Packet
Forwarding
Hardware
Simple Packet
Forwarding
Hardware
Simple Packet
Forwarding
Hardware
Simple Packet
Forwarding
Hardware
Simple Packet
Forwarding
Hardware
11
OpenFlow Basics
Narrow, vendor-agnostic interface to
control switches, routers, APs, basestations.
12
Step 1:
Separate Control from Datapath
Network OS
OpenFlow
Switch
OpenFlow
Switch
OpenFlow
Switch
OpenFlow
Switch
13
Step 2: Cache flow decisions in datapath
“If header = x, send to port 4”
“If header = y, overwrite header with z, send to ports 5,6”
“If header = ?, send to me”
Flow
OpenFlow
Table
Switch
OpenFlow
Switch
OpenFlow
Switch
OpenFlow
Switch
14
Plumbing Primitives
1. Match arbitrary bits in headers:
Data
Header
Match: 1000x01xx0101001x
– Match on any header; or new header
– Allows any flow granularity
2. Actions:
– Forward to port(s), drop, send to controller
– Overwrite header with mask, push or pop
– Forward at specific bit-rate
15
The “Software-defined Network”
3. Well-defined open API
Feature
Feature
2. At least one Network OS
probably many.
Open- and closed-source
Network OS
1. Open interface to hardware
OpenFlow
Simple Packet
Forwarding
Hardware
Simple Packet
Forwarding
Hardware
Simple Packet
Forwarding
Hardware
Simple Packet
Forwarding
Hardware
Simple Packet
Forwarding
Hardware
16
Isolated “slices”
Many operating systems, or
many versions
Feature
Feature
Feature
Feature
Network
Operating
System 1
Network
Operating
System 2
Network
Operating
System 3
Network
Operating
System 4
Open interface to hardware
Virtualization or “Slicing” Layer (FlowVisor)
Open interface to hardware
Simple Packet
Forwarding
Hardware
Simple Packet
Forwarding
Hardware
Simple Packet
Forwarding
Hardware
Simple Packet
Forwarding
Hardware
Simple Packet
Forwarding
Hardware
Our Strategy
Barrier: The network infrastructure is closed and
will remain ossified
Strategy: The Software Defined Network
– Add OpenFlow to switches, routers, WiFi APs,
basestations, … deploy in our network
– Use SDN for our own research
– Study how to apply to different types of network
– Enable others to do research in their network
– (Work with GENI community to deploy widely)
18
Some research examples
19
Ethane, a precursor to OpenFlow
Centralized, reactive, per-flow control
Controller
Simple Packet
Forwarding
Hardware
Simple Packet
Forwarding
Hardware
Simple Packet
Forwarding
Hardware
Host B
Host A
Simple Packet
Flow
Switch
Forwarding
Hardware
[Ethane, Sigcomm ‘07]
FlowVisor Creates Virtual Networks
OpenPipes
Demo
OpenFlow Wireless
Demo
PlugNServe
Load-balancer
OpenFlow
Protocol
OpenFlow
Switch
OpenFlow
Switch
OpenFlow
Protocol
OpenFlow
Switch
FlowVisor
OpenPipes
Policy
Multiple, isolated
slices in the same
physical network
[Paper in submission]
[Sigcomm 2009 – Best Demo]
Demo Infrastructure with Slicing
OpenPipes
Partition hardware designs across a network
[Sigcomm 2009 – 2nd Best Demo]
23
[Paper in submission]
Load-balancing as Network Primitive
Goal: Minimize http response time over campus network
Approach: Route over path to jointly minimize <path latency, server latency>
“Pick path & server”
Internet
LoadBalancer
Network OS
OpenFlow
Switch
OpenFlow
Switch
OpenFlow
Switch
OpenFlow
Switch
OpenFlow
Switch
[Sigcomm 2009 Demo]
24
[Paper in preparation]
Intercontinental VM Migration
Moved a VM from Stanford to Japan without changing its IP.
VM hosted a video game server with active network connections.
[Sigcomm 2008– Best Demo]
Converging Packet and Circuit Networks
Goal: Common control plane for “Layer 3” and “Layer 1” networks
Approach: Add OpenFlow to all switches; use common network OS
Feature
Feature
NOX
OpenFlow
Protocol
OpenFlow
Protocol
WDM
Switch
IP
Router
TDM
Switch
IP
Router
WDM
Switch
[Supercomputing 2009 Demo]
[OFC 2010]
ElasticTree
Goal: Reduce energy in data center networks
Approach:
1. Reroute traffic
2. Shut off links and switches to reduce power
“Pick paths”
DC
Manager
Network OS
[NSDI 2010]
ElasticTree
Goal: Reduce energy in data center networks
Approach:
1. Reroute traffic
2. Shut off links and switches to reduce power
X
X
X
“Pick paths”
DC
Manager
X
Network OS
X
[NSDI 2010]
Making a Network Application Friendly
“Create a chat room”
“Send to all participants”
Junction
“Encrypt data”
“Min. bandwidth is 6Mbps”
“Create a multicast group”
“Encrypt a flow”
“Calculate multicast routing”
“Assign flow rate”
Phone2Phone
Apps
Network OS
OpenFlow
Switch
OpenFlow
Switch
OpenFlow
Switch
OpenFlow
Switch
[SIGCOMM’10 APSys Workshop]
[SIGCOMM’10 MobiHeld Workshop]
Will SDN happen?
30
We now believe SDN will happen
It is starting in big data centers
– Driven by cost and control
– Unable to cope with virtualization, multi-tenancy…
– We are trying to “steer” them in same direction
Growing interest by ISPs, cellular operators
(GENI: Deploying on college campuses)
31
Example: New Data Center
Cost
Control
200,000 servers
Fanout of 20 a 10,000 switches
$5k vendor switch a $50M
$1k commodity switch a $10M
1.More flexible control
2.Quickly improve and innovate
3.Enables “cloud networking”
Savings in 10 data centers = $400M
We believe large data centers will use SDN.
POMI Progress
OpenFlow added to many devices
– Switches, routers, APs, basestations, transport
switches, chips
Many research experiments have validated the
approach
Deployments happening on college campuses
33
Self Assessment
+ Good progress on basic architecture
+ “Slicing” very promising
+ Research experiments validate the approach
- The networking industry is very entrenched
- To break down the barrier, it takes a lot of
engineering.
+ More deployments than we expected
- Difficult to scale to meet interest/demand
34
Outline
We set out to address two “barriers to innovation”
in the network…
Barrier: The network infrastructure is
closed and will remain ossified
Barrier: There is abundant capacity available,
but it is closed and unavailable
35
What does it take to…..
Open the wireless infrastructure
so users can choose any free
spectrum, any network, or many
networks, any time?
36
AT&T
3G
Sprint
WiMAX
Any network….
37
AT&T
3G
Sprint
WiMAX
Many networks….
38
What does it take to
give users choice?
39
Technology and contracting
Contracts are limited or enabled by technology
This has a first order impact on network
economics
[ Example: BGP and interdomain routing ]
1. What technology is needed to enable a
new form of contract?
2. Are there countervailing economic forces that
might prevent efficient use of new technology?
Application: Learning to share
Can wireless providers learn to share?
Technologies such as OpenFlow Wireless and
radio virtualization enable users to make choices.
Will providers let them?
Central requirement is complementarity:
Profit-maximizing providers must find collective
action in their own best interest.
Examples:
Geographical complementarity (roaming).
Overcoming high fixed costs (tower sharing).
How do we give users choice?
42
Wish List
1. Instantaneous contracts with any physical
network, independent of its owner or radio
technology
2. A network-independent way to choose a
network, and to control mobility
43
Design Choice
1. Establish my own instantaneous contracts
and control the network (hard), or
1. Delegate to an entity in the infrastructure
– A service provider
– My own agent
Conceptually the same; we start by delegating
44
Requirement
Technical
– Radio-independent control layer
– A method for a service provider to control my
flows on my behalf
Business
– An incentive for infrastructure owners to open
access to service providers
45
“AT&T”
Billing,
Mobility
New Service
Network OS
“Vodafone”
New Service
Billing,
Mobility
New Service
Network OS
Feature
Feature
Network OS
Network OS
“Slicing” Layer
OpenFlow
Switch
OpenFlow
Switch
OpenFlow
Switch
OpenFlow
BS
OpenFlow
AP
Consequences
Radio-independent control layer
– Service provider controls user flows
– Easy handover between physical networks
– Can use several networks simultaneously
– Service innovation by service providers
A method to share the physical infrastructure
– Isolation between service providers
– Short-term or long-term lease of rights-of-way
47
AT&T
Service Layer: Authentication, Billing,
Mobility Management, Routing, …
Network Layer: Wireline Network
Radio Network: Spectrum, Radios
48
Separating the service
from the network
Service Layer: Authentication, Billing,
Mobility Management, Routing, …
Separation/Virtualization
Network Layer: Wireline Network
Radio Network: Spectrum, Radios
49
Service provider controls a slice
across physical networks
Service
“AT&T”
Service
Service
Service
Network
Network
Network
Separation/Virtualization
Network
Radio Network: Spectrum, Radios
50
Progress so far
Created OpenFlow wireless network
– WiFi and WiMAX
– Sliced by bandwidth, flowspace, and SSID
Experiments in mobility management
– Projects Class
– Lossless handover
– Predictive handover
– Vertical handover
(With GENI, plan to deploy in other campuses)
51
Next Steps
Control across physical network owners
– With Clearwire: Vertical handoff between our
WiMAX network and theirs
– With Google: OpenWiFi project to share WiFi
access
– Outsourcing management of home networks
– On GENI: Separation of control from network
nationwide (WiFi and WiMAX).
52
A natural next step
“AT&T”
Billing,
Mobility
New Service
Network OS
“Vodafone”
Billing,
Mobility
New Service
Network OS
My Application
Specific Service
Application
Specific
Control
User
Application
Network OS
“Slicing” Layer
OpenFlow
Switch
OpenFlow
Switch
OpenFlow
Switch
OpenFlow
Switch
OpenFlow
WiFi AP
Examples
1. Junction
General communication broker
2. Application specific quality control
In-network replication
54
Demonstration
My Application
Specific Service
“Give me high
quality”
Network OS
Video server
“Loss!”
OpenFlow
BS
OpenFlow
Switch
Loss!
OpenFlow
Switch
OpenFlow
AP
OpenFlow
Switch
OpenFlow
AP
55
Can we virtualize the radio and
spectrum?
56
Step 1: Separating service from network
Service Layer: Authentication, Billing,
Mobility Management, Routing, …
Separation/Virtualization
Network Layer: Wireline Network
Radio Network: Spectrum, Radios
57
Step 1: Open the wireless infrastructure
so users can choose any network, or
many networks, any time?
What about the network operator?
Can we open the wireless infrastructure so
operators can choose any radio, any
available spectrum, any time?
58
Step 2: Separating network from radio
Service Layer: Authentication, Billing,
Mobility Management, Routing, …
Separation/Virtualization
Network Layer: Wireline Network
Separation/Virtualization
Radio Network: Spectrum, Radios
59
Why separate network from radio?
AT&T
3G
Sprint
WiMAX
60
Why separate network from radio?
AT&T
3G
Sprint
WiMAX
61
Trends
• Currently, ~10 wireless devices per person
Future, expect 1000 devices per person
 a trillion devices coming online
• Most of them will be battery operated and
expected to last a long time
• Current WiFi+Cellular infrastructure won’t scale
62
How to meet this demand?
Provide high throughput connectivity anytime, anywhere
while keeping battery consumption constant/low
Current networks operate close to the Shannon limit
 Change how networks are architected
Increase density : Bring the infrastructure and client closer
Increase spectrum : Adaptively exploit unused spectrum
Who will pay for this infrastructure/spectrum?
• Revenue is not keeping pace with traffic growth
 Operators unlikely to invest in expensive infrastructure
• To scale, the same physical infrastructure and spectrum
has to be shared among multiple networks
Our approach: Separate networks from physical
infrastructure/spectrum via virtualization
Step 2: Separating network from radio
AT&T Verizon Sprint
New Virtual
Network
Network Layer:
Wireline Network
Separation/Virtualization
Radio Network:
Spectrum, Radios
WiMax BS
LTE BS
LTE BS
700-900Mhz 1.8-1.9GHz 2.6-2.8GHz
Software
Radio
Network operators use any BS with spectrum that’s available
(assuming the BS works in that range)
65
Spectrum Virtualization
• Spectrum resources can be used along 3
dimensions
– Frequency
– Space
– Time
• Spectrum Slice Abstraction
– Sets of non-contiguous frequencies as a virtual
spectral block (VSB)
– OFDM to stitch together non-contiguous bands
Infrastructure Virtualization
• Different networks need to co-exist on the same
physical hardware
– Guarantee power, spectrum and timing isolation
• Two approaches
– Virtualizing within the same technology (e.g. LTE BS)
• Scheduling flows to provide QOS, and spectrum virtualization to share
spectrum
– Virtualizing hardware to support heterogeneous wireless
technologies (e.g. LTE and WiMax on the same BS)
• Designing higher level computing units (FFT, message passing decoders
etc) that can be stitched to create different wireless PHYs
Self Assessment
+ Progress being made towards our “big vision”
+ Surprised how easy experiments are to create
+ Expanded the vision to virtualize infrastructure &
spectrum
- Hard to work with cellular providers
- Hard to deploy widely: Spectrum, engineering
- A lot of work left to reach our “big vision”
68