An Approach for Security, Performance, and Generic ...

Journal of Information Assurance and Security ISSN 1554-1010 Volume 6 (2011) pp. 262-272 © MIR Labs, www.mirlabs.net/jias/index.html

An Approach for Security, Performance, and Generic Data Retrieval in RESERVOIR Clouds Antonio Celesti1 , Massimo Villari1 Antonio Puliafito1 and Francesco Longo1 1

University of Messina, Faculty of Engineering, Dept. of Mathematics Contrada di Dio, S. Agata, 98166 Messina, Italy {acelesti, mvillari, apuliafito, flongo}@unime.it

Abstract: RESERVOIR is a Cloud service provider able to arrange virtual environments in order to provide on-demand Infrastructure as a Services (IaaSs) to its clients. Typically, the RESERVOIR’s clients use such services to deploy their own software platforms. However, clients need to logically identify both the entities related to their software platforms and the entities of their RESERVOIR IaaS. This involves that clients must be able to name and retrieve information about many types of entities for security, monitoring, and many other tasks. Moreover, name alterations can frequently occur because RESERVOIR has to face allocation, deallocation, and migration of virtual environments from an execution context to another. In such a scenario, the mere use of the Domain Name System (DNS) could make the naming and information retrieval tasks very difficult. This paper aims to propose a flexible Cloud naming system and, by exploring several RESERVOIR use cases, to demonstrate how can be possible for IT societies, organizations, universities, and general end-users to simplify the management of their assets deployed into the RESERVOIR Cloud. Keywords: Cloud Computing, Cloud Name Space, Cloud Naming System, RESERVOIR, XRI, XRDS

I. Introduction Nowadays, Cloud providers supply many kinds of Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS) to their users, e.g., common desktop clients, companies, governments, organizations, and other Clouds. In Cloud computing environments as well as in all systems characterized by a high level of dynamism, naming and resource location become critical issues. Currently, the Internet uses the Domain Name System (DNS) for the resolution of prefixed domain names. DNS does not seem to be suitable to the new emerging Cloud scenarios. In fact, it presents several disadvantages: the traditional resource records are not able to describe complex structured entities and to efficiently remap entities that frequently change their status. An example of entity is a virtual machine which could be allocated, deallocated, or moved from a context to another, due to migration mechanisms. As a migration may trigger an identity alteration, a Cloud entity being part of an IaaS could later be-

come part of another IaaS either in the same Cloud or in another Cloud if we consider federated environments. In Cloud environments, there are several concrete and abstract entities which need to be identified both in human-readable and in machine-readable fashion. These entities might hold one or more identifiers with different levels of abstraction. In such a context, the management of Cloud entity names and Cloud name spaces may become very difficult. As described in [1], a Cloud naming system should be characterized by: scalability, extensibility, services of description and discovery, name recycling, non-correlation, and name space integration mechanisms which avoid name conflicts. This paper aims to apply the Cloud naming concepts proposed in [1] to RESERVOIR [2], a real federated Cloud architecture. More specifically, we introduce a methodology to design a Cloud naming system able to meet as much as possible the requirements of several use cases described in the RESERVOIR architectural document. The main advantages of the proposed Cloud naming system are: integration between different Cloud name spaces, compatibility with other URI-based naming systems and with the public DNS, support to the “mounting” of a Cloud name space under other Cloud name spaces. The paper is organized as follows. Section II provides a brief description of the European 7FP project RESERVOIR. Several use cases are introduced and analyzed highlighting the involved naming issues. Section III describes the background of our work and provides the state of the art of naming systems and the most widely adopted solutions in distributed and ubiquitous computing environments. In Section IV, we present and analyze the issues related to Cloud name spaces introducing the reference framework used to develop our own Cloud naming system. In Section V, we provide an overview of the eXtensible Resource Identifier (XRI) [3] and eXtensible Resource Descriptor Sequence (XRDS) [4] technologies motivating how, in our opinion, they suit the management of Cloud name spaces. In Section VI, we show as a possible implementation of the Cloud naming framework based on XRI and XRDS can meet the requirement of several RESERVOIR use cases. Conclusions and lights to the future are summarized in Section VII.

Dynamic Publishers, Inc., USA

Celesti et al.

263

II. RESERVOIR: an Example of Cloud Virtualization Infrastructure

data intercommunication framework represent a big challenge in this Cloud context.

In this Section, we describe the RESERVOIR architecture and the involved use cases on which, in Section VI, we are going to apply our naming concepts. RESERVOIR introduces an abstraction layer that allows to develop a set of high level management components that are not tied to any specific environment. This abstraction involves a federation of heterogeneous physical infrastructures. In RESERVOIR, more sites can share physical infrastructure resources on which IaaS(s) can be executed. Each site is partitioned by a virtualization layer into virtual execution environments (VEEs). These environments are fully isolated runtime modules that abstract away the physical characteristics of the resources and enable sharing. The virtualized computational resources, along with the virtualization layer and all the management enablement components, are referred as VEE Hosts. A service application is a set of software components that work to achieve a common goal. Each component of such a service application is executed in a dedicated VEE. These VEEs are placed on the same or different VEE Hosts within the site, or even on different sites. We underline, that neither the Service Provider (SP) nor the final user are aware of the real mapping between service applications and hardware resources. Our proposal makes real this assumption, guarantying an high level of Cloud interoperability and enabling a transparent interaction among the involved entities.

2) The Utility Computing Application Use Case

A. Description of the RESERVOIR Use Cases In the architectural RESERVOIR designing phase, several use cases of real applications have been identified and investigated. Such use cases represent the source of user’s requirements that Cloud environments should satisfy. Originally these application were thought for traditional distributed systems, but the virtualization technology has permitted the execution of them into the Cloud. 1) The Telco Application Use Case The Telco application use case focuses on building a complete computing environment in which a Telco operator, such as Telef´onica, could host massive access Web Services, such as one linked to a worldwide event, like the Olympics, or a service like Youtube. This use case will develop a “Platform as a Service” (PaaS) business model where the Telco operator could host owned or third party services over a Cloud Computing infrastructure, integrating them using the Web 2.0 EzWeb integration platform. Third party service could be created with platform services (billing, messaging, video streaming, VoIP, etc.). To deploy such a system in a Cloud infrastructure it is necessary to guarantee intercommunication among all the components of the platform (PaaS). This determines a transparent intercommunication among the interdomain federated networks. All Web Services have also to be identified when they are spreading among many sites. Finally the monitoring, billing and accounting policies need a common framework in order to interact and also exchange data. Thus, network management, name service consistency, and

It is based on the Sun Grid Engine (SGE or GE), an application able to provide Grid functionalities confined into virtual environments.The SGE provides workload management and dynamic provisioning of application workloads. The SGE accepts jobs from the outside world, queues, and schedules them according to policies. A Sun Grid Engine cluster consists of the following core components: hosts, daemons, and queues. Hosts present four types of configuration: Master Host, Execution Host, Administration Host, and Submit Host. Three daemons characterize the Sun infrastructure: Master Daemon, Scheduler Daemon, and Execution Daemon. A queue is a container for a class of jobs that are allowed to run on one or more hosts concurrently. A queue determines certain job attributes, e.g., whether the job can be migrated or not. To deploy such a system in a Cloud infrastructure it is necessary to guarantee intercommunication among all the Virtual Machines hosting the GRID environment. The main constrain in such a context is that the virtual resources management has to be totally transparent with respect to the overall native functionalities of the SGE. 3) The eBusiness Application Use Case It is based on a commercial application, the SAP software customers management. The use case described below illustrates the case of providing a pre-existing application (that was not necessarily designed for the Cloud) on the Cloud. A SAP system is a three-tiers system consisting of a presentation layer, application layer, and a database layer. The main components are: •

•

•

The Dialogue Instance (DI) hosts the work processes that execute the “Advanced Business Application Programming” (ABAP) programs as a response to user requests. The number of DIs can be configured for scalability. There is only a single Central Instance (CI) per SAP system. The CI communicates with the DIs and performs central services such as locking, messaging, registration of DIs, and session initiation and load balancing among DIs. A single Database Management System (DBMS) serves the SAP system. The DBMS accesses its storage either as a Network-Attached Storage (NAS) or by a Storage Area Network (SAN).

From a scalability and robustness point of view, one can add and remove DIs while the system is running, as well as adapt the number of work processes of a specific DI or CI. The components can be arranged in a variety of configurations, from a minimal configuration where all components run on a single machine, to larger ones where there are several DIs, each running on a separate machine, and a separate machine with the CI and the DBMS. The deployment of such a system in a Cloud infrastructure has to guarantee intercommunication among all the physical hosts and hypervisors where

An Approach for Security, Performance, and Generic Data Retrieval in RESERVOIR Clouds

the VMs of DIs, CIs and DBMS are confined, even in partner Clouds.

III. Background Cloud computing is generally considered as one of the more challenging research field in the IT world. It mixes aspects of Utility computing, Grid computing, Internet computing, Autonomic computing and Green computing [5], [6]. Nowadays, Clouds provide IaaS, PaaS, and SaaS to their clients according to a priori Service Level Agreements (SLAs) and to specific pay-per-use models. An SLA is a sort of contract established between a Cloud provider and its clients that guarantee that a Cloud service is provided with a certain degree of trustiness and according to certain performance parameters. In order to guarantee such SLAs, Cloud providers need to retrieve data concerning both trustiness and performance of the virtual machine monitor (VMM named also “Hypervisor”) and more specifically of the virtual machines (VMs) on which a IaaS, PaaS, and SaaS(s) are arranged. For such reasons, several works are present in the literature concerning performance evaluation and identity management in VMMs and VMs. Identity (ID) management has been considered in [7] and [8]. In [7], Hirano et al. state the importance of ID management for a security-purpose VMM system to enforce security policies on an end-user environment. They present a design of a portable ID management framework for a security-purpose VMM. The proposal employs a smart card for user authentication. The proposed ID management framework can provide generic programming interfaces to existing VMM software. It realizes an authentication between a VMM and its users, an authorization for a VM boot operation, storage of cryptographic keys for VMM-layers disk encryption/decryption, and access control for virtual/physical resources based on a user identity. An advanced and efficient intrusion detection system (IDS) management architecture and the combination with the VMM is presented in [8]. By implementing the known IDS standard IDMEF and a plugin concept, the proposed approach ensures flexibility and compatibility. Experiments are carried out to demonstrate the extensibility and virtualization-compatibility of the proposed IDS management architecture. Based on the proposed architecture, two application scenarios, IDS on Lock-Keeper and IDS in the Cloud, are realized and presented in the paper. To effectively operate, a Cloud needs a monitoring system that can provide data on the actual usage and changes in resources of the Cloud and of the services running in the Cloud. Existing monitoring systems such as Ganglia, Nagios, MonaLisa, and GridICE have addressed monitoring of large distributed systems. They are designed for a fixed, and relatively slowly changing physical infrastructure that includes servers, services on those servers, routers and switches. However, they are not able to rapidly hanging and dynamic infrastructure typical of virtual environments. In the physical world, new machines do not appear or disappear very often. Sometimes, some new servers are purchased and added to a rack, or a server or two may fail. Also, it is rare that a server will move from one location to another. In the virtual world, the opposite is the case. Many new hosts can appear and disappear rapidly, often within few minutes. Furthermore, the

264

virtual hosts can be migrated from one network to another, still retaining their capabilities. In [9] Clayman et al. present the main aspects of a new monitoring framework, which has been specifically designed for monitoring resources and services in virtualized environments including many VMMs. The issues related to federation of service Clouds, and how this affects monitoring in particular are also discussed. In [10], the same authors expose the advantages of the same monitoring framework to monitor virtual networks. In our opinion, Clouds need a unique tool able to identify and retrieve different types of data including security, performance and other generic information associated to Cloud platforms and their services. A possible solution could be the adoption of a seamless naming system but, unfortunately, in literature there are not many works on naming systems applied to Cloud environments, as DNS is still erroneously considered as the “panacea for all ills”. DNS presents some problems: it is host centric, unsuitable for complex data and services location, and it is not suited to heterogeneous environments. An alternative to DNS is presented in [11]. The authors propose a Uniform Resource Name System (URNS), a decentralized solution providing a dynamic and fast resource location system for the resolution of miscellaneous services. The work lacks of an exhaustive resource description mechanism. With regard to naming system in ubiquitous computing, in [12] the authors propose a naming system framework for smart space environments. The framework aims to integrate P2P independent Cloud naming systems with the DNS, but appears unfitted to be exported in other environments. In addition, it aims to localize and identify an entity that moves from a smart space to another using as description mechanism the little exhaustive DNS resource records. A hybrid naming system that combines DNS and Distributed Hash Table (DHT) is presented in [13]. The authors adopt a set of gateways executing a dynamic DNS name delegation between DNS resolver and DHT node, but it seems to lack of extensible name description mechanism. For the aforementioned we think that naming systems for Cloud computing environments need to be better analyzed and investigated.

IV. Naming and Information Retrieval Issues in Cloud Computing Environments In this Section, we provide a generic analysis of the Cloud name space, and we present our Cloud Naming System Framework able to address any Cloud use cases. A. The Cloud Name Space Analysis In a high-dynamic federated Cloud environment, the design of a Cloud naming system could be very hard. First of all, it is not clear which the involved entities and the virtual contexts are. Moreover, in federated environments, a Cloud naming system should be able to manage frequent name alteration and name space integration. The following analysis aims to clarify such concerns. Regardless the internal Cloud structure, we think a Cloud has many logical representations in various abstraction levels. In addition, there are many abstracted, structured entities. These entities are characterized

265

Celesti et al.

by a high-level of dynamism: allocations, changes and deallocations could occur frequently. Moreover, these entities may have one or more logical representations in one or more contexts. But which are the entities involved in Cloud computing? In order to describe such entities, we introduce the generalized concept of Cloud Named Entities Class (CNEC), indicating a set of Cloud Named Entities (CNEs). A CNE is a generic entity indicated by a name or an identifier which may refer both to real/abstracted and simple/structured entities. As depicted in Figure 1, examples of CNE may be a Cloud federation, a Cloud itself, a sub-Cloud, a Cloud application, a site, a host running a hypervisor, virtual machines (VMs), or Cloud users including organizations, enterprises, data centers, technicians, and generic human end-users.

integration. Our solution to the problem is a Cloud naming framework placed inside the highest level of a generic threelayers Cloud architecture (from the bottom: Virtual Machine Manager, Virtual Infrastructure Manager and Cloud Manager) [15] compliant to the major existing Cloud platforms. Since the Cloud Manager layer is responsible for high-level tasks, we think the framework can provide naming support to monitoring, QoS, security, identity management, federation, and billing. For example, for monitoring purposes the name of a CNE may be resolved with the corresponding performance data. Instead, for security purposes, a CNE name could be resolved by means of an identity provider (IdP) asserting its credentials in a given CCNTX. Figure 2 depicts the Cloud naming framework in detail.

Figure. 1: A generic CNE in several Cloud contexts (CCNTXs).

Figure. 2: Cloud Naming Framework in a generic Cloud architecture.

In our abstraction, we assume that a CNE is associated to one or more identifiers. Since a CNE is subject to frequent changes holding different representations in various Cloud Contexts (CCNTXs), the user-centric identity model [14] seems to be the most convenient approach. We define a CCNTX as an environment where a CNE is represented by one or more identifiers. A CCNTX can be a Cloud federation, a Cloud itself, a sub-Cloud, a Cloud application or whatever abstracted environment. In this work, we assume a CNE is represented by one or more service end-points (SEPs), which are objects returning metadata associated to a CNE in a given CCNTX. The generic CNE depicted in Figure 1 is associated with six identities within four CCNTXs. The target CNE holds identity 1, 2 inside CCNTX A, identity 3 inside CCNTX B, identity 4 inside CCNTX C, and identity 5, 6 inside CCNTX D. We define a Cloud Naming System (NS) a system that maps one or more identifiers to a CNE. A Cloud NS consists of a set of CNEs, an independent Cloud name space, and a mapping between them. A Cloud name space is a definition of Cloud domain names. Instead, a name or identifier is a label used to identify a CNE. A client resolver who needs to identify a CNE in a given CCNTX performs a resolution task. Resolution is the function of referencing an identifier to a set of metadata describing the CNE in a given CCNTX. B. The Cloud Naming System Framework The Cloud name space management raises new challenges concerning: compatibility, scalability, extensibility, CNE description, name recycling, non-correlation, and name space

The CNE Descriptor is the component describing a generic CNE. It can be a document containing a set of metadata associated to the target CNE, and a set of pointers to one or more SEPs representing the CNE in various CCNTXs. The Cloud Naming System represents the generic naming system used inside a Cloud. The Cloud Name Space Mounter, is the component responsible of mounting a CNE name inside the Cloud naming system. The Cloud Naming System Manager is the main component of the framework. It coordinates the whole Cloud naming, managing the Cloud Naming System, the mounting of CNE names by means of the Cloud Mounter, the integration with other federated Cloud name spaces, and the integration with the public naming system. It plays an important role in Cloud name space integration by means of cross-reference and cross-resolver mechanisms. Let us consider two different Clouds with different name spaces which establish a federation. With crossreference mechanisms the two Clouds could mount their name spaces under a common root forming a new CNE with a federated name space. Instead, cross-reference mechanisms permit the Cloud Name Space Manager to perform CNE name mounting inside the same name space or from a Cloud name space to another. The Cloud Federation CrossResolver is the component which defines a Cloud federation name space root under which the name spaces of the complying Clouds will be linked. Besides defining the name space root, it is also responsible for avoiding name conflicts. In a federated Cloud scenario several Cloud Federation CrossResolvers may exist, one for each Cloud federation. In some cases there may be the need to mount the whole Cloud name


spaces or part of them in a public name space domain. In such perspective the framework must guarantee interoperability with any public naming system. For such purpose, a Public Naming System Mounter has been designed to act as a gateway between Cloud name spaces and the public name space (the DNS). In a distributed scenario many Public Naming System Mounters may be active for each geographical area.

•

266

Permits to extend the system without affects the interoperability.

As depicted in Figure 3, such a technology creates an abstraction layer over the identification layer for real resources represented by the IRI, URI and IRI specifications. The

V. The XRI Technology for Cloud Computing In this Section, after an introduction of the XRI technology, we motivate why in our opinion it is adapted for naming and information retrieval of CNEs. XRI, designed by OASIS, is an emerging technology which aims to provide a standard protocol for the identification of generic resources regardless their representations, for both real and totally abstract entities. Nowadays XRI is widely used especially in the security area for the development of new emerging SSO authentication applications. Some of the main projects using XRI include OpenID 2.0 [16], Higgins [17], and XDI [18]. As will be argued in the following we think that such a technology can be a valid tool for developing of a seamless Cloud naming system. A. Overview on XRI Specifications The design of XRI has started from the solid bases provided by the Uniform Resource Identifier (URI) and the Internationalized Resource Identifier (IRI), so that URI is extended by IRI and IRI is extended by XRI. The URI specification enables to identify resources over heterogeneous and distributed networks, but has the limit to allow only ASCII characters, limit that has been overcome by the IRI specification which considers also Unicode Character Set (UCS). XRI solves the problem of the identification of totally abstract resources which was not easy to solve by means of the URI and IRI specifications. The XRI technology is able to solve a wide set of issues: •

•

•

•

•

•

Creates a syntax and a protocol for the uniform resolution of real or abstract resources with persistent or reassignable identifiers. Provides both generic and trusted protocols to transform an abstract identifier into several concrete identifiers.

Figure. 3: The goal of XRI is to provide an uniform abstract identification layer (OASIS xri-intro-v2.0 document). XRI syntax follows the “Uniform Resource Identifier (URI): Generic Syntax” [19], the “Internationalized Resource Identifier (IRI)” [20], and “Uniform Resource Names (URN)” [21] standards. An XRI identifier consists of a “xri://” prefix followed by four syntactic elements: •

•

•

•

The “authority” component indicates a specific name space and it commonly starts with “//” and ends with “/” The “/path” component indicates the path to a target authority in a tree. The “?query” component represents a string of information which allows the elaboration of a request. The “#fragment” component represents a set of additional information which will be interpreted by the XRI client resolver at the end of the recovery of the information requested by means of the query component.

These components are seen as a superset of the corresponding components of the URI and IRI syntaxes; such a situation allows an easy transformation of lots of URI and IRI identifiers in valid XRI addresses, simply changing the resolution protocol, e.g. from “http://” to “xri://”. As explained in OASIS’s xri syntax version 2.0 [3], the XRI syntax extends the IRI’s syntax on four aspects:

Through a simple standard, it permits the discovery of the URIs associated to a target resource, including the resources requiring additional metadata for their resolutions.

Persistent and reassignable segments. Unlike generic URI syntax, XRI syntax allows to the internal components of an XRI reference to be explicitly designated as either persistent or reassignable.

Provides an uniform syntax for the assignment of identifiers to abstract authority (i.e., an authority in XRI is the identifier of a generic entity.) belonging to whatever abstraction level and/or context.

Cross-references. Cross-references allow XRI references to contain other XRI references or IRIs as syntacticallydelimited sub-segments. This provides syntactic support for “compound identifiers”, i.e., the use of wellknown, fully-qualified identifiers within the context of another XRI reference. Typical uses of cross-references include using well-known types of metadata in an XRI reference (such as language or versioning metadata), or the use of globally-defined identifiers to mark parts of an XRI reference as having application- or vocabularyspecific semantics.

Defines a particular entity named “cross-reference” which provides an indexing system to address the resource through different contexts. Provides systems which guarantee the privacy of the data associated to an identifier relating the minimum possible number of information.

Celesti et al.

267 Additional authority types. While XRI syntax supports the same generic syntax used in IRIs for DNS and IP authorities, it also provides two additional options for identifying an authority: a) global context symbols (GCS), shorthand characters used for establishing the abstract global context of an identifier, and b) crossreferences, which enable any identifier to be used to specify an XRI authority. Standardized federation. Federated identifiers are those delegated across multiple authorities, such as DNS names. Generic URI syntax leaves the syntax for federated identifiers up to individual URI schemes, with the exception of explicit support for IP addresses. XRI syntax standardizes federation of both persistent and reassignable identifiers at any level of the path. As the XRI technology has been developed on top of the IRI and URI standards, it inherits lots of the constrains and syntactic rules of them. In the following we provide a brief overview of such rules. The set of characters of XRI is the same of URI and IRI, but the allocation of such characters is different for the “general delimiters” and “sub-delimiters”. Other reserved characters, that do not have a definite semantic, are used for the implementation of delimiters and appear in the construction of xrisub-delims. In addition, further characters named rgcs-char (e.g. “@”/ “x” / “=” / “$”) are used for the generation of xri-gen-delims. xri-reserved = xri-gen-delims / xri-sub-delims xri-gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "(" / ")" / "*" / "!" / rgcs-char xri-sub-delims = "&" / ";" / "," / "’" As it has already been described, the authority is the entity an XRI name belongs to. We distinguish three types of authorities: •

Global Context Symbol (GCS) Authority

•

XRI Authority

•

IRI Authority

The GCS authorities have the function to indicate the global logical context of an identifier gcs-authority= pgcs-authority / rgcs-authority pgcs-authority= "!" xri-subseg-pt-nz *xri-subseg rgcs-authority= rgcs-char xri-segment rgcs-char= "=" / "@" / "+" / "$" These authorities are identified by a single character, namely the rgcs-char along with the “!” character (bang character) which is responsible to identify persistent XRI names (inumber). Each rgcs-char indicates a different global context and the most used are “@” for companies and “=” for people. The XRI authorities are other types of authorities which can be formed by means of the GCS authorities themselves or through a cross-reference. Instead the IRI authorities are

identified by three fundamental parts: the first identifies the user in the context of the host, the second identifies the host by means of an IPv4 or IPv6 address, the third is optional and identifies the port number. The cross-references is the main tool used by XRI to make flexible and extensible the resources’ addressing. Such a mechanism allows the hierarchical addressing or resources and permits to reuse identifiers also in different contexts. From the syntax point of view a cross-reference is identifiable by means of its delimiters which are “(” and “)”, inside of which it is possible to insert the reference of a XRI name or an IRI name in absolute form. "(" ( XRI-reference / IRI ) ")" *xri-subseg The path component is composed of various segments, where each one, delimited by a “/”, ends with either a “?” before of the starting of a query component, or a “#” before of the starting of a fragment component, or with a xri reference. The XRI path segment is parsed by a XRI processor in two types of segment: star segment “*” and bang segment “!”. The first is for reassignable identifiers, instead the second is for persisten identifiers The query and fragment components are inherited by IRI and their structure is shown in the following: iquery = *( ipchar / iprivate / "/" / "?" ) ifragment = *( ipchar / "/" / "?" ) B. Resolution of XRI Names Given the multitude of the possible information and addressable resources through the XRI technology, OASIS designers do not have defined a unique resolution architecture which could be applied to all the cases manageable by XRI, but they created a generic format for the description of resources named Extensible Resource Descriptor Sequence (XRDS) and a standard for the request of XRDS document corresponding to a particular XRI name. As well as the DNS, the resolution of XRI identifiers takes place through XRI name server in recursive manner. The resolution can be performed in four different scenarios: •

Local Resolution.

•

Local Resolution using recursing authority servers.

•

Proxy Resolution.

•

Proxy Resolution using recursing authority servers.

Each of the aforementioned scenarios evolves in two phases: 1. Authority Resolution. This phase consists of the resolution of the authority or XRI name in a XRDS document which describes a given entity. The resolution depends on the scenario. 2. Service-End-Point Selection. This optional phase allows a XRI client resolver to select from the XRDS document the right Service-End-Point (SEP) resolving the XRI name in a given context. The selection of the SEP is performed choosing from the XRDS document


268

a particular eXtensible Resource Descriptor (XRD) including a set of metadata describing the SEP, which actually resolves, the XRI name, and an URI to the server running that SEP. In addition XRI supports the secure resolution of XRI names by means of a Security Assertion Markup Language (SAML) trusted resolution protocol. C. Why Does XRI suit to Cloud Computing? Even Though, the XRI Technology has not conceived for Cloud computing, in our opinion it offers several potentialities to solve many naming and information retrieval issues in Cloud environments. The XRI is a flexible, interoperable and extensible technology allowing to retrieve more information than the traditional DNS. Commonly, the DNS associates names to corresponding IP addresses by means of resource records. Commonly, when a client resolver needs to resolve a name, he sends a query to the DNS server, which respond with the corresponding IP address. XRI goes beyond such a functionality allowing to associate to a name an entire XML document, the XRDS, containing several metadata for the retrieval of different associated information. Such information can be retrieved within the XRDS documents itself, or in different distributed SEPs acting as service providers. In this latter case the XRDS contains the metadata describing how to retrieve target information in a particular SEP. Consequently, the XRI also allows to resolve a name by means of associated services. In our opinion, as XRI meets the requirements of Cloud name space management scenarios, it can be adopted to develop seamless Cloud naming systems offering support to many tasks. As XRI is compatible with IRI naming systems, there is not the need to use a unique global naming system, even though this would be possible. This feature allows Clouds to manage their own XRI naming systems, mapping them on the global DNS maintaining the compatibility with the existing naming systems. Moreover, with XRI a Cloud can keep one or more name spaces representing its own CNEs by managing one or more XRI trees. In addition, such a technology can be used for both identify and resolve CNE names by means of the resolution of XRI authorities. For simplicity, from now on, with terms as “CNE name”, “XRI authority”, or “XRI authority name” we will refer to the same concept. Moreover, the XRDS document can be used to describe a XRI authority associated to a target CNE, indicating how to resolve the CNE itself in several CCNTXs by means of SEPs acting as “CCNTX Resolver Servers”. Figure 4 depicts the resolution process of a CNE name. In step 1 a client resolver which can be a generic end-user, the middleware of a Cloud platform or an external system performs a resolution request of a CNE name to the XRI name server associated to one or more Clouds. In step 2 the XRI name server responds with the XRDS document corresponding to the CNE name, so that the Cloud resolver, in step 3, selects right the CCNTX resolver server in order to retrieve the information associated to the CNE name in a given CCNTX. It important to stress that the CCNTX resolver server can return either information that the resolver can directly use, or metadata in order to perform tasks on other CCNTXs or systems. For example let us consider a virtual machine which needs

Figure. 4: Resolution process of a CNE name.

to be resolved in three different ways in different CCNTXs. In the fist way the VE has to be resolved by means of general metadata (e.g. CPU, memory, kernel, operating system, virtualization format version), in the second way the VE has to be resolved by means of instantaneous performance metadata (e.g. amount of used CPU and memory), in the third way instead the VE has to be resolved by means of SSO authentication metadata (e.g. information provided by an Identity Provider (IdP) asserting the trustiness of the VE when it migrate from a place to another in order to avoid identity theft). Such a situation can be addressed by mean of three different XRDs inside the XRDS document corresponding to the VE, each one pointing to a target SEP. Figure 5 shows a simplified example of XRDS document describing a CNE representing a VE. The XRI authority

Figure. 5: Example of XRDS document. “VE3” identifying a CNE “VE” is mounted under the parent

Celesti et al.

269 XRI authority xri://@CLOUDA*datacenter-1*host-1, and has also an unpersistent identifier “VM-Ubuntu-1” (i-name) and a persistent “4161540” (i-number). As the VE holds three representations in three CCNTXs, each element indicates how to resolve the VE in a given CCNTX by means of a SEP identified by one or more elements. This elements accept a URI, IRI, or XRI to identify the service type. This makes the XRDS format extensible without the need of a central registry. In addition, each SEP can include a set of URIs representing concrete network endpoints where a target service is available. In the example, the VE has three representations in three different CCNTXs. The SEP “ve.info” with URI http://CLOUDA.example.net/res/info/4161540/? returns general information regarding the VE. The SEP “ve-performance” with URI, http://CLOUDA.example.net/res/perf/4161540/? returns performance data. URI

The SEP “sso-auth” with

http://openid.example.net/4161540/? is resolved by an OpenID server [16] asserting the credential of the VE. As the aim of this paper is showing how it can be possible to apply the XRI naming system for the management of RESERVOIR use cases, further details regarding XRDS document are omitted. As far as it is concerned the integration among independent Cloud name spaces in a federated environment, the crossreference mechanism provided by XRI allows to logically mount CNE names belonging to a Cloud name space into another one. In order to clarify the ideas, let us consider two Cloud platform: A and B. Cloud A rents a VE which is physically placed its own virtualization infrastructure and which is identified by the XRI authority VE3 to Cloud B which logically considers such a VE as part of its virtual resource pool along with other VEs physically placed in its own virtualization infrastructure. Using the XRI cross-reference mechanism the target VE can be at the same time mounted inside the Cloud A name space xri://@CLOUDA*datacenter-1*host-1*VM3 and mounted through a XRI cross-reference mounting tasks also in Cloud B name space: xri://@CLOUDB*resources* (xri://@CLOUDA*datacenter-1*host-1*VM3)

VI. XRI Naming and Information Retrieval in RESERVOIR Use Cases In this Section, we debate how it is possible to address both naming and information retrieval in RESERVOIR use cases, using a combination of the XRI and the XRDS technologies,

as one of the possible implementation of the Cloud Naming Framework. In fact, the framework acts as an extensible and scalable mapping tool able to logically arrange any Cloud scenario. In the following, we demonstrate how XRI is able to solve many naming issues in Cloud environments. The main benefit of using XRI is the support to the hierarchical mounting (and unmounting) of single CNE names or entire name spaces (i.e., XRI tree or subtree) under other CNE names, by means of cross-reference mechanisms. For simplicity, in the following use cases we do not consider neither the mounting of the Cloud name space on the public DNS nor the integration between different Cloud name spaces, but we specifically focus on naming and information retrieval in RESERVOIR use cases. More specifically, in the following RESERVOIR scenarios we highlight how the XRI naming system can provides support for the management of security, QoS, and many other general purpose tasks. Even though, XRI can be used to represent practically any CNE, in order to map the RESERVOIR use cases we will focus on infrastructures, clusters, physical host running hypervisor, and virtual machines to arrange the name spaces of Telco, SGE, and SAP applications, each one deployed in a different IaaS of the Reservoir Cloud. In order to show how the naming system can provide support to security, QoS, and other general purpose tasks, we will present for each CNE different types of SEPs. More specifically, as example of the support of the naming system for security tasks we will consider SEPs acting as Identity Provider (IdP) servers. An IdP is a provider of SSO authentication services which allows to entities to perform the log-in once gaining the access to all the Service Providers (SPs) trusted with that target IdP. The process of SSO authentication works as follows: an entity has an account on an IdP. When the entity wants to perform the authentication on a specific SP, it performs the log-in once on the IdP which will assert the trustiness of the entity to all the trusted SPs. In all use cases the entities of the IdP/SP model are CNEs, whereas SPs represent CCNTXs (e.g. Clouds, infrastructures, services, etcetera). Instead as example of the support of the naming system for QoS and general purpose tasks we will consider SEPs acting as web service server providing respectively performance and general information related to CNEs in specific CCNTXs. A. The Telco Application Use-case In this use case, the Telco Operator, using a PaaS, acts as broker: it uses its own infrastructure or the physical resources rented from external infrastructure providers in order to offer deployment services to its clients (service providers), where they may deploy their services. The service provider will pay the deployment services according to the resource usage, business rules, and SLA contracts. The proposed naming solution allows a hierarchical organization of the involved CNEs, which are the Telco Operator itself, the infrastructures where the service are deployed and the services themselves. As depicted in Figure 6, each XRI name of an infrastructure or a service has been associated to a XRDS document, which contains the links to several SEPs resolving the CNE in a given CCNTX. For example, the name xri://@Telco*Infr 1, referred to an infrastructure, is associated to several SEPs,


Figure. 6: Telco Operator use case. which resolve the name in various CCNTXs. SEP1 provides general info (i.e. whether the infrastructure is physical and owned by the Telco Operator or it is virtual and rented from RESERVOIR), SEP2 provides metadata referred to the performance, SEP3 acts as IDP, asserting the authenticity of the infrastructure, when it needs to access to external assets of third parties. Example of IDP technologies are OpenId [16], SAML [22], and Shibboleth [23]. Instead, the name XRI://@Telco*Infr 1*Service 2 identifies a service deployed in the XRI://@Telco*Infr 1 infrastructure. It may be resolved by means of SEP3, SEP4, SEP5, and SEP6. SEP3, as well as for xri://@Telco*Infr 1, acts as IDP providing authentication data, when Service 2 needs to be identified by an external third party. SEP4 and SEP5 provide respectively information on the service and the relative performance, instead SEP6 resolve the service providing metadata related to resource consumption and billing.

270

given cluster. For example, the XRI://@Grid*Cluster2*VM2 identifies the virtual machine *VM2, belonging to the cluster named *Cluster2 and managed by the SGE application named XRI://@Grid. It may be resolved by means of SEP3, SEP4, and SEP5. SEP4 resolves the name XRI://@Grid*Cluster2*VM2 describing if the virtual machine runs a Master Host, an Execution Host, an Administration Hosts, or a Submit Host. In addition SEP3 provides information regarding the daemons installed and their status. SEP4 resolves virtual machine name providing metadata referred to its performances, whereas SEP3 acts as Identity Provider (IDP), asserting the authenticity of the virtual machine. In this case, the IDP prevents the access of false SGE Host to the SGE application. C. The eBusiness Use-case This use case is a little more complicated than the previous ones. It consists of the deployment of a SAP system into the RESERVOIR virtualization infrastructure. As depicted in Figure 8, the proposed naming solution allows a hierarchical organization of the involved CNEs, which may be a physical host, a virtual machine, or a ABAP program. The SAP

B. The Utility Computing Use-case In this use case, a SGE application is deployed into the RESERVOIR infrastructure in order to provide workload management and dynamic provisioning of resources. As depicted in Figure 7, the proposed naming solution allows a hierarchical organization of the involved CNEs, which may be hosts and clusters. Hosts are virtual machine hosted into the RESERVOIR virtualization infrastructure, whereas clusters are groups of virtual machines connected to a virtual network managed by RESERVOIR. The SGE appli-

Figure. 7: Utility Computing use case. cation must be able to identify the virtual machines of a

Figure. 8: eBusiness use case. system must be able to logically map and manage both its components (DI, CI, and DBMS) and the ABAP programs that it instantiates on-demand. Therefore, it has to identify which virtual machines host the various components, and which DI executes the ABAP programs. For example, the xri://@SAP*PH2*VM3 identifies the virtual machine *VM3 placed in a physical host *PH2, and managed by the SAP system named xri://@SAP. It may be resolved by means of SEP7, SEP8, and SEP9. SEP7 resolves the name xri://@SAP*PH2*VM3 describing the configuration of the virtual machine (i.e., CI/DBMS, DI/CI-DBMS, or DI). SEP8 resolves virtual machine name providing metadata referred to its performances. SEP9 acts as Identity Provider (IDP), asserting the authenticity of the virtual machine. In this case, the IDP prevents the access of false SAP components to the SAP system. Instead, the xri://@SAP*ABAP 1 name identify a ABAP program, which may be resolved with monitoring, performance, and authentication metadata by means of the SEP10, SEP11, and SEP12. As a single ABAP program may be executed by one or more virtual machines acting as DIs, it is needed to identify each single ABAP instance. In Figure 8, using the XRI cross-reference mecha-

Celesti et al.

271 nisms, the xri://@SAP*ABAP 1/*(xri://@SAP*PH2*VM3) name identifies the aforementioned virtual machine *(xri://@SAP*PH2*VM3) acting as DI, hosting an instance of the *ABAP 1 program in the xri://@SAP system.

VII. Conclusions and Future Works In this paper we tackled the naming and resource location problems in Cloud computing, more specifically focusing on some RESERVOIR use cases. A reference Cloud Naming Framework has been defined and some examples of Cloud naming scenarios have been presented considering XRI and XRDS technologies. More specifically, three RESERVOIR use cases have been treated providing resource identification and resolution examples. In future works we will use the reference naming framework to address scenarios where it is needed an integration between independent Cloud name spaces.

Acknowledgements The research leading to the results presented in this paper has received funding from the European Union’s seventh framework programme (FP7 2007-2013) Project RESERVOIR under grant agreeement number 215605.

References [1] A. Celesti, M. Villari, and A. Puliafito, “Ecosystem of Cloud naming systems: An approach for the management and integration of independent Cloud name spaces,” in The 9th IEEE International Symposium on Network Computing and Applications (NCA), pp. 68 – 75, july 2010.

[8] C. M. S. Roschke, F. Cheng, “An advanced ids management architecture,” Journal of Information Assurance and Security, vol. 5, pp. 246–255, 2010. [9] S. Clayman, A. Galis, C. Chapman, L. Merino, L. Vaquero, K. Nagin, B. Rochwerger, and G. Toffetti, “Monitoring future internet service Clouds,” in Towards the Future Internet - A European Research Perspective book, pp. 115–126, April 2010. [10] S. Clayman, A. Galis, and L. Mamatas, “Monitoring virtual networks,” in Towards the Future Internet A European Research Perspective book, pp. 115–126, April 2010. [11] D. Yang, Y. Qin, H. Zhang, H. Zhou, and B. Wang, “Urns: A new name service for uniform network resource location,” in Wireless, Mobile and Multimedia Networks, 2006 IET International Conference, pp. 1–4, 2006. [12] Y. Doi, S. Wakayama, M. Ishiyama, S. Ozaki, T. Ishihara, and Y. Uo, “Ecosystem of naming systems: discussions on a framework to induce smart space naming systems development,” in ARES, p. 7, April 2006. [13] Y. Doi, “Dns meets dht: treating massive id resolution using dns over dht,” in Applications and the Internet International Symposium, pp. 9–15, January 2005. [14] G.-J. Ahn, M. Ko, and M. Shehab, “Privacy-enhanced user-centric identity management,” in IEEE International Conference on Communications, ICC ’09, pp. 14–18, June 2009. [15] B. Sotomayor, R. Montero, I. Llorente, and I. Foster, “Virtual infrastructure management in private and hybrid Clouds,” Internet Computing, IEEE, vol. 13, pp. 14–22, September 2009.

[2] J. Caceres, R. Montero, B. Rochwerger, “RESERVOIR: An Architecture for Services, The first issue of the RESERVOIR Architecture document”, http://www.reservoir-fp7.eu/twiki/pub/Reservoir/Year1 Deliverables/080531-ReservoirArchitectureSpec1.0.PDF, June 2008.

[16] D. Reed, L. Chasen, and W. Tan, “Openid identity discovery with xri and xrds,” in Proceedings of the 7th symposium on Identity and trust on the Internet, pp. 19– 25, 2008.

[3] Extensible Resource Identifier (XRI) Syntax V2.0, OASIS, http://www.oasis-open.org.

[17] Higgins, Open Source Identity Framework, http://www.eclipse.org/higgins/.

[4] Extensible Resource Identifier (XRI) Resolution V2.0, OASIS, http:/docs.oasis-open.org/xri/2.0/specs/xriresolution-V2.0.html.

[18] D. Reed, G. Strongin, XDI (XRI Data Interchange), A White Paper for the OASIS XDI Technical Committee v2, OASIS, 2004.

[5] I. Foster, Y. Zhao, I. Raicu, and S. Lu, “Cloud computing and grid computing 360-degree compared,” in Grid Computing Environments Workshop, 2008. GCE ’08, pp. 1–10, 2008.

[19] RFC 3986, Uniform Resource Identifier (URI): Generic Syntax, http://www.ietf.org/rfc/rfc3986.txt.

[6] R. L. Grossman, “The case for Cloud computing,” in IT Professional, vol. 11, pp. 23–27, March-April 2009. [7] E. K. Manabu Hirano, Takeshi Okuda and S. Yamaguchi, “Design and implementation of a portable idmanagement framework for a secure virtual machine monitor,” Journal of Information Assurance and Security, vol. 2, pp. 211–216, 2007.

[20] RFC 3987, Internationalized Resource Identifiers (IRIs), http://tools.ietf.org/html/rfc3987. [21] RFC 2141, Uniform Resource Names (URNs): URN Syntax, http://www.ietf.org/rfc/rfc2141.txt. [22] SAML V2.0 Technical Overview, OASIS, http://www.oasis-open.org. [23] The Shibboleth system standards http://www.openqrm.com.


Author Biography Antonio Celesti received the master degree in Computer Science at the Faculty of Mathematical, Physical and Natural Sciences, University of Messina, Italy in 2008, final score 110/110 cum summa laude; the topic of his thesis focused on Service Oriented Architectures (SOAs) and Web Services. From April 2009, he is attending his Ph.D. studies in “Advanced Technologies for Information Engineering” at the Faculty of Engeenering, University of Messina, Italy. From April 2009 e is one of the members of the Multimedia and Distributed Systems Laboratory (MDSLab), Messina, Italy. In 2010 he was winner of the best paper award at “The Second International Conference on Advances in Future Internet”. His scientific activity has been focused on both distributed systems and Cloud computing. His main research interests include virtualization, migration, security, federation, and information retrieval. Massimo Villari received his PhD in 2003 Computer Science School of Engineering and the Laurea degree (bachelor’s degree + masters) in 1999 in Electronic Engineering, University of Messina, Italy. Since 2006 he is an Assistant Professor at University of Messina. He is actively working as IT Security and Distributed Systems Analyst in Cloud computing, virtualization and Storage for the European Projects “RESERVOIR” and “VISION”. Previously, he was an academic advisor of STMicroelectronics, help an internship in Cisco Systems and worked on the MPEG4IP and NEMO projects. He investigated issues related with user mobility and security, in wireless and ad hoc and sensor networks. He is IEEE member. Currently he is strongly involved on EU Future Internet initiatives, specifically Cloud Computing and Security in Distributed Systems. His main research interests include virtualization, migration, security, federation, and autonomic systems. Antonio Puliafito is a full professor of computer engineering at the University of Messina, Italy. His interests include parallel and distributed systems, networking, wireless and GRID and Cloud computing. During 1994-1995 he spent 12 months as visiting professor at the Department of Electrical Engineering of Duke University, North Carolina - USA, where he was involved in re-

272

search on advanced analytical modelling techniques. He is the coordinator of the Ph.D. course in Advanced Technologies for Information Engineering currently available at the University of Messina and the responsible for the course of study in computers engineering. He was a referee for the European Community for the projects of the fourth, fifth and sixth Framework Program and he is currently acting as a referee also in the seventh FP. He is currently the director of the RFIDLab, a joint research lab with Oracle and Intel on RFID and wireless. He acted as the director of the Centre on Information Technologies Development and Their Applications (CIA) till 2009. He is currently the vice-president of the Consorzio Cometa whose aim is to enhance and exploit high performance computing. From 2006 to 2008 he acted as the technical director of the Project 901, aiming at creating a wireless/wired communication infrastructure inside the University of Messina to support new value added services (winner of the CISCO innovation award). He is also the responsible for the University of Messina of two big Grid Projects (TriGrid VL, http://www.trigrid.it, and PI2S2, http://www.pi2s2.it) funded by the Sicilian Regional Government and by the Ministry of University and Research, respectively. He is currently a member of the general assembly and of the technical committee of the Reservoir project, an IP project funded from the European Commission under the seventh FP to explore the deployment and management of IT services across different administrative domains, IT platforms and geographies. He is the scientific director of Inquadro s.r.l., a spin-off company of the University of Messina whose main business is RFID and its application both in public and private sectors. Francesco Longo received his Degree in Computer Engineering from the University of Messina (Italy) in november 2007, final score 110/110 cum summa laudae. The title of his thesis was “Symbolic representation of the reachability graph of nonMarkovian stochastic Petri net”. From settember 2007 to june 2008 he worked at the University of Messina within the PON Project “Progetto per l’Implementazione e lo Sviluppo di una e-Infrastruttura in Sicilia basata sul paradigma della grid (PI2S2)” with the aim of designing and implementing a QoS management system in Grid environment. In june 2008 he received a Master’s degree in Open Source and Computer Security. He is currently attendig his Ph.D studies in “Advanced Technologies for Information Engineering” at the University of Messina. His main research intersts include performance and reliability evaluation of distributed systems (mainly Grid and Cloud) with main attention to the use of non-Markovian stochastic Petri nets. Between May 2010 and October 2010 he spent a period as a visiting scholar in the United States at the Duke University (Durham, NC) where he had the opportunity to callaborate with prof. Kishor S. Trivedi in the modeling of Cloud systems and in the quantitative evaluation of their performance and availability.