Ecosystem of Cloud Naming Systems: an Approach for the Management andIntegration of Independent Cloud Name Spaces

Antonio Celesti, Massimo Villari and Antonio PuliafitoDept. of Mathematics, Faculty of Engineering, University of Messina

Contrada di Dio, S. Agata, 98166 Messina, Italy.e-mail: acelesti, mvillari,apuliafito@unime.it

Abstract—Cloud computing is a highly dynamic environmentwhere resources can be composed with other ones to providemany kinds of services to clients. In such scenario namingand resource location become critical issues and the existingDomain Name System (DNS), considered alone, is not ableto address the new emerging problems. A cloud environmentoffers a variety of concrete and abstracted entities which needto be identified, whose states can frequently change: a virtualresource, could be allocated, deallocated or moved from acontext to another. Moreover, a cloud entity could hold one ormore names, identifiers, and representations in various cloudcontexts where name alterations could frequently occur. In suchenvironment, the management and integration of independentcloud name spaces is then becoming more compelling. Thispaper aims to propose a cloud naming system able to addresssuch problems, providing an implementation practice in a cloudfederation use case.

Keywords-Cloud Computing; Cloud Name Space; CloudNaming System; Cloud Federation; XRI; XRDS.

I. INTRODUCTION

In cloud computing environments, as well as in all systemscharacterized by a high level of dynamism, naming andresource location become critical issues. Until now, theInternet has used the Domain Name System (DNS) forthe resolution of domain names, that does not seem tobe suitable to the new emerging cloud scenarios. In fact,the DNS presents several disadvantages: it is host-centric,unscalable and unsuitable to describe complex structuredentities by mean of its own resource records.

In cloud computing there are a variety of entities whosestate could frequently change: for example a virtual resource,could be allocated, deallocated or moved from a context toanother by means of migration mechanisms. In addition, amigration could trigger an identity alteration, since an entitycan be moved from a cloud to another: a cloud entity beingpart of a virtual cloud application could later become partof another cloud application, either in the same cloud orin another cloud if we consider federated environments. Inaddition, these entities might hold one or more identifiersalso with different levels of abstraction. Furthermore, theperspective of federation among heterogeneous clouds, andthe dynamic provisioning and migration of virtual resources,open toward new challenges. In such context, the manage-ment of cloud entity names and cloud name spaces maybecome very difficult.

In a high-dynamic, heterogeneous, and federated cloudscenario, the need of an effective cloud naming system isbecoming more compelling. Such naming system shouldbe characterized by: scalability, extensibility, services ofdescription and discovery, name recycling, non-correlation,and name space integration mechanisms which avoid nameconflicts. To achieve this goal, in our opinion, it is neededa preliminary analysis of the involved entities in variouscloud contexts as well as an investigation of the cloud namespace. This paper aims to propose a practice of cloud namingsystem in which it is possible to manage and integrateindependent cloud name spaces. The main advantages of theproposed cloud naming system are: I) integration betweendifferent cloud name spaces, II) support to the “mounting”of a cloud name space under other cloud name spaces, III)compatibility with other URI-based naming system and withthe public DNS. We propose a reference framework for ageneric cloud naming system and an implemented approachbased on the integration of three main technologies: eX-tensible Resource Identifier (XRI) [1], eXtensible ResourceDescriptor Sequence (XRDS) [2], HTTP, and DNS. Wepresent a use-case of the proposed cloud naming systemin a scenario of federated clouds where a provisioning ofvirtual resources from a cloud to another is performed.

The paper is organized as follows: section II describesthe state of the art of naming systems and the most widelyadopted solutions in distributed systems and in ubiquitouscomputing environments. Section III provides a brief de-scription of cloud computing and the importance to managecloud name spaces: we define what are the possible cloudname spaces, pick out which are the named entities involved,and which are their behaviors and relationships. In addition,we introduce the terminology adopted in the rest of the pa-per. In section IV we present an analysis of the requirementsthe cloud naming system has and introduce a referenceframework used to develop our own cloud naming system.In section V we describe which are the technologies adoptedto develop the proposed cloud naming system and howthese may be used for resource description and resolutionpurposes. In section VI we show a detailed use case, wherethe proposed cloud naming system supports the provisioningof resources between two federated clouds. We demonstratehow a resource belonging to a cloud name space can be

mounted under the name space of another federated cloudthrough name space integration and aliasing mechanisms.Conclusions and lights to the future are summarized insection VII.

II. RELATED WORKS

Cloud computing is generally considered as one of themore challenging research field in the IT world. It mixesaspects of Utility computing, Grid computing, Internet Com-puting, Autonomic computing and Green computing [3]. Insuch perspective naming and resource location are criticalissues. Nevertheless, in literature there are not many workson naming systems in cloud computing, as DNS is stillerroneously considered as the “panacea for all ills”. DNSpresents some problems: it is host centric, unsuitable forcomplex data and services location, and it is not suited toheterogeneous environments. Possible improvements mightcome from the naming system works in high-dynamic,heterogeneous and ubiquitous environments. An alternativeto DNS is presented in [4]. The authors propose a UniformResource Name System (URNS), a decentralized solutionproviding a dynamic and fast resource location system forthe resolution of miscellaneous services. Nevertheless, thework lacks of an exhaustive resource description mechanism.With regard to naming system in ubiquitous computing, in[5] the authors propose a naming system framework forsmart space environments. The framework aims to integrateP2P 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 thatmoves from a smart space to another using as descriptionmechanism the little exhaustive DNS resource records. Ahybrid naming system that combines DNS and DistributedHash Table (DHT) is presented in [6]. The authors adopt aset of gateways executing a dynamic DNS name delegationbetween DNS resolver and DHT node. With regard advancedresource description technologies, OASIS is developing theeXtensible Resource Identifier (XRI) [1], a URI-compatibleprotocol that provides a uniform syntax for abstract andstructured entities. OASIS is defining also a simple genericresource descriptor format (XRDS) [2], that aims to becomethe standard in the near future. We believe that theseprotocols offer excellent potentialities to solve many cloudnaming and resource location problems.

III. OUR CLOUD NAME SPACE ANALYSIS

In this section, we clarify some ideas concerning namespaces and cloud name systems in cloud computing. In ahigh-dynamic federated cloud environment, the design of acloud naming system could be very hard. First of all, it is notclear which are the entities and the virtual contexts involved.Moreover, in federated environments, a cloud naming systemshould be able to manage frequent name alteration and namespace integration. The following analysis aims to clarify such

concerns. Regardless the internal cloud structure, we think acloud has many logical representations in various abstractionlevels. In addition, there are many abstracted, structuredentities involved. These entities are characterized by a high-level of dynamism: allocations, changes and deallocationscould occur frequently. Moreover, these entities may haveone or more logical representations in one or more contexts.But which are the entities involved in cloud computing? Todescribe such entities we introduce the generalized conceptof Cloud Named Entities Class (CNEC). It indicates aset of Cloud Named Entities (CNEs) involved in cloudcomputing. A CNE is a generic entity indicated by a nameor an identifier which may refer both to real/abstracted andsimple/structured entities. Examples of abstract structuredCNEs may be a cloud federation, a cloud itself, a sub-cloud,a cloud application provided in form of Infrastructure as aService (IaaS), Platform as a Service (PaaS) or Softwareas a Service (SaaS). A real, structured CNE may be a site(or a cluster) or a host running a hypervisor which encom-passes several virtual machines (VMs). A simple, abstractedentity could be instead a VM. Futhermore CNEs could berepresented by cloud users: cloud technicians responsible ofadministration tasks, organizations, enterprises, data centerswhich use cloud applications, clouds themselves which useeither cloud applications or directly the virtual resourcesprovided by other federated clouds, and generic end-userswho use cloud service applications. Figure 1 depicts thepossible CNEs involved in cloud computing.

Figure 1. Cloud Named Entity (CNE).

In our abstraction, we assume that a CNE is associatedto one or more identifiers. In such perspective it becomesfundamental the user-centric identity model [7]. Using suchmodel an entity has full control of its identity. Let’s considera person. Her identity could be associated to many identi-fiers: home address, telephone number, personal web page,email address and other accounts. When the number of suchidentifiers becomes huge, their management becomes verydifficult. With the user-centric identity, users have completecontrol over their identifiers. Therefore, it is the user who

decides what her identifiers are and which informationwill be shared in a given context. While on one hand aCNE is subject to frequent changes and it holds differentrepresentations in various Cloud Contexts (CCNTXs), inour opinion, the user-centric identity model seems to be themost convenient approach to the cloud identity management.We define a CCNTX as an environment where a CNE isrepresented by one or more identifiers. A CCNTX can berepresented by a cloud federation, a cloud itself, a sub-cloud,a cloud application or whatever abstracted environment. Inthis work, we assume that the digital identity of a CNEis represented by one or more service end-points (SEPs),which are objects asserting the identity of a CNE in adetermined CCNTX. A service end-point is, for example, aweb service, a web application, or an authentication serverthat returns metadata associated to a CNE in a CCNTX.Figure 2 depicts a generic CNE which holds six identitieswithin four CCNTXs. The target CNE holds identity 1, 2inside CCNTX A, identity 3 inside CCNTX B, identity 4inside CCNTX C, and identity 5, 6 inside CCNTX D.

Figure 2. Representation of CNE in several CCNTXs.

Nowadays, name spaces are widely used to identify en-tities in various contexts. Examples include DNS, electricproduct codes, and credit card numbers. Considering theDNS and the URL http://example.net, a client resolver willlook up a resource record associated to the name example.netto find the corresponding IP address. We define a CloudNaming System (CNS) as a system that maps one or moreidentifiers to a CNE. A CNS consists of a set of cloudnamed entities, an independent cloud name space, and amapping between them. A cloud name space is a definitionof cloud domain names. Instead, a name or identifier isa label used to identify a CNE. A client resolver whoneeds to identify a CNE in a given CCNTX performs aresolution task. Resolution is the function of referencingan identifier to a set of metadata describing the CNE ina given CCNTX. In our scenario we assume that each

cloud holds an independent name space. In a high-dynamicand federated cloud environment the integration betweenseveral independent cloud name spaces becomes a criticalissue and an essential feature. The integration between moreindependent cloud name spaces open toward new challenges:

• A CNE could hold several logical representations invarious CCNTXs.

• A CNE belonging to a cloud name space could holdfurther logical representations in other cloud namespaces.

• In a federated cloud scenario the name of a CNEphysically placed in a cloud could be moved from acloud name space to another.

A solution for the integration among independent cloudname spaces is to use the existing DNS. Figure 3 shows anexample of integration among two independent cloud namespaces using the DNS. Each cloud name space includes

Figure 3. Example of cloud name spaces integration.

several CNEs. CNE A and C are placed in cloud Ω, whereasCNE B is placed in cloud Φ. In the example, the three CNEsidentify VMs. CNE A and B are identified by the samename VM1 and CNE C is identified by the name VM13. Anintegration between these cloud name spaces must preventname conflicts. Mounting the two name spaces under thesame DNS root it is possible to avoid such conflicts. Asshown in Figure 3, cloud name space Ω is mounted undercloudΩ.org, while cloud Φ is mounted under cloudΦ.net.So, it is possible to distinguish the name VM1.cloudΩ.orgof CNE A from the name VM1.cloudΦ.org of CNE B.Such integration allows for further functionalities. First, itis possible to identify the same CNE in different cloudname spaces. Second, it is possible to move a name of aCNE from a cloud name space to another. In the example,CNE A is physically placed in cloud Ω and it is representedwith identifier VM1 into the cloud name space Ω and withidentifier VM4 into the cloud name space Φ. Instead, CNEC is physically placed in cloud Ω, but its logical identifierVM13 is moved from the cloud name space Ω to the cloud

name space Φ. This operation implies an unmount task of thename VM13 from the DNS sub-tree cloudΩ.org and a mounttask of the name VM13 under the DNS sub-tree cloudΦ.netwhich will become VM13.cloudΦ.net

IV. OUR CLOUD NAMING SYSTEM FRAMEWORK

In this section, we describe our proposal for a CloudNaming System framework. After a preliminary requirementanalysis, we present the proposed framework in detail andshow how it can be used inside a generic cloud platform.

A. Objective and Requirements

Cloud name space management raises new challengesconcerning: compatibility, scalability, extensibility, CNEdescription, name recycling, non-correlation, and namespace integration. Our solution to the problem is a CloudNaming System Framework (CNSF) suitable to any exist-ing cloud platform such as Reservoir [8], Eucalyptus [9],Cloud@Home [10], OpenQRM [11], and many others. Thepurpose of the framework is to allow clouds to managetheir name spaces, mapping one or more names associatedto a CNE, with the corresponding service representing thetarget CNE in a given CCNTX. In addition the frameworkmust be able to manage and resolve names of every CNEtype: i.e. end users, administrators, federated clouds, cloudsthemselves, sub-clouds, cloud services (in form of SaaS,PaaS, or IaaS), and virtual machines. The first goal ofour CNSF is the compatibility among independent namespaces of federated clouds. In addition, in an environment,which is subject to frequent changes, the framework mustguarantee scalability and extensibility features. Each CNEmay need of a particular description mechanism. In fact,CNEs are more complex than the current Internet webresources, and DNS resource records are not appropriate todescribe them. Hence, the framework must guarantee moreadvanced CNE description mechanisms. Resolution is thefunction of dereferencing a name or an identifier to a set ofmetadata describing the identified entity. Typically, a DNSname is resolved by means of resource records associatingIP addresses. The framework, using CNE description mech-anisms, has to properly resolve a CNE name, by meansof service end-points returning the metadata associated tothe CNE in one or more CCNTXs. Moreover, if a CNEceases to exist, a name recycling mechanism is needed.Given that each cloud manages its own name space, thesame name, representing two or more different CNEs, mightoccur in different independent cloud name spaces. In suchcase, the CNSF must ensure non-correlation mechanisms,avoiding name conflicts and guaranteeing the correct reso-lution process. Furthermore, in the federation perspective,the framework should allow independent cloud name spaceintegration and CNE mounting from an independent cloudname space to another. For example, let’s think to a team ofoperators working in cloud A. Cloud A decides to extend its

virtual infrastructure using for billing the virtual resourcesof a federated cloud B. On one hand, the acquired resourcesare physically placed in cloud B, but on the other hand,the operators must be able to access such resources in thesame way they access the virtual resources placed in cloudA. A solution to the problem is to mount the names of theacquired virtual resources in the cloud A name space.

B. The Framework Components

For scalability, extensibility, and compatibility purposes,we assume that each cloud manages its own independentname space using any of the available naming systemtechnology. In fact, the technology adopted does not haveto prevent the applicability of the framework. A genericcloud architecture is presented in [12]. It includes basicallythree main components: Cloud Manager, responsible forthe administration of the entire cloud; Virtual InfrastructureManager, responsible for the management of the underlyingvirtual infrastructure; Virtual Machine Manager, represent-ing an hypervisor managing VMs. More specifically, a CloudManager is responsible for monitoring, QoS, billing, identitymanagement, and federation. Each of such tasks requires toname and resolve appropriately the involved CNEs insideCCNTXs. For example, for monitoring purposes the name ofa CNE may be resolved with the corresponding performancemetadata. Instead, for security purposes, a CNE name couldbe resolved by means of an identity provider asserting itscredentials in a given CCNTX. In such perspective theframework can be used in Cloud management providingnaming support in monitoring, QoS, billing, identity man-agement, and federation. Figure 4 depicts the CNSF indetail. The framework includes the following components:CNE descriptor, Cloud Naming System, Cloud Name SpaceMounter, Cloud Name Space Manager, Cloud FederationCross-Resolver, and Public Naming System Mounter.

Figure 4. CNSF integrated in a generic cloud architecture.

A CNE Descriptor is the component describing a genericCNE. It can be a document containing a set of metadata:

names and aliases associated to the target CNE, and a set ofpointers to one or more service end-points representing theCNE in various CCNTXs. For example, considering a virtualmachine, a service end-point 1 can provide general de-scription informations (i.e. creation date, operating system,and version), a service end-point 2 can indicate an identityprovider asserting its credential inside a cloud X, and aservice end-point 3 can provide the real time performanceinside a cloud application of the cloud X. A Cloud NamingSystem represents the naming system used inside a cloud. ACloud Name Space Mounter, is the component responsibleof mounting a CNE name inside the Cloud Naming System.A Cloud Naming System Manager is the main componentof the framework. It coordinates the whole cloud naming,managing the Cloud Naming System, the mounting of CNEnames by means of the Cloud Mounter, the integration withother federated cloud name spaces, and the integration withthe public naming system. It plays an important role incloud name space integration by means of cross-referenceand cross-resolver mechanisms. Let’s consider two differentclouds with different name spaces which establish a federa-tion. With cross-reference mechanisms the two clouds couldmount their name spaces under a common root authorityforming a new CNE with a federated name space. Instead,cross-reference mechanisms permit the Cloud Name SpaceManager to perform CNE name mounting inside the samename space or from a cloud name space to a another. ACloud Federation Cross-Resolver is the component whichdefines a cloud federation name space root under whichthe name spaces of the complying clouds will be linked.Besides defining the name space root, it is also responsiblefor avoiding name conflicts. In a federated cloud scenarioseveral Cloud Federation Cross-Resolvers may exist, onefor each cloud federation. In some cases there may be theneed to mount whole cloud name spaces or part of themin a public name space domain. In such perspective theframework must guarantee interoperability with any publicnaming system. For such purpose, a Public Naming SystemMounter has been designed to act as a gateway betweencloud name spaces and the public name space. Currently,DNS is the public naming system adopted over the Internet.Considering DNS, the Public Naming System Mounter maybe a DNS authority server integrating cloud name spaces inthe DNS hierarchy. In such perspective the component mustaccomplish parsing tasks from the cloud naming system toURL. In a distributed scenario many Public Naming SystemMounter may be active for each geographical area.

V. DESIGN DETAILS

In this section, we describe a CNSF implementationbased on the Yadis [13], XRI, XRDS, HTTP and DNS,representing a set specifications and technologies selectedto meet the framework requirements argued in section IV-A.Yadis is a RESTful specification providing: a general pur-

pose identifier for people or any other entity, which canbe used with a variety of services; a service descriptiondocument identifying services available using the identifier;a protocol for obtaining a resource description document fora given identifier. The specification represents a guideline,but does not define implementation details. Therefore, inour CNSF practice we used XRI to name CNEs, XRDS asCNE description document, and HTTP as protocols for XRIresolution of CNE names in various CCNTXs.

A. XRI and XRDS

The XRI protocol provides a standard syntax for identi-fying entities, regardless any particular concrete represen-tation. The protocol is built on URI (Uniform ResourceIdentifiers) and IRI (Internationalized Resource Identifiers)extending their syntactic elements and providing parsingmechanisms. Particular types of URI are URN and URL.Since an URL is also an URI, the protocol provides aparsing mechanism from XRI to URL. Therefore XRI isalso compatible with any URN domain. XRI supports per-sistent and reassignable identifiers by means of i-numbers(Canonical ID) and i-names (Local ID). It also provides fourtypes of synonyms (LocalID, EquivID, CanonicalID, andCanonicalEquivID) to provide robust support for mappingXRIs, IRIs, or URIs to other XRIs, IRIs, or URIs thatidentify the same target entity. This is particularly useful fordiscovering and mapping to persistent identifiers as oftenrequired by trust infrastructures. The protocol provides twoadditional options for identifying an authority: Global Con-text Symbols (GCS) and cross-references. Common GCS are“=” for people, “@” for organization, and “+” for genericconcepts. For example the xri://@XYZ*marketing indicatesthe marketing branch of an organization named XYZ, wherethe “*” marks a delegation. Instead, cross-reference allowsXRI references to contain any other XRI references or IRIsas sub-segments. The XRI system is similar to DNS, includ-ing a set of hierarchical XRI authorities. XRDS documentsrepresents a simple, extensible XML resource descriptionformat standard describing the features of any URI, IRI, orXRI-identified resource in a manner that can be consumedby any XML-aware system. As XRIs may be used across awide variety of applications, no single resolution mechanismmay prove appropriate for all XRIs. Using HTTP, XRIresolution involves two phases: Authority resolution which isthe phase required to resolve a XRI into a XRDS documentdescribing the target entity, and service end-point selectionwhich is the phase of selection in the final XRDS documentof the specific service end-point returning the metadatadescribing the entity in a given context.

B. XRI and XRDS for the CNSF

In our practice, XRI is the main technology adopted inthe CNSF for the management of cloud name spaces. Infact it guarantees scalability, extensibility, and compatibility

with other URI-based technologies. XRI identifiers areused by the Cloud Naming System Manager to name CNEsusing XRI Canonical ID and Local ID to ensure also namerecycling support. XRI cross-reference mechanisms areused both for compatibility between the cloud namingsystems and for the integration of independent cloudname spaces. As described in section IV-B, each cloudmanages its own independent name space using any namingsystem technology. In fact, the technology adopted doesnot have to prevent the applicability of the framework.By means of XRI cross-reference, the Cloud Name SpaceManager may manage any naming system URI/IRI-based.Therefore, it can manage also peer-to-peer naming systemassociated to the URN model. Cross-reference allowsalso to the Cloud Name Space Manager the integrationwith other federated cloud name spaces. By means ofcross-reference, Cloud Name Space Manager, through theCloud Mounter, mounts CNE names from a cloud namespace to another. XRI cross-reference enables also cross-resolver mechanisms. Cross-resolver allows integrationbetween two or more independent cloud name spacesunder a common XRI CNE root representing a cloudfederation. The cross-resolver task is performed into theframework by the Cloud Federation Cross-Resolver, thatis responsible for the name space of a cloud federation,issuing the common XRI root under which the federatedcloud name spaces are mounted. The compatibility withthe public DNS is instead ensured thought XRI parsingmechanisms used by the Public Naming System Mounterthat is a name server authority acting as gateway betweenthe cloud naming systems and the DNS. XRDS documentsare used in the CNSF as CNE descriptor. It includes a setof metadata identifying the CNE in various CCNTX. AnXML-aware CNE resolver, first performs the resolution ofthe corresponding XRDS document selecting the serviceend-point representing the CNE in a given CCNTX, and thenit forwards a metadata request. Figure 5 shows an exampleof XRDS document describing a CNE which represents avirtual machine. The virtual machine is mounted on theparent XRI Authority xri://@CLOUDA*lab2*host1with xri://@CLOUDA*lab2*host1*VM3 and holdboth a LocalID H2 VM3 and a CanonicalIDxri://@CLOUDA*lab2*host1/!1234. The virtual machineholds three representations in three CCNTXs. Each XML<xrd:service> element indicates a representation of theCNE in a given CCNTX by means of a service end-point.Each service end-point, can be identified using one ormore <xrd:Type> elements and returns the metadatadescribing the resource in the CCNTX. This elementsaccept a URI, IRI, or XRI to identify the service type. Thismakes the XRDS format extensible by any specificationor service provider without the need for a central typeregistry. In addition to advertising the service types itsupports, each service endpoint can include a set of URIs

Figure 5. An example of the virtual machine XRDS document.

representing concrete network endpoints where this serviceis available. In the example, the virtual machine hasthree representations in three different CCNTXs. The firstservice end-point xri://@CLOUDA*lab2*host1/!1234of type xri://$res*cloudA*info returns generalinformations on the virtual machine. The second,xri://@CLOUDA*lab2*host1/!1234, of typexri://$res*auth*($v*2.0) indicates an OpenID [14] serverasserting the credential of the virtual machine insideCloud A. The third, xri://@CLOUDB*PlatformB/!9457,of type xri://$res*performance, returns metadatarepresenting the performace of the virtual machineinside xri://@CLOUDB*PlatformB CCNTX. The XMLelement <service:URI> indicates instead the location ofthe service end-points.

VI. USE CASES IN FEDERATED CLOUD SCENARIOS

The CNSF is designed to address any cloud namingscenario. In this section, we discuss how it allows tomanage and to integrate several independent cloud namespaces in federated scenarios. More specifically, a resourceprovisioning use case is presented with some configurationexamples.

A. CNSF as Support for the Cloud Federation

The CNSF is designed to address several cloud federationscenarios. We distinguish at least three typical cases ofcloud federation: Horizontal Federation, Vertical Federation,and Enterprise-Cloud Federation. In Horizontal Federation,clouds gain economies of scale performing an efficient useof their assets to meet peak capacity. In Vertical Federation,

clouds offers services to other federated clouds. Instead, inEnterprise-Cloud Federation, clouds offer services to organi-zations, enterprises, and data centers. In Figure 6 is depictedan example of how the framework provides naming supportto the three types of cloud federation. In the Horizontal

Figure 6. Examples of application of CNSF to cloud federation scenarios.

Federation, there are two CNEs represented by Clouds Aand B, which in order to perform an efficient use of theirassets, decide to adhere to a cloud federation named SIL-VERFED, that we consider as an abstract CNE. Thus, CloudName Space Managers A and B contact the Cross-ResolverCloud Federation corresponding to SILVERFED. The Cross-Resolver Cloud Federation analyzes the two cloud namespace roots, and avoiding name conflicts, returns a commonXRI root representing the @SILVERFED federation. There-fore, Cloud Name Space Manager A and B contact theirrespective Name Space Mounters which link cloud A andcloud B independent name spaces under the common XRI@SILVERFED root creating a new federated name space.Thus, cloud A will be referred as @SILVERFED*CLOUDA,whereas cloud B as @SILVERFED*CLOUDB. In VerticalFederation, Cloud C needs a platform for testing its ap-plications. Thence, it decides to use a cloud applicationgranted by cloud A in form of PaaS. Such cloud appli-cation is considered as a CNE identified with the XRIname TESTING. Thus, Cloud C’s Name Space Manager,by means of its Cloud Name Space Mounter and usingcross-reference mechanisms, mounts the cloud applicationTESTING under the XRI @CLOUDC root. Therefore, cloudC may refer to the acquired cloud application with thename @CLOUDC*TESTING. In Enterprise-Cloud Feder-ation, XYZ Organization is a software house that needs ofan infrastructure to give support to its development team.XYZ Organization decides to purchase a cloud applicationin form of IaaS from cloud B. Cloud B instantiates andmounts the cloud application in its XRI naming system.The organization holds a XRI-based intranet naming system,

and through cross-reference mechanisms mounts the cloudapplication under its XRI root assigning the alias DEVEL-OPMENT. Thus, XYZ can refer to the cloud application asXRI @XYZ*DEVELOPMENT also if it is not physicallyplaced in its infrastructure. In each type of federation, theintegration with the public naming system is guaranteedby several Public Naming System Mounters which act asgateways between independent or federated cloud namespaces and the public name space. Considering the DNS,we may have one or more Public Naming System Mountersspread in several geographic locations acting as special typeof DNS name servers which perform parsing tasks from theXRI format to URL and the mounting under a DNS subtree.

B. Resources Provisioning in Horizontal Cloud Federation

CNSF is designed to address any cloud naming issue. Asa use case of the applicability of the framework, we considertwo clouds performing a “resource provisioning task” ina horizontal federation scenario where is accomplished anintegration among the two independent cloud name spaces.The reference scenario is depicted in Figure 7. It describesstep by step the phases of the name space integration.

Figure 7. Use case of the CNSF in horizontal cloud federation.

Clouds A and B are CNEs whose XRI are respectively“@CLOUDA” and “@CLOUDB”. Both systems managetheir own independent name spaces using the XRItechnology. Cloud A is also member of the CNEcorresponding to the cloud federation indicated withthe XRI “@SILVERFED”. By means of cross-referencemechanisms, the cloud A name space with root @CLOUDAis mounted under the cloud federation root @SILVERFED.The resulting XRI is @SILVERFED!A/ (!@CLOUDA),where “@SILVERFED” is the XRI indicating the targetcloud federation, “!A” is a sequence of symbols usedto avoid name conflicts among independent cloud namespaces, and “(!@CLOUDA)” is the cross-reference tothe XRI root of the cloud A name space. Cloud B

saturates its resources and decides to join @SILVERFEDcloud federation. Thus, Cloud B contacts the CloudFederation Cross-Resolver corresponding to @SILVERFEDestablishing a federation. Once the federation is established@SILVERFED Cloud Federation Cross-Resolver returnsits root to cloud B, corresponding to @SILVERFED!B,where “!B” is a sequence of symbols used to avoidname conflicts with other member of the federation.Therefore, Cloud B Name Space Manager mounts, bymeans of XRI cross-reference mechanisms, the XRI@CLOUDB root under the XRI @SILVERFED!Bobtaining @SILVERFED!B/(!@CLOUDB). Thus, thetwo cloud name spaces become part of a uniquefederated name space. Later on, cloud B needs avirtual machine and forwards a resource request tocloud A. After an acknowledgment, cloud A instantiatesthe virtual machine inside its infrastructure, mountingit under the XRI path xri://@CLOUDA*lab2*Host1,where CNEs “lab2” and “Host1” indicate respectivelya laboratory and a Host running an hypervisor.Cloud A associates the virtual machine with thelocal i-name *VM3, the LocalID H2 VM3, andthe CanonicalID xri://(@CLOUDA*lab2*host1)!1234.Cloud A sends the path of the virual machinexri://@SILVERFED!A/(@CLOUDA*lab2*host1) tocloud B that creates for the resource an i-name entry*(xri://@SILVERFED!A/(@CLOUDA*lab2*host1))into the XRI parent authority *PlatformB, associatingalso the LocalID *PB VM2 and the CanonicalID:xri://(@CLOUDB*PlatformB)!5678. Thus the virtualmachine can be referred, inside the cloud B, asxri://CLOUDB*PlatformB*(xri://@SILVERFED!A/(@CLOUDA*lab2*host1)) or as xri://CLOUDB*PlatformB*PB VM2 using the localID alias for simplicity. Whereas,inside cloud federation, the virtual machine can bereferred as xri://@SILVERFED!B/(CLOUDB*PlatformB-*PB VM2). With such technique, cloud B may treatthe virtual machine as part of its infrastructure, also ifindeed, the resource is physically placed inside cloud A.In addition the virtual machine XRI can be resolved bymeans of a XRDS document, in different ways insideCCNTXs. Examples of CCNTXs which may be pickedout are: cloud A, cloud B, SILVERFED cloud federation,@CLOUDB*PlatformB, and many others. Inside eachCCNTX the virtual machine may be represented bydifferent metadata.

VII. CONCLUSIONS AND FUTURE WORKS

In this paper we tackled naming and resource locationproblems in cloud computing, more specifically focusing oncloud name space integration in federated environments. Areference Cloud Naming System Framework (CNSF) hasbeen defined and some practical examples have been pre-sented using XRI and XRDS technologies. More specifically,

name space issues in resource provisioning have been treatedproviding configuration examples. In future works we aregoing to use the reference framework to address cloudsecurity and policy problems of CNEs accessing to severalCCNTXs.

ACKNOWLEDGEMENTS

The research leading to the results presented in this paperhas received funding from the European Union’s seventhframework programme (FP7 2007-2013) Project RESER-VOIR under grant agreeement number 215605.

REFERENCES

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

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

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

[4] D. Yang, Y. Qin, H. Zhang, H. Zhou, and B. Wang, “Urns:A new name service for uniform network resource location,”in IET, pp. 1–4, 2006.

[5] Y. Doi, S. Wakayama, M. Ishiyama, S. Ozaki, T. Ishihara,and Y. Uo, “Ecosystem of naming systems: discussions on aframework to induce smart space naming systems develop-ment,” in ARES, p. 7, April 2006.

[6] Y. Doi, “Dns meets dht: treating massive id resolution usingdns over dht,” in Applications and the Internet InternationalSymposium, pp. 9–15, January 2005.

[7] G.-J. Ahn, M. Ko, and M. Shehab, “Privacy-enhanced user-centric identity management,” in ICC, pp. 14–18, June 2009.

[8] Resources and Services Virtualisation without Barriers(Reservoir) European Project, http://www.reservoir-fp7.eu/.

[9] Elastic Utility Computing Architecture LinkingYour Programs To Useful Systems, Eucalyptus,http://open.eucalyptus.com/.

[10] S. D. Stefano, D. Cunsolo, A. Puliafito, and M. Scarpa,“Volunteer computing and desktop cloud: The cloud@homeparadigm,” in NCA, pp. 134–139, June 2009.

[11] OpenQRM, “the next generation, open-source Data-centermanagement platform”, http://www.openqrm.com/.

[12] B. Sotomayor, R. Montero, I. Llorente, and I. Foster, “Virtualinfrastructure management in private and hybrid clouds,”Internet Computing, IEEE, vol. 13, pp. 14–22, September2009.

[13] Yadis 1.0, The Identity and Accountability Foundation forWeb 2.0, http://yadis.org/wiki/Main Page.

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