Transcript Seminar: Introduction to SDN/OpenFlow

Introduction to
OpenFlow /SDN
&
its effects on the future of Internet
Mohammad Moghaddas
[email protected]
www.1cisco.com
2012, July
Welcome
Goals of this Seminar
By the end, everyone should know:
– Knowledge about OpenFlow/SDN
• What these are
• How they relate
• What’s available now
• Where it’s going
• How it’s used
– OpenFlow/SDN and You
• How you can use it
• How you can build on top of what’s available
• How you can build something completely new
Have fun!
Original Question
How can researchers on college campuses test out
new ideas in a real network, at scale?
 We like to do new experiments:
Mobility management
New naming/address schemes
Network access control
New features of Cloud Computing
Virtualization features
….
Problem
Many good research ideas
on college campuses…
No way to test new ideas at scale, on
real networks, with real user traffic
Consequence: Almost no
technology transfer
Research problems
Well known problems
Security, mobility, availability
Incremental ideas
Fixing BGP, multicast, access control,
Mobile IP, data center networks.
More radical changes
Energy management, VM mobility, …
The only test network large enough to
evaluate future Internet technologies
at scale, is the Internet itself.
Today’s Networks are Defined by the
“Box”
• Hardware, Operating System, and
Applications Built Into a “Box”.
• Cannot Mix and Match
• Barrier to Entry
AppAppAppAppAppAppAppAppAppAppApp
Specialized
Applications
Specialized
Operating
System
Specialized
Hardware
Vertically integrated
Closed, proprietary
Slow innovation
Small industry
Open Interface
Windows
(OS)
or
Linux
or
Open Interface
Microprocessor
Horizontal
Open interfaces
Rapid innovation
Huge industry
Mac
OS
AppAppAppAppAppAppAppAppAppAppApp
Specialized
Features
Specialized
Control
Plane
Specialized
Hardware
Vertically integrated
Closed, proprietary
Slow innovation
Open Interface
Control
Plane
or
Control
Plane
or
Open Interface
Merchant
Switching Chips
Horizontal
Open interfaces
Rapid innovation
Control
Plane
What is SDN?
Current Internet
Closed to Innovations in the Infrastructure
Closed
Ap
p
Ap
p
Ap
p
Operating
System
Ap
p
Specialized Packet
Forwarding Hardware
Ap
p
Ap
p
Ap
p
Ap
p
Operating
System
Ap
p
Specialized Packet
Forwarding Hardware
Operating
System
Ap
p
Specialized Packet
Forwarding Hardware
Ap
p
Ap
p
Operating
System
Ap
p
Ap
p
Ap
p
Specialized Packet
Forwarding Hardware
Operating
System
Specialized Packet
Forwarding Hardware
13
“Software Defined Networking” approach
to open it
App
App
App
Network Operating System
Ap
p
Ap
p
Ap
p
Operating
System
Ap
p
Specialized Packet
Forwarding Hardware
Ap
p
Ap
p
Ap
p
Ap
p
Operating
System
Ap
p
Specialized Packet
Forwarding Hardware
Operating
System
Ap
p
Specialized Packet
Forwarding Hardware
Ap
p
Ap
p
Operating
System
Ap
p
Ap
p
Ap
p
Operating
System
Specialized Packet
Forwarding Hardware
Specialized Packet
Forwarding Hardware
Software Defined Network (SDN)
(
f View
Control
Programs
)
(
f View
(
)
Control
Programs
f View
)
Control
Programs
Abstract Network View
Network Virtualization
Global Network View
Network OS
Packet
Forwarding
Packet
Forwarding
Packet
Forwarding
Packet
Forwarding
Packet
Forwarding
Software Defined Network (SDN)
(
f View
Control
Programs
)
(
firewall.c
…
f View
(
)
f View
)
if( pkt->tcp->dport == 22)
Control
Control
dropPacket(pkt);
Programs
Programs
…
Abstract Network View
Network Virtualization
Global Network View
1. <Match, Action>
Network
OS
2. <Match, Action>
1. <Match, Action>
2. <Match, Action>
3. <Match, Action>
4. <Match, Action>
5. <Match, Action>
6. …
7. …
Packet
Forwarding
Packet
Forwarding
3. <Match, Action>
4. <Match, Action>
5. <Match, Action>
6. …
7. …
1. <Match, Action>
2. <Match, Action>
3. <Match, Action>
4. <Match, Action>
5. <Match, Action>
6. …
7. …
Packet
Forwarding
Packet
Forwarding
Packet
Forwarding
1. <Match, Action>
2. <Match, Action>
3. <Match, Action>
4. <Match, Action>
5. <Match, Action>
6. …
7. …
1. <Match, Action>
2. <Match, Action>
3. <Match, Action>
4. <Match, Action>
5. <Match, Action>
6. …
7. …
With SDN we will:
1. Formally verify that our networks are
behaving correctly.
2. Identify bugs, then systematically
track down their root cause.
How do other
industries do it?
Making ASICs Work
Specification
Functional
Description (RTL)
Testbench &
Vectors
Functional
Verification
Logical Synthesis
Static Timing
Place & Route
Design Rule
Checking (DRC)
Layout vs
Schematic (LVS)
Layout Parasitic
Extraction (LPE)
Manufacture
& Validate
$10B tool business
supports a
$250B chip industry
Making Software Work
Specification
Functional
Description (Code)
Static Code
Analysis
Run-time Checker
Testbench
Invariant
Checker
Model
Checking
Interactive
Debugger
$10B tool business
supports a
$300B S/W industry
Example: New Data Center
Cost
200,000 servers
Fanout of 20  10,000 switches
$5k vendor switch = $50M
$1k commodity switch = $10M
Savings in 10 data centers = $400M
Making Networks Work (Today)
traceroute, ping, tcpdump, SNMP, Netflow
…. er, that’s about it.
Why debugging networks is hard
Complex interaction
– Between multiple protocols on a switch/router.
– Between state on different switches/routers.
Multiple uncoordinated writers of state.
Operators can’t…
– Observe all state.
– Control all state.
Networks are kept working by
“Masters of Complexity”
A handful of books
Almost no papers
No classes
Philosophy of Making Networks Work
YoYo
“You’re On Your Own”
YoYo Ma
“You’re On Your Own, Mate”
With SDN we will:
1. Formally verify that our networks are
behaving correctly.
2. Identify bugs, then systematically
track down their root cause.
Three Methods
 Static Checking
“Independently checking correctness”
 Automatic Testing
“Is the datapath behaving correctly?”
 Interactive Debugging
“Finding bugs, and their root cause,
in an operational network”
Static checking
Independently checking correctness
Peyman
Kazemian
Hongyi
‘James’
Zeng
George
Varghese
(UCSD)
Motivations
In today’s networks, simple questions are hard
to answer:
– Can host A talk to host B?
– What are all the packet headers from A that can
reach B?
– Are there any loops in the network?
– Is Group X provably isolated from Group Y?
– What happens if I remove a line in the config file?
29
Software Defined Network (SDN)
Control
Programs
Policy
Control
Programs
Control
Programs
“A can talk to B”
Abstract Network View
“Guests can’t reach
PatientRecords”
Network Virtualization
Static
Checker
Global Network View
Network OS
1.
2.
3.
4.
5.
6.
7.
1.
2.
3.
4.
5.
6.
7.
<Match, Action>
<Match, Action>
<Match, Action>
<Match, Action>
<Match, Action>
…
…
Packet
Forwarding
1.
2.
3.
4.
5.
6.
7.
<Match, Action>
<Match, Action>
<Match, Action>
<Match, Action>
<Match, Action>
…
…
Packet
Forwarding
1.
2.
3.
4.
5.
6.
7.
1.
2.
3.
4.
5.
6.
7.
<Match, Action>
<Match, Action>
<Match, Action>
<Match, Action>
<Match, Action>
…
…
Packet
Forwarding
<Match, Action>
<Match, Action>
<Match, Action>
<Match, Action>
<Match, Action>
…
…
Packet
Forwarding
<Match, Action>
<Match, Action>
<Match, Action>
<Match, Action>
<Match, Action>
…
…
Packet
Forwarding
1.
2.
3.
4.
5.
6.
7.
<Match, Action>
<Match, Action>
<Match, Action>
<Match, Action>
<Match, Action>
…
…
1.
2.
3.
4.
5.
6.
7.
<Match, Action>
<Match, Action>
<Match, Action>
<Match, Action>
<Match, Action>
…
…
1.
2.
3.
4.
5.
6.
7.
<Match, Action>
<Match, Action>
<Match, Action>
<Match, Action>
<Match, Action>
…
…
1.
2.
3.
4.
5.
6.
7.
<Match, Action>
<Match, Action>
<Match, Action>
<Match, Action>
<Match, Action>
…
…
How it works
Header Space Analysis
Header Space Analysis
2
3
1
4
1
2
3
4
Port ID
Header Space Analysis
2
3
1
4
1
2
3
4
Port ID
Use Cases
• Can host A talk to B?
All Packets sent from A can use to communicate with B
A
T-11
Box 1
T-11
T-12
Box 2
T2(T1(X,A))
T1(X,A)
T-14
T4(T1(X,A))
Box 4
Box 3
B
T-13
T-13
T3(T2(T1(X,A)) U T3(T4(T1(X,A))
34
Use Cases
• Is there a loop in the network?
– Inject an all-x text packet from every switch-port
– Follow the packet until it comes back to injection
port
T1(X,P)
Box 2
T2(T1(X,P))
T-12
Box 1
T-13
T-11
Box 3
T-14
Original HS
Returned HS
T4(T3(T2(T1(X,P))))
T3(T2(T1(X,P)))
Box 4
35
Use Cases
• Is the loop infinite?
Finite Loop
Infinite Loop
?
36
Header Space Analysis
Consequences
1. Finds all packets from A that can reach B
2. Find loops, regardless of protocol or layer
3. Can prove that two groups are isolated
Proves if network adheres to policy
Works on existing networks and SDNs
Stanford Backbone
Hassell tool
1.
2.
3.
4.
Reads Cisco IOS Configuration
Checks reachability, loops and isolation
10 mins for Stanford Backbone
Easily made parallel: 1 sec is feasible
Hassell is available for free, for you to run
Stanford backbone network
~750K IP fwd rule.
~1.5K ACL rules.
~100 Vlans.
Vlan forwarding.
39
Stanford backbone network
• Loop detection test – run time < 10 minutes on
a single laptop.
Vlan RED
Spanning Tree
Vlan BLUE
Spanning Tree
40
Performance
Performance result for Stanford Backbone Network on a single
machine: 4 core, 4GB RAM.
Generating TF Rules
~150 sec
Loop Detection Test (30 ports)
~560 sec
Average Per Port
~18 sec
Min Per Port
~ 8 sec
Max Per Port
~ 135 sec
Reachability Test (Avg)
~13 sec
41
What is OpenFlow?
Short Story: OpenFlow is an API
• Control how packets are forwarded
• Implementable on COTS hardware
• Make deployed networks programmable
– not just configurable
• Makes innovation easier
• Goal (experimenter’s perspective):
– No more special purpose test-beds
– Validate your experiments on deployed hardware
with real traffic at full line speed
OpenFlow: a pragmatic compromise
• + Speed, scale, fidelity of vendor hardware
• + Flexibility and control
• Leverages hardware inside most switches
today
• Vendors don’t need to expose implementation
 Put an open platform in hands of researchers/students
to test new ideas at scale through production networks.
 An open development environment for all researchers
 Give access to flow tables in switches:
- lookup tables, access control list, etc..
- Control packet forwarding in routers and switches.
How Does OpenFlow
Work?
Ethernet Switch
Control Path (Software)
Data Path (Hardware)
OpenFlow Controller
OpenFlow Protocol (SSL/TCP)
Control Path
OpenFlow
Data Path (Hardware)
OpenFlow Flow Table Abstraction
Software
Layer
Controller
PC
OpenFlow Firmware
Flow Table
Hardware
Layer
MAC
src
MAC
dst
IP
Src
IP
Dst
TCP
TCP
Action
sport dport
*
*
*
5.6.7.8
*
port 1
5.6.7.8
port 2
*
port 3
port 1
port 4
1.2.3.4
OpenFlow Basics
Flow Table Entries
Rule
Action
Stats
Packet + byte counters
1.
2.
3.
4.
5.
Switch VLAN
Port
ID
Forward packet to port(s)
Encapsulate and forward to controller
Drop packet
Send to normal processing pipeline
Modify Fields
MAC
src
MAC
dst
Eth
type
IP
Src
IP
Dst
IP
Prot
TCP
sport
TCP
dport
Examples
Switching
Switch MAC
Port src
*
MAC Eth
dst
type
00:1f:.. *
*
VLAN IP
ID
Src
IP
Dst
IP
Prot
TCP
TCP
Action
sport dport
*
*
*
*
IP
Dst
IP
Prot
TCP
TCP
Action
sport dport
*
*
port6
Flow Switching
Switch MAC
Port src
MAC Eth
dst
type
port3 00:20.. 00:1f.. 0800
VLAN IP
ID
Src
vlan1 1.2.3.4 5.6.7.8
4
17264 80
port6
Firewall
Switch MAC
Port src
*
*
MAC Eth
dst
type
*
*
VLAN IP
ID
Src
IP
Dst
IP
Prot
TCP
TCP
Forward
sport dport
*
*
*
*
*
22
drop
Examples
Routing
Switch MAC
Port src
*
*
MAC Eth
dst
type
*
*
VLAN IP
ID
Src
IP
Dst
*
5.6.7.8 *
*
VLAN IP
ID
Src
IP
Dst
IP
Prot
vlan1 *
*
*
TCP
TCP
Action
sport dport
port6,
port7,
*
*
port9
*
IP
Prot
TCP
TCP
Action
sport dport
*
port6
VLAN Switching
Switch MAC
Port src
*
*
MAC Eth
dst
type
00:1f.. *
http://geni.net
GENI OpenFlow deployment (2010)
83 Universities/Research centers & 2 National Backbones
http://groups.geni.net/geni/wiki/ProtoGENIFlashClient
Switches
Stanford Reference
Implementation
• Linux based Software Switch
• Release concurrently with specification
• Kernel and User Space implementations
• Note: no v1.0 kernel-space implementation
• Limited by host PC, typically 4x 1Gb/s
• Not targeted for real-world deployments
• Useful for development, testing
• Starting point for other implementations
• Available under the OpenFlow License (BSD Style) at
http://www.openflowswitch.org
Wireless Access Points
• Two Flavors:
– OpenWRT based (Busybox Linux)
• v0.8.9 only
– Vanilla Software (Full Linux)
• Only runs on PC Engines Hardware
• Debian disk image
• Available from Stanford
• Both implementations are
software only.
NetFPGA
• NetFPGA-based implementation
– Requires PC and NetFPGA card
– Hardware accelerated
– 4 x 1 Gb/s throughput
•
•
•
•
Maintained by Stanford University
$500 for academics
$1000 for industry
Available at http://www.netfpga.org
Open vSwitch
• Linux-based Software Switch
• Released after specification
• Not just an OpenFlow switch; also supports VLAN trunks,
GRE tunnels, etc
• Kernel and User Space implementations
• Limited by host PC, typically 4x 1Gb/s
• Available under the Apache License (BSD Style) at
http://www.openvswitch.org
OpenFlow Vendor Hardware
Product
Prototype
Core
Juniper MX-series
Cisco Catalyst 6k
HP ProCurve 5400
Enterprise
Campus/DC
Circuit
Switch
Cisco Cat3750
Arista 7100 series
(Q4 2010)
Pronto
NEC IP8800
Ciena CoreDirector
WiMAX (NEC)
more to follow...
Wireless
63
HP ProCurve 5400 Series
•
Chassis switch with up to 288 ports of 1G or 48x10G (+
other interfaces available)
•
•
•
•
Line-rate support for OpenFlow
Deployed in 23 wiring closets at Stanford
Limited availability for Campus Trials
Contact HP for support details
Praveen
Yalagandula
Jean
Tourrilhes
Sujata
Banerjee
Rick
McGeer
Charles
Clark
NEC IP8800
• 24x/48x 1GE + 2x 10 GE
• Line-rate support for OpenFlow
• Deployed at Stanford
• Available for Campus Trials
• Supported as a product 
• Contact NEC for details:
• Don Clark ([email protected])
• Atsushi Iwata ([email protected])
Atsushi
Iwata
Hideyuki
Jun
Shimonishi Suzuki
Masanori Nobuyuki
Takashima Enomoto
Philavong
Minaxay
Shuichi
Saito
(NEC/NICT)
Tatsuya
Yabe
Yoshihiko
Kanaumi
(NEC/NICT)
Juniper MX Series
• Up to 24-ports 10GE or 240-ports 1GE
• OpenFlow added via Junos SDK
• Hardware forwarding
• Deployed in Internet2 in NY and at Stanford
• Prototype
• Availability TBD
Umesh
Krishnaswamy
Michaela
Mezo
Parag
Bajaria
James
Kelly
Bobby
Vandalore
Cisco 6500 Series
• Various configurations available
• Software forwarding only
• Limited deployment as part of demos
• Availability TBD
Work on other Cisco models in progress
Pere
Monclus
Sailesh
Kumar
Flavio
Bonomi
Demo Infrastructure with Slicing
WiMax
WiFi APs
OpenFlow switches
Flows
Packet processors
– The individual controllers and the FlowVisor are applications on commodity PCs (not shown)
Be sure to check out the demos in www.openflow.org
OpenFlow Demonstration Overview
Topic
Network
Virtualization
Hardware
Prototyping
Demo
FlowVisor
OpenPipes
Load Balancing
PlugNServe
Energy Savings
ElasticTree
Mobility
MobileVMs
Traffic Engineering
Aggregation
Wireless Video
OpenRoads
FlowVisor Creates Virtual Networks
OpenPipes
Demo
Each demo described here
runs in an isolated slice of
Stanford’s production
network.
OpenFlow
Switch
OpenFlow
Switch
PlugNServe
Load-balancer
OpenRoads
Demo
OpenFlow
Protocol
OpenFlow
Protocol
OpenFlow
Switch
FlowVisor
OpenPipes
Policy
FlowVisor slices OpenFlow
networks, creating multiple
isolated and programmable
logical networks on the
same physical topology.
OpenPipes
•Plumbing with OpenFlow to
build hardware systems
Partition hardware designs
Mix
resources
Test
Plug-n-Serve:
Load-Balancing Web Traffic using OpenFlow
Goal: Load-balancing requests in unstructured networks
What we are showing
 OpenFlow-based distributed load-balancer
Smart load-balancing based on network and server
load
Allows incremental deployment of additional
resources
OpenFlow means…
 Complete control over traffic within the
network
Visibility into network conditions
Ability to use existing commodity hardware
This demo runs on top of the FlowVisor, sharing the same physical network with other experiments and production traffic.
ElasticTree:
Reducing Energy in Data Center Networks
• Shuts off links and switches to reduce data center power
• Choice of optimizers to balance power, fault tolerance, and BW
• OpenFlow provides network routes and port statistics
• The demo:
• Hardware-based 16-node
Fat Tree
• Your choice of traffic
pattern, bandwidth,
optimization strategy
• Graph shows live power
and latency variation
NOX Controller
• Available at http://NOXrepo.org
• Open Source (GPL)
• Modular design, programmable in C++ or Python
• High-performance (usually switches are the limit)
• Deployed as main controller in Stanford
Martin
Casado
Scott
Shenker
Teemu
Koponen
Natasha
Gude
Justin
Pettit
References
• www.geni.net
• www.openflow.org
• www.openflowswitch.org
• www.noxrepo.org
• www.opennetworking.org
• www.cisco.com/go/one
• onrc.stanford.edu
• www.usenix.org
• http://www.techrepublic.com
Thank you!