2015 IEEE 4th Symposium on Network Cloud Computing and Applications

Realization of a Virtual Resource Management

Framework in IaaS Cloud Federation
Anant V Nimkar and Soumya K Ghosh
School of Information Technology
Indian Institute of Technology Kharagpur, India
anantn@sit.iitkgp.ernet.in, skg@iitkgp.ac.in
evaluated before and after the deployment of all modules in
VRMF since it may vary significantly as each module uses
one or more other module(s) to perform its function.

AbstractThe virtual resources in the federated cloud can

be collectively and securely managed by one or more
participating stakeholder(s) through a Virtual Resource
Management
Framework
(VRMF).
VRMF
provides
authorization, authentication and identity solutions in IaaS
cloud federation. The performance of the system must be
evaluated before and after the deployment of all modules in
VRMF since it may vary significantly as each module uses one
or more other module(s) to perform its function. This paper
presents an implementation of VRMF to manage virtual
resources in federated clouds and evaluate the performance.
The implementation uses the response time as the performance
parameter for evaluating the ecosystem before and after
integration of all individual modules. The integrated framework
with authorization, authentication and identity services shows
encouraging results.

I.

VRMF uses Federation Access Control Model (FACM),

Name-and-Label Space Model (NLSM) [3] and Caucus
Authentication Protocol (CAP) for authorization, identity
solution and authentication respectively. FACM and NLSM
use a new concept of subjects as subsets of federating
stakeholders. The authorization of subjects over objects is
carried out using NLSM, FACM and CAP as follows. CAP
allows authentication of subjects composed of one or more
federating stakeholder(s) using a variant of Multi-Party
Computation (MPC). NLSM provides identities and security
labels of subjects and federated virtual resources required in
the FACM authorization process. FACM authorizes subjects
to access federated objects by collective decisions of i)
comparison of security labels using Cartesian operators and
ii) federated discretionary access rights using MAC and DAC
policies respectively.

I NTRODUCTION

Cloud computing delivers virtual resources (i.e.

virtualized instances of switches, routers, machines and links)
as a utility over the Internet using Infrastructure as a Service
(IaaS) cloud delivery model. If cloud provider cannot fulfill
customers requirements, it may borrow virtual resources to
form virtual networks from other cloud providers. In IaaS
cloud federation, Service Providers (SePs) federate with
Infrastructure Providers (InPs) and supply virtual networks
out of data centers to their customers [1]. Virtual networks
consist of sets of virtual nodes connected by virtual links. In
IaaS cloud federation, collocation of tenants virtual
networks across data centers, is called as Multi-tenant
Network Collocation (MNC). The management of federated
virtual resources needs two special treatments. First,
management of federated virtual resources must be
cooperatively handled by subsets of federating stakeholders,
viz. SePs, InPs and customers. For example, virtual nodes
and links are collaboratively created and deleted by their
respective InPs on receiving requests from SePs. Further,
virtual resources need to be cooperatively configured by their
SePs, users and InPs. Second, the management of federated
virtual resources must be handled securely, as and when
federations are established or torn down respectively.

In this paper, NLSM, FACM and CAP are realized as

Node-and-Path Label Distribution Protocol (NPLDP), Access
Control Enforcement Engine (ACEE) and Caucus
Authentication Mechanism (CAM) in VRMF respectively.
Further, the realization uses minimal part of FACM as
MAC-based Enforcement Engine (MACEE) for secure
multiplexing and de-multiplexing of users traffic in virtual
and physical infrastructures. NPLDP is implemented as a
distributed signaling protocol to instruct physical routers for
secure embedding of virtual resources. CAM is implemented
as a distributed protocol running on all stakeholders
premises. Further, the simulation has been carried out on
different number of users authorization requests to evaluate
the system using response times before and after integration
of authorization, authentication and identity solution as
suggested in VRMF.
The rest of the paper is organized as follows. Section II
presents a synopsis on IaaS cloud federation and Virtual
Resource Management Framework in Section II-A and
Section II-B respectively. Section III presents a realization of
VRMF using Name-and-Label Space Model, Federation
Access Control Model and Caucus Authentication Protocol in
Section III-A, Section III-B and Section III-C respectively.
The simulation study and results are presented in Section IV.
The concluding remarks are given in Section V.

Virtual Resource Management Framework (VRMF) [2]

provides a mechanism to securely manage federated virtual
resources through three local and global modules for (i)
Authorization over objects (i.e. federated virtual resources),
(ii) Authentication of subjects (i.e. collective stakeholders)
and (iii) Identity solution for subjects and objects in IaaS
cloud federation. Each module makes use of one or more
other module(s). The performance of the system must be

978-1-4673-7741-6/15
/15
$31.00 2015 IEEE
$31.00 2015 IEEE
DOI 10.1109/NCCA.2015.24

99

II.

BACKGROUND

The first step towards IaaS cloud federation includes the

three-phase cross federation [4], mobile-agent based cloud
federation [5] and Reservoir Model [6]. IBMs Virtual Data
Center (VDC) [7] is an industry implementation of IaaS
cloud federation.

This paper gives an implementation case study on

collocation of tenants virtual networks in federated clouds
through Virtual Resource Management Framework. This
section presents fundamentals of IaaS cloud federation and
Virtual Resource Management Framework.

B. Virtual Resource Management Framework

Virtual Resource Management Framework (VRMF) [2]
has three types of stakeholders, viz. (i) IaaS cloud providers,
(ii) A broker and (iii) Users as shown in Fig. 2. Each IaaS
cloud can be SeP, InP or both. The data center of IaaS cloud
has a controller, a physical infrastructure (PIn), a virtual
infrastructures (VIn) and a set of software modules. The
software modules consist of (i) local and federated Resource
Access Control (RAC), (ii) local and federated Identity
Management (IdM) and (iii) local Authentication Agents
(AA) and federated Authentication System (AS). The
federations among stakeholders are established by the
controllers of InPs using three standard functionsmatching,
discovery and advertisementof brokered architecture. The
users have only local Authentication Agents (AA) to
participate in the authentication process. Each user also has
local Authentication Agent (AA) for authentication of subject
as collective stakeholders.

A. IaaS Cloud Federation

In IaaS cloud federation, each cloud provider can be a
Service Provider (SeP), Infrastructure Provider (InP) or both.
SePs supply virtual networks to their customers through a
brokered collaboration among InPs. Virtual networks consist
of sets of virtual nodes connected by virtual links. Fig. 1
shows an ecosystem of IaaS cloud federation. It shows
federations among three cloud providers, viz. InP#1/SeP#1,
InP#2 and SeP#3/InP#3 and three users, viz. User#1, User#2
and User#3. The physical networks of InPs are shown in
black plain-line rectangles at the bottom. The service
provider SeP#1 borrows a virtual network segment{VN6 } to
User#1 from InP#3 and provides a virtual network
{VN1 ,VN6 }. Similarly, the service provider SeP#3 borrows
virtual network segments {VN3 ,VN4 } and {VN2 } from the
InPs and provides virtual networks {VN3 ,VN4 ,VN7 } and
{VN2 ,VN5 } respectively. The blue single-dot-dash and
saffron double-dot-dash ovals indicate the boundaries of
SeP#1 and SeP#3 respectively.

Fig. 2: Virtual Resource Management Framework (VRMF)

III.

I MPLEMENTATION

The authorization, authentication and identity solutions in

IaaS cloud federation are addressed by designing FACM
enforcement policies, implementing CAP and deploying
NLSM respectively. The details of FACM, CAP and NLSM
are subsequently presented in this section and their
implementation details as ACEE, CAM and NPLDP are later
presented in Section IV respectively.
A. Name-and-Label Space Model
Fig. 1: An ecosystem of IaaS cloud federation among three
InPs/SePs

Name-and-Label Space Model (NLSM) uses the concepts

of ordered tuples and set theory for the formation of
identities and security labels respectively in IaaS cloud

100

federation ecosystem. NLSM uses security labels of the form

hSLSeP , SLU , SLInP s i where SLSeP , SLU and SLInP s
denote security labels of SeP, its user and a set of InPs
respectively. NLSM also uses three binary Cartesian
operators on tuple based security labels. The binary Cartesian
operator j returns true if the first two fields of two security
labels are non-empty and same, and the third field of first
security label is a subset of the third field of second security
label. The binary Cartesian relation returns true if the first
two fields of two security labels are non-empty and all the
three fields are same in both security labels.

authentication ticket for execution of federation services

before the validity of the authentication ticket.
IV.

The local and global modules of FACM, CAP and NLSM

are implemented as Access Control Enforcement Engine
(ACEE), Caucus Authentication Mechanism (CAM) and
Node-and-Path Label Distribution Protocol (NPLDP)
respectively. Fig. 3 shows a block-level view of realization of
all modules on k number of SePs/InPs in federated
ecosystem. Each SeP has variable number of users. Similarly,
each InP has a controller and variable number of Physical
Nodes (PNs) on which variable number of Virtual Nodes
(VNs) can be installed. All modules are implemented as
different modules in ns3 environment.

B. Federation Access Control Model

Federation Access Control Model (FACM) combines
mandatory and federated discretionary based access control
model. In FACM, subjects can be authorized to access
objects by collective decisions of i) Comparison of tuple
based security labels and ii) Federated discretionary access
rights using Cartesian operators, MAC and DAC policies.
FACM can be formally defined for InPs as 5-tuple as
follows.
F = {(Si , Oi , Pi , Fi , Li ) | 1 i }

S IMULATION AND R ESULTS

Node-and-Path Label Distribution Protocol (NPLDP) is

an combined and distributed implementation of NLSM and
signaling protocol. NPLDP runs on all controllers and PNs.
CAM is a distributed protocol running on SePs, InPs and
user premises to facilitate authentication of subjects as
subsets of federating participants. CAM consists of two parts
namely, Caucus Authentication Server (CAS) and Caucus
Authentication Agent (CAA). CAS and CAA are
implemented as ns3 application module. ACEE is a
distributed implementation of FACM running on the
controller while MACEE is a minimal MAC part of FACM
for securely forwarding user and network-centric traffic
between physical and virtual networks.

(1)

Si and Oi are sets of subjects and objects in InPs

respectively. Pi is a set of 3-tuple access permissions that
can be exercised by each subject over the objects. Fi is a set
of ordered pairs of security label mappings of subjects and
objects at a particular time instance. Li is a partial order set
of each individual InPs security levels at a particular time
instance. FACM provides integrity and confidentiality among
all stakeholders in the federations. The integrity of
services/software in the federation is treated differently and it
is higher with increasing federating participants the subjects.
C. Caucus Authentication Protocol
In IaaS cloud federation, services are cooperatively
executed by subjects as subsets of federating stakeholders.
Caucus1
Authentication Protocol (CAP) efficiently
authenticates such subjects which cannot be handled by all
identity management solutions including WS-Federation [8]
and Shibboleth [9]. CAP needs three independent services,
namely Caucus Server (CS), Role Client (RC) and Role
Servers (RSs) running on an authentication server, a
stakeholder as authentication initiator and all stakeholders
except authentication initiator. CAP first authenticates all
stakeholders s S and finally the subject S using the
concept of MPC [10] as follows. In the first step, an
authentication initiator out of all stakeholders in the subject
(i.e. sa S) sends a request to CS for authentication of a
subject, S. In the second step, CS creates role tickets for all
stakeholders in S and then sends them to authentication
initiator, RC (i.e. process running on sa ). In the third step,
RC forwards role tickets to all RSs (i.e. processes running
S sa ). In the fourth step, all RCs send role tickets to CS to
share their MPC values. Finally, CS creates an authentication
ticket using all MPC values and then sends it to RC after its
validation. Any stakeholder in the subject can use this

Fig. 3: Secured Federated Clouds Architecture

NPLDP uses Virtual Label Information Base (VLIB) and
distributes identities of virtual routers and virtual links as
follows. The labels of virtual routers and links are entered in
VLIB whenever FACM successfully executes virtual resource
management services using ACEE. In case of virtual labels
of virtual links, NPLDP has a set of procedures to send the
virtual labels along a optimal physical path. The virtual
labels of virtual resources are deleted from VLIB whenever
delete-node and delete-link services are successfully executed
by ACEE. ACEE provides security provisions by enforcing
MAC and DAC policies. MACEE uses MAC policies and

1 The dictionary meaning of the word Caucus is a small group of people

who have same interests.

101

R EFERENCES
[1]

[2]

(a) Response times for authentication of subjects

[3]

[4]

[5]

(b) Response times for management of virtual resources

Fig. 4: Performance Evaluation

Management Framework

of

Virtual

[6]

Resource
[7]

Security label Information Base (SLIB) to multiplex and

de-multiplex traffics of local virtual routers.

[8]

The simulation has been carried out for different values of

the number of InPs/SePs (i.e. k). It has been observed that
the response times for management of virtual resources and
authentication of subjects for different values of k were found
in the same range. Fig. 4 shows the performance of VRMF
for 10 SePs/InPs by considering the response times before and
after the integration of ACEE, CAM and NPLDP. Fig. 4a and
Fig. 4b show that the response times are in the range of 0.04 to
0.06 mSec for both management of virtual resources as well
as authentication of subjects. Fig. 4a and Fig. 4b show that
the response time after the integration of ACEE, CAM and
NPLDP has marginally increased.

V.

[9]

[10]

C ONCLUSION

Virtual resources in federated cloud can be collectively

and securely managed by one or more participating
stakeholder(s) using Virtual Resource Management
Framework (VRMF). VRMF has local and global modules
for authorization, authentication and identity management
solution in IaaS cloud federation. The authorization,
authentication and identity solution have been implemented
as case study for management of virtual resources in
federated clouds to evaluate the individual modules and the
system itself after integration of all modules using VRMF.
The simulation results show a marginal increase in the
response time while the integrated framework provides
secured management of virtual resources.

102

A. Celesti, F. Tusa, M. Villari, and A. Puliafito, Three-phase crosscloud federation model: The cloud sso authentication, in Advances
in Future Internet (AFIN), 2010 Second International Conference on.
Venice, Italy: IEEE, July 2010, pp. 94 101.
A. V. Nimkar and S. K. Ghosh, A security framework for
virtual resource management in horizontal iaas federation, in
Advanced Computing, Networking and Informatics- Volume 2, ser.
Smart Innovation, Systems and Technologies. Springer International
Publishing, 2014, vol. 28, pp. 241247. [Online]. Available:
http://dx.doi.org/10.1007/978-3-319-07350-7 27
A. V. Nimkar and S. K. Ghosh, A theoretical study on access control
model in federated systems, in Recent Trends in Computer Networks
and Distributed Systems Security, ser. Communications in Computer
and Information Science. Springer Berlin Heidelberg, 2014, vol. 420,
pp. 310321. [Online]. Available: http://dx.doi.org/10.1007/978-3-64254525-2 28
A. Celesti, F. Tusa, M. Villari, and A. Puliafito, How to enhance
cloud architectures to enable cross-federation, in Cloud Computing
(CLOUD), 2010 IEEE 3rd International Conference on. Miami, FL,
USA: IEEE, July 2010, pp. 337345.
Z. Zhang and X. Zhang, Realization of open cloud computing
federation based on mobile agent, in Intelligent Computing and
Intelligent Systems, 2009. ICIS 2009. IEEE International Conference
on, vol. 3. Shanghai, China: IEEE, Nov 2009, pp. 642646.
B. Rochwerger, D. Breitgand, E. Levy, A. Galis, K. Nagin, I. Llorente,
R. Montero, Y. Wolfsthal, E. Elmroth, J. Caceres, M. Ben-Yehuda,
W. Emmerich, and F. Galan, The reservoir model and architecture
for open federated cloud computing, IBM Journal of Research and
Development, vol. 53, no. 4, pp. 4:14:11, July 2009.
A. Amokrane, M. Zhani, R. Langar, R. Boutaba, and G. Pujolle,
Greenhead: Virtual data center embedding across distributed
infrastructures, Cloud Computing, IEEE Transactions on, vol. 1, no. 1,
pp. 3649, Jan 2013.
Web Services Federation 1.2, OASIS, May 2009. [Online].
Available:
http://docs.oasis-open.org/wsfed/federation/v1.2/os/wsfederation-1.2-spec-os.pdf
Shibboleth Architecture Protocols and Profiles, Sept. 2005. [Online].
Available: http://shibboleth. internet2.edu/docs/draft-mace-shibboletharch-protocols-latest.pdf
H. Vegge, Realizing secure multiparty computations, Masters
thesis, Norwegian University of Science and Technology, Faculty of
Information Technology, Mathematics and Electrical Engineering,
Department of Telematics, Sept. 2009. [Online]. Available:
http://www.diva-portal.org/smash/get/diva2:347815/FULLTEXT01.pdf