WO2012113446A1

WO2012113446A1 - Associating computing resources and communication resources with a service in a resource management architecture

Info

Publication number: WO2012113446A1
Application number: PCT/EP2011/052621
Authority: WO
Inventors: Klaus Hoffmann; Marco Hoffmann; Klaus SCHMIDT-SCHYKOWSKI
Original assignee: Nokia Siemens Networks Gmbh & Co. Kg
Priority date: 2011-02-22
Filing date: 2011-02-22
Publication date: 2012-08-30
Also published as: EP2678981A1

Abstract

For associating computing resources and communication resources with a service in a resource management architecture comprising networked computing resources and communication resources, and a resource management entity capable of managing computing resources and communication resources, the following steps are performed: (a) sending a service request from a user via a user equipment to the resource management entity, wherein the service request includes a desired service and associated operational and service level requirements; (b) selecting by the resource management entity based on the service request computing resources from the networked computing resources, wherein the computing resources are selected to provide the desired service compliant with its associated operational requirements; (c) selecting by the resource management entity communication resources from the communication resources, the selected communication resources capable of interconnecting the selected computing resources among each other and with the user equipment; (d) by the resource management entity, combining the selected computing and communication resources and checking whether both the operational and the service level requirements are fulfilled with the combined computing and communication resources; and (e) in case the operational and service level requirements in step d) are fulfilled, reserving the combined computing and communication resources by the resource management entity, wherein the resource management entity further conducts virtualization of these resources, and handing over control of the virtualized combined computing and communication resources from the resource management entity to the user.

Description

Associating Computing Resources and Communication Resources with a Service in a Resource Management Architecture

The present invention relates to associating computing re- sources and communication resources with a service in a re^¬ source management architecture.

"Cloud computing is a model for enabling convenient, on- demand network access to a shared pool of configurable com- puting resources (e.g., networks, servers, storage, applica^¬ tions, and services) that can be rapidly provisioned and re^¬ leased with minimal management effort or service provider in^¬ teraction." This definition of cloud computing, together with essential characteristics, service and deployment models, is provided by the National Institute of Standards and Technol^¬ ogy (NIST) accessible at

http://csrc.nist.gov/groups/SNS/cloud-computing. With this definition cloud computing shows similarity in the principles and concepts applied to those of network virtualization as described by R. Bless and C. Werle in "Network Virtualiza^¬ tion from a Signaling Perspective", Future-Net '09 Interna^¬ tional Workshop on the Network of the Future 2009 in conjunc^¬ tion with IEEE ICC 2009, Dresden, June 16th-18th, 2009. The cloud computing principles enable a user to use computing and/or data processing resources, applications and services of a provider potentially not even known by the user through remote access via a communication network.

Various types of applications can be supported and/or pro- vided by the use of mechanisms and technologies of cloud com^¬ puting. Such applications, however, are getting more and more complex, resource and time consuming. Typical applications are e.g. computing applications such as simulation, computa^¬ tion and control of complex systems and processes in science and engineering (weather, climate, flow models, telecommunication and power distribution networks, traffic control, ...) as well as concrete business applications such as booking systems, stock exchange and commodity trade programs, logis^¬ tics, etc, ... . Other complex and time consuming applications may arise in the areas of search engines, Internet trade, so- cial networks, interactive (team) gaming, and many others. Some of these applications may be time critical or even re^¬ quire real-time delivery of computing results.

Increasing application complexity and performance require- ments, however, may also result in increased and in some cases very special requirements to related computing re^¬ sources. As a consequence, applications may even be distrib^¬ uted over different clouds (or sub-clouds) exchanging data, coordination and control information via interconnection net- works. Hence, communication services have to be used to con^¬ nect related users among each other, clouds among each other, and users with the related clouds and/or computing resources.

Up to now, cloud computing has primarily been discussed in view of the public internet (the Internet) used as intercon^¬ nection network. The properties and capabilities of the

Internet are taken as given and not questioned nor discussed any further. Service level agreements (SLA) are thus basi^¬ cally related to the expectations to, and the capabilities and services expected from the computing and data processing resources, taking the network capabilities as given or even neglecting them. The use of cloud computing is thus restricted to applications satisfied with Internet communica^¬ tion service capabilities (i.e. best effort) and related SLAs are concentrating on requirements related to the computing and data processing environment.

Time critical and/or real-time applications, however, may need to fulfill requirements and SLAs not reliably achievable through the Internet. Thus, special networks, network sec- tions and network components with specific capabilities may have to be provided for such applications to complement the computing and data processing resources in view of the overall SLA targets. However, computing and data centers, includ^¬ ing computing clouds, and communication networks are usually provided and operated separately and independently of each other with no specific coordination or control of any interactions in between.

The present invention aims at overcoming the above problems and at providing a resource management architecture capable of fulfilling the computing and communication service level requirements of an application.

This is achieved by the method, apparatus and computer pro^¬ gram product as defined in the appended claims.

According to an embodiment of the invention, computing and processing resources and communication resources are se^¬ lected, and their use is coordinated in such a way that the requirements and objectives of the application and its SLAs are fulfilled.

In the following the present invention will be described by way of embodiments thereof taking into account the accompany^¬ ing drawings, in which:

Fig. 1 shows a schematic block diagram illustrating a resource management architecture according to an embodiment of the invention; Figs. 2A, 2B and 2C respectively show examples of possible configurations of networked cloud resources;

Fig. 3 shows a schematic block diagram illustrating internal building blocks of the resource management architecture ac^¬ cording to an embodiment of the invention; Fig. 4 shows a schematic block diagram illustrating a control unit, to be used e.g. for any type of resource management en^¬ tity in the resource management architecture; and Fig. 5 shows a flow chart illustrating a process of associat^¬ ing computing resources and communication resources according to an embodiment of the present invention.

Fig. 1 shows a resource management architecture according to an embodiment of the present invention for the set up of a virtual network consisting of networked computing and proc^¬ essing resources (in the following referred to as computing resources), e.g. cloud resources, and telecommunication net^¬ work resources (in the following referred to as communication resources) by using network virtualization .

In the following description,

- a (sub-) cloud is a set of networked elements providing com^¬ puting resources, e.g. servers, computers, storage elements, etc., that is connected via a LAN (local area network) and is operated and managed by one entity (e.g. a resource manager), wherein different configuration options are given as shown in Fig. 2 to be described later on;

- a cloud service is a service that is offered by the cloud, e.g. computation power, storage, etc.;

- a cloud application is an application that runs in the cloud, e.g. banking software, office applications, gaming, etc . ;

- a network service means WAN (wide area network) connec- tivity including SLAs;

- a combined service means a combined cloud and network ser^¬ vice, e.g. access to a data base with 50ms response time; and

- a user cloud application is an application that is uploaded by a user to a cloud. Referring to Fig. 1, a user 1 sends a service request to a combined virtual resource manager (CVRM) 3 e.g. by means of a user equipment. The CVRM 3 is a resource management entity capable of managing computing resources and communication re- sources. As shown in Fig. 3, the CVRM 3 comprises a computing engine 31 and a database 32. If the user 1 has a good know- how about service requirements, the service request is sent directly from the user 1 e.g. using the user equipment to the CVRM 3. Alternatively, the user may delegate sending of a service request to a virtual network operator (VNO) . A re^¬ sponsible entity is a combined virtual network controller (CVNC) 2 of the user or the virtual network operator. An interface to the CVRM 3 can be a proprietary interface offered by the CVRM 3, e.g. a web interface. The service request of the user 1 includes a desired service and associated opera^¬ tional and service level requirements. For example, the ser^¬ vice request may include a desired cloud service, e.g. compu^¬ tation power, storage, etc., and service level agreements (SLAs) that are required to use this cloud service and/or are required to upload, interact and control a user cloud appli^¬ cation the user 1 optionally wishes to run on the cloud. Ad^¬ ditionally, the request includes a contact point of the user 1 (e.g. user location) and optionally a contact point of a cloud. The SLAs can be split up in cloud relevant SLAs (op- erational requirements) related to e.g. memory size, comput^¬ ing performance, local response times etc., and in typical network related SLA parameters (service level requirements) . The network related SLA parameters can be divided into QoS related parameters (e.g. bandwidth, delay, jitter, loss) and availability and reliability parameters like e.g. service up^¬ time ('5 nines' of service availability, failure rates, pro^¬ tection and repair times, etc.. Characteristics visible at the application level like e.g. overall response times to user actions will always result from the combination of re- lated cloud and netwok related performances. The CVRM 3 stores the information given by the service re^¬ quest in the database 32 and asks a virtual information tech^¬ nology (IT) resource manager (VITRM) 4 of a cloud for a cloud service that is able to provide the requested cloud service with the required SLAs . The VITRM 4 comprises a computation engine 42 and a database 43 as shown in Fig. 3. According to the example shown in Fig. 1, the VITRM 4 manages IT resources (ITRs) 41 which may be distributed over multiple locations. Alternatively, according to a first option, the CVRM 3 has already a pool of always available cloud services inclusive SLA parameters propagated by VITRMs 4 of different clouds in its database 32 that fulfil the requested requirements. Ac^¬ cording to a second option the CVRM 3 asks based on a stored cloud list VITRMs 4 of different clouds for service fulfil^¬ ment. An interface between the CVRM 3 and the VITRMs 4 may be a market place web interface offered by the CVRM 3. In any case the CVRM 3 gets a list of possible cloud contact points for network connectivity towards network domain (transport) and for service connectivity offering the user 1 (or VNO) re^¬ spectively its CVNC 2 addresses for later access to the cloud service of one or more VITRMs 4 of clouds that, either alone or in combination, are capable to fulfill the requested re^¬ quirements .

In other words, the CVRM 3 selects based on the service re^¬ quest computing resources from the networked computing re^¬ sources (e.g. ITRs 41), which are selected to provide the de^¬ sired service compliant with its associated operational re- quirements.

Figs. 2A, 2B and 2C show different configuration examples of managing the ITRs 41. According to Fig. 2A, a cloud service may be provided by a single cloud 44 of ITRs 41 managed by a single VITRM 4. According to Fig. 2B, a cloud service may be provided by mul^¬ tiple sub-clouds 45 of ITRs 41 which are managed by a single VITRM 4. The sub-clouds 45 may be co-located or distributed over multiple locations. It is to be noted that co-located sub-clouds 45 may or may not use (external) communication re^¬ sources. This example of cloud service provision is also de^¬ picted in Fig. 1. According to Fig. 2C, a cloud service may be provided by mul^¬ tiple clouds 44 with multiple VITRMs 4. The clouds 44 may be co-located or distributed, and will always use (external) communication resources. According to a further option not illustrated in the drawings, a cloud service may be provided by multiple clouds 44 as shown in Fig. 2C comprising multiple sub-clouds 45 accord^¬ ing to Fig. 2B. Moreover, the CVRM 3 sends a list of user access and cloud contact points with connectivity requirements (network SLA parameters) to a virtual resource manager (VRM) 5. The VRM 5 calculates in its computation engine (CE) 52 shown in Fig. 3 a list of available network routes that fulfil these require- ments, and sends the list back to the CVRM 3 as illustrated by the dotted arrow in Fig. 3. Alternatively, the VRM 5 al^¬ ready marked currently available resources among networked elements (NEs) 51 with SLA characteristics, but not

seized/reserved them towards the CVRM 3. However, in both cases the CVRM 3 has a global view about the resources poten^¬ tially available in both the telecommunication network managed by the VRM 5 and the cloud managed by the VITRM 4. As shown in Fig. 3, the VRM 5 further comprises a database 53. It is to be noted that more than one VRM 5 may be contacted by the CVRM 3 for selecting communication resources, e.g. NEs 51 and/or interconnection links or channels. In other words, the CVRM 3 selects communication resources from the communication resources (e.g. NEs 51), wherein the communication resources are capable of interconnecting the computing resources selected as described above among each other and with the user 1 e.g. via the user equipment.

The CVRM 3 stores the informaton received from the VRM 5 via the dotted arrow connection shown in Fig. 3, in its database 32 and calculates with an optimization algorithm for different purposes e.g. the most cost efficient solution that ful^¬ fills the requirements of the service request for both the communication network and the cloud. The CVRM 3 may split the SLA parameters, e.g. application level response times, be- tween the communication network and the cloud for optimization purposes. It is to be noted that the CVRM 3 can get re^¬ sources (e.g. ITRs 41 and NEs 51) in a passive way like a market place or can order actively resources (e.g. ITRs 41 and NEs 51) from the VRMs 5 and VITRMs 4.

In other words, the CVRM 3 combines the selected computing and communication resources and checks whether both the op^¬ erational and the service level requirements are fulfilled with the combined computing and communication resources.

If a solution for fulfilling the operational and service level requirements has been found, the CVRM 3 triggers the VRM 5 and the VITRM 4 to reserve the calculated resources. The CVRM 3 further conducts virtualization of these re- sources. In the virtualization, resources such as the ITRs 41 and the NEs 51 which are provided in physical networks are identified and selected, the selected resources are isolated from other resources of the physical networks and reserved for exclusive use in a virtual network to be provided for the user 1 based on his service request. Moreover, unique identi^¬ fication, address and access information are attached to the isolated and reserved resources in order to enable exclusive accessibility in the virtual network.

After the reservation of the calculated resources (computing and communication resources) has been confirmed, the CVRM 3 hands over control of the virtualized combined computing and communication resources from the CVRM 3 to the user 1 by providing the related identification, address and access information to the user.

Alternatively, the CVRM 3 may hand over the calculated re^¬ sources to the CVNC 2 which can start to configure the al^¬ ready confirmed virtual resources. After configuration, the CVNC 2 signals to the user 1 that the resources are ready to start the requested service (e.g. upload) and waits for fur^¬ ther instructions from the user. In other words, the control of the virtualized combined computing and communication re^¬ sources is handed over from the CVRM 3 to the CVNC 2 which is to control the desired service for the user 1.

According to an embodiment of the invention, for carrying out the above operations, each of the user equipment, the CVNC 2, the CVRM 3, the VITRM(s) 4 and the VRM(s) 5 comprises at least one control unit 10 as illustrated in Fig. 4. The con- trol unit 10 comprises processing resources 11, memory re^¬ sources 12 and interfaces 13 which are interconnected by one or several links. The memory resources 12 may function as a working area for the processing resources 11, and may also function as a storage for storing a program which includes software code causing the processing resources 11 to carry out the above operations, respectively, as well as for any other purposes needing to store program code or data. The in^¬ terfaces 13 may carry out sending/receiving of service re^¬ quests and sending/receiving of responses to service request, for example, as well as any other communications required for the operation and maintenance of the control unit and the de^¬ vice (s) controled by it.

The embodiments of the present invention as described above enable a combined selection of computing and communication resources required by applications using distributed and es^¬ pecially so called cloud computing, while reflecting the spe^¬ cific conditions and requirements of service levels, e.g. in terms of performance, transmission quality (QoS) , availabil- ity and reliability of the services, to be fulfilled for a reasonable presentation of the application services to their users .

The embodiments of the invention as described above cover the following scenarios:

- a single user sends, e.g. via a user equipment, a batch job (code and data) as the above-described service request to a cloud;

- a single user uses an application provided by a cloud, i.e. sends application data - or a simple start command - only as the service request which may include a user authen^¬ tication;

- multiple users use an application provided by, or having been sent by a user to, a cloud, wherein their service re- quest may need some kind of user authentication/login;

- an application is distributed over several clouds (with single or multiple users) e.g. as batch job downloaded by a user or as an application provided by the clouds;

- an interactive application with single or multiple users, in single or multiple clouds.

The user equipment used by the user may also be distributed over several locations, i.e. it may comprise several termi^¬ nals . Fig. 5 shows a flow chart illustrating a process of associat^¬ ing computing resources and communication resources according to an embodiment of the present invention. The process illustrated in Fig. 5 is for associating comput^¬ ing resources and communication resources with a service in a resource management architecture as shown in Fig. 1, which comprises networked computing resources (e.g. ITRs 41) and communication resources (e.g. NEs 51), and a resource manage- ment entity (e.g. the CVRM 3) capable of managing computing resources and communication resources.

In step SI a service request is sent from a user (e.g. user 1 in Fig. 1) via a user equipment to the resource management entity, wherein the service request includes a desired ser^¬ vice and associated operational and service level require^¬ ments .

In step S2, the resource management entity selects based on the service request computing resources from the networked computing resources, wherein the computing resources are se^¬ lected to provide the desired service compliant with its as^¬ sociated operational requirements. In step S3, the resource management entity selects communica^¬ tion resources from the communication resources, the selected communication resources capable of interconnecting the selected computing resources among each other and with the user equipment .

In step S4, the resource management entity combines the se^¬ lected computing and communication resources and checks whether both the operational and the service level require^¬ ments are fulfilled with the combined computing and communi- cation resources. In case the operational and service level requirements in step S4 are fulfilled ("yes" in step S4), the process ad^¬ vances to step S5 in which the resource management entity re^¬ serves the combined computing and communication resources and further conducts virtualization of these resources, and hands over control of the virtualized combined computing and commu^¬ nication resources from the resource management entity to the user . In case the operational and/or service level requirements in step S4 are not fulfilled ("no" in step S4), step S3 and/or step S4 and step S5 are repeated. In case the service level requirements are not fulfilled after e.g. five to ten passes, the process may be cancelled and a failure or reject message may be sent back to the user.

The service request may be sent from the user via the user equipment and via a service control entity (e.g. the CVNC 2 shown in Fig. 1) acting on behalf of the user, and the con- trol of the virtualized combined computing and communication resources may be handed over from the resource management en^¬ tity to the service control entity which is to control the desired service for the user. The user equipment may comprise several terminals, which can be used simultaneously in the execution of the requested ser^¬ vice .

The service request may be pre-processed by the resource man- agement entity before selecting the computing resources and the communication resources. Such pre-processing may comprise an optional pre-distribution of the requested service into sub-services to be requested from different clouds and/or sub-clouds of the system. The computing resources may be selected from at least one set of networked elements of a plurality of sets of networked elements, and the communication resources selected may com^¬ prise communication resources to connect the selected comput- ing resources belonging to different sets.

The computing resources may comprise cloud resources and the desired service may be a cloud service. Optional embodiments of the invention

Referring again to Figs. 1, 2 and 3, the main problem is to provide a user with computing and communication resources capable to provide a requested service in compliance with re- lated performance and service level requirements. The re^¬ quested service may relate to an application running in a po^¬ tentially distributed computing environment, where different locations and entities of user equipment and computing envi^¬ ronment are interconnected via telecommunication networks and services. The scenario envisaged is typically that of cloud computing .

Normally the user currently addresses a service for instance via an http request, which especially contains the particular domain name (DN) (for instance "www.apps.com" for the cloud service in question) .

However, currently no guaranteed telecommunication transport service is provided with that simple http request and there- fore an efficient telecommunication resource reservation of both the virtual telecommunication network resources and the virtualized IT (cloud) resources (e.g. real time application in the IT domain (cloud) ) is required. The selection of a particular cloud service like for instance the above

"www.apps.com" from a conceptual point of view requires cer^¬ tain "general" SLAs . For instance the maximum response time to a keyboard touch a player performed in an online game com^¬ prises the network transmission time from the user to the cloud, the real processing time of the event by the reated gaming software in the cloud, and the time for re- transmission of the reaction created by the game to the player. Similar considerations apply to a virtualized soft^¬ ware running a trading program for stock exchange markets, which in addition poses highest expectations on the reliabil^¬ ity of the cloud service and the networks connecting the stock exchange locations with the cloud locations hosting the application .

It is a special advantage of the CVRM 3 to know details of both, the network resources and the IT resources (cloud ser- vices) , that enables it to optimize both the cost and the

SLAs simultaneously across both domains. This can especially be done by intelligent modelling and understanding of how to split the "general" service requirements into a set of de^¬ rived network SLAs and IT (cloud) SLAs. The user finally does not care how the transmission delay or the computational processing time in the cloud contributes to the overall de^¬ lay, as long as his "general" service level requirements are met. Additionally, the CVRM 3 can provide innovative proce^¬ dures for billing and charging of the services being used. Furthermore it may also be advantageous to perform measure^¬ ments of the amount of packets sent, the CPU cycles being leased, or any other additional or related metrics.

A precise specification of the computing and service level requirements of an application, such as e.g. processor performance in floating point operations per second (FLOPS) or the amount of workspace memory or long-term storage needed, or a response time to a certain type of user request enables systematic fragmentation and/or parallelization of applica- tion tasks to different locations/processors. That means each user cloud application is classified by the so called IT (cloud) SLA. As already known also the network is requested to support network SLAs related to e.g. band^¬ width requirements, transmission delay, packet loss and jit- ter in addition to a required network reliability and service availability .

Most of the existing protocols in the telecommunications en^¬ vironment are dedicated to use path information and destina- tion network addresses. Thus, as for example, a prootocol like RSVP (resource reservation protocol) currently does not know about URLs or domain names. However, for addressing of cloud applications, computer clouds and/or related services and interconnecting them among themselves and with users while respecting specific SLAs, such information could be ad^¬ vantageously used.

In the following a possible embodiment of the present inven^¬ tion will be described.

In general, a user may simply wish to be connected with a specific application, and as such may not really care about technical details and protocol specifics in order to be able to set up a guaranteed connectivity with a service provided by a cloud. For that it is efficient for the user that there is a web interface between the user and the CVNC 2, or the CVRM 3 respectively, which allows the user to indicate which particular service is desired to be utilized. For instance, a user may wish to be connected to a service named apps.com and type a related URL via the web interface, such that the CVNC 2 gets notion about the desire of the user. Furthermore, this web interface also needs to be able to indicate at which IP (internet protocol) address the user wants to receive the connection towards the cloud. This would probably be the network attachment address of the user over which the traffic is to be transported.

Further details of the request are then to be handled by the CVNC 2 by deriving the overall requirements and setting up the details in the signalling protocols and information ele^¬ ments as needed.

Alternatively, the user (or a user's application (e.g. an- other cloud service) ) may utilize an interface like an aug^¬ mented RSVP. For that a protocol like RSVP may be modified by additionally allowing a domain name in a new (sub-) object within the Session object (destination) and the

Sender_Template object (Source) of the RSVP Path message to- gether with already existing RSVP objects for maximum re- utilization of existing services of RSVP. If only the Session object carries a domain name, but the Sender_Template does not so, this indicates that a user wants to request a service in the virtual IT cloud. If additionally the Sender_Template carries a domain name, this indicates that two applications residing in different IP cloud locations want to communicate with each other.

Layout of the domain name (to be allowed and carried addi- tionally) in the RSVP (Session object and the Sender_Template object) is as shown below:

31 24 23 16 15 8 7 0

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.+

Obj length (a)

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.+

Domain name coded as UTF-8

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.+ wherein (a) indicates an Overall object length in bytes not including header word, and remaining bytes to fill a word are padded. UTF8 coding is defined in h11p : / /too1 s , ietf . org/htm1 ,/rfc3629. So for instance the new object carries www.apps.com in binary format .

Regardless which interface may be utilized between the user(s) and the CVNC 2, in the end the CVNC 2 receives a re^¬ quest to provide a connection between a user and a particular cloud service ("www.apps.com") knowing the traffic transport interface and the cloud service to be connected to. As already explained each application for which the applica^¬ tion "www.apps.com" is just one example implicitly expects that some "general" SLAs needs to be adhered to. Note, that in the following the term SLAs stands for the combination of computing or communication service level agreements or any subset thereof. The CVNC 2 which is offering the services to its customers naturally is expected to know the particular needs of all the applications its wants to provide. As such the CVNC 2 maintains a list of applications and corresponding "general" SLAs. Consequently, the CVNC 2 can derive from the name of the application the corresponding "general" SLAs and can send a subset or all of the related information via sig^¬ nalling to the VITRM 4.

Alternatively the CVNC 2 may wish to delegate the determina- tion of the "general" SLAs to the VITRM 4. In that case the VITRM 4 maintains the list of applications and corresponding "general SLAs".

Consequently there is no need to explicit signal the "gen- eral" SLAs from the CVNC 2 to the CVRM 3, since that "gen- eral" SLAs can be implicitly derived from the name of the ap^¬ plication .

As the CVNC 2 receives the request (may it via Web Interface or modified RSVP) to set up the connectivity between the user and the cloud service, the CVNC 2 in turn requests to set up a connectivity from the CVRM 3.

In this context it is referred to the above description about the augmented RSVP interface, since from a signalling and functional point of view there is no difference here for this option .

However, in addition to the above description the CVNC 2 may also request to get access to dedicated virtual resources

(nodes) from the CVRM 3 which it can configure after the suc^¬ cessful resource reservation.

Furthermore, this signalling information may carry the ex- plicit "general" SLAs additionally in case the CVNC 2 main^¬ tains the list of applications and the corresponding "gen^¬ eral" SLA requirements. However, alternatively the "general" SLAs may not be signalled in case the CVRM 3 maintains that list. In that case the CVRM 3 is in the position to derive the "general" SLA implicitly from the name of the cloud ser^¬ vice and can conveniently and internally split from that knowledge the optimal distribution of margins between the network SLA part and the IT (cloud) SLA part. In any case the CVRM 3 is in the position to optimize between the general re- quirements and the costs of the offerings of the VRM 5 and VITRM 4.

The CVRM 3 may have received the above request either with the explicit "general SLAs" or without. In case there is no "general" SLAs the CVRM 3 needs to derive the "general" SLAs internally from the name of the cloud service. However, the CVRM 3 needs to calculate the cloud resources with the optimal location with regard to the location of the user, therefore as a prerequisite the VIRTM 4 may have adver- tised the addresses of the possible network attaching point of the IT (cloud) resources for certain services with their related costs via e.g. a web interface to the CVRM 3 (other types of interfaces are possible as well) . Those resources are marked for being available as guaranteed IT (cloud) re- sources for a later reservation by the CVRM 3. Similarly, the VRM 5 may have advertised the virtualized network resources possibly via OSPF (open shortest path first) to the CVRM 3 as well allowing the CVRM 3, based on the availability of the information from both domains, to calculate the best location of the IT (cloud) resources related to the corresponding ori^¬ gin, may it be a user or another cloud.

After the calculation/selection of the

best/efficient/optimal/cheapest combination of the network resources and the IT resources now they need to be allocated. The CVRM 3 already has known the possible network attaching point of the cloud service in question and selected the final attachment point and now requests the dedicated allocation of the cloud service for the selected attachment point from the VITRM 4. The VIRTM 4 receives the request for that final at^¬ tachment points and returns the address of the virtualized cloud back to the CVRM 3. In this example the CVRM 3 at first turns to the VITRM 4 to allocate the virtual resources in the cloud and afterwards turns to the VRM 5 in the following way.

The CVRM 3 extracts the content of the Session object (desti^¬ nation address) and the Sender_Template object (Source ad^¬ dress) from the RSVP . In case both the Session object (desti^¬ nation address) and the Sender_Template object (Source ad- dress) carries a domain name (DN) , two consecutive DNS may be performed or one single DNS request carrying both DNs are sent towards the VITRM 4. Assuming that a user wants to con^¬ nect to the www.apps.com, the CVRM 3 may have selected IP1 (e.g. 26.0.0.73) as being best to be connected to the net^¬ work, while simultaneously expressing the need for the IT- SLAs as given below, a modified DNS (domain name server) query may look like:

Header | OPCODE=SQUERY

+

Question | QNAME=www . apps . com, QCLASS=IN, QTYPE=A, NWA=IP1

+

Answer | <empty>

+

Authority | <empty>

+

Additional | <empty>

+

IT-SLA I CPU cycle=10000/s, Memory=lGyte, parallel=no where

a) www.apps.com denotes the cloud service being requested, b) NWA (NetWork Attachment) carries the selected IP address for the cloud service, and

c) CPU cycle denotes the number of CPU cycles per second, the needed memory expressed in Gbytes and the non possibility of parallel execution. Further attributes may be added.

However, in case the CVRM 3 wants to handover the responsi^¬ bility (because the CVNC 2 may have wanted to have access to the virtualized resources) of the virtual resources, then the CVRM 3 may issue the following DNS request towards the VITRM 4.

The query may for instance look like this:

Header | OPCODE=SQUERY I

+ +

Question | QNAME=www . apps . com, QCLASS=Virtual , QTYPE=A, NWA=IP1 | Answer | <empty> I + +

Authority | <empty> I

+ + Additional | <empty> I

+ +

IT-SLA I CPU cycle=10000/s, Memory=lGyte, parallel=yes | where

For instance, with the signalling of the Qclass=Virtual the CVRM 3 requests that the CVNC2 and/or the CVRM 3 is inter- ested in the access to the virtualized resources and expects to receive the address of them in the DNS response.

It is up to the VITRM 4 to record and check the utilization of the IT (cloud) resources and therefore to return the ad^¬ dresses of the virtual IT (cloud) resources in the modified DNS response to the CVRM 3.

The VITRM 4 may return the resolved "hard coded" IP addresses of

a) the interconnection point between the network domain and the IT domain (cloud) , and

b) the addresses of the virtual resources for later usage by the CVNC 2 (e.g. operation) for the DN(s) / applications in question according to the layout shown below.

+ +

Header | OPCODE=SQUERY, RESPONSE, AA I

+ +

Question | QNAME= www.apps.com, QCLASS= Virtual, QTYPE=A |

+ + Answer | www.apps.com 86400 IN A 26.0.0.73 I

I 86400 IN A 10.0.0.51 I + +

Authority | <empty> I +

Additional | <empty>

+ In this embodiment the CVRM 3 interprets the two IP addresses returned in the DNS response as explained in the following.

The first occurrence carries the address of the interconnec^¬ tion point towards the network domain. This should be the repetition of the IP1 of the DNS query.

The second occurrence carries the address of the virtual IT resources for later usage by the CVNC 2. Consequently, the CVRM 3 stores this address for the insertion back to the CVNC 2.

As a next the step, the CVRM 3 requests an allocation of net^¬ work resources from the VRM 5. The CVRM 3 can replace the corresponding DNs as possibly sent by the CVNC 2 with the se^¬ lected "hard coded" IP address (e.g. IP1: 26.0.0.73) of the RSVP path and sends the RSVP message to the VRM 5. The vir^¬ tual address of the virtual IT (cloud) resources is stored for later population of the RSVP Resv response, so that the CVNC 2 can have access to the virtual IP resources. The RSVP Path request sent by the CVRM contains resolved IP addresses for edges.

The edges may be for instance either the user(s) attachment point and the IT (cloud) resources network attachment point as selected and allocated by the CVRM 3 or possibly two se^¬ lected IT (cloud) resources network attachment points in case two clouds are to be connected. Thus, the VRM 5 is expected to allocate the corresponding resources. Furthermore is to be noted that with the above RSVP Path re^¬ quest, certain QoS requirements are signalled based on the decision of the CVRM 3 how to distribute/proportion the "gen- eral" SLAs across the network domain and the IT domain

(cloud) respectively the corresponding network SLAs and the IT (cloud) SLAs. The network SLAs like for instance bandwidth and delay can be already signalled via the mechanism of the existing RSVP technology.

Upon receipt of the RSVP Path request, the VRM 5 allocates the network resources and responds with the related RSVP Resv message towards the CVRM 3. The RSVP Resv message contains the addresses of the virtual network resources being allo^¬ cated and to be handed over to the CVNC 2 via CVRM 3 for later usage.

After the receipt of the RSVP Resv message from the VRM 5 (and of course after the modified DNS response from the VITRM 4) the virtual resources at the VRM 5 and at the VITRM 4 have been allocated successfully. In both responses the addresses, allowing the access to the virtualized resources, are handed over to the CVRM 3 from the VRM 5 and the VITRM 4 respec- tively. Consequently, the CVRM 3 can respond to the CVNC 2 with a RSVP Resv message to the RSVP path message being sent by the CVNC 2 earlier.

Since the CVNC 2 possibly requested the access to the virtu- alized resources the Resv message is to be populated with two kinds of addresses. One kind of addresses is those addresses allowing the access to the virtual network nodes. The other kind of addresses is the addresses allowing the access to the virtualized IT resources as received in the DNS response. That means that the RSVP Resv message is further modified so that the address of the virtualized IT (cloud) resources can be additionally carried along. For that a new information element is specified to carry the AVIT (Address of Virtual IT (cloud) resources) . The syntax is the same as for the ad- dresses of the network nodes, but it is a distinct new ob^¬ ject/parameter. Additionally the CVRM 3 also inserts the NAPVIT (network attachment point of the Virtual IT (cloud) resources) to the RSVP Resv message. This NAPVIT has been se^¬ lected out of the potential access points the VITRM 4 offered and is now to be reported back to the CVNC 2 and the user(s) . Therefore another new information element is defined for the RSVP Resv message. The semantics are the same as for the AVIT, however it is a new object / information element as it carries distinct information. Consequently the CVRM 3 sends the so modified RSVP Resv message towards the CVNC 2 so that the CVNC 2 can access its virtual resources.

The CVNC 2 receives the above mentioned and modified RSVP Resv message from the CVRM 3. In case of using the augmented RSVP, the CVNC 2 can forward the received RSVP Resv message towards the user respectively its user equipment, however the CVNC 2 surely removes the ad^¬ dresses of the virtual IT resources, as the operation of the IT (cloud) resources are in the business of the CVNC 2 only and not to be revealed to the user in view of security as^¬ pects. With the return of Resv message the resources can be used by the requesting user, may it be a user or an IT domain (cloud) requiring connectivity to an IT domain (cloud) , and connectivity between the above-described edges is allowed. Consequently now the application (on behalf of the user) can issue the http request as usual, however now being granted with the QoS as requested and provided by the RSVP cycle that was performed before. The NAPVIT is not removed from the RSVP message, as it is for the user to be able to access the vir- tual cloud.

In case of using a web interface, the CVNC 2 responds via the web interface towards the user in order to report back the successful creation of the IT service and its guaranteed ac- cess via the network. Simultaneously the user also gets the NAPVIT so that the user can access remotely. It may be noted that the above-described procedure in general may be applicable to the conventional non virtualized case as well. To distinguish the both scenarios QCLASS=Virtual is introduced.

It is to be understood that the above description is illus^¬ trative of the invention and is not to be construed as limit^¬ ing the invention. Various modifications and applications may occur to those skilled in the art without departing from the true spirit and scope of the invention as defined by the ap^¬ pended claims.

Claims

CLAIMS :

1. A method for associating computing resources and communication resources with a service in a resource management ar- chitecture comprising networked computing resources and com^¬ munication resources, and a resource management entity capa^¬ ble of managing computing resources and communication resources, the method comprising:

(a) sending a service request from a user via a user equipment to the resource management entity, wherein the ser^¬ vice request includes a desired service and associated opera^¬ tional and service level requirements;

(b) selecting by the resource management entity based on the service request computing resources from the networked computing resources, wherein the computing resources are se^¬ lected to provide the desired service compliant with its as^¬ sociated operational requirements;

(c) selecting by the resource management entity communi^¬ cation resources from the communication resources, the se- lected communication resources capable of interconnecting the selected computing resources among each other and with the user equipment;

(d) by the resource management entity, combining the se^¬ lected computing and communication resources and checking whether both the operational and the service level require^¬ ments are fulfilled with the combined computing and communi^¬ cation resources; and

(e) in case the operational and service level require^¬ ments in step d) are fulfilled, reserving the combined com- puting and communication resources by the resource management entity, wherein the resource management entity further con^¬ ducts virtualization of these resources, and handing over control of the virtualized combined computing and communica^¬ tion resources from the resource management entity to the user.

2. The method of claim 1, further comprising:

(f) in case the operational and/or service level re^¬ quirements in step d) are not fulfilled, repeating steps (b) and/or (c) and steps (d) and (e) .

3. The method of claim 1 or 2, wherein in step a) the service request is sent from the user via the user equipment and via a service control entity acting on behalf of the user, and/or in step e) the control of the virtualized combined computing and communication resources is handed over from the resource management entity to the service control entity which is to control the desired service for the user.

4. The method of any one of claims 1 to 3, wherein the user equipment comprises several terminals.

5. The method of any one of claims 1 to 4, further compris^¬ ing :

pre-processing the service request by the resource man- agement entity before selecting the computing resources and the communication resources.

6. The method of any one of claims 1 to 5, wherein the com^¬ puting resources are selected from at least one set of net- worked elements of a plurality of sets of networked elements, and the communication resources selected comprise communica^¬ tion resources to connect the selected computing resources belonging to different sets.

7. The method of any one of claims 1 to 6, wherein the com^¬ puting resources comprise cloud resources and/or the desired service is a cloud service.

8. A control unit equipped with processing resources, memory resources and interfaces, the control unit comprising means to (a) receive a service request from a user via a user equipment, wherein the service request includes a desired service and associated operational and service level require^¬ ments;

(b) select, based on the service request, computing re^¬ sources from networked computing resources to provide the de^¬ sired service compliant with its associated operational re^¬ quirements, wherein the networked computing resources are provided by a resource management architecture comprising the networked computing resources and communication resources;

(c) select communication resources from the communica^¬ tion resources, the selected communication resources capable of interconnecting the selected computing resources among each other and with the user equipment;

(d) combine the selected computing and communication re^¬ sources and check whether both the operational and the ser^¬ vice level requirements are fulfilled with the combined com^¬ puting and communication resources; and

(e) in case the operational and service level require- ments in step d) are fulfilled, reserve the combined comput^¬ ing and communication resources, wherein the control entity further comprises means to conduct virtualization of these resources, and hand over control of the virtualized combined computing and communication resources to the user.

9. The control unit of claim 8, further comprising means to (f) in case the operational and/or service level requirements in step d) are not fulfilled, repeat steps (b) and/or (c) and steps (d) and (e) .

10. The control unit of claim 8 or 9, implemented with dis^¬ tributed computing devices.

11. A computer readable medium storing a program for a proc- essing device, comprising software code portions for perform- ing the steps of any one of claims 1 to 7 when the program is run on the processing device.