Quality of Service Aware Virtual Network Mapping ... - IEEE Xplore

Globecom 2013 Workshop - Cloud Computing Systems, Networks, and Applications

Quality of Service Aware Virtual Network Mapping Across Multiple Domains Hao Di1, Vishal Anand2, Hongfang Yu1, Lemin Li1, Dan Liao1,3 and Gang Sun1,3 1

Key Lab of Optical Fiber Sensing and Communications (Ministry of Education), University of Electronic Science and Technology of China, Chengdu, China 2 Department of Computer Science, The College at Brockport, State University of New York, USA 3 Institute of Electronic and Information Engineering in Dongguan, UESTC, China {dihao, yuhf, gangsun, liaodan}@uestc.edu.cn, [email protected]

Abstract—Network virtualization allows the coexistence of multiple virtual networks on a shared substrate network. A virtual network created by a service provider (SP) typically spans across multiple domains that may be managed by different infrastructure providers (InPs). The topology and resource information on each domain is confidential and kept private by the InP. However, a domain-level view is required to achieve quality of service (QoS)-aware VN mapping across multiple domains. In this paper, we present a framework for the QoSaware VN mapping across multiple domains. In the framework, the VN mapping is accomplished by the mapping manager that is the broker between the SPs and the InPs. The mapping manager collects the mapping candidates for the VN request from the InPs, and then establishes the abstracted domain-level graph. Finally the candidates are selected on the domain-level graph with QoS consideration. We formulate the problem of candidate selection as an integer linear programming (ILP) and also present a heuristic algorithm to solve it. The simulation results show that our proposed framework can achieve low resource allocation cost and good QoS performance for the VN request. Keywords: network virtualization, multiple domains, virtual network mapping, QoS performance, domain-level graph

I.

INTRODUCTION

Network virtualization [1-4] is regarded as a solution that can prevent Internet ossification and offer more flexibility without extensive network redesign. Using virtualization multiple heterogeneous network architectures can cohabit on a shared substrate network. Virtualization technology is also a business enabler that allows agile deployment of various applications and services with increased flexibility while optimizing the use of infrastructure resources as well as reducing the cost of maintaining them. Each request in a virtualized network environment is modelled as a virtual network (VN), consisting of virtual nodes interconnected by virtual links. It is essential to address the VN mapping problem for enabling network virtualization. The VN mapping problem is the allocation of substrate network resources to satisfy the constraints of the virtual nodes and links of the VN, e.g., satisfying the required computing resources on the virtual nodes and the bandwidth resources of the virtual links.

This research was partially supported by the National Grand Fundamental Research 973 Program of China under Grant (No. 2013CB329103), Natural Science Foundation of China grant (No. 61271171, No. 61001084), Sichuan Youth Science and Technology Fund (No. 2012JQ0020), Program for New Century Excellent Talents in University (No.NCET-11-0058), the Fundamental Research Funds for the Central Universities (ZYGX2010J002, ZYGX2012J004, ZYGX2010J009), Guangdong Science and Technology Project (2012B090500003, 2012B091000163, 2012556031), and Science and Technology Research Projects of Chongqing Municipal Education Commission under Grant KJ120523. The research of Dr. Vishal Anand©2013IEEE is supported in part by the Provost476 978-1-4799-2851-4/13/$31.00

The underlying substrate network typically consists of multiple administrative domains provided by Infrastructure Providers (InPs). Each InP deploys and manages the physical network resources in its domain and offers their resources to the Service Providers (SPs). Each SP leases the resources from multiple InPs to create and deploy the VN for end users [4]. An InP can map the VN request in its administrative domain using the intra-domain algorithms proposed in [5-11] as the InP has the complete knowledge of its domain. However, when the VN request is mapped across multiple domains (e.g., to satisfy location, resource efficiency constraints) there is no global view of the underlying substrate as InPs in different domains do not expose or share their topology and resource information with each other. In this work we propose a scheme that uses a broker between the InPs and the SPs to enable the InPs to cooperate and accomplish the VN mapping across multiple domains. The work in [12,13] proposes decentralized VN mapping frameworks to address VN mapping across multiple domains. In [12] the VN request is partitioned into several VN subgraphs, and each subgraph is mapped by an InP in its domain. Finally, the inter-domain virtual links interconnecting the VN subgraphs (in different domains) are mapped onto inter-domain paths. In [13] the VN request is sent to all InPs; an InP then partially maps the received VN request and forwards the residual part to other InPs in a recursive manner. After the mapping of virtual nodes is determined in different domains, the inter-domain virtual links are mapped. These works can map the VN request across multiple domains without knowing the topology and resource information of the individual domains. However, they do not take into account quality of service (QoS) considerations which are important to meet the service level agreements (SLAs) between the SPs and InPs, which in turn impacts the QoS service received by the end users. For example, when the VN is used for social network services or online gaming, the delay on virtual links will affect the experience of end users. Hence, it is necessary to evaluate and estimate the QoS performance to guide the mapping of virtual nodes and links, e.g., virtual links should be mapped onto the paths on which the time delay is acceptable. When the VN request is mapped across multiple domains, QoS evaluation can be viewed in two levels:

Globecom 2013 Workshop - Cloud Computing Systems, Networks, and Applications

domain 1

domain 1 a

domain 3 domain 2

b a

c

(b)

domain 1

b1

domain 3

domain 2

c (a)

b

a

b

(c) domain 1

a1 domain 3

domain 2

c3

a2

b

a

(d)

domain 3

c

domain 2

b3

(e)

Fig. 1. Example of VN mapping across multiple domains with the proposed framework

· At the intra-domain level the InP can evaluate QoS performance for the partial VN mapping since the InP has the complete knowledge of the domain and the mapping. · At the domain level the QoS performance involving the inter-domain mapping such as delay on inter-domain VI links should also be evaluated to guide the domain-level mapping. For example, if the end node of an interdomain virtual link can be mapped in different domains, it is necessary to determine the domain in which the end node should be mapped for better QoS performance on the inter-domain virtual link. Thus a domain-level view is necessary to evaluate inter-domain QoS performance. In [12,13] the mapping of the inter-domain virtual links is not coordinated with the intra-domain mapping (i.e., are done in separate phases). In this paper we present a QoS-aware VN mapping framework that considers both intra-domain QoS and inter-domain QoS for VN mapping, and also determines the intra-domain and inter-domain VN mapping in the same phase. In our framework, the mapping manager receives the VN request from the SP, and cooperates with the InPs to find the VN mapping. In each domain the InP finds the candidates for mapping the virtual nodes and links while considering the intra-domain QoS. The InPs then offer the intra-domain candidates to the mapping manager bidding for the virtual nodes and links in the VN request, and cooperate with the mapping manager to find inter-domain link candidates that interconnect intra-domain node candidates. The mapping manager collects these candidates and pricing provided by InPs to establish a domain-level graph and selects the candidates from the graph with (intra-domain and inter-domain) QoS and cost consideration, i.e., intra-domain and inter-domain VN mapping is determined in the same phase. The rest of the paper is organized as follows. Section II formulates the multi-domain QoS-aware VN mapping problem. Section III describes our QoS-aware VN mapping framework. Section IV presents the ILP and the heuristic algorithm for candidate selection. Section V presents the simulation results, and Section VI concludes the paper. II.

PROBLEM STATEMENT

In this section we formulate the problem of QoS-aware VN mapping across multiple domains.

477

A. Substrate Network The underlying substrate network is modeled as a weighted undirected graph GS = (VS, ES), where VS is the set of substrate nodes and ES is the set of substrate links. The substrate consists of N domains interconnected by inter-domain links, as shown in Fig. 1(a). The domain managed by the k-th (1≤k≤N) InP is also modeled as a weighted undirected graph GS,k = (VS,k, ES,k), where VS,k is the set of substrate nodes in the domain k and ES,k is the set of intra-domain substrate links in the domain k. ES,I is the set of inter-domain substrate links. Then GS is GS,1∪GS,2 ∪…∪GS,N∪ES,I. The available computing capacity (e.g., CPU) on the node n ∈ VS is represented by CS(n). Each (intra-domain or interdomain) substrate link is denoted by l = (i, j)∈EN where i and j are the end nodes of l. Note that, the end nodes of an interdomain link are the border nodes in different domains. The available bandwidth on the substrate link l is represented by BS(l). The unit capacity price (or cost to the SP) of substrate nodes and links is denoted by uN(n) and uL(l) respectively. We use d(l) to represent the delay on the substrate link l∈EN. B. VI Request Similarly, we model a VN request as an undirected graph GV = (VV, EV), where VV and EV are the sets of virtual nodes and links (as shown in Fig. 1(b)). The required computing capacity (CPU) of the virtual node n∈VV is represented by CV(n). Each virtual link is denoted by l =(i, j)∈EV, where i and j are the end nodes of l. The required bandwidth on the virtual link l is represented by BV(l). C. VN Mapping Across Multiple Domains The VN request is mapped across multiple domains with the virtual nodes mapped onto different substrate nodes, and the virtual links mapped onto the substrate paths so as to satisfy the resource requirements of the virtual nodes and links. In the domain-level mapping, the fact that the virtual node nV∈NV is mapped in the domain GS,k is represented by D(nV) = k. nV →GS,k: D(nV) = k, nV∈VV, GS,k Í GS The virtual links may be mapped within a domain or across domains. The substrate path on which the virtual link lV∈EV is

Globecom 2013 Workshop - Cloud Computing Systems, Networks, and Applications

mapped is denoted by p(lV). We use D(lV) = k to represent the fact that lV is mapped in the domain GS,k, i.e., the links of the path are in GS,k. lV →GS,k: D(lV) = k, lV∈VV, GS,k Í GS For example, as shown in Fig. 1(e), the virtual node a is mapped in domain 2, and the virtual nodes b and c and the virtual link (b, c) are mapped in domain 3.When D(i) and D(j) are not the same (i.e., D(i) ≠ D(j)), the virtual link (i, j)∈EV is an inter-domain virtual link that passes through the interdomain substrate links. Based on the domain-level VN mapping the VN request is partitioned into H subgraphs which are interconnected by interdomain virtual links. Each subgraph contains the virtual nodes and links that are mapped in the same domain. The i-th (1≤ i ≤H) subgraph of GV is represented by GV,i = (VV,i, EV,i), where VV,i ( Í VV) and EV,i ( Í EV) are the sets of the virtual nodes and links in the subgraph. EV,C is the set of all the inter-domain virtual links, and GV is GV,1∪GV,2∪…∪GV,H∪EV,C. For the intra-domain mapping when the VN subgraph GV,i (1≤ i ≤H) is mapped in GS,k (1≤k≤N), M(nV) = nS represents the fact that the virtual node nV in GV,i is mapped onto the substrate node nS in GS,k. And M(lV) = p(lV) represents the fact that the intra-domain virtual link lV in GV,i is mapped onto the substrate path in GS,k. The mapping of virtual nodes is subject to the computing capacity constraints and location constraints, and the mapping of virtual links is subject to the bandwidth capacity constraints. The problem of intra-domain VN mapping is formulated in [5-11], so we do not present the formulation in this work specifically. In this work we consider both the cost of the allocated resources (of the VN request) to the SPs and the time delay on virtual links. The node mapping cost of nV, which is the product of the cost of unit capacity and the used capacity is defined as in (1).

f (nV ) = u N ( M (nV )) * CV (nV )

(1)

The mapping of the inter-domain virtual link lV is similar to that of an intra-domain virtual link, subject to the available bandwidth on the substrate. Similarly, M(lV) = p(lV) represents the fact that the inter-domain virtual link lV is mapped onto the inter-domain path p(lV). Then the cost fP(lV) of mapping the (intra-domain or inter-domain) virtual link lV is defined as in (2), which is the sum of the bandwidth cost on the links of the path p(lV), where the bandwidth cost on a link is the product of the unit cost of bandwidth and the allocated bandwidth.

f P (lV ) =

å

lS Î p (lV )

uL (lS )* CV (lV )

fQ (lV ) = a (lV )

å

lS Î p ( lV )

d (lS )

(2) (3)

The QoS performance fQ(lV) is defined as in (3), where fQ(lV) is the sum of the time delays on all the substrate links used by virtual link lV, i.e., the delay of the mapped path. The parameter

478

α(lV) represents the importance or weight of the delay on lV among all virtual links. The larger the value of α(lV) the more important the virtual link lV. We use the utility function f(lV) to define the mapping cost of the virtual link lV, as in (4).

f (lV ) = f P (lV ) + b * fQ (lV )

(4)

As shown in (4), the mapping cost of lV is the sum of the cost of used resources and the QoS performance. The parameter β represents the weight associated with the QoS performance, and is also used to make the orders of magnitude of fP(lV) and fQ(lV) the same. Then the VN mapping cost f is defined as in (5). Our aim is to minimize f.

f =

å

nV ÎVV

f (nV ) +

å

lV ÎEV

(5)

f (lV )

III. THE FRAMEWORK In this section, we present the framework for QoS-aware VN mapping across multiple domains. A. Framework Design SP

VN request step 1

Mapping manager step 5

VN request

Domain-level graph

step 2

InP 1

step 4

Find candidates

Candidate selection … step 6

InP 2 Find candidates

InP N …

Find candidates

step 3

Domain 1

Domain 2

Domain N

Fig. 2. The framework of QoS-aware VN mapping across multiple domains

For QoS-aware VN mapping the QoS performance should be estimated to guide the VN mapping both in the intra-domain level and the domain level. For the intra-domain level, the QoS performance can be evaluated by the InP with the complete knowledge of its administrative domain. A domain-level view is needed to guide the domain-level mapping based on the inter-domain QoS performance. Since the domain information is unavailable, our framework uses a bidding mechanism to get a domain-level view, i.e., InPs bid for the virtual nodes and links of the VN request. The bid and the QoS performance for a virtual node and/or link can be regarded as a mapping candidate. The set of all the candidates for both intra-domain and inter-domain mapping then form the abstracted domainlevel view. Both the intra-domain and inter-domain VN mapping is determined by selecting the candidates with the aim of minimizing the VN mapping cost (defined in (5)) for SPs.

Globecom 2013 Workshop - Cloud Computing Systems, Networks, and Applications

Our mapping framework is shown in Fig. 2, where the mapping manager acts as the broker between the SP and the InPs, aiming to minimize the VN mapping cost. After receiving the VN request from the SP (step 1 in Fig. 2), the mapping manager sends the request to all InPs (step 2). Each InP then computes the intra-domain mapping to find the candidates for the virtual nodes and links (step 3). The mapping manager collects the candidates from InPs and forms an abstracted domain-level view (step 4). Based on the domain-level graph the candidates are selected (step 5) to accomplish the VN mapping. Finally the mapping manager sends the selection to InPs for instantiation (step 6). B. Finding Candidates When an InP receives the VN request, it computes the intra-level VN mapping to find the feasible mapping for the virtual nodes and links. The works in [5-11] propose several intra-domain mapping algorithms, which can be used by the InPs (with modification for partial mapping) to find candidates according to its policy, e.g., minimizing resource cost or load balancing. For example, as shown in Fig. 1(c), the candidates for the virtual nodes a and b and the virtual link (a, b) are found in domain 1, another candidate for a is in domain 2, another candidate for b is in domain 3, and the candidate for link (b, c) is also in domain 3. The InPs send these candidates and the corresponding mapping cost as defined in (1) and (4) to the mapping manager. C. The Domain-level Graph The mapping manager collects all the candidates to establish a domain-level graph to determine the intra-domain and inter-domain VN mapping in the same phase. The candidates found by each InP is a subgraph of the VN topology (as in Fig. 1(c)), and the mapping cost of the candidates is known. All the subgraphs from the InPs are then added into the domain-level graph (as in Fig. 1(d)). If there is a virtual link lV between the virtual nodes whose candidates are in different domains, the node candidates are interconnected by a link candidate lD using dotted lines in Fig. 1(d). The InPs and the mapping manager cooperate to estimate the mapping cost f(lV) for the candidate for the inter-domain virtual link lV. The cost of inter-domain paths between the border routers can be got by the border gateway protocol (BGP) with the link weights set based on (4), and the cost of the intra-domain path between the node candidates and the border routers can be got from the InPs. Thus the cost of inter-domain paths between the node candidates can be estimated. After all the candidates for the inter-domain virtual links are added, the domain-level graph is established as in Fig. 1(d). Then the candidates are selected on the domain-level graph to accomplish the QoS-aware VN mapping along with cost considerations. Thus, the mapping is done without the knowledge of the topology and resource information of the domains. D. Candidate Selection On the established domain-level graph, candidates are selected for the virtual nodes and links in the VN request (as shown in Fig. 1(e)) while minimizing the mapping cost defined in (5). The VN mapping fails if there are no candidates for a virtual node or link in the VN request. After successful candidate selection the mapping manager informs the InPs of

479

the respective candidates for instantiation, e.g., virtual link setup in [14]. IV.

THE ALGORITHM FOR CANDIDATE SELECTION

In this section we formulate candidate selection as an integer linear programming (ILP) problem. Since the problem is NP-hard, we also present a heuristic algorithm to address the problem. A. The ILP formulation As shown in Fig. 1(d), the domain-level graph is modeled by GD = (VD, ED), where VD and ED are the sets of the candidate nodes and links. Each candidate node or link (nD∈VD or lD∈ED) for a virtual node or link (nV∈VV or lV∈EV) is represented by cad(nD) = nV or cad(lD) = lV. For example, as shown in Fig. 1(d), cad(a1) = a and cad(b3) = b. The (given) cost of selecting the candidate nD or lD is denoted by f(nD) or f(lD), where f(nD) or f(lD) are f(cad(nD)) or f(cad(lD)), respectively. On the established domain-level graph, candidates are selected to support the VN request, aiming to minimize total candidate cost. Variables x(nD) (nD∈VD): Binary variable denoting whether the node candidate nD is selected; 1 if selected and 0 otherwise. y(lD) (lD∈ED): Binary variable denoting whether the link candidate lD is selected; 1 if selected and 0 otherwise. Objective minimize

f =

å x(n

D

nD ÎVD

)* f (nD ) +

å y(n

lD ÎED

D

)* f (lD )

(6)

Constraints

å

nD :cad ( nD ) = nV

å

lD :cad ( lD ) =lV

x(nD ) = 1, "nV ÎVV

(7)

y(lD ) = 1, "lV Î EV

(8)

x(nD ) ³ y(lD ), "lD = (nD , nD ')or (nD ', nD ) Î E D

(9)

x(nD ) Î {0,1}, "nD ÎVD

(10)

y (lD ) Î {0,1}, "lD Î ED

(11)

The objective function (6) minimizes the total cost of selected candidates. Constraints (7)-(9) are for the selected candidates composing the VN topology. Constraints (7) and (8) ensure that one candidate is selected for each virtual node and link. Constraint (9) ensures that the end (candidate) nodes are also selected when a candidate link is selected.

Globecom 2013 Workshop - Cloud Computing Systems, Networks, and Applications

Constraints (10)-(11) are the binary domain constraints for the variables. B. The Candidate Selection Algorithm Since the problem of candidate selection is NP-hard [15], we develop the heuristic algorithm for candidate selection as shown in Fig. 3. As shown in Fig. 1(d) and Fig. 1(e) the candidates selected from the domain-level graph support the VN request in Fig.1(b). Our algorithm aims to minimize the cost of the candidates that support the VN request. The algorithm iteratively removes link candidates with high cost and the associated node candidates (and accordingly the links connected to the deleted node) such that after their removal the residual graph can still support the VN request. For example, as shown in Fig. 1(d), if the high cost link (a1, b3) is removed from the domain-level graph then one of the nodes a1 or b3 also have to be removed, and in addition all the links adjacent to the removed node also have to be deleted. In this example the node a1 is removed and accordingly links (a1, b3), (a1, b1) and (a1, c3) are also deleted. 1: S = Ø 2: record the number of candidates for nV∈VV and lV∈VV by Ncad(nV) and Ncad(lV) 3: sort all lD∈ED in decreasing order of f(lD) 4: if Ncad(nV) = 0 for any nV then 5: return false 6: end if 7: for lD = (m, n)∈VD 8: if lD can be removed then //Ncad(cad(m)) ≠ 1 or Ncad(cad(n)) ≠ 1 9: removed_node = Ncad(cad(m)) > Ncad(cad(n))?m : n 10: end if 11: remove removed_node from the VD and the link candidates adjacent to removed_node from ED 12: Ncad(cad(removed_node)) = Ncad(cad(removed_node)) - 1 13: end for 14: record the residual candidates in the set S 15: return S Fig. 3. The algorithm for candidate selection

In the algorithm set S records the selected candidates. At the beginning of the algorithm, the numbers of candidates for each virtual node and link are recorded (line 2). If there are no candidates for a virtual node, the VN request cannot be supported (lines 4-6). The link candidates are iterated over in decreasing order of link cost (line 2). If the end (candidate) nodes of the iterated link candidate lD are both the only residual node candidates for the end (virtual) nodes of the virtual link cad(lD), the link candidate lD cannot be removed from the graph (line 8) (otherwise we cannot support the virtual link cad(lD)). If the link candidate can be removed, the end node nD for which cad(nD) has more node candidates (line 9) is removed from the residual graph (as described above). And the link candidates adjacent to nD are also removed from the graph (line 11). After all the link candidates are iterated, the residual graph now supports the VN request. The complexity of sorting the link candidates is O(|ED|*log|ED|), and in the |ED| iterations at most |ED| link candidates are removed. Thus, the time complexity of the algorithm is O(|ED|*log(|ED|) + |ED|).

480

For example, as shown in Fig. 1(d), first the link candidate (a1, b3) whose cost is maximal is tried, and node a1and its adjacent links are deleted as explained before. In the next step (a2, b1) is iterated, which is the link candidate with maximum cost on the residual graph. Similarly, its end node b1 and the residual link candidates adjacent to b1, i.e., (b1, a2) and (b1, c3) are removed. After removing the high cost link candidates (a1, b3) and (b1, a2) and the associated nodes, now the residual candidates (Fig. 1(e)) are the only ones left to support the VN request, and hence no further link candidates can be removed. V.

SIMULATION RESULTS

In this section, we present our simulation environment and the results of our simulation experiments and analysis. A. Simulation Environment In our simulation we assume that the underlying substrate consists of 5 domains. There are 12 substrate nodes in each domain, and each pair of the nodes is interconnected by an intra-domain link with the probability of 0.5. The available computing capacity on each substrate node is 400 units, and the unit cost of computing capacity varies according to a uniform distribution from 1 to 3. The available bandwidth on each intradomain substrate link is 800 units, and the unit cost of bandwidth and the delay on the intra-domain links vary according to a uniform distribution from 1 to 3. Each pair of domains is interconnected with probability of 0.5. When a domain pair is interconnected, the number of links interconnecting the domains is one or two with probability of 0.5. The available bandwidth on the inter-domain substrate links is 2000 units, and the unit cost of bandwidth and the delay on the inter-domain links vary according to a uniform distribution from 6 to 12. For each virtual request, virtual node pairs are randomly connected by a virtual link with the probability of 0.5. The required computing capacity of each virtual node varies according to a uniform distribution from 10 to 50 units. There are location constraints on virtual nodes [13], where the virtual node should be mapped within the required geographical region. In the allowed location region for each virtual node we assume 8 random substrate nodes (may be in different domains) are available. For each virtual link lV the required bandwidth varies according to a uniform distribution from 10 to 50 units. The parameter α(lV) (from (3)) is 1 for each virtual link lV, and β (from (4)) is set at 20 to ensure the cost of resources and the QoS performance are in the same order of magnitude. B. Comparison Method We compare the proposed QoS-aware VN mapping framework by solving the ILP for candidate selection (denoted by ILP), the proposed framework with the proposed algorithm (denoted by QoS_VNM) and the framework in [13] (denoted by Fwd_VNM). In the Fwd_VNM framework, the SP sends the VN request to all InPs. The InPs partially map the VN request and forward the residual part to other InPs. The mapping that results in the lowest cost is selected as the final mapping. In QoS_VNM and Fwd_VNM, each InP uses the intra-domain algorithm presented in our previous work in [9] to partially map the VN request, where the algorithm is modified for the location-aware partial mapping. For the intra-mapping

Globecom 2013 Workshop - Cloud Computing Systems, Networks, and Applications

Fig. 4. The average delay of all virtual links

Fig. 5. The costof resouces allocated for the VN request

in QoS_VNM, the mapping cost is defined as in (5), and in Fwd_VNM only the cost of allocated resources is considered. In our simulations, single VN requests are mapped across multiple domains with QoS_VNM and Fwd_VNM. The number of virtual nodes in a VN request varies from 8 to 20. Ten VN request of the same size are randomly generated and the average is reported. Based on different VN sizes, we compare QoS_VNM and Fwd_VNM for the average delay of the virtual links, the cost of allocated resource and the mapping cost f defined in (5). C. Analysis of Results As shown in Fig. 4 the average delay on the virtual links of the VN request is smaller using the ILP and QoS_FWN. This is because QoS performance is considered (as in (5)) for both intra-domain and domain-level mapping. Fig. 5 shows that the cost of the allocated resources for the VN request is lower with ILP and QoS_VNM. This is because the inter-domain links can be mapped onto the paths with lower cost using the global domain-level knowledge. Fig. 6 shows that ILP and QoS_VNM achieves lower VN mapping cost and at the same time achieves good QoS performance. From Fig. 4 - Fig. 6 we can see that the results of QoS_VNM are close to the ILP. However, as the size of problem increases the ILP becomes intractable and the proposed QoS_VNM framework can be used to effectively map the VN request across multiple domains. As shown in Fig. 4 and Fig. 5, the average delay and resource allocation cost increase with the growth of VN size, as the mapping of larger VN requests requires more computing and bandwidth resources. Also as the number of substrate hops of the paths for virtual links increases so does the delay on virtual links. Fig. 6 also shows that the difference between QoS_VNM and Fwd_VNM tends to be larger as the VN size increases. This is because larger VN requests tend to have more inter-domain paths, and the inter-domain mapping is more cost efficient in QoS_VNM than in Fwd_QoS. VI. CONCLUSION In this paper we propose a framework for QoS-aware VN mapping across multiple domains. In the proposed framework, the mapping manager and the InPs cooperate to establish a domain-level graph for intra-domain and inter-domain mapping. By using the domain-level graph, the QoS performance can be

481

Fig. 6. The total mapping cost

evaluated to guide both the intra-domain and the inter-domain VN mapping in the same phase. We also develop algorithms that select node and link mapping candidates that minimize costs while giving good QoS. The simulation results show that the framework leads to good QoS performance and low cost. REFERENCES [1] [2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14] [15]

J. S. Turner, D.E. Taylor, “Diversifying the Internet,” Global Telecommunications Conference, pp. 755-760, 2004. T. Anderson, L. Peterson, S. Shenker, et al., “Overcoming the Internet impasse through virtualization,” IEEE Computer Magazine, vol. 38, pp. 34-41, 2005. N. Feamster, L. Gao, and J. Rexford, “How to lease the Internet in your spare time,” ACM Computer communication review, vol.37, pp. 61-64, 2007. N.M.M.K. Chowdhury and R. Boutaba, “Network virtualization: state of the art and research challenges,” IEEE Communications Magazine vol.47, pp. 20-26, 2007. Y. Zhu and M. Ammar, “Algorithms for assigning substrate network resources to virtual network components,” IEEE INFOCOM, pp.1-12, 2006. I. Houidi, W. Louati and D. Zeghlache, “A Distributed Virtual Network Mapping Algorithm,” IEEE International Conference on Communications (ICC), pp. 5634-5640, 2008. N.M.M.K. Chowdhury, M.R. Rahman and R. Boutaba, “Virtual Network Embedding with Coordinated Node and Link Mapping,” IEEE INFOCOM, pp. 783-791, 2009. J. Lischka and H. Karl, “A virtual network mapping algorithm based on subgraph isomorphism detection,” the 1st ACM workshop on Virtualized infrastructure systems and architectures, pp. 81-88, 2009. H. Di, L. Li, V. Anand, et al. “Cost Efficient Virtual Infrastructure Mapping using Subgraph Isomorphism,” Asia Communications and Photonics Conference (ACP), pp.533-534, 2010. M. Yu, Y. Yi, J. Rexford, et al. “Rethinking virtual network embedding: Substrate support for path splitting and migration,” ACM SIGCOMM Computer Communication Review, vol. 38, pp. 17-29, 2008. Q. Hu, Y. Wang and X. Cao, “Resolve The Virtual Network Embedding Problem: A Column Generation Approach,” IEEE INFOCOM, pp. 410414, 2013. I. Houidi, W. Louati, W. Bean-Ameur, and D. Zeghlache, “Virtual network provisioning across multiple substrate networks,” Computer Networks, vol. 55, pp. 1011-1023, 2011. M. Chowdhury, F. Samuel, and R. Boutaba, “Polyvine: policy-based virtual network embedding across multiple domains,” Proceedings of the second ACM SIGCOMM workshop on VISA. ACM, pp. 49–56, 2010. C. Werle, P. Papadimitriou, I. Houidi, et al. “Building virtual networks across multiple domains,” SIGCOMM, pp. 412-413, 2011. D Wedelin , An algorithm for large scale 0-1 integer programming with application to airline crew scheduling, Annals of Operations Research, vol. 57, pp. 283-301, 1992.