From Active & Programmable Networks to.. OpenFlow & Software Defined Networks. Prof. C. Tschudin, M. Sifalakis, T. Meyer, M. Monti, S.

Transcription

1 From Active & Programmable Networks to.. OpenFlow & Software Defined Networks Prof. C. Tschudin, M. Sifalakis, T. Meyer, M. Monti, S. Braun University of Basel Cs321 - HS 2012 (Slides material from Overview Brief summary on routing and forwarding Introduction to Openflow notions and ideas Device architecture Flow Based forwarding Examples Controller architecture Software Defined Networking 1

2 Control, Mgmt & Data Planes Every network device today typically have 3 planes of operation Data (Forwarding) plane Forwarding plane (often instantiated in hardware) directs the flow of traffic Forwarding tables (FIB) = lookup tables for next hop selection 2

3 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 protocols RIB at the control plane FIB at the forwarding plane 3

4 Routing protocols 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 Problems hard to detect, sometimes even harder to remediate Most distributed algorithms are more complex to implement and 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! 4

5 Controller Device 10/30/2012 Nevertheless, still distributed but at a different dimension Centralised Distributed Device architecture... possibilities in the future Architectural components of a conventional net device today 5

6 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 Switching & Flow forwarding At first... Not much difference seems to manifest compared to a L2 switch A closer look reveals a seemingly more simple process 6

7 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... Actions DO action CLEAR state ADD new state INCLUDE metadata 7

8 Flow Tables Longest prefix match Flow Tables examples L2 learning switch L3 switch 8

9 Flow Tables examples Stateful packet inspection (firewall) Flow Tables examples Multipath/Policy routing Load Balancing 9

10 Pipeline processing Maybe you can identify some similarity or correspondence between the two? RB Functional composition framework in ANA 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 10

11 So what about the controller end? Controller Updates the flow table rules on the devices Software Defined Networking (SDN) It s just 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 network topology model in memory Computes routing paths, spanning trees, etc, using simpler centralised algorithms Exports an interface/api to the user 11

12 Controller Architectures Centralised (w/ back up redundancy) Distributed Controller Architectures..seems like we re going back to where we started? 12

13 Controller Architectures Layered Hierarchies (w/ hypervisors)..does it start smelling like a distributed component based architecture? Controller frameworks Controllers w/ app plugins!..with support for runtime functional composition? 13

14 The big picture The big players Cloud providers 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,... Network as a service (NaaS) 14

15 Current Openflow scene: 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 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 15

16 Questions 16