Upload
others
View
10
Download
0
Embed Size (px)
Citation preview
Software Defined Networking (SDN)
T-110.5111 Computer Networks II
Hannu Flinck
What is Software Defined Network (SDN)?
The aim of SDN is to provide open interfaces that enable the development of software that can control the connectivity provided by a set of network resources and the flow of network traffic though them.
Basic characteristics:
– Decoupling of control and data planes – Logically centralized control – New abstraction for networking – Exposure of abstract network resources and their state to
external applications – Interface between controller and the data plane defined by
OpenFlow protociol. Pairs with Open vSwitch (OVS) that provides data plane to be controlled by SDN
What is the problem SDN is solving?
• Server virtualization has led to dynamic workloads: – Server consolidation through virtualization=> VM migration =>
dynamic workloads => networking challenges
• Traffic patterns in the (enterprise and data centers) networks changing dynamically
• New challenges: – scalability (1000s of VMs), isolation of tenants, short SW life cycles
• Networks are hard to manage – heavily depend on manually intensive management systems, prone to
misconfiguration and errors, troubleshooting being lengthy and tiresome
– provisioning a service/virtual server is of oder of 60 min, provisioning connectivity for the service is days or weeks
• Networks are hard to evolve (compared to other SW systems)
Server Virtualization brought the Virtual Switches
Virtual switch: A virtual switch is a software program that allows one virtual machine (VM) to communicate with another. Some vendors embed them into their virtualization software, and others include virtual switches in a server's hardware as part of its firmware. We will look into Open Virtual Switch (OVS) as one practical example that supports SDN.
Server Virtualization brought the Virtual Switches (cont.)
• Old ways to configure a network
Limitations of Current Networks
Specialized Packet Forwarding Hardware
App App App
Specialized Packet Forwarding Hardware
App App App
Specialized Packet Forwarding Hardware
App App App
Specialized Packet Forwarding Hardware
App App App
Specialized Packet Forwarding Hardware
Operating System
Operating System
Operating System
Operating System
Operating System
App App App
Ref. OpenFlow/SDN tutorial, Srini Seetharaman, Deutsche Telekom, Silicon Valley Innovation Center
6
Limitations of Current Networks (cont.)
Million of lines of source code
Billions of gates
Many complex functions baked into infrastructure
OSPF, BGP, multicast, differentiated services, Traffic Engineering, NAT, firewalls, …
Specialized Packet Forwarding Hardware
Operating System
Feature Feature
Ref. OpenFlow/SDN tutorial, Srini Seetharaman, Deutsche Telekom, Silicon Valley Innovation Center
Cannot change dynamically to follow changing network conditions
Current Network Abstractions are not meeting the new needs
• Current network abstractions:
– no common abstractions for the control plan
– for routing: distributed algorithms that opeate on network graphs, RIB/FIB but they are vendor specific
– for isolation: Access Control Lists, VLANs, firewall rules
– for traffic engeering: adjusting weights, MPLS-TE etc..
• There is a need for new common abstractions for forwarding state and network topology state abstractions (e.g. information and data models, and API that operate on those models)
Forwarding Abstraction
Purpose: Abstract away forwarding hardware while still be able to express how and where to forward a packet
Flexible
– Forwarding behavior specified by control plane – Built from basic set of forwarding primitives
Minimal – Streamlined for speed and low-power – Open and not vendor-specific
OpenFlow is an example of such an abstraction
Ref. Software Defined Networking (COMS 6998-8)
9 Source: Nick Mckeown, Stanford
Application
Network OS/SDN Controllers
1. South Bound API: Open interface to packet forwarding
3. North Bound API: Consistent, up-to-date global network view
2. At least one Network OS probably many.
Open- and closed-source
The big picture of SDN
Packet Forwarding
Packet Forwarding
Packet Forwarding
Packet Forwarding
Packet Forwarding
Based on Ref. Software Defined Networking (COMS 6998-8)
10
Application
Network OS Network OS: distributed system of controllers that creates a consistent, up-
to-date network wide(logically centralized) view for its applications
– SDN controllers run on commodity x86-servers • Floodlight, ODL, POX, Pyretic, Nettle ONIX, Beacon, … + more
• Uses forwarding abstraction at the South Bound Interface: – Get state information from forwarding elements – Give control directives to forwarding elements – Typically Open Flow used to provide commands and get state information
• Offers a Noth Bound Interface to applications: – Example applications: MAC learning switch, Routing daemon, FW etc – No standard NBI API, typically REST…
– All modules in Java – New modules can be added as need – Main module is FloodlightProvider
• Manages I/O to switches • Multi-threaded via Netty library (all modules
must be thread-safe)
– REST API as North Bound API to SDN
applications – Controller translates application level
requests into OpenFlow messages – Selects the path for a flow – http://floodlight.openflowhub.org
Example of a SDN controller: Floodlight Fl
oo
dlig
htP
rovi
der
DeviceManager
TopologyManager
RestServer
StorageSource
Forwarding
StaticFlowPusher
LinkDiscovery
Based on material from Big Switch Inc
OpenFlow is the dominant SDN protocol at the moment
https://www.opennetworking.org/ Developes OpenFlow protocol specfications
Short introduction to OpenFlow
Introduction to OpenFlow
• OpenFlow enables SDN controllers to determine the path of network packets through the network of switches
• OpenFlow is a protocol and API, not a product – Standardized interface between control and forwarding plane(s)
• OpenFlow is used to populate forwarding tables of switches
– Flow entries programmed through OF
– Switch performs lookups in flow table
– Switch needs to be OpenFlow enabled
Alternatives to OpenFlow
• OpenFlow originated SDN but now also other “southbound protocols” and tools are being discussed and implemented by the industry:
– XMPP, Netconf, ForCES, PCE, etc.
• How do they compare against OpenFlow?
– OpenFlow is a very-low level abstraction/API (L2 , L3, and a bit of L4)
– Could probably implement XMP, ForCES, PCE, etc. using OpenFlow
– Could not implement OpenFlow using XMP, ForCES, PCE, etc
– Reduced complexity from feature interaction
OpenFlow is between SDN controller and switch(es)
16
Data Path (Hardware)
Control Path OpenFlow
Controller OpenFlow Protocol (SSL/TCP)
OpenFlow/SDN tutorial, Srini Seetharaman, Deutsche Telekom, Silicon Valley Innovation Center
North Bound API
OpenFlow Switch & Flow Tables
SDN controller
Secure channel Group Table
Flow Table
Flow Table
Flow Table
South Bound: OpenFlow
Pipeline
OpenFlow Switch, e.g. OVS
Match Fields Counters Instructions
Flow Table
Match field: a field against which a packet is matched Counters: to update for matching packets Instructions: to modify the action set or pipeline processing
North Bound API
Packet flow through pipeline
Source: OpenFlow Switch Specification, Version 1.1.0 Implemented ( Wire Protocol 0x02 )
Pipeline processing
Any matches
Go through tbl N
Drop packet
Update counters, update
action set, update
metadata
Execute Action Set
Packet received Set tbl 0
Go tbl N+1
Table miss entry
Y
Y
No No
No
Y
Actions
• Forward to Port (Physical or Virtual): – All: to all interfaces except incoming interface – Controller: encapsulate and send to controller – Local: send to its local networking stack – Table: Perform actions in the flow table – In_port: Send back to input port – Normal: Forward using traditional Ethernet – Flood: Send along minimum spanning tree except the incoming
interface
• Enqueue: To a particular queue in the port QoS • Drop • Modify Field: e.g., add/remove VLAN tags, ToS bits, Change
TTL
Source: http://www.cse.wustl.edu/~jain/cse570-13/
• “Field” is defined to match specific protocol field: eth_dst, eth_src, vlan_pcp, Ipv4_src, tcp_src, udp_src etc.
• Actions are applied to matching packets
OpenFlow 1.2: Extensible Match Structure
OpenFlow Extensible Match (OXM) is a structure that matches a particular protocol field. A complicated match rule is defined as a sequence of OXMs, which all must match. OXM's are segregated by class, and then field. For OP1.2 there is only one class: OpenFlowBasic. Fields are defined to handle very specific protocol matching: eth_dst, eth_src, vlan_pcp, Ipv4_src, tcp_src, udp_src etc.
OpenFlow Examples
22
Switching
*
Switch Port
MAC src
MAC dst
Eth type
VLAN ID
IP Src
IP Dst
IP Prot
TCP sport
TCP dport
Action
* 00:1f:.. * * * * * * * port6
Firewall
*
Switch Port
MAC src
MAC dst
Eth type
VLAN ID
IP Src
IP Dst
IP Prot
TCP sport
TCP dport
Action
* * * * * * * * 22 drop
OpenFlow/SDN tutorial, Srini Seetharaman, Deutsche Telekom, Silicon Valley Innovation Center
Routing
*
Switch Port
MAC src
MAC dst
Eth type
VLAN ID
IP Src
IP Dst
IP Prot
TCP sport
TCP dport
Action
* * * * * 5.6.7.8 * * * port6
Reactive vs. Proactive modes
Reactive mode
• Packet with no matching flow entry is sent to the controller
• Controller insert matching flows to the switch
• Efficient use of flow table
• Every new flow adds load to the controller
• If the connection between the controller and switch is lost, switch fails to serve new flows
Proactive (pre-populated mode)
• Controller pre-polulates flow tables
• Zero additional flow setup time
• Loss of control connection doesn’t disrupt traffic
• Benefits from wildcard (aggregated) rules
Selected Use cases
1. Network Virtualization – Isolation 2. Virtual Machine Management and Migration 3. Network Function Chaining
Use Case: Network Virtualization - Isolation
FlowVisor
Alice Bob Cathy
Isolation Policy
• Scalable isolation domains and network slicing.
Ref. Fllodlight tutorial by Big Switch’s
Use case: Virtual Machine Management and Migration
Ref. Fllodlight tutorial by Big Switch’s
• Flexible migration of virtual machines
Use Case: Network Function Chaining
Network Policy: Firewall IDS Web
WEB
Firewall IDS
SDN Controller
Applications Applications Applications
Source: CPS 590: Software Defined Networking, Theophilus Benson
How is SDN shaping Industry? • Open Networking Foundation (ONF)
– New non-profit standards organization (Mar 2011)
– Defining standards for SDN, starting with OpenFlow
– 39 Member Companies • Cisco, VMware, IBM, Juniper, HP, Broadcom, Citrix, NTT, Intel, Ericsson,
Dell, Huawei, …
• OpenDaylight (ODL)
– Led by IBM and Cisco
– Mission is to develop open source SDN platform
– Provides ODL SDN controller among others
Ref. Software Defined Networking (COMS 6998-8)
28
What about SDNv2?
• Will target carrier networks (that have a lot of lecagy)
• Will take better into account Layers 4-7, virtual switching and network function virtualization
Tenets of SDNv2
1. Software goes to the edge; the core stays dumb. 2. “Middleboxes” get included in SDN; layer 4 -7
appliances 3. The network is opened up to third-party services. 4. Closed interfaces are not allowed.
https://www.sdncentral.com/news/scott-shenker-preaches-revised-sdn-sdnv2/2014/10/
Conclusion
• Software Defined Networking addressess the challenges stemming from server and network virtualization
• Defines new forwarding abstratctions • Encompasses: controller-OpenFlow-switch • SDN controller has two APIs: North Bound and Shouth
Bound (OpenFlow) • OpenFlow is the dominant SDN protocol at the
moment, but not the only one • Use cases start from enterprise and data centers but
extend to wide area networks
About the assigment
• Topic: Data center network with software-defined network
• Use of Mininet to set up the network, useful youtube video about how to set mininet topologies:
– http://www.youtube.com/watch?v=yHUNeyaQKWY
– Add hosts and switches: leftHost = self.addHost( 'h1' ), leftSwitch = self.addSwitch( 's11' )
– Add links self.addLink( leftHost, leftSwitch )
• Attach a controller (there is its own ref. controller with Mininet install, but POX maybe better)
• Create an application that uses the controller: a forwarding algorithm