Efficient topology discovery in software defined networks Farzaneh Pakzad, Marius Portmann, Wee Lum Tan, Jadwiga Indulska ABSTRACT Software Defined Networking (SDN) is a new networking paradigm, with a great potential to increase network efficiency, ease the complexity of network control and management, and accelerate the rate of technology innovation. One of the core concepts of SDN is the separation of the network's control and data plane. The intelligence and the control of the network operation and management, such as routing, is removed from the forwarding elements (switches) and is concentrated in a logically centralised component, i.e. the SDN controller. In order for the controller to configure and manage the network, it needs to have up-to-date information about the state of the network, in particular its topology. Consequently, topology discovery is a critical component of any Software Defined Network architecture. In this paper, we evaluate the cost and overhead of the de facto standard approach to topology discovery currently implemented by the major SDN controller frameworks, and propose simple and practical modifications which achieve a significantly improved efficiency and reduced control overhead. We have implemented our new topology discovery approach on the widely used POX controller platform, and have evaluated it for a range of network topologies via experiments using the Mininet network emulator. Our results show that our proposed modifications achieve an up to 45% reduction in controller load compared to the current state-of-the-art approach, while delivering identical discovery functionality. Fulltext : http://ieeexplore.ieee.org/xpl/articleDetails.jsp?tp=&arnumber=7021050&queryText%3DEfficient+topology+discovery+in+software+defined+networks

1. 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 Pakzad
8th International Conference on Signal Processing and Communication Systems
15 - 17 December 2014, Gold Coast, Australia
1

2. Overview
• Background
• SDN Topology Discovery
– State of the art
– Improved version
• Experiments
• Conclusion
2

3. Logical view of
Software Defined Networking (SDN)
Architecture
3
Topology
Discovery

4. 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

5. 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

6. SDN Topology Discovery
Topology Discovery Frame structure
Chassis
ID
TLV
port
ID
TLV
Time
To Live
TLV
Optional
TLVS
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

7. OFDP
Port 1
Port 2
Port 3
7
S1-port1---S2-port3
Port 1
Port 2
Port 3
 Controller creates individual LLDP packets
for each port of each switch
LLDP pkt
Chassis ID = s1
Port ID = Port 1
LLDP pkt
Chassis ID = s1
Port ID = Port 3
LLDP pkt
Chassis ID = s1
Port ID = Port 2

8. 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

9. 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 data
and 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

10. Our proposed improvement: “OFDPv2”
Port 1
Port 2
Port 3
10
Port 3
Port 2
Port 1
S1-port1---S2-port3
Ethernet Frame
Src MAC addr = Port 3
LLDP pkt
Chassis ID = s1
Ethernet Frame
Src MAC addr = Port 1
LLDP pkt
Chassis ID = s1
Ethernet Frame
Src MAC addr = Port 2
LLDP pkt
Chassis ID = s1
What about rewriting the packet headers!?
In particular, rewrite the source MAC address of the outgoing
Ethernet frame. (Controller can map MAC addresses to Port
Numbers)

11. 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

12. 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

13. Experiment Results
Number 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 msgs
OFDP
# control msgs
OFDPv2
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

14. 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

15. Controller CPU load
15
Reduction of CPU time and load ranging from a minimum
of 35% for Topology 2 up to 45% for Topology 1

16. 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. 17