DEBS Tutorial: Software-defined Networking Event-based systems meet SDN

(1)

Universität Stuttgart

Institute of Parallel and Distributed Systems (IPVS) Universitätsstraße 38 D-70569 Stuttgart

DEBS Tutorial: Software-defined Networking

“Event-based systems meet SDN”

Boris Koldehofe, Frank Dürr, Muhammad Adnan Tariq University of Stuttgart

(2)

Universität Stuttgart IPVS Research Group

“Distributed Systems”

Overview

1.

Event-based System view on SDN

2.

Introduction into Software-Defined Networks (SDN)

3.

Illustrating the Power of SDN in the context of Event-Based Systems

4.

Implementation & Testing of SDN

(3)

Overview

1.

•

Requirements

•

Shaping the network

•

How SDN helps

2.

3.

(4)

Universität Stuttgart IPVS Research Group “Distributed Systems”

Event-Based Systems

•

Large-scale deployment

◦

Integrates many consumer and producers

◦

Intelligent bus that allows for processing events in real-time

•

Many critical applications

◦

Traffic monitoring, smart grid, logistics

4

Factory Transporter _warehouse

Basic events

(5)

Requirements

•

Efficient resource utilization

◦

bandwidth

◦

Processsing

•

High Throughput

•

Low latency

◦

Processing and communication

◦

Soft Real-Time Requirements

(6)

Typical problems impacting efficiency

•

Matching algorithms

◦

Filter, Aggregation, Sequence

•

Routing

◦

Best path from publisher to consumer

•

Placement

◦

Minimize bandwidth utilization

◦

Low latency response

6 Network Filter, Operator Input Streams Output Streams

P

C

(7)

How event-based systems deal with networks

•

Most event-based systems realized as a

communication middleware

◦

Builds on transport protocols: TCP, UDP

◦

Network topology is transparent

•

Middleware observes characteristics of the network and reacts to it

◦

Monitor network characteristic

◦

Dynamic network map

▪

E.g. Vivaldi Communication Middleware Network B₂ B₁ Low/High Latency Monitoring

(8)

Naive Idea: Shape the network

Determine routes of packets at the network layer to match demand of services

Key benefits:

•

Increase resource usage and performance

◦ Services at lower cost possible

◦ Switching in

•

Improve predictability of performance

◦ Verification, Stability

•

Benefit from network operations

◦ Built-in operations of routers and switches

◦ Processing of packets

(9)

Example: Publish/Subscribe

•

Overlay network

◦

Messages are transmitted multiple times

◦

Increased path length

•

Forwarding implemented in software

◦

Reduces throughput, increases latency

Publisher:

Notification(stock value = $500)

Subscriber:

stock value > $450

(10)

Example: Publish/Subscribe

•

Shaping the network

◦

Reduces number of messages

◦

Faster filtering in Hardware

◦

Shorter paths 10 Publisher: Notification(stock value = $500) Subscriber: stock value > $450 Subscriber: stock value > $420 No Duplicates!

B

Hardware Fitering!

(11)

Many obstacles

•

Accessing the hardware and utilizing different protocols

•

Configuration of the network

•

Dynamic Network management

High inflexibility currently has prevented advancements in efficiency and robustness of networked applications

(12)

Limited Flexibility: Access to hardware

Raises Two Concerns:

1.

No direct access to the network devices

→ Requires new abstractions to access switches

◦

Google Compute Engine provides access to a simple router

◦

Network Virtualization

2.

Black box design of switches

◦

Standard and proprietary protocols (hardcoded)

◦

No changes without support of the manufacturer

◦

Switches and routers become more open and programmable

(13)

Limited Flexibility: Programming

•

What if the switch/router hardware is open?

Adding new protocols or network control logic is complex

•

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?

(14)

Limited Flexibility: Automated Management

•

Networked systems became highly dynamic

◦

Event-based systems

▪

Dynamic data sources, changes in interest, load variations

◦

Datacenter network

▪

Dynamic set of VMs with dynamic locations (hosts), variable traffic patterns, heterogeneous QoS demands, etc.

•

Manual configuration not possible anymore

◦

Automatic configuration and provisioning of network resources

•

Fixed set of policies to configure the network does not sufficient

anymore

(15)

Overcoming these Problems with

Software-defined Networking (SDN)

Software defined-networking leverages increased flexibility

•

Easy modification of the network control logic

◦

From “hard-coded” logic to exchangeable software

•

High-level programming languages

◦

For implementation of logic

◦

To benefit from powerful integrated developing environments

•

API to “program” the network

(16)

Software-defined Networking: Features

•

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 view: application & network

◦

Global view onto the system

▪ Application state and network state

•

Reducing the complexity of implementing control logic

◦

Distribution transparency 16 Intelligence Network Compute Server

(17)

SDN in a nutshell

•

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

◦

Utilzes pradigm of centralized control to program the switches and routers of the network

“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)

Historic Notes

•

Flexible network management tools

◦

E.g. for ATM switches

◦

Failed to involve vendors of switches

◦

Not targeted at IP

•

OpenFlow standard key driver

◦

Evolved from Stanford University

◦

Currently developed by Opennetwork Foundation

◦

Defines the interface to control a network of switches

◦

Expected to be supported by most of next generation switches

•

Real-world deployment

◦

Datacenter, Internet-Service Provider

(19)

Tremendous Industrial Interest

•

>100 members and many key players

•

Manufacturer of switches, telecommunication operators

•

Supporter and operator of data center

(20)

Supports dealing in a flexible manner with a

huge number of protocols and standards

(21)

SDN is already in use

•

Google

◦

Isolate user and data replication services

▪ Famous talk by Urs Hölzl

•

Network virtualization

◦

Establish independent flows for services

•

Reduce overhead in large data center

◦

Address resolution protocol (ARP)

◦

Avoid frequent flooding by moving

(22)

Not everything solved by SDN straight away

Although Control is logically centralized many issues involved in achieving consistent control

•

Requires revisiting key results of Distributed Systems research

◦ Consistent scalable reconfigurations (recall the famous CAP theorem)

•

Methods and protocols for efficient networked applications

◦ Utilize the benefits of SDN to achieve high performant middleware

◦ E.g. line-rate publish/subscribe with matching in

•

Networking abstractions

◦ leverage SDN to wide area networks

•

Methods for design and verification of networked applications

22

(23)

Gaining scientific impact

0 100 200 300 400 500 600 700 800 900 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 P2P SDN Publish/Subscribe

(24)

(25)

Overview

1.

2.

3.

(26)

Overview

1.

A view on networks from EBM

2.

•

Concepts

•

Architecture

•

Northbound Interface: Control

•

Southbound Interface: OpenFlow

3.

4.

(27)

Basic concepts

Key problems addressed by SDN:

•

Simple definition of communication relations between hosts

•

Control and data plan separation

•

Logically centralized control

(28)

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 + TCP/IP protocol ids

•

Fine-grained forwarding of selected flows or coarse-grained aggregation

Elephant flow of backup service

All other traffic from H1 to H2 H1

(29)

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

(30)

Control Plane

Logically Centralized Controller

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

(31)

Architecture of an SDN System

Controller Control Logic Northbound Interface Southbound Interface Control Logic Control Logic

(32)

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

◦ Used in datacenters to connect multiple virtual machines to physical interface of host

◦ Example: Open vSwitch [http://openvswitch.org/]

• Hybrid switches: Implement SDN & standard L2/L3 forwarding

(33)

Components (2)

SDN Controller

• Process executed on external host • Implements control plane

◦ Routing information base / Routing table

◦ Management of network graph (topology, traffic) • Implements southbound interface to switches

◦ Configuration of forwarding tables

◦ Events from switch (packet-in)

◦ Collection of traffic statistics

• Interfaces with control logic via northbound interface(s)

◦ No standard, but dedicated controller exist for high-level programming

◦ NOX (C/Python), Beacon (Java; OSGi, HTTP/REST), Floodlight (Java, Controller Northbound Interface Southbound Interface

(34)

Components (3)

Control Logic

•

Defines routes

◦

Proactive and reactive routing

•

Might interface with other information sources

◦

Example: Virtual machine manager (locations of VMs on hosts)

34 Control Logic Control Logic Control Logic

(35)

Control Plane Distribution

•

Controller can be physically distributed in various ways

◦

No standard way of distribution defined

•

Logical centralization: distribution transparent to control logic

◦

Allows global view onto the system

•

Goal:

◦

Deal with failures

◦

Increase scalability

(36)

Control Plane Distribution: Replication

36

Primary (Master)

Secondary (Slave, on standby)

Reduces downtime for reconfigurations

- e.g. deploy new subscriptions

(37)

Control Plane Distribution: Partitioning

Part 1 Part 2 coordination Support large-scale deployment - Raises issues similar to P2P networks - Knowledge about neighborhood - Coordination and consistency

(38)

Southbound Interface: The OpenFlow Protocol

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

(39)

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)

◦

Events for receiving packets (reactive routing)

(40)

OpenFlow: A mature standard?

Note: That OpenFlow is still quickly evolving

•

Many switches and controller still only implement OpenFlow 1.0!

◦

No support for IPv6 addresses, limited matching capabilities, …

•

The following descriptions are based on OpenFlow 1.3.

◦

New development most likely to focus on 1.3

(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: 6633

(42)

OpenFlow Switch

The Way of a Packet through a Switch

42

Flow Table 0

Packet _{Table 1}Flow _TableFlow Execute_Actions

n Packet … packet, ingress port, actions = {} ingress port, packet, meta data, actions packet, actions in out

(43)

Flow Tables & Flow Entries

• Flow tables consist of a list of flow entries

• Flow entry:

◦ Match field: Defines matching packets

◦ Priority: Precedence of matching if multiple

entries match

◦ Counters: Counts matches

◦ Instructions:

▪ Modify action set and meta data

▪ Forward to other tables (or stop)

◦ Timeouts: Removes entry after a certain (idle)

time

◦ Cookie: filtering of flow modifications and

statistics; not used in packet processing

Flow Table

Entry Entry

Entry

(44)

One Step in the Pipeline

1.

Find highest priority matching entry, say e

2.

Apply instructions of e:

◦

Update packet

◦

Update action set

◦

Update meta data

3.

Goto next table

if defined by instructions or execute action set

44 Flow Table Entry Entry Entry … ingress port, packet, meta data, actions ingress port, packet’, meta data’, actions’

(45)

Match Fields

Subset of L2-4 header fields

•

10 tuple (must be supported)

◦

More (optional) fields exist

Note: hardware switches might only support

hardware-accelerated matching on some combinations!

◦

Rest goes the “slow path“

Ingress Port

Ether Src Ether Dst VLAN ID Ether Type

IP SRC IP DST IP PROTO

TCP/UDP SRC TCP/UDP SRC

• Specifies layer 3

protocol

• E.g, 0x0800 = IPv4

• Specifies layer 4 protocol

(46)

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 * * *

All traffic to a certain web server (port 80) Traffic of a certain VLAN from a certain port

(47)

Wildcard Matching (2)

•

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

◦

Parallel matching of all entries in one cycle

•

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

(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 tags to/from the packet

•

Set header fields

◦

Example: IP-address re-writing

•

Group actions

◦

Example: Multicast

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

(49)

Table Misses

Important for reconfigurations

•

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)

◦

Or define another default action

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

(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

50

Controller

(51)

Proactive Routing

Controller proactively “pushes“ flow table entries onto switches

•

Advantage: Reduces controller load

◦

No reactive handling of packets

•

Disadvantage: Occupied space in flow table

◦

Even without traffic

◦

Size of flow table is limited!

▪ thousands to hundred thousand entries

Controller

add entry add entry

(52)

Proactive Routing Example

Pub/Sub middleware

•

Sender sends advertisements to controller

•

Receiver sends subscriptions to controller

•

Controller calculates distribution tree

◦

Before notifications are flowing

•

Relieves controller from bursts of notifications!

52

Publisher:

Will send stock values

Subscriber:

Want stock values > $450

Subscriber:

Want stock values > $420

Controller

(53)

Reactive Routing (1)

•

Switch receives a packet without matching flow table entry

•

Switch redirects packet (header) to controller

◦

Open flow packet_in event at controller

◦

Forwarded to control logic

•

Controller calculates route

◦

Option 1: Install flow table entries along path

▪

Further packets of flow don‘t involve controller

◦

Option 2: Just forward packet (no flow table entry set)

▪

Next packet of flow is again redirected to controller

Controller

Missed packets

New flows + packets

(54)

Reactive Routing (2)

•

Advantage: Saves flow table space

•

Disadvantage: Puts load onto controller and control network

◦

Bottleneck for reconfigurations

▪

May vary for TCP and UDP

▪

TCP: Sender blocked until connection setup is done

▪

UDP can send at full rate immediately (without warning)!

(55)

Reactive Routing: Use Cases

Reactive calculation of dissemination tree

•

Controller executes Dijkstra‘s algorithm on demand

•

Sets up source-based multicast tree

Controller

sender

(56)

Reactive Routing: Use Cases

Reactive calculation of dissemination tree

•

Controller executes Dijkstra‘s algorithm on demand

•

Sets up source-based multicast tree

56

Controller

sender

receiver

(57)

Summary

Key concepts and benefits of SDN:

• Flow-based forwarding

◦ Enables fine-grained treatment of flows • Control/data plane separation

◦ High flexibility without sacrificing performance

▪ Ease of adding and changing control logic via dedicated controller

▪ Fast forwarding in hardware by switches

◦ Simpler switches through “outsourcing“ of control logic • Logically centralized view

◦ Ease of implementation through distribution transparency

◦ Global optimization

(58)

Towards high per formant event-based

systems

(59)

Overview

1.

2.

3. ◦

Motivation

◦

Reference Architecture for Content Routing in the Future Internet

◦

Line-Rate Publish/Subscribe in OpenFlow

◦

Research Challenges and Conclusions

(60)

Event-based communication

•

Applications react asynchronously to events

•

Selective interest in information

•

Minimize communication

and processing load in brokering events

•

Offer high responsiveness

Basic events

Traffic Jam

(61)

Publish/Subscribe Systems

•

Selective dissemination of information

•

Broker overlay for dissemination

Topic based

Information divided into topics

Content based

Restrictions on message content { Traffic = any ^ Distance < 100km }

P P P S S S Traffic M81? Traffic M6? Traffic M8? Danger in Danger in Mannheim Broker Overlay S S S P P P

(62)

Publish/Subscribe vs IP-Multicast

•

Content-Routing

+

Minimize network utilization

-

Matching overhead in each hop at application layer

-

Unawareness of network topology

•

IP-Multicast

+

Line-rate processing in the routers

+

Good adaptation to network topology

-

no large diversity in streams

62

bandwidth

responsiveness

BUT: Multicast can provide far better responsiveness

vs.

(63)

Trends towards Line Rate Publish/Subscribe

•

Improve QoS by network monitoring

◦

Improves network awareness and responsiveness

•

Specific Hardware + network Configurations

◦

Net FPGA

◦

LIPSIN

But no Interoperability at Internet-scale!

•

No standards expected to be available soon

(64)

Outline

•

Motivation

•

Challenges and Conclusions

(65)

New technologies with impact on approaches

Potential to change middleware deployment in the Future

Internet

1.

Software-defined Networking

◦

Supported by next generation switches

▪

Massive interest by industry, e.g. Cisco featuring OpenFlow

◦

Switches become configurable by separation of control and data plane

2.

Network Virtualization

◦

Allows application-centric configuration of networks

◦

Isolation between multiple applications

(66)

Network Virtualization

◦

Dimensioned according to application needs,

◦

E.g. bandwidth, latency

•

OpenFlow perfect abstraction

to configure virtual networks

◦

Easy mapping of flows to physical switches

⇒ Preserve performance also for virtual switches

66 Internet Service Provider Virtual Network S _P P S P P S S P Publisher S

Subscriber Virtual Switch

offer virtual Network resources

(67)

(68)

Outline

•

Motivation

•

Research Challenges & Conclusion

(69)

Approache Overview

Channelization

•

Form dynamically clusters

•

A separate flow is created for

each cluster

Filtering

•

Filtering of events within the switch network

•

Flows are created according to similarities between subscriptions and advertisements S₃ S₂ S₁ S₄ S₂ S₁ S₄ S₃ Queries _Cluster … … P S₁ S₂ S₇ S₆ S₆

(70)

Modeling Filters in OpenFlow

70

Map subscriptions and events to fields in a flow table

•

Events:

◦ Attribute value pairs

◦ Binary string for point in the multi-dimensional event space

•

Advertisement/Subscriptions:

◦ Binary string for a subspace

•

String generation based on Spatial Indexing

1 10 1010

(71)

What fields in a flow table to choose from?

Avoid conflicts with other Internet applications and protocols

In Port VLAN ID Ethernet IP TCP SA DA Type SA DA Proto Src Dst

•

Cannot overwrite whole IP-address range

•

Restriction to parts of Multicast ranges (our target to improve)

•

IPv6 (

ff0e::/8)

•

E.g. Prefix of 28bits leaves

•

100 bits for encoding advertisements,

subscriptions and events

(72)

How it works

Subscription/Advertisement

1.

Any new subscription/ advertisement is send to IP_fix

2.

Controller optimizes topology:

◦

establishes path to all covered subscribers

Sending event:

•

Encode event accodring: Ip_prefix ∘ Bitstring

(73)

(74)

Latency dependent on number of suberiber

74

Measured with OpenVSwitches in Data Center Topology

(75)

Conclusion and challenges

•

We have shown that it is possible to map content routing to OpenFlows

◦

Contribute both bandwidth reduction

◦

Responsiveness of event-based applications

▪ Switching cost < 4

•

Many research challenges remain

◦

Minimizing flow table size

◦

Scalable controller, decentralized control and coordination

◦

Correct operation and verification

◦

Quality of Service (QoS)

◦

Virtual network abstractions

(76)

Testing, Implementation, and Evaluations

(77)

Overview

1.

2.

Introduction to Software-Defined Networks (SDN)

3.

4. ◦

Evaluation goals

◦

Evaluation methodology

◦

Setup & Initial Experience

(78)

SDN Evaluation

Typical Evaluation Goals:

•

Bandwidth Utilization

•

False positive/ False negative rate

•

Throughput

•

End-to-end latency

•

Control overhead

•

Reconfiguration time

(79)

Testing and evaluation methods

Possibilities:

•

Simulation

•

Emulation

(80)

Simulation

•

Many network simulation tools are available

◦

NS3, OMNET, …

•

Alllow to define large-scale topologies

◦

Learn about bandwidth utilization of a concrete network topologies

•

Integration of controller not straight forward

◦

Own controller

•

Hard to evaluate latency related requirements

◦

E.g. effects of control in combination with low latency data for

•

Controller can later not be utilized for real-world software

◦

That‘s why we aimed for a simple programming interface

(81)

Emulation

•

Network emulation

◦

Execute protocols as if in a real environment

◦

Time-scale for execution can be longer

•

OpenFlow supported by Mininet

◦

Can model explicit interactions with the controller

◦

Ideal for testing control logic

•

Drawbacks:

◦

Not suitable for throughput and end-to-end latency

◦

Not suitable to measure reconfiguration time

(82)

Testbed

Best to understand real-world scenarios

•

Requires

◦ Investment in hardware

◦ Building up a physical topology of switches

•

Hardware determines

◦ Number of flows

◦ Support for IPv4 vs IPv6

◦ Switch performance

•

Topology

◦ Depends on use-cases, e.g. Data Center

◦ May restrict generality of results

◦ Hard to dertermine scalable scenarios

(83)

Design of testbed

•

Significant investment:

◦

ca 40.000€ for small data center topologies

•

Alternative external providers of testbed

◦

European Euphelia Testbed

◦

At lower cosr

(84)

Universität Stuttgart IPVS Research Group Distributed Systems 84 Switch Host … Frontend OpenFlow controller Topology manager VM manager 4-port NIC Client Host Open vSwitch

Patch panel switch

(managed switch (48 x 1 Gbps port)

VM VM VM VM

4-port NIC

12 hosts (PCs)

Overview Stuttgart Testbed

• Build on comodity hardware

◦ 12 PCs : hosts and vSwitch

◦ Patch panel switch: connectivity between hosts and vSwitches

(85)

Client Host Client Host

VM VM VM VM VM VM VM VM

OF controller (on frontend)

control network

Switch Host

Switch Host Switch Host

Switch Host Switch Host Switch Host Switch Host

links through patch-panel switch

(86)

Universität Stuttgart IPVS Research Group Distributed Systems 86

Role of a controler

Determines

• Programming language to write controller

• Supports in aggregating statistics

Many controller implementations are available

• Floodlight (currently most stable)

◦ Java, Python, HTTP/Rest

• Daylight

◦ The potential successor

(87)

Many Counters for statistics

Supports many things you want to find out to optimize routes: e.g.

- Number of bytes per flow,

- Number of bytes and dropped messages per port - Link utilization and find bottlenecks

- Errors (e.g., CRC checksum errors) - Find and avoid “bad” links

(88)

Summary

SDN most likely more than a hype:

•

SDN provides high flexibility to program networked applications

•

Industry is investing significantly in OpenFlow

•

High potential to improve performance of event-based systems

◦

delays for delay sensitive applications

•

Many interesting research problems

◦

Efficient and consistent control algorithms

◦

Optimization

◦

Design, Modeling and verification

◦

Network abstractions

(89)

Questions?

Muhammad Adnan Tariq, Boris Koldehofe, Gerald Koch, and Kurt Rothermel. Distributed spectral cluster management: A method for building dynamic publish/subscribe systems. In Proceedings of the 6th ACM International

Conference on Distributed Event-Based Systems (DEBS 2012).

M. Adnan Tariq, Boris Koldehofe, Gerald Koch, Imran Khan, and Kurt Rothermel. Meeting subscriber-defined QoS constraints in

publish/subscribe systems. In Journal on Concurrency and Computation: Practice and Experience, John Wiley & Sons, Inc., 2011

Boris Koldehofe, Frank Dürr,Muhammad Adnan Tariq and Kurt Rothermel. The Power of Software-defined Networking: Line-rate Content-based Routing Using OpenFlow. In Proceedings of the 7th MW4NG Workshop of the 13th For more info:

http://www.ipvs.uni-stuttgart.de/abteilungen/vs/forschung/projekte/sdn