www.broadcom.comBroadcom Proprietary & Confidential. © 2009 Broadcom Corporation. All rights reserved.
Software Defined Networking – Future of Networking or Hype?
Jun. 2011
“OpenFlow and Software Defined Networking (SDN) are not only here to stay, but they will define the future of networking.”
Art Fewell, Network World, 10/18/2011
3Broadcom Proprietary & Confidential. © 2009 Broadcom Corporation. All rights reserved.
Agenda
• Introduction– What is SDN?
• Open Flow – History– Enabling innovation on campus– Standard way to control flow-tables in commercial switches and routers– Being deployed at Stanford
• Open Controllers and Switches
• Analysis – Pros and Cons– The Potential – Some Use Cases– The Challenges
• Predictions
Introduction• The Networking landscape is currently in a state of disruption due to
Virtualization and Convergence
• This is driving many radical new requirements for networking
• The power-base for driving these requirements may be shifting – from the traditional networking vendors and towards the Data Center operators (Google,
Facebook, Amazon etc), who are seeking to drive down costs and open up interfaces for their own value-add.
• Accordingly the concept of “Software-Defined Networking” has emerged
• The idea is to reduce network devices to relatively simple hardware and software entities on standard compute platforms working through APIs into the network devices.
• The recently announced Open Networking Foundation is the most influential attempt to create industry-standard.
4
What is Software Defined Networking?
5
Forwarding Plane
Network OS
Mgmt Layer
Applications/Protocols
NMS
SNMP,CLI, XML,etc
Today
Forwarding Plane
Network OS
Mgmt
Applications/Protocols
OpenFlow
SDN
TraditionalSwitch/Router
Workstation
OpenFlow Switch
OpenFlow Controller
1
nOpenFlow Agent
OpenFlow History & Progress
6
Ethane
OpenFlow Consortium
OpenFlow 1.0 Spec
Open Networking Foundation
2007 2008 2009 2010 2011
Board: Deutsche Telekom, Facebook, Google (Chair), Microsoft, Verizon, Yahoo!Members: Big Switch Networks, Broadcom, Brocade, Ciena, Cisco, Citrix, Comcast, Dell, Ericsson, Extreme Networks, Force10 Networks, HP, IBM, IP Infusion, Juniper Networks, Marvell, Mellanox Technologies, Metaswitch Networks, NEC, Netgear, Netronome, Nicira Networks, Nokia Siemens Networks, NTT, Plexxi Inc., Riverbed Technology, Vello Systems, Vmware…Growing all the time
Nox, Open vSwitch
Academia
Silicon Vendors,Early adopters (NEC, Google)
Start-ups (Nicira, BigSwitch)
Telcos, System Vendors
OpenFlow 1.1
Inte
rest
Innovations in campus wiring closets
Experiments we’d like to do Mobility managementNetwork-wide energy managementNew naming/addressing schemesNetwork access control
Problem with our networkPaths are fixed (by the network)IP-onlyAddresses dictated by DNS, DHCP, etcNo means to add our own processing
OpenFlow Switching
A way to run experiments in the networks we use everyday.
A “pragmatic” compromiseAllow researchers to run experiments in their network…
…without requiring vendors to expose internal workings.
BasicsAn Ethernet switch (e.g. 128-ports of 1GE)
An open protocol to remotely add/remove flow entries
Experimenter’s Dream(Vendor’s Nightmare)
StandardNetwork
Processing
StandardNetwork
Processinghwsw Experimenter writes
experimental codeon switch/router
User-defined
Processing
User-defined
Processing
No obvious way
Commercial vendor won’t open software and hardware development environmentComplexity of supportMarket protection and barrier to entry
Hard to build my ownPrototypes are flakeySoftware only: Too slowHardware/software: Fanout too small
(need >100 ports for wiring closet)
Furthermore, we want…
• Isolation: Regular production traffic untouched• Virtualized and programmable: Different flows
processed in different ways • Equipment we can trust in our wiring closet• Open development environment for all researchers (e.g.
Linux, Verilog, etc). • Flexible definitions of a flow
Individual application trafficAggregated flowsAlternatives to IP running side-by-side…
Controller
OpenFlow Switch
FlowTableFlowTable
SecureChannelSecureChannel
PCOpenFlow
Protocol
SSL
hw
sw
OpenFlow Switch specification
OpenFlow Switching
Flow Table Entry
SwitchPort
MACsrc
MACdst
Ethtype
VLANID
IPSrc
IPDst
IPProt
TCPsport
TCPdport
Rule Action Stats
1. Forward packet to port(s)2. Encapsulate and forward to controller3. Drop packet4. Send to normal processing pipeline
+ mask
Packet + byte counters
Controller
PC
OpenFlowAccess Point
Server room
OpenFlow
OpenFlow
OpenFlow
OpenFlow-enabledCommercial Switch
FlowTableFlowTable
SecureChannelSecureChannel
NormalSoftware
NormalDatapath
Sample openflow Deployment
OpenFlow Usage Models
1. Experiments at the flow level User-defined routing protocols Network access control Network management Energy management VOIP mobility and handoff
2. Experiments at the packet level Slow: Controller handles packet processing Fast: Redirect flows through programmable hardware Modified routers, firewalls, NAT, congestion control…
3. Alternatives to IP Flow-table is Layer-2 based e.g. new naming and addressing schemes
Controller
PC
NetFPGA
Laboratory
Experiments at the packet level
OpenFlow-enabledCommercial Switch
FlowTableFlowTable
SecureChannelSecureChannel
NormalSoftware
NormalDatapath
Open Flow components
18
Available controllers and switches
NOX (http://noxrepo.org/, GNU GPLv3)
Provides network-wide view of the topology C++ and Python modules make decisions
OpenVSwitch (http://openvswitch.org/, Apache 2) Soft-switch, replaces Linux bridge Designed to be used with VM's
Hardware switches: Quanta LB4G (Broadcom), NetFPGA
Analysis – The Potential
• “SDN will open up networking”– Do for networking what Linux did for the server – break the proprietary lock– Vendors and DC Operators will be able to take control of their network without being
limited to what switch vendors will give them• Do-it-yourself rather than waiting 12 months to work it’s way through a vendor roadmap
– Create an open platform for innovation
• “Centralization of Control will yield better solutions”– Global view of data -> more efficient
• Processing will be done once (rather than in multiple devices per traditional distributed protocols)
– Smaller, simpler code
19
Analysis – The Potential
• “Workstations offer better platforms for processing large distributed datasets”
– “Comp Science is years ahead of embedded in this respect” – e.g. Hadoop– Better, richer, more productive programming environment– Larger, more accessible body of engineering skills
• “OpenFlow will result in lots of cheap switches!”– “White box” unbranded switches, possibly Open Source
• No vendor premium for the heavyweight software load• No vendor lock-in
– Small, cheap CPUs
20
FlowVisor Message Handling
OpenFlowFirmware
Data Path
AliceController
BobController
CathyController
FlowVisorOpenFlow
OpenFlow
Packet
Exception
Policy Check:Is this rule allowed?
Policy Check:Who controls this packet?
Full Line RateForwarding
Rule
Packet
Analysis – The Potential – Use Cases
• ElasticTree: Reducing Energy in Data Center Networks– Today data centers are provisioned for peak traffic running at peak power– Improve the energy efficiency of a data center network– Dynamically adjust network elements - links and switches.– ElasticTree uses OpenFlow to measure traffic statistics and control flow routes– Upto 60% savings demonstrated.
23
Analysis – The Potential – Some Use Cases
• Aster*x: Load-Balancing as a Network Primitive– Traditionally Load Balancing is done with an expensive Box, sitting in the Data path.– Load Balancing is a just smart routing.– Transform an existing network into a distributed load-balancing system.– Demonstrated one such OpenFlow-based load-balancer called Aster*x– Load Balancing became a Control plane solution– http://www.youtube.com/watch?v=Sfqofxdk1gE
24
Analysis – The Potential – Some Use Cases
• Using All Wireless Networks Around Me– This demo shows how we can exploit all the wireless networks around us to achieve
better connectivity and hence better video streaming from a moving vehicle.– simultaneous use of multiple wireless networks. – Uses OpenFlow Wireless-enabled WiFi and WiMAX networks.
– http://www.youtube.com/watch?v=ov1DZYINg3Y
25
Analysis – The Challenges
• “OpenFlow is too limited”– How can you solve all networking problems with such a narrow set of primitives?– All solutions will require lots of network services outside of OpenFlow in order to
function, so does the “openness story” really hang together?
• “You cannot replace all the traditional switch/routing functions”– Need to maintain Controller connectivity across a network– Local processing required for HA/Fast failover– So will the switches really be any cheaper/simpler, or does OpenFlow support
become yet another switch feature?
• “SDN doesn’t scale”– Today switches do a lot of local processing (and need complex software and big
CPUs for a reason!) – they have a lot of dynamic, event-driven processing to-do• Yes you can simplify this, but can you replace or export it?
– If you put all that up on a remote station, the both processing throughput and event latency will become big issues
26
Analysis – The Challenges
• “Is it really that new? What can you do with OpenFlow that we can’t already do with existing configuration methods?”
• “Solutions may move from being Switch vendor to Controller vendor dependent”
– Where’s the interoperability?– Industry-hardened multi-vendor standards have been available in traditional networks
for years.
27
Broadcom’s Involvement
• Early supporter of OpenFlow Consortium with SDK-based reference solutions
• Collaborative FASTPATH Demo Solutions with Controller vendors
• Hybrid model – OpenFlow co-exists with regular switching functions
28
Predictions
• SDN will supplement rather than completely replace traditional switch features
– Will still need much of traditional switching and routing for the foreseeable future– See OpenFlow as a value-add feature
• SDN will create an innovation platform that will attract a lot of interesting solutions
– OpenFlow Controllers will look more like OS’s – platforms not solutions– The Networking “App Store” will arrive!– However many solutions will require optional and proprietary features in the switch
• SDN will create opportunities for silicon innovation– The richer the “instruction set”, the more powerful the solutions!
• Overall, this is a key trend that will happen, and will energize our industry
29
www.broadcom.com
Thank You – Q&A
History/Progression• Origins
– Ethane (Stanford U Research Project) -> OpenFlow• Vehicle for academic research into Network Protocols
• OpenFlow Consortium– Started working on specs for the Controller/Switch interface, got switch implementations started
• Lots of organizations piled in and started driving the specs– Academia, switch vendors, OpenSource community– Start-ups: Nicira, BigSwitch– Users: Google, NEC, etc
• Momentum gathered and companies started seeing lots of possibilities– DC providers/operators, Telcos– Saw it as an opportunity to:-
• Open up switching – break the Cisco lock• Create innovation platforms that they could own• Commoditize Network Switching!
• Basically out-grew the OpenFlow Consortium– OpenFlow seemed too narrowly defined -> Software Defined Networking!– Community became fragmented after OpenFlow 1.1– Enter the Open Networking Foundation!
31Broadcom Proprietary & Confidential. © 2009 Broadcom Corporation. All rights reserved.
Open Network Foundation
• Open Network Foundation members: -– Board: Deutsche Telekom, Facebook, Google (Chair), Microsoft, Verizon, Yahoo!– Members: Big Switch Networks, Broadcom, Brocade, Ciena, Cisco, Citrix, Comcast,
Dell, Ericsson, Extreme Networks, Force10 Networks, HP, IBM, IP Infusion, Juniper Networks, Marvell, Mellanox Technologies, Metaswitch Networks, NEC, Netgear, Netronome, Nicira Networks, Nokia Siemens Networks, NTT, Plexxi Inc., Riverbed Technology, Vello Systems, Vmware
– Growing all the time
32Broadcom Proprietary & Confidential. © 2009 Broadcom Corporation. All rights reserved.
?
Top Related