Efficient and Green Embedding of Virtual Data Centers with ...supcache.wyqrks.com/data/ontrc.org/Upload/PicFiles/... · IEEE Transactions on Cloud Computing IEEE TRANSACTIONS ON JOURNAL

2168-7161 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for moreinformation.

This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TCC.2019.2897273,IEEE Transactions on Cloud Computing

IEEE TRANSACTIONS ON JOURNAL NAME, MANUSCRIPT ID 1

Efficient and Green Embedding of Virtual Data Centers with Mixture of Unicast and

Multicast Services Chao Guo, Kai Xu, Sanjay Kumar Bose, Senior Member, IEEE, Moshe Zukerman, Fellow, IEEE,

and Gangxiang Shen, Senior Member, IEEE

Abstract—The improved efficiency achieved by virtualizing data centers (DCs) has been well established. In this paper, we

propose a mixed Virtual Data Center (VDC) capable of supporting both unicast and multicast services. We provide a new method

to realize the embedding of these VDCs. We also provide a Mixed Integer Linear Programming (MILP) formulation and a scalable

heuristic algorithm for efficiently embedding its demands. Numerical results show that mixed VDC embedding supporting both

unicast and multicast services performs significantly better than existing embedding methods in terms of system cost, power

consumption, link capacity utilization, and VDC acceptance ratio.

Index Terms—Data center, virtual data center, multicast, unicast

—————————— ——————————

1 INTRODUCTION

LOUD computing has gained significant popularity in cost-effectively supporting new business models such

as Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS), and Software-as-a-Service (SaaS) [1]. However, cur-rent cloud providers mainly offer resources in terms of vir-tual machines (VMs), where the temporal computing-in-tensive peaks in one VM may disturb other VMs. If such cloud providers do not design their networks to specifi-cally guarantee performance isolation, then this may ad-versely affect the performance of the deployed services and the DC resource utilization [2]. To address these weaknesses, new architectures like SecondNet [3], Ok-topus [4], and NetLord [5] have been proposed by fully virtualizing data centers. A virtual data center (VDC) is composed of a set of VMs with assigned computing and storage resources, connected by virtual links with assigned capacity. In this way, infrastructure providers (InPs) like Amazon EC2 [6], Google App Engine [7], and Microsoft Azure [8] can create multiple VDCs on top of shared phys-ical DCs, and then rent these VDCs to service providers (SPs). After the latter obtain one or more VDCs, they can provide cloud services to their end users [2].

To enable VDCs to efficiently share common DC resources spread over many physical nodes and links, VDC embedding is an essential but challenging research problem. Although VDC embedding has some similarity to virtual network embedding (VNE), the former has to overcome a significantly higher complexity because of the large number of nodes in a DC and its complex features [9].

Prior research on VDC embedding has focused on perfor-mance criteria such as system cost [10], energy consump-tion [11], and reliability [12] and have mainly used them to evaluate the performance of unicast services. Many appli-cations in a DC may actually generate a mixture of unicast and multicast traffic. For example, the Hadoop framework consists of two main parts - the MapReduce process and the Hadoop Distributed File System (HDFS) [13]. While a large amount of unicast traffic is there between mappers and reducers [13], multicast traffic also exists during the shuffle stage of the MapReduce procedure and in the HDFS [14]. Using unicast mode alone to also deliver mul-ticast traffic would waste a lot of transmission capacity which would in turn lead to a higher cost (i.e., energy cost and hardware cost) and/or possible violation of quality of service (QoS) requirements (i.e., higher service rejection ra-tios and/or excessive delays).

To overcome these drawbacks, this paper proposes to incorporate native multicasting capability in a DC to con-figure VDCs that can support a mixture of unicast and multicast services. Although multicast embedding has been considered in [15], [16], and [17], these studies focus on backbone networks or wireless mesh networks. Also, although the research in [18], [19], and [20] aims to im-prove efficiency and service quality of data center net-works (DCNs), these do not consider VDCs, nor do they consider supporting both unicast and multicast services in the same VDC. The key novelty and contributions of this paper are as follows. Propose the concept of mixed VDC embedding: In a mixed

VDC, both unicast virtual links and multicast (virtual) trees are present. A multicast tree in a VDC is com-posed of a group of virtual links connecting one source node to all the other destination nodes in the tree. Unlike unicast virtual links, all the virtual links in the virtual tree are unidirectional. Moreover, the

xxxx-xxxx/0x/$xx.00 © 200x IEEE Published by the IEEE Computer Society

————————————————

C. Guo and G. Shen (corresponding author) are with the School of Elec-tronic and Information Engineering, Soochow University, P.R. China. E-mail: [email protected] .

K. Xu and M. Zukerman are with the Department of Electronic Engineer-ing, City University of Hong Kong, Hong Kong SAR, China.

S. K. Bose is with the Department of Electronics and Electrical Engineer-ing, IIT Guwahati, India.

C

mailto:[email protected]



2 IEEE TRANSACTIONS ON JOURNAL NAME, MANUSCRIPT ID

capacities of the virtual links in the tree are equal to each other as they are responsible for delivering the same data from the source node to all the destination nodes in the tree. Also, when embedding a mixed VDC onto a substrate DCN, we fully utilize the native multicast capability of the switch elements to effi-ciently support multicast services in the VDC.

Develop a MILP optimization model for mixed VDC em-bedding which embeds multicast virtual links in a mul-ticast approach: The primary objective of the MILP model is to minimize system cost and energy con-sumption while improving link capacity utilization. This model considers static VDC demands where for a given set of VDC requests, their arrival and holding times and resource requirements are known in ad-vance. This, for example, applies to situations where tenants pre-order VDC services for some time in the future.

Develop an efficient heuristic algorithm to embed mixed VDC in a multicast approach aiming to achieve the same goal as the MILP model: This heuristic algorithm has significantly lower time complexity than the MILP model and can therefore implement mixed VDC em-bedding even for large, realistically sized networks and for network with dynamic service requests.

Simulation studies for scenarios involving both static and dynamic VDC demand: For the static demand, we em-ploy both the MILP model and the heuristic algorithm to implement mixed VDC embedding. Numerical re-sults for small size problems demonstrate the effi-ciency of the proposed heuristic algorithm, which performs close to the MILP model. The numerical results also show that the proposed heuristic algo-rithm based on mixed VDC embedding significantly outperforms a heuristic algorithm where only unicast services are supported (i.e., the algorithm with unicast embedding). We have a similar observation on the performance of the proposed heuristic algo-rithm under dynamic demands, where the algorithm considering mixed VDC embedding achieves signifi-cantly better performance in terms of VDC rejection ratio than both the algorithm with unicast embedding and the approach employed in the SecondNet frame-work.

The remainder of this paper is organized as follows. In Section 2, we survey existing research on VDC embedding. We then introduce the concept of mixed VDC embedding in Section 3. In Section 4, we define the problem of mixed VDC embedding, based on which we further present its MILP model. An efficient heuristic algorithm on how to ef-ficiently embed mixed unicast and multicast services is presented in Section 5. We evaluate the performance of the proposed schemes through simulations in Section 6. Sec-tion 7 concludes the paper.

2 RELATED WORK

2.1 VDC Embedding

The VDC embedding problem is to map required VDC resources such as VMs and virtual link capacities onto

physical servers and links. The existing research on VDC embedding has been limited to being mainly focused on the following directions.

Several publications aim at minimizing energy consumption, in addition to minimizing system cost, through efficient resource mapping. Nam et al. [1] proposed switching off idle servers to reduce power consumption and proposed embedding VMs as close to each other as possible to minimize the communication required. In [11], Ghazisaeedi et al. considered reducing power consumption when embedding MapReduce-based virtual networks onto a DCN. Further, Amokrane et al. [21] proposed reducing power consumption by embedding VDCs onto several different DCs. Yang et al. [22] and Chang et al. [23] considered virtual switches in VDCs and selected servers as close as possible while embedding VMs and mapping virtual switches and links simultaneously so as to reduce both energy consumption and system cost. Zhani et al. [10] proposed reducing energy consumption and system cost by migrating VMs.

There are also studies on reliability. Zhang et al. [12]

proved that the problem of reliable VDC embedding is NP-

hard and proposed a framework called Venice to address

the problem. Wen et al. [9] developed a reliable VDC

embedding framework based on software-defined

networking (SDN). Sun et al. [24] proposed a heuristic

algorithm to embed reliable VDCs across multiple DCNs.

Yu et al. [25] considered survivability for the VDC

embedding problem. Lo et al. [26] proved that the problem

of survivable VDC allocation is NP-hard and proposed a

framework called CALM to provide a solution that

recovers switch failures.

Improving the successful VDC embedding ratio has been another important objective of VDC embedding. In [27], Chowdhury et al. implemented joint embedding for both virtual nodes and links to improve the successful VDC embedding ratio. In [28], Rabbani et al. developed an approach to jointly embed VMs onto servers and virtual switches onto physical switches. In [29], Gilesh et al. improved the successful embedding ratio using an approach that can minimize the fragmentation of residual resource by migrating VMs appropriately.

There are also studies focusing on security [30] and network topology [31]. However, almost all the existing publications on VDC embedding deal only with unicast services and have not considered embedding VDCs with a mixture of both unicast and multicast services.

2.2 Multicast in DCNs

Data centers today have to support a wide variety of ser-vices, of which many are inherently multicast. For example, distributed file systems such as the Google File System (GFS) and the Hadoop Distributed File System (HDFS) use multicasting to deliver the same information from one source node to many destination nodes [14]. Parallel data-base join operations [32], VM provisioning [33], and in-cluster software updating [34] also use multicasting. Therefore, it is important to consider multicasting require-ments when embedding VDCs.



AUTHOR ET AL.: TITLE 3

Several studies have indeed looked into multicast in DCs without considering VDC embedding. Samadi et al. [14] proposed a multicast system for DCNs based on the multicast capability of optical components such as optical splitters. In [35], Li et al. presented efficient and scalable multicast routing algorithms for DCNs. In [36], Saridis et al. presented an all-optical DCN that dynamically offers the multicast capability for VDC applications. However, these studies have only focused on a DCN, but not on VDC em-bedding.

2.3 Summary

In summary, the existing studies on VDC embedding have not considered situations where there is a mixture of unicast and multicast services. Also, although there are studies considering multicast in DCs, these do not focus on the problem of VDC embedding. However, it would be re-alistic to have a VDC today that can support a mixture of both unicast and multicast services. Therefore, it is important to develop effective approaches for VDC em-bedding that would support such a mixture of services. This work contributes to this objective by providing efficient approaches for mixed VDC embedding.

3 MIXED VDC EMBEDDING SUPPORTING BOTH

UNICAST AND MULTICAST SERVICES

In this section, we first introduce a physical DC, then de-scribe how to realize multicast in a DCN, and finally introduce the concept of mixed VDC embedding support-ing both unicast and multicast services.

3.1 Data Centers with VDC Embedding

A physical DC is typically organized as a tree-like topol-ogy in three tiers as shown in Fig. 1. Servers are placed in racks and each server is directly connected to a switch on the top of the rack (i.e., Top-of-Rack (ToR) switch). The ToR switches are further connected to several second-tier switches (i.e., aggregation switches). The latter are further connected to core switches. Optical fibers are only used to interconnect DCN switches, and the links between servers and ToR switches are often made of copper (e.g., Ethernet cables) [37], [38]. In the context of this network layout, the multicast capability can be achieved both in the electronic domain by deploying Internet Protocol (IP multicast), as well as in the optical domain by using passive optical split-ters [14].

The concept of VDC embedding is to use a DC to sup-port multiple VDCs by allowing them to share the common resources of the DC virtually. Fig. 1 illustrates an example involving two VDCs, each of which requires com-puting and storage resources at a VDC node (i.e., VM node) and capacity on a VDC link (i.e., virtual link). Here we are adopting the same definition of a VDC as in, e.g., [1], [3], [9], where no virtual switches are considered in the context of a VDC. There are also publications that consider virtual switches for VDCs, e.g., [22] and [28]. In our opinion, the difference between the two definitions of a VDC are not crucial, but they do differ on whether to explicitly allocate

switching capability to each VDC. With bandwidth guar-anteed for each virtual link of a VDC as in [1], [3], and [9], the VDC essentially possesses virtual switching capability decomposed from physical switches since each virtual link traverses multiple physical switches. The guarantee of vir-tual link bandwidth means the assurance of allocated switching capability at these physical switches.

Fig. 1. DCN and mixed VDC embedding.

In the example of Fig. 1, all virtual resources in VDCs are provided by the physical resources in the DC through a specific mapping relationship. The communication be-tween the VM nodes in a VDC is carried out through either unicast or multicast. In Fig. 1, the unicast traffic is trans-mitted over unicast virtual links (shown by solid lines), which are bidirectional, while the multicast traffic is deliv-ered by multicast trees (shown by dotted lines), each of which is composed of a group of unidirectional virtual links with the same source node and different destination nodes. In addition, all the virtual links on a multicast tree have the same capacity as they transmit the same information from the source node to all the destination nodes in the tree. As an example, VDC2 in Fig. 1 consists of three unicast virtual links and one multicast tree.

3.2 Mapping Multicast Trees for VDCs

Fig. 2 shows an example of mapping a multicast tree for a VDC where the multicast tree is over four VM nodes and three virtual links. Here VM0 is the source node, and VM1, VM2, and VM3 are the destination nodes. The computing resource (in units of CPUs) required by each VM node is shown in the figure. Suppose that the given servers have sufficient computing resources, and the VM nodes VM0, VM1, VM2, and VM3 are mapped onto servers 0, 1, 2, and 3, respectively. Also, assume that the capacity of each vir-tual link in the tree is one unit. Then we can have the fol-lowing two approaches to map these virtual links.

Fig. 2(b) illustrates the multicast approach, which relies on the multicast capabilities in physical switches to sup-port multicast services. Under this approach, a multicast tree can be built with only one unit of link capacity re-served at each physical link traversed by the tree (e.g., Link 4-1). This is because the physical switches traversed by the tree, e.g., Node 4 (switch), can duplicate the information sent from Node 0 (source), and then transmit it to the next physical nodes. Also, for data delivery, only one copy of data processing capacity is required at Node 0.

ToR Switch

Aggregation Switch

Core Switch

VDC1

VDC2

Basic group_1 Basic group_2 Basic group_3

Medium group_1 Medium group_2

Large group_1

Unicast

Virtual Link

Multicast

Tree




(a) A multicast tree

(b) Multicast embedding (c) Unicast embedding

Fig. 2. Embedding a multicast tree based on the unicast and multicast approaches.

In contrast, Fig. 2(c) shows virtual link mapping for a multicast tree using the unicast approach. This requires three independent paths for building each virtual link on the multicast tree, which consumes more capacity on each traversed link. Specifically, three units of capacity are required on link 0-4 and two units of capacity are required on links 4-5 and 5-6, since they are commonly traversed by multiple virtual links to different destination nodes. In addition, since each virtual link is independently deliver-ing data from the source node (Node 0), three copies of data processing capacity should be reserved at the source node. This means extra data processing capacity required at the source node (Node 0). For example, CPU2 (in blue) is the extra data processing capacity that has to be added to Node 0, in addition to the already available CPU0 and CPU1 (in red).

As can be seen from Fig. 2(c), the link from Server 0 to Switch 4 has significantly more unicast traffic than in the scenario when multicast is used (see Fig. 2(b)). Therefore, this link tends to become a bottleneck under heavy loading and this bottleneck tends to become more severe with an increasing number of destination nodes. It may be possible to use a data compression technique to reduce the load on each virtual link so as to alleviate the bottleneck. However, such compression can be done only if it is permitted by the service level agreements (SLA) with users. Moreover, such compression hardly works when the scale of a multicast tree increases substantially. Alternatively, when SLAs do not permit data compression, we have to reject VDCs, which adversely affects revenues. The other option is to augment the capacity of the physical infrastructure, which increases the system cost. However, these problems can be largely avoided when multicast is directly incorporated as shown in Fig. 2(b). Clearly, applying multicast to support multicast services in VDCs improves the utilization effi-ciency of a DC’s resource, reduces CAPEX, and increases revenue and profits as compared with the unicast ap-proach.

4 PROBLEM FORMULATION AND MILP MODEL FOR

MIXED VDC EMBEDDING

As shown by the example in Section 3.2, using unicast VDC

embedding to support multicast services may cause signif-icant wastage of both link capacity and server resources. This wastage may lead to a higher system cost because more servers and links have to be used. In addition, such wastage will cause an increase in power consumption be-cause more equipment has to be deployed and turned on. To avoid this, we propose to employ mixed VDC embed-ding, where while a unicast communication technique is applied to deliver a unicast traffic, the multicast-enabled VDC embedding, shown in Fig. 2(b), is employed for the multicast traffic based on the concept of mixed VDC em-bedding. Next, we introduce the problem definition and then the MILP optimization model and the proposed heu-ristic algorithm.

4.1 Problem Definition

The problem of mixed VDC embedding is defined as fol-lows. We are given a physical DC as the one shown in Fig. 1, which consists of a set of server nodes, a set of switch nodes, and a set of physical links interconnecting these server nodes and switch nodes. Each server node provides resources of CPU, memory, and disk space. The physical links between server nodes and ToR switch nodes are cop-per based (Ethernet cables), while the other links are opti-cal fiber cables. All switches in the DCN are assumed to have multicast capability.

Each VDC request consists of a set of VM nodes, each of which needs resources of CPU, memory, and disk space from a server node. Each VDC may include multiple unicast virtual links, which are used for delivering unicast traffic and are bidirectional. Multicast trees are also config-ured in each VDC, where the virtual links in each tree are used for delivering multicast traffic and are all unidirec-tional (see Fig. 1). The capacity required by each virtual link of a multicast tree is the same, and only one unit of such capacity is reserved on a physical link commonly traversed by these virtual links (as shown in Fig. 2(b)).

We call both unicast virtual links and multicast trees ses-sions. For example, a multicast tree in a VDC is a session with one source node and several destination nodes. Alt-hough a unicast session can be considered as a special case of a multicast session, we distinguish them by using two different demand matrices.

We consider VDC embedding scenarios involving both static and dynamic VDC requests, which are introduced as follows.

4.1.1 Static Scenario

Under the static scenario, all the VDC requests are given in advance. The arrival time and duration of each VDC are also known in advance. This applies to situations where tenants order VDC services for use at some time in the fu-ture. In this case, we aim to minimize physical resources in terms of servers and link capacity used subject to the condition that all the VDCs are embedded onto the physi-cal infrastructure. For this scenario, we formulate the prob-lem as a MILP model that is applicable to embedding VDCs with both unicast and multicast services. We also propose a heuristic algorithm for solving this embedding problem.

VM0 (2)

VM1 (1) VM2 (2) VM3 (1)

# of required

CPUs

02

13

02

13

02

13

02

13

0 1 2 3

1 unit 1 unit

1 unit 1 unit1 unit1 unit

4 6

5

02

13

02

13

02

13

0 1 2 3

4 6

5

02

13

2 units 2 units

3 units

1 unit 1 unit1 unit




4.1.2 Dynamic Scenario

Under the dynamic scenario, VDC requests arrive ran-domly and sequentially. These are then established for a certain period until they finally depart. Here, due to the limitation of physical resources, some requests may be re-jected. Therefore, for this scenario, we aim to minimize the VDC rejection ratio (i.e., the ratio of the total number of rejected requests out of the total number of requests that arrive during the period over which the system is observed), as this would improve the revenue of an InP.

4.2 MILP Model

For the static scenario, we develop a MILP model to embed VDCs optimally. Here for building a multicast tree, we re-fer to the work in [39] when formulating our MILP model. The MILP model is given below.

Sets: 𝑷 Set of server nodes. 𝑺 Set of switch nodes, including ToR, aggregation,

and core switches. 𝑵𝑬𝒎 Set of neighbor nodes of node 𝑚. Here a node

can be a server node or a switch node. 𝑹 Set of server resource types, including CPU,

memory, and disk space. 𝜴 Set of VDC requests. 𝑻 A time sequence or set of times, each of which

corresponds to the arrival time of each considered VDC request.

𝑵𝒊 Set of VM nodes in VDC 𝑖. 𝜰𝒊 Set of multicast sessions in VDC 𝑖. 𝜣𝒊𝒋 Set of VM nodes in multicast session 𝑗 of VDC 𝑖,

represented as [𝑠𝑖𝑗 , 𝑑𝑖𝑗1 , 𝑑𝑖𝑗

2 , … , 𝑑𝑖𝑗

𝐿𝑖𝑗−1], where 𝑠𝑖𝑗

is the source VM node and 𝑑𝑖𝑗1 , 𝑑𝑖𝑗

2 , … , 𝑑𝑖𝑗

𝐿𝑖𝑗−1 are

the destination VM nodes of the session. Parameters: 𝐶𝑟 Capacity of resource type 𝑟 in each server node.

We assume that each server has the same resources.

𝐵𝑚𝑛 Capacity of physical link (𝑚, 𝑛), where m and n are the two end nodes of the link.

𝑡𝑖 The arrival time of VDC request 𝑖. ∆𝑡𝑖 Duration of VDC 𝑖. 𝛽𝑖𝑡 A binary parameter to denote whether VDC 𝑖 is

still active at time 𝑡. Specifically, we have 𝛽𝑖𝑡 =

{1 𝑡𝑖 ≤ 𝑡 < 𝑡𝑖 + ∆𝑡𝑖

0 𝑜𝑡ℎ𝑒𝑟𝑤𝑖𝑠𝑒 ∀𝑖 ∈ 𝜴

𝑅𝐷𝑣𝑖,𝑟 Amount of resource type 𝑟 required by VM

node 𝑣 in VDC 𝑖. 𝐿𝑖𝑗 Number of VM nodes in multicast session j of

VDC 𝑖. 𝜆𝑖𝑗 Virtual link capacity required by multicast

session 𝑗 in VDC 𝑖. Here each virtual link is as-sumed to require the same amount of capacity.

𝜆𝑠𝑑𝑖 Virtual link capacity required by the unicast

session between VM node pair (𝑠, 𝑑) of VDC 𝑖. We assume that there are two opposite unicast sessions between each VM node pair.

𝑃𝑠, 𝑃𝑒 , 𝑃𝑜

Normalized costs of a server, an electronic switch port (which is calculated as the total

switch cost divided by the total number of switch ports), and an optical transponder, respectively. The cost of a switch port does not include the cost of an optical transponder that is plugged into the switch port.

𝛼 A factor used to weigh two optimization objec-tives.

Variables: 𝛿𝑣𝑛

𝑖 A binary variable that takes the value of 1 if VM node 𝑣 of VDC 𝑖 is embedded onto server node 𝑛; 0, otherwise.

𝜔𝑛 A binary variable that takes the value of 1 if server node 𝑛 is used; 0, otherwise.

𝜎𝑚𝑖𝑗 A binary variable that takes the value of 1 if the

tree of multicast session 𝑗 in VDC 𝑖 uses physical node 𝑚; 0, otherwise.

𝜇𝑚𝑛𝑖𝑗

A binary variable that takes the value of 1 if the tree of multicast session 𝑗 in VDC 𝑖 traverses physical link (𝑚, 𝑛); 0, otherwise.

𝜑𝑚𝑛𝑖𝑗

An integer variable that denotes the number of commodity flows of multicast session 𝑗 in VDC 𝑖 that traverse physical link (𝑚, 𝑛).

𝜏𝑛𝑖𝑗

A binary variable that takes the value of 1 if only the destination VM nodes of multicast ses-sion 𝑗 in VDC 𝑖 are mapped onto server node 𝑛, but its source VM node is not mapped onto this server node; 0, otherwise. We call this type of server node destination server node of session j in VDC 𝑖, and it receives data only from this ses-sion.

𝜏𝑖𝑗 An integer variable that denotes the total num-ber of destination server nodes in multicast ses-sion 𝑗 of VDC 𝑖. In general, 0 ≤ 𝜏𝑖𝑗 ≤ 𝐿𝑖𝑗 − 1.

𝜆𝑚𝑛𝑖,𝑠𝑑 A real variable that denotes the amount of traf-

fic for a unicast session between node pair (𝑠, 𝑑) in VDC 𝑖 that traverses physical link (𝑚, 𝑛).

𝜔𝑚𝑛 A binary variable that takes the value of 1 if physical link (𝑚, 𝑛) is used; 0, otherwise.

𝑞𝑠 , 𝑞𝑒 , 𝑞𝑜 Three integer variables that denote the numbers of servers, electronic switch ports, and optical transponders used, respectively.

Our objective is to minimize the total system cost and

the total link capacity used when all the VDC requests are

embedded.

Objective: minimize

𝑃𝑠 ∙ 𝑞𝑠 + 𝑃𝑒 ∙ 𝑞𝑒 + 𝑃𝑜 ∙ 𝑞𝑜 + 𝛼 ∙ (∑ 𝜆𝑖𝑗 ∙𝑖∈𝜴,𝑗∈𝜰𝒊

∑ 𝜇𝑚𝑛𝑖𝑗

𝑚∈𝑷∪𝑺,𝑛∈𝑵𝑬𝒎+

∑ 𝜆𝑚𝑛𝑖,𝑠𝑑

𝑚∈𝑷∪𝑺,𝑛∈𝑵𝑬𝒎,𝑖∈𝜴,𝑠,𝑑∈𝑵𝒊:𝑠≠𝑑 )

(1)

The embedding of all the VDC requests is subject to the

following constraints.

Constraints:

− VM node mapping constraints

∑ 𝛿𝑣𝑛𝑖 ∙ 𝛽𝑖𝑡 ∙ 𝑅𝐷𝑣

𝑖,𝑟𝑖∈𝜴,𝑣∈𝑵𝒊

≤ 𝐶𝑟 ∀𝑟 ∈ 𝑹, 𝑛 ∈ 𝑷, 𝑡 ∈ 𝑻 (2)

∑ 𝛿𝑣𝑛𝑖

𝑛∈𝑷 = 1 ∀𝑖 ∈ 𝜴, 𝑣 ∈ 𝑵𝒊 (3)

𝜏𝑛𝑖𝑗

≥ 𝛿𝑣𝑛𝑖 − 𝛿𝑠𝑖𝑗𝑛

𝑖 ∀𝑖 ∈ 𝜴, 𝑗 ∈ 𝜰𝒊, 𝑛 ∈ 𝑷, 𝑣 ∈ 𝜣𝒊𝒋: 𝑣 ≠

𝑠𝑖𝑗 (4)




𝜏𝑛𝑖𝑗

≤ 1 − 𝛿𝑠𝑖𝑗𝑛𝑖 ∀𝑖 ∈ 𝜴, 𝑗 ∈ 𝜰𝒊, 𝑛 ∈ 𝑷 (5)

𝜏𝑛𝑖𝑗

≤ ∑ 𝛿𝑣𝑛𝑖

𝑣∈𝜣𝒊𝒋 ∀𝑖 ∈ 𝜴, 𝑗 ∈ 𝜰𝒊, 𝑛 ∈ 𝑷 (6)

𝜏𝑖𝑗 = ∑ 𝜏𝑛𝑖𝑗

𝑛∈𝑷 ∀𝑖 ∈ 𝜴, 𝑗 ∈ 𝜰𝒊 (7)

− Multicast link mapping constraints

∑ 𝜇𝑚𝑛𝑖𝑗

𝑚∈𝑵𝑬𝒏= 𝜎𝑛

𝑖𝑗 ∀𝑖 ∈ 𝜴, 𝑗 ∈ 𝜰𝒊, 𝑛 ∈ 𝑺 (8)

𝜎𝑛𝑖𝑗

≥ 𝛿𝑣𝑛𝑖 ∀𝑖 ∈ 𝜴 𝑗 ∈ 𝜰𝒊, 𝑣 ∈ 𝜣𝒊𝒋, 𝑛 ∈ 𝑷 (9)

𝜎𝑛𝑖𝑗


𝑣∈𝜣𝒊𝒋 ∀𝑖 ∈ 𝜴, 𝑗 ∈ 𝜰𝒊, 𝑛 ∈ 𝑷 (10)


= 𝜏𝑛𝑖𝑗

∀𝑖 ∈ 𝜴, 𝑗 ∈ 𝜰𝒊, 𝑛 ∈ 𝑷, 𝑚 ∈ 𝑵𝑬𝒏 (11)

∑ 𝜇𝑛𝑚𝑖𝑗

𝑚∈𝑵𝑬𝑛≥ 𝜎𝑛

𝑖𝑗 ∀ 𝑖 ∈ 𝜴, 𝑗 ∈ 𝜰𝒊, 𝑛 ∈ 𝑺 (12)

𝜇𝑛𝑚𝑖𝑗

≥ 𝛿𝑠𝑖𝑗𝑛𝑖 − ∑ 𝛿𝑣𝑛

𝑖𝑣∈𝜣𝒊𝒋:𝑣≠𝑠𝑖𝑗

(𝐿𝑖𝑗 − 1)⁄

∀𝑖 ∈ 𝜴, 𝑗 ∈ 𝜰𝒊, 𝑛 ∈ 𝑷, 𝑚 ∈ 𝑵𝑬𝒏 (13)


≤ 1 − 𝜏𝑛𝑖𝑗

∀ 𝑖 ∈ 𝜴, 𝑗 ∈ 𝜰𝒊, 𝑛 ∈ 𝑷, 𝑚 ∈ 𝑵𝑬𝒏 (14)



𝑣∈𝜣𝒊𝒋 ∀𝑖 ∈ 𝜴, 𝑗 ∈ 𝜰𝒊, 𝑛 ∈ 𝑷, 𝑚 ∈ 𝑵𝑬𝒏 (15)

− Commodity flow constraints for creating a tree

∑ 𝜑𝑛𝑚𝑖𝑗

𝑚∈𝑵𝑬𝒏= ∑ 𝜑𝑚𝑛

𝑖𝑗𝑚∈𝑵𝑬𝒏

∀𝑖 ∈ 𝜴, 𝑗 ∈ 𝜰𝒊, 𝑛 ∈ 𝑺 (16)

𝜑𝑛𝑚𝑖𝑗

≤ (𝐿𝑖𝑗 − 1) ∙ 𝛿𝑠𝑖𝑗𝑛𝑖 ∀𝑖 ∈ 𝜴, 𝑗 ∈ 𝜰𝒊, 𝑛 ∈ 𝑷, 𝑚 ∈

𝑵𝑬𝒏

(17)


≤ 𝜏𝑖𝑗 ∀𝑖 ∈ 𝜴, 𝑗 ∈ 𝜰𝒊, 𝑛 ∈ 𝑷, 𝑚 ∈ 𝑵𝑬𝒏 (18)


≥ 𝜏𝑖𝑗 − (𝐿𝑖𝑗 − 1) ∙ (1 − 𝛿𝑠𝑖𝑗𝑛𝑖 ) ∀𝑖 ∈ 𝜴, 𝑗 ∈

𝜰𝒊, 𝑛 ∈ 𝑷, 𝑚 ∈ 𝑵𝑬𝒏

(19)


≤ (𝐿𝑖𝑗 − 1) ∙ (1 − 𝛿𝑠𝑖𝑗𝑛𝑖 ) ∀ 𝑖 ∈ 𝜴, 𝑗 ∈ 𝜰𝒊, 𝑛 ∈

𝑷, 𝑚 ∈ 𝑵𝑬𝒏

(20)


≥ 𝜏𝑛𝑖𝑗

∀𝑖 ∈ 𝜴, 𝑗 ∈ 𝜰𝒊, 𝑛 ∈ 𝑷, 𝑚 ∈ 𝑵𝑬𝒏 (21)


≤ 𝜑𝑚𝑛𝑖𝑗

∀𝑖 ∈ 𝜴, 𝑗 ∈ 𝜰𝒊, 𝑛 ∈ 𝑷 ∪ 𝑺, 𝑚 ∈ 𝑵𝑬𝒏 (22)

(𝐿𝑖𝑗 − 1) ∙ 𝜇𝑚𝑛𝑖𝑗

≥ 𝜑𝑚𝑛𝑖𝑗

∀𝑖 ∈ 𝜴, 𝑗 ∈ 𝜰𝒊, 𝑛 ∈ 𝑷 ∪𝑺, 𝑚 ∈ 𝑵𝑬𝒏

(23)

− Unicast link mapping constraints

∑ 𝜆𝑛𝑚𝑖,𝑠𝑑

𝑚∈𝑵𝑬𝑛− ∑ 𝜆𝑚𝑛

𝑖,𝑠𝑑𝑚∈𝑵𝑬𝑛

= 𝜆𝑠𝑑𝑖 ∙ (𝛿𝑠,𝑛

𝑖 − 𝛿𝑑,𝑛𝑖 )

∀𝑖 ∈ 𝜴, 𝑠, 𝑑 ∈ 𝑵𝒊: 𝑠 ≠ 𝑑, 𝑛 ∈ 𝑷

(24)

∑ 𝜆𝑛𝑚𝑖,𝑠𝑑

𝑚∈𝑵𝑬𝑛− ∑ 𝜆𝑚𝑛

𝑖,𝑠𝑑𝑚∈𝑵𝑬𝑛

= 0 ∀𝑖 ∈ 𝜴, 𝑠, 𝑑 ∈

𝑵𝒊: 𝑠 ≠ 𝑑, 𝑛 ∈ 𝑺

(25)

− Link capacity constraint

∑ 𝛽𝑖𝑡 ∙ 𝜆𝑚𝑛𝑖,𝑠𝑑

𝑖∈𝜴,𝑠,𝑑∈𝑵𝒊:𝑠≠𝑑 + ∑ 𝛽𝑖𝑡 ∙ 𝜇𝑚𝑛𝑖𝑗

∙ 𝜆𝑖𝑗𝑖∈𝜴,𝑗∈𝜰𝒊≤

𝐵𝑚𝑛 ∀𝑛 ∈ 𝑷 ∪ 𝑺, 𝑚 ∈ 𝑵𝑬𝒏, 𝑡 ∈ 𝑻

(26)

− Active server constraints

𝜔𝑛 ≥ 𝛿𝑣𝑛𝑖 ∀𝑖 ∈ 𝜴, 𝑣 ∈ 𝑵𝑖 , 𝑛 ∈ 𝑷 (27)

𝜔𝑛 ≥ 𝜇𝑚𝑛𝑖𝑗

∀𝑖 ∈ 𝜴, 𝑗 ∈ 𝜰𝒊, 𝑛 ∈ 𝑷, 𝑚 ∈ 𝑵𝑬𝒏 (28)

𝜔𝑛 ≥ 𝜇𝑛𝑚𝑖𝑗

∀𝑖 ∈ 𝜴, 𝑗 ∈ 𝜰𝒊, 𝑛 ∈ 𝑷, 𝑚 ∈ 𝑵𝑬𝒏 (29)

𝜆𝑠𝑑𝑖 ∙ 𝜔𝑛 ≥ 𝜆𝑚𝑛

𝑖,𝑠𝑑 ∀𝑖 ∈ 𝜴; 𝑠, 𝑑 ∈ 𝑵𝒊: 𝑠 ≠ 𝑑, 𝑛 ∈ 𝑷, 𝑚 ∈ (30)

𝑵𝑬𝒏

𝜆𝑠𝑑𝑖 ∙ 𝜔𝑛 ≥ 𝜆𝑛𝑚

𝑖,𝑠𝑑 ∀𝑖 ∈ 𝜴; 𝑠, 𝑑 ∈ 𝑵𝒊: 𝑠 ≠ 𝑑, 𝑛 ∈ 𝑷, 𝑚 ∈𝑵𝑬𝒏

(31)

− Active switch port constraints

𝜔𝑛𝑚 ≥ 𝜇𝑛𝑚𝑖𝑗

∀ 𝑖 ∈ 𝜴, 𝑗 ∈ 𝜰𝒊, 𝑛 ∈ 𝑷 ∪ 𝑺, 𝑚 ∈ 𝑵𝑬𝒏 (32)

𝜔𝑛𝑚 ≥ 𝜇𝑚𝑛𝑖𝑗

∀ 𝑖 ∈ 𝜴, 𝑗 ∈ 𝜰𝒊, 𝑛 ∈ 𝑷 ∪ 𝑺, 𝑚 ∈ 𝑵𝑬𝒏 (33)

𝜔𝑛𝑚 ≤ ∑ 𝜇𝑛𝑚𝑖𝑗

𝑖∈𝜴,𝑗∈𝜰𝒊+ ∑ 𝜇𝑚𝑛

𝑖𝑗𝑖∈𝜴,𝑗∈𝜰𝒊

+

∑ 𝜆𝑛𝑚𝑖,𝑠𝑑 + 𝜆𝑚𝑛

𝑖,𝑠𝑑𝑖∈𝜴;𝑠,𝑑∈𝑵𝒊:𝑠≠𝑑 ∀𝑛 ∈ 𝑷 ∪ 𝑺, 𝑚 ∈ 𝑁𝐸𝑛

(34)

𝜆𝑠𝑑𝑖 ∙ 𝜔𝑛𝑚 ≥ 𝜆𝑛𝑚

𝑖,𝑠𝑑 ∀𝑖 ∈ 𝜴; 𝑠, 𝑑 ∈ 𝑵𝒊: 𝑠 ≠ 𝑑, 𝑛 ∈𝑷, 𝑚 ∈ 𝑵𝑬𝑛

(35)

𝜆𝑠𝑑𝑖 ∙ 𝜔𝑛𝑚 ≥ 𝜆𝑚𝑛

𝑖,𝑠𝑑 ∀𝑖 ∈ 𝜴; 𝑠, 𝑑 ∈ 𝑵𝒊: 𝑠 ≠ 𝑑, 𝑛 ∈𝑷, 𝑚 ∈ 𝑵𝑬𝑛

(36)

− Numbers of servers and switch ports used

𝑞𝑒 = 𝑞𝑠 = ∑ 𝜔𝑛𝑛∈𝑷 (37)

𝑞𝑜 = ∑ 𝜔𝑛𝑚𝑛∈𝑺,𝑚∈𝑵𝑬𝒏∩𝑺 (38)

VM node mapping constraints: Constraint (2) ensures the resource restriction, including CPU, memory, and disk space, of each server at any time. Constraint (3) ensures that each VM node is mapped onto only one physical server node. This is always true since a VM cannot be split and mapped onto different servers. Constraints (4)-(6) de-cide whether server node n is a destination server node of session j in VDC i. Specifically, if server node 𝑛 hosts at least one destination VM node of session 𝑗 in VDC 𝑖, but does not host the source VM node of the session, then 𝑛 is considered a destination server node of session 𝑗 in VDC 𝑖. Constraint (7) finds the total number of destination server nodes in session j of VDC i.

Multicast link mapping constraints: Constraint (8) en-sures that every switch node that belongs to a multicast tree has one incoming edge on the tree. Constraints (9) and (10) ensure that if there is any VM node of session j in VDC i mapped onto server node n, then the server node must belong to the multicast tree of the session. Constraint (11) ensures that each destination server node must have an in-coming edge on the tree of the multicast session. Con-straint (12) ensures that each switch node used by a mul-ticast session has at least one outgoing edge on the mul-ticast tree. Constraint (13) ensures that if a server node n hosts the source VM node of a multicast session and there is at least one destination VM node hosted by a different server node, then server node n has one outgoing edge on the tree. Constraint (14) ensures that a destination server node of a session does not have any outgoing edge on the tree. Constraint (15) ensures that if there is no VM node mapped onto a server node, then this server node does not have any outgoing edge on the tree.

Commodity flow constraints for creating a tree: Con-straints (16)-(23) are the flow-conservation equations for successfully creating a tree topology [39]. Specifically, Constraint (16) ensures that at an intermediate switch node, the total number of outgoing flows equals that of incoming flows. Constraints (17)-(19) ensure that the total number of




outgoing flows from a source server node equals the total number of destination server nodes in a session, and the number of outgoing flows from a destination server node is zero. Constraint (20) ensures that there is no incoming flow for the source server node of a session. Constraint (21) ensures that each destination server node has one incom-ing flow. Constraints (22) and (23) ensure that if the num-ber of commodity flows in a multicast session that uses a physical link is greater than zero, then this physical link must be used by this multicast session.

The set of “Multicast link mapping constraints” (i.e., (8)-(15)) plus the set of “Commodity flow constraints for cre-ating a tree” (i.e., (16)-(23)) jointly ensure to create a mul-ticast tree for each multicast session.

Unicast link mapping constraints: Constraints (24) and (25) jointly ensure flow conservation for all the unicast ses-sions.

Link capacity constraint: Constraint (26) ensures that the total capacity of all the unicast and multicast commu-nication sessions of all the active VDCs that traverse a com-mon physical link does not exceed the total capacity of the link.

Active server and switch port constraints: Constraint (27) ensures that if there is a VM node mapped onto a server node, then this server node must be active. Con-straints (28)-(31) ensure that if there is any incoming or out-going traffic for any server node, then this server node must be active. Constraints (32)-(36) decide whether a physical link is used. Constraints (37)-(38) find the total numbers of servers and switch ports used.

The computational complexity of an ILP model is decided by the dominant number of variables and con-straints. In this model, the dominant number of variables is at the level of 𝑂(|𝜴| ∙ |𝑽|2 ∙ |𝑵| ∙ |𝑵𝑬|) due to variable 𝜆𝑚𝑛

𝑖,𝑠𝑑, where |𝜴| is the total number of VDC requests, |𝑽| is the total number of VMs in each VM node set 𝑵𝒊 (𝑖 ∈ 𝜴), |𝑵| is the total number of physical nodes, and |𝑵𝑬| is the total number of neighbor nodes in each set 𝑵𝑬𝒎 (𝑚 ∈ 𝑷 ∪𝑺). The dominant number of constraints is at the level of 𝑂(|𝜴| ∙ |𝑽|2 ∙ |𝑷| ∙ |𝑵𝑬|) due to constraints (35) and (36), where |𝑷| is the total number of server nodes in the physi-cal network.

To minimize the total numbers of server nodes and link capacity used, VM nodes in a VDC should be mapped onto as few server nodes as possible. This, however, would af-fect the reliability of this VDC as the failure of a single server node would then affect many VM nodes of the VDC [9]. Therefore, to ensure the VDC’s reliability, we add a new constraint (39) to require a server node to hold only up to K VM nodes of a VDC. Without losing generality, this study has set K=1 for high reliability.

∑ 𝛿𝑣𝑛𝑖

𝑣∈𝑵𝑖≤ 𝐾 ∀𝑖 ∈ 𝜴, 𝑛 ∈ 𝑷 (39)

In addition, if a unicast session is seen as a special case of a multicast session with only two VM nodes intercon-nected by one virtual link, then for simplicity we may use a unified model to remove all the unicast parameter 𝜆𝑠𝑑

𝑖 , variable 𝜆𝑚𝑛

𝑖,𝑠𝑑 and constraints (24)-(25), (30)-(31), and (35)-

(36). Also, constraints (26) and (34) can be simplified by re-moving the unicast variables and parameters, and the ob-jective function can be simplified to

𝑃𝑠 ∙ 𝑞𝑠 + 𝑃𝑒 ∙ 𝑞𝑒 + 𝑃𝑜 ∙ 𝑞𝑜 + 𝛼 ∙

∑ 𝜆𝑖𝑗 ∙ 𝜇𝑚𝑛𝑖𝑗

𝑚∈𝑷∪𝑺,𝑛∈𝑵𝑬𝒎,𝑖∈𝜴,𝑗∈𝜰𝒊

(40)

5 HEURISTIC ALGORITHM FOR MIXED VDC

EMBEDDING

Although the MILP model can provide an optimal solution, the time complexity increases rapidly when the problem scales up, and the model becomes computationally infea-sible to use. Because of this, we also develop a heuristic al-gorithm, which can solve the mixed VDC embedding problem in a short time and can achieve a performance close to that of the MILP model. This heuristic algorithm is described next.

Specifically, as in [3], we divide the server nodes into groups of different sizes. Servers hosted in the same rack are grouped to form a basic group. Then these basic groups are further combined to form larger groups. As shown in Fig. 1, these larger groups can be the combination of any two basic groups or may even consist of all the basic groups. We sort these server groups according to their sizes in ascending order. If there are groups with the same number of servers, then we further sort these groups, in descending order, according to the numbers of active serv-ers in each. The purpose of the second sorting is to enable the group that has more active servers to embed VDCs ear-lier so as to reduce the use of servers and link capacity. We denote this ordered group list as 𝓛. For any VDC request, the algorithm scans 𝓛 to find the first eligible group to em-bed the VDC. The pseudocode of this VDC embedding al-gorithm is shown in Fig. 3. The algorithm includes two key steps, i.e., VM node mapping and virtual link mapping, whose details are given next.

Embed a VDC 1. For a server group 𝑔 in 𝓛 //𝓛 is the server group list

2. If(MatchNodes()==false) // VM node mapping 3. Continue; //turn to the next server group

4. Else 5. Allocate resources for VM nodes;

6. flag=false; 7. For each communication session in the VDC

8. flag=BuildMulticastTree(); //virtual link mapping 9. If (flag==false) //not enough residual link capacity for this session

10. Break; //turn to the next server group 11. Else

12. Allocate resources for virtual links 13. If (flag==false)

14. Withdraw resources allocated to the VDC 15. Else

16. Return success.

Fig. 3. Pseudocode of the proposed VDC embedding algorithm.

Procedure of VM node mapping: This step implements the function MatchNodes() in the pseudocode of Fig. 3. For each server group that is eligible to embed a VDC, we as-sign resources available on server nodes in the group to each VM node of the VDC in a way as shown in Fig. 4. We




first sort the VM nodes in the VDC according to their CPU resource requirements in descending order. We also sort the server nodes in the group according to their remaining CPU capacities in ascending order. In Fig. 4, the VM nodes are displayed in descending order on the left-hand side, and the server nodes are displayed in ascending order on the right side. Then we get a VM node from the left-hand side list to find an eligible server node that can provide suf-ficient resources. These include CPU, memory, and disk space required by the VM, as well as the ingress and egress capacities of the VM. The egress capacity required by a VM is the sum of traffic demands of all the sessions where this VM is a source node. The ingress capacity is the sum of traffic demands of all sessions where this VM is a destina-tion node. If it is possible for this server node to provide all these capacities, then we use it to map this VM node. We repeat the same process for the subsequent VM nodes in the VM node list until they are all mapped. The right-most column in Fig. 4 shows the resource status of the server nodes after mapping. This mapping process aims to mini-mize the mismatch of CPU resources between VM nodes and their mapped server nodes, thereby reducing the num-ber of active server nodes required. In the above process, we have also considered the constraint that VM nodes be-longing to a common VDC should not be mapped onto a common server node.

Fig. 4. Mapping VM nodes onto server nodes with the least CPU mismatch.

Procedure of virtual link mapping: This step imple-ments the function BuildMulticastTree() in the pseudocode of Fig. 3. After successfully mapping the VM nodes onto the server nodes, this step maps each communication ses-sion by building a multicast tree on a physical tree topol-ogy. Here we consider each unicast request as two mul-ticast sessions with two VM nodes and that they are in op-posite directions. Before building the multicast tree, we re-move all the links from the physical topology that do not have enough remaining capacity to serve the session. For each session, we first create an empty tree . Then, we add its source server node and the ToR switch that the server node directly connects to, and the link connecting these two nodes, to . Next, for each destination server node, we run Dijkstra’s algorithm based on the physical topology to find a switch node S in that is the nearest to this server node. Then we find the shortest route from S to the server node. Finally, we augment by adding the links and nodes on the route that are new to . We repeat this process for all the destination nodes and create a multicast

tree for the multicast session. As done for the server node mapping, when mapping

virtual links, we also first use as many as possible of those switch nodes that are already active to avoid turning on new switches. New switches are turned on only if the cur-rently active switches cannot accommodate a session.

The main parts of the above algorithm are the proce-dures of VM node mapping and virtual link mapping, which are of polynomial computational complexities. The computational complexity of the VM node mapping pro-cedure is 𝑂(|𝑽| ∙ 𝑙𝑜𝑔|𝑽| + |𝑮| ∙ 𝑙𝑜𝑔|𝑮|) when fast sorting al-gorithms are used, where |𝑽| is the total number of VM nodes in the VDC request and |𝑮| is the total number of servers in a server group considered. The computational complexity of building a multicast tree is 𝑂(|𝑵|2 ∙ |𝜣|) , where |𝑵| is the total number of physical nodes and |𝜣| is the total number of VM nodes in a multicast session. Thus, the computational complexity of the virtual link mapping procedure is 𝑂(|𝑵|2 ∙ |𝜣| ∙ |𝜰|), where |𝜰| is the total num-ber of sessions in the VDC request. Consequently, the over-all computational complexity for embedding a VDC is 𝑂((|𝑽| ∙ 𝑙𝑜𝑔|𝑽| + |𝑮| ∙ 𝑙𝑜𝑔|𝑮| + |𝑵|2 ∙ |𝜣| ∙ |𝜰|) ∙ |𝓛|) , where |𝓛| is the total number of server groups considered.

The algorithm described above embeds one VDC. When embedding multiple VDCs, there are some differences for the algorithms under the static and dynamic VDC request scenarios.

5.1 Static Scenario

Under the static scenario, the information on all the VDC requests, including their arriving and holding times, will be given in advance. We aim to minimize the total system cost and the power consumption subject to the condition that all the VDC requests are successfully embedded. For this, we first assume that there are sufficient DC resources including servers and link capacity. Once all the VDCs are embedded, we remove all the inactive equipment (includ-ing servers and switches) not actually being used from the system and then find the corresponding performance re-sults in terms of system cost, power consumption, etc.

It is important to observe that the embedding results are influenced by the order, in which VDCs are embedded. Therefore, we consider applying a shuffling process to op-timize results. Specifically, we have a time sequence 𝑻, and for each time 𝑡 ∈ 𝑻, there can be multiple VDC requests that are active at 𝑡 (in other words, their service durations cross 𝑡). We first shuffle the times in 𝑻 many times, and then for each 𝑡 ∈ 𝑻, we further shuffle many times the VDC requests that are active, but have not been embedded yet at the time t being considered. Next, we embed these shuf-fled unserved VDC requests one by one for each time t in the shuffled time sequence T. The above embedding pro-cess under different shuffling sequences will lead to differ-ent system performance in terms of system cost and energy consumption. We calculate the objective value based on (1) for each of the shuffled sequences to select the one with the smallest value of the objective function.

.

3

2

2

2

4

3

2

VDCServer group

(Before embedding)

0

0

4

0

Server group(After embedding)

VMServer

Requested CPUs

Remaining CPUs




5.2 Dynamic Scenario

Under the dynamic scenario, VDC requests arrive ran-domly and sequentially. They provide cloud services to us-ers for a certain period and finally depart. Each time a VDC request arrives, we embed it using the above heuristic al-gorithm. If the embedding process is successful, we allo-cate resources to this VDC; otherwise, we reject this VDC request. When the lifespan of a VDC is over, we withdraw the resources allocated to it. We keep on simulating this VDC dynamic arrival and departure process. After simulating a certain large number (e.g., 106) of VDC re-quests, we count the total number of rejected VDC requests and calculate the rejection ratio as the number of rejected VDC requests divided by the total number of arriving VDC requests.

6 SIMULATIONS AND PERFORMANCE ANALYSES

In this section, we evaluate the performance of the pro-posed mixed VDC embedding. We consider both the static and dynamic demand scenarios. Under the static scenario, we consider system cost, link capacity utilization, and power consumption as the evaluation metrics. Under the dynamic scenario, we consider the rejection ratio of VDC requests as an evaluation measure.

6.1 Test Conditions

We employ the VL2 topology of [40] for the DCN. One test case (i.e., Case 1) consists of 15 servers connected by 3 ToR switches, and further connected by 2 aggregation switches and 2 core switches. Another test case (i.e., Case 2) consists of 300 servers, 6 ToR switches, 4 aggregation switches, and 4 core switches. The link between each server and a ToR switch is a twisted copper wire with a 1-Gb/s capacity. The links between the switches are optical fibers, each of which has a 10-Gb/s capacity. Each server hosts 8 CPUs, 64-GB memory, and 500-GB disk space. The price of a 1-Gb/s cop-per switch port is normalized to be 1 unit. The price of each 10-Gb/s switch port with an optical transponder plug-in is set to be 100 units and the price of a server is set to be 1300 units. Note that all these prices are set based on their cur-rent market prices.

In Case 1, the number of VM nodes per VDC (i.e., M) is set to vary from 2 to 8. The number of CPUs required by each VM node varies from 1 to 3, the memory requirement varies from 0 to 32 GB, and the disk space requirement varies from 0 to 100 GB. Multicast sessions in a VDC are randomly generated and the number of sessions per VDC varies from 1 to M. The number of VM nodes in each mul-ticast session varies from 3 to M. As a special case, the number of VM nodes in each unicast session is always 2. The virtual link capacity in each session varies from 40 Mb/s to 100 Mb/s.

In Case 2, we set the number of VM nodes per VDC to vary from 2 to 15, while all the other parameters are the same as those of Case 1. Since a DC may not be able to serve a VDC with a unicast approach when the number of VMs in a multicast session is too large, we limit the number of VMs in a session to 8 or less for the static scenario, so that all the VDCs can be successfully embedded for both

unicast and multicast approaches. Of course, such a con-straint is not needed for the dynamic scenario.

For performance comparison, we also evaluate the per-formance based on unicast embedding, where for each des-tination node in a multicast session, an independent unicast session is set up. Moreover, as the source node needs to process multiple unicast sessions independently for each destination node, additional CPUs are required compared to the implementation based on multicast ses-sions. Here, we assume that the data delivery process of each session (either multicast or unicast) consumes 1/3 unit of CPU resource at the session source node. Therefore, the number of extra CPUs required when applying the unicast embedding approach to embed a multicast session is ⌈(𝐿𝑖𝑗 − 2)/3⌉ where ⌈∙⌉ is the ceiling of a decimal number “∙” and 𝐿𝑖𝑗 is the total number of VM nodes in a session (see Section 4.2). In addition, the embedding algorithm em-ployed in the SecondNet framework [3] is also considered for comparison. Specifically, for each VDC, the algorithm first selects a candidate server group, and then builds a bi-partite graph with the VM nodes of the VDC on one side and the server nodes in the server group on the other side. Then the algorithm further adds edges between each pair of VM node and server node as long as the server node has enough capacity to hold the VM node. Then, the algorithm transforms the VM mapping problem to a minimum cost flow problem, and completes the VM mapping process by solving the problem. For more details on the algorithm, please refer to [3]. In addition, for the fairness of perfor-mance comparison, we also apply the same shuffling pro-cess as described earlier to the algorithm of SecondNet when embedding a set of VDC requests under the static scenario.

We employ the commercial software AMPL/Gurobi to solve the MILP model, for which in (1) is set it to be 0.01 by considering the minimization of the system cost as the first priority, and the MIPGAP is set to be 0.01%. We used Java to implement the heuristic algorithm.

6.2 Simulation Results

6.2.1 Static Scenario

For the static scenario, we consider both Cases 1 and 2. We randomly generate floating-point numbers with a uniform distribution to represent the arriving time and duration of each VDC request. Without losing generality, we normal-ize the arriving time of each VDC to vary from 0 to 1 and its duration to vary from 0.5 to 1. We use the arrival times of all VDCs to construct the time sequence 𝑻 (as defined in Section 4.2).

For the shuffling process, the total number of shuffles is dependent on the number of VDCs to be embedded. Spe-cifically, for the smaller case, i.e., Case 1, if the factorial of the number of VDC requests is no more than 10,000, then the number of shuffles for the time sequence is set to be the previous factorial value; otherwise, it is set to be 10,000. Similarly, for shuffling of VDC requests at each time 𝑡 ∈ 𝑻, if the factorial of the number of VDC requests not yet em-bedded is 10,000 or less, then the number of corresponding shuffles is set to be the previous factorial value; otherwise, it is set to be 10,000. In Case 2, due to its much larger system




size, we set both the shuffle times for the time sequence and the VDC requests not embedded at each time 𝑡 ∈ 𝑻 to be 100.

We evaluate the performance in terms of system cost, link capacity utilization, and energy consumption, which are analyzed as follows.

1) System cost: We first evaluate the total system cost re-quired for accommodating all the VDC requests. The sys-tem cost is the sum of the costs of the servers and the elec-tronic and optical switch ports, weighted by their normal-ized market prices. Fig. 5(a) shows the results of the small test case (i.e., Case 1), in which “Uni” corresponds to the case of using unicast technique to support multicast ses-sions, “Multi” corresponds to the case of mixed VDC em-bedding, “Model” corresponds to the results obtained by the MILP model, and “Alg” corresponds to the results ob-tained by the heuristic algorithm. “SecondNet” corre-sponds to the results found using the algorithm of Second-Net [3].

Based on these results, we find that the mixed VDC em-bedding can significantly reduce the system cost compared to the unicast embedding, i.e., up to 24%. This is because the multicast approach consumes much less capacity when embedding multicast virtual links, thereby significantly re-ducing the number of switches used. On the other hand, using the unicast approach to support multicast sessions consumes more CPU capacity, which increases the number of servers used. As a result, the mixed VDC embedding needs significantly fewer physical resources including switches and servers, and therefore, shows a much lower system cost.

In addition, comparing the results of the MILP model and the heuristic algorithm, we see that the results of the heuristic algorithm match those of the MILP model reason-ably well. They have almost the same performance except when the numbers of VDCs are around 7~9. Actually, the difference here is minor as it is only the cost difference of one server and one electronic switch port, i.e., for these VDC values, the heuristic algorithm requires one server and one electronic switch port more than the MILP model.

Similar studies were also carried out for Case 2, for which results are shown in Fig. 5(b). Here we do not pro-vide the results for the MILP model as it is computationally intractable to run the model for a large number of servers and VDCs. However, we provide the results obtained by the SecondNet embedding approach as a benchmark. Comparing the results of the unicast and mixed embed-ding, we again see that the latter significantly outperforms the former, i.e., by up to 19%. This once again shows the efficiency of the proposed mixed embedding approach. Moreover, comparing with the benchmark scheme, we find that the mixed embedding approach significantly out-performs the SecondNet embedding approach, i.e., by up to 20%. This, therefore, shows the efficiency of the pro-posed mixed VDC embedding approach. In addition, it is interesting to see that the unicast embedding approach proposed in this paper and the embedding approach of SecondNet perform very similarly. This is because both of them use multiple unicast virtual links to construct a mul-ticast tree, but do not employ the multicasting capability of the physical tree as proposed in the mixed VDC embed-ding scheme.

2) Link capacity utilization: As the second optimization objective, we also minimize the link capacity used. Fig. 6(a) shows the results of this for Case 1. Overall, we see that performance trends are similar to those observed for the system cost. The mixed embedding approach can signifi-cantly outperform the unicast embedding approaches, i.e., by more than 45%. Moreover, the results of the MILP model and the heuristic algorithm based on mixed embed-ding are very close to each other, which indicates the effi-ciency of the proposed algorithm. A similar performance comparison is also made for the larger test case, i.e., Case 2, whose results are shown in Fig. 6(b). As before, we see that the mixed embedding approach is more efficient and significantly outperforms the unicast embedding approach, i.e., by up to 53%. SecondNet’s performance is almost the same as that of the unicast embedding approach as they are both based on unicast link mapping.

(a) Case 1

(b) Case 2

Fig. 5. System costs of the different approaches.

8

10

12

14

16

18

20

4 6 8 10 12

Sy

ste

m C

os

t (x

100

0)

# of VDCs

Multi_Model

Uni_Model

24.8%

Multi_Alg

17

19

21

23

25

27

29

31

33

26

80 90 100 110 120 130 140

Sy

ste

m C

os

t (x

100

00)

# of VDCs

Multi_Alg

Uni_Alg

SecondNet

20.1%

19%




(a) Case 1

(b) Case 2

Fig. 6. Link capacity utilization of the different approaches.

3) Power consumption: We also evaluate the power con-sumption of the system based on the term 𝐸𝑠 ∙ 𝑞𝑠 + 𝐸𝑒 ∙ 𝑞𝑒 +𝐸𝑜 ∙ 𝑞𝑜 , where 𝐸𝑠 , 𝐸𝑒 , and 𝐸𝑜 are the average power con-sumptions of a server, a 1-Gb/s electrical switch port, and a 10-Gb/s optical switch port, respectively. We set their values to be 400 W, 9 W, and 82 W, respectively. Note that these data were once again derived from the power con-sumption data of actual products in the market. Fig. 7 shows the results of power consumption for the different approaches. The mixed embedding approach always con-sumes less power (i.e., by up to 24%) than that for the unicast embedding approach. The result trend is very sim-ilar to that of the system cost shown in Fig. 5. This is rea-sonable as the multicast embedding approach can reduce the numbers of servers and switch ports compared to the unicast embedding approach, thereby reducing power consumption.

(a) Case 1

(b) Case 2

Fig. 7. Power consumption of the different approaches.

6.2.2 Dynamic Scenario

For the dynamic scenario, we only consider Case 2. We evaluate the performance of the heuristic algorithm of mixed embedding in term of the VDC rejection ratio, which is defined as the total number of rejected VDC re-quests divided by the total number of VDC requests that arrived during the simulation run.

As described earlier, under the dynamic scenario, VDC requests arrive randomly and sequentially. The arrival and holding time of each VDC request is not known in advance. In our experiment, we assume that VDC requests arrive following a Poisson arrival process with arrival rate re-quests/hour and the duration of each VDC service follows an exponential distribution with mean 1/. Here we nor-malize the mean duration 1/ to be 1 hour. A total of 106 VDC request arrivals were simulated to compute the VDC rejection ratio.

The results of the VDC rejection ratio with an increasing arrival rate are shown in Fig. 8. We can see that the mixed embedding approach can significantly outperform both the unicast embedding approach and the approach em-ployed by SecondNet. This is reasonable because the mixed embedding approach needs fewer physical re-sources to provision a VDC, which enables provisioning of more VDCs given the limited physical resources of the sys-tem. Consequently, the mixed embedding approach can achieve a lower VDC rejection ratio.

Fig. 8. Rejection ratio change with an increasing VDC request arrival rate.

3

5

7

9

11

13

15

4 6 8 10 12

Lin

k C

pa

cit

y U

tiliza

tio

n (

Gb

/s)

# of VDCs

Multi_Model

Multi_AlgUni_Model

45.7%

100

150

200

250

300

350

80 90 100 110 120 130 140

Lin

k C

ap

ac

ity

Uti

liza

tio

n (

Gb

/s)

# of VDCs

Multi_Alg

Uni_Alg

SecondNet

53.5%

Multi_Alg

2.5

3.0

3.5

4.0

4.5

5.0

5.5

6.0

6.5

7.0

4 6 8 10 12

Po

wer

Co

nsu

mp

tio

n (

kW

)

# of VDCs

Uni_Model

Multi_Model

24.5%

19%

55

65

75

85

95

105

115

80 90 100 110 120 130 140

Po

wer

Co

nsu

mp

tio

n (

kW

)

# of VDCs

Multi_Alg

Uni_Alg

SecondNet

20.1%

1.00E-03

1.00E-02

1.00E-01

1.00E+00

90 100 110 120 130 140 150

Reje

cti

on

Ra

tio

Arrival rate

Multi_Alg

Uni_Alg

SecondNet




We also evaluate how the capacity required by each VDC multicast session can impact the VDC rejection ratio. Fig. 9 illustrates the VDC rejection ratio changes with an increasing average capacity requirement of each multicast session. Here the arrival rate of VDC requests is set to be 100 requests/hour, which corresponds to a 100-erlang traf-fic load. The average capacity of each multicast session changes from 50 Mb/s to 200 Mb/s with a 50-Mb/s step-size. For each average capacity X Mb/s, we then randomly generate a specific capacity whose value is uniformly distributed within the range of [X-30, X+30] Mb/s for each multicast session. Based on the results in Fig. 9, we can see that with an increasing average capacity of multicast ses-sions, the VDC rejection ratio increases since each mul-ticast session consumes more resources at a higher average capacity requirement. Moreover, we observe that the per-formance difference between the unicast embedding and multicast embedding approaches becomes more signifi-cant under a higher average capacity requirement. The im-provement of the rejection ratio is only 0.022 when the av-erage capacity requirement of a multicast session is 50 Mb/s, while this improvement increases to 0.45 when the average capacity requirement of a multicast session grows to 250 Mb/s. This is because, compared to the mixed em-bedding approach, the unicast embedding approach wastes more system resources at a higher average capacity requirement when it uses multiple unicast virtual links to construct a multicast tree for a multicast session.

Fig. 9. Rejection ratio change with an increasing average capacity requirement of multicast sessions.

6.2.3 Computational Time

As in other publications on VDC embedding [1], [3], [22], we also evaluate the time consumption for embedding a VDC when its size scales up. We consider Case 2 because it considers a larger-size problem, and here the test condi-tions are the same as those presented earlier in Section 6.1. We also limit the number of VMs in each session to 8 for each VDC as was done for the static scenario earlier. We measure the execution times by embedding different VDC requests on a 3.40-GHz Intel Core i7 with 8-GB memory and. The results of computation times are shown in Fig. 10. From the results, we can see that the proposed mixed em-bedding approach is significantly faster than the approach used by SecondNet. Moreover, as the scale of a VDC grows,

the difference between them becomes even more pro-nounced. Specifically, when the size of a VDC is 28, the ap-proach used by SecondNet takes 580% more time than that of the mixed embedding approach. This is reasonable be-cause when mapping VMs, the approach of SecondNet needs to build a bipartite graph and then run minimum cost flow algorithm based on the graph, whose computa-tional complexity is higher than that of the proposed ap-proach in this paper. In addition, because the unicast and multicast embedding approaches adopt the same category of algorithm, they have very close time consumptions for embedding a VDC.

Fig. 10. Time consumption for embedding a VDC by the different

approaches.

7 CONCLUSION

Considering the inefficiency of using the unicast tech-

nique to transmit data for multicast services, we pro-

pose a mixed VDC embedding approach, which em-

ploys the multicasting capability of switches to carry

multicast sessions in VDCs. To minimize the system

cost and the resource consumption, we develop a MILP

model and a heuristic algorithm to solve the problem of

proposed mixed VDC embedding. Simulation results

show that for the static VDC demand, the proposed

mixed embedding approach can significantly

outperform its unicast counterpart to reduce the system

cost, link capacity unitization, and power consumption

by up to as much as 37%, 55%, and 38%, respectively. In

addition, the heuristic algorithm is efficient and per-

forms close to the MILP model. We also evaluate the

performance of the proposed mixed VDC embedding

approach in a dynamic VDC demand scenario. It is

found that the mixed VDC embedding approach is also

efficient to significantly reduce the VDC rejection ratio

compared to the unicast-only approaches.

ACKNOWLEDGMENT

This work was jointly supported by National Natural Sci-ence Foundation of China (NSFC) (61671313), the Science and Technology Achievement Transformation Project of Jiangsu Province, PR China (BA2016123), and by a grant

1.00E-03

1.00E-02

1.00E-01

1.00E+00

50 100 150 200 250

Re

jeti

on

Rati

o

Average Capacity Requirement of Multicast Sessions (Mb/s)

Multi_Alg

Uni_Alg

SecondNet

0.45

0.022

Multicast

5

15

25

35

45

55

65

75

85

95

105

115

4 8 12 16 20 24 28

Tim

e C

on

su

mp

tio

n (

ms)

VDC Size (#VM)

SecondNet

Unicast

587.5%




from the Research Grants Council of the Hong Kong Spe-

cial Administrative Region, China (CityU 11200318).

REFERENCES

[1] T. M. Nam, N. V. Huynh, L. Q. Dai, and N. H. Thanh, “An en-

ergy-aware embedding algorithm for virtual data centers,” in

Proc. International Teletraffic Congress (ITC) 2016.

[2] M. F. Bari et al., “Data center network virtualization: A survey,”

IEEE Communications Surveys & Tutaorials, vol. 15, no. 2, pp. 909-

928, second quarter, 2013.

[3] C. Guo et al., “SecondNet: A data center network virtualization

architecture with bandwidth guarantees,” in Proc. ACM CoN-

EXT 2010.

[4] H. Ballani, P. Costa, T. Karagiannis, and A. Rowstron, “Towards

predictable datacenter networks,” in Proc. ACM SIGCOMM 2011.

[5] J. Mudigonda et al., “NetLord: A scalable multi-tenant network

architecture for virtualized datacenters,” in Proc. ACM

SIGCOMM 2011.

[6] Amazon Elastic Compute Cloud (Amazon EC2) http://aws.am-

azon.com/ec2/.

[7] Google App Engine. http://appengine.google.com/ .

[8] Microsoft Azure. http://azure.microsoft.com/ .

[9] X. Wen, Y. Han, B. Yu, X. Chen, and Z. Xu, “Towards reliable

virtual data center embedding in software defined networking,”

in Proc. MILCOM 2016.

[10] M. F. Zhani, Q. Zhang, G. Simon, and R. Boutaba, “VDC Planner:

Dynamic migration-aware virtual data center embedding for

clouds,” in Proc. IFIP/IEEE International Symposium on Integrated

Network Management 2013.

[11] E. Ghazisaeedi and C. Huang, “GreenMap: Green mapping of

MapReduce-based virtual networks onto a data center network

and managing incast queueing delay,” Elsevier Computer Net-

works, vol. 112, pp. 345-359, Jan. 2017.

[12] Q. Zhang, M. F. Zhani, M. Jabri, and R. Boutaba, “Venice: Relia-

ble virtual data center embedding in clouds,” in Proc. INFOCOM

2014.

[13] T. White, Hadoop: The Definitive Guide, CA, USA: O’Reilly Me-

dia, 2012, ISBN: 978-1-449-31152-0.

[14] P. Samadi et al., “Optical multicast system for data center net-

works,” Optics Express, vol. 23, no.17, pp. 22162-22180, Aug. 2015.

[15] X. Gao et al., “Multicast service-oriented virtual network map-

ping over elastic optical networks,” in Proc. ICC 2015.

[16] D. Liao, G. Sun, V. Anand, and H. Yu, “ Survivable provisioning

for multicast service oriented virtual network requests in cloud-

based data centers,” Elsevier Optical Switching and Networking, vol.

14, part 3, pp. 260-273, Aug. 2014.

[17] P. Lv, Z. Cai, J. Xu, and M. Xu, “Multicast service-oriented virtual

network embedding in wireless mesh networks,” IEEE Commu-

nications Letters, vol. 16, no. 3, pp. 375-377, Mar. 2012.

[18] J. Duan, Z. Guo, and Y. Yang, “Cost efficient and performance

guaranteed virtual network embedding in multicast fat-tree

DCNs,” in Proc. INFOCOM 2015.

[19] J. Duan, Z. Guo, and Y. Yang, “Embedding nonblocking mul-

ticast virtual networks in fat-tree data centers,” in Proc. IEEE In-

ternational Parallel and Distributed Processing Symposium 2015.

[20] S. Ayoubi, C. Assi, K. Shaban, and L. Narayanan, “MINTED:

Multicast virtual network embedding in cloud data centers with

delay constraints,” IEEE Transactions on Communications, vol. 63,

no. 4, pp. 1291-1305, Apr. 2015.

[21] A. Amokrane, M. F. Zhani, R. Langar, R. Boutaba, and G. Pujolle,

“Greenhead: Virtual data center embedding across distributed

infrastructures,” IEEE Transactions on Cloud Computing, vol. 1, is-

sue 1, pp. 36-49, Jan.-Jun. 2013.

[22] Y. Yang, X. Chang, J. Liu, and L. Li, “Towards robust green vir-

tual cloud data center provisioning,” IEEE Transactions on Cloud

Computing, vol. 5, no. 2, pp. 168-181, Apr.-Jun. 2017.

[23] X. Chang et al., “Green cloud virtual network provisioning based

ant colony optimization,” in Proc. Annual Conference Companion

on Genetic and Evolutionary Computation 2013.

[24] G. Sun, S. Bu, V. Anand, V. Chang, and D. Liao, “Reliable virtual

data center embedding across multiple data centers,” in Proc. the

1st Conference on Internet of Things and Big Data 2016.

[25] R. Yu, G. Xue, X. Zhang, and D. Li, “Survivable and bandwidth-

guaranteed embedding of virtual clusters in cloud data centers,”

in Proc. INFOCOM 2017.

[26] H. Lo and W. Liao, “CALM: survivable virtual data center allo-

cation in cloud networks,” in IEEE Transactions on Services Com-

puting, to appear. doi:10.1109/TSC.2017.2777979.

[27] M. Chowdhury, M. R. Rahman, and R. Boutaba “Vineyard: Vir-

tual network embedding algorithms with coordinated node and

link mapping,” IEEE/ACM Transactions on Networking, vol. 20, no.

1, pp. 206-219, Feb. 2012.

[28] M. G. Rabbani et al., “On tackling virtual data center embedding

problem,” in Proc. IFIP/IEEE International Symposium on Inte-

grated Network Management 2013.

[29] M. P. Gilesh, S. D. M. Kumar, L. Jacob, and U. Bellur, “Towards

a complete virtual data center embedding algorithm using

hybrid strategy,” in Proc. ICDCS 2017.

[30] W. Hou, Z. Ning, L. Guo, Z. Chen, and M. S. Obaidat, “Novel

framework of risk-aware virtual network embedding in optical

data center networks,” IEEE Systems Journal, vol. 12, no. 3, pp.

2473 - 2482, Sep. 2018.

[31] P. Yi and B. Ramamurthy, “Network-aware virtual data center

resource orchestration in an optical data center,” in Proc. ICNC

2017.

[32] W. Mach and E. Schikuta, “Parallel database join operations in

heterogeneous grids,” in Proc. International Conference on Parallel

and Distributed Computing, Applications and Technologies 2007.

[33] R. N. Calheiros, R. Ranjan, and R. Buyya, “Virtual machine pro-

visioning based on analytical performance and QoS in cloud

computing environments,” in Proc. IEEE ICPP 2011.

[34] “Twitter murder: Fast data center code deploy using bittorrent,”

http://engineering.twitter.com/2010/07/murder-fast-datacen-

ter-code-deploys.html.

[35] D. Li, Y. Li, J. Wu, S. Su, and J. Yu, “ESM: efficient and scalable

data center multicast routing,” IEEE/ACM Transactions on Net-

working, vol. 20, no. 3, pp. 944-955, Jun. 2012.

[36] G. M. Saridis et al., “LIGHTNESS: A deeply-programmable SDN-

enabled data centre network with OCS/OPS multicast/unicast

switch-over,” in Proc. ECOC 2015.

[37] C. Kachris and I. Tomkos, “A survey on optical interconnects for

data centers,” IEEE Communications Surveys & Tutorials, vol. 14,

no. 4, fourth quarter 2012.

[38] L. Zhao, W. Hu, and X. Zhang, “Architecture and performance

of grouped ROADM rings with shared optical amplifier and

grouped add/drop ports for hybrid data center network,” Else-

vier Optical Switching and Networking, vol. 23, part 1, pp. 1-4, Jan.

2017.

[39] B. Mukherjee, Optical WDM Networks, Springer, 2016, ISBN:978-

http://aws.amazon.com/ec2/

http://aws.amazon.com/ec2/

http://appengine.google.com/

http://azure.microsoft.com/




0-387-29055-3

[40] A. Greenberg et al., “VL2: A scalable and flexible data center net-

work,” in Proc. SIGCOMM 2009.

Chao Guo is currently pursuing his master’s degree with the School of Electronic and Infor-mation Engineering, Soochow University. His research interest is network virtualization.

Kai Xu is now with Department of Electronic Engineering, City University of Hong Kong, Kowloon, Hong Kong as a Ph.D. student. His research interests are in the areas of broad-band networks, optical networks, and network virtualization.

Sanjay Kumar Bose (SM’91) received the B.Tech. Degree from IIT Kanpur in 1976, and the Master’s, and the Ph.D. from SUNY Stony Brook, USA, in 1977 and 1980, respectively. He was with the Corporate R&D Centre of the General Electric Co., Schenectady, NY, USA, till 1982. He joined IIT Kanpur as an Assistant Professor and became a Professor in 1991. He left IIT Kanpur in 2003 and joined the School of EEE, NTU, Singapore, as a Faculty Member. In 2008, he left NTU to join IIT Guwahati where

he is currently a Professor with the Department of EEE. He has been involved in various areas in the field of computer networks and queue-ing systems and has published extensively in the area of optical networks and network routing. He is a fellow of IETE (India), and a member of Sigma Xi and Eta Kappa Nu.

Moshe Zukerman (M’87–SM’91–F’07) re-ceived his B.Sc. and M.Sc. degrees from the Technion, Israel, and his Ph.D. degree in engi-neering from University of California, Los Ange-les, in 1985. He was an independent Consultant with the IRI Corporation and a Postdoctoral Fel-low with the University of California, Los Ange-les, in 1985–1986. During 1986–1997, he was with Telstra Research Laboratories. He also taught and supervised graduate students at

Monash University in 1990–2001. During 1997– 2008, he was with The University of Melbourne, Victoria, Australia. In 2008 he joined City University of Hong Kong as a Chair Professor of Information Engineer-ing, and a team leader. He has over 300 publications in scientific jour-nals and conference proceedings. He has served on various editorial boards and contributed to numerous conference technical committees.

Gangxiang Shen (S’98–M’99–SM’12) received the B.Eng. degree from Zhejiang University, China, the M.Sc. degree from Nanyang Technological University, Singapore, and the Ph.D. degree from the University of Alberta, Canada, in 2006. He is a Distinguished Professor with the School of Elec-tronic and Information Engineering of Soochow University in China. Before he joined Soochow Uni-versity, he was a Lead Engineer with Ciena, Linthi-cum, Maryland. He was also an Australian ARC

Postdoctoral Fellow with the University of Melbourne. His research in-terests include integrated optical and wireless networks, spectrum ef-ficient optical networks, and green optical networks. He has authored and co-authored over 150 peer-reviewed technical papers. He is a Lead Guest Editor of the IEEE Journal on Selected Areas in Commu-nications Special Issue on ‘‘Next-Generation Spectrum-Efficient and Elastic Optical Transport Networks,’’ and a Guest Editor of the IEEE Journal on Selected Areas in Communications Special Issue on ‘‘En-ergy-Efficiency in Optical Networks.’’ He is currently an Associate Ed-itor of the IEEE/OSA Journal of Optical Communication and Network-ing, and an Editorial Board Member of Optical Switching and Network-ing and Photonic Network Communications. He was a Secretary for the IEEE Fiber-Wireless (FiWi) Integration Sub-Technical Committee. He received the Young Researcher New Star Scientist Award in the ‘‘2010 Scopus Young Researcher Award Scheme’’ in China. He was a recipient of the Izaak Walton Killam Memorial Award from the Uni-versity of Alberta and the Canadian NSERC Industrial Research and Development Fellowship. He was selected as “Highly Cited Chinese Researcher’’ by Elsevier in 2014-2017. He was elected as IEEE Com-Soc Distinguished Lecturer (2018-2019). He is also a voting member of IEEE ComSoc Strategic Planning Standing Committee (2018-2019).

Documents

Efficient and Green Embedding of Virtual Data Centers with ...supcache.wyqrks.com/data/ontrc.org/Upload/PicFiles/... · IEEE Transactions on Cloud Computing IEEE TRANSACTIONS ON JOURNAL