Software Defined Networking What is it, how does it work, and what is it good for? Many slides stolen from Jennifer Rexford, Nick McKeown, Scott Shenker, Teemu Koponen, Yotam Harchol and David Hay
Agenda What is Software Defined Networking (SDN)? What is OpenFlow? How does it work? Challenges en route to SDN Research directions
What is SDN?
The Internet: A Remarkable Story Tremendous success from research experiment to global infrastructure Enables innovation in applications Web, P2P, VoIP, social networks, virtual worlds But, the Internet s infrastructure remained fairly stagnant for decades
The Internet s Landscape constant innovation Applications: stagnant! Internet Protocols: routing, congestion control, naming, (TCP/IP, BGP, DNS, OSPF, ECMP, ) Technologies: constant innovation
Why Can t We Innovate? 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 Impacts performance, security, reliability, cost
Networks are Hard 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
Traditional Computer Networks Data plane: packet streaming forward, filter, buffer, mark, rate-limit, and measure packets
Traditional Computer Networks Control plane: distributed algorithms track topology changes, compute routes, install forwarding rules
Traditional Computer Networks Management plane: human time scale collect measurements and configure the equipment
New Paradigm: Software Defined Networking (SDN) logically-centralized control smart, slow API to the data plane (e.g., OpenFlow) switches dumb, fast
A Helpful Analogy 12
Mainframes App App App App App App App App App App App Specialized Applications Specialized Operating System Specialized Hardware Windows (OS) Open Interface or Linux or Open Interface Microprocessor Mac OS vertically integrated closed, proprietary slow innovation small industry horizontal open interfaces rapid innovation huge industry
Routers/Switches App App App App App App App App App App App Specialized Features Specialized Control Plane Specialized Hardware Control Plane Open Interface or Control Plane or Open Interface Merchant Switching Chips Control Plane vertically integrated closed, proprietary slow innovation horizontal open interfaces rapid innovation
15 How SDN works The OpenFlow protocol
OpenFlow Switching OpenFlow Switch specification OpenFlow Switch PC sw Secure Channel Controller hw Flow Table
Controller: Programmability Controller Application Network OS events from switches topology changes, traffic statistics, arriving packets commands to switches (un)install rules, query statistics, send packets 17
Reactive vs. Proactive Reactive SDN: switches send (first) packets to controller, then controller programs switch's flow table to handle rest of the flow Problem: source of DoS on controller (packet-in event) Proactive SDN: Controller programs the switches proactively, according to its own knowledge of the network Requires smarter approaches than just reacting to network events (global knowledge, discovery, updates )
Flow Table Entry at Switch Type 0 OpenFlow Switch Rule Action Stats Packet + byte counters 1. Forward packet to port(s) 2. Encapsulate and forward to controller 3. Drop packet 4. Send to normal processing pipeline Switch Port MAC src MAC dst Eth type VLAN ID IP Src IP Dst IP Prot TCP sport TCP dport + mask
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 1. src=1.2.*.*, dest=3.4.5.* drop 2. src = *.*.*.*, dest=3.4.*.* forward(2) 3. src=10.1.2.3, dest=*.*.*.* send to controller
OpenFlow Definition in progress Additional actions rewrite headers map to queue/class encrypt More flexible header allow arbitrary matching of first few bytes Support multiple controllers load-balancing and reliability
Example OpenFlow Applications Dynamic access control Seamless mobility/migration Server load balancing Network virtualization Using multiple wireless access points Energy-efficient networking Adaptive traffic monitoring Denial-of-Service attack detection See http://www.openflow.org/videos/
E.g.: Dynamic Access Control Inspect first packet of a connection Consult the access control policy Install rules to block or route traffic
E.g.: Seamless Mobility/Migration See host send traffic at new location Modify rules to reroute the traffic
E.g.: Server Load Balancing Pre-install load-balancing policy Split traffic based on source IP src=0* src=1* 25
In-depth Example: Simple Repeater Controller 1 2 Switch Simple Network Repeater 26 forward packets received on port 1 out 2 and vice versa
Controller (POX) (Pseudo)-Program Simple Repeater def handle_packetin(packet): out_port = 2 if packet.in_port == 2: out_port = 1 flow_mod = ofp_flow_mod() flow_mod.match = ofp_match() flow_mod.match.in_port = \ packet.in_port action = ofp_action_output() action.out_port = out_port flow_mod.action = [ action ] flow_mod.buffer_id = \ packet.buffer_id send(flow_mod) Controller 1 2 Switch Flow Table Priority Pattern Action Counters DEFAULT IN_PORT:1 OUTPUT:2 (0,0) DEFAULT IN_PORT:2 OUTPUT:1 (0,0) 27
OpenFlow in the Wild Open Networking Foundation 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, POX, Network deployments Campuses, research backbone networks Commercial deployments (e.g., Google backbone)
But Heterogeneous Switches Number of packet-handling rules (TCAM/memory limits) Different OpenFlow version support Range of matches and actions (not all matches and actions are mandatory in the protocol) Multi-stage pipeline of packet processing (allowed but not defined in the standard) Vendor-specific features Offload some control-plane functionality (?) access control MAC look-up IP look-up 29
SDN or OpenFlow? OpenFlow is not being adapted as-is Major vendors either completely discard OpenFlow or use a massively changed variant Doing that requires having the ability to change the protocol on both sides (controller + switch) Is OpenFlow dead? 30
Challenges 31
Controller Delay and Overhead Controller is much slower the the switch Processing packets leads to delay and overhead Need to keep most packets in the fast path packets 32
Distributed Controller Controller Application For scalability and reliability Controller Application Network OS Partition and replicate state Network OS and: where to put the controller(s)? Taking into account latency, resiliency, load balancing... 33
Testing and Debugging OpenFlow makes programming possible Network-wide view at controller Direct control over data plane Plenty of room for bugs Still a complex, distributed system Need for testing techniques 34 Controller applications Controller and switches Rules installed in the switches
Programming Abstractions Controller APIs are low-level Thin veneer on the underlying hardware Need better languages Composition of modules Managing concurrency Querying network state Network-wide abstractions Controller Example: http://www.frenetic-lang.org/ Switches 35
MiniNet 36
MiniNet Creates scalable SDN (up to hundreds of nodes) using OpenFlow, on a single PC Allows to quickly create, interact with and customize a SDN prototype with complex topologies, and can be used to emulate real networks all on your PC Can work with any kind of OpenFlow controller Takes seconds to install Easy to program Of course, is an open source project 37
MiniNet Not only for teaching purposes! Used for the development and testing of networks 38
Innovating with SDN
Dealing with Large Tables Palette: Distributing Tables in Software Defined Networks Y. Kanizo, D. Hay and I. Keslassy
Access Control in SDN Consider the following network. Table at each ingress point Ingress points hold (too) large tables 41
How to Solve this Problem? Idea: Distribute the rules among all switches such that each packet goes through all rules along its path. 42
Palette: Step I Split the large (TCAM) table into smaller tables identify each smaller table with a unique colour 43
Palette: Step II Assign at most a single colour to each switch s.t. every packet-forwarding path is a rainbow path
Algorithmic Challenges Maximizing the number of colours (smaller tables), k Splitting the large (TCAM) table into k smaller tables so as to minimize the size of the largest table http://webee.technion.ac.il/~isaac/p/tr12-05_palette.pdf
Rethinking (Routing) Protocols On the Resilience of Routing Tables: J. Feigenbaum, P. B. Godfrey, A. Panda, M. Schapira, S. Shenker, and A. Singla
Motivation d
Motivation d Routes computed by, say, shortest paths routing alg
Motivation Packet i X d forwarding path? No!
Routing: Data vs. Control Plane Routing is a control plane operation slow (ms s) Packet forwarding is a data plane operation fast (μs) Today s routing protocols 1. establish connectivity 2. optimize routes (= shortest paths) failure re-convergence dropped packets!
How to Solve this Problem? Idea: Push (only!) connectivity to the data plane immediately react to failures optimize routes on a longer time scale 51
Forwarding Model Packet for node d arrives at node i Outgoing edge is a function of - incoming edge - set of live edges d i f id : E i x P(E i ) -> E i
Resilient Forwarding Forwarding is t-resilient iff for any (at most) t edge failures: existence of path from i to d loopfree forwarding from to d Perfect resilience t
Thm: Can always protect against one failure Big Gap! Thm: Cannot always provide perfect resilience
What Next? Conditions for k-resilience? restricted failure models? Resilience for specific families of graphs? Randomized forwarding rules?...? Full paper available online as YALE/DCS/TR1454 See also [Liu-Panda-Singla-Godfrey-S-Shenker, NSDI 2013]
Conclusion SDN is revolutionizing networking Rethinking networking open interfaces to the data plane separation of control and data leveraging techniques from distributed systems Significant momentum, many challenges 56 in both research and industry
Thank You