OCCI and TTCN-3
Towards a Standardized Cloud Quality Assessment Framework
Yongzh
eng Liang
bwcon GmbH, Breitscheidstrasse 4, 70174 Stuttgart, Germany
Keywords: Cloud Quality Assessment, Standardized Testing, TTCN-3, Cloud Standards, OCCI, Software Defined
Network, Network Functions Virtualization.
Abstract: Impacting basically all types of IT infrastructures The Cloud is one of the most important evolving IT
paradigms. A standard-based Cloud quality and compliance assessment framework will be therefore of
utmost importance. Bringing together the Open Cloud Computing Interface OCCI and the ETSI
standardized test specification language TTCN-3 and related test methodologies this paper is going to
demonstrate initial steps towards such a framework. Taking into account the diversity of Cloud
infrastructures, of service providers, and related architectural, harmonization and standardization effort this
approach is mainly motivated by studying Cloud-related effort of the NIST Cloud Computing Program and
the ETSI Cloud Standards Coordination (CSC). Reflecting the “Cloudiness” of the Software Defined
Network (SDN) and ETSI Network Functions Virtualization (NFV) this paper is considering these
initiatives as necessary elements of the scope of every future standardized Cloud quality assessment
framework as well.
1 INTRODUCTION
Impacting basically all types of IT infrastructures
“The Cloud” is one of the most important evolving
IT paradigms. A standard-based Cloud quality and
compliance assessment framework will be therefore
of utmost importance. Bringing together the Open
Cloud Computing Interface OCCI and the ETSI
standardized test specification language TTCN-3
and related test methodologies this paper is going to
demonstrate initial steps towards such a framework.
Taking into account the diversity of Cloud
infrastructures, of service providers, and related
architectural, harmonization and standardization
effort our approach is motivated by studying Cloud-
related effort of the NIST Cloud Computing
Program, NIST CC, the ETSI Cloud Standards
Coordination (CSC). Reflecting the “Cloudiness” of
the Software Defined Network (SDN) and ETSI
Network Functions Virtualization (NFV) this paper
is considering theses initiatives as necessary
elements of the scope of every future standardized
Cloud quality assessment framework.
The rest of the paper is organized as follows:
Chapter 2 is introducing pertinent work of NIST CC
and ETSI CSC– here the role of the OCCI standard
becomes already visible. The methodological look at
NIST/ETSI will follow the triple “use cases –
standards – testing” and corresponding mappings.
Chapter 3 describes how, following the
virtualization paradigm, the “Software Defined
Network”, SDN, and ETSI NFV have met the
Cloud. It will be noticed that the NFV use case
“IMS as a Service” (IMSaaS) has in its original
3GPP and ETSI context an elaborated TTCN-3
framework.
Chapter 4 introduces the OGF OCCI standard.
Chapter 5 decribes some OCCI related effort of
relevance in the given context.
Chapter 6 introduces TTCN-3, the “Testing and Test
Control Notation Version 3” the test specification
language standardized by ETSI. Chapter 7 describes
relevant TTCN-3 effort.
Chapter 8 describes “TTCN-3 on top of OCCI” for
both a subset of the ETSI Interoperability test cases
and for BonFIRE – a large European Multi-Cloud
project.
Chapter 9 resumes the paper and gives an outlook on
future work.
40
Liang Y..
OCCI and TTCN-3 - Towards a Standardized Cloud Quality Assessment Framework.
DOI: 10.5220/0005451900400048
In Proceedings of the 5th International Conference on Cloud Computing and Services Science (CLOSER-2015), pages 40-48
ISBN: 978-989-758-104-5
Copyright
c
2015 SCITEPRESS (Science and Technology Publications, Lda.)
2 TOWARD A STANDARDIZED
CLOUD QUALITY
ASSESSMENT FRAMEWORK
Influenced by and possibly influencing the evolution
of Cloud ecosystems potential Cloud adopters have
developed related use cases of different abstraction
level above the basic technologies in question. At
the same time and in a similar interdependency
relation in numerous bodies Cloud standards have
evolved and are still evolving. In such a situation
mapping use cases to compatible or even
“integrated” standards is one of the natural important
steps to happen next. Eventually, addressing
different test types such as conformance,
performance etc. test cases will be specified. Being a
simplified one, this process is nevertheless a typical
and necessary element in the evolution towards a
quality assessment framework.
Following this process and given the sheer weight of
the US Government as a Cloud adopter and the
important role of ETSI concerning high-quality
standards and formal testing methodologies we are
going to use the NIST Cloud Computing Program
and the ETSI Cloud Standard Coordination effort in
order to argue for a TTCN-3- and OCCI-oriented,
standardized Cloud quality assessment framework.
2.1 NIST CC Program
The NIST (National Institute of Standards and
Technology) designed its Cloud Computing
Program, CC, “to support accelerated US
government adoption, as well as leverage the
strengths and resources of government, industry,
academia, and standards organization stakeholders
to support cloud computing technology innovation”
(NIST, 2014). The cited document “US Government
Cloud Computing Technology Roadmap” compri-
sing the Volume I “High-Priority Requirements to
Further USG Agency Cloud Computing Adoption”
and Volume II “Useful Information for Cloud
Adopters” summarizes the results of now the
finalized Phase I and defines and relates ten “high-
level requirements” to the different NIST CC
working groups for Phase II.
Key documents of Phase I are concerning Cloud
taxonomy and vocabulary, reference architecture,
standards and security; for references see (NIST,
2014).
The NIST projects and working groups apply a use
case methodology to define business and technical
operational scenarios and requirements. The NIST-
chaired public Cloud Computing Business Use Case
Working Group (CCBUCWG) has produced use
cases at the functional mission level. Those
“business use case are decomposed into a list of
high-level requirements, then into successively more
detailed requirements, until they can ultimately be
mapped to technical requirements that are required
to identify and executed” as “technical use cases”.
Dealt with by the group “Standards Acceleration to
Jumpstart the Adoption of Cloud Computing”
(SAJACC) the latter use cases are “designed to
facilitate the qualitative testing of standards through
the use of third-party APIs implemented in
adherence to candidate specifications and emerging
standards”. SAJACC use cases represent single
activities, such as the “deletion of data, and the
actions needed to successfully execute that activity
(receive the request, respond to the request, execute
the request, etc.)”.
Without any ambition towards formalization in
terms of possible map-ability and automated
processing, for the description of use cases two types
of templates have been developed.
A particular set of standards in relation to a use
cases was termed “compatible standards” – no
specific exercise was undertaken to consider the
“integration” of those specific standards in question
– e.g. CDMI and OCCI; see also below (Edmonds,
2011) However, concerning the “current state of
conformity assessment in Cloud Computing”,
(NIST, 2014), section 6.2.4 states: In some cases,
such as the CDMI, OCCI, OVF, and CIMI
standards… industry-sponsored testing events and
“plug-fests” are being advertised and conducted with
participation from a variety of vendors and open
source projects and community-based developers. In
other cases, either the standards are not yet mature
enough to permit such testing, or the participants
have not yet exposed the conformity assessment
processes to public view. – In this spirit NIST
representatives gave presentations at the “First
Cloud Interoperability Week” (Sill, 2013); see also
(Liang, 2013a). Finally, in order to cope with
questions like “is the proposed quality assessment
framework not overkill?” - it should be mentioned
that the NIST is considering Cloud ecosystems as
eventually big, complex and potentially endangered
by “catastrophes” comparable to the famous Internet
or global power grid breakdowns. Accordingly –
with participation of the OGF Research Group on
Grid Reliability and Robustness - NIST has started
the “Complex Information Measurement Project -
Koala” (NIST, 2015).
It should be noticed that so far NIST doesn’t deal
with SDN or NFV issues, see below.
OCCIandTTCN-3-TowardsaStandardizedCloudQualityAssessmentFramework
41
2.2 ETSI CSC
Being part of the European Commission’s Cloud
related strategy the so-called key action “Cutting
through the jungle of standards” was assigned by
DG Connect to the specifically created ETSI
working group “Cloud Standards Coordination”,
CSC. The latter in its mission’s final step 3 created
three “Specification identification gap analysis”
working groups: SLAs – Security & Privacy – and –
Interoperability, Data port, Reversibility. Launched
in December 2012, the CSC provided a final report
(ETSI, 2013). This report stated that “the Cloud
Standards landscape is complex but not chaotic and
by no means a 'jungle' “.
In this report ETSI CSC introduces vocabulary and
taxonomies applicable to Cloud Actors and their
Roles within Use Cases. The analysis of Use Cases
comprises the following dimensions: “Phases and
Activities”, “Perspectives” (SLAs, Interoperability,
Security), generic domains (e.g. “Applications in the
Cloud”, “Cloud Bursting” etc.), and “Phases and
Activities”. This schema is then used in a mapping
of use cases to standards.
Gaps related to SLAs, security and privacy are dealt
with in the final report. Interoperability is
specifically covered by the Technical Specification
“CLOUD; Test Descriptions for Cloud
Interoperability” (ETSI, 2013b). The standards dealt
with herein are OCCI, see below, and CDMI,
CAMP, OVF and CIMI. In Chapter 8 below we are
going to demonstrate some initial work related to the
OCCI-related test cases.
It should be mentioned that also ETSI CSC
expresses a positive view concerning OCCI
(together with CDMI and OVF): “OCCI as the
universal and extensible interface description for the
provisioning of virtualised computing resources.”
ETSI CSC has called for a 2nd Phase of work to be
started in early 2015 – and in close cooperation with
NIST CC.
Without any further explanation the ETSI CSC final
report provides a list of the ETSI NFV
specifications; see next chapter.
3 ETSI NFV, SDN AND THE
CLOUD
Instrumental as a key concept and as enabler of
many aspects of computing , storage and networking
“Virtualization“ lies at the ground of both the Cloud
and concepts or initiatives such as the “Software
Defined Network”, SDN (ONF, 2011) and ETSI’s
“Network Function Virtualization”, NFV (ETSI,
2012).
SDN has evolved as a potential solution to both the
growing management complexity of the overly
successful Internet and, in turn, the growing
“ossification” of the latter. Aiming at more
flexibility and dynamicity of network services
through programmability of network hardware boxes
such as routers, switches, firewalls etc. the
OpenFlow™ protocol and API is a key element in
the context. Launched in 2011 by Deutsche
Telekom, Facebook, Google, Microsoft, Verizon,
and Yahoo!, the Open Networking Foundation
(ONF) is a non-profit organization with more than
140 members whose mission is to accelerate the
adoption of open, standardized OpenFlow-based
SDN.
Used as generic term “software defined networking”
is also addressed by the “Network Functions
Virtualization - Industry Specification Group”,
NFV(ISG). Initiated in 2012 within ETSI by seven
telecom operators the group was joined by over 200
companies including network operators, telecoms
equipment vendors. Opposed to SDN, NFV was
primarily driven by concerns related to OPEX and
CAPEX of typical telecom hardware appliances and
service agility. NFV aims to use “advanced IT
virtualization techniques” (aka Cloud plus Cloud
enablers i.e. hypervisors etc.) in order to convert
typical telecom appliances and service frameworks
into “X as a Service” instances, the latter class being
instantiated even into “IMS as a Service”, IMSaaS.
SDN and NFV are highly complementary to and
independent of each other.
In order to promote NFV trough OpenFlow-based
SDN in March 2014 ONF and ETSI agreed on a
related strategic partnership.
The NFV(ISG) has produced since five
specifications covering NFV use cases,
requirements, the architectural framework, and
terminology. The fifth specification defines a
framework for coordination and promotion of public
demonstrations of Proofs of Concept, PoC (ETSI,
2014). The PoC demonstrate key aspects of NFV
use cases – specifically the explicitly Cloud-related
“NFV Infrastructure as a Service” (NFVIaaS), the
“Virtual Network Functions as a Service”
(VNFaaS), the “Service Chain Forwarding Graphs”
(VNF FG), the “Virtual Network Platform as a
Service” (VNPaaS) and the mobility–oriented
“Virtualization of the Mobile Core Network and
IMS”. The first results of the NFV PoC have been
showcased.
CLOSER2015-5thInternationalConferenceonCloudComputingandServicesScience
42
While aiming at vendor and product neutrality the
Cloud “core” of the PoC was the OpenDaylight
Hydrogen release of OpenStack comprising inter
alia the OpenStack Neutron component as
OpenFlow oriented SDN controller.
Here, in the context of this paper, it should be
noticed that this whole architecture is controlled by a
(super-)set of the OpenStack RESTful APIs; see
below the MCN project.
Finally, it should be mentioned that ETSI NFV
doesn’t refer to ETSI CSC or the ETSI TC MTS, the
Technical Committee Methods for Testing and
Specification (ETSI, 2015); specifically, there is no
hint given to the ample, standardized TTCN-3-
oriented test framework (ETSI, 2015a).
4 OCCI
The Open Grid Forum’s (OGF) ‘Open Cloud
Computing Interface’ (OCCI) is a well-defined,
RESTful Cloud management protocol and interface,
which can be applied to and extended from its initial
target IaaS to functional and non-functional aspects
also of PaaS and SaaS – even in Multi-Cloud
ecosystems.
The definition of OCCI comprises a “Core” and a
meta-model aspect according to the following figure,
see (OCCI, 2011b).
The “Core” describes the foundation of the OCCI
type system – “what types of resources can be out
there”. This is orthogonal and complementary to the
wire”.
The meta-model aspect represents the descriptive
part allowing for extensibility, hierarchies, dynamic
runtime modifications of resource instances and
tagging via Mixins, and introspection via the
mandatory discovery interface (Edmonds, 2012).
Members of the OCCI specification group
developed a related conformance platform in Python
(OGF, 2012b and OGF, 2012a). This work was not
continued after 2012; it is/was not directly targeting
whole OCCI-controlled Cloud systems but the
conformance of (language) specific OCCI
implementations.
The OCCI Working Group of the OGF is actively
pursuing the further development of the OCCI
standard; a completed specification is available e.g.
for JSON rendering; a “Monitoring” specification
and a related “Notification” specification are almost
ready, and there is work for a “Platform” (PaaS)
specification; see (OGF, 2014).
At the same time the WG is present at many related
Cloud events such as the Cloud Interoperability
Figure 1: The OCCI “Core” Model.
Week mentioned above. Basically all WG members
are also present in NIST CC or EGI (EGI, 2015) and
MCN; see below.
5 OCCI-RELATED EFFORT
In order to further argue for the “robustness” of the
OCCI case, in the following we are going to shortly
mention effort covering technical and “market”
aspects of OCCI applicability.
5.1 OCCI Technical Versatility
In (Edmonds, 2011) a standards conformant
“integration scenario” of OCCI, CDMI and OVF is
presented.
The “First Open Cloud Broker” developed in the
CompatibleOne project and initiative is an early
example for the extensibility of OCCI beyond IaaS
(CompatibleOne, 2015).
The EU project MCN - Mobile Cloud –
Networking, 2012-2015, “is motivated primarily by
an ongoing transformation that drives the
convergence between the Mobile Communications
and Cloud Computing industry enabled by the
Internet” (MCN, 2014). MCN’s two scenarios are
“Exploiting Cloud Computing for Mobile Network
Operations” and “The End-To-End Mobile Cloud”.
While not fully concurrent with ETSI’s NFV PoC
architectural principles MSC is about to realize a
comparable SDN/NFV framework wherein the
Cloud component will be represented by OpenStack
too. In contrast to ETSI’s PoC non-standard set of
related RESTful interfaces MCN is targeting OCCI.
Referring to Core meta-model mechanisms, (MCN,
2013) section “2.4.1 OCCI Extensions” and “2.4.2
OpenStack Extensions”, the project has defined
necessary extensions to both OCCI and OpenStack.
OCCIandTTCN-3-TowardsaStandardizedCloudQualityAssessmentFramework
43
Finally, among the set of MCN’s XaaS to be
provided we are specifically mentioning MaaS,
Monitoring as a Service (see also below the
BonFIRE project) and IMSaaS, IMS as a Service.
The OCCI work in MCN is well aligned with the
OCCI WG.
5.2 OCCI in Large Infrastructures
“The European Grid Infrastructure (EGI) is building
a federated, standards-based IaaS Cloud platform,
building on its decade-long experience in delivering
a reliable, federated Grid infrastructure for scientific
computing and e-Research across Europe and
worldwide.” “Federations are enabled by a set of
core services such as seamless authentication and
authorization of users, gathering of accounting
information, information discovery, monitoring and
VM management across multiple cloud domains; see
(EGI, 2015)
In the given context it is of relevance that EGI
Engage, the next large project of the initiative, is
targeting well defined OCCI extensions in order to
increase functions and performance of its pan-
European Cloud federation. This work is closely
aligned with the OCCI WG.
Our tests below are using the so-called rOOCI, an
OCCI implementation in ruby. The rOCCI is part of
the EGI effort.
6 TTCN-3
TTCN-3, the “Testing and Test Control Notation
Version 3” is a successful Test Specification
Language standardized by ETSI. Initially targeted at
protocol conformance testing e.g. for IPv6, or SIP,
the coverage of TTCN-3 was extended to new
technical domains such as the Web, embedded and
real-time systems, and new sectors such as Health,
Automotive and “Intelligent Transport Systems”
(ITS). Related organizations are e.g. 3GPP, OMA
and AUTOSAR. The ETSI TTCN-3 standards have
also been adopted by International Telecom-
munication Union (ITU-T) in the Z.160 series. The
main characteristics of TTCN-3 are: Multi-
Separation of Concerns by dividing a test system
into an abstract but executable Test Specification
Layer (“ATS” in Figure 2), and Concrete Codec and
System-Adaptation Layers; see again Figure 2. From
an effort point of view codec and adapter represent a
major piece of (initial) work, paving the way
towards a potential large testing framework at ATS
level. This separation between concrete and abstract
layer is also allowing for a high degree of
reusability. Targeting testing by design TTCN-3
provides an elaborated mechanism for the
construction of Templates the latter to be used as test
oracles; see e.g. (Schieferdecker, 2012). A related
powerful Template matching mechanism then serves
to validate output from the “System under Test”
(SUT) on the level of the ATS; compare this e.g.
with the language dependencies in (OGF, 2012a). -
Related global Verdicts are computed, possibly
composed from local Verdicts.
Figure 2: Layout of a TTCN-3 Executable Test Suite.
7 TTCN-3 RELATED EFFORT
In following, the first section is shortly describing
effort related to TTCN-3 language developments.
Section two is showing TTCN-3 as an element of
ETSI’s effort towards model-based testing.
7.1 TTCN-3 Development
TTCN-3 related effort is devoted to both the
development of the language as such (via well- --
defined formal procedures within the ETSI); an
example of relevance in context is “MTS The
Testing and Test Control Notation version 3; Part
11: Using JSON with TTCN-3” - and other aspects.
Such work may be carried out e.g. in cooperation
with tool providers – to improve the efficiency of the
coding/decoding process in a Web service
environment would be an example. For a recent
overview see (Stepien, 2014).
7.2 TTCN-3 in the ETSI TC MTS
TTCN-3 is not “just another standalone test
specification language” but is part of an overall
CLOSER2015-5thInternationalConferenceonCloudComputingandServicesScience
44
effort within ETSI to further the development of
methodologies in the spirit of “model-based testing”
(ETSI, 2015).
Initially targeting communicating systems the ETSI
MTS is addressing the formalization and
mechanization/automation of a stack of processes
and specifications ranging from requirements
solicitation and “notation” over test and test purpose
to test case specification.
Herein TTCN-3 is placed at the bottom layer.
Looking at the table format of the NIST technical
and the ETSI CSC use cases the corresponding TC
MTS historical effort is TPLan, ETSI ES 202 553.
At present the TC MTS is pursuing with the TDL,
Test Description Language, a more rigorous
approach: integrating and unifying test description
and test purpose specification layer above TTCN-3
TDL raises the abstraction layer of the latter and
allows at the same time for down-mapping from the
requirements layer; see (Makedonski, 2014).
8 TTCN-3 AND OCCI
“TTCN-3 on top of OCCI” was, to our knowledge,
presented for the first time at the “Cloud
Interoperability Week Workshop”, (Liang, 2013a)
and at the UCAAT 2013 (Liang, 2013b). This work
was related to the initial version of ETSI “Test
Descriptions for Cloud Interoperability” (ETSI,
2013b).
We improved and extended this effort in the
following way:
- We wrote new versions of the Codec and the
System Adapter allowing specifically for a complete
treatment of all coding and systems requirements of
the OCCI tests of (ETSI, 2013b); see Figure 2 and
Figure 3 again for the positioning these
components.
- Using the current version of the ETSI document, so
far we carried out all the OCCI Core and
Infrastructure tests against a rOCCI-based EGI
Cloud test infrastructure (EGI, 2015).
- We run initial tests of the BonFIRE Multi-Cloud
project “Elasticity as a Service” (for “BonFIRE and
OCCI” see below), (BonFIRE, 2014).
8.1 TTCN-3 and OCCI Mapping
The Figure 3 below shows the functional
components and potential mappings of a TTCN-3
test system and those of an OCCI controlled Cloud
system:
Figure 3: Mapping TTCN-3 - OCCI.
Elements formatted according to the OCCI
specification can be expressed in terms of a TTCN-3
Abstract Test Specification. The rendering of the
different MIME types will be accomplished by the
Codec. The OCCI transport via HTTP will be
provided by the System Adaptor.
For example, the OCCI “Category” can be
abstracted into the following TTCN-3 Data type:
Category {
charstring category,
CategoryValue category_value
}
type set CategoryValue {
charstring term,
charstring scheme,
charstring class,
charstring title optional,
charstring rel optional,
charstring location optional,
charstring attributes optional,
charstring actions optional
}
type set of Category CategoryList;
type record Category {
charstring category,
CategoryValue category_value
}
type set CategoryValue {
charstring term,
charstring scheme,
charstring class,
charstring title optional,
charstring rel optional,
charstring location optional,
charstring attributes optional,
charstring actions optional
}
type set of Category CategoryList;
In order to carry out the ETSI test case
“TD/OCCI/INDRA/CREATE/004: Create an OCCI
Compute Resource” one has to create the following
TTCN-3 request template:
OCCIandTTCN-3-TowardsaStandardizedCloudQualityAssessmentFramework
45
template OCCIReq
Req_TD_OCCI_INFRA_CREATE_004 :={
url_req :={
scheme := "http://",
authority :=
"rocci.herokuapp.com",
path := "/compute/"
},
category_list := {
{
category := "Category",
category_value := {
term := "compute",
scheme :=
"http://schemas.ogf.org/occi/infrastruc
ture#",
class := "kind"
}
},
{
category := "Category",
category_value := {
term := "small",
scheme :=
"http://my.occi.service/occi/infrastruc
ture/resource_tpl#",
class := "mixin"
}
},
{
category := "Category",
category_value := {
term := "my_os",
scheme :=
"http://my.occi.service/occi/infrastruc
ture/os_tpl#",
class := "mixin"
}
}
},
link_list := omit,
x_occi_attribute_list := omit
}
This template represents the test oracle, i.e. the
expected response of the SUT, for this conformance
test.
The related HTTP verbs GET, POST, PUT and
Delete and the OCCI rendering have to be
parameterized as follows:
/* select HTTP verb */
modulepar boolean Create := true;
modulepar boolean Read := false;
modulepar boolean Update := false;
modulepar boolean Delete := false;
/* select OCCI Rendering */
modulepar charstring ContentType :=
"text/occi";
modulepar charstring AcceptValue :=
"text/occi";
The annotated Figure 4 shows the corresponding
result of the test:
Figure 4: Creating an Infrastructure OCCI Compute
resource modified by two mixins.
The tool window (TTworkbench, 2015) is showing:
- the list of all the implemented ETSI tests - the
currently executed is highlighted (left upper corner)
- the action “create” and the related content type
“text/occi”
- a “compute” “kind” modified by the two “mixins”
(large window, middle right; see Figure 1 again for
terminology); (the small window, upper corner right,
is showing that the compute resource was created on
a server of the PaaS provider HEROKU used by EGI
for testing purposes).
- the OCCI Request/Response message exchange
between the System_under_Test and the Test
System (graphical window right bottom; the Verdict
“pass” message is just not visible;).
8.2 TTCN-3 and “BonFIRE OCCI”
BonFIRE a recent EU project has realized and is
providing a multi-site testbed on top of seven Cloud
infrastructures operated by seven project partners.
BonFIRE IaaS offers heterogeneous compute,
storage and network resources, (BonFIRE, 2014).
In the given context, the main features of the
BonFIRE (BF) architecture are the following:
- BF implements an “almost” OCCI-based resource
manager on top of the participating IaaS testbed sites
(no Categories etc., no MIXINS).
- The rendering uses the private type
“application/vnd.bonfire+xml”
- BF provides a monitoring capability at both the
VM and physical level. Under user control events
generated by (Zabbix) monitoring agents are
transported via AMQP to an “Aggregator”. From a
functional point of view, the BF monitoring fits well
the “Focused Technical (security) Requirements” of
(NIST, 2014) Part II, “Visibility/Control for
Consumers”.
CLOSER2015-5thInternationalConferenceonCloudComputingandServicesScience
46
- BF provides an experimental EaaS – Elasticity as a
Service - across the test bed sides.
Formally, according to the BF data model, the BF
user carries out “Experiments”. In a full OCCI
setting “Experiments” would be defined as a
Category above the participating infrastructures.
Except for the description part and the fixed
allocation of monitoring agents to user created VMs
the monitoring architecture is close to the proposal
presently discussed within the OGF OCCI WG.
The annotated Figure 5 shows:
Figure 5: Creating a BonFIRE elasticity group.
- the creation of a elasticity group distributed over
several BonFIRE geographical sites in France, the
UK and Germany - in response to the request
template (upper part right)
- the related action is (naturally) “create”
- (left below) the rendering’s private type
“application/vnd.bonfire+xml”
- the verdict “pass” message (graphical window
part).
Not considering the only “almost” OCCI compliance
of the project BonFire is a clear and working
example for the potential of OCCI beyond its initial
specification.
9 SUMMARY AND OUTLOOK
Using Cloud related work of NIST and ETSI we
have presented standardized testing of standard-
based Cloud infrastructures as a necessary element
of a Cloud quality assessment framework. We have
shown that OCCI is well positioned to play a pivotal
role within that context.
Assuming a key role of SDN/NFV in future Cloud
provisioning we have also pointed to work using
OCCI in SDN/NFV settings of Cloud
infrastructures.
Then we have introduced the ETSI effort towards
model-based testing – comprising TTCN-3 at the
lowest layer.
In summary we propose – as strategically vision
behind our effort - to adopt the Cloud world as the
next big application field of the well-established
ETSI TTCN-3-related testing methodologies.
Finally, as a proof-of-concept we demonstrated
“standardized” TTCN-3 test cases against OCCI
controlled Cloud test beds.
In order to gather and solicit support for our vision
future work will include true interoperability tests in
the spirit of ETSI CSC and further test types such as
performance tests. If SDN/NFV Cloud
infrastructures such as in the OCCI-oriented MCN
become available tests exploiting advanced features
both of TTCN-3 and OCCI are foreseen.
ACKNOWLEDGEMENTS
We would like to thank – Boris Parák of CESNET
for support in using the rOCCI/EGI infrastructure –
the former colleagues of BonFIRE for provision of
the BonFIRE testbed – Prof. Ina Schieferdecker for
guidance in the TTCN-3 world – Testing
Technologies for the friendly provision of their
TTCN-3 tool TTworkbench. The paper is partly
funded by the EU project CloudSocket H2020-
644690.
REFERENCES
BonFIRE, 2014. www.bonfire-project.eu/. Accessed
January 06, 2015.
CompatibleOne, 2015. CompatibleOne The Open Source
Cloud broker. http://www.compatibleone.org/.
Accessed January 06, 2015.
Edmonds, A., Metsch, T., Luster, E., 2011. An Open,
Interoperable Cloud.
http://www.infoq.com/articles/open-interoperable-
cloud. Accessed January 06, 2015.
Edmonds, A. et al. Towards an Open Cloud Standards.
IEEE Internet Computing. July/August 2012.
EGI, 2015. EGI European Grid Infrastructure.
https://www.egi.eu/infrastructure/cloud/.
ETSI, 2012. http://www.etsi.org/technologies-clusters/
technologies/nfv. Accessed January 06, 2015.
ETSI, 2013a. Cloud Standards Coordination Final Report
November 2013 VERSION 1.0. November 2013.
ETSI, 2013b. TS 103 142 V2.0.2 (2013-09) CLOUD; Test
Descriptions for Cloud Interoperability.
ETSI, 2014. NFV Proofs of Concept.
http://www.etsi.org/technologies-
clusters/technologies/nfv/nfv-poc. Accessed January
06, 2015.
ETSI, 2015. TC Methods for Testing and Specification
http://www.etsi.org/images/files/ETSI
OCCIandTTCN-3-TowardsaStandardizedCloudQualityAssessmentFramework
47
TechnologyLeaflets/MethodsforTestingand
Specification.pdf. Accessed January 06, 2015.
ETSI, 2015a. http://www.etsi.org/technologies-
clusters/technologies/testing/ims-testing.
Accessed January 27, 2015.
Liang, Y., 2013a. Harnessing TTCN-3 Test Framework
for OCCI-based Cloud Ecosystems. In DMTF, ETSI,
OASIS, OCEAN Project, OGF, OW2 and SNIA. First
Cloud Interoperability Week Santa Clara, USA,
September 16-18 and Madrid, Spain, September 18-
20, 2013 (co-hosted with the EGI and SDC
conferences)
http://www.cloudplugfest.org/events/past-plugfest-
agendas/cloud-interoperability-week/workshop
Accessed December 14, 2014.
Liang, Y., 2013b. Towards a TTCN-3 test framework for
OCCI-based Cloud ecosystems. In UCAAT, 1st User
Conference on Advanced Automated Testing. Paris
22-24 October 2013. http://ucaat.etsi.org/2013/
program_conf.html Accessed December14, 2014.
Makedonski, P. et al., 2014. Bringing TDL to Users: A
Hands-on Tutorial. http://www.swe.informatik.uni-
goettingen.de/sites/default/files/publications/TDL%20
Tutorial.pdf. Accessed January 06, 2015.
MCN, 2014. Mobile Cloud Networking project.
http://www.mobile-cloud-networking.eu/site/
(accessed December 14, 2014).
MCN 2013 FUTURE COMMUNICATION
ARCHITECTURE FOR MOBILE CLOUD
SERVICES. FP7-ICT-2011-8 Project No: 318109.
D3.1 Infrastructure Management Foundations –
Specifications & Design for Mobile Cloud framework.
08 November 2013.
NIST, 2014. Special Publication 500-293. Version 2. US
Government Cloud Computing Technology Roadmap.
Volume I. High-Priority Requirements to Further USG
Agency Cloud Computing Adoption. Volume II.
Useful Information for Cloud Adopters
http://dx.doi.org/10.6028/NIST.SP.500-293. October
2014.
NIST, 2015. Koala. In “Measurement Science for
Complex Information Systems”. http://www.nist.gov/
itl/antd/emergent_behavior.cfm. Accessed January 06,
2015.
NIST, 2014b. Special Publication 500-299. Draft. NIST
Cloud Computing Security Reference Architecture.
OCCI, 2011a. http://occi-wg.org/about/. Accessed January
06, 2015.
OCCI, 2011b. Core Specification: http://ogf.org/
documents/GFD.183.pdf.
OCCI, 2011c. Infrastructure: http://ogf.org/
documents/GFD.184.pdf.
OCCI, 2011d. HTTP Rendering: http://ogf.org/
documents/GFD.185.pdf.
OGF, 2012a. Grokking OCCI Syntax: OCCI ANTLR
Grammar. http://occi-wg.org/2012/02/29/occi-antlr-
grammar/. Accessed January 06 2015.
OGF, 2012b. Do you Speak OCCI? http://occi-
wg.org/2012/03/05/do-you-speak-occi/.
OGF, 2014. OGF42 Updates from the Group. http://occi-
wg.org/2014/09/15/updates_from_ogf42/. Accessed
January 06 2015.
ONF, 2011. https://www.opennetworking.org/. Accessed
January 06, 2015.
Schieferdecker, I. Oracles in TTCN-3 and UTP. In
CREST Workshop. 2012, May 22nd, London.
Stepien, B. Peyton, L. 2014 “Innovation and Evolution in
Integrated Web Application Testing with TTCN-3”,
International Journal on Software Tools for
Technology Transfer. June 2014, Volume 16, Issue 3,
pp 269-283.
Sill, A., 2013. SAJACC: The NIST Cloud Use Case Test
Definition Project. In - same as (Liang, 2013a).
TTCN-3, 2013. http://www.ttcn-3.org/. Accessed January
06, 2015.
TTworkbench, 2015. http://www.testingtech.com/
products/ttworkbench.php.
CLOSER2015-5thInternationalConferenceonCloudComputingandServicesScience
48
