Elsevier

Computer Communications

Volume 77, 1 March 2016, Pages 52-61
Computer Communications

Efficient topology discovery in OpenFlow-based Software Defined Networks

https://doi.org/10.1016/j.comcom.2015.09.013Get rights and content

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, are removed from the forwarding elements (switches) and are 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 efficiency 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 as well as a specific topology in the OFELIA SDN testbed. Our results show that our proposed modifications achieve an up to 40% reduction in controller load compared to the current state-of-the-art approach, while delivering identical discovery functionality.

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...
  • J. Naous 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...
  • N. Feamster et al.

    The road to sdn

    Queue

    (2013)
  • Open Networking Foundation. URL https://www.opennetworking.org (accessed...
  • D. Kreutz et al.

    Software-defined networking: a comprehensive survey

    Proc. IEEE

    (2015)
  • H. Kim et al.

    Improving network management with software defined networking

    IEEE Commun. Mag.

    (2013)
  • B.N. Astuto et al.

    A survey of software-defined networking: past, present, and future of programmable networks

    IEEE Commun. Soc.

    (2014)
  • F. Hu et al.

    A survey on software-defined network and openflow: from concept to implementation

    IEEE Commun. Surv. Tutor.

    (2014)
  • T. Koponen et al.

    Onix: a distributed control platform for large-scale production networks

    Symposium on Operating Systems Design and Implementation, OSDI

    (2010)
  • S. Jain et al.

    B4: experience with a globally-deployed software defined wan

    SIGCOMM Comput. Commun. Rev.

    (2013)
  • N. McKeown et al.

    Openflow: enabling innovation in campus networks

    ACM SIGCOMM Comput. Commun. Rev.

    (2008)
  • R. Sherwood, G. Gibb, K.-K. Yap, G. Appenzeller, M. Casado, N. McKeown, G. Parulkar, Flowvisor: A Network...
  • A. Al-Shabibi et al.

    Openvirtex: a network hypervisor

    Proceedings of Open Networking Summit, ONS

    (2014)
  • Open Networking Foundation

    Software-Defined Networking: The New Norm for Networks, White paper

    (2012)
  • Open vSwitch URL http://openvswitch.org (accessed...
  • Open Flow Standard URL https://www.opennetworking.org/sdn-resources/onf-specifications/openflow (accessed...
  • M. Jammal et al.

    Software defined networking: state of the art and research challenges

    Comput. Netw.

    (2014)
  • F. Pakzad et al.

    Efficient topology discovery in software defined networks

    Proceedings of the 8th International Conference on Signal Processing and Communication Systems, ICSPCS

    (2014)
  • OpenDaylight URL http://www.opendaylight.org/project/technical-overview (accessed...
  • Cited by (91)

    • Extended indirect controller-legacy switch forwarding for link discovery in hybrid multi-controller SDN

      2022, Computer Communications
      Citation 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].

    View all citing articles on Scopus
    View full text