Costin Raiciu
Using slides from Brandon Heller and
Nick McKeown

How do we test a new idea in computer networking?

I have my shiny new protocol. How do I test it?
• Implement and test it in software
– Quick prototyping, bad performance
• Build your own hardware!
– Prohibitive costs
– Difficult to change the design after its built
• Convince a vendor to implement a protocol
– Huh!

Feature
Operating
System
The Networking Industry (2007)
Routing, management, mobility management, access control, VPNs, …
Feature
Million of lines of source code
5400 RFCs Barrier to entry
Specialized Packet
Forwarding Hardware
Billions of gates Complex Power Hungry
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”
Little ability for non-telco network operators to get what they want
Functionality defined by standards, put in hardware, deployed on nodes
4

Closed Systems (Vendor Hardware)
• Can’t extend
• Stuck with interfaces (CLI, SNMP, etc)
• Hard to meaningfully extend
• Hard to meaningfully collaborate
• Vendors starting to open up, but not usefully
5

• Give a simple interface to the data plane in hardware
– Goes fast
– Don’t need to change functionality
• Implement control plane in software
– Can change as often as required

OpenFlow Switch specification
OpenFlow Switch
Controller
PC sw
Secure
Channel hw
Flow
Table

Flow Table Entry
“Type 0” OpenFlow Switch
Rule Action Stats
Packet + byte counters
1. Forward packet to port(s)
2. Encapsulate and forward to controller
3. Drop packet
4. Send to normal processing pipeline
Switch
Port
+ mask
MAC src
MAC dst
Eth type
VLAN
ID
IP
Src
IP
Dst
IP
Prot
TCP sport
TCP dport

• When a packet does not match any rule, encapsulate and send it to the controller
• The controller can decide to:
– Insert a new rule to process the flow
– Drop the packet

• Reference implementation – C
• NOX – python, C++
• Trema – C, Ruby
• Many others…

• On controller startup:

• Dedicated OpenFlow switches
– Forwarding done only based on OF rules
– Rules can be inserted beforehand to reduce lookup times
• OpenFlow-Enabled Switches
– Enable experiments to take place alongside existing traffic
– Allow the use of the “normal” processing pipeline

• Spec maintained by the OpenFlow consortium
– Currently at version 1.1
• Supported by most switch vendors
• Flow tables increasing in size
– Hundreds to thousands of rules
• Big hype on software-defined networking