Efficient topology discovery in OpenFlow-based Software Defined Networks
Introduction
Software Defined Networking (SDN) is a new networking paradigm, which has recently gained tremendous momentum, both in terms of commercial activity as well as academic research [1], [2], [3].
One of the key concepts of SDN is the separation of the data plane from the control plane. This is in contrast to traditional IP networks, where routers perform both packet forwarding (data plane) and run routing protocols, which discover network paths and make routing decisions (control plane). In SDN, control “intelligence” is removed from the forwarding elements (routers, switches), and concentrated in a logically centralised entity called the SDN controller, implemented in software1 [4], [5], [6], [7].
Logical centralisation of control does not necessarily imply physical centralisation, which can result in scalability and reliability problems, since the SDN controller would represent a single point of failure. To address this issue, researchers have proposed physically distributed SDN controllers, such as the Onix system [8].
Via the centralisation of network control, SDN essentially does away with traditional distributed network protocols. As a result, SDN forwarding elements, in the following simply referred to as switches, can become simpler and cheaper than traditional routers, and network configuration and management is significantly simplified [4], [5], [7], [9].
With SDN, the network becomes much more programmable and enables a higher rate of innovation. New network services, applications and policies can simply be implemented via an application running on the controller, which controls the forwarding elements (data plane) via appropriate abstractions and a well defined API, such as OpenFlow [10]. By installing the appropriate rules, a controller application can program SDN switches to perform a wide range of functionality, such as routing, switching, firewalling, network address translation, load balancing, etc. This can be done at different layers of the protocol stack.
Another critical benefit of SDN is its ability to facilitate network virtualisation, e.g. via tools such as FlowVisor [11] or OpenVirteX [12], which is essential in many deployment scenarios, in particular in data centre applications. These and other benefits of SDN have resulted in a great amount of recent industry traction, with many established and new vendors offering an increasing number of SDN enabled switches and other devices, as well as a range of SDN controller platforms.
Fig. 1 shows a logical view of the basic SDN architecture [13]. At the bottom is the infrastructure layer, consisting of a set of interconnected forwarding elements, i.e. SDN switches, which provide the data plane functionality. Switches can be both hardware devices, or software based, virtual switches, such as Open vSwitch [14].
The next layer up is the control layer, consisting of a logically centralised, software based SDN controller. One of the key roles of the controller is to provide and maintain a global view of the network. The SDN controller provides this view as an abstraction to the application layer, hiding a lot of the complexity of maintaining and configuring a distributed network of individual network devices. Topology discovery, the focus of this paper, is an essential service provided by the SDN control layer. The SDN controller is responsible for managing and configuring the individual SDN switches by installing the appropriate forwarding rules. The interface between the control layer and the infrastructure layer is often referred to as the southbound interface. The most prominent southbound interface standard is OpenFlow [10], [15], which we will assume and use in this paper. Section 2 will provide some more details on OpenFlow that are relevant for our discussions later in the paper.
The top layer in the SDN architecture is the application layer, where high level network policy decisions and services such as routing and traffic engineering are defined and implemented. The interface between the application layer and the control layer is called the northbound interface. However, in contrast to the southbound interface, the definition of a standard for the northbound interface is still very much a work in progress [16].
In this paper, we focus on topology discovery, which is a critical service provided at the control layer of the SDN architecture, and which underpins the centralised configuration and management in SDN. The contribution of the paper includes an analysis of the overhead of the current de facto standard for SDN topology discovery. We further propose an improved version and implement two variants of the basic idea. Our improved method achieves the same functionality, while reducing both controller CPU load and control traffic overhead by up to 40%. We present experimental results which demonstrate this. The work presented in this paper is an extension of previously published initial and preliminary work by the same authors [17].
As a basis for our following discussions, Section 2 provides the relevant background on OpenFlow. Section 3 discusses the current state-of-the-art approach to topology discovery in SDN, and Section 4 presents our proposed new approach. Sections 5 and 6 present evaluation results, and Section 7 provides concluding remarks.
Section snippets
Background – OpenFlow
OpenFlow [15] is a protocol that provides the SDN southbound interface, i.e. the interface between control layer and the infrastructure layer in Fig. 1. In practical terms, OpenFlow provides a communications interface between the SDN controller and SDN switches, which allows the controller to configure and manage the switches [4], [5], [7].
While there are other protocols proposed and employed as the southbound interface, such as SNMP, BGP, PCEP, etc. [18], OpenFlow promoted by Open Network
SDN topology discovery – current approach
In order for an SDN controller to be able to manage the network and to provide services such as routing, it needs to have up-to-date information about the network state, in particular the network topology. Therefore, a reliable and efficient topology discovery mechanism is essential for any Software Defined Network.
To be precise, when we refer to topology discovery in the following, we are really concerned with connectivity discovery or link discovery. An SDN controller does not need to
Proposed improvement – OFDPv2
The goal of OFDPv2 is to reduce the overhead of the topology discovery mechanism by reducing the number of control messages that need to be sent by the controller. The basic idea is simple. Instead of creating a unique LLDP packet for each port of each switch, and sending each such packet to the corresponding switch via a separate OpenFlow Packet-In message, as is the case in OFDP, we create and send only a single LLDP packet to each switch. We further provide instructions to the switch to
Evaluation
We have implemented both variants of our proposed topology discovery mechanism (OFDPv2) in Python on the POX SDN controller platform [23]. Our implementation is based on discovery.py, POX’s implementation of OFDP, which we also used as a benchmark for comparison. The source code of our implementation is available via github, for both OFDPv2-A [29] and OFDPv2-B [30].
We performed extensive tests for a wide range of network topologies, to establish the functional equivalence of OFDP and OFDPv2.4
Testbed validation
To further validate our emulation results based on Mininet, we have conducted a range of experiments on the OFELIA [36], [37] SDN testbed. OFELIA is a federated, OpenFlow-based SDN testbed distributed across a number of sites, or islands, in a number of European countries, including the UK, Switzerland, Germany, Belgium, Spain and Italy. At the time of performing our experiments, OFELIA consisted of 10 islands, each equipped with a range of SDN hardware switches, supporting the OpenFlow 1.0
Conclusions
In this paper, we have addressed the issue of topology discovery in OpenFlow based Software Defined Networks. Topology discovery is a key component underpinning the logically centralised network management and control paradigm of SDN, and is a service provided by all SDN controller platforms. We have discussed OFDP, the current de facto standard for SDN topology discovery, implemented by most, if not all, key SDN controller platforms. We have analysed the overhead of OFDP in terms of the
References (40)
- Open Flow Standard version 1.4 URL...
- et al.
Implementing an OpenFlow switch on the NetFPGA platform
Proceedings of the 4th ACM/IEEE Symposium on Architectures for Networking and Communications Systems
(2008) - N. McKeown, Software-defined networking, INFOCOM Keynote Talk, 2009, URL...
- et al.
The road to sdn
Queue
(2013) - Open Networking Foundation. URL https://www.opennetworking.org (accessed...
- et al.
Software-defined networking: a comprehensive survey
Proc. IEEE
(2015) - et al.
Improving network management with software defined networking
IEEE Commun. Mag.
(2013) - et al.
A survey of software-defined networking: past, present, and future of programmable networks
IEEE Commun. Soc.
(2014) - et al.
A survey on software-defined network and openflow: from concept to implementation
IEEE Commun. Surv. Tutor.
(2014) - et al.
Onix: a distributed control platform for large-scale production networks
Symposium on Operating Systems Design and Implementation, OSDI
(2010)
B4: experience with a globally-deployed software defined wan
SIGCOMM Comput. Commun. Rev.
Openflow: enabling innovation in campus networks
ACM SIGCOMM Comput. Commun. Rev.
Openvirtex: a network hypervisor
Proceedings of Open Networking Summit, ONS
Software-Defined Networking: The New Norm for Networks, White paper
Software defined networking: state of the art and research challenges
Comput. Netw.
Efficient topology discovery in software defined networks
Proceedings of the 8th International Conference on Signal Processing and Communication Systems, ICSPCS
Cited by (91)
Artificial intelligence based load balancing in SDN: A comprehensive survey
2023, Internet of Things (Netherlands)HyPASS: Design of hybrid-SDN prevention of attacks of source spoofing with host discovery and address validation
2022, Physical CommunicationExtended indirect controller-legacy switch forwarding for link discovery in hybrid multi-controller SDN
2022, Computer CommunicationsCitation Excerpt :Hussain et al. [14], proposed a Broadcast based Link Discovery (BBLD) scheme which required a single Pout to unearth the complete link discovery in SDN. Hasan et al. [22] studied the re-transmission events which might occur if the packets are lost between controller and OpenFlow Switch (OFS) and based its observation on [12]. The works focused on handling the security issues are by Nehra et al. [15] and Azzouni et al. [16].
Topology-Aware Cognitive Self-Protection Framework for Automated Detection and Mitigation of Security and Privacy Incidents in 5G-IoT Networks
2023, Proceedings - International Conference on Network Protocols, ICNP