OpenFlow/Software Defined
Networking
Nick Feamster
Georgia Tech
(some slides courtesy Nick McKeown)
Lithium: Event-Driven Network Control
Nick Feamster, Hyojoon Kim, Russ Clark
Georgia Tech
Andreas Voellmy
Yale University
Pre-GENI Thinking:
Network as Artifact
“There is a tendency in our field to believe that
everything we currently use is a paragon of
engineering, rather than a snapshot of our
understanding at the time. We build great myths
of spin about how what we have done is the only
way to do it to the point that our universities now
teach the flaws to students (and professors and
textbook authors) who don't know better.”
-- John Day
2
What if we could change the
network as easily as applications?
TCP/IP Header in Lego Format.
3
Now, We Can:
Software-Defined Networking
• Before: Network
devices closed,
proprietary
• Now: A single
software program
can control the
behavior of entire
networks.
4
Software-Defined Networking
• Distributed configuration is a bad idea
• Instead: Control the network from a logically
centralized system
2004
2005
RCP
Decision
2008
Dissemination
Discovery
Network
Data
Feamster et al. The Case for Separating Routing from Routers. Proc. SIGCOMM FDNA,
2004
5
Software Defined Networking
6
Background: OpenFlow Switching
OpenFlow Switch specification
OpenFlow Switch
sw Secure
Channel
hw Flow
Table
PC
Controller
Key Idea: Control/Data Separation
8
OpenFlow Forwarding Abstraction
9
OpenFlow 1.0 Flow Table Entry
Rule
Action
Stats
Packet + byte counters
1.
2.
3.
4.
Switch MAC
Port
src
+ mask
MAC
dst
Forward packet to port(s)
Encapsulate and forward to controller
Drop packet
Send to normal processing pipeline
Eth
type
VLAN
ID
IP
Src
IP
Dst
IP
Prot
TCP
sport
TCP
dport
OpenFlow Forwarding Abstraction
• Match
– Match on any header or new header
– Allows any flow granularity
• Action
– Forward to port(s), drop, send to controller
– Overwrite the header
– Forward at a specific bitrate
11
OpenFlow Forwarding Abstraction
• Protocol independent
– Construct Ethernet, IPv4, VLAN, MPLS
– Construct new forwarding methods
• Backwards compatible
– Run in existing networks
• Technology independent
– Switches, routers, WiFi APs
– Cellular basestations
– WDM/TDM circuits
12
Software Defined Network
Management
• Software defined networking (SDN) makes it
easier for network operators to evolve network
capabilities
• Can SDN also help network operators manage
their networks, once they are deployed?
– Campus/Enterprise networks
– Home networks
13
Big Problem: Configuration
Changes Frequently
• Changes to the network
configuration occur daily
– Errors are also frequent
• Operators must
determine
– What will happen in
response to a
configuration change
– Whether the
configuration is correct
14
But, Network Configuration is
Really Just Event Processing!
• Rate limit all Bittorrent traffic between the hours
of 9 a.m. and 5 p.m.
• Do not use more than 100 GB of my monthly
allocation for Netflix traffic
• If a host becomes infected, re-direct it to a
captive portal with software patches
• …
15
Lithium:
Event-Based Network Control
Main Idea: Express network policies as
event-based programs.
Resonance: Inference-Based Access Control for Enterprise Networks. Nayak, Reimers,
Feamster, Clark. ACM SIGCOMM Workshop on Enterprise Networks. August 2009.
16
Extending the Control Model
• OpenFlow only
operates on flow
properties
• Lithium extends the
control model so
that actions can be
taken on time,
history, and user
17
Event-Driven Control Domains
Domain: A condition on which traffic forwarding rules
can be expressed.
18
Dynamic Event Handler
• Reacts to
domain events
• Determines
event source
• Updates state
based on
event type
• Can process
both internal
and external
events
19
Representing Network State:
Finite State Machine
• State: A set of domain values represents a
state. Representation of network state.
• Events: Event-driven control domains invoke
events, which trigger state transitions in the
controller’s finite state machine.
– Intrusions
– Traffic fluctuations
– Arrival/departure of hosts
20
Current Implementation
• NOX Version 0.6.0
• Lithium plumbing: About 1,300 lines of C++
• Policies
– Enterprise network access control: 145 lines of C++
– Home network usage cap management: 130 lines
• Ongoing: Policies without general-purpose
programming
21
Two Real-World Deployments
• Access control in enterprise networks
– Re-implementation of access control on the Georgia
Tech campus network
– Today: Complicated, low-level
– With SDN: Simpler, more flexible
• Usage control in home networks
– Implementation of user controls (e.g., usage cap
management, parental controls) in home networks
– Today: Not possible
– With SDN: Intuitive, simple
22
Example from Campus Network:
Enterprise Access Control
3. VLAN with Private IP
7. REBOOT
Switch
1. New MAC Addr
2. VQP
6. VLAN with Public IP
New Host
4. Web
Authentication
VMPS
5. Authentication
Result
Web Portal
23
Problems with Current Approach
• Access control is too coarse-grained
– Static, inflexible and prone to misconfigurations
– Need to rely on VLANs to isolate infected machines
• Cannot dynamically remap hosts to different
portions of the network
– Needs a DHCP request which for a windows user
would mean a reboot
• Cannot automatically process changes to
network conditions.
24
Lithium: State Machine-Based
Control for Campus Networks
Infection removed or manually fixed
Registration
Failed Authentication
Quarantined
Successful
Authentication
Clean after update
Authenticated
Operation
Vulnerability detected
25
Requirements: Policy Language
• Network policies
– Are dynamic
– Depend on temporal conditions defined in terms of
external events
• Need a way to configure these policies without
resorting to general-purpose programming of
a network controller
• Intuitive user interfaces can ultimately be built on
top of this language
26
Language Design Goals
• Declarative Reactivity: Describing when events
happen, what changes they trigger, and how
permissions change over time.
• Expressive and Compositional Operators:
Building reactive permissions out of smaller reactive components.
• Well-defined Semantics: Simple semantics,
simplifying policy specification.
• Error Checking & Conflict Resolution:
Leveraging well-defined, mathematical
semantics.
27
The Need for Reactive Control
• Simple policies are doable in FML: “Ban the device if
usage exceeds 10 GB in the last 5 days”
• But, adding temporal predicates is difficult!
– “Remove the ban if usage drops below 10 GB.”
– “Remove the ban when an administrator resets.”
• Each condition requires a new predicate.
28
Procera: Programming Reactive,
Event-Based Network Control
Define a signal function for a device
going over (or under) the usage cap:
Define the set of devices over the cap:
• Controller: signal functions and a flow constraint function
• Receives input signals from environment
• Periodically updates a flow constraint function that
controls the forwarding elements
29
Deployment: Campus Network
• Software-defined
network in use
across three
buildings across the
university
• Redesign of network
access control
• Also deployed at
other universities
30
Example From Home Networks:
Usage Control
• Network management in homes is challenging
• One aspect of management: usage control
– Usage cap management
– Parental control
– Bandwidth management
• Idea: Outsource network management/control
– Home router runs OpenFlow switch
– Usage reported to off-site controller
– Controller adjusts behavior of traffic flows
31
Example From Home Networks:
Usage Control
32
Deployment: Home Networks
(Outsourced Home Network Management)
• User monitors
behavior and sets
policies with UI
(next slide)
• Lithium controller
manages policies
and router
behavior
33
uCap: Intuitive Management Interface
Joint work with Boris de Souza, Bethany Sumner, Marshini Chetty.
34
Frontier #1: GENI/SDN @ Home
• OpenFlow deployments in home networks: Slicing
all the way to the end user in the home!
• BISmark (http://projectbismark.net/)
35
Frontier #2: Programmable Substrate
• Augment OpenFlow switches with
custom packet processors
• Device abstraction layer to allow
programmability of this substrate
– Single device
– Network wide
• Applications
– Big data applications
– On-the fly encryption, transcoding,
classification
– Selective deep packet inspection
36
Frontier #3: Policy Languages
• Today’s configuration languages are errorprone, distributed, low-level
• Functional reactive programming
– Support for “boxes and arrows” (or signals and
systems) style programming
– Can support much more complicated conditions
• Procera/Lithium is one example
37
Summary
• Network management is difficult and error-prone
• Lithium: Event-based network control
• Deployment in two real-world settings (campus
and home network)
• Developing a high-level control language that
enables reactive control
38