Software Defined Networking & Openflow Autonomic Computer Systems, HS 2015 Christopher Scherb, 01.10.2015
Overview What is Software Defined Networks? Brief summary on routing and forwarding Introduction to SDN/OpenFlow notions and ideas SDN Device architecture Flow Based forwarding Examples SDN Controller architecture The game in Software Defined Networking SDN prospective and critique
Scope of Software Defined Nets Taking a step back (in time) Active & Programmable Networks...... Configure Data Path OO-band Augment Data Path Logic Modify Control Plane Logic Programmable Switch OpenFlow SDN (..or this is what we assume)
Control, Mgmt & Data Planes Every network device today typically have 3 planes of operation
Data (Forwarding) plane Forwarding plane directs the flow of traffic Forwarding tables (FIB) = lookup tables for next hop selection Implemented in hardware
How routing translates to forwarding Routing path information (RIB) used to compute the best next-hop to each destination àfib Information in RIBs obtained through distributed processes aka Routing protocol
RIB at the control plane FIB at the forwarding plane
Routing protocols in Internet today Pros and Cons Pros Distributed and Scalable Heterogeneous systems need no common APIs Loose coupling of devices Adaptive metrics Distributed consistency Reliability and Fault tolerance Cons Poor multipath support Often too long convergence times (esp. BGP) Problems hard to track, sometimes even harder to remediate Most distributed algorithms are more complex to implement than their centralised counterparts
A possible alternative to routing protocols Seems like going a bit back in time? From distributed back to centralised Well...sometimes trading one thing enables another Simplicity for programmability!
Nevertheless, still distributed but at a different dimension Controller Centralised Device Distributed
SDN Device architecture... possibilities in the future Architectural components of a conventional net device today
A router or a switch? If we remove the control plane routing protocols from a router.. is it still a router, or a switch? forwarding based on MAC addr = L2 switch forwarding based on IP addr (L3 ID) + Routing protocols = Router Router routing?= L3 switch Forwarding by arbitrary flow rule? Lets call it... OpenFlow switch
Openflow Switches Controller: Contains defined rules Install flows L3-Switch: Requests actions Applies flows (high speed)
Openflow tables
Match-Actions Fields Match Fields Ingress interface Ether src/dst/type VLAN id/priority MPLS label/class IP src/dst/proto/tos ARP code TCP/UDP/SCTP port ICMP type... Instructions and Actions APPLY action CLEAR action ADD new action INCLUDE metadata
Flow Tables Longest prefix match
Flow Tables examples
Flow Tables examples Stateful packet inspection (firewall)
Flow Tables examples Multipath/Policy routing Load Balancing
Pipeline processing
Flow rules generation Proactivelly Controller/admin generates flow tables for a whole routing domain Fast (no delays for flow authorisation) Less flexible Largely based on aggregate flow entries Reactivelly (Learning) First packet of flow triggers installation of flow rules (also setting up the reverse path) More flexible Controller availability is an issue
So what about the controller end? Controller Updates the flow table rules on the devices
OpenFlow Controller It s all software!.. running on a general purpose PC/OS Needs to be directly connected to all controlled devices (speaks the OpenFlow protocol) Read forwarding state Receive unclassified traffic Update forwarding state Maintains a topology model in memory Computes routing paths, spanning trees, etc, using simpler centralised algorithms Exports an interface/api to the user
Controller Architectures Centralised (w/ back up redundancy)
Controller Architectures Distributed J!!..seems like we re going back to where we started?
Controller Architectures Layered Hierarchies (w/ hypervisors)..does it start looking like a distributed middleware architecture?
Controller frameworks Controllers w/ app plugins!..with support for application level functional composition?
The big picture in SDN
The stakeholders Cloud providers: Network as a service (NaaS) In need of effective virtualisation and centralised management for data-centers Amazon, Google, Yahoo, Verizon,... Device manufacturing Providers of virtualisable hardware Cisco, Juniper, Ericson, Nokia, NEC,... Enterprise & ISP networks Intra-domain easy Inter-domain (still a challenge) Not easy for the Internet core (performance limitations)
Openflow in Cloud based Networks (NaaS)
Current Openflow scene (2012): Resources and success stories Openflow switches IBM G8264 HP Procurve 5400zl series, 6600 series NEC Univerge PF5240 (best product so far!) Cisco ONE architecture and onepk Pica8 Linux Open vswitch (best product so far!) Openflow controller NOX: C++/Python controller open sourced by Nicira Networks Beacon: A Java controller built by Stanford Maestro: A Java controller built at Rice university BigSwitch Networks OpenFlow in action Google G-scale Facebook Amazon Cloud E-bay Yahoo Indiana university (Openflow campus)
Critique on Openflow (2012) Mostly scalability, some views The number of flows a physical device can handle in hardware is limited, and the software-based devices are still too slow Hardware limitations on the number of flows that can be installed in a time period (usually less than thousand flows per second) Large-scale networks with distributed intelligence (control plane) perform inherently better than systems with centralized control It is impossible to recover from a node or link failure in 50 milliseconds (typical in networks handling voice traffic) when it takes longer to get a reply from the central controller
SDN programmability so far (2013) Components of a typical Differentiated services capable router/switch Flow Classification Traffic Conditioning Active Queue Management Scheduling M. Sifalakis OpenFlow 1.4 Programming SDN Dynamics - 33
Thank you for your attention.