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

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

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

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

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

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

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

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

Example II: Simple Scan Detection CSci8211: SDN Controller Design

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

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

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

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

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

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