1

OpenFlow History & Progress

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.1In

tere

st

OpenFlow Usage Models1. 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

5

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

6

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

7

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

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

10

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.

11

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

12

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

13

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

14

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.

15

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

Thank You – Q&A

17

ConfigAPP1 to App2App3 to App1Web to DBEtc.

ConfigAPP1 to App2App3 to App1Web to DBEtc.

ConfigAPP1 to App2App3 to App1Web to DBEtc.

ConfigAPP1 to App2App3 to App1Web to DBEtc.

ConfigAPP1 to App2App3 to App1Web to DBEtc.

App1 App1

App3

App2 App2

App3

ConfigAPP1 to App2App3 to App1Web to DBEtc.

ConfigAPP1 to App2App3 to App1Web to DBEtc.

How OpenFlow works (Simplified)

Applications flows are preprovisioned throughout the network

Topology/application changes are reflected

APIs allow application to instruct network behavior

SDN/OpenFlow Customer Use Case 1- Trevela

18

Provider of a market-leading distributed fabric for global trading, risk analysis and e-commerce

Validated networking based upon OpenFlow, for predictable performance for complex and demanding applications

Fast Packet Forwarding using OpenFlow

Intelligent path selection

Line Rate Performance

Fast Convergence

Predictable performance

OpenFlow based traffic segregation

SDN/OpenFlow customer use case 2: Selerity

19

OF API

OF API OF API

OF API OF API OF API

Closed network elements forced the customer to a server to do the packet processing needed

Provider of ultralow-latency realtime financial information• Delivers machine-readable event data immediately as events are breaking which relies on

the fastest possible network performance

Performance impactNot an ideal solution

Used OpenFlow to get complete control of the network

Network based upon OpenFlow provided an order of magnitude (1000 times) better performance

SDN/OpenFlow Customer Use Case 3 – SPAN and Tap

20

DiagnosticComplianceMonitoring Auditing

Parallel network for diagnostics, compliance, auditing

Move flows from SPAN or TAP to OpenFlow switches

Cost-effective alternative to special-purpose devices

Open, standards-based cost-effective solution

Real World Deployments

FlowVisor

Alice Bob Cathy

IsolationPolicy

Scalable isolation domains and network slicing.

Example: Flowvisor

Network Virtualization

Inserting and managing network services, such as load balancing, firewall, IDS/IPS, QoS, etc.

Example: FlowScale

Platform for Network Services

Flexible mobility of virtual machines

Example: Stanford WAN VM Migration

Virtual Machine Management

CLOS Fabrics

Lower cost, high-performance networks

Example: non-blocking CLOS architectures

Simplified data vibility and traffic monitoring

Data Analysis / Monitoring Hybrid Clouds

Networks spanning public / private DCs

Example: Amazon VPC

21

OpenFlow as a strawman flow-based substrate

Our Approach1. Define the substrate

• OpenFlow is an open external API to a flow-table

• Version 1.0– Defined to be easy to add to existing hardware switches,

routers, APs, …– Timeframe: Now

• Version 2.0– OpenFlow-optimized hardware– General “flowspace”– Timeframe: 2011

OpenFlow Deployments• Stanford Deployments

– Wired: CS Gates building, EE CIS building, EE Packard building

– WiFi: 100 OpenFlow APs across SoE– WiMAX: OpenFlow service in SoE

• Other deployments– Internet2 (NetFPGA switches)– JGN2plus, Japan (NEC switches)– 10-15 research groups have switches

OpenFlow DeploymentsPlans in 2009-10

• Campus deployments– Lab + production use– “Enterprise GENI” (NSF/GPO)

• Backbone deployments– National research backbones– Research + Production use