investigating the impact of network topology on the processing times of sdn controllers

Institute of Computer ScienceChair of Communication Networks

Prof. Dr.-Ing. P. Tran-Gia

Investigating the Impact of Network Topology on the Processing Times of SDN Controllers

Christopher Metter, Steffen Gebert, Stanislav Lange, Thomas Zinner, Phuoc Tran-Gia, Michael Jarschel*

www3.informatik.uni-wuerzburg.de

* Nokia GmbH, Munich

Steffen Gebert2Impact of Network Topology on the Processing Times of SDN Controllers

Metadata

u This paper was presented at the “The Seventh IFIP/IEEE International Workshop on Management of the Future Internet” (ManFI), colocated with IM`2015 in Ottawa, Canada.

u http://manfi.org

u Paper author version:http://www3.informatik.uni-wuerzburg.de/staff/steffen.gebert/author_versions/conf_510_author_versions.pdf


Motivation – SDN Architecture

Data PlaneData Plane

C

D

C

D

Control Plane


Impact of Controller Implementations on Message Processing Times

u Analysis of processing times for a L2 learning switch§ Switching modules of OpenDayLight (ODL) and Ryu§ Packet-in/packet-out pairs

– e.g., in case of unconnected switches or requests for non-reachable destinations

§ Packet-in-packet-out/flow-mod pairs– e.g., to set a forwarding path in the flow table to a certain destination

u Topology emulation and packet-in traffic generation§ Controlled, low-rate traffic emulation to reduce waiting times§ Impact of network topology on the service times

– Unconnected topology (baseline)– Fat-tree topology (data center)– WAN topologies (261 topologies from the Internet Topology Zoo)


OFCProbe

github.com/lsinfo3/ofcprobe

u Controller performance analysis tool§ Emulation of virtual OpenFlow-enabled switches§ Generate OF messages per switch§ PCAP file playback§ Configurable payload IAT distributions§ Per-switch statistics collection

C


Topology Discovery

u Switches are configured to connect to the controlleru Controller has no information about links between switches

??

?1

2

3

C


?

Topology Discovery

u Controller injects LLDP packets (Link Layer Discovery Protocol)u Switches flood them to all ports

?

LLDP

LLDP

PacketOut(flood)

LLDP

?1

2

3

C


C

Topology Discovery

u Other switches receive packets and report packet-in to controlleru Controller learns topology from information about incoming ports

?

PacketOut(flood)

LLDPPacketIn(port 7)

LLDP

PacketIn(port 2)

LLDP

Switch Port To Switch2 2 1

3 7 1

1

2

3

2

7


Processing Steps of a Controller for Packet-Ins

1. Data reception2. Decoding of OpenFlow message and classification3. Attribute extraction and delegation to application module4. Module-specific processing 5. Response generation (e.g., packet-out / flow-mod message …)6. Data transmission

Impact of controller implementation on module-specific processing?


Controller

C

Baseline Topology

u 20 switches, 1 host per switch, no connections between switches

u Resulting action in packet-out message: flood


Baseline Performance

u Emulated switches generate 16 packet-ins one after anotheru Controller responds with packet-out message

u Periodic behavior in response times (per switch)u Higher variation of processing times for ODL (JVM?)u ODL outperforms Ryu


C

u 20 switches, represents data center topology

Fat-Tree


Packet-Out: Fat-Tree

u Bursts of 16 packets are sent from one host to another

u Increased processing times compared to unconnected switchesu Similar average processing times, but high variation and outlierswhen using ODL


Flow-Mod: Fat-Tree

u Flow-mods by utilizing Layer 2 learning switch module

u Processing times for flow-mods 2-8 times higher than packet-outsu ODL processing times stabilize after ~20 secondsu Ryu has nearly constant processing times and outperformsODL


u Experiment performed on 261 WAN topologiesu CDF shows all measured processing times

u Ryu: Topology has no effect on processing times, flow-modprocessing slightly slower than packet-out processing

u ODL: High variation for packet-out, flow-mods significantly longer

Internet Topology Zoo – Aggregated Results


Topology Investigation

u Analysis of the topology impact on the processing times

u Ryu: rather constant behavior, similar processing times for flow-mods and packet-outs

u ODL: high impact of message type, varying processing times


u Investigation of controller processing times§ Emulated different network topologies using OFCProbe§ Time measurements done directly within the controllers§ Using Layer 2 switch modules (as starting point)

u Benchmarking results:§ Ryu shows very constant response times§ ODL faster for packet-out, Ryu for flow-mod

u Main take-aways:§ Test your own forwarding algorithms using different topologies!§ OFCProbe now allows importing GraphML topologies§ Measurement probes available for ODL and Ryu controllers1

1 source code on github.com/lsinfo3 (manfi2015-perf-* repos)

Summary


OFCProbe Architecture

OF Controller

Best Effort Traffic Generator

OpenFlow Connection Handler Module

Configuration

Communication Layer

Traffic Generation Layer Traffic Generation Module

Statistics

Statistics: PPS Module

Statistics: RTT Module

Statistics: Custom Module

Interface

ConfigurationPacketsStatistics

Implementation

Payload

OF Message

OF Reply

OF ReplyOF Reply

investigating the impact of network topology on the processing times of sdn controllers

Technology

topology discoveryu

modulespecific processing

controlleru controller

report packet

case of unconnected

ryu packetinpacket

reachable destinations

openflow message