efficient topology discovery in software defined networks
TRANSCRIPT
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