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