DistributedSDN

1.Introduction

Here, we provide several functional modules in UbiFlow such as AP optimized allocation, overlay structure and flow collection.

• The eastwestcommunication provides the function of supporting Communication between controllers, by transferring and migrating traffic flows for mobile switching.
• The flowcollection provides the functions of collecting information of flowtables in the OpenFlow swithes in the SDN network. The flow entries in the flow table reflect current flow status of the IoT devices.
• The assignAP provides the function of assigning the optimal AP to the mobile IoT device according to capacity of AP, profit and demand of IoT device.
• The overlay provides the functions of eatablishing Chord ring, mobile handover when IoT moves in different areas, scalable controller when SDN controller node leaves(or breakdown) or joins the overlay network.
• The networkcalculus provides the functions of modeling the depart curve by depicting curve and service curve. The controller models the arrival curve through requesting the traffic from the switch ingress port at the edge of the network partition, and the service curve is customized according to the link rate.

2. Architecture of distributed SDN system

A multi-layer structure is adopted in the system prototype,as illustrated in Fig. In this architecture, the controllers are distributed in proximity to the network edge. The entire network is divided into several partitions to present different geographical areas. At the network edge, each IoT device is associated with heterogeneous APs based on the needs of flow types. The OpenFlow switches are connected with SDN controllers to provide high speed services with low latency. Because of the heterogeneity of APs and MDs, the southbound interface protocols are extended with middleware applications to handle network compatibility, so as to enable agile access and handover.

In the control plane, as each controller is responsible for a specific geographical area, it will have a local view of the network status. Information pertaining to service requests and flow transmissions are managed by the partition-dependent controllers. The flow requests and resource allocation are determined through coordinating these distributed controllers. Through the extension of east/westbound interface to support communications between controllers, distributed mobility management and access control can be achieved by exchange the information recorded by different controllers via connected switches. Therefore, above distributed SDN system architecture is able to meet the network availability and scalability needs in software defined Edge computing.

3.Implement

The implementation details are summarized as follows:

3.1 AP supporting wireless SDN

For practical implementation using our code, the Cisco Linksys WRT1900AC WiFi router could be used to play the role of OpenFlow switch. It has an OpenWrt system and supports for customized firmware. The source code of the Open vSwitch (OVS) needs to be downloaded to recompile the firmware of WRT1900AC to support the Southbound OpenFlow protocol. In addition, the interface configure files of WRT 1900AC are modified to make the IoT devices connect to it via OpenFlow. As WRT1900AC supports 2.4G and 5G WiFi, those WiFi interfaces are added to the OVS bridge to enable wireless access. Furthermore, heterogeneous AP based on the Linux kernel, and their functions can be expanded by software. For example, customized programs and scripts are deployed in AP to support encapsulating packets with radio access and spectrum information, and interacting with SDN controller or other network devices.The steps to support wireless SDN are as follows:

3.2 Build-in application in Floodlight Controller

In the control plane, Floodlight is used as the SDN controller, which is an enterprise-class, open source SDN controller and provides many fundamental modules for managing the network. The users can adopt RESTful API to call modules built in Floodlight or deploy their own modules according to functional requirements quickly and flexibly. We add customized modules flowcollection,eastwestcommunication and networkcalculus in Floodlight, to collect all the flow table information in the OpenFlow switches connected to the SDN controller, support simple communication between controllers and analyze the network status of a partition using a network calculus model respectively. The procedures of "How to add a REST API to a Module" in Floodlight controller are given in Official Document.Notice that, all custom modules need to be registered in the controller, this is done by adding the fully qualified module name on it's own line in src/main/resources/META-INF/services net.floodlightcontroller.core.module.IFloodlightModule. Then we tell the module to be loaded. We modify the Floodlight module configuration file to append the modules. The default one is src/main/resources/floodlightdefault.properties. The key is floodlight.modules and the value is a comma separated list of fully qualified module names. In addition, these modules need to be exposed in the form of REST so that external applications can use the RESTful API to call these interfaces to manage the network. "How to add a REST API to a Module" is given in this Document.

3.3 RESTful API supporting overlay structure

For simple and flexible purposes, we deploy overlay and assignAP program in application layer to call northbound API of controller instead of modules placed inside the controller. The overlay function can use the RESTful API to get mobility information of the IoT devices, and implement mobile handover.

NOTE:The current system is designed for a specific SDN switch(Cisco Linksys WRT1900AC WiFi router), the switch's configuration file does not apply to other switches. Next we will continue to improve the system to make it more versatile, and develop new applications.