SLAFM

A Service Level Agreement Formal Model for Cloud Computing

Lucia De Marco

1,2

, Filomena Ferrucci

and M-Tahar Kechadi

School of Computer Science and Informatics, University College Dublin, Belﬁeld, Dublin 4, Ireland

Department of Management and Information Technology DISTRA-MIT, University of Salerno,

Via Giovanni Paolo II, 132 - 84084 - Fisciano (SA), Italy

Keywords:

Service Level Agreement, SLA Management, Cloud Services Logs, SLA Formal Model.

Abstract:

Cloud Computing services are regulated by a contract called Service Level Agreement (SLA). It is co-signed

between the customers and the providers after a negotiation phase, and during their validity time several

constraints have to be respected by the involved parties. Due to their popularity, cloud services are enormously

used and unfortunately also abused, specially by cyber-criminals. Sometimes the crimes have the consequence

of violating some contractual constraints without the parties are aware of. A manner for guaranteeing more

control of the SLA respect is to consider a dedicated system interacting with the cloud services and detecting

the SLA violations by analysing the log ﬁles. We introduce a formal model aimed to represent the contents of

such SLAs necessary in the context of an automatic mechanism for detecting SLA violations.

1 INTRODUCTION

Cloud services are regulated by Service Level Agree-

ment contracts (SLA) (Mell et. al, 2011), where all

the constraints among a cloud service provider and its

customer(s) are detailed; the contracts are co-signed

by the parties and they have legal validity in case of a

court litigation (Baset, 2012; ?). Because of their im-

portance and contents(CSA, 2013), SLAs have been

being considered to be monitored to detect their vio-

lations. Many attempts to automate such monitoring

there exist in literature, but to the best of our knowl-

edge most of them do not consider cloud services

logs; nevertheless the literature focuses on the mon-

itoring of performances constraints.

In this paper a set of rules is presented in the shape

of a formal model named SLAFM; we aim to formal-

ize the necessary information needed by the SLA vi-

olation detection capability, including input, output,

and intermediary computations. In addition, some di-

agrams will be presented in order to visualize the in-

teractions among the components dedicated to imple-

ment our SLA violation detection capability based on

our formal model.

The remainder of the paper is structured as fol-

lows: in Section 2 we synthesize the background lit-

erature about both formal modelling and automatic

monitoring of SLAs; Section 3 provides an overview

about contents and structure of cloud SLAs. In Sec-

tion 4 we discuss the principal objectives of our pro-

posal, while an example of the proposal is illustrated

in Section 5. The details of the formal model are ex-

plained in Section 6, and a case study based on the

previous example is provided in Section 7. Some pro

and con are presented in Section 8, and conclusion

and future work ideas close the paper in Section 9.

2 BACKGROUND

Automating the management of a textual document

is a big challenge. Our focus is to target such topic

to the SLAs stipulated for cloud services. The ﬁnal

aim is to detect contractual violations. The informa-

tion involved in this process are the ones concerning

cloud services logs. Our approach provides a formal

model that represents both SLAs and cloud logs. The

analysed literature covers different arguments, such

as formal representation of SLAs and automatic SLA

monitoring research projects using SLA formal repre-

sentations, which provide the background of our pro-

posal. Most work provide a customized manner to

structure the SLAs contents, which are then formal-

ized via mathematical tuple, e.g. in (Czajkowski et.

al, 2002; Unger et. al, 2008; Ghosh et. al, 2012;

Ishakian et. al, 2011; De Marco et. al, 2014); in other

521

De Marco L., Ferrucci F. and Kechadi M..

SLAFM - A Service Level Agreement Formal Model for Cloud Computing.

DOI: 10.5220/0005451805210528

In Proceedings of the 5th International Conference on Cloud Computing and Services Science (CLOSER-2015), pages 521-528

ISBN: 978-989-758-104-5

 2015 SCITEPRESS (Science and Technology Publications, Lda.)

works the authors use concepts from set theory, e.g.

in (Skene et. al, 2007) and (De Marco et. al, 2014);

the other used formalism include derivation rules, re-

action rules, integrity rules and deontic rules (Paschke

et. al, 2008), or mathematical logic concepts (Unger

et. al, 2008).

Other work are dedicated to manage the SLAs in

terms of monitoring the respect of some constraints

and to prevent their violation; for instance, a frame-

work called DESVI(Emeakaroha et. al, 2010) is dedi-

cated to monitor low level Cloud resources in order

to detect if their measured value respects the con-

straints extracted from SLAs with the goal of detect-

ing QoS violations. This work has been recovered

in(Emeakaroha et. al 2012b) to demonstrate its efﬁ-

ciency in monitoring a single Cloud data centre, and

also in (Brandic et. al, 2010), where some speciﬁc

metrics are applied on the resources, whose values are

required to match with a speciﬁed threshold to prevent

possible contractual violations. In(Morshedlou et. al,

2014) a proactive resources allocation prototype is

proposed for reducing the negative impact of SLAs’

violations and for improving the level of users’ satis-

faction. In (Maurer et. al, 2012) a prototype for an

autonomic SLA enhancement is discussed; it behaves

as resource parameters reconﬁguration tool at virtual

machines level of cloud infrastructures, with the main

advantage of reducing SLA violations and of optimiz-

ing resources utilization. Instead, in (Emeakaroha et.

al, 2012a) the proposed SLA monitoring and viola-

tion detection architecture plays at the Cloud appli-

cation provisioning level, where some metrics are ex-

ploited to monitor at runtime the resource consump-

tion behaviour and performance of the application it-

self. In (Cedillo et. al, 2014) an approach to moni-

tor some Cloud services non-functional SLA require-

ments is presented; a middle-ware interacting with

services and applications at runtime is designed; it

analyses the information and provides some reports

as soon as an SLA violation is identiﬁed. Last but

not least, SALMonADA (Muller et. al, 2014) is a

platform that utilizes a structured language to repre-

sent the SLA, which is then automatically monitored

to detect whether any violation occurs or not; such

detection is performed by implementing a technique

based on a constraint satisfaction problem.

3 SLA CONTENTS AND

STRUCTURE

In a free trade context people have the freedom to

choose for a speciﬁc need which services they prefer

from a big offer pool. Once such choice is accom-

SLA Dismission

Potential

Client

Request

SLA Template SLA Negotiation

Potential

Client

Changes

SLA Co-Signed

Changes

Approved

By Both

Parties

SLA Execution

Service

Activation

Revision

Change

Request

Change

Request

Approved

Change

Request

Discarded

Time Expired

Change Requests

Figure 1: SLA Life Cycle.

plished, a user contacts a speciﬁc service provider.

This latter is responsible of delivering the service to

the user after the instantiation of a particular Service

Level Agreement (SLA) contract. An SLA concern-

ing the provisioning of IT services is deﬁed as a for-

mal, negotiated, document in qualitative and quan-

titative terms detailing the services offered to a cus-

tomer (ITIL). To the best of our understanding among

cloud services, an SLA follows the life cycle depicted

in the UML (Rumbaugh et. al, 2004) state chart di-

gram in Figure 1.

After a potential customer request, a contractual

template is customized by the cloud service provider

depending on some change requests to the stan-

dard offer; subsequently a negotiation phase happens,

where solutions to the change requests are included,

together with information about expenses, penalties,

and reports. The SLA co-signed state determines that

both entities agree on the actual contractual contents,

then the service provisioning can begin. The SLA has

a validity time, that can be either explicitly expressed

with start and end dates, or an initial date together

with a time interval can be included in the document.

Such validity time begins after the contract is hardly

or digitally co-signed by both parties in the SLA Ex-

ecution state. During its life cycle, an SLA can be

subject to a revision to resolve some change requests

instantiated by either party. The revision phase can

provide solutions to such requests in order to continue

the service provisioning and the contract validity. In

case a solution is not met by the parties the service

provisioning and the SLA validity are dismissed.

In an SLA regulating cloud services the duties

and responsibilities of both parties are described, to-

gether with the possible presence and operations of

a third party. The main contents of an SLA con-

cern deﬁnitions and descriptions of the service, some

rules and regulations about its delivering, some per-

formance measures together with possible tolerance

intervals about the levels of the services to guarantee,

CLOSER2015-5thInternationalConferenceonCloudComputingandServicesScience

522

CLOUD SERVICE PROVIDER

SLA EXTRACTION

INFORMATION

SLAs

RULES

SaaS PaaS IaaS

SaaS Logs PaaS Logs IaaS Logs

CLOUD LOGS CONVERTER

COMPARISON

PERFORMER

FORMATTED

LOGS

SLAs

VIOLATION

DETECTION?

ACTIONS

Figure 2: SLA Violation Detection Capability.

and the pricing and penalties measures in case such

tolerances are not respected. For sake of monitoring

and user satisfaction purposes, it is good practice to

provide service levels that can be audited, managed,

and measured (Larson, 1998).

4 SLA VIOLATION DETECTION

An SLA violation detection capability is aimed to

automatically guarantee in a real time manner the

respect of the contract in relation to the Cloud be-

haviour. This capability has two different input. They

are the SLA constraints and some Cloud logs. The

capability intends to perform the comparison between

them. The main challenge for implementing such ca-

pability is to convert the natural language expressions

of the contract in rules that a machine can manipu-

late. About the management of the cloud logs, in-

stead, the effort is less, because once the structure of

the logs is known they can be manipulated. In most

cloud service providers such structure is documented.

In Figure 2 the interactions among the components

dedicated to implement our SLA violation detection

capability is designed. The beginning of such capa-

bility corresponds with the SLA to guarantee starting

time. The necessary contractual sections are extracted

and structured in a speciﬁc format. The information

gathered from the cloud services logs are translated,

aggregated and indexed according to another speciﬁc

format, compatible with the one the SLA sections are

converted to. The capability is responsible to perform

the comparison between the SLAs constraints and the

cloud service behaviour structured in logs. The com-

parison results are stored and utilized for subsequent

comparison; they also feed a decision making mod-

ule, responsible to manage the consequences of the

detected SLA violations.

5 EXAMPLE: AMAZON S3

In this section we want to provide a real-world com-

mercial well deﬁned SLA contract documents as ex-

ample for the implementation of the SLA violation

detection capability depicted in Figure 2.

In order to obtain the necessary logs, we need to

access to as many information as possible, among

the quantity granted by a cloud service provider. It

is well documented that the amount of information

accessible by cloud services customers is bigger in

IaaS level, medium in PaaS, and small in SaaS (Liu

et. al, 2011). Thus, we chose a IaaS type of cloud

service. Moreover, we considered Amazon as cloud

provider because it is considered by both business and

academia as a pioneer of a complete pool of cloud

services delivering. From all these considerations,

our choice fell on Amazon Simple Storage Service

(S3) (Amazon), which is an Infrastructure as a Ser-

vice (IaaS) provided by Amazon.com.

We accessed to both the S3 public SLA and the

logs, available at a customer level. Among all the

legal constraints, we consider the service level ex-

pressed as Monthly Uptime Percentage. The reader

has to consider this parameter as a quality attribute of

the Amazon S3 cloud service. Amazon Web Services

will use commercially reasonable efforts to make

Amazon S3 available with a Monthly Uptime Percent-

age [...] of at least 99.9% during any monthly billing

cycle.

Scanning the SLA, we can ﬁnd the deﬁnition of

such attribute as: Monthly Uptime Percentage is cal-

culated by subtracting from 100% the average of

the Error Rates from each ﬁve minute period in the

monthly billing cycle. Again, Amazon carefully de-

ﬁned the aforementionedError Rates as the total num-

ber of internal server errors returned by Amazon S3

as error status InternalError or ServiceUnavailable

divided by the total number of requests during that

ﬁve minute period(Amazon).

In order to guarantee the respect of the monthly

uptime percentage service level, an SLA violation

detection capability has to consider the information

about server responses to the HTTP requests made to

S3 every ﬁve minutes. Such data is available in the

Server Access Log ﬁles available in S3, which col-

lects some information every request made to the ser-

vice. An example of them is provided in Figure 3.

The information in red circles are the ones necessary

to calculate the Error Rates, i.e., the time and the Er-

ror Code.

In a speciﬁc ﬁve minute period time our capabil-

ity has to collect the log ﬁles for all the requests made,

i.e., from Time

to Time

+5min

. Then the Error Rate is

SLAFM-AServiceLevelAgreementFormalModelforCloudComputing

523

calculated counting the number of Error Code equals

to InternalError or ServiceUnavaiable, divided by the

total number of requests during that ﬁve minute pe-

riod.

Considering that every entry in the log has a re-

lated Error Code ﬁeld, we can afﬁrm that the total

number of requests during that ﬁve minute period is

obtained by the following formula:

5minRequests =

+5min

∑

ErrorCode

The Error Rate of a ﬁve minute time period is ob-

tained by the following formula:

5minErrorRate= (

+5min

∑

ErrorCode = InternalError

ORServiceUnavaiable)/5minRequests

In order to have a monthly value the capability has

to compute this value along a billing month time pe-

riod. Every solar day has 60/5 ∗ 24 = 288 ﬁve min-

utes time periods; this value has to be multiplied for

the number of days of a billing month. Assuming that

a billing month is composed of thirty days, we will

have 288 ∗ 30 = 8640 ﬁve minutes time periods. Fi-

nally, the monthly uptime percentage will be obtained

by the following formula:

AverageErrorRate = (

8640

∑

5minErrorRate)/8640

MUP = 100%− AverageErrorRate

6 FORMAL MODEL

The SLA Formal Model (SLAFM) is aimed to pro-

vide a theoretical approach for a contractual violation

detection capability for cloud computing services. A

previous draft of the same formalism was discussed

in (De Marco et. al, 2014), where only a speciﬁc sce-

nario has been taken into account. We extend that

formal model by adding the modelling of cloud ser-

vices logs; according to that, some changes to the

modelling of the SLA structure have been added. The

model utilizes mathematical formalisms as tuple, set

theory, functions (Ben-Ari, 1993).

6.1 Service Level Agreement

SLAs are contractual documents written in natural

language composed of a set of information structured

as service levels. An sla l is an element of the set of

slas L. An sla is described by a mathematical tuple

composed of a set of service levels SL, the validity

starting time t

start

and the validity ending time t

end

L = {l

,...,l

}, j ∈ N

l = hSL,t

start

end

i;t

end

> t

start

A service level sl is an element of the set of service

levels SL. Each sl has a validity time interval, deter-

mined by a starting and an ending time; during this

time, some indicators related to a service level at-

tribute for a speciﬁc service resource need to be ver-

iﬁed, hence an sl is described by the following tuple,

composed of the set of indicators I, the attribute a of

the resource r, and the starting and ﬁnishing times, t

and t

respectively.

SL = {sl

,sl

,... ,sl

}, j ∈ N

sl = hI,a

i;t

> t

An indicator i is an element of the set of the indi-

cators I. An indicator is described by a mathematical

tuple composed of a conditioned value c k u of the at-

tribute a

for the resource r

. A condition c belongs

to the set of conditions C; in case any condition is not

expressed in the contractual text, the value of c will

be set as =. A value k is related to the attribute a

the resource r

; u is the optional unit measure used to

express the value k, belonging to the set of unit mea-

sures U. The conditioned value c k u has to be veriﬁed

through the application of the metric m belonging to

the set of metrics M. The metrics can be either atomic

or composed, namely the value is obtained by com-

bining more atomic metrics.

I = {i

,... ,i

}, j ∈ N

i = hcku,mi

c ∈ C;C = {≤ ;≥;<;>;<>;=}

u ∈ U;U = {u

,... ,u

}, j ∈ N

m ∈ M;M = {m

,... ,m

}, j ∈ N

6.2 Cloud Service Log

A cloud computing architecture is composed of a set

of resources R, either physical or virtual.

P = {R

⊆ R}

V = {R

⊆ R}

R = {r

,... ,r

}, j ∈ N

CLOSER2015-5thInternationalConferenceonCloudComputingandServicesScience

524

Figure 3: Amazon S3 Sever Access Log.

A resource r is described by a set of attributes A,

e.g., ﬁlename, date of creation, size. Let a be an at-

tribute, it belongs to the set of attributes A.

A = {a

,... ,a

}, j ∈ N

r = {A

⊆ A}

| 6= 0∀r ∈ R

Theorem 1. The set of attributes A cannot be empty.

Proof. Every resource r ∈ R is described by a set of

attributes A

which is subset of A.

A =

[

∀r∈R

⇒ |A| =

[

bydef.

⇒ |A

| 6= 0∀r ∈ R

⇒ |A| 6= 0

During the execution of a Cloud service, the value

of an attribute of a resource is subject to changes via

an operation o. An operation o is an element of the

set of operations O. Each operation is described by a

mathematical tuple composed of a sender s that is the

executor of such operation, a result value(a

) that de-

scribes the value assigned to attribute a of resource r,

an operation resource r, an attribute a, and an oper-

ation time t

. The operation value is a mathematical

function that assigns a value to an attribute of a re-

source. The assigned value can be of numeric type;

moreover it can be associated to an optional unit mea-

sure u. A sender s is an entity (process) performing

operations in the Cloud, e.g., an IP address or a Drop-

box process. Let s be a sender, it belongs to the set of

senders S.

S = {s

,... ,s

}, j ∈ N

O = { o

,... ,o

} j ∈ N

o = hs,a

,value(a

),u,t

u ∈ U

value : a

→ value(a

) = k ∈ Z

The information about the sequence of operations are

stored in a cloud log cl, which is an element of the set

of cloud logs CL. Every log is composed of a set of

operations O

concerning an attribute a of a resource

r; the set O

is included in the set of all the operations

CL = {cl

,cl

,... ,cl

}, j ∈ N

cl = O

⊆ O

6.3 Violation Detection Capability

An SLA violation detection capability is responsible

to perform a comparison between an indicator of an

attribute for a resource expressed in a service level

∈ I and a set of operations of a speciﬁc cloud logs

where the sequence of values of such attribute is

contained. Such comparison is evaluated according

to the metric m

used to calculate the value. Formally,

the aforementioned entities are correlated in the fol-

lowing tuple. A comparison n belongs to the set of

comparisons N. A comparison tuple is composed of a

cloud log cl, an indicator that has to be veriﬁed i

∈ I,

and the comparison time t

SLAFM-AServiceLevelAgreementFormalModelforCloudComputing

525

N = {n

,... ,n

}, j ∈ N

n = hcl, i

≥ t

∀o ∈ O

,∀i ∈ I

)

= (a

)

Deﬁnition 1. SLA Violation

Given a comparison n ∈ N and a service level sl ∈

SL, the comparison is considered an SLA violation

if the values of the set of operations O

composing

the cloud log cl on the attribute a of the resource r at

the time t are different from the conditioned value cku

of the related indicator i

about the service level sl,

on the same attribute a of the same resource r. The

validity has to be determined during the correct time

interval, namely the times of the operations have to

be included in the time interval t

(i) − t

(i); the value

value(a

)

is obtained by the application of the metric

) = value(a

) 6= (cku)

(1)

(i) ≤ t

value(a

)

≤ t

(i) (2)

7 CASE STUDY: AMAZON S3

The aim of this section is to map the formal model of

the previous section onto the Amazon S3 information

illustrated in Section 5.

7.1 Service Level Agreement

The Amazon S3 SLA has a validity time that begins

when a customer subscribes begins to have access to

the S3 service until it decides to terminate. We con-

sider the solar year 2015 as the S3 SLA validity time.

L = {S3}

S3 = hS3SL,01/01/2015, 31/12/2015i

Among all the legal constraints, we consider the

service level expressed as Monthly Uptime Percent-

age, MUP for short. Amazon Web Services will use

commercially reasonable efforts to make Amazon S3

available with a Monthly Uptime Percentage [...] of

at least 99.9% during any monthly billing cycle. We

consider February 2015 as the billing month range.

a = MonthlyU ptimePercentage

r = S3server

S3SL = {MUP}

MUP = hI,MonthlyU ptimePercentage

S3server

01/02/2015,28/02/2015i

I = {i

}

c = atleast =≥

i = h≥ 99,,MUP

The unit measure is not expressed, so we can discard

it due it is deﬁned optional.

Recalling the deﬁnition of such attribute: Monthly

Uptime Percentage is calculated by subtracting from

100% the average of the Error Rates from each ﬁve

minute period in the monthly billing cycle. Error Rate

is the total number of internal server errors returned

by Amazon S3 as error status InternalError or Ser-

viceUnavailable divided by the total number of re-

quests during that ﬁve minute period(Amazon).

The metric for calculating MUP is a composed

metric, because it needs the computation of the Av-

erageErrorRate that depends on 5minErrorRate, de-

pending again on 5minRequests .

M = {MUP

,AverageErrorRate

,5minErrorRate

5minRequests

}

MUP

= 100%− AverageErrorRate

AverageErrorRate

= (

8640

∑

5minErrorRate

)/8640

5minRequests

+5min

∑

ErrorCode

5minErrorRate

= (

+5min

∑

ErrorCode = InternalError

ORServiceUnavaiable)/5minRequests

7.2 S3 Server Access Log

The SLA violation detection capability collects every

ﬁve minute period time the S3 Server Access Log ﬁles

available in S3 where everyHTTP request made to the

service and its response is stored (see Figure 3). The

information from those logs are mapped in our formal

model in the following way.

R = {S3server}

A = {MonthlyU ptimePercentage}

S3server = { {MonthlyU ptimePercentage}

S3server

}

During the execution of a Cloud service, the value

of an attribute of a resource is subject to change via

an operation o. An operation o is an element of the

set of operations O. Each operation is described by a

mathematical tuple composed of a sender s that is the

executor of such operation, a result value(a

) that de-

scribes the value assigned to attribute a of resource r,

CLOSER2015-5thInternationalConferenceonCloudComputingandServicesScience

526

an operation resource r, an attribute a, and an oper-

ation time t

. The operation value is a mathematical

function that assigns a value to an attribute of a re-

source. The assigned value can be either a numeric or

textual; moreover it can be associated to an optional

unit measure. A sender s is an entity (process) per-

forming operations in the Cloud. Let s be a sender, it

belongs to the set of senders S.

S = {137.43.248.70}

The sender is the Remote IP address ﬁeld of the log

in Figure 3.

O = {REST.GET.OBJECT}

The operation is the Operation ﬁeld of the same S3

Server Access Log ﬁle. The components of the oper-

ation are described in the following tuple.

REST.GET.OBJECT = h137.43.248.70,

MonthlyU ptimePercentage

S3server

,,,

18/Feb/2015 : 10 : 37 : 23+ 0000i

The value component of the tuple is empty, as well as

the unit measure. More precisely, the value compo-

nent is not either InternalError or ServiceUnavailable.

7.3 Violation Detection Capability

In order to build a log cl ∈ CL the SLA violation de-

tection capability translates many S3 Server Access

Log ﬁle, covering an amount of time to be decom-

posed in ﬁve minutes periods From this mapping, the

S3 Server Access Log ﬁle operations mapped to cloud

log O

feed the metric MUP

in order to determine

the elements of the set of comparisons N.

8 DISCUSSION

SLAFM is devoted to formalize a capability to man-

age SLAs violation detections for cloud services. The

proposed approach concerns the representation of in-

formation from both the SLAs and the cloud logs in a

speciﬁc format. One of the strengths of such approach

is its extensibility; because the formal model is a high

level abstraction, it can be enriched with additional

information.

The entity sender is included in this formal model

because considered necessary to easy the eventual

forensic investigation triggered once a violation hap-

pens. The senders are important to reconstruct an

events time-line more efﬁciently and to relate the ﬂow

of the operations stored by cloud logs per authors.

An extension of the model can be the necessity of

managing some legal principles, thus a speciﬁc set of

formal rules can be added to the formal model. The

comparison among a service level and the operations

of the cloud logs have to be memorized because they

can be necessary for computing comparisons of other

service levels. This depends on how the SLAs relate

the service levels and the indicators.

A dedicated system module reacting to the de-

tected SLA violations is out of the SLAFM formal

model duties, but it can be considered as a possible

extension or integration of both the formal model and

the system implementing our capability designed in

Figure 2.

9 CONCLUSION AND FUTURE

WORK

The management of Service Level Agreement con-

tracts for cloud services provisioning is an extremely

challenging and active research trend. Several pro-

posals have been made in literature to approach the

QoS levels guaranteeing issues described in the con-

tracts with the purpose of monitoring a platform be-

haviour.

The main objective of such research works is

to detect whether the agreed resources performances

are respected, without considering the cloud services

logs. In some papers, the issue is formally modelled

for being subsequently implemented; in other ones,

a speciﬁc framework is proposed demonstrating the

manner how such monitoring is performed.

In the future we intend to prototype a system de-

signed in Figure 2 based on the SLAFM formal model

proposed in Section 6. The prototype will simulate

cyber attacks to a cloud service regulated by an SLA,

and it will perform comparisons among the logs and

the SLA constraints. Moreover, we want to test the

number of SLA formal rules violations that can be

detected in a speciﬁc amount of time.

We strongly believe that such capability can en-

hance the security strategies of a Cloud platform, so

that it can be considered as a must requirement for it,

and very likely becoming a standard in the next years.

REFERENCES

Amazon Simple Storage Service (S3), [online]

http://aws.amazon.com/s3/sla/, accessed on

22/02/2015.

Baset, S.A., 2012. Cloud SLAs: present and future. ACM

SLAFM-AServiceLevelAgreementFormalModelforCloudComputing

527

SIGOPS Operating Systems Review, vol. 46, no. 2, pp.

57-66.

Ben-Ari, M., 1993. Mathematical Logic for Computer Sci-

ence, SPRINGER, ﬁrst edition.

Brandic, I., Emeakaroha, V.C., Maurer, M., Dustdar, S.,

Acs, S., Kertesz, A., Kecskemeti, G., 2010. LAYSI: A

Layered Approach for SLA-Violation Propagation in

Self-Manageable Cloud Infrastructures, COMPSACW

Workshop, 2010, pp.365 - 370, IEEE.

Cedillo, P., Gonzalez-Huerta, J., Abrahao, S., Insfran,

E., 2014. Towards Monitoring Cloud Services Using

Models@run.time, International Workshop on Mod-

els at run.time, to appear.

CSA, 2013. Mapping the Forensic Standard ISO IEC

27037 to Cloud Computing, Cloud Security Alliance,

[online] https://cloudsecurityalliance.org/download/

mapping-the-forensic-standard-isoiec-27037 -to-

cloud-computing/

Czajkowski, K., Foster, I., Kesselman, C., Sander, V.,

Tuecke, S., 2002. SNAP: A Protocol for Negotiating

Service Level Agreements and Coordinating Resource

Management in Distributed Systems, Job schedul-

ing strategies for parallel processing, Springer Berlin

Heidelberg, pp. 153-183.

De Marco, L., Abdalla, S., Ferrucci, F., Kechadi, M-

T., 2014. Formalization of SLAs for Cloud Forensic

Readiness, Proc. ICCSM Conference, Academic Con-

ferences and Publishing International Limited, Read-

ing, UK, Dr. Barbara Endicott-Popovsky University of

Washington, Seattle, USA Edition, pp. 42 - 50.

Emeakaroha, V.C., Calheiros, R.N., Netto, M.A., Brandic,

I., De Rose, C.A., 2010. DeSVi: An Architecture for

Detecting SLA Violations in Cloud Computing Infras-

tructures, ICST Cloud Comp Conference.

Emeakaroha, V.C., Ferreto, T.C., Netto, M.A.S., Brandic, I.,

De Rose, C.A.F., 2012. CASViD: Application Level

Monitoring for SLA Violation Detection in Clouds,

IEEE COMPSAC Conference, pp. 499 - 508.

Emeakaroha, V.C., Netto, M.A., Calheiros, R.N., Brandic,

I., Buyya, R., De Rose, C.A., 2012. Towards Auto-

nomic Detection of SLA Violations in Cloud Infras-

tructures, Future Generation Computer Systems, vol.

28, issue 7, pp. 1017-1029.

Ghosh, N., Ghosh, S.K., 2012. An Approach to Identify

and Monitor SLA Parametersfor Storage-as-a-Service

Cloud Delivery Model, GC Wkshps, pp. 724-729.

Information Technology Infrastructure Library (ITIL),

http://www.itil-ofﬁcialsite.com

Ishakian, V., Lapets, A., Bestavros, A., Kfoury, A., 2011.

Formal Veriﬁcation of SLA Transformations, IEEE

World Congress on Services, pp. 540-547.

Larson, K. D., The role of service level agreements in IT

service delivery, Information Management & Com-

puter Security, vol. 6, issue 3, pp. 128-132, 1998.

Liu, F., Tong, J., Mao, J., Bohn, R., Messina, J., Badger,

L., Leaf, D., 2011. NIST cloud computing reference

architecture, NIST special publication, 500, 292.

Maurer, M., Brandic, I., Sakellariou, R., 2012. Self-

Adaptive and Resource-Efﬁcient SLA Enactment

for Cloud Computing Infrastructures, IEEE CLOUD

Conference, pp. 368 - 375.

Mell, P., Grance, T., 2011. Final Version of

NIST Cloud Computing Deﬁnition, [online],

http://csrc.nist.gov/publications/nistpubs/800-

145/SP800-145.pdf

Morshedlou, H., Meybodi, M.R., 2014. Decreasing Impact

of SLA Violations: A Proactive Resource Allocation

Approach for Cloud Computing Environments, IEEE

Transactions on Cloud Computing, vol.2, no.2, pp.

156-167.

Muller, C., Oriol, M., Franch, X., Marco, J., Resinas, M.,

Ruiz-Corts, A., Rodriguez, M., 2014. Comprehen-

sive explanation of SLA violations at runtime. IEEE

Transactions on Services Computing, vol. 7, issue 2,

pp. 168-183.

Paschke, A., Bichler, M., 2008. Knowledge Representation

Concepts for Automated SLA Management, Decision

Support Systems, vol. 46, issue 1, pp. 187-205.

Patel, P., Ranabahu, A.H., Sheth, A.P., 2009. Service

Level Agreement in Cloud Computing, [online],

http://corescholar.libraries.wright.edu/knoesis/78

Rumbaugh, J., Jacobson, I., Booch, G. 2004. Uniﬁed

Modeling Language Reference Manual, The. Pearson

Higher Education.

Skene, J., Skene, A., Crampton, J., Emmerich, W., 2007.

The Monitorability of Service-Level Agreements for

Application-Service Provision, Proc. International

Workshop on Software and Performance, pp. 3-14.

Unger, T., Leymann, F., Mauchart, S., Scheibler, T., 2008.

Aggregation of Service Level Agreements in the Con-

text of Business Processes, Proc. ICEDOC Confer-

ence, pp. 43-52.

CLOSER2015-5thInternationalConferenceonCloudComputingandServicesScience

528