Transcript A Simple Unified Control Plane for Packet and Circuit Networks

http://openflowswitch.org
Unifying Packet & Circuit Networks
with OpenFlow
Saurav Das, Guru Parulkar, & Nick McKeown
Stanford University
Huawei, Feb 3rd 2010
Internet has many problems
Plenty of evidence and documentation
Internet’s “root cause problem”
It is Closed for Innovations
2
We have lost our way
Routing, management, mobility management,
access control, VPNs, …
App
App
App
Operating
System
Specialized Packet
Forwarding Hardware
Million of lines
of source code
5400 RFCs
Barrier to entry
500M gates
10Gbytes RAM
Bloated
Power Hungry
IPSec
Firewall
Router
Software
Control
OSPF-TE
RSVP-TE
HELLO
HELLO
HELLO
Hardware
Datapath
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”
Reality
App
App
App
App
Operating
System
App
App
Operating System
Specialized Packet
Forwarding Hardware
Specialized Packet
Forwarding Hardware
• Lack of competition means glacial innovation
• Closed architecture means blurry, closed interfaces
Glacial process of innovation made
worse by captive standards process
Idea
Standardize
Wait 10 years
• Driven by vendors
• Consumers largely locked out
• Glacial innovation
Deployment
Change is happening in non-traditional markets
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
The “Software-defined Network”
2. At least one good operating system
Extensible, possibly open-source
3. Well-defined open API
App
App
App
Network Operating System
1. Open interface to hardware
Simple Packet
Forwarding
Hardware
Simple Packet
Forwarding
Hardware
Simple Packet
Forwarding
Hardware
Simple Packet
Forwarding
Hardware
Simple Packet
Forwarding
Hardware
The change has already started
In a nutshell
– Driven by cost and control
– Started in data centers…. and may spread
– Trend is towards an open-source,
software-defined network
– Growing interest for cellular and telecom networks
Example: New Data Center
Cost
Control
200,000 servers
Fanout of 20 a 10,000 switches
$5k commercial switch a $50M
$1k custom-built switch a $10M
1. Optimize for features needed
2. Customize for services & apps
3. Quickly improve and innovate
Savings in 10 data centers = $400M
Large data center operators are moving towards defining their own network in software.
Trend
App
App
App
Windows
Windows
Windows
(OS)
(OS)
(OS)
Linux
Linux
Linux
App
App
App
Mac
Mac
Mac
OS
OS
OS
Virtualization layer
x86
(Computer)
Computer Industry
Controller11
NOX
Controller
(Network OS)
Controller
Controller
Network
OS
22
Virtualization or “Slicing”
OpenFlow
Network Industry
Simple common stable hardware substrate below+ programmability + strong isolation
model + competition above = Result : faster innovation
Decoupled
Automated
Control
Simple, Robust, Reliable
Data Path
Control
Signaling
Data
Controller
The Flow Abstraction
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
Flow N.
Rule
(exact & wildcard)
Default Action
Statistics
e.g. Port, VLAN ID, e.g. unicast, mcast, Count packets & bytes
L2, L3, L4, …
map-to-queue, drop Expiration time/count
OpenFlow Switching
Controller
OpenFlow Switch
sw Secure
Channel
hw Flow
Table
• Add/delete flow entry
• Encapsulated packets
• Controller discovery
A Flow is any combination of above 14
fields
described in the Rule
Flow Example
Routing
Controller
A Flow is the fundamental
unit of manipulation within a switch
Rule
Action
Statistics
OpenFlow
Protocol
Rule
Action
Statistics
Rule
Action
Statistics
OpenFlow is Backward Compatible
Ethernet Switching
SwitchMAC
Port src
MAC Eth
dst type
VLAN IP
ID
Src
IP
Dst
IP
Prot
TCP TCP
sport dport
Action
*
00:1f:..*
*
*
*
*
port6
SwitchMAC
Port src
MAC Eth
dst type
VLAN IP
ID
Src
*
*
*
*
*
IP Routing
*
*
*
*
IP
IP
TCP TCP
Action
Dst Prot sport dport
5.6.7.
*
*
*
port6
8
Application Firewall
SwitchMAC
Port src
*
*
*
MAC Eth
dst type
*
VLAN IP
ID
Src
IP
Dst
IP
Prot
TCP TCP
sport dport
Action
*
*
*
*
drop
*
22
OpenFlow allows layers to be combined
Flow Switching
SwitchMAC
Port src
port3
MAC Eth
dst type
VLAN IP
ID
Src
00:2e.. 00:1f.. 0800
vlan1
IP
Dst
IP
Prot
1.2.3.4 5.6.7.8 4
TCP TCP
Action
sport dport
17264 80
port6
VLAN + App
SwitchMAC
Port src
*
*
MAC Eth
dst type
*
*
VLAN IP
ID
Src
IP
Dst
IP
Prot
TCP TCP
Action
sport dport
vlan1
*
*
*
*
80
port6,
port7
Port + Ethernet + IP
SwitchMAC
Port src
port3
MAC Eth
dst type
00:2e.. *
0800
VLAN IP
ID
Src
IP
Dst
*
5.6.7.8
*
IP
Prot
4
TCP TCP
Action
sport dport
*
*
port 10
A Clean Slate Approach
Goal: Put an Open platform in hands of
researchers/students to test new ideas at scale
Approach:
1. Define OpenFlow feature
2. Work with vendors to add OpenFlow to their
switches
3. Deploy on college campus networks
4. Create experimental open-source software
- researchers can build on each other’s work
18
OpenFlow Hardware
Juniper MX-series
HP Procurve 5400
Quanta LB4G
NEC IP8800
WiMax (NEC)
WiFi
Cisco Catalyst 6k
Arista 7100 series
(Fall 2009)
Ciena CoreDirector
(Fall 2009)
OpenFlow Deployments
Research and Production Deployments
on commercial hardware
Juniper, HP, Cisco, NEC, (Quanta), …
• Stanford Deployments
– Wired: CS Gates building, EE CIS building, EE Packard
building (soon)
– WiFi: 100 OpenFlow APs across SoE
– WiMAX: OpenFlow service in SoE
• Other deployments
– Internet2
– JGN2plus, Japan
– 10-15 research groups have switches
Nationwide OpenFlow Trials
UW
Univ
Wisconsin
Princeton
Stanford
NLR
Indiana
Univ
Rutgers
Internet2
Clemson
Georgia
Tech
Production deployments
before end of 2010
Motivation
IP and Transport networks
C
D
C
C
 are separate
networks
that
are
controlled
and
D
D
managed independently leading toDCduplication of
functions and resources in multiple layers and high
capex and opex
C
C
 do not dynamically
interact
and
thus
do
not
benefit
C
D
from diverse
switching
technologies
D
D
C
D
D
 have very different
architectures that makes
C
D
D
integrated operation and convergence
hard
D
D
UCP
C
D
C
D
C
D
C
D
C
Flow
Network
C
D
C
D
C
D
C
D
D
D
D
D
D
pac.c
Research Goal: Packet and Circuit Flows Commonly
Controlled & Managed
Simple,
Robust,
Reliable
network
of Flow
Switches
Flow
Network
… that switch at different granularities: packet, time-slot, lambda & fiber
OpenFlow & Circuit Switches
Packet Flows
Switch MAC
Port src
MAC Eth
dst
type
VLAN IP
ID
Src
IP
Dst
IP
Prot
TCP
TCP
sport dport
Action
Exploit the cross-connect table in circuit switches
Circuit Flows
In
Port
VCG Starting Signal
In
25
Lambda
Time-Slot Type
Out
Port
VCG Starting Signal
Out
25
Lambda
Time-Slot Type
The Flow Abstraction presents a unifying abstraction
… blurring distinction between underlying packet and circuit
and regarding both as flows in a flow-switched network
25
Unified Architecture
App
App
App
App
Networking
Applications
NETWORK OPERATING SYSTEM
OPENFLOW Protocol
Packet
Switch
Circuit
Switch
Unifying
Abstraction
Packet & Circuit
Switch
Unified
Control
Plane
Underlying Data
Plane Switching
OpenFlow UCP
enables innovation
@
pkt-ckt interface
Network
Recovery
Congestion
Routing
Control
Traffic
QoS
Engineering Power
Mgmt
Security
Discovery
27
OpenFlow Example
IP 11.12.0.0
VLAN 1025
IP 11.13.0.0
TCP 80
+ VLAN2, P1
+ VLAN2, P2
VLAN2
VCG 3
VCG3
P1 VC4 1
P2 VC4 4
P1 VC4 10
+ VLAN7, P2
VLAN7
VCG5
VCG5
P3 STS192 1
OpenFlow
(software)
R
A
S
OpenFlow
(software)
R
A
S
IN
Packet
Packet Switch Fabric
OUT
TDM
VCG3
VCG5
Switch Fabric
GE
ports
Circuit
Switch Fabric
TDM
ports
Example Application (1)
Congestion
Control
..via Variable Bandwidth Packet Links
OpenFlow Demo at SC09
Example Application (2)
Traffic
Engineering
Example Application (2)
Traffic
Engineering
..via Dynamic Automated Optical Bypass
Controller
NOX
OpenFlow
protocol
NetFPGA based
OF packet switch
Ethernet
Hosts
AWG
AWG
WSS
(1×9)
WSS
(1×9)
Fujitsu WSS based
OF circuit switch
OpenFlow packet switch
OpenFlow packet switch
25 km SMF
GE-Optical
GE-Optical
Mux/Demux
Openflow Circuit Switch
Unified Virtualization
C
C
OpenFlow Protocol
C
FLOWVISOR
OpenFlow Protocol
CK
P
CK
CK
P
CK
CK
P
P
Unified Virtualization
ISP ‘A’ Client
Controller
C
Private Line
Client Controller
C
High-end Client
Controller
C
OpenFlow Protocol
Under Transport n/w
Service Provider control
FLOWVISOR
OpenFlow Protocol
CK
Isolated
Client
Network
Slices
P
CK
CK
P
CK
CK
P
P
Single
Physical
Infrastructure
of Packet &
Circuit
Switches
Summary
• OpenFlow is a large clean-slate program with many
motivations and goals
• convergence of packet & circuit networks is one such goal
• OpenFlow simplifies and unifies across layers and
technologies
• packet and circuit infrastructures - electronics and photonics
• while unified API allow innovations
• in data and control planes independently
• in network control, management and virtualization
• Example demonstrations at circuit & packet intersection
• Variable Bandwidth Packet Links
• Dynamic Automated Optical Bypass
• More @ http://openflowswitch.org/wk/index.php/PAC.C
Backup
Issues with Current IP & Transport n/w
• Separate management systems and incompatible protocols -
complexity of managing across several layers, interfaces &
architectures, leading to duplication of resources and functions
• Lack of a unified architecture across packet and circuit –
• fully distributed with tightly linked control and data planes in packet
networks,
• fully distributed, decentralized or fully centralized in transport networks,
• multiple vendor domains with proprietary interfaces prevent greater
integration and increase complexity
• GMPLS the only attempt towards a UCP across packet & circuit (2000)
• Today – Packet vendors and ISPs are not interested
• Transport n/w SPs view it as a signaling tool available to the mgmt system
for provisioning private lines (not related to the Internet)
• After 10 yrs of development, next-to-zero significant deployment
• GMPLS Issues 
Issues with GMPLS
•Issues are when considered as a unified architecture
and control plane
• control plane complexity escalates when unifying across packets
and circuits because it
• makes basic assumption that the packet network remains same:
IP/MPLS network – many years of legacy L2/3 baggage
• and that the transport network remain same - , multiple layers and
multiple vendor domains
• use of fragile distributed routing and signaling protocols with
many extensions, increasing switch cost & complexity, while
decreasing robustness
• does not take into account the conservative nature of network
operation • can IP networks really handle dynamic links?
• Do transport network service providers really want to give up
control to an automated control plane?
• does not provide easy path to network virtualization
PWE3
CORBA
Transport
NE
Software
Control
HELLO
RSVP-TE
HELLO
OSPF-TE
HELLO
Hardware
Datapath
Many complex functions baked into the infrastructure
41
More coming ……
Control Plane Architectures
Control Plane
OF Protocol
Data Plane
OpenFlow: Architecture Concepts
• Separate data from control
– A standard protocol between data and control
• Define a “generalized flow” based data path
– Very flexible and generalized flow abstraction
– Delayer or open up layers1-7
• Hierarchically centralized “open” controller with API
– For control and management applications
• Virtualization of data and control planes
• Backward compatible
– Though allows completely new header
OpenFlow: Architecture Implications
• Separate data from control
– Independent innovations in data and control planes
– Less dependence on a single vendor
• Define a “generalized flow” based data path
– Simpler data path: cheaper, uniform, stable
– Applicable across technologies and layers
• Hierarchically centralized “open” control with an API
– Easier to make reliable and robust
– Enables lots of innovations by different stakeholders
OpenFlow: Architecture Implications
• Virtualization
– Enable innovations and experimentation
– Deployment of new ideas: “production revision control”
• Backward compatible
– Easy to support in existing switches/routers and networks
– Easy to show the value proposition
Software Defined Networking