naveen nimmu sdn future of networking

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


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


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!


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


?