Date post: | 18-Jan-2018 |
Category: |
Documents |
Upload: | brendan-chandler |
View: | 246 times |
Download: | 0 times |
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