Software Defined Networking & Openflow -...
Transcript of Software Defined Networking & Openflow -...
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
01.10.15 SDN & Openflow
Scope of Software Defined Nets
01.10.15 SDN & Openflow
Taking a step back (in time)
Active & Programmable Networks
ConfigureDataPathOO-band
ModifyControl
PlaneLogic
ProgrammableSwitch
AugmentData Path
Logic
........
OpenFlow
SDN(..or this is what we assume)
Control, Mgmt & Data Planes
• Every network device today typically have 3 “planes” of operation
01.10.15 SDN & Openflow
Data (Forwarding) plane
01.10.15 SDN & Openflow
Forwarding tables (FIB) = lookup tables for next hop selectionImplemented in hardware
Forwarding plane directs the flow of traffic
How routing translates to forwarding
01.10.15 SDN & Openflow
Information in RIBs obtained through distributed processes aka Routing protocol
Routing path information (RIB) used to compute the best next-hop to each destination àFIB
RIB at the control planeFIB at the forwarding plane
01.10.15 SDN & Openflow
Routing protocols in Internet todayPros and Cons
01.10.15 SDN & Openflow
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
01.10.15 SDN & Openflow
• Seems like going a bit back in time ?• From distributed back to centralised
• Well ...sometimes trading one thing enables another• Simplicity for programmability!
01.10.15 SDN & Openflow
Nevertheless, still distributed but at a different dimension
Con
trolle
rD
evic
e
Centralised
Distributed
01.10.15 SDN & Openflow
SDN Device architecture
Architectural components of a conventional net device today
... possibilities in the future
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
01.10.15 SDN & Openflow
01.10.15 SDN & Openflow
Openflow Switches
• Controller: • Contains defined rules• Install flows
• L3-Switch: • Requests actions• Applies flows (high speed)
Openflow tables
01.10.15 SDN & Openflow
01.10.15 SDN & Openflow
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 TablesLongest prefix match
01.10.15 SDN & Openflow
Flow Tables examples
01.10.15 SDN & Openflow
Flow Tables examples
Stateful packet inspection (firewall)
01.10.15 SDN & Openflow
01.10.15 SDN & Openflow
Flow Tables examples
Multipath/Policy routing
Load Balancing
01.10.15 SDN & Openflow
Pipeline processing
01.10.15 SDN & Openflow
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
01.10.15 SDN & Openflow
So what about the controller end?
ControllerUpdates the flow table rules on the devices
OpenFlow Controller
01.10.15 SDN & Openflow
• It’sallsoftware!..running onageneralpurposePC/OS
• Needstobedirectlyconnectedtoallcontrolleddevices(speakstheOpenFlowprotocol)
• Readforwardingstate• Receiveunclassified traffic• Updateforwardingstate
• Maintainsatopologymodel inmemory
• Computesrouting paths,spanning trees,etc,usingsimplercentralisedalgorithms
• Exportsaninterface/APItotheuser
Controller Architectures
• Centralised (w/ back up redundancy)
01.10.15 SDN & Openflow
Controller Architectures
01.10.15 SDN & Openflow
Distributed J !!..seems like we re going back to where we started ?
01.10.15 SDN & Openflow
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 ?
01.10.15 SDN & Openflow
The big picture in SDN
01.10.15 SDN & Openflow
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)
01.10.15 SDN & Openflow
Openflow in Cloud based Networks (NaaS)
01.10.15 SDN & Openflow
Current Openflow scene (2012):Resources and success stories
Openflow switches– IBMG8264– HPProcurve 5400zlseries,6600series– NECUniverge PF5240(bestproductsofar!)– CiscoONEarchitecture andonePK– Pica8– LinuxOpenvSwitch (bestproductsofar!)Openflow controller– NOX:C++/PythoncontrolleropensourcedbyNicira Networks– Beacon:AJavacontrollerbuiltbyStanford– Maestro:AJavacontrollerbuiltatRiceuniversity– BigSwitch NetworksOpenFlow inaction– GoogleG-scale– Facebook– AmazonCloud– E-bay– Yahoo– Indianauniversity(Openflow campus)
01.10.15 SDN & Openflow
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”
01.10.15 SDN & Openflow
01.10.15 SDN & Openflow
SDN programmability so far (2013)
OpenFlow 1.4
Flow
Classification
Traffic
Cond
ition
ing
Activ
eQue
ueMan
agem
ent
Sche
dulin
g
Components of a typical Differentiated services capable router/switch
Programming SDN Dynamics - 33M. Sifalakis
Thank youfor your attention.