1. Overview of SDN Controller Design
SDN Re-cap
SDN Controller Design: Case Studies
NOX
Next Week:
ONIX
ONOS
Scalability and other design issues of SDN controllers
This Thursday:
Overview of Mininet and OVS -- by Hesham Mekky
CSci8211: SDN Controller Design

2. CSci8211: SDN Controller Design
SDN Recap
General forwarding model (data plane abstraction)
Currently based on Openflow (flow-level) forwarding model
prioritized rules [header: counters, actions]: match  actions
assume forwarding elements provide (standardized) APIs
install and manipulate forwarding tables, perform match and actions, & collect stats, etc.
Logically centralized control plane (a “network OS”)
serve as a “network operating system”
provide distributed state management, map control logic to data plane actions, etc.
provide a “global network view” to (high-level) “control apps”
enable “higher-level” abstractions to hide “lower-level” details
Control apps operate on higher-level abstractions
control apps focus on “control logic” using network OS APIs
Hopefully, much easier to write, verify and maintain!
CSci8211: SDN Controller Design

3. CSci8211: SDN Controller Design
How to design a Network Operating System?
What features or “abstractions” should be provided by this “Network Operating System”?
In particular, what should be the “global network view” & “programmatic interfaces” provided to control apps?
or what “low-level” details should be handled by Network OS?
And what is the granularity of control allowed to “apps”?
Analogies (& possible differences?):
computer OS and (high-level) programming models
computer architecture: instruction sets, CPU, memory, disks, I/O devices, ...
(high-level) programming language constructs: statements, data types, functions, …
OS: (virtual) memory, processes, I/O and drivers, system calls, …
(distributed) file systems (or databases or data stores)
files, directories & permissions, transactions, relations & schemas; vs. disks, ….
CSci8211: SDN Controller Design

4. SDN Controller Design Questions
Some Key Questions & Issues:
How to obtain global (network-wide) information?
How to perform distributed state management?
time scales of state change dynamics? consistency issues?
What are the configurations? Abstractions & APIs?
How to implement such a Network OS?
And will it really work? E.g., response time & other performance issues?
How to program control apps? E.g., a SDN programming language?
Will it scale?
Not only in terms of network size, but also # flows, control apps, etc.?
What about reliability & security issues?
… (e.g., inter-operability, evolvability)
Are there some fundamental design principles we can adopt & apply?
CSci8211: SDN Controller Design

5. CSci8211: SDN Controller Design
NOX Case Study
1st open-source network OS implemented in C++ by Stanford
Components:
NOX controller on PC server
network view (database)
control app processes
Network View:
switch-level topology
locations of users, hosts, middle-
boxes & other network elements
services offered (e.g., web, NFS)
bindings between names & addresses
but NOT current state of network traffic
Control granularity
flow-level (as opposed to packet-level, or network-prefix level)
control exerted on flow initiation: e.g., 1st packet of a flow (following packets treated same)
CSci8211: SDN Controller Design

6. Time Scales & Control Granularity
Time scales (in conventional networks)
“Events” & control granularity
Packet arrivals: millions of arrivals per sec (on a 10G link)
Flow initiations: one or more orders less than packet arrivals (notion of “flows” is more “persistent” than Netflow)
Changes in the “network views”: order of 10s of events per second for a network of thousands of hosts
Scaling? network view vs. per-flow vs. per-packet states?
CSci8211: SDN Controller Design

7. Programmatic Interface
Event-based:
Events: flow arrives, users come/go, links up/down, etc
Some events are directly generated by Openflow switches,
e.g., switch join/leave, packet received, switch stats received
Others by other services/applications: e.g., user authenticated
NOX applications use a set of event handlers to register for execution when a particular event happens
Event handlers are executed in the order of their priority
specified during handler registration (but how to determine priority?)
Network View and Namespaces
NOX includes a “base” applications to construct network view and maintain a high-level namespace used by other applications
e.g., various “name-address” bindings
Applications can be written in a “topology-independent” manner, then “compiled” against network view to produce low-level “look-up” functions to be enforced per-packet
Also include “high-level” services (“system libraries”)
CSci8211: SDN Controller Design

8. Example I: User-Based VLAN Tagging
CSci8211: SDN Controller Design

9. Example II: Simple Scan Detection
CSci8211: SDN Controller Design

10. CSci8211: SDN Controller Design
Onix Case Study
1st commercial network OS implemented in Nicira
Design Goals
Generality
Scalability
Reliability
Simplicity
Control plane performance
Components:
managed physical infrastructure
connectivity infrastructure
Onix
Control logic implemented by management applications
CSci8211: SDN Controller Design

11. CSci8211: SDN Controller Design
Onix Design
Onix API:
data model that represents the network infrastructure
with each network elements corresponding to one or more data objects
control logic: read the current state associated with the data objects; alter the network state by operating on these objects; and register for notifications of state changes to these objects
Network Information Base (NIB)
A copy of network state tracked by Onix and stored in a data structure called NIB (similar to RIB in routers)
NIB: a collection of network entities, each identified by a flat 128-bit identifiers, and holds a set of key-value pairs
network entities are “base data structure ” from which all types are derived: Onix supports (strong) typed entities!
Typed entities: predefined attributes and methods
CSci8211: SDN Controller Design

12. CSci8211: SDN Controller Design
Typed Entity Examples
CSci8211: SDN Controller Design

13. CSci8211: SDN Controller Design
Onix NIB API
CSci8211: SDN Controller Design

14. Onix Scaling & Reliability
Scaling: Onix supports three strategies to improve scaling
Partitioning
Aggregation
Consistency & Durability
Reliability: handle four types of failures
network element & link failures
Onix (instance) failures
connectivity infrastructure failures
While Onix handles replication & distribution of NIB data, it relies application-specific logic to both detect & provide conflict resolution of network state as it is exchanged among multiple Onix instances
CSci8211: SDN Controller Design

15. CSci8211: SDN Controller Design
Distributing the NIB
Two guiding observations in design of state distribution mechanisms:
Applications have differing requirements on scalability, frequency of updates on shared space, and durability
Distinct applications often have different requirements for consistency of the network state they manage
App designers responsible for explicitly determining mechanisms; write their own import/export modules to transfer data into/out of NIB
State distribution between Onix instances
two types of data stores: i) transactional persistent database or ii) one-hop eventually consistent, memory-only DHT (similar to Dynamo)
Network Element State Management
does not dictate switch mgmt protocol-> NIB: primary interface to apps
Consistency and Coordination
requires apps to declare what data to be imported/exported
does not require strong consistency
CSci8211: SDN Controller Design