SDN Recap

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

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

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

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

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

6. 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”) Programmatic Interface CSci8211: SDN Controller Design

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

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

9. Onix Case Study • Design Goals • Generality • Scalability • Reliability • Simplicity • Control plane performance 1st commercial network OS implemented by Nicira (now part ofVMWare) • Components: • managed physical infrastructure • connectivity infrastructure • Onix • Control logic implemented by management applications CSci8211: SDN Controller Design

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

11. Typed Entity Examples CSci8211: SDN Controller Design

12. Onix NIB API CSci8211: SDN Controller Design

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

14. Distributing the NIB • Two guiding observations in design of state distribution mechanisms: • Applications have differing requirements on scalability, frequency of updates on shared state, 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

15. Onix: Connectivity Infrastructure

16. Handling Failures in Connectivity Infrastructure? • Two types of failures: i) between Onix instances and network elements; ii) between Onix instances • Two deployment settings: i) out-of-band: i.e., dedicated mngnt network; ii) in-band: shared the same data plane

17. Handling Failures in Connectivity Infrastructure? • Two types of failures: i) between Onix instances and network elements; ii) between Onix instances • Two deployment settings: i) out-of-band: i.e., dedicated mngnt network; ii) in-band: shared the same data plane