EP2678981A1 - Associating computing resources and communication resources with a service in a resource management architecture - Google Patents
Associating computing resources and communication resources with a service in a resource management architectureInfo
- Publication number
- EP2678981A1 EP2678981A1 EP11706517.7A EP11706517A EP2678981A1 EP 2678981 A1 EP2678981 A1 EP 2678981A1 EP 11706517 A EP11706517 A EP 11706517A EP 2678981 A1 EP2678981 A1 EP 2678981A1
- Authority
- EP
- European Patent Office
- Prior art keywords
- resources
- service
- computing
- resource management
- user
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Withdrawn
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/78—Architectures of resource allocation
- H04L47/781—Centralised allocation of resources
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
- H04L41/5003—Managing SLA; Interaction between SLA and QoS
- H04L41/5009—Determining service level performance parameters or violations of service level contracts, e.g. violations of agreed response time or mean time between failures [MTBF]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/72—Admission control; Resource allocation using reservation actions during connection setup
- H04L47/724—Admission control; Resource allocation using reservation actions during connection setup at intermediate nodes, e.g. resource reservation protocol [RSVP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/80—Actions related to the user profile or the type of traffic
- H04L47/805—QOS or priority aware
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/40—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using virtualisation of network functions or resources, e.g. SDN or NFV entities
Definitions
- 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
- 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.
- 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.
- Service level agreements 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 may need to fulfill requirements and SLAs not reliably achievable through the Internet.
- 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.
- 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.
- 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.
- 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
- 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 .
- computing resources e.g. networked computing and proc ⁇ essing resources
- cloud resources e.g. cloud resources
- communication resources telecommunication net ⁇ work resources
- 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 . ;
- WAN wide area network
- a combined service means a combined cloud and network ser ⁇ vice, e.g. access to a data base with 50ms response time;
- a user cloud application is an application that is uploaded by a user to a cloud.
- 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.
- 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) .
- VNO virtual network operator
- 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.
- 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.
- SLAs service level agreements
- 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.
- 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.
- 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.
- 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.
- 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 .
- 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.
- the networked computing re ⁇ sources e.g. ITRs 41
- Figs. 2A, 2B and 2C show different configuration examples of managing the ITRs 41.
- a cloud service may be provided by a single cloud 44 of ITRs 41 managed by a single VITRM 4.
- 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.
- 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.
- 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.
- 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.
- the VRM 5 al ready marked currently available resources among networked elements (NEs) 51 with SLA characteristics, but not
- 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.
- the VRM 5 further comprises a database 53.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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 .
- QoS transmission quality
- 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;
- 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;
- 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.
- networked computing resources e.g. ITRs 41
- communication resources e.g. NEs 51
- a resource manage- ment entity e.g. the CVRM 3
- 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 .
- 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.
- 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 .
- 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.
- 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 .
- step S3 and/or step S4 and step S5 are repeated.
- 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.
- the desired service may be a cloud service.
- 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 .
- DN domain name
- 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.
- IT cloud
- 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 .
- 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.
- 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.
- apps.com and type a related URL via the web interface, such that the CVNC 2 gets notion about the desire of the user.
- 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.
- the user may utilize an interface like an aug ⁇ mented RSVP.
- 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.
- 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.
- 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".
- the CVNC 2 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.
- the CVNC 2 requests to set up a connectivity from the CVRM 3.
- CVNC 2 may also request to get access to dedicated virtual resources
- 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.
- the "general" SLAs may not be signalled in case the CVRM 3 maintains that list.
- 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.
- 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.
- 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.
- OSPF open shortest path first
- 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.
- 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 .
- 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.
- 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:
- 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.
- the CVRM 3 may issue the following DNS request towards the VITRM 4.
- the query may for instance look like this:
- 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.
- 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.
- VITRM 4 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
- 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.
- 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.
- the VRM 5 is expected to allocate the corresponding resources.
- 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
- the network SLAs like for instance bandwidth and delay can be already signalled via the mechanism of the existing RSVP technology.
- the VRM 5 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.
- the virtual resources at the VRM 5 and at the VITRM 4 have been allocated successfully.
- 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.
- 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.
- 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.
- the CVRM 3 also inserts the NAPVIT (network attachment point of the Virtual IT (cloud) resources) to the RSVP Resv message.
- NAPVIT network attachment point of the Virtual IT (cloud) resources
- 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.
- 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.
- 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.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer And Data Communications (AREA)
Abstract
Description
Claims
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/EP2011/052621 WO2012113446A1 (en) | 2011-02-22 | 2011-02-22 | Associating computing resources and communication resources with a service in a resource management architecture |
Publications (1)
Publication Number | Publication Date |
---|---|
EP2678981A1 true EP2678981A1 (en) | 2014-01-01 |
Family
ID=44625283
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP11706517.7A Withdrawn EP2678981A1 (en) | 2011-02-22 | 2011-02-22 | Associating computing resources and communication resources with a service in a resource management architecture |
Country Status (2)
Country | Link |
---|---|
EP (1) | EP2678981A1 (en) |
WO (1) | WO2012113446A1 (en) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10900666B2 (en) | 2013-06-28 | 2021-01-26 | Ecovat Ip B.V. | Wall part, heat buffer and energy exchange system |
Families Citing this family (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN104054308B (en) * | 2012-12-24 | 2017-02-08 | 华为技术有限公司 | Application layer resources selection method, device and system |
CN109218378B (en) * | 2018-01-10 | 2021-05-04 | 陕西科技大学 | Design method of small logistics management platform based on cloud platform |
CN114629805B (en) * | 2020-11-27 | 2023-07-21 | 中国移动通信有限公司研究院 | SLA policy processing method and device, server and service node |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7284054B2 (en) * | 2003-04-11 | 2007-10-16 | Sun Microsystems, Inc. | Systems, methods, and articles of manufacture for aligning service containers |
-
2011
- 2011-02-22 EP EP11706517.7A patent/EP2678981A1/en not_active Withdrawn
- 2011-02-22 WO PCT/EP2011/052621 patent/WO2012113446A1/en active Application Filing
Non-Patent Citations (1)
Title |
---|
See references of WO2012113446A1 * |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10900666B2 (en) | 2013-06-28 | 2021-01-26 | Ecovat Ip B.V. | Wall part, heat buffer and energy exchange system |
Also Published As
Publication number | Publication date |
---|---|
WO2012113446A1 (en) | 2012-08-30 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP7252356B2 (en) | MOBILE EDGE COMPUTING NODE SELECTION METHOD, APPARATUS AND SYSTEM AND COMPUTER PROGRAM | |
CN107689882B (en) | Method and device for service deployment in virtual network | |
JP6007217B2 (en) | Method and apparatus for network virtualization | |
Xin et al. | Embedding virtual topologies in networked clouds | |
JP2022522368A (en) | Mobile Edge Computing Node Selection Methods, Devices and Systems | |
JP2018198068A (en) | Profile-based sla guarantees under workload migration in distributed cloud | |
WO2017113201A1 (en) | Network service lifecycle management method and device | |
Kim et al. | VNF-EQ: dynamic placement of virtual network functions for energy efficiency and QoS guarantee in NFV | |
WO2017045471A1 (en) | Method and apparatus for acquiring service chain information in cloud computing system | |
CN112532675B (en) | Method, device and medium for establishing network edge computing system | |
US20150358251A1 (en) | Unified cloud resource controller | |
CN108462592A (en) | Resource allocation methods based on SLA and NFVO | |
JP6738965B2 (en) | Network service life cycle management permission method and device | |
Hegyi et al. | Application orchestration in mobile edge cloud: Placing of IoT applications to the edge | |
EP3455728A1 (en) | Orchestrator for a virtual network platform as a service (vnpaas) | |
JP2017517170A (en) | Method and communication unit for service implementation in an NFV system | |
EP3531749B1 (en) | Management method, management unit and system for network function | |
KR20180103975A (en) | Method and system for managing resource objects | |
Racheg et al. | Profit-driven resource provisioning in NFV-based environments | |
WO2016155023A1 (en) | Network management system, device and method | |
KR20180061299A (en) | Network function virtualization resource processing method and virtual network function manager | |
CN112994937A (en) | Deployment and migration system of virtual CDN in intelligent fusion identification network | |
EP2678981A1 (en) | Associating computing resources and communication resources with a service in a resource management architecture | |
KR102389334B1 (en) | Virtual machine provisioning system and method for cloud service | |
Doan et al. | Reusing sub-chains of network functions to support mec services |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PUAI | Public reference made under article 153(3) epc to a published international application that has entered the european phase |
Free format text: ORIGINAL CODE: 0009012 |
|
17P | Request for examination filed |
Effective date: 20130923 |
|
AK | Designated contracting states |
Kind code of ref document: A1 Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR |
|
DAX | Request for extension of the european patent (deleted) | ||
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN |
|
18D | Application deemed to be withdrawn |
Effective date: 20140418 |
|
REG | Reference to a national code |
Ref country code: DE Ref legal event code: R079 Free format text: PREVIOUS MAIN CLASS: H04L0012560000 Ipc: H04L0012913000 |
|
REG | Reference to a national code |
Ref country code: DE Ref legal event code: R079 Free format text: PREVIOUS MAIN CLASS: H04L0012560000 Ipc: H04L0012913000 Effective date: 20141112 |