Software Defined Networking (SDN) is increasingly being deployed in large wired data center networks due to its benefits, such as better network management and higher level abstractions. To this end, we present a novel approach for using SDN-based multicast (SDMC) for flexible, network load-aware, and switch memory-efficient group communications in DCNs. 3) SDN is slowly being adopted in wireless scenarios, such as wireless mesh networks (WSN), compared to wired data center networks.
Software Defined Networking
In this way, Software-Defined Networking (SDN) has emerged as a new intelligent architecture for network programmability. The controller offers northbound interfaces to network applications that provide higher-level abstractions for programming various services and applications at the network level.
Challenges and proposed Solutions for Software Defined Networks 3
Group Communication in Date Center Networks using
Although multicast is useful for efficient group communication u, multicast IP has been very little adopted in data center networks due to its disadvantages such as inefficient scaling, inefficient use of switch memory, receiver initial delay. Solution: SDN-based Adaptive Multicast (SDMC) for efficient group communication in data center networks: To solve these problems, in this work, we propose a new way to implement multicast protocol for group communication protocol in SDN-enabled networks, especially in large data center networks.
Software defined Wireless mesh networks
Another effort [36] discusses the controller placement problem, but only in the context of network load. The SDN controller is part of the control plane in the SDN architecture as we discussed in the last section.
Bootstrapping Software Defined Network for Flexible and Dynamic Con-
Motivation
There is no globally optimal view of the network to maintain a consistent network state among multiple controllers. During the SDN operation, InitSDN can increase or decrease the size of slices dynamically, change the topology of the control slice, change the coordination mechanism between the controllers (e.g. use Zookeeper or Chubby, etc.) to adapt to network topology changes or to dynamic network loads or simply as part of an upgrade.
Problem Description
- Control Plane Message Types
- Limitations of Existing Control Plane
- Problem Statement
Figure 2, shows three types of messages flowing in the SDN network: (1) control messages (shown as red pipes), (2) data messages (shown as yellow pipes) and (3) meta-control messages (shown as blue pipes). Therefore, control messages are thought to flow in the pre-SDN (or non-SDN or legacy network).
Solution Approach
- Intuition Behind our Solution
- InitSDN in Action
- Implementation Details for Prototype
Control Plane Topology: This module allows the network operator to define the initial control plane topology. InitSDN then builds the control plane topology based on the configuration provided by the network operator and the network topology model from the previous step.
Experimental Evaluation
- Evaluation Criteria: Building Network Applications for
- Evaluation Criteria: Controller Scale-up/Scale-down
- Evaluation Criteria: Controller/switch Migration
- Evaluation Criteria: Managing Control-Plane Topol-
In this way, InitSDN brings the separation of concerns in the SDN control plane management. In InitSDN, the controller or switch migration is reduced to just the task of updating the control plane topology. InitSDN builds new control plane topology after notifying its discovery module of the change in network topology.
This new topology is then enforced on the control plane, as described in the previous subsection.
Related Works
This decision is based on whether the control plan requirement of the new vSDN is satisfied by the existing control plan. Therefore, Pratyaastha does not require network hypervisors as the control plane still resides in the dedicated network. Although, Prayastha provides control plane resiliency in case of controller load change, it does not provide resiliency in case of large network topology changes or large-scale failures in the physical hosts of the initially assigned control plane after the nodes physical control plane are still statically assigned.
The authors in [12] discuss the control plan placement problem and note that a single controller is sufficient for most use cases.
Concluding Remarks
It also installs OR rule in the edge switch of the sender to block all traffic with the destination idMi. SDMC then installs OR rule in the edge switch of the receiver to block all the traffic with the destination idMi. As described in figure IV.3, in the SDN-based wireless mesh networks, only a few switches are directly connected to controller.
OF_Initial_Path_Response:Switch sends this message to the controller on the initial path found in phase I.
SDN-based Adaptive Multicast (SDMC) For Efficient Group Communica-
Motivation
- Importance of Group Communication in Large Data
- IP Multicast for group communication in DCN and its
- SDN based multicast
- Our Contribution
Apart from the above data center specific tasks, DCN also hosts many client applications that rely on group communication. So it is very clear that efficient group communication is important for better performance of data center networks. Traditionally, IP multicast (IPMC) has been used (although quite minimally and inefficiently) for the group communication requirements of various applications.
In this work, we propose a new way to implement multicast protocol for group communication protocol in SDN-enabled networks specifically in large data center networks.
Problem Description
In this work, we describe the design and implementation of SDMC using SDN controllers and OpenFlow-enabled switches and evaluate it for various metrics such as adaptability to network load and switch memory utilization. This multicast protocol will be more lightweight, dynamic, adapted to network resources such as link utilization and switch memory compared to the traditional multicast solutions. For example, if two (or more) multicast IDs have the same (or nearly) receivers (or switches that receivers are connected to), they should be able to reuse the same multicast routing tree, thus saving valuable switch memory.
SDMC should be able to adapt to the switch memory limitation scenario of the data center.
Solution Approach
- SDMC infrastructure
- Lazy Initialization
- Two-level SDMC-ID
- Network link monitoring
- Network Switch-memory monitoring
- Workings of SDMC
So whenever SDN switch memory usage in an SDN network exceeds the threshold, NetApp monitoring notifies SDMC-NetApp. This threshold is specified in the percentage of switch memory usage or in the number of OF rules installed on the switch for SDMC. The SDMC will then update the translation rule in the SDN middleware of the sender s1 by adding the one-digit address of the receiver r1 (u1) to its mapping.
SDMC then adds an OF rule to the sender edge switch to block traffic from sender s1.
Experimental Evaluation
- Average latency for receivers
- Network Load Adaptive-ness
- Switch-Memory Utilization Adaptive-ness
- Packet Loss
Basic unicast (when used in one-to-many communications) increases network load because it must duplicate the same packets for each receiver. When the network load is lower, SDMC uses unicast, while it switches to multicast when the network load increases. As shown in Figure 14, SDMC thus adjusts the network load by switching between unicast and multicast.
Therefore, as seen from Figure 14, SDMC adopts switching memory and performs better than multicast.
Related Works
Now, we will measure packet loss during SDMC compared to basic unicast and multicast. As seen in Figure 15, SDMC does not reduce packet loss compared to basic multicast (IPMC). Therefore during this time SDMC suffers less packet loss compared to IPMC, so overall SDMC performs better than basic IPMC.
This approach creates backup overlays for each multicast course tree as it moves through it according to network load fluctuations.
Concluding Remarks
However, SDN is slowly being used in wireless scenario such as wireless complex networks (WSNs). In a traditional wireless complex network, a router (commonly called a switch in SDN terminology) communicates with its neighbors to achieve mutual routing paths using Ad-Hoc on-Demand Distance Vector Routing (AODV) or Optimized Link State Routing (OLSR) protocol. This makes routing in an SDN-based wireless complex network more complex than that in traditional complex networks.
Prithviraj Patil, Akram Hakiri, Yogesh Barve, Aniruddha Gokhale, “Openflow-based three-level routing protocol for software-defined wireless mesh networks”, 2016 IEEE International Conference on Computer Communications (in submission).
Software defined Wireless mesh networks
Introduction
- Wireless Mesh Networks (WMN)
- Software Defined Wireless Mesh Networks (SD-WMN) 53
Wireless mesh network (WMN)[2, 22] is a special type of mobile ad-hoc network which consists of mobile end hosts and wireless routers. But wireless networking is the exact opposite of that and consists of highly dynamic and distributed network topologies. In this work we provide a better approach for converting wireless mesh networks to purely software-defined networks.
First, we describe the differences between non-SDN-based wireless mesh network and SDN-based one in chapter IV.2.
Desgin
- Motivation behind Three-Stage Routing
- Existing Solutions
- Design considerations
There are major challenges in using routing algorithms in the architecture in Figure 16 compared to traditional non-SDN wireless mesh networks due to the following differences in architecture. Another major difference between SDN and non-SDN wireless mesh networks is that in SDN, control decisions are made by the centralized controller. However, in traditional wireless mesh networks, control decisions are made in a distributed manner by the algorithms installed in each switch that is itself distributed.
They propose to combine SDN-enabled switches and legacy switches (or routers) into a wireless network router as shown in Figure 18 where SDN-enabled switches form the SDN network while traditional switches form the legacy network.
Three-Stage Routing: Architecture
- OpenFlow Modifications for staged routing
In this way, each switch that receives the OF_Initial_Path_Request message establishes an initial path to the controller. This message is sent only when the initial path differs from the shortest path between the controller and the switch. Each switch sends the OF_Initial_Path_Response message to the controller via the initial path found in phase-I.
In our example, switch-3 has received OF_Initial_Path_Request from two switches (Switch-2 and switch-4).
Experimental Evaluation
Finally, in stage-III (Figure 22), the controller installs routing paths among switches using the shortest path from stage-II. In our implantation, the POX controller is directly connected to one of the switches in the Mininet in a hard-coded way. We measured this latency in relation to the number of broken links between the controller switch as shown in Figure 25.
This helps the overall performance of the current routing between the circuit breaker link in phase III, as seen in Figure 26.
Conclusions
In this chapter, we describe a summary of our contributions in the field of software-defined networking. Prithviraj Patil, Akram Hakiri, Aniruddha Gokhale, "Adaptive Software-defined Multicast for Efficient Data Center Group Communications", 2016 IEEE Conference on Network Functions Virtualization and Software-Defined Networks (NFV-SDN 2016). Akram Hakiri, Prithviraj Patil, Aniruddha Gokhale, “SDN-enabled Wireless Fog Network Management”, 2016 IEEE Conference on Network Functions Virtualization and Software Defined Networks (NFV-SDN 2016).
In Proceedings of the Second ACM SIGCOMM Workshop on Hot Topics in Software-Defined Networking, pages 7–12.
Summary
Summary of Contributions
InitSDN: we described a solution approach that involves a separate bootstrapping or initialization phase for the SDN network. SDMC: We proposed a new way to use SDN based multicast (SDMC) for flexible, network load aware, switch-memory efficient group communication specifically for the data center networks. Openflow-based Routing in Wireless Mesh Network: We proposed three-step routing to effectively use SDN in wireless mesh networks.
We described extensions to the existing Openflow protocol with three new message types that facilitate three-step routing.
Summary of Publications
- Software defined networking layers
- Three Types of Messages Flowing in the Distributed Controller Archi-
- InitSDN modular architecture
- Legacy Network During the Bootstrapping Phase (1) network slicing
- Legacy Network turned into SDN Network After Bootstrapping is Com-
- Three Types of Messages Flowing in the bootstrapped SDN
- SDMC infrastructure
- Initial SDMC Sender Setup
- Initial SDMC Receiver Setup
- Adapting to Network Load
- Adapting to Switch Memory Utilization
- Receiver Latency against group size
- Receiver Latency for different network topology and size
- SDMC adaptive-ness to network load and to switch memory utilization . 49
- SDN Based Wireless Mesh Network
- Hybrid Architecture for SDN Wireless Mesh Network (1)
- Hybrid Architecture for SDN Wireless Mesh Network (2)
- Example SDN Mesh Scenario
- Stage I Interactions
- Stage II Interactions
- Stage III Interactions
- Implementation components
- Controller Switch Connection Latency
- Controller Switch Re-Connection Latency
- Switch-Switch Connection Latency
Netwerk voor flexibel en dynamisch controlevlakbeheer”, IEEE Conference on Network Softwarization (IEEE NetSoft 2015). Prithviraj Patil, Akram Hakiri, Aniruddha Gokhale “Cyber Foraging and Offloading Framework for Internet of Things”, de 40e IEEE Computer Society International Conference on Computers, Software & Applications 2016. Yogesh Barve, Prithviraj Patil, Aniruddha Gokhale “Een cloudgebaseerd meeslepend leren -ing Environment for Distributed Systems Algorithms”, de 40e IEEE Computer Society International Conference on Computers, Software & Applications 2016.
2013 IEEE 9th International Conference on Wireless and Mobile Computing, Networking and Communications (WiMob), pages 89–95.
