Goal Translation and Data Model Refinement Synchronisation

The level of specification and the details about the data model vary according to the level of our architecture. The information and the data model vision of a user requesting a service are different from those explored by the infrastructure provider. A high level description is refined and formatted with information coming from management framework. For exemplifying the expression of user’s requests and the goal translation considering our data model, we selected a scenario were one is requesting a traditional IaaS, informing some elasticity configuration as well as the network requirements. At a very high level the goals expressed by the user could look something like the following:

• 10 VMs and connect them to my two enterprise sites, Madrid and London. VMs: 2 vCPU,

4GB RAM, 120GB HDD, Linux OS, Internet connection, located in Germany.

• I want to be able to scale up to 50 VMs (i.e. the minimum I want is 10, and I can go to a

• Connection between data centre and enterprise sites: maximum end to end delay of 100 ms. “I don’t want my connection to pass through Belgium”.

Using parts of our possible embodiment for the data model (see Section 3.2.1), this request would look something like presented in Figure 3.6 (shortened for the sake of brevity). This does not mean that this is the final expression of the data model, just a very illustrative example.

This model is in line with the high level description in Sections 3.1.1 - 3.2 with regards to how the data model should look like. Also, the presence of “access points” here can be understood by making the analogy with the ports in the single router abstraction we mentioned above. A VM in an external data centre (Germany) is linked to one of the ports in our facilities “single router” (the access link).

We can also clearly observe how the data model reflects the goals at this level of the architecture. However, in the refinement process, the management functions explained in Section 5 also need to be refined and re-expressed accordingly to the increased level of detail and the dynamic references being resolved as such requests get mapped into the actual infrastructure. At the end of the day, when a VM gets to an IaaS cloud provider, the provider itself needs to trace certain goals (e.g. minimize data centre energy consumption by keeping physical machine utilization up to 80 % and no less than 65 %, then switch equipment off. Of course, these goals imply different knowledge (e.g. specific placement algorithms, data centre topology information, etc.) and details that need to be mapped into the data model.

<?xml v e r s i o n=” 1 . 0 ” e n c o d i n g=”UTF−8”?>

<d e s c r i p t i o n x m l n s=” h t t p : / /www . v x d l f o r u m . o r g / v x d l ” x m l n s : x s i=” h t t p : / /www . w3 . o r g / 2 0 0 1 /

XMLSchema−i n s t a n c e ” x s i : s c h e m a L o c a t i o n=” h t t p : / /www . v x d l f o r u m . o r g / v x d l VXDL . x s d ”>

<v i r t u a l I n f r a s t r u c t u r e i d=” G o a l t r a n s l a t i o n . Example ” owner=” SAIL p r o j e c t ”>

<v A r r a y i d=” 1 0VMs” c a r d i n a l i t y =” 1 0 ”> <vNode i d=”VM”> <l o c a t i o n>germany . eu</l o c a t i o n> <cpu> <c o r e s> <s i m p l e>2</s i m p l e> </c o r e s> <f r e q u e n c y> <i n t e r v a l> <min>2.0</min> </i n t e r v a l> <u n i t>GHz</u n i t> </f r e q u e n c y> </cpu> <memory> <s i m p l e>4</s i m p l e> <u n i t>GB</u n i t> </memory> <s t o r a g e> <i n t e r v a l> <min>120</min> </i n t e r v a l> <u n i t>GB</u n i t> </s t o r a g e> </vNode> </vArray> <v A c c e s s P o i n t i d=” Madrid ”> <e x t e r n a l R e g i o n>I n t e r n e t</e x t e r n a l R e g i o n> <l o c a t i o n>m a d r i d . s p a i n . eu</l o c a t i o n> <i p s e c></i p s e c> </v A c c e s s P o i n t> <v L i n k i d=”VMs t o Madrid ”> <b a n d w i d t h> <f o r w a r d> <i n t e r v a l> <min>1</min> <max>10</max> </i n t e r v a l> <u n i t>Mbps</u n i t> </f o r w a r d> <r e v e r s e> <i n t e r v a l> <min>1</min> <max>10</max> </i n t e r v a l> <u n i t>Mbps</u n i t> </r e v e r s e> </b a n d w i d t h> <l a t e n c y> <i n t e r v a l> <max>100</max> </i n t e r v a l> <u n i t>ms</u n i t> <l a t e n c y> <s o u r c e>10VMs</s o u r c e> <d e s t i n a t i o n>Madrid</d e s t i n a t i o n> </v L i n k> </v i r t u a l I n f r a s t r u c t u r e> </d e s c r i p t i o n>

4 Control Interactions

In this section we consider control interactions across infrastructure services. The arrangement of control in the CloNe architecture is based on a number of principles, the need for delegation and the need for distributed coordination across administrative domains.

4.1 Principles of Infrastructure Control

Here we detail the requirements of the general model for development of the control plane.

• Limited information disclosure: each Infrastructure Service Provider will be unwilling to expose details of its service, physical topology or traffic matrices. Hence, the Infrastructure Service Provider should be able to undertake cross-domain resource provisioning without detailed knowledge of underlying administrative domains.

• Rapid resource provisioning: the user should be able to provision resources across multiple domains at time scales comparable to existing compute resource provisioning in single domain IaaS offerings.

• To scale with the number of Infrastructure Service Providers: it should be possible for the Infrastructure Service Provider to utilize services from many Infrastructure Service Providers without major impact on the performance of the service.

• To scale with the number of user requests: it is important to give guarantees or bounds for searching processes and sending of requests and messages.

• Autonomy of an Infrastructure Service Provider: the Infrastructure Service Provider should be able to accept or deny any request from an infrastructure service user. Local policies can be applied locally if so desired.

• Filtering: a domain may apply whatever filtering policy it chooses to limit external interac- tion with its own domain, including cross-domain control interaction (similarly to the existing BGP).

A key design goal is to make the control infrastructure independent of the heterogeneous underly- ing networking technologies by defining and specifying interfaces and communications middleware with the appropriate level of abstraction.