Prithviraj Patil
email: prithviraj6116@gmail.com

Akram Hakiri
email: akram.hakiri@gmail.com

Shashank Shekhar
email: shashank.shekhar@vanderbilt.edu

Aniruddha Gokhale
email: a.gokhale@vanderbilt.edu

Scalable and Adaptive Software Defined Network Management for Cloud-hosted Group Communication Applications

Keywords: Networks → Network resources allocation, Cloud computing, Data center networks, • Computer systems organization → Cloud computing, Fault-tolerant network topologies, Cloud Computing, Adaptive Multicast, Software Defined Network, OpenFlow, Data Center Networks

ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

INTRODUCTION

Many cloud infrastructure management tasks as well as cloudhosted applications require group communication semantics in cloud Data Center Networks (DCNs) [START_REF] Chen | Enabling technologies for future data center networking: a primer[END_REF]. For example, DCNs must offer diverse elasticity techniques to provide commodity and tenantbased services for scaling up or down of computing, storage and network resources, e.g., Amazon Elastic Compute Cloud (Amazon EC2) and services like Twitter and Facebook, which use multicast-centric architectures. Additionally, several fault management strategies, * Work conducted as part of doctoral studies at Vanderbilt University. such as passive and active replication, failover, state synchronization of cluster servers and quorum management in active replication require group communications to tolerate and mitigate faults [START_REF] Zhao | Fault Tolerance Middleware for Cloud Computing[END_REF].

Group communication is also used to enforce security solutions in DCNs, such as prevention, detection and removal of malware and viruses, as well as in performing bulk software installment, update, and upgrade [START_REF] Roy | Application of MultiCast Tree concept to cloud security with optimization algorithm for node search technique[END_REF]. For example, software management tools for cloud infrastructure like Chef send the same commands to multiple (i.e., 100s of) virtual machines during software installation and update. Likewise, access control policies in DCNs use group communication to manage users, groups, passwords, and user privileges [START_REF] Sriprasadh | A novel method to secure cloud computing through multicast key management[END_REF].

Two key considerations dictate the performance of group communications in DCNs. First, the router/switch's available network capacity (i.e., available bandwidth) is required to estimate the bandwidth available for data traffic and control messages that can be forwarded along their multiple ports concurrently [START_REF] Wang | Timing is Everything: Accurate, Minimum Overhead, Available Bandwidth Estimation in High-speed Wired Networks[END_REF]. Hence, the ability to instrument the router's (or switch's) network capacity is crucial to estimating the network load in terms of the overall bandwidth that a router/switch is able to support. Second, since the memory of the routers/switches (including their queuing buffers) holds packets and connection state information of the traffic transiting across the network devices, it is important to maintain the router/switch memory utilization under a given threshold to avoid buffer overflows [START_REF] Khoshkholghi | Energy-Efficient Algorithms for Dynamic Virtual Machine Consolidation in Cloud Data Centers[END_REF].

Group communication semantics for contemporary DCN-hosted applications are often realized using multicast, e.g., IP multicast (IPMC), which is a commonly used group communication protocol in the Internet to support multi-point communication requirements so as to conserve bandwidth and reduce the load on servers [START_REF] Mcbride | Multicast in the Data Center Overview[END_REF]. IPMC, however, incurs substantial security, performance and scalability degradation in DCNs, e.g., IPMC can be exploited for distributed Denial-of-Service attack [START_REF] Basin | Sources of Instability in Data Center Multicast[END_REF]. Moreover, existing multicast routing algorithms, such as Protocol-Independent Multicast (PIM) (e.g., PIM Sparse Mode (PIM-SM) and PIM Dense Mode (PIM-DM)) and Multicast Open Shortest Path First (MOSPF), require substantial manual deployment and management efforts by the cloud operators [START_REF] Li | Scaling IP Multicast on Datacenter Topologies[END_REF]. Furthermore, the Internet Group Management Protocol (IGMP) [START_REF] Holbrook | Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast[END_REF], which is used by IPMC for dynamic membership registration, sends multiple messages to all the routers to notify the occurrence of group events, which requires significant CPU resources, and substantial memory resources to hold the table size for IP multicast [START_REF] Nakagawa | A Management Method of IP Multicast in Overlay Networks Using Openflow[END_REF].

A further downside with IPMC concerns its limited state space in commodity routers which impedes router functionality since they must maintain routing states and perform a costly and wasteful pergroup translation [START_REF] Vigfusson | Dr. Multicast: Rx for Data Center Communication Scalability[END_REF]. Hence, packet filtering becomes ineffective in large multicast groups and in turn the overwhelmed receivers will begin dropping packets. Although several improvements, such as Hierarchy-Aware multicast [START_REF] Nagaraj | Hierarchyaware distributed overlays in data centers using DC2[END_REF], multi-path routing [START_REF] Li | RDCM: Reliable data center multicast[END_REF], and Bloom filter-based group management [START_REF] Li | Scalable data center multicast using multi-class bloom filter[END_REF], address these issues, they cannot be readily adopted in DCNs due to their complexity, security issues, and the manual efforts required in managing them.

Being cognizant of the switch memory utilization as well as the network load to avoid drastic problems is a critical requirement for any group-based communication semantics in DCNs. Complicating this requirement is the fact that DCNs often comprise a very large number of distributed network equipment, which makes it harder to instrument, coordinate and maintain a consistent and global view of the system without developing additional and complex solutions. It is in this context that emerging approaches in the form of Network Function Virtualization (NFV) or network softwarization and Software-Defined Networking (SDN) [START_REF] Kreutz | Software-Defined Networking: A Comprehensive Survey[END_REF] hold promise [START_REF] Pan | Software-Defined Network (SDN) Problem Statement and Use Cases for Data Center Applications[END_REF]. NFV, for instance, aims to virtualize a set of network functions by moving network function into software packages, meaning that building a service chain no longer requires acquiring hardware. Complementing NFV is SDN which separates the control plane from the data or forwarding plane. NFV can enable multicast routing on SDN by constructing a traffic forwarding topology, deploying the required multicast functions and steering traffic through the constructed multicast trees [START_REF] Zhang | Routing Algorithms for Network Function Virtualization Enabled Multicast Topology on SDN[END_REF]. Recent efforts [START_REF] Cui | Scalable and Load-Balanced Data Center Multicast[END_REF][START_REF] Iyer | Avalanche: Data center Multicast using software defined networking[END_REF] have used SDN for efficient bandwidth management during the creation of multicast trees by using topology information in DCNs. Despite this promise, current approaches cannot autonomously adapt to the network load and router (or SDN switch) memory utilization, which is critical to the scalability of group communications, and also for monitoring and evaluating network performance in DCNs.

To leverage the benefits of NFV/SDN while addressing unresolved challenges and limitations in recent SDN-based multicast efforts, we propose an autonomic Cloud resource management architecture called SDN-based Multicast (SDMC) to achieve utility in clouds by supporting dynamic and flexible, network load-aware and switch memory-efficient group communications in DCNs. SDMC is not a new multicast protocol; rather it is a SDN-enabled distributed middleware framework for improving utility in DCNs that provides dynamic resource management by intelligently and dynamically switching different group communications flows between unicast and multicast thereby balancing between network bandwidth and switch memory utilization. SDMC is fully decoupled from any specific multicast protocol, such as IPMC. Moreover, the middleware aspect enables a large number of DCN-based group communication applications and services to avail of our adaptive resource management solution.

The key contributions of these paper are:

• We describe the architectural innovations and algorithms in SDMC that provide an autonomous, adaptive and flexible network link and switch memory load-aware multicast approach for data center networks.

• We present details of our distributed SDMC middleware, which is manifested in the form of (i) a suite of SDN network applications hosted on a SDN controller and OpenFlowenabled switches [START_REF] Mckeown | OpenFlow: enabling innovation in campus networks[END_REF], and (ii) a SDN middleware layer on the network hosts where applications reside. • We evaluate the effectiveness of our approach in different data center network topologies along a number of metrics, such as load variations and switch-memory utilization.

The rest of the paper is organized as follows: Section 2 describes the design and implementation details of SDMC. Section 3 provides an empirical evaluation of SDMC. Section 4 discusses related work and compares them to SDMC. Finally, Section 5 presents concluding remarks alluding to lessons learned and future work.

DESIGN AND IMPLEMENTATION OF SDMC

This section delves into the details of SDMC. We first present three key contributions in SDMC required to support application-agnostic dynamic and adaptive resource management, and then present the architectural details that enable us to realize utility in the cloud. Subsequently we present the algorithms that use the framework to perform an adaptive, network link and switch memory load-aware multicast for data center networks.

Contribution 1: Two-level SDMC-ID Structure

A key requirement for SDMC is to support application-agnostic adaptive behavior and promote the reuse of multicast routing trees. To that end, SDMC defines a new multicast identifier space called SDMC-ID. 1 The SDMC-ID space is divided into two regions: application-level (or external, i.e., ID e ) and network-level (or internal, i.e., ID i ). Applications using SDMC interact using only the external SDMC-IDs while the network data path deals only with internal SDMC-IDs. To keep applications agnostic of internal IDs, SDMC supports a translation layer in the form of a middleware on each host (see Section 2.4). This two-level SDMC-ID structure allows SDMC to use the same multicast routing tree (with the same internal SDMC-ID) with overlapping receivers belonging to two different external SDMC IDs. SDMC maintains the mapping between the two types of IDs by encoding the participants' external multicast channel IDs and the node-specific internal IDs, and storing it in each immediate SDN router/switch without requiring packet header modification. As shown in Figure 1, traditional multicast uses the same multicast ID for all the communication needs. In contrast, SDMC uses the external SDMC multicast ID for communication between application endpoints (i.e., sender and receiver) and network endpoints (i.e., switches or controller). For the communication between the controller and switches, SDMC uses the corresponding internal multicast ID. Hence, the communication over lines 1, 2 and 3 uses external (or application-level) multicast ID while the communication over lines 4 and 5 uses internal (or network-level) multicast ID.

Contribution 2: Lazy Initialization Strategy

Our second contribution lies in the initialization process for the SDMC senders/receivers and the SDMC routing tree creation, which uses a lazy approach to reduce the initial latency that is otherwise incurred by the receivers in traditional multicast and also to allow flexibility in adapting dynamically to the network load and switch memory. SDMC exhibits this lazy approach in its operation while switching to multicast communication from the default unicast. Specifically, the immediate SDN router/switch does not rely on multicast routing information right away; rather it can be stateless for forwarding since it uses existing unicast routing information. This lazy approach manifests itself in three different situations. First, when a new receiver requests to listen on an external SDMC-ID, it is not immediately added to the SDMC-ID as a multicast receiver but rather as a unicast destination for all the existing senders of that SDMC-ID, if any. Second, the SDMC multicast routing tree for a new receiver is created in the controller but is not installed (e.g., in the form of OpenFlow rules [START_REF]OpenFlow Switch specification v1[END_REF]) in the switches right away. Third, when a receiver (or sender) leaves the SDMC-ID group, the multicast tree is not updated immediately. All these decisions (i.e., when to add a receiver as a multicast destination; when to install the multicast routing tree in switches; and when to update the multicast routing tree after a receiver leaves) are taken by SDMC holistically based on all other SDMC sender/receiver statuses and depending on the network load and switch-memory utilizations (see the algorithms in Section 2.5).

Figure 2 shows the lazy initialization of a sender. It shows the setup when two receivers subscribe to this sender. Even though the sender has a multicast ID attached to it, receivers are added as a unicast destination to reduce the start-up latency. This enables the receiver to receive packets immediately since there is no need to create any multicast routing tree in the switches. The corresponding behavior on the receiver side appears in Figure 3. As seen from

Blocked

In Switch

Blocked

In Switch

Allowed

In Switch

Allowed

In Switch

Allowed

In Switch

No Receivers

After one receiver After two receivers

Contribution 3: Network Link and Switch Memory Monitoring

To make dynamic resource management decisions, SDMC must periodically keep track of the utilizations of network links and switches. SDN switches use counters for tracking the number of packets that are sent through a given link and record link forwarding success and failure. This is used to track the bandwidth utilization and detect if certain packets are consuming more bandwidth than anticipated. Using these counters, the controller can make a decision about the link utilization. To that end, SDMC provides a special capability in the SDN controller via a network management application (see Section 2.4). SDMC then populates the network link utilization information against the SDMC-IDs which are using that link for unicast for a given receiver. The network topology corresponding to this scenario is shown in Figure 4. SDMC also keeps track of the memory utilization of the network switches with the help of the controller. Since the controller installs rules in the switches, it knows exactly how many Open-Flow rules exist on each of the switches. Each switch comes with a maximum number of OpenFlow rules that it can accommodate. So we measure the switch-memory utilization as the number of actual OpenFlow rules installed in the switch against the maximum number of OpenFlow rules allowed.

SDMC SDN controller:

The DCN is managed by a (logically) centralized SDN controller, which is placed on a dedicated machine(s) with dedicated out-of-band connections to all the OpenFlowenabled routers. The SDMC-specific SDN NetApps hosted on the controller provide the core intelligence of SDMC as follows:

• Topology Discovery: This NetApp provides autonomous discovery of joining and leaving routers and hosts. It uses the link layer discovery protocol (LLDP) to assist the controller in identifying the joining or leaving multicast group participants. OpenFlow-enabled switches: In a typical DCN, a number of OpenFlow-enabled switches are connected to form a network with topologies like mesh, tree or jellyfish. Each switch contains an OpenFlow client to connect to the SDN controller. The OpenFlow client conforms to the OpenFlow protocol by providing capabilities to add, remove, update, and delete packets inside the network devices. The OpenFlow logic is designed in terms of flow processing controlled by a group of flow tables. Flow tables are composed of a set of entries to process packets whose headers match predefined patterns in the header field. The OpenFlow protocol specifies the formats of the messages exchanged between controllers and remote switches through a secure channel so that commands and packets can be exchanged securely. The mapping of the data plane into forwarding tables provides a simple abstraction to describe the common requirements of network equipment to store, process, and forward packets hop-by-hop. Thus, the abstraction provided by the OpenFlow protocol enables the use of open and standardized interfaces that can be used to program network devices in a vendor-agnostic manner.

Host machines and SDMC middleware: Multicast functionalities, which deal with overlay multicast, are implemented using SDMC's SDN middleware that runs in each of the host machines. The SDN middleware controls the communication using a host manager service to translate endpoints listening on multicast IDs into multiple unicast IDs, and switch endpoints from unicast to multicast and vice-versa transparently to the applications. Those endpoints can decide whether senders or receivers are able to send or listen only on SDMC IDs or not.

Host manager: The host manager NetApp (not shown) keeps track of all machines connected to the network. This application is used by SDMC to communicate with the SDMC middleware on the host machines. This application is required since we build a hybrid multicast protocol by combining application-level multicast (or overlay multicast) and native network-level-multicast.

SDMC participants: The SDMC participants (senders and receivers) run on top of the SDMC middleware on the hosts. d

SDMC Behavior and its Dynamic Resource Management Algorithms

We now describe the runtime operation of SDMC and explain its dynamic resource management algorithms. We illustrate these operations in the form of sequence of activities executed by SDMC in response to various events like sender and receiver join, and sender and receiver leave.

2.5.1 Algorithm for Sender Join. When a participant (sender) wants to send data on an application-level SDMC-ID, M e , the following sequence of steps described in lines 4-10 of Algorithm 1 are carried out. • The sender uses its SDN middleware to forward the request to the SDMC Routing NetApp. The latter assigns an appropriate internal SDMC-ID M i to correspond to the requested application-level SDMC ID, M e . The SDMC Routing NetApp at the controller side installs an OpenFlow rule in the edge switch of the sender to block all the traffic with destination ID M i . • Thereafter, if this sender is the first sender for M e , then the SDN middleware on the sender node (and for all the existing receivers) installs a translation rule for M e ↔ M i in the host middleware so that (1) when sender sends packets on external SDMC-ID M e , it gets translated to internal SDMC ID M i and also [START_REF] Beloglazov | Energy-aware resource allocation heuristics for efficient management of data centers for Cloud computing[END_REF] when any receiver receives the packet with SDMC-ID M i , it gets translated to application-level external SDMC-ID M e . • Additionally, the SDN middleware of the joining sender installs the translation rule M e → (M i , U r 1 , U r 2 ), to convert M e into destinations of the existing unicast receivers, i.e. U r 1 and U r 2 . This step is performed only if at least one receiver is listening on M e as a unicast destination. This allows the sender to start sending packets using unicast immediately instead of incurring the delay in traditional multicast.

2.5.2 Algorithm for Receiver Join. Similar to the joining of a sender, when a joining receiver wants to listen on an applicationlevel SDMC-ID M e , it requests its SDN middleware to retrieve the internal network-level SDMC-ID M i from the SDMC SDN NetApp. Then, the SDN middleware installs two translation rules M e ↔ M i and M e ↔ U r (where U r is the unicast ID of this receiver), while giving preference to the M e ↔ U r rule over M e ↔ M i so that the first rule gets matched. This forces the receiver to listen on the unicast ID instead of multicast ID to begin with. This is part of the lazy initialization of SDMC receivers.

Lines 11-15 of Algorithm 1 illustrate the joining operation for a SDMC receiver. The following sequence of steps are followed:

• When a new receiver (r1) sends a request to listen on M e , the receiver is not immediately added to M e as a multicast destination. Instead it is added as a unicast destination (as U r 1 ) for all the existing senders of M e . • Next, SDMC concurrently creates a multicast routing tree for a new receiver as explained in Section 2.5.3. Even though every existing sender of M e has a multicast ID (in the form of M i ) attached to it, new receivers are added as unicast destinations for reducing the startup latency. This allows the joining receiver to receive packets immediately. • The receiver is transparently switched to multicast only if the network link utilization crosses a threshold limit, as explained in Section 2.5.4. As part of these steps, the SDMC SDN NetApp searches for all the senders of M i and adds the unicast destination of U r in their SDN middleware translation rules. Then, it requests the unicast routing paths for this receiver to every sender of M i from the Routing module at the SDN controller. Based on these routing paths, it then updates the controller's routing table by adding a sender-receiver pair against each appropriate network link and switch.

Multicast Tree Calculation.

In the current IP multicast, the number of multicast forwarding states is proportional to the number of multicast groups where the number of multicast groups grow proportionally to the number of forwarding states. Additionally, the number of control messages required to maintain the forwarding states will grow in the same manner. This scalability issue has to be solved before multicast can be deployed over the Internet. To address this issue, SDMC allows optimally aggregating multicast groups so that the controller can aggregate local groups into virtual meta-groups to perform routing tree aggregation and addressing.

To that end, the SDMC Routing NetApp in the SDN controller implements Algorithm 2 to compute the multicast tree. Based on inputs from the topology discovery NetApp, it keeps track of all links in the network and adds them to the link list (L), and creates a list of nodes (N) joining those links as shown in lines 1 to 6. Moreover, since there could be multiple multicast groups in the DCN, SDMC finds the address of the group from the list of all available multicast groups and returns a list of routers in the same group, i.e., the multicast tree (lines 7-9). Subsequently, SDMC calculates the shortest path in the multicast tree and installs the OpenFlow rules for that multicast tree (lines 10 and 11).

Since the DCN environment can carry multiple concurrent multicast sessions, SDMC allows accommodating all the multicast groups while allowing the optimization of the network resource among multiple co-existing multicast trees. As shown in line 8 in Algorithm 2, SDMC allows multicast tree packing based on the least cost tree (Steiner tree) to perform adaptive resource management. In random graphs, such as distributed routers in the Internet, the Steiner tree is known to be NP-Complete. Nonetheless, the routers and switches in DCNs are organized as structured graphs so that it is possible to build optimal or near-optimal routing trees using a Steiner tree.

Furthermore, as SDMC can dynamically perform the multicastto-unicast translation, a source group can send an aggregation packet to the edge switch using the unicast ID, typically IP unicast address, so that the controller installs the required OpenFlow rule to perform multicast group registration. This strategy offers bandwidth efficiency for a large number of OpenFlow rules because the translation happens likely close to the receiver. This way, SDMC drastically reduces the required network states and concentrates them in a single switch at the network edge close to the receiver. Furthermore, the application remains agnostic to the rest of the network topology changes because transparent to the application, SDMC makes trade-offs to retain the benefits of group communication by dynamically switching between unicast and multicast, and effectively limiting the explosion of the network states during the communication.

Adaptive Resource Management

. SDMC keeps track of network links and their utilization with the help of the SDMC Monitoring NetApp. Then, it populates the link utilization information against the SDMC-IDs which are using that link for the unicast for a receiver. Additionally, SDMC also keeps track of the memory utilization of the network switches with the help of the controller. SDMC reduces switch memory utilization by dynamically switching some multicast receivers to unicast destinations. This is due to the removal from the switch of OpenFlow rules used for multicast routing of those toggled receivers. Similarly, SDMC also reduces link utilization by switching some unicast receivers to multicast destinations, which reduces packet duplication and hence decreases network link utilization. In this way, SDMC trades off link and switch memory utilization keeping both of them below the threshold limits. In current work we do not consider both metrics at once. Moreover, SDMC also does not handle the case when both metrics are high, nor does it handle oscillations in adaptations.

Based on insights from [START_REF] Beloglazov | Energy-aware resource allocation heuristics for efficient management of data centers for Cloud computing[END_REF], we maintain the threshold limits under 70% of the resource utilization to avoid possible SLA violation while decreasing the energy consumption as soon as possible. To trigger the dynamic adaptations, SDMC registers listener events in the SDMC Monitoring NetApp to get notifications about link and switch memory threshold violations. Algorithm 3 describes the procedure for this dynamic and adaptive resource management. 14 end SDMC continually monitors link and switch memory utilization. As shown in Lines 1-6 of Algorithm 3, when a switch memory reaches the threshold limit, first, SDMC updates the translation rule in the SDN middleware of all the senders by adding in its mapping the unicast address of r 1, i.e., M e ↔ (M i , U r 2 ) would become M e ↔ (M i , U r 1 , U r 2 ). Then, SDMC instructs the receiver to listen on its own unicast ID (U r 1 ) along with multicast ID M i . At this point the SDN middleware of r 1 starts receiving duplicate packets: one each from unicast and multicast destinations. SDMC, however, instructs the SDN middleware of r 1 to discard any duplicate packets. Hence, the application-level receiver (r1) receives only a single copy of each packet. Now, since r 1 does not need multicast destination support, SDMC can safely remove OpenFlow entries in the router that were installed before to reach r 1. This step reduces the switch memory utilization. At this point, r 1's SDN middleware again starts to receive only a single copy of each packet but through unicast destination. Now, SDMC instructs r 1 to stop listening on multicast ID M i altogether. In this way, r 1 is toggled from multicast to unicast to reduce the switch memory utilization.

In the same way, when a link utilization crosses threshold limit, SDMC reduces link utilization (Lines 8-13 in Algorithm 3) as follows. First, SDMC updates the multicast routing tree for multicast ID of r 1 (M i ) inside the SDN routers by adding flow entries that allow r 1 to be reached by all the senders of M i . Then, SDMC instructs the receiver to listen on multicast ID M i along with its own unicast ID (U r 1 ). At this point, the SDN middleware of r 1 starts receiving duplicate packets: one each from unicast and multicast destination. SDMC, however, instructs the middleware of r 1 to discard the duplicate packets. Hence, the application level receiver (r1) receives only a single copy of each packet. Then, SDMC updates the translation rule in the SDN middleware of all the senders by removing in its mapping the unicast address of the r 1, e.g., M e ↔ (M i , U r 1 , U r 2 ) would become M e ↔ (M i , U r 2 ). This step reduces the network link utilization as each sender now sends one less copy of each packet. At this point, r 1's SDN middleware again starts to receive only a single copy of each packet but through the multicast destination. Now, SDMC instructs r 1 to stop listening on unicast ID U r 1 altogether. In this way, r 1 is switched from unicast to multicast to reduce the network link utilization. f

EXPERIMENTAL EVALUATION

We evaluated SDMC using an emulated DCN testbed comprising Mininet [START_REF] Lantz | A network in a laptop: rapid prototyping for software-defined networks[END_REF] as the network emulator with OpenFlow virtual switches used for creating different DCN topologies. We implemented SDMC using the Python-based POX SDN controller. For senders and receivers, we developed a representative publishsubscribe application which runs as a SDMC participant (sender or receiver) and is hosted on 200 virtual hosts. We also created up to 500 multicast groups for these participants. We arranged these 200 virtual hosts in four different topologies, viz., Jelly-fish, Tree, Fattree and Random, which are the most used network topologies in DCNs. We argue that these topologies have diverse dissemination paths that highlight the advantages of SDMC. We evaluate SDMC in terms of initial setup latency, network overhead, switch-memory utilization, and packet loss and compare it against traditional IP multicast. 2

Average Initialization Setup Time

Multicast service mode needs an initialization setup time to enable receivers to join the group and perform their membership. The initial setup time is measured as the time for processing a receiver's joining-request by the controller. It does not concern actually sending or receiving packets. So the time between some receiver A contacting the controller that it wants to join and the controller replying back with a message of "membership successful" is the initial setup time. In IPMC this time involves updating all sender-to-receiver mcast trees but in SDMC it only involves updating the sender switches. Thus, SDMC's receiver-initiated group membership allows better management of the leaf nodes. Figure 6 shows the receiver-initiated setup time in terms of number of senders in the group. For this experiment, the sender would send packets with max UDP size (65K) at some constant rate. The transmission rate was same for all the senders (1 Mbps), which was set by the mininet virtual switches and communication was through UDP channel. The figure shows that SDMC incurs less setup latency than IPMC. In particular, in all cases the average initialization latency incurred is at least 50% less than IP multicast. This is due to the fact that SDMC defers creating the routing tree in the controller to a later time. Since the controller has global knowledge of all the joining/leaving nodes, it programs the switches by injecting OpenFlow rules, which allows receivers to join the multicast tree at a later time. This approach is different from traditional IP multicast, which involves IGMP snooping to filter the unwanted multicast packets. These results validate our claims about better latency performance compared to traditional IP multicast. Additionally, we measured the initialization setup time for different network topologies in DCNs. Figure 7 shows the setup delay for the most common data center network topologies, viz. jellyfish, tree, flat-tree, and random topologies. It shows that SDMC incurs less setup time compared to traditional multicast in all the four DCN topologies. Again, the evaluation results confirm the efficiency of our SDN-enabled multicast compared to traditional IP multicast.

Adaptiveness to Network Load

To evaluate the awareness and adaptation capabilities of SDMC to router capacity, we performed network load measurements in four of the data center network topologies, i.e., jellyfish, mesh, tree, and random topologies. Figure 8 shows the network load for SDMC and IP multicast. SDMC efficiently switches between unicast and multicast based on network load as described in Algorithm 3. When network load is less, SDMC uses unicast while it switches to multicast when network load increases. As seen from Figure 8, SDMC adapts to network load by toggling between unicast and multicast. In particular, SDMC incurs up to 25% network overhead when increasing the number of multicast groups up to 500. Conversely, IP multicast incurs up to 80% of network overhead.

Adaptiveness to Switch-Memory Utilization

Figure 9 shows the switch memory utilization for IPMC and SDMC to evaluate the effectiveness of our approach in avoiding the switch buffer overflow. SDMC requires 50% less memory utilization as measured in terms of the number of OpenFlow rules that are stored in switch buffers compared to IPMC once the number of multicast groups exceeds size 30. This is due mainly to the fact that OpenFlow rules are injected by the SDN controller only when missing packets or unrecognized packets transit through the switch. Thereafter, the switch will send a request to the controller to install new rules. Moreover, as described in Algorithm 3, when the switch memory utilization crosses a threshold limit, i.e. 70% of the available resources as described in Section 2.5.4, SDMC toggles to unicast. This helps to reduce load on switch memory buffers resulting in less switch buffer overflows. This approach is different from traditional multicast, which performs stateful packet forwarding, because it needs to maintain the same state across all the transit switches.

Our results, show that our approach succeeds in improving switch memory utilization compared to IP multicast.

Evaluating the Packet Loss

We evaluated the packet loss and studied its impact in affecting the network's application behavior. Packet loss can occur when the traffic transmitted to the receivers across a particular link exceeds the capacity of that link. Additionally, another source of packet loss is that short-lived bursts of traffic may occur and deteriorate the network performance for a short time. By characterizing the link utilization through the packet loss we can better investigate the bottlenecks, if any, of our SDN-enabled multicast approach. Note that SDMC ensures that the sender does not send duplicate packets. Hence, during dynamic adaptation, the receiver will not receive any duplicates but can received packets out of order, which we assume will be handled by the application layer since the underlying protocol we use is UDP. Figure 10 illustrates the packet loss for the IP multicast and compare it to our approach in SDMC. This figure shows that our approach presents a less than 2% of packet loss, which is better than the traditional multicast that experiences more than 6% of packet loss, when the number of multicast groups exceeds size 70. These results demonstrate that our SDN-enabled multicast performs better data transmission compared to IP multicast.

RELATED WORK

This section describes related work on resource management solutions for group communications in data center networks and compares it to the SDMC solution.

Scalable Multicast Routing in DCNs

Due to the many different challenges incurred in deploying group communications in DCNs, scalable multicast routing has been an important topic of research. In [START_REF] Li | ESM: Efficient and Scalable Data Center Multicast Routing[END_REF], Bloom filter-based group management was introduced to compress multicast routing entries by removing computations of distributed routes from multicast routers. Similarly, BUFFALO [START_REF] Yu | BUFFALO: Bloom Filter Forwarding Architecture for Large Organizations[END_REF] distributes IP forwarding tables on each router interface and requires one Bloom filter on each router interface. A similar idea was discussed in [START_REF] Guo | Exploring Server Redundancy in Nonblocking Multicast Data Center Networks[END_REF] to encode the multicast h tree information into in-packet Bloom filters. Despite the advantages of Bloom filter-based multicast in reducing flow entries, such approaches require installing Bloom filters in each switch port to perform the compression actions. Moreover, in typical high-density Ethernet port routers installed in DCNs, it is difficult to maintain efficient memory utilization since dealing with false positives in the lookup incur additional router overhead.

The Hierarchy-Aware multicast framework [START_REF] Nagaraj | Hierarchyaware distributed overlays in data centers using DC2[END_REF] relies on Distributed Hash Tables (DHTs) to create multicast forwarding trees for dynamic membership management in overlay DCNs. Nonetheless, DHT-like tree creation pays less attention to the links at the bottom of the tree, which results in suboptimal routing when top-down data forwarding is performed. Dual-structure Multicast (DuSM) [START_REF] Cui | Scalable and Load-Balanced Data Center Multicast[END_REF] classifies multicast groups based on their flow granularity. First, large (i.e., elephant) flows are detected and classified in the same multicast trees to which higher bandwidth is allocated. Then, multicast-tounicast translation rules are performed for all the other short (i.e., mice) flows. Although such an approach allows control over traffic congestion in DCNs, it is difficult to adopt it in latency-sensitive applications associated with bursty mice traffic, which represent most of the traffic transiting the DCNs.

Recent efforts [START_REF] Li | Reliable Multicast in Data Center Networks[END_REF][START_REF] Li | RDCM: Reliable data center multicast[END_REF] introduced Reliable Data Center Multicast (RDCM) by exploiting the multi-path diversity available in highly connected DCNs. RDCM creates backup overlays for every multicast routing tree, and switches among them as per network load fluctuations. Similarly, a unified unicast-multicast framework was introduced in the Code-Oriented eXplicit multicast (COXcast) project [START_REF] Jia | A Scalable Multicast Source Routing Architecture for Data Center Networks[END_REF], where a unicast path is created to the underlying routers and then multicast trees are created by encoding the output port bitmap of nodes on the path between the source and destination. Our approach is similar to RDCM and DuSM in that SDMC achieves fault tolerant and network-efficient communication by bypassing initial multicast tree creation and switching to unicast instead. Similar to COXcast that uses both a common identifier and a node-specific key to route packets to multiple receivers, SDMC introduces two-level identifiers to interact with multiple end hosts and routers, respectively. Unlike these approaches, SDMC moves the multicast management logic from routers to a centralized SDN controller, which holds all the intelligence required to manage multicast groups. The SDN controller leverages high-density links in DCNs to provide a global view of the entire network and installs multicast flow entries in the routers.

SDN-enabled Multicast in DCNs

Prior research on multicast issues in SDN-enabled group communications exist. For instance, [START_REF] Nakagawa | A Management Method of IP Multicast in Overlay Networks Using Openflow[END_REF] extends IP multicast using Open-Flow for dynamic group management rather than employing the traditional IGMP protocol [START_REF] Holbrook | Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast[END_REF]. The authors introduce a VXLAN [START_REF] Mallik Mahalingam | Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks[END_REF] controller to perform Ethernet-over-IP encapsulation over a logical "tunnel." Similarly, in [START_REF] Hong | OpenFlow-based multicast in IP-over-LOBS networks: A proof-of-concept demonstration[END_REF], the authors introduce IP-over-Labeled Optical Burst Switching (LOBS) network to encapsulate multicast messages over a Layer 2 tunneling protocol. OpenFlow is used to build and delete multicast trees using a unified SDN control plane.

CastFlow [START_REF] Cesar Ac Marcondes | CastFlow: Clean-slate multicast approach using in-advance path processing in programmable networks[END_REF] moves IP multicast management to a centralized SDN controller, and IP multicast trees are calculated using OpenFlow. The controller implements the IGMP messaging layer to handle joining/leaving messages when they are received by the first router. Inspired by CastFlow, Software-Defined Multicast (SDM) [START_REF] Rückert | Software-Defined Multicast for Over-the-Top and Overlay-based Live Streaming in ISP Networks[END_REF] was introduced to manage live streaming traffic in the ISP's networks. It combines IP multicast functionality with unicast data delivery using OpenFlow to achieve efficient traffic delivery. SMARTFlow [START_REF] Lopes | SMARTFlow: A Solution for Autonomic Management and Control of Communication Networks for Smart Grids[END_REF] uses an OpenFlow controller to calculate multicast trees based on the Spanning Tree algorithm and encapsulates multicast messages in smart grids over Ethernet MAC addresses. The authors in [START_REF] Jia | A Unified Unicast and Multicast Routing and Forwarding Algorithm for Software-Defined Datacenter Networks[END_REF] present Scalar-pair Vectors Routing and Forwarding (SVRF), which encodes multicast group addresses into scalar-pair vectors to identify outgoing ports for delivery of unicast and multicast packets.

Using a remote SDN controller to perform multicast management was also introduced in OpenFlow Multicast (OFM) [START_REF] Yu | OFM: A Novel Multicast Mechanism Based on OpenFlow[END_REF]. OFM maintains a multicast rule database to store all flow entries for all routers managed by the controller. OFM holds a state database to store multicast group members and their state information. However, in practice it is hard to forecast all possible flow entries that can match against future arriving multicast group members. The Avalanche Routing Algorithm (AvRA) [START_REF] Iyer | Avalanche: Data center Multicast using software defined networking[END_REF] was introduced to minimize the size of the routing tree. It enables efficient bandwidth management by using a centralized SDN controller to gather topology information in DCNs that do not have traditional IP multicast. Likewise, the authors in [START_REF] Zhao | Software defined network-enabled multicast for multi-party video conferencing systems[END_REF] propose building multicast trees for video conferencing by using a SDN controller, where source-based multicast trees are constructed for end-to-end packet delivery.

Our approach in SDMC allows managing multicast communications in overlay data center networks using OpenFlow. Compared to CastFlow, SDMC eliminates periodic join/leave messages generated by IGMP. Rather, by using the topology discovery module, the controller keeps track of all joining and leaving nodes in real-time thereby addressing the hardware resource problem. Furthermore, compared to Avalanche, which achieves data rates up to 12% better than IP multicast, in applications deployed in the Portland Fat Tree topology, SDMC demonstrates a more general framework that can address different topologies like tree, random, mesh, and jellyfish. For instance, SDMC's jellyfish topology, which supports more servers than an equal-cost Avalanche fat-tree topology, achieves often up to 60% better average latency. Moreover, Avalanche gets up to 35% reduction, compared to IP multicast, in the number of links that are less than 5% utilized, once the number of multicast groups exceeds 1,000. In contrast, the performance of SDMC is up to 50% better, compared to IP multicast, in the switch memory utilization, once the number of multicast groups exceeds just 50. Additionally, SDMC provides a monitoring module for traffic monitoring and merging trees to detect the switch between unicast and multicast.

CONCLUSIONS

This paper presented the design, implementation and evaluation of a SDN-enabled multicast solution called SDMC for autonomous, adaptive and flexible network load-aware and switch memory-efficient group communications in data center networks. SDMC, which is provided as a middleware suite, uses a combination of unicast and software-defined multicast, and dynamically switches between them while ensuring that end applications remain agnostic to the i adaptation yet provide superior performance over either only unicast or multicast cases, which ultimately improves the utility of the clouds. Experimental evaluation of our solution shows that SDMC performs up to 50% better compared to IP multicast alone in terms of network load-awareness, and switch-memory utilization efficiency, and up to 60% better for latency performance. SDMC is available in open source at https://github.com/prithviraj6116/sdmc.

Presently, SDMC makes adaptation decisions considering only one criteria at a time, i.e., utilization of network link or switch memory, and does not handle potential oscillations in the adaptation. Our future work will focus on handling them together with weights assigned to each depending on the needs of the group communication traffic. We will also support distributed SDMC controllers using blockchains, which supports novel consensus algorithms to improve controller coordination, consistency, and reliability for holding persistent data sharing and enabling selective privacy.

  Architecture of the SDN-enabled Multicast Approach

Figure 1 :

 1 Figure 1: Comparison between the SDN-enabled Multicast and Traditional IP Multicast

Figure 2 :

 2 Figure 2: Initial SDMC Sender Setup showing External and Internal SDMC-IDs

Figure 3 :

 3 Figure 3: Initial SDMC Receiver Setup

Figure 4 :

 4 Figure 4: Network Link and Switch Memory Monitoring

Figure 5 :

 5 Figure 5: SDMC Architecture

Algorithm 1 :

 1 Joining Multicast Group Data: M e , M i , U r 1 , U r 2 Result: sender or receiver joined SDMC 1 senderJoinRequest(M e ); 2 receiverJoinRequest(M e , U r 1 ); 3 while Listening do 4 if sender then 5 if firstsender then 6 create new M i for M e ; installOFTransRule(M e → M i ) in this sender and in all the existing receivers; 7 else 8 retrieve M i for M e ; installOFTransRule(M e → M i ) in this sender;

  e → U r 1 , U r 2 , ...) in all the senders;

e 2 :

 2 Algorithm Minimum Steiner Multicast Tree and Route CalculationData: M e , N Result: Minimum Steiner Multicast Tree 1 foreach M e in N do 2 if M e ! visited then 3 visited.add(M e );

  i ← t r ee[0] to len(tree) do 8 multicastTree= Steiner(tree,M i , M e );

  multicastTree,M i , M e ); 11 return mul t icastT r ee;

Algorithm 3 : 2 addUnicastDestToSender(U r 1

 321 Adapting to network link and switch memory utilizationData: switch(s1), Link(l1), receiver(r1, U r 1 ), SDMC(M i ) Result: Receiver toggled between multicast and unicast & resource utilization kept under threshold 1 if ThresholdViolationDetect(switch s1) then

Figure 6 :

 6 Figure 6: Setup Latency Induced by Increasing Multicast Senders

Figure 7 :

 7 Figure 7: Initial Receiver Latency for SDMC and IP Multicast

Figure 8 :

 8 Figure 8: Network Overhead for SDMC and IP Multicast

Figure 9 :

 9 Figure 9: Switch-Memory Utilization for SDMC and IP Multicast

Figure 10 :

 10 Figure 10: Packet Loss for SDMC and IP Multicast

  • Topology Management: This NetApp creates a graph topology of all nodes connected to the controller. By manipulating the connected graph, the controller can activate or de-activate the connected routers, hosts and the links connecting them.

	Monitoring	Routing g Topology Management
	SDMC Resource Manager	Topology Discovery
		SDN Controller SD SDN N Co Cont ntroll ller ntro
		Host Host
		OpenFlow
		Switch
	OpenFlow	OpenFlow
	Switch	Switch
	Sender Receiver	OpenFlow
		Switch	Sender Receiver
	SDN Middleware		SDN Middleware
	Host	Sender Receiver	Host Host
		SDN Middleware
		Host
	Yellow is SDMC contributions
	• Monitoring: This NetApp provides real-time reports on vari-
	ous network parameters, such as bandwidth utilization, la-
	tency, packet error rates, resource utilization, etc to the con-
	troller.
	• Routing: This NetApp implements the multicast intelligence
	(explained in Section 2.5.3) to build the dynamic multicast
	routing tree at run-time.

• Resource Manager: This NetApp manages the SDMC ID space and the mapping between the external and internal IDs (explained in Sections 2.5.1 and 2.5.2), and determines and enforces the resource management decisions (explained in Section 2.5.4).

We use SDMC-ID to denote both the identifier space for SDN-enabled multicast as well as the actual external or internal IDs assigned to a flow. Its semantics should be evident from the context. b

SDMC is decoupled from IPMC. Moreover, comparing SDMC performance with other multicast protocols is part of future work.

ACKNOWLEDGMENTS

This work was funded partially by the Fulbright Visiting Scholars Program and NSF CNS US Ignite 1531079. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of NSF, DGA, CNES or the Fulbright program.