Software-defined Networking (SDN)

(1)

Software-defined Networking (SDN)

A New Technology for

Flexible Communication Networks

GI/ACM Groups Stuttgart/Böblingen May 4, 2015

Stuttgart, Germany

Frank Dürr

Universität Stuttgart IPVS

(2)

GI/ACM Groups Stuttgart/Böblingen © Frank Dürr

Overview

1.

Motivation of Software-defined Networking

2.

Introduction to Software-Defined Networking (SDN)

3.

Selected SDN Research Topics

4.

Summary

(3)

The Internet Protocol Stack: A Success Story

The basic architecture remained the same for 30+ years.

Application Transport Network Data Link Physical Network Data Link Physical Network Data Link Physical Application Transport Network Data Link Physical HTTP TCP IP MAC 802.* fibre, copper, wireless

End system End system

Routers & multi-layer switches MAC 802.* fibre, copper, wireless UDP SMTP IMAP …

(4)

Constant Evolution in Networking

•

Basic network architecture stayed the same

•

However, there is a constant evolution going on

 New networked systems with new requirements appear constantly

(5)

Growing Number of Networking Scenarios (1)

•

Unicast, multicast, anycast, information-centric networking, …

◦

Different addressing and routing concepts

•

Heterogeneous Quality of Service (QoS)

◦

Real-time and low-latency applications

▪ Soft-real time requirements: Web search, shopping systems, social networks, instant messaging

▪ Strict real-time requirements: Networked control systems

◦

Delay-tolerant applications

▪ Backups, email, file transfer

◦

High throughput applications

(6)

Growing Number of Networking Scenarios (2)

•

Virtual networks (VLANs)

◦

Isolation of communication flows (e.g., in a cloud data center)

•

Connection of local networks via wide-area network

◦

VPNs tunneling of flows between networks

•

Mobility support

◦

Transparent forwarding of flows to mobile device

◦

Migration of virtual machines in or across data centers

•

And more …

(7)

Consequence: Constantly Increasing Number of

Network Protocols and Standards

(8)

Challenge and Problems

Challenge: Implement networking infrastructure supporting all of these functions, requirements, and protocols

Problems of today’s networking infrastructure:

•

Limited flexibility

•

Separation of network and application

(9)

Problem: Limited Flexibility (1)

•

Switches and routers are closed “black” boxes

•

Support standard protocols and proprietary protocols of manufacturer

•

No easy changes without support of manufacturer

(10)

Problem: Limited Flexibility (2)

And even if the switch/router hardware and software is open: Adding new network protocols and functions is hard

•

Have you ever written a Linux kernel module?

◦

Compare this to programming a user-space application

•

Have you ever used VERILOG?

◦

Compare this to C/C++, Java, Python, …

•

Have you ever targeted an embedded device?

◦

Compare this to writing code for a server

10

NetFPGA(http://netfpga.org/) WRT54L

(11)

Problem: Increasing Switch/Router Complexity

Switches and router implement large set of complex protocols

•

Even redundant protocols like multiple routing protocols

•

Even protocols that are not needed by the application / customer

•

Customer pays for hardware resources and functionality that he might not need

◦

… and still cannot easily implement his

(12)

Problem: Separation of Network and Application

•

Application view onto the network: byte pipe (black box)

•

Network view onto the application: load generator (black box)

•

Integrated system view would benefit application and network!

◦

Higher performance of application

◦

Higher efficiency and utilization of network

(13)

Example: VM Migration

•

Virtual Machine moved from Host A to B

•

Switches reactively find new location of host using ARP protocol

◦

High load through broadcasts, slow reaction

•

Why not let management application “program” the network

proactively based on its knowledge of VM locations and network topology?

VM1

ToR Switch ToR Switch

Switch

(14)

Example: Publish/Subscribe

•

Classic approach: Overlay networks

◦

Messages are transmitted multiple times

◦

Increased path length

•

Forwarding implemented in software

◦

Reduces throughput, increases latency

14 Publisher: Notification(stock value = $500) Subscriber: stock value > $450 Subscriber: stock value > $420 Duplicates!

B

𝐶

𝑃

(15)

Example: Publish/Subscribe

With SDN

•

Reduced number of messages

(less network load, better scalability)

•

Faster filtering in hardware (micro-seconds vs. milliseconds)

•

Shorter paths (less load, lower latency)

Publisher: Notification(stock value = $500) Subscriber: stock value > $450 Subscriber:

B

𝐶

𝑃

Hardware Fitering!

(16)

Example: Elastic Tandem Machines

based on SDN

Goal: Energy-proportional machine for data centers

• Low-power consumption in idle mode and low load

• Scale-up to nominal

(maximum) resources of VM

Approach: Elastic Tandem Machines

• Integration of System-on-a-Chip (SoC) machine and classic VM

• Seamless and transparent handover in network through Software-defined Networking ETMI LPMI (Web-/Application Server) Backend Server (Database/File Server) HPI (Web-/Application Server) Clients Internet Core Switches (OpenFlow-enabled) OpenFlow

Aggregation, ToR, and Virtual Switches (Layer 2 Forwarding)

Data connection to public service IP address of ETMI

(switched to LPMI or HPI) Datacenter Gateways Load Monitor Connection Monitor Connection Blocker Load Monitor Connection Monitor Connection Blocker SDN Controller with ETMI Handover Logic

Control connections to individual IP addresses

of LPMI and HPI VM Manager

Frank Dürr:Improving the Efficiency of Cloud Infrastructures with Elastic Tandem Machines.

In Proceedings of the 6th IEEE International Conference on Cloud Computing (Cloud 2013), pp. 91–98, Santa Clara, CA, USA, June 2013

(17)

SDN in a Nutshell

SDN is a paradigm to program networks at a high-level

“Think of it as a general language or an instruction set that lets me write a control program for the network rather than having to

(18)

Benefits of SDN (1)

•

Easy modification of the network control logic

◦

From “hard-coded” logic to exchangeable software

•

API to “program” the network

◦

Software (application) “defines” the network

•

High-level programming languages

◦

For implementation of logic

◦

To benefit from powerful integrated developing environments

(19)

Benefits of SDN (2)

•

Reduced switch complexity

◦

Remove control logic from switch and host it on servers

◦

Preserve same forwarding performance!

▪ Switch still supports forwarding in hardware

•

Integrated system: application & network

◦

Global view onto the system

•

Reducing the complexity of implementing control logic

◦

Distribution transparency “Intelligence” Network Compute Server

(20)

Tremendous Industrial Interest

•

> 100 members and many key players

•

Manufacturer of switches, telecommunication operators

•

Supporter and operator of data center

20

(21)

Gaining scientific impact

#Publications in ACM Portal by keyword and year

0 100 200 300 400 500 600 700 800 2 000 ₂001 ₂002 ₂003 ₂004 ₂005 ₂006 007₂ ₂008 ₂009 ₂010 ₂011 ₂012 ₂013 ₂014 P2P Publish/Subscribe SDN

(22)

Overview

1.

2.

Introduction to Software-Defined Networking (SDN)

◦

Principle 1: Flow-based forwarding

◦

Principle 2: Control plane / data plane separation

◦

Principle 3: Logical centralization (physical distribution)

◦

SDN system architecture

◦

Southbound interface: OpenFlow

◦

Northbound interfaces of OpenDaylight

3.

4.

Summary

(23)

Flow-based Forwarding

Forwarding defined on flows rather than only IP or MAC addresses

•

Theoretically: any information of a packet that identifies a

communication relation

•

Practically: combinations of selected layer 2 to 4 header fields

◦ Example: IP + Ports + protocol ids

•

Fine-grained forwarding of selected flows or coarse-grained

aggregation Elephant flow of backup service Latency-sensitive traffic H1

(24)

Control Plane and Data Plane Separation

•

Control plane: defines routes, manages network graph

•

Data plane: forwarding of packets

Control Plane Data Plane Data Plane Data Plane _Data Plane Data Plane Control Logic Control Logic Control Logic

(25)

Control Plane

Logically Centralized Controller

Data Plane Data Plane Data Plane _Data Plane Data Plane Control Logic Control Logic Control Logic physically distributed logically centralized

(26)

Why Logical Centralization?

•

Greatly simplifies implementation of control logic

◦

Consistent global view onto network

•

Global view can increase performance of control

◦

E.g., faster convergence

 Example: Distributed vs. centralized routing (see next slides)

(27)

Distributed Routing (1)

Distributed routing protocols

•

Need time to converge to optimum  lower resource utilization

•

Complex protocol and algorithm

20 5 5 10 10 10 10

(28)

Distributed Routing (2)

Distributed routing protocols

•

28 5 5 10 10 2.5 2.5 Switches S1 & S2 decide to use the same paths

S2 S1

(29)

Distributed Routing (3)

Distributed routing protocols

•

5 5 10 10 5 Converged to optimum after 2 steps S2 S1 5

(30)

Logically Centralized Routing

Centralized optimization

•

Faster convergence  higher resource utilization

•

Simpler routing algorithm on global view

30 5 5 10 10 5 Converged to optimum in 1 step S2 S1 5

(31)

Logically Centralized Routing

•

Significant performance increase in practice

•

Example: Google backbone optimization

◦

Nearly 100 % network utilization

◦

http://goo.gl/DN6RYv

Urs Hölzle

(32)

Architecture of an SDN System

Controller Control Logic Northbound Interface Southbound Interface Control Logic Control Logic

(33)

Components (1)

Switches/Routers

• Implement data plane: packet forwarding ◦ Manages forwarding information base

• Typically multi-layer switches

◦ Forwarding based on layer 2-4 headers

• Hardware switches

◦ Hardware support for fast matching

▪ Ternary content-addressable memory (TCAM)

• Software switches

◦ Connect multiple virtual machines to physical interface of host ◦ Example: Open vSwitch [http://openvswitch.org/]

(34)

Components (2)

SDN Controller

• Server process executed on host

• Implements control plane

• Implements southbound interface to switches

◦ Configuration of forwarding tables

◦ Injecting packets

◦ Events from switch (packet-in)

◦ Collection of traffic statistics

◦ Discovery of topology

• Interfaces with control logic (control “application”) via northbound interface(s)

34

Controller

Northbound Interface

(35)

Components (3)

Control Logic

•

Defines routes of “flows”

◦

Proactive and reactive routing

•

Might interface with other information sources

◦

Example: Virtual machine manager knowing locations of VMs on hosts Control Logic Control Logic Control Logic

(36)

Control Plane Distribution

•

Controller can be physically distributed in various ways

◦

No standard way of distribution defined

•

Objectives:

◦

Increase robustness

(37)

Control Plane Distribution: Replication

Primary (Master) Secondary (Slave, on standby) OpenFlow standard allows for connections from switch to multiple controllers

(38)

Control Plane Distribution: Partitioning

Part 1 Part 2

(39)

Southbound Interface: The OpenFlow Protocol

Controller Control Logic Northbound Interface Southbound Interface Control Logic Control Logic OpenFlow

(40)

The OpenFlow Protocol: Overview

•

OpenFlow de facto standard for southbound

interface

•

Defined by Open Networking Foundation

◦

Major vendors (Cisco, IBM, NEC, HP, Alcatel-Lucent, VMWare, …)

•

Interface to a single switch

◦

No aspects of control plane distribution defined

•

Basic functionality

◦

Modification of flow tables (adding, removing, modifying entries)

◦

Injecting packets

◦

Events for receiving packets (reactive routing)

◦

Querying traffic statistics (counters)

(41)

Architecture of an OpenFlow System

OpenFlow Switch Channel Controller Group Table Flow Table Flow Table … Southbound Interface Channel OpenFlow Protocol pipeline TCP optional: TLS/SSL for authentication &

encryption

Switch connects to standard port:

• Previously: 6633 • Now: 6653 (IANA)

(42)

Flow Tables & Flow Entries

• Flow tables consist of a list of flow entries

• Flow entry (slightly simplified):

◦

Match field: Defines matching packets

◦

Priority: Precedence if multiple entries match

◦

Counters: Counts matches

◦

Instructions:

▪ Modification and forwarding of packet

◦

Timeouts: Removes entry after a certain (idle) time 43 Flow Table Entry Entry Entry …

(43)

Table Misses

Important for dynamic routing

•

Each table supports a table-miss flow entry

◦

Lowest priority

◦

Matches all packets

•

Possible actions (at least):

◦

Drop

◦

Send to controller

•

If no table-miss entry is defined

◦

Drop packet (default in OF1.3)

◦

Or define another default action

Flow Table Entry Entry Entry … no match? Table-Miss Flow Packet

(44)

Match Fields

Subset of L2-4 header fields

•

10 tuple (must be supported)

◦

For more (optional) fields please see OF standard

•

Note: hardware switches might only support hardware-accelerated matching on some combinations!

◦

Rest goes the “slow path“

45

Ingress Port

Ether Src Ether Dst VLAN ID Ether Type

IP SRC IP DST IP PROTO TCP/UDP SRC PORT TCP/UDP SRC PORT • Specifies layer 3 protocol • E.g, 0x0800 = IPv4

• Specifies layer 4 protocol • E.g, 6 = TCP, 17 = UDP

(45)

Wildcard Matching (1)

•

Not all fields need to be specified: Wildcard *

◦

Matches any value

•

For IP addresses, bitmasks can be specified (CIDR)

◦

Example: Subnet mask of IPv4 address 192.168.1.1/24

(netmask 255.255.255.0) In Port Eth Src Eth Dst Eth Type VLAN ID IP SRC IP DST IP Proto Src Port Dst Port * * * 0x0800 (IPv4) * * 10.2.3.4 6 (TCP) * 80 2 * * * 42 * * * * * * * * 0x0800 (IPv4) * * 10.1.2.3 * * *

Traffic of a certain VLAN from a certain port

(46)

Wildcard Matching (2)

•

Hardware switches can perform very fast matching using Content Addressable Memory (CAM)

◦

Parallel matching of all entries in one clock cycle (micro-seconds)

•

Two types of CAM

◦

Binary CAM (BCAM): ordinary bits 0, 1

▪ Good for exact match

◦

Ternary CAM (TCAM): ordinary bits + wildcard (don‘t care) 0,1, *

▪ Implementation of longest prefix match on IP addresses

•

Drawbacks: Consumes significant energy, silicon space

◦

Limited memory size in switches

(hundreds to hundred thousand entries)

◦

Remember the day of the 512k problem!

(47)

A Thought about Flexibility

•

OpenFlow specification tailored to specific protocols

◦

IP, TCP, UDP, ICMP, ARP, …

◦

Did not support IPv6 in version 1.0!

•

Again: Stuck with standard protocols

◦

Practical trade-off: existing hardware switches can be easily

modified to support OpenFlow

•

Theoretically, we could just assume a big bit field and bit mask

◦

Fields could be freely defined

bit 0

(48)

Actions

•

Output: output packet on the specified port

•

TTL modifications

◦

Decrement TTL, copy TTL outwards/inwards

•

Push and pop tags

◦

Add or remove VLAN/MPLS/PBB (MAC-in-MAC) tags to/from the

packet

•

Set header fields

◦

Example: IP- or MAC-address re-writing

•

Group actions

◦

Example: Multicast

Order of execution of actions is well-defined by action type 49

(49)

Instructions

•

Write actions

◦

Adds given actions to the action set

◦

Overwrites actions of the same type

•

Go to table with given id

◦

Hybrid switches can also go to the “normal“ table

•

Apply specific actions immediately

◦

Modify packet before going to next table

•

Clear action set

(50)

Proactive vs Reactive Routing

•

Routes defined by a set of flow table entries

◦

Along the path of packets

•

So far, we know what a flow table entry contains

•

Question now: When to set up flow table entries?

•

Two options:

◦

Proactively: before the flow starts

◦

Reactively: as soon as the flow starts

51

Controller

(51)

Proactive Routing

•

Controller proactively “pushes“ flow table entries onto switches

•

Advantage: Reduces controller load

◦

No reactive handling of packets

•

Disadvantage: Occupies space in flow table of switch

◦

Even without traffic

◦

Remember:

Size of flow table is limited!

Controller

add entry add entry

add entry

Control Logic

(52)

Reactive Routing (1)

•

Switch receives a packet without matching flow table entry

◦

Switch redirects packet to controller

▪ Open flow packet_in event at controller ▪ Forwarded to control logic

•

Control logic calculates route

•

Controller installs flow table entries along path

◦

Further packets of flow

don‘t involve controller again 53 Controller packet-in event packet Control Logic

(53)

Reactive Routing (1)

•

◦

•

◦

don‘t involve controller again

Controller

add entry add entry

add entry

Control Logic

(54)

Reactive Routing (1)

•

◦

•

◦

don‘t involve controller again 55 Controller packet packet packet packet No packet-in events of this flow anymore until timeout of flow table entries

(55)

Reactive Routing (2)

•

Advantage: Saves flow table space

•

Disadvantage: Puts load onto controller and control network

◦

Not such a big problem for TCP

▪ Sender blocked until connection setup is done

◦

Beware: Connection-less UDP can send at full rate immediately (without warning)!

(56)

Required Information for Routing

Dynamic routing requires knowledge of network status

•

Network topology (nodes and links):

◦

Switches and hosts

◦

Links between switches (from switch port to switch port)

◦

Links between hosts and switches (connection host to switch port)

◦

Bandwidth of links

•

Traffic statistics

◦

Number of packets or bytes

◦

Number of dropped packets, receive/transmit errors, etc.

◦

Per flow (entry), link/port, group, etc.

(57)

Network Topology

•

Discovery of network topology not covered by OpenFlow

•

Controller implements standard protocols

◦

Logical Link Layer Discovery Protocol (LLDP)

◦

ARP handling for host discovery

•

Controller exposes discovered information to control logic

(58)

Traffic Statistics

•

OpenFlow switches implement counters

•

Controller can query counters using OpenFlow messages:

◦

Flow Statistics (OFPMP_FLOW, OFPMP_AGGREGATE)

◦

Port Statistics (OFPMP_PORT_STATS)

◦

Table Statistics (OFPMP_TABLE)

◦

Queue Statistics (OFPMP_QUEUE)

◦

Group Statistics (OFPMP_GROUP)

◦

Meter Statistics (OFPMT_METER)

(59)

(60)

Northbound Interface

61 Controller Control Logic Northbound Interface Southbound Interface Control Logic Control Logic OpenFlow

(61)

No Single Standard Interface

•

No standard for the northbound interface from the ONF

•

Every controller can define its own interfaces

•

We focus on two specific interfaces of the most popular open SDN controller: OpenDaylight

◦

REST Interface

◦

Java/OSGi interface

(62)

REST Interfaces

•

REST interfaces are popular for web services

◦

Many programmers already know web technologies

◦

Can expose network configuration as a web service

•

Based on common web technologies

◦

HTTP

▪ No problems with firewalls

◦

XML, JSON

▪ Simple and intuitive markup languages

•

Drawback: events not supported

◦

HTTP based on request/response paradigm

◦

Restricted to proactive routing!

(63)

RE

presentational

S

tate

T

ransfer (REST)

REST is resource-oriented

•

In contrast to service-oriented architectures (XML-RPC, WS-*)

•

Unique identifiers to identify resources (URI)

◦

Employees of a company: http://foo.bar/employees/

One employee: http://foo.bar/employees/170974d

◦

Relevant SDN resources: flows, topology, hosts, etc.

•

Client/Server architecture

◦

Server manages resources ( controller implements server)

◦

Client manipulates resources ( control logic/applications)

•

Uniform interface: well-defined methods to manipulate resources

(64)

RE

presentational

S

tate

T

ransfer (REST)

HTTP methods to manipulate resources:

•

GET: retrieve a resource

•

POST: create resource

•

PUT: update resource

•

DELETE: remove resource

•

HEAD: retrieve meta data on resource

•

OPTIONS: methods that can be executed on resource

(65)

RE

presentational

S

tate

T

ransfer (REST)

Stateless protocol between client and server

•

Exchange of resource representations between client and server

◦

XML,

◦

JSON,

◦

binary format,

(66)

REST interface(s) of OpenDaylight

(67)

(68)

REST Interface: Adding a Flow

•

PUT request to URI

http://<controller_ip>:8080/controller/nb/v2/

flowprogrammer/default/node/OF/00:00:00:00:00:00:00:02/ staticFlow/flow1

•

JSON (or XML) payload:

71 { "name":"flow1", "installInHw":"true", "priority":"65535" "node": {"id":"00:00:00:00:00:00:00:02","type":"OF"}, "ingressPort":"2", "etherType": "0x800", "protocol": "6", "tpDst": "80", "actions":["DROP"] }

Type and ID of data path element (switch) Type and ID of data path element (switch)

(69)

REST Interface: Deleting a Flow

•

DELETE request to URI

http://<controller_ip>:8080/controller/nb/v2/

flowprogrammer/default/node/OF/00:00:00:00:00:00:00:02/ staticFlow/flow1

•

No payload

(70)

REST Interface: Getting Flows

•

GET requests to different URIs return configured flows:

◦

All Flows:

http://<controller_ip>:8080/controller/nb/v2/ flowprogrammer/default

◦

Flows of a node (switch):

http://<controller_ip>:8080/controller/nb/v2/ flowprogrammer/default/node/{nodeType}/{nodeId}

◦

Specific flow: http://<controller_ip>:8080/controller/nb/v2/ flowprogrammer/default/node/{nodeType}/{nodeId}/ staticFlow/{name} 75

(71)

Querying Topology Information

•

GET request to URI

http://localhost:8080/controller/nb/v2/topology /default

•

Returns JSON (or XML) document:

{"edgeProperties ... "edge":{ "tailNodeConnector":{ "node":{"id":"00:00:00:00:00:00:00:01","type":"OF"}, "id":"2","type": "OF" }, "headNodeConnector":{ "node":{"id":"00:00:00:00:00:00:00:02","type":"OF"}, "id":"2","type":"OF" } } #2 #2

(72)

Finding an End Systems

•

GET request to URI

http://localhost:8080/controller/nb/v2/ hosttracker/default/address/10.0.0.1

•

Returns JSON (or XML) document:

77 { "dataLayerAddress":"ba:17:35:47:98:7f", "nodeType":"OF", "nodeId":"00:00:00:00:00:00:00:01", "nodeConnectorType":"OF", "nodeConnectorId":"1","vlan":"0", "staticHost":false, "networkAddress":"10.0.0.1" } #1

(73)

Getting all Active End Systems

•

GET request to URI

http://localhost:8080/controller/nb/v2/ hosttracker/default/hosts/active

•

Without manual configuration, only hosts that have already communicated can be found!

•

Manual host configuration possible with PUT/DELETE requests to URI

http://localhost/nb/v2/hosttracker/default/ address/10.0.0.1

(74)

OpenDaylight OSGi Interface

82 82 OSGi Framework (Apache Equinox) OSGi Bundle Interface of exported service SAL IDataPacketService IListenDataPacket OpenDaylight

Service Abstraction Layer Binding to service

(77)

Implementing a Bundle

•

One bundle can implement several components

•

Implement an Activator that …

◦

… returns implementations (classes) of each implemented

component

◦

… configures each component instance

▪ Declare exported services ▪ Declare used services

•

Implement each component

◦

Bind to used services at initialization

◦

Implement control logic

▪ Implement callback for packet-in events

(78)

Activators (1)

Example: An Activator returning one component called PacketHandler (implementing our control logic)

public class Activator extends ComponentActivatorAbstractBase {

public Object[] getImplementations() {

Object[] res = { PacketHandler.class }; return res;

} }

(79)

Activators (2)

public class Activator extends ComponentActivatorAbstractBase {

public void configureInstance(Component c, Object imp, String containerName) {

if (imp.equals(PacketHandler.class)) {

// Export IListenDataPacket service

Dictionary<String, Object> props = new Hashtable<String, Object>(); props.put("salListenerName", "mypackethandler");

c.setInterface(new String[] {IListenDataPacket.class.getName()}, props);

// Register for IDataPacketService

c.add(createContainerServiceDependency(containerName). setService(IDataPacketService.class).setCallbacks(

"setDataPacketService",

"unsetDataPacketService").setRequired(true)); }

(80)

Binding to Services / Unbinding from Services

public class PacketHandler implements IListenDataPacket {

private IDataPacketService dataPacketService;

private IFlowProgrammerService flowProgrammerService;

// Bind to service

public void setDataPacketService(IDataPacketService s) { dataPacketService = s;

}

// Unbind from service

public void unsetDataPacketService(IDataPacketService s) {

if (dataPacketService == s) { dataPacketService = null; }

}

(81)

OSGi Interface: Callback for Packet-in Events

@Override

public PacketResult receiveDataPacket(RawPacket inPkt) {

// The connector, the packet came from ("port")

NodeConnector ingressConnector =inPkt.getIncomingNodeConnector();

// The node that received the packet ("switch")

Node node = ingressConnector.getNode();

// Here you might want to decode the packet, // program flows, forward the packet, etc.

// Alternative return values:

// PacketResult.CONSUME, PacketResult.IGNORED

return PacketResult.KEEP_PROCESSING; }

(82)

Decoding Packets

// Use DataPacketService to decode the raw packet (inPkt).

Packet l2pkt = dataPacketService.decodeDataPacket(inPkt);

// Repeated type checking and type casting

if (l2pkt instanceof Ethernet) {

Object l3Pkt = l2pkt.getPayload();

if (l3Pkt instanceof IPv4) { IPv4 ipv4Pkt = (IPv4) l3Pkt;

int dstAddr = ipv4Pkt.getDestinationAddress(); InetAddress addr = intToInetAddress(dstAddr);

System.out.println("Pkt. to " + addr.toString() + " received by node " + node.getNodeIDString() + " on connector " +

ingressConnector.getNodeConnectorIDString()); }

(83)

Programming Flows: Defining Match Rule

Match match = new Match();

// Match IPv4 ethertype

match.setField(MatchType.DL_TYPE, (short) 0x0800);

// Match TCP protocol id

match.setField(MatchType.NW_PROTO, (byte) 6);

// Match on IP destination address

match.setField(MatchType.NW_DST, sourceAddr);

// Match on destination port number

(84)

Programming Flows: Setting Actions

// List of actions applied to the packet

List actions = new LinkedList();

// Output packet on certain port

actions.add(new Output(egressConnector));

(85)

Creating and Programming the Flow

// Create the flow

Flow flow = new Flow(match, actions);

// Use Flow Programmer Service to program flow.

Status status = flowProgrammerService.addFlow(node, flow);

if (!status.isSuccess()) {

log.error("Could not program flow: " + status.getDescription()); }

(86)

Forwarding Packets

// Maybe you want to modify some fields of the packet using // the methods from classes Ethernet, IPv4, TCP

// (typecast RawPacket to corresponding type; // see decoding packet).

// Define, over which port to forward packet

pkt.setOutgoingNodeConnector(egressConnector);

// Use Data Packet Service to forward packet

dataPacketService.transmitDataPacket(pkt);

(87)

Creating and Deploying the Bundle

•

Compile Activator and component implementation

•

Package into OSGi bundle (JAR)

 Maven helps to automate these steps

(88)

Essential Commands (1)

•

Listing all bundles:

osgi> ss id State Bundle 0 ACTIVE org.eclipse.osgi_3.8.1.v20120830-144521 1 ACTIVE org.apache.felix.fileinstall_3.1.6 2 ACTIVE org.eclipse.jdt.core.compiler. batch_3.8.0.I20120518-2145

•

Listing a bundle matching a given name: osgi> ss | grep simple

171 ACTIVE org.opendaylight.controller.samples. simpleforwarding_0.4.1.SNAPSHOT

(89)

Essential Commands (2)

•

Installing and starting a bundle:

osgi> install file:/home/user/myctrlapp/target/ myctrlapp-0.1.jar

Bundle id is 256

osgi> start 256

•

Updating a bundle:

osgi> update file:/home/user/myctrlapp/target/ myctrlapp-0.1.jar

(90)

Essential Commands (3)

•

Stopping and uninstalling a bundle:

osgi> ss | grep simple

171 ACTIVE org.opendaylight.controller.samples. simpleforwarding_0.4.1.SNAPSHOT

true

osgi> stop 171

osgi> uninstall 171

•

Showing information about a bundle (e.g., used and exported services):

osgi> bundle 171

(91)

Further Details

•

Developing OSGi Components for OpenDaylight:

•

Reactive Flow Programming with OpenDaylight:

(92)

Overview

1.

2.

3.

◦

Control plane distribution and consistency

◦

Real-time SDN

◦

SDN-based networked control systems

◦

SDN-based high-performance communication middleware

4.

Summary

(93)

Control Plane Distribution and Consistency

Horizontal scalability _{No single point of failure}

Distributed SDN-Controller

OpenFlow Protocol

Challenge:

Control Plane Consistency

Challenge: Consistent routes: • No black holes • No micro-loops • No duplicates • …

(94)

SDN’s CAP Problem

•

Logically centralization makes implementation …

◦

… of control logic (e.g., routing algorithm) simpler

◦

… implementation of controller hard

•

Well-known CAP problem also applies to a distributed SDN controller

◦

Only two out of the three CAP properties possible:

Consistency, availability, partitioning tolerance

•

Control plane distribution

is subject to current research

101

C

A P

Distributed

(95)

Data Plane Consistency

•

Reitblatt et al. proposed concept of packet level consistency ◦ Each packet sees consistent network configuration during route

transition

◦ Either old or new route; no mixture

•

Can show: each invariant that holds before and after update also holds during updates

◦ Assuming routing is correct (no black-holes, loops, duplicates), these properties also hold during transition

102 102 pkt 2 pkt 1 source destination old route new route

(96)

Packet-level Consistency

•

Approach:

◦ Packet tagging on end systems ▪ Using VLAN id header field

◦ Keeping both routes in network during transition

•

Drawback: memory overhead

◦ Requires 2x TCAM space in worst-case

◦ Motivates research for more light-weight update strategies  update ordering

103 103 103 pkt 2: VLAN 1 pkt 1: VLAN 2 source destination old route new route

(97)

Data Plane Consistency with Update Ordering

•

Question: Can we find an update sequence that ensures given

properties?

•

Example: Avoiding black-holes during unicast route updates ◦ Update flows in reverse order from destination to source

•

Can be further optimized, e.g.:

◦ Considering update speed of switches [Jin et al.]

◦ Avoid network congestion during updates [Liu et al.]

•

Can be extended,

e.g., to Multicast (@IPVS)

p2

p1

1st update 2nd update

source _destination

Xin Jin, Hongqiang Harry Liu, Rohan Gandhi, Srikanth Kandula, Ratul Mahajan, Ming Zhang, Jennifer Rexford, Roger Wattenhofer: Dionysus: Dynamic Scheduling of Network Updates. Proceedings of the ACM SIGCOMM 2014

(98)

Real-time SDN for Manufacturing Systems

•

Motivation

◦ Improve re-configurability of manufacturing systems

◦ Network follows manufacturing system changes

•

Challenges

◦ Real-time requirements for control systems in manufacturing

•

Approach

◦ Software-defined environment for improving flexibility

◦ Coordinated TDMA traffic scheduling in time-triggered local area network

105 Remote Controller LAN sensing action decision

(99)

SDN-based Networked Control Systems

Motivation:

• Cyber-physical Systems (CPS) based on geo-distributed sensors & actuators

◦ Smart grid: ~ 50 Mio. smart meters in 43 % of US households in 2014 [IEI]

◦ Smart homes: > 500 smart devices per household by 2022 [Gartner]

◦ Tele-robotics & manufacturing (Industry 4.0)

• Networked Control Systems (NCS) required to control these CPS

◦ Close control loop over network

Problem:

• IP networks offer insufficient quality of service for NCS

◦ Uncontrolled packet delay & jitter

106

IP Network sensing

(100)

NCS-specific Routing Algorithm

[Carabelli et al.]

• SDN controller has global view onto packet loss & delay distribution of links

• Routing algorithm searches optimal feasible paths: ◦ Fulfilling end-to-end delay distribution (QoS)

◦ Minimizing network load defined by sampling rate and transit time

Sensor

NCS-controller

Arrival probability P() Delay distribution L()

Ben Carabelli, Frank Dürr, Boris Koldehofe, Kurt Rothermel: A Network Abstraction for Control Systems. Technical Report 2014/01, University of Stuttgart, 2014

(101)

High Performance Communication Middleware

•

Modern applications have demanding requirements

◦ Low latency, high throughput, efficient bandwidth utilization, ...

◦ High frequency trading: 1ms less delay  $100 million/year

◦ Online shopping: 100ms delay penalty  1% loss in sales

◦ Internet gaming: delay > 50ms  hurt user experience

•

Communication middleware so far:

◦ Overlay network of brokers

▪ Duplicate messages, increase path length ◦ Forwarding implemented in software

▪ Reduce throughput, increase delay

•

Can achieve sub-micro second latency and line-rate throughput with SDN

Duplicates! B P S₁ S₂ InformationWeek, 2007 Amazon, 2008 HotNets, 2014

(102)

Overview

1.

2.

3.

4.

Summary

(103)

Summary

•

SDN new networking standard

◦

SDN increases flexibility and efficiency significantly

◦

Strong support from industry and academia

•

SDN concepts:

◦

Flow-based forwarding

◦

Logical centralization

◦

Control plane / data plane separation

•

SDN controller interfaces:

◦

Southbound to network

◦

Northbound to control application

(104)

Discussion

Thank you very much for your attention!

(http://netfpga.org/

◦http://goo.gl/DN6RYv

http://foo.bar/employees/

http://foo.bar/employees/170974d

Software-defined Networking (SDN)