16
Insights into Software-Defined Networking and Applications in Fog Computing

Osman Khalid, Imran Ali Khan, and Assad Abbas

Department of Computer Sciences, COMSATS University Islamabad, Abbottabad, Pakistan

16.1 Introduction

Software-defined networking (SDN) is an emerging implementation model for wired networking that decouples the data plane (system that forwards data to destination) from control plane (system that makes decision about where to send data). The aim of SDN is to simplify the network management. In traditional networks, the control and data planes are merged into the same networking device due to which the flexibility to accommodate new services is reduced. Moreover, devices manufactured by one vendor could not interoperate with the devices of other vendors. As a result the businesses were locked to a particular vendor specific hardware tool. SDN decouples data plane and control plane. With this separation the networking companies can use equipment from various vendors and can apply policies on the entire network. The switches are only used to forward data while the centralized SDN controller is used to implement control logic [1]. SDN provides multiple opportunities to traditional networks. The management of the network becomes efficient and easy with centralized control. These frameworks are well suited for end-to-end communication across different wireless technologies.

The Open Network Foundation (ONF) has defined architecture for SDN as illustrated in Figure 16.1. The ONF categorized SDN into three layers [2]:

  1. The application layer consists of various end-users' business applications that utilize the communication services of SDN. Northbound application programming interface (API) provides the connection between application layers and the control layer.
  2. The control layer controls the network forwarding decision through centralized logic.
    Architecture of software-defined network (SDN) categorized into three layers: The application layer consisting of various business applications; the control layer controls the network forwarding decision through centralized logic; and the infrastructure layer composed of multiple network nodes.

    Figure 16.1 Architecture of software-defined network (SDN). (See color plate section for the color representation of this figure)

  3. The infrastructure layer is composed of multiple network nodes. These nodes provide packet switching and forwarding from source to destination. OpenFlow communication protocol provides interaction between control layer and infrastructure layer. OpenFlow is the required interface for the SDN architecture.

To support sophisticated services in wireless frameworks, mobile operators should design devices that could manage growing traffic in these paradigms. Cellular interference in these frameworks is high due to small cell size. Mobile operators have to reuse frequency to increase capacity. Numerous wireless technologies 3G, 4G, Wi-Fi, and Bluetooth are being supported in today's mobile devices. To maintain a mechanism to migrate users from one technology to another is a challenging task. Seamless provision of services across different technologies is also a challenge for mobile operators. These challenges could be overcome by adding OpenFlow-based SDN communication protocol in wireless networks [2]. Centralized logic control in wireless SDN provides efficient collaboration of base stations and controller, hence avoiding inter-cellular interference. The logical centralized control in SDN has the potential to control any OpenFlow-based mobile nodes that are associated with any vendor. New network services and capabilities are expected to introduce quickly. This logical controller can also provide efficient use of resources, such as optimal use of the radio frequency spectrum. OpenFlow with SDN provides potentials to network operators to customize the behavior of the network. This makes efficient decisions of off-load flow to manage network traffic [3].

The use of SDN in mobile wireless networks not only simplifies networking but also provides simplicity in the deployment of protocol and application by providing collaboration between access points [1]. The use of multiple controllers provide the user with the flexibility to connect with any access point regardless of the operator it belongs to. Wireless SDN provides the flexibility of link sharing to network operators. For example, in case of sudden excessive traffic in a link the Internet service provider could off-load its traffic to other collaborative network technology. SDN monitoring mechanism also provides a clear vision of network activities. Any abnormal behavior could be recognized easily. Wireless SDN has the potential to provide user localization information even in the absence of GPS with the help of the controller that is collecting information from access points.

Besides these potentials, there are multiple challenges associated in wireless-based SDN networks (SDWN) [4]. Wireless networks have link separation challenges. SDN and OpenFlow were basically designed for wired networks and utilizing them in wireless infrastructures is difficult. Interference among the nodes is the main issue in these frameworks that limit the numbers of channels reused. The main types of interferences in these architectures are: (1) the receivers could not decode the signal due to physical interference because it is receiving some other strong signals, and (2) intrusion due to simultaneous transmission of multiaccess protocol [5]. Moreover, segmentation is required in wireless networks for isolation of communication channels to minimize interference between these segments. For wired and infrastructure networks, detachment of the link is simple by implementing different wavelengths in cables. In wireless networks, time synchronization (such as in time division multiplexing) and bandwidth wastage (in frequency division multiplexing) have to be taken care of. Load estimation on a wireless medium is handy due to the frequent change of state in the medium. Handling frequent handoff is another big challenge in implementing SDN. However, overall advantage of SDN dominates its challenges [1].

The rest of the chapter is organized as follows. Section 16.2 describes the OpenFlow protocol and architecture of OpenFlow switch. Section 16.3 outlines the different SDN-based research works. Section 16.4 surveys different state-of-art of SDN in fog computing. Section 16.5 discusses the applications of SDN in wireless mesh networks. Section 16.6 presents SDN in wireless sensor networks, and finally Section 16.7 concludes the chapter.

16.2 OpenFlow Protocol

OpenFlow is a standardized interface between the control and forwarding layers of SDWN architecture. ONF provides standards for OpenFlow [1]. It is the most common SDN interface manufactured by a number of vendors including IBM [6]. NOX, Floodlight, and Maestro are the examples of OpenFlow interface [6]. OpenFlow provides the integration of heterogeneous devices in a common way. It provides seamless subscriber mobility that works across different cellular technologies.

16.2.1 OpenFlow Switch

In SDN, OpenFlow switch is a hardware device used to forward packets. OpenFlow switch consists of OpenFlow secure channel, an external controller, and one or more flow tables. The basic function of OpenFlow switch is packet forwarding to the external controller. The switch management is performed by controller through OpenFlow protocol. The basic function of the controller is to add and remove flow entries from the flow table interface [6]. The controller performs the required operations, such as addition, deletion, and update, on the flow. The architecture of the OpenFlow switch is depicted in the Figure 16.2.

A set of flow entries is associated with every flow table in the switch. Every flow entry contains the following fields: (1) counters to notify against matching packets, (2) matching field to compare against packets. This consists of an entrance port and packet header with optional metadata provided by the previous table, and (3) instructions to apply to matching packets [7]. Matching of flow starts from the first flow table and proceeds to the next. The priority-based mechanism is used by flow entries. First, the matching entry in the table is found. After finding the matching entry, the associated commands with particular flow entry are performed. If no matching entry is found, then the packet may be dropped, or forwarded to the next flow table. Commands associated with each flow table indicate packet refinement, packet forwarding, pipeline computing, or group table computing. Pipeline computing allows instructions to the succeeding flow table for further executions. If the instruction set connected with a matching flow entry does not identify the next table, then the table pipeline computing is stopped. At this stage, the packets are either modified or forwarded. Packets may be forwarded to physical or virtual ports defined by the switch.

Image described by caption.

Figure 16.2 An OpenFlow switch communicate with controller over a secure connection using the OpenFlow protocol.

Group entries are part of group table. The capability for a flow to direct to a group empowers OpenFlow to use additional techniques of forwarding (e.g. multicast, broadcast). Each group entry consists of the following fields: (1) group identifier to uniquely identify a group, (2) group types, (3) counters that are updated after the processing of packets in group, (4) action buckets that contain the ordered list of actions. Each action bucket consists of some specific action to be executed.

The group types are named as: all group, select group, and indirect group. All group types process all buckets in the group and are used for broadcasting or multicast forwarding. Select group types process one bucket in the group. Indirect groups only process a single defined bucket in the group. The OpenFlow switch and controller are connected through an interface called OpenFlow channel. The controller manages the switch and receives messages from switch through this interface [6]. In the next section we present the research that applies SDN in the wireless environment.

16.3 SDN-Based Research Works

By using SDN in wireless networks, the control functionalities of network devices (base station [BS] and gateways) are migrated to centralized logical control. The centralized logical control enables the underlying physical infrastructure resources to be abstracted from global and dynamic traffic management. In this section, we discuss the existing SDN infrastructures with their strengths and weaknesses.

Costanzo et al. [3] have applied SDN on IEEE 802.15.4 low-rate wireless personnel area networks (LR-WPAN) to improve network efficiency and control management. Due to differences at the higher layers of protocol stack, the devices applying the same access technology cannot operate into another network in traditional technology. Such problems can be solved by the use of SDN, as the functionality performed at network and higher layers are controlled by a centralized controller (CC). The authors propose the protocol architecture for a sensor and actuator network based on LR-WPAN communication nodes with limited computational and energy capabilities [3]. The nodes consist of a micro-controller and transceiver. The network controller runs on a sink node, which in turn is connected to the embedded system. The proposed architecture is composed of generic node and sink node. All generic nodes form a peer-to-peer topology and run the basic physical and mandatory access control (MAC) layer functionalities of IEEE 802.15.4 standard. Packets from MAC layers are provided to the forwarding layer that identifies the type of the packets. The control packets are sent to network operating system (NOS), whereas the data packets are subjected to the required functionality of modification, broadcasting, and copying. A sink node's architecture is divided into two sublayers. The lower layer runs on the same type of hardware as that of generic node. The upper layer provides the additional high-level computational and communicational functionalities that are executed in the Linux base operating system. Devices and embedded systems are connected through communication interfaces like USB and RS232. The adaption layer in the embedded system is responsible for formatting messages. Besides the application layer, sink node consists of one or more controller(s) that implement network management. The topology information in 802.15.4 is collected by NOS. This information is needed by every node for communication with the sink node. Actions on the packets are performed according to packet format, which is described in the packet header. The proposed technique optimizes the system and shows effectiveness in the defined domain by utilizing lesser resources, and exhibits shorter response time for the end-users [3]. Moreover, the proposed system is generalized enough to allow customization. However, the security mechanism of the system is not that efficient and the system is not interoperable [8].

Sun et al. propose SDN wireless architecture for the next generation mobile communication (5G) to simplify the network management [9]. A multitier cloud controller architecture is designed for SDN based on 5G networks. The architecture of system prototype is based on OpenFlow interface. Proposed architecture is deployed with two basic entities: (1) edge controller (EC), which is used to process the event within a single network domain, and (2) global controller (GC), which processes the event within at least two heterogeneous networks. Event processing is implemented through online transaction processing (OTLP) and online analytical processing (OLAP). OTLP executes low-level events with real-time measurements. High-level events such as load balancing are performed through OLAP. Multiple virtual operators share the resources and network through network function virtualization (NFV) in SDWN-based 5G. OpenFlow data plane forwards the data packets. Two logical interfaces, security link (SSL) channel for event reporting and Simple Network Management Protocol (SNMP) for monitoring, are supported by the common Ethernet card. Cloud controller, OpenFlow switch, and network simulators are included in current prototype. For virtualization techniques, one GC and two EC are implemented in the cloud controller for this prototype. The extended monitoring of localization, energy management, topology discovery, and cloud radio reactive handover are the four new applications supported for the 5G network in this prototype. Software architecture for the controller and simulator consists of following layers: (a) the communication layer is responsible for message exchange function, (b) logical control layer performs the responsibility of wireless-related logic control functions, and (c) persistence layer provides user-friendly APIs and performs data operations. The messages and communication among the virtual switches, controller, and network simulator is modeled in Wi-simu-comm an OpenFlow wireless network simulator. The main contribution of the authors is the provision of global cloud radio access for 5G mobile infrastructures. In addition, the network status is monitored in real time. In case of network bottleneck or congestion at data, forwarding command is sent based on quality of service (QoS) parameters. The research proposed a layered cloud-based scheme having two components EC and GC for multiple controllers. The significance of this scheme is the balancing of load for cloud controller and reducing the response latency [10].

Sood et al. highlight the emergence of SDNs and describe the recent developments in the wireless environment to integrate SDN and Internet of Things (IoT) [11]. With the emergence of IoT, mobile networks will have to handle enormous data and increased network traffic with devices having limited bandwidth. IoT devices connect to serve heterogeneous applications where no single wireless standard could be enough. How to connect devices wirelessly to gain potentials of IoT is a challenging task. To cope with these types of challenges SDN is a good alternate to increase bandwidth of the networks. Information gathering, analysis of gathered information, decision making, and implementation have become simple by using SDN in IoT. The merging of SDN on IoT will provide the potential of exchanging bandwidth between users and devices and visibility of network resources. SDN smartly directs traffic with efficient use of network resources to prepare the network for massive data of IoT. Security and scalability are the main challenges in the integration of IoT with SDN. If hackers have the access to the controller they can attempt security breaches. A strong detection mechanism to detect malicious devices trying to access the network is necessary. In SDN, a logically CC controls the switch that evaluates each incoming packet. Each switch maintains a limited size of the flow table and could not scale beyond few hundred entries. The type and length of flow while planning scalability solutions is necessary. The larger the flow length, the more time is taken by the particular flow, hence there are more chances of collision and delay in WLAN networks. Therefore, IoT networks can be made more scalable with SDNs [11].

Managing, controlling, and evaluating a large number of access points (APs) in IEEE 802.11 WLAN frameworks is a challenging task. To overcome interference due to shared channels in wireless paradigms, the coordination between APs is necessary to increase performance. To address such issues, the authors proposed an SDN-based architecture where the management of APs is the responsibility of the access controller (AC) [12]. Communication between AC and AP is provided by Control and Provisioning of Wireless Access Point (CAPWAP) protocol that provides potentials for seamless roaming. In traditional networks, when a client leaves an AP range, the AP notifies the CC that directs the client to the new AP with the strongest signals. The new AP confirms the client's presence by four-handshake protocol. However, such handovers inculcate delays due to reconfiguration. Monin et al. describe a system that integrates SDN and WLAN to enable speedy roaming policy [12]. Roaming is started with a connection establishment between the client and new AP. The CAPWAP notifies SDN about the migration of client. The experimental results showed that SDN-based WLAN have 70% faster roaming than traditional frameworks with no additional delays.

Kumar et al. discuss the challenges of interferences among nodes that limit the numbers of channels being reused [5]. The authors propose SDN-based WLANs to cope with these kinds of interferences. The work also proposes a load-aware handoff algorithm for these infrastructures. The algorithm checks the signal intensity at wireless clients and reviews the state of congestion on APs. Load unbalancing among APs is resolved and seamless mobility is provided. The load on the network is periodically checked at the CC. To reduce delay between handoffs, Channel Switch Announcement (CSA) message in (Beacon) frames is used. The CC is the main component of the proposed SDN based WLANs. CC periodically records network traffic and reconfigures the network optimally. Assistive agent (AA) is another module of the defined architecture that is installed on AP. The AP communicates all necessary parameters (congestion on AP, load of each AP, handoffs) with CC. OpenFlow support is provided by integrating APs with Open vSwitch. Handoff decisions by CC are notified by the APs. CC measures load on APs. The described algorithm runs on CC. Initial signal thresholds' value on APs is fixed, then it is dynamically changed on APs depending on their congestion that provides good QoS. Network state provision and parameters for load-aware handoff decisions are challenging in these frameworks. Experimental results shows that in proposed algorithms, both static and mobile users could be associated with less loaded APs and cleverly utilize bandwidth of the network. The proposed architecture could also be efficiently implemented with multichannel WLANs frameworks.

Chaudet et al. describe the challenges and opportunities posed by SDN in wireless infrastructure [4]. Implementation of SDN is relatively easy in wired networks as compared to wireless frameworks that pose link separation challenges. SDN and OpenFlow were basically designed for wired networks and incorporating those in wireless infrastructures is difficult. Segmentation is required in wireless networks for isolation of communication channels to minimize interference between these segments. For wired and infrastructure networks, detachment of links is simple by implementing different wavelength in cables. Moreover, in wireless networks, time synchronization and bandwidth wastage have to be taken care of. Handling of frequent handoff is another challenge in implementing SDN.

Bernardos et al. illustrates the advantages of using SDN model to mobile wireless networks [1]. By referencing the 3GPP Evolved Packet System, the paper proposes an architecture of SDWN that is implemented by using two models: (1) Evolutionary Model: new model is developed by incrementing new strategies in the existing network, and (2) Clean State Model: using an API between virtual operator and SDN controller, control plane functions are directly programmed on the SDN controller.

A lot of effort has been put forward in SDN architecture implementation in multihop networks [13]. These multihop networks included wireless mesh networks (WMNs) and wireless sensor networks. In the next section we analyze the use of SDN in these multihop networks.

16.4 SDN in Fog Computing

In recent years, fog computing has emerged as a technology to augment cloud computing. The term fog computing was first coined by Cisco, and is aimed to bring the storage and computing resources closer to the end-user. Fog computing is suitable for the applications that require real-time response, e.g. real-time gaming, augmented reality, real-time healthcare, and traffic management. The same applications when run on the cloud may experience delays due to far-off deployment of cloud nodes and congestion on the backbone network. Despite its benefits, fog computing may face numerous challenges in managing heterogeneous devices, e.g. large numbers of IoT devices connected with fog [14]. SDN can be integrated into fog computing in order to increase network performance [15]. In SDNs, the network intelligence is moved to a logically centralized SDN controller, which maintains a global view of the network, interacts with data-plane devices, and provides a programming interface for network management applications. Using this concept, the SDN controllers are usually deployed along fog networks to orchestrate the traffic engineering and resource management more efficiently in a centralized manner by having insight into applications' requirements and available resources. This helps in alleviating resource contention in IoT environments and improves overall IoT performance. Besides fog orchestration, SDN controller performs traffic control by using OpenFlow and connectivity management for IoT devices. As the size of fog-enabled IoT platforms increases, efficient routing mechanisms are required in fog computing to forward the ubiquitous IoT data to related servers with low latency, low bandwidth, and/or high security. Therefore, SDN can be employed to optimize the routing process in fog-enabled IoT platforms.

In the subsequent text, we mention some of the existing researches on SDN-based fog computing.

Nobre et al. proposed an architecture combining fog computing and SDN for vehicular ad hoc networks (VANETs) [16]. An SDN controller is located in the middle of fog and cloud layers and is responsible for fog orchestration and resource management. A vehicular fog node downloads the global traffic conditions from cloud and uploads the local traffic conditions using network infrastructure, such as vehicle-to-vehicle V2V or vehicle-to-infrastructure V2I. The cloud controls the fog nodes in a centralized fashion. The SDN-enabled VANET architecture enables content dissemination to efficiently accommodate a large number of vehicular users with any kinds of communication technologies and devices.

Khan et al. proposed a hierarchical 5G next generation VANET architecture using SDN and fog computing framework [17]. The authors propose a fog computing framework with the control functionality of controllers divided in a hierarchical manner to reduce the overhead on the CC. This helps in reducing the transmission delay and overhead in the proposed framework.

The authors illustrate a fog node–based distributed blockchain cloud architecture for IoT in [17]. The architecture utilizes SDN and fog computing to implement a distributed security scheme based on block chaining. At the fog layer, the authors propose the use of blockchain-based distributed secure SDN controller network for the fog node. All the SDN controllers are connected in a distributed fashion at the fog node using block chaining. Each SDN controller has an analysis function and packet migration function to secure the network during attacks. The network edge is deployed with multi-interface BSs equipped with an SDN switch to facilitate IoT-based wireless communication technologies. The BS act as a forwarding SDN switch for the fog controller collecting data from IoT devices and forwards to fog node controller. Each fog node is composed of distributed SDN controllers and uses the blockchain technique to provide scalable, reliable, and high-availability services. In [14], Yoshigoe et al. propose the use of SDN to alleviate resource contentions in the IoT environment to improve overall performance of IoT.

As the size of the fog-enabled IoT platforms increases, the efficient routing mechanisms are also required to forward the ubiquitous IoT data to related servers with low latency, low bandwidth, and/or high security. SDN has been employed by several proposals to optimize the routing process in fog-enabled IoT platforms [18]. Okay et al. propose a hierarchical SDN-based fog computing architecture for routing in fog-enabled IoT platforms [18]. The SDN-based fog controllers take the decisions locally for frequent evens, whereas the cloud controller takes decision globally for less frequent events. The authors evaluated the performance of the proposed scheme by varying the number of controllers and results indicated that hierarchical SDN framework has the potential to reduce routing delay and data transmission overhead.

16.5 SDN in Wireless Mesh Networks

16.5.1 Challenges in Wireless Mesh Networks

WMN consists of a mesh of routers. Few of these routers are connected to gateways. Mobile clients that are not connected to the Internet must route their traffic between mesh routers to reach gateway-connected routers. As there are only a limited number of routers that are providing Internet access, a bottleneck situation may arise. There is a need of routing the traffic to alternate gateways and routers to avoid congestion. In addition, mesh routers are configured in ad hoc mode and lack global knowledge of the network. Therefore, they provide poor performance of network resource allocation.

16.5.2 SDN Technique in WMNs

SDN can handle the aforementioned challenges in WMNs. Mesh routers in SDN architecture are OpenFlow enabled [19]. SDN provides simplified network management with the help of a global view of the WMN. It decouples the data plane and control plane as shown in Figure 16.3. Separation of data and control traffic is achieved via dividing the wireless spectrum. There is a logical CC that constitutes the rules for data forwarding. Actual data forwarding is performed by numerous SDN mesh routers. Rules from the controller can be simple or complex. Simple rules match the incoming packet's port number while complex rules match MAC address for each packet. There are several benefits of a CC as in SDN over a distributed one but some parameters can also be compromised. Table 16.1 summarizes that SDN-based CC provides more flexibility to implement new services in WMNs and load balancing is achieved with this controller to avoid traffic congestion. However, at the same time SDN controller–based WMN requires a way for fault tolerance in case of failure. This suggests that distributed controller paradigm provides more reliability.

Architecture of SDN-based wireless mesh network, which decouples the data plane and control plane achieved via dividing the wireless spectrum.

Figure 16.3 Architecture of SDN-based wireless mesh network.

Table 16.1 Comparison between centralized and distributed controller.

Flexibility Reliability Global view of network Complexity Efficient response time Cost Load balancing Control traffic congestion
Centralized controller Yes No Yes No No No Yes Yes
Distributed controller No Yes No Yes Yes Yes No No

Three algorithms are proposed by Huang et al. that divide and assign the spectrum for data and control traffic to avoid congestion [13]. These algorithms are called Fixed-Band Non-Sharing (FB-NS) algorithm, Non-Fixed Band Non-Sharing algorithm (NFB-NS) and Non-Fixed-Band Sharing (NFB-S) algorithm. In FB-NS algorithm, the radio spectrum is divided in subbands. A fixed fraction of all subbands is allocated to control traffic. Whereas the remaining subbands are used to transmit data traffic. Fixed subband allocation in the FB-NS algorithm can lead to poor resource utilization. To overcome this problem another algorithm is proposed, called NFB-NS. In this algorithm, number of subbands can be selected freely, as per the need for data and control traffic; however, control traffic is given more priority. In addition, both the control and data traffic cannot share the same link, even if there is a remaining capacity in one of the links. This scenario decreases the spectrum utilization. To overcome this situation, NFB-S algorithm is introduced. It suggests that data traffic can be transmitted in same subband of control traffic if there is still some remaining capacity. Performance of all three algorithms is evaluated and compared. It is clear from the results that NFB-S algorithm has the highest throughput as compared to others, due to maximum utilization of spectrum and flexibility. However, there is also some overhead of its complex implementation.

16.5.3 Benefits of SDN in WMNs

Major contributions of SDN in WMNs are better mobility management and efficient allocation of resources. With flexible routing, load balancing is achieved and client mobility is made more efficient. In the Mesh Flow project, the authors introduced SDN-based mesh routers [20]. These mesh routers have multiple interfaces. With help of these interfaces, mesh routers can connect to the Internet or other routers. The physical interface of each router is further divided into two virtual interfaces. One virtual interface is used for data traffic and the other for control traffic. There is a unique service set ID (SSID) for each virtual interface.

Frequent topology changes in WMNs are handled with help of Optimized Link State Routing OLSR [21]. A large amount of control traffic is needed to update topology, which can cause a delay in control and data plane communication. Such a delay is minimized with the OLSR routing technique. However, OLSR routing without the OpenFlow controller only considers the shortest path for routing and does not optimize resource allocation. This scenario results in less throughput and congestion. In the Mesh Flow project, OLSR constitutes a daemon (program that runs in the background) named as OLSRD. This daemon program is used for IP routing and is connected to control interface. Whereas, data interface is connected to an SDN controller, which is based on OpenFlow architecture. The controller accesses the information related to topology changes from a local agent. This local agent does the network monitoring and is connected to each router. An end-user station also possesses a monitoring agent that gives information about handovers to the controller. These end stations are connected to mesh access points.

In Mesh Flow, the controller also constitutes a monitoring and control server (MCS) [20]. Handoffs are taken care of with the help of this MCS that provides an updated topology based on the information from the monitoring agents of routers. It helps the controller to create and maintain flow tables for routing. MCS also maintains information about the handovers for end-users. In this way, SDN-based WMNs can support effective load balancing and handovers.

Mesh Flow is extended further to support even more flexible routing schemes, such as Gap [22]. Gap also provides effective resource allocation in WMNs. This is achieved by setting effective routing rules by the gap controller. Multiple interfaces connect routers with data and control planes. A unique SSID is utilized by mesh routers for each virtual interface. There are four virtual interfaces. The first one utilizes Hybrid Wireless Mesh Protocol (HWMP), to control forwarding of data traffic. Second and third interfaces provide connection to the access network, while the fourth one serves as the backbone of WMN.

Yang et al. propose SDN architecture for effective load balancing [23]. To balance the traffic load on different routes and avoid congestion, a network management tool is utilized. This tool tracks the network traffic situation and dynamically updates the routing paths. An in-band control message is exchanged between mesh routers and CC to perform load balancing.

16.5.4 Fault Tolerance in SDN-based WMNs

One of the disadvantages of SDN-based WMNs is the single point of failure. As there is only a single controller, if it fails the whole network will suffer. There is no access to control the plane for the nodes in case of failure and hence routing rules cannot be retrieved by the nodes. To achieve fault tolerance, additional techniques are required that can detect failure of the CC. Mechanisms are also required to overcome the fault by activating an alternative controller, which is an extension of Mesh Flow and addresses the issue of fault tolerance in WMNs [24]. Detti et al. implement a distributed control mechanism in case of the failure of the controller. This supports continuity of the operations without interruption. The entries from the flow table of CC are removed and typical OLSR routing rules are implemented. This is achieved by an embedded flow table manager.

16.6 SDN in Wireless Sensor Networks

16.6.1 Challenges in Wireless Sensor Networks

Wireless sensor networks (WSN) constitutes of large number of spatially distributed sensors to measure a phenomenon of some interest like temperature and humidity [25]. As the sensors in WSNs are based on batteries, it is very important to reduce energy consumption. In addition, maintaining a topology that provides good coverage of survey area is another challenge for WSNs. Multihop topology is most suitable for WSNs as there are low-energy sensors with limited radio range. Large coverage area and tough physical situations can result in broken links. Due to these distorted links packets can fail to reach their destination. WSNs are data centric and application specific. In some scenarios, such networks can provide data for multiple applications having multiple types of sensors at the same physical area. To support such diversity of applications effective abstractions are required.

16.6.2 SDN in Wireless Sensor Networks

WSN architecture is related to SDN, as it consists of a centralized sink node that gathers the information from the network [26]. In this way, the sensor nodes are similar to data planes of SDN. These sensor nodes are only forwarding the data, so they have a simple architecture that consumes less energy. Routing and topology management is handled by the controller. As the controller utilizes the global view of the network, it can provide a better connectivity mechanism among different nodes. New protocols can be implemented very easily by updating the control plane and hence multiple applications can be supported. The architecture of SDN-enabled WSNs is shown in Figure 16.4. Control plane consists of routing and energy management components, whereas data plane consists of sensors.

Typical wireless networks implemented in SDN vary from WSNs, as in WSNs data fusion techniques that are applied to aggregate the traffic at the intermediate nodes [26]. Moreover, sensor nodes are embedded devices and are prone to faults. Therefore, the network topology is dynamic and unreliable. In addition, WSNs are data centric rather than address centric. Thus, SDN techniques must be applied in such a way that the aforementioned requirements of WSNs are carefully addressed. In short, WSNs should be able to support implementation of new architectures.

Architecture of SDN-enabled wireless sensor network in which the control plane consists of routing and energy management components, whereas data plane consists of sensors.

Figure 16.4 Architecture of SDN-enabled wireless sensor network.

16.6.3 Sensor Open Flow

Sensor OpenFlow is the extension of OpenFlow standard, for WSNs [27]. Sensor OpenFlow introduces new forwarding techniques to meet the requirements of WSNs. It also enables multiple applications to operate simultaneously. In addition, duty-cycling is also controlled to provide less energy consumption [28]. As the traffic flow in WSNs is data centric rather than address centric, sensor OpenFlow is extended to utilize user-defined transport protocols. This is achieved by adding new functions that match the compact addresses and attributes. In SDN-enabled WSNs, the same network topology is used for both data and control traffic, rather than an individual control channel for communication with data plane. As the topology is changing frequently and there are only a few sinks, a lot of control packets flow from sensors toward the sinks. Time-out strategies are used by Sensor OpenFlow to address such scenarios.

16.6.4 Home Networks Using SDWN

SDN in wireless home networks is a novel research area. Many researchers have proposed different approaches to combine the home networks with SDN to provide virtualization [29, 30]. The techniques proposed in [29, 30] utilize NOX controllers and OpenFlow as a protocol to achieve simpler management, easy interface, and traffic isolation. There are differences in performing traffic isolation, and the management by various schemes. In [31], the authors discuss a DHCP- and DNS-based implementation that achieved enhanced control of home networks. New approaches have been introduced to add WSDN to home networks that focused on splitting the virtual layers into the slices [32]. Splitting the network layer will overcome the challenges of home networks as this will reduce the cost of deployment because multiple stakeholders with their own slice will share overall deployment cost. Moreover, in sliced networks, the management and data configuration is no more a challenging task. Slices distributed among different stakeholders have to be secured, which means that the data from one slice must be inaccessible to the other slice. However, the security, performance, customization, flexibility, and privacy cannot be achieved simultaneously, so still there is need for different strategies that can accomplish better balancing of aforementioned trade-offs.

16.6.5 Securing Software Defined Wireless Networks (SDWN)

Due to separation of data and control plane, SDWN are vulnerable to security attacks. Therefore, it requires new security mechanisms. Sood et al. describe various potential threats to SWDN [33]. Both forwarding devices and controller could be attacked with denial of service (DoS) attacks. The most severe attack is on CC. A compromised controller could be misused by the malicious user to corrupt the entire network. SDWN requires additional security mechanisms compared to traditional networks. Use of Transport Layer Security/Secure Socket Layer (TLS/SSL) in OpenFlow for mutual authentication between controller and forwarding devices could mitigate malicious threats. Confidentiality in SDWN could be achieved by encrypting communication medium between forwarding devices and controller. In case of DoS attacks, the data, devices, and services to authorized user could be made available by the controller by restoring the network routes dynamically. Message authentication code is used in SDWN to make sure that the message has not been changed by a malicious user. To achieve consistency in SDWN and to avoid conflicting rules, an intermediary between controller and application is used. The security mechanism of SWDN should be fast enough to tackle threats. There should be a proper monitoring mechanism in SDWN to deal with mobility and dynamic network states.

16.7 Conclusion

SDN introduces multiple opportunities in the network architecture space. The use of centralized intelligence has revolutionized the whole network infrastructure. SDN improved the resource virtualization, resource sharing among different vendors, and reduced the cost. However, the use of the technology in different networks is still an issue. Challenges, such as link separation in wireless domains, interference among the nodes due to limited numbers of channels, and load estimation on a wireless medium due to frequent change of state in the medium are the limitations of these networks.

References

  1. 1 Bernardos, C. and Oliva, A. (2014). Architecture for software defined wireless networking. IEEE Wireless Communications 21 (3): 52–61.
  2. 2 Open Networking Foundation, OpenFlow Enabled Mobile and wireless Networks, ONF Solution Brief [online]: https://www.opennetworking.org/wp-content/uploads/2013/03/sb-wireless-mobile.pdf. Accessed May, 2019.
  3. 3 Costanzo, S., Galluccio, L., Morabito, G., and Palazzo, S. (2012). Software defined wireless networks unbridling SDNs. In: Proceedings of the 2012 European Workshop on Software Defined Networking, 59–60. IEEE.
  4. 4 Chaudet, C. and Haddad, Y. (2013). Wireless defined network: challenges and opportunities. In: Proceedings of IEEE International Conference on Microwaves Communication, Antennas and Electronic Systems, 1–5. IEEE.
  5. 5 Rangisetti, A.K., Baldaniya, H.B., Kumar, P., and Tamma, B.R. (2014). Load-aware hands-offs in software defined wireless LANs. In: IEEE 10th International Conference on Wireless and Mobile Computing, Networking and Communications (WiMob), 8–10. IEEE.
  6. 6 McKeown, N., Anderson, T., Balakrishnan, H. et al. (2008). OpenFlow: enabling innovation in campus networks. ACM SIGCOMM Computer Communication Review Archive 38 (2): 69–74, ACM: New York,.
  7. 7 Open Networking Foundation, OpenFlow Switch Specification Version 1.5.0, [online]: https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow-switch-v1.5.0.noipr.pdf, accessed May 2019.
  8. 8 Sadiq, S. and Shaukat, F. (2015). A survey on wireless software defined networks. International Journal of Computer and Communication System Engineering 2 (1): 316–325.
  9. 9 Sun, G. and Liu, F. (2014). Software defined wireless network architecture for the next generation proposal and initial prototype. Journal of Communication 9 (12): 143–151.
  10. 10 S. K. Routray and K. P. Sharmila, Software defined networking for 5G, 4th International Conference on Advanced Computing and Communication Systems (ICACCS), Vol. 26, No. 1, pp. 82–92, 2015.
  11. 11 Sood, K. and Yu, S. (2016). Software defined wireless networking opportunities and challenges for internet-of-things: a review. IEEE Internet of Things 3 (4): 453–463.
  12. 12 S. Monin and A. Shalimov, Chandella: smooth and fast Wi-Fi roaming with SDN/Openflow, https://www.usenix.org/sites/default/files/ons2014-poster-monin.pdf, 2014.
  13. 13 H. Huang and S. Guo, Software-Defined Wireless Mesh Networks: Architecture and Traffic Orchestration, IEEE Network, Vol. 29, No. 4, 2015.
  14. 14 Yoshigoe, K., Maljevic, I., and Radusinovic, I. (2017). Software-defined fog network architecture for IoT. Wireless Personal Communications 92 (1): 181–196.
  15. 15 Ola, S., Imad, E., Ali, C., and Kayssi, A. (2018). IoT survey: an SDN and fog computing perspective. Computer Networks 143: 221–246.
  16. 16 Nobre, J.C., de Souza, A.M., Rosário, D. et al. (2019). Vehicular software-defined networking and fog computing: integration and design principles. Ad Hoc Networks 82: 172–181.
  17. 17 A. A. Khan, M. Abolhasan, and W. Ni, 5G next generation VANETs using SDN and fog computing framework, 15th IEEE Annual Consumer Communications & Networking Conference (CCNC), Las Vegas, NV, January 12–15, 2018.
  18. 18 Okay, F.Y. and Ozdemir, S. (2018). Routing in fog-enabled IoT platforms: a survey and an SDN-based solution. IEEE Internet of Things Journal 5 (6): 4871–4889.
  19. 19 P. Dely and A. Kassler, OpenFlow for wireless mesh networks, Proceedings of the 20th International Conference of Computer Communications and Networks (ICCCN), 2011.
  20. 20 B. Anderson, F. Farias, V. Nascimento, and A. Abelém, OpenMesh: OpenFlow in wireless mesh networks, 1st Workshop on Experimental Research on the Future Internet, December 2016.
  21. 21 S. Salsano and G. Siracusano, Controller selection in a Wireless Mesh SDN under network partitioning and merging scenarios, arXiv preprint arXiv:1406.2470, 2014.
  22. 22 V. Nascimento, M. Moraes, R. Gomes et al., Filling the gap between software defined networking and wireless mesh networks, in 10th International Conference on Network and Service Management (CNSM) IEEE, November 17–21, 2014.
  23. 23 F. Yang and V. Gondi, OpenFlow-based load balancing for wireless mesh infrastructure, in The 11th Annual IEEE Consumer Communications and Networking Conference (CCNC), January 10–13, 2014.
  24. 24 A. Detti, C. Pisa, S. Salsano, and N. Blefari-Melazzi, Wireless Mesh Software Defined Networks (wmSDN), 2013 IEEE 9th International Conference on Wireless and Mobile Computing, Networking and Communications (WiMob), Lyon, France, October 7–9, 2013.
  25. 25 Tilak, S., Abu-Ghazaleh, N.B., and Heinzelman, W. (2002). A taxonomy of wireless micro-sensor network models. ACM SIGMOBILE Mobile Computing and Communications 6 (2): 28–36.
  26. 26 C. Intanagonwiwat, D. Estrin, R. Govindan, and J. Heidemann, Impact of network density on data aggregation in wireless sensor networks, in Proceedings 22nd International Conference on Distributed Computing Systems, July 2–5, 2002.
  27. 27 Luo, T. and Tan, H.P. (2012). Sensor OpenFlow: enabling software-defined wireless sensor networks. IEEE Communications Letters 16 (11): 1896–1899.
  28. 28 W. Ye and J. Heidemann, An energy-efficient MAC protocol for wireless sensor networks, in Proceedings of IEEE International Conference on Computer Communications (INFOCOM), New York, 2002.
  29. 29 Philip Venmani, D., Gourhant, Y., Reynaud, L. et al. (2012). Substitution networks based on software defined networking. In: Ad Hoc Networks, 242–259. Berlin: Springer.
  30. 30 Chaudet, C. and Haddad, Y. (2013). Wireless software defined networks: challenges and opportunities. In: IEEE International Conference on Microwaves, Communications, Antennas and Electronic Systems, 1–5. ACM.
  31. 31 N. Soetens, J. Famaey, M. Verstappen, and S. Latre, SDN-based management of heterogeneous home network, 11th International Conference on Network and Service Management (CNSM), November 9–13, 2015.
  32. 32 Yiakoumis, Y., Yap, K., Katti, S. et al. (2011). Slicing home networks. In: Proceedings of the 2nd ACM SIGCOMM Workshop on Home Networks, 1–6. ACM.
  33. 33 He, D., Chan, S., and Guizani, M. (2016). Securing software defined wireless networks. IEEE Communications Magazine 54 (1): 20–25.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset