Efficient Topology Discovery

in Software Defined Networks

Farzaneh Pakzad, Marius Portmann, Wee Lum Tan,

and Jadwiga Indulska

School of ITEE, The University of Queensland

Brisbane, Australia

Presented by Farzaneh Pakzad8th International Conference on Signal Processing and Communication Systems15 - 17 December 2014, Gold Coast, Australia

1

Overview

• Background

• SDN Topology Discovery

– State of the art

– Improved version

• Experiments

• Conclusion

2

Logical view of Software Defined Networking (SDN)

Architecture

3

Topology Discovery

OpenFlow

4

Topology discovery provides and maintains a global view of the network

Topology discovery underpins the logically centralized network management and configuration

Topology Discovery

SDN Topology Discovery - State of the art

• Controller performs Topology Discovery

• OFDP = OpenFlow Discovery Protocol– Implemented by most SDN controllers de facto

standard

– OFDP leverages the packet format of LLDP

– OFDP operates completely differently

• LLDP = Link Layer Discovery Protocol– IEEE 802.1AB

– Used in traditional Ethernet network devices

5

SDN Topology DiscoveryTopology Discovery Frame structure

ChassisID

TLV

portID

TLV

Time To Live

TLV

OptionalTLVS

END of LLDPDU

6

LLDP Data Unit (LLDPDU)

Ethernet Frame

LLDP information is sent by devices in the form of an Ethernet frame. Each frame contains one LLDP Data Unit (LLDPDU) Each LLDPDU is a sequence of type-length-value (TLV) structures.

LLDP Type

OFDP

Port 1

Port 2

Port 3

7

S1-port1---S2-port3

Port 1

Port 2

Port 3

Controller creates individual LLDP packetsfor each port of each switch

LLDP pkt

Chassis ID = s1Port ID = Port 1

LLDP pkt

Chassis ID = s1Port ID = Port 3

LLDP pkt

Chassis ID = s1Port ID = Port 2

Idea: reduce the number of packet-Out

Port 1

Port 2

Port 3

8

Port 1

Port 2

Port 3

Controller load and performance is critical for the scalability of SDN

Reduction the number of packet-Out from each port of every switch to one per switch

Ask the switch to send the packet on all its ports

The Problem

Port 1

Port 2

Port 3

9

Port 1

Port 2

Port 3

Can we instruct the switch to rewrite the LLDP Port ID TLV on-the-fly !?

The answer is OpenFlow switches do not support access to packet payload dataand rewriting of that…

LLDP pkt

Chassis ID = s1

Port ID = Port 1

LLDP pkt

Chassis ID = s1

Port ID = Port 1

LLDP pkt

Chassis ID = s1

Port ID = Port 1

Our proposed improvement: “OFDPv2”

Port 1

Port 2

Port 3

10

Port 3

Port 2

Port 1

S1-port1---S2-port3

Ethernet FrameSrc MAC addr = Port 3

LLDP pktChassis ID = s1

Ethernet FrameSrc MAC addr = Port 1

LLDP pktChassis ID = s1

Ethernet FrameSrc MAC addr = Port 2

LLDP pktChassis ID = s1

What about rewriting the packet headers!?In particular, rewrite the source MAC address of the outgoingEthernet frame. (Controller can map MAC addresses to Port

Numbers)

Implementation

• POX as our SDN controller platform

• Implement OFDPv2 based on OFDP - topology

discovery module - in POX and also use it as a benchmark

11

Experiments

• Goal:– Measure the controller overhead reduction of OFDPv2 vs.

OFDP • In terms of the number of control messages

• In terms of the controller CPU load

• Methodology– Mininet: Linux based network emulator

• Allows creation of arbitrary virtual networks

• In-built support for SDN

– Considered 4 different topologies

12

Experiment ResultsNumber of Packet-Out control message

Topology #Switches #ports

Topology 1 Tree, d =4, f=4 85 424

Topology 2 Tree, d =7, f=2 127 380

Topology 3 Linear, N=100 100 298

Topology 4 Fat Tree, K=4 20 80

# control msgsOFDP

# control msgsOFDPv2

Efficiency Gain (G)

Topology 1 424 85 80%

Topology 2 380 127 67%

Topology 3 298 100 67%

Topology 4 80 20 75%13

A great reduction in the number of Packet-Out control messages

Controller CPU load

• Controller load is critical for any SDN application and is a key factor for network scalability and performance

• Second experiment explores CPU load imposed by both OFDP and OFDPv2

• We measure cumulative CPU time consumed by POX topology discovery service, over a period of 300 seconds

14

Controller CPU load

15

Reduction of CPU time and load ranging from a minimumof 35% for Topology 2 up to 45% for Topology 1

Conclusions• Topology discovery is a key service provided by all SDN

controllers

• We proposed improved topology discovery mechanism for OpenFlow based SDNs

• Reduction in controller overhead, in terms of:– Number of control messages (packet-Out)– CPU load on SDN controller (up to 45%)

• Increased controller efficiency– Increased network performance– Increased network scalability

16

17