CSci8211: SDN Controller Design 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

controllersThis Thursday:

Overview of Mininet and OVS -- by Hesham Mekky

CSci8211: SDN Controller Design 2

SDN RecapGeneral 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” detailsControl 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

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 QuestionsSome 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

NOX Case Study1st 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

“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?

Time scales (in conventional networks)

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

Onix Case Study1st commercial network OS implemented in Nicira

Components: managed physical

infrastructure connectivity

infrastructure Onix Control logic

implemented by management applications

Design Goals Generality Scalability Reliability

Simplicity Control plane performance

CSci8211: SDN Controller Design 11

Onix Design

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

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

CSci8211: SDN Controller Design 12

Typed Entity Examples

CSci8211: SDN Controller Design 13

Onix NIB API

CSci8211: SDN Controller Design 14

Onix Scaling & Reliability

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

Scaling: Onix supports three strategies to improve scaling Partitioning Aggregation Consistency & Durability

CSci8211: SDN Controller Design 15

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