Enabling Innovation Inside the Network Jennifer Rexford Princeton University
The Internet: A Remarkable Story Tremendous success –From research experiment to global infrastructure Brilliance of under-specifying –Network: best-effort packet delivery –Hosts: arbitrary applications Enables innovation in applications –Web, P2P, VoIP, social networks, virtual worlds But, change is easy only at the edge… 2
Inside the ‘Net: A Different Story… Closed equipment –Software bundled with hardware –Vendor-specific interfaces Over specified –Slow protocol standardization Few people can innovate –Equipment vendors write the code –Long delays to introduce new features 3 Impacts performance, security, reliability, cost…
How Hard are Networks to Manage? Operating a network is expensive –More than half the cost of a network –Yet, operator error causes most outages Buggy software in the equipment –Routers with 20+ million lines of code –Cascading failures, vulnerabilities, etc. The network is “in the way” –Especially a problem in data centers –… and home networks 4
Creating Foundation for Networking A domain, not a discipline –Alphabet soup of protocols –Header formats, bit twiddling –Preoccupation with artifacts From practice, to principles –Intellectual foundation for networking –Identify the key abstractions –… and support them efficiently To build networks worthy of society’s trust 5
Rethinking the “Division of Labor” 6
Traditional Computer Networks 7 Data plane: Packet streaming Forward, filter, buffer, mark, rate-limit, and measure packets
Traditional Computer Networks 8 Track topology changes, compute routes, install forwarding rules Control plane: Distributed algorithms
Traditional Computer Networks 9 Collect measurements and configure the equipment Management plane: Human time scale
Shortest-Path Routing Management: set the link weights Control: compute shortest paths Data: forward packets to next hop
Shortest-Path Routing Management: set the link weights Control: compute shortest paths Data: forward packets to next hop
Inverting the Control Plane Traffic engineering –Change link weights –… to induce the paths –… that alleviate congestion
Avoiding Transient Anomalies Distributed protocol –Temporary disagreement among the nodes –… leaves packets stuck in loops –Even though the change was planned! 13 1
Death to the Control Plane! Simpler management –No need to “invert” control-plane operations Faster pace of innovation –Less dependence on vendors and standards Easier interoperability –Compatibility only in “wire” protocols Simpler, cheaper equipment –Minimal software 14
Software Defined Networking (SDN) 15 API to the data plane (e.g., OpenFlow) Logically-centralized control Switches Smart, slow Dumb, fast
OpenFlow Networks 16
Data-Plane: Simple Packet Handling Simple packet-handling rules –Pattern: match packet header bits –Actions: drop, forward, modify, send to controller –Priority: disambiguate overlapping patterns –Counters: #bytes and #packets 17 1.src=1.2.*.*, dest=3.4.5.* drop 2.src = *.*.*.*, dest=3.4.*.* forward(2) 3. src= , dest=*.*.*.* send to controller 1.src=1.2.*.*, dest=3.4.5.* drop 2.src = *.*.*.*, dest=3.4.*.* forward(2) 3. src= , dest=*.*.*.* send to controller
Controller: Programmability 18 Network OS App #1App #2App #3 Events from switches Topology changes, Traffic statistics, Arriving packets Commands to switches (Un)install rules, Query statistics, Send packets
Dynamic Access Control Inspect first packet of each connection Consult the access control policy Install rules to block or route traffic 19
Seamless Mobility/Migration See host sending traffic at new location Modify rules to reroute the traffic 20
E.g.: Server Load Balancing Pre-install load-balancing policy Split traffic based on source IP src=0* src=1*
Example Applications Dynamic access control Seamless mobility/migration Server load balancing Using multiple wireless access points Energy-efficient networking Adaptive traffic monitoring Denial-of-Service attack detection Network virtualization 22 See
OpenFlow in the Wild Open Networking Foundation –Creating Software Defined Networking standards –Google, Facebook, Microsoft, Yahoo, Verizon, Deutsche Telekom, and many other companies Commercial OpenFlow switches –HP, NEC, Quanta, Dell, IBM, Juniper, … Network operating systems –NOX, Beacon, Floodlight, Nettle, ONIX, POX, Frenetic Network deployments –Eight campuses, and two research backbone networks –Commercial deployments (e.g., Google backbone) 23
Algorithmic Challenges in Software Defined Networking 24
Two-Tiered Computational Model 25 Smart, slow Dumb, fast What problems can we solve efficiently in this two-tiered model?
Example: Hierarchical Heavy Hitters Measure large traffic aggregates –Understand network usage –Detect unusual activity Fixed aggregation level –Top 10 source IP addresses? –Top 10 groups of 256 IP addresses? Better: –Identify the top IP prefixes, of any size –Contributing a fraction T of the traffic 26
** 000* *010*011* 01** 40 0*** 0 1*** 40 **** HH: sends more than T= 10% of link cap Heavy Hitters (HH) All IP prefixes Contributing >= T of capacity
** 000* *010*011* 01** 40 0*** 0 1*** 40 **** HH: HHH: Hierarchical Heavy Hitters (HHH) All IP prefixes Contributing >= T of capacity … excluding descendents 28
Computational Model Previous work: custom hardware –Streaming algorithms using sketches –Fast and accurate, but not commodity hardware Our model: simplified OpenFlow –Slow, smart controller Read traffic counters Adapt rules installed in the switch –Fast, dumb switch Ternary match on packet headers Traffic counters What algorithm should the controller run? 29 ? rulescounters
Monitoring HHHes ** 000* *010*011* 01** 40 0*** 0 1*** 40 **** PriorityPrefix RuleCount *12 3 0***17
** 000* *010*011* 01** 40 0*** 0 1*** 40 **** Detecting New HHHs Monitor children of HHH Using at most 2/T rules 31
Iteratively Adjust Wildcard Rules Expand: if count > T, install rule for children Collapse: if count < T, remove rule ** 000* *010*011* 01** 80 0*** PriorityPrefix RuleCount 1 0***80 2 ****0
Iteratively Adjust Wildcard Rules ** 000* *010*011* 01** 80 0*** PriorityPrefix RuleCount 1 00** **3 3 ****0 Expand: if count > T, install rule for children Collapse: if count < T, remove rule
Iteratively Adjust Wildcard Rules ** 000* * 011* 01** 80 0*** Expand: if count > T, install rule for children Collapse: if count < T, remove rule PriorityPrefix RuleCount 1 000* *7 3 ****3
Using Leftover Rules Monitoring children of all HHHs –Threshold fraction T of traffic (e.g., T=0.1) –At most 2/T rules (e.g., 20 rules) Often need much less –Some HHH are very large –So, may have fewer than 1/T HHHs Using the extra rules –Monitor nodes close to the threshold –Most likely to become new HHHs soon! 35
Experimental Results CAIDA packet traces –Trace of 400,000 IP packets/second –Measuring HHHes for T=0.05 and T=0.10 –Time intervals of 1 to 60 seconds Accuracy –Detect and measure ~9 out of 10 HHHes –Large traffic aggregates are stable Speed –Take a few intervals to find new HHHs –Meanwhile, report coarse-grain results *
Stepping Back Other monitoring problems –Multi-dimensional HHH –Detecting large changes –Denial-of-Service attack detection Changing the computational model –Efficient, generic support for traffic monitoring –Good for many problems, rather than perfect for one Other kinds of problems –Flexible server load balancing –Latency-equalized routing –… 37
Making SDN Work Better Distributed controllers –Improve scalability, reliability, performance –Need: efficient distributed algorithms Distributed policies –Spread rules over multiple switches –Need: policy transformation algorithms Verifying network properties –Test whether the rules satisfy invariants –Need: efficient verification algorithms Many more interesting problems! 38
Conclusion SDN is exciting –Enables innovation –Simplifies management –Rethinks networking SDN is happening –Practice: useful APIs and good industry traction –Principles: start of higher-level abstractions Great research opportunity –Practical impact on future networks –Placing networking on a strong foundation 39