unifying packet & circuit networks with openflow
DESCRIPTION
http://openflowswitch.org. Unifying Packet & Circuit Networks with OpenFlow. Saurav Das, Guru Parulkar , & Nick McKeown Stanford University Huawei , Feb 3 rd 2010. Internet has many problems Plenty of evidence and documentation Internet’s “root cause problem” - PowerPoint PPT PresentationTRANSCRIPT
Unifying Packet & Circuit Networks
with OpenFlowSaurav Das, Guru Parulkar, & Nick McKeown
Stanford University
Huawei, Feb 3rd 2010
http://openflowswitch.org
Internet has many problems
Plenty of evidence and documentation
Internet’s “root cause problem”
It is Closed for Innovations
2
Million of linesof source code
5400 RFCs Barrier to entry
500M gates10Gbytes RAM
Bloated Power Hungry
We have lost our way
Specialized Packet Forwarding Hardware
OperatingSystem
App App App
Routing, management, mobility management, access control, VPNs, …
SoftwareControl
Router
HardwareDatapath
Auth
entica
tion,
Secu
rity, A
ccess
Contro
l
HELLO
MPLS
NATIPV6
anycastmulticas
tMobile IP
L3 VPN
L2 VPN VLANOSPF-TE
RSVP-TEHELLOHELLO
Firewall
Multi layer m
ulti
region
iBGP,
eBGP
IPSec
Many complex functions baked into the infrastructureOSPF, BGP, multicast, differentiated services,Traffic Engineering, NAT, firewalls, MPLS, redundant layers, …
An industry with a “mainframe-mentality”
Operating SystemOperating System
Reality
App
AppApp
Specialized Packet Forwarding Hardware
Specialized Packet Forwarding Hardware
Specialized Packet Forwarding Hardware
OperatingSystem
App App App
• Lack of competition means glacial innovation• Closed architecture means blurry, closed interfaces
DeploymentIdea Standardize
Wait 10 years
Glacial process of innovation made worse by captive standards
process
• Driven by vendors• Consumers largely locked out• Glacial innovation
Specialized Packet Forwarding Hardware
App
App
App
Specialized Packet Forwarding Hardware
App
App
App
Specialized Packet Forwarding Hardware
App
App
App
Specialized Packet Forwarding Hardware
App
App
App
Specialized Packet Forwarding Hardware
OperatingSystem
OperatingSystem
OperatingSystem
OperatingSystem
OperatingSystem
App
App
App
Network Operating System
App App App
Change is happening in non-traditional markets
App
Simple Packet Forwarding Hardware
Simple Packet Forwarding Hardware
Simple Packet Forwarding Hardware
App App
Simple Packet Forwarding Hardware Simple Packet
Forwarding Hardware
Network Operating System
1. Open interface to hardware
3. Well-defined open API2. At least one good operating system
Extensible, possibly open-source
The “Software-defined Network”
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
Cost200,000 serversFanout of 20 10,000 switches$5k commercial switch $50M$1k custom-built switch $10M
Savings in 10 data centers = $400M
Control
1.Optimize for features needed2.Customize for services & apps3.Quickly improve and innovate
Large data center operators are moving towards defining their own network in software.
Windows(OS)
Windows(OS)
Linux MacOS
x86(Computer)
Windows(OS)
AppApp
LinuxLinuxMacOS
MacOS
Virtualization layer
App
Controller 1
AppApp
Controller2
Virtualization or “Slicing”
App
OpenFlow
Controller 1NOX(Network OS)
Controller2Network OS
Trend
Computer Industry Network Industry
Simple common stable hardware substrate below+ programmability + strong isolation model + competition above = Result : faster innovation
Signaling
Control
Data
Simple, Robust, ReliableData Path
Controller
DecoupledAutomated Control
Open Interface
Into Hardware
The Flow Abstraction
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.
e.g. Port, VLAN ID, L2, L3, L4, …
e.g. unicast, mcast, map-to-queue, drop
Count packets & bytesExpiration time/count
14
Controller
OpenFlow Switch
FlowTableFlowTable
SecureChannelSecureChannel
OpenFlow
Protocol
SSL
hw
sw
OpenFlow Switching
• Add/delete flow entry• Encapsulated packets• Controller discovery
A Flow is any combination of above fields described in the Rule
ControllerFlow Example
OpenFlowProtocol
Rule Action Statistics
Rule Action Statistics Rule Action Statistics
A Flow is the fundamentalunit of manipulation within a switch
Routing
OpenFlow is Backward Compatible
Ethernet Switching
*
SwitchPort
MACsrc
MACdst
Ethtype
VLANID
IPSrc
IPDst
IPProt
TCPsport
TCPdport
Action
* 00:1f:..* * * * * * * port6
Application Firewall
*
SwitchPort
MACsrc
MACdst
Ethtype
VLANID
IPSrc
IPDst
IPProt
TCPsport
TCPdport
Action
* * * * * * * * 22 drop
IP Routing
*
SwitchPort
MACsrc
MACdst
Ethtype
VLANID
IPSrc
IPDst
IPProt
TCPsport
TCPdport
Action
* * * * *5.6.7.8
* * * port6
OpenFlow allows layers to be combined
VLAN + App
*
SwitchPort
MACsrc
MACdst
Ethtype
VLANID
IPSrc
IPDst
IPProt
TCPsport
TCPdport
Action
* * * vlan1 * * * * 80 port6, port7
Flow Switching
port3
SwitchPort
MACsrc
MACdst
Ethtype
VLANID
IPSrc
IPDst
IPProt
TCPsport
TCPdport
Action
00:1f..0800 vlan1 1.2.3.4 5.6.7.84 17264 80 port600:2e..
port3
SwitchPort
MACsrc
MACdst
Ethtype
VLANID
IPSrc
IPDst
IPProt
TCPsport
TCPdport
Action
0800 5.6.7.8 4 port 1000:2e..
Port + Ethernet + IP
* ****
A Clean Slate Approach
18
Goal: Put an Open platform in hands of researchers/students to test new ideas at
scaleApproach:
1. Define OpenFlow feature2. Work with vendors to add OpenFlow to their switches
3. Deploy on college campus networks4. Create experimental open-source software - researchers can build on each other’s work
OpenFlow Hardware
Cisco Catalyst 6k
NEC IP8800
HP Procurve 5400
Juniper MX-series WiMax (NEC) WiFi
Quanta LB4G Ciena CoreDirectorArista 7100 series (Fall 2009) (Fall 2009)
OpenFlow Deployments
• 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
Research and Production Deployments on commercial hardware
Juniper, HP, Cisco, NEC, (Quanta), …
UW
Stanford
UnivWisconsin
IndianaUniv
Rutgers
Princeton
ClemsonGeorgia
Tech
Internet2
NLR
Nationwide OpenFlow Trials
Production deployments before end of 2010
Production deployments before end of 2010
DDC
DDC
DDC
DDC
IP/MPLSIP/MPLS IP/MPLS
IP/MPLS
IP/MPLSIP/MPLS
IP/MPLSIP/MPLS
CDD
CDD
CDD
DD
DD
DD
DD
C C
DD
DD
GMPLS
Motivation
IP and Transport networks
are separate networks that are controlled and managed
independently leading to duplication of functions and resources
in multiple layers and high capex and opex
do not dynamically interact and thus do not benefit from
diverse switching technologies
have very different architectures that makes integrated
operation and convergence hard
FlowNetwork
DDC
DDC
DDC
DDC
IP/MPLSIP/MPLS IP/MPLS
IP/MPLS
IP/MPLSIP/MPLS
IP/MPLSIP/MPLS
CDD
CDD
CDD
DD
DD
DD
DD
C C
DD
DD
GMPLS
UCP
pac.c
FlowNetwork
… that switch at different granularities: packet, time-slot, lambda & fiber
Simple,Robust,Reliablenetwork of Flow Switches
Research Goal: Packet and Circuit Flows Commonly Controlled & Managed
25
OpenFlow & Circuit Switches
Exploit the cross-connect table in circuit switches
Packet FlowsSwitchPort
MACsrc
MACdst
Ethtype
VLANID
IPSrc
IPDst
IPProt
TCPsport
TCPdport
Action
25
Circuit Flows
Signal Type
VCG25 Signal Type
VCG
The Flow Abstraction presents a unifying abstraction
… blurring distinction between underlying packet and circuit and regarding both as flows in a flow-switched network
Unified Architecture
OPENFLOW Protocol
PacketSwitch
CircuitSwitch
Packet & Circuit Switch
NETWORK OPERATING SYSTEM
Underlying Data Plane SwitchingUnderlying Data Plane Switching
AppApp AppApp AppApp AppApp
UnifiedControl Plane
Unifying Abstraction
Networking Applications
Congestion ControlQoS
27
OpenFlow UCPenables innovation
@pkt-ckt interface
NetworkRecovery
Traffic Engineering
PowerMgmt
SecurityDiscovery
Routing
IN OUT
GE ports
TDM ports
Packet
Switch Fabric
Packet
Switch Fabric
OpenFlow(software)OpenFlow(software)
R A S R A S
IP 11.12.0.0 + VLAN2, P1 VLAN2 VCG 3
OpenFlow(software)OpenFlow(software)
VLAN 1025 + VLAN2, P2
VLAN7 VCG5
Packet Switch FabricPacket Switch Fabric
IP 11.13.0.0 TCP 80
+ VLAN7, P2
TDM
CircuitSwitch Fabric
VCG5
VCG3
VCG3 P1 VC4 1 P2 VC4 4 P1 VC4 10
VCG5 P3 STS192 1
OpenFlow Example
Congestion Control
Congestion Control
Example Application (1)
..via Variable Bandwidth Packet Links
OpenFlow Demo at SC09
TrafficEngineering
Example Application (2)
TrafficEngineering
Example Application (2)
..via Dynamic Automated Optical Bypass
Controller
OpenFlowprotocol
AWGWSS(1×9)
AWG Fujitsu WSS basedOF circuit switch
Ethernet
Hosts
NOX
WSS(1×9)
NetFPGA basedOF packet switch
Openflow Circuit Switch
25 km SMF
OpenFlow packet switch OpenFlow packet switch
GE-Optical
GE-Optical
Mux/Demux
OpenFlow Protocol
C
C C
FLOWVISOR
OpenFlow Protocol
CK
CK
CK
PP
CK
P
CKP
Unified Virtualization
OpenFlow Protocol
C C C
FLOWVISOR
OpenFlow Protocol
CK
CK
CK
PP
CK
P
CKP
ISP ‘A’ Client Controller
Private Line Client Controller
High-end Client Controller
Under Transport n/w Service Provider control
IsolatedClient
Network Slices
SinglePhysical
Infrastructureof Packet &
Circuit Switches
Unified Virtualization
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 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
Issues with GMPLS
LMP
HELLO
41
UNI
TL-1GMPLS
PBB-TECarrier
EthernetMPLS-TP
ASON
ENNI intra
ENNI inter
OSPF-TE
RSVP-TEHELLOHELLO
CORBA
L1VPN
,
L2VPN
PCE PWE3
Many complex functions baked into the infrastructure
More coming ……
Control Plane
Data Plane
OF Protocol
Control Plane Architectures
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