1. 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 controllers This Thursday: Overview of Mininet and OVS -- by Hesham Mekky

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

3. 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, ….

4. 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?

5. CSci8211: SDN Controller Design 5 NOX Case Study 1 st 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., 1 st packet of a flow (following packets treated same)

6. 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)

7. 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”)

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

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

10. CSci8211: SDN Controller Design 10 Onix Case Study 1 st 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

11. 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

12. CSci8211: SDN Controller Design 12 Typed Entity Examples

13. CSci8211: SDN Controller Design 13 Onix NIB API

14. 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

15. 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