• Current Internet services are not a “cure-all” and are not fully cognisant of end-user requirements, especially for enterprises and mission critical applications.
• Current Internet services operate on a “best-effort” basis: there is little consideration for quality, e.g. of service, of experience, etc. Indeed in certain parts of a service stack there no comprehension of quality guarantees.
• There are little or no service guarantees to the consumer: if any, they are static, inflexible and not negotiable. Often it is left up to the consumer to implement their own systems to ensure guaranteed service.

To address this, the services must be imbued with the principle of Dependability. Dependability is a set of attributes that a service SHOULD (requirement) exhibit in order to be deemed dependable. It should be noted that only a subset of those attributes MUST be exhibited (Reliability and Availability) as these are quantifiable. The other attributes are somewhat more subjective. For all Internet services to be dependable they will share new common requirements or constraints and as Eames said, “Design depends largely on constraints” and “design is an expression of the purpose”, where the purpose is dependability. To be dependable a service must exhibit/implement the following attributes as defined by an IEEE group,which is the embodiment of 24 years of work in the IEEE:

There are many challenges to cloud computing but one core to enabling further value is the removal of lock-in and the enablement of interoperability between cloud services.

To be interoperable means to imbue the common abilities of mobility to cloud service instances, to extract all service instance described by a common representation, to share all cloud service instance related data in and out of providers and to allow cloud service instances work together.

To provide interoperability, it must be present at the lowest level of the cloud stack and so IaaS should firstly be the target, with those interoperability capabilities offered to the upper layer of PaaS where lock-in is even more prevalent. To execute upon this desire, standard specifications need to be agreed upon by both research and industrial domains. In essence this means, in the context of IaaS, to agree upon standardised ways to import and export IaaS customer deployments, to interface with those deployments in a common way during their lifecycle and runtime and to have access to the data supplied and generated and in creating that deployment. These three types of standards must cooperate and integrate as there is no one SDO that can capture research and industry interest and supply the relevant skills all as one. In terms of the IaaS domain this specifically means:

1. Standardised specifications for the import and export of virtualised infrastructure service instances
2. Standardised runtime specification to allow the run-time and lifecycle management of virtualised infrastructure service instances
3. Standardised data access, import and export capabilities to the data that created and was generated by the virtualised service instances

Interoperability is not only a challenge for those in the research and industrial  domains but also for the standards development organisations that solicit input from both the former domains. It is also a challenge that increases in complexity as we move up the commonly accepted cloud computing stack (IaaS –> PaaS –> SaaS). There will be many technical challenges in cloud interoperability below the level of standard specifications but the some more obvious are:

1. Data migration: Cloud service instances can retrieve, consume and process data in ranges greater than terabytes. If one has a cloud service and its related data set is of such an order, current day network technologies are not sufficient to transfer the data in any reasonable time.
2. Service instance migration: A challenge in a similar vein to the previous, what’s of particular interest here is how to maintain and enable  live migration capabilties between cloud providers where paths between two can span many subnets. Work from projects like RESERVOIR is appropriate.
3. Capability Advertisement/Negotiation: Before any migration of service instances can be accomplished, it is necessary that each cloud service provider advertises its service capabilities so that customers wishing to migrate can verify that their current set of capabilities will be satisfied by the target cloud provider. This verification mechanism can also be seen as a negotiation of capabilities, which would lend well to the idea of automated SLAs. Such work from SLA@SOI, OGF’s WS-Agreement would provide a good base line here.

By tackling the challenge presented by interoperability enablement there are a large set of advantages that will emerge, amongst those will be:

• Increased Choice: With many cloud services offering the same interoperability capabilities, the choice of selecting and indeed moving to and from a cloud service provider becomes very much easier. What must be heeded by SDOs is to enable specifications that are easily extendable and that those extensions are easily discovered at runtime. If this is not adhered to by SDOs then provider uptake will be low given that differentiation by price may not be something all providers can compete on. Where they all can is on product differentiation and so SDOs must account for this. Interoperability can only but foster further cloud market place competition.
• Reduced Cost: Interoperability brings with it standardised interfaces and with these, common tools appear. With these tools cognitive and technical complexity is reduced and the number of tools once required to support multiple cloud services of the same type are consolidated. This all goes to reducing technical tooling and education costs.
• Increased Business Agility: Interoperability allows businesses integrate their systems and supporting infrastructures quicker and faster and is a resultant property of increased portability and easier integration through well-known and understood concepts and interfaces.

As of today there are movements under way to tackle the challenge of cloud interoperability. At international levels the efforts of the US NIST initiative and the EU SIENA initiative are leading examples of both research and industry collaborating on this topic. From the view of SDOs, those most active to date are the DMTF, OGF, SNIA and IEEE, where each have a particular study lens on to the area of cloud computing, yet are collaborating together so that they can ensure that they integrate with each other. Within the European Union Framework Programme there are a number of projects seeking to address various aspects within cloud interoperability such as SAIL, GEYSERS, SLA@SOI, RESERVOIR, 4caast and Contrail.

Background: For a period of months, SLA@SOI and RESERVOIR have been collaborating with a goal of architectural and technical integration. Both SLA@SOI and RESERVOIR are each multi-million Euro funded projects under the European Framework Programme 7.

Collaboration activities need communication and commonly agreed structures put in place. From a management view, we, the collaborators, established such elements early in our efforts and this helped us greatly. However, what we then needed was to have complimentary and requisite collaboration from the technical view. This meant having a common and agreed means to communicate technical syntax and semantics between both SLA@SOI and RESERVOIR’s infrastructural layers. These means were supplied to our efforts in the fashion of the Open Cloud Computing Interface (OCCI) [1] specification. It was established early on that the OCCI specification would be a suitable baseline to cater for the horizontal integration of SLA@SOI and RESERVOIR’s infrastructural service layers and hence frame our collaboration at a technical level.

The Open Cloud Computing Interface (OCCI) is a working group formed within the Open Grid Forum [2]. The motivation for initiating this group was the lack of any open standard for the Infrastructure as a Service (IaaS) model-based clouds. The open standardisation process is driven by the following motives:

• Interoperability: the ability to enable different systems integrate with each other. This is an absolute in use cases related to the Intercloud, where two distinctly separate and independent IaaS provider work and orchestrate seamlessly from a customer perspective.
• Portability: the need for easy code reuse in end-user application like cloud clients or portals. Enabling this allows migration from on IaaS to another with minimal impact upon the customer. Where migration through portability is provided and hence lock-in is a non-issue, this focuses the provider on offering compelling and attractive services, which due to the almost commodity-like nature of IaaS often implies competitiveness through lowering of service costs.
• Integration: the idea of “wiring up” IaaS with not only current and modern provider offerings but also to legacy resources and services.

With the focus of providing standardised interfaces to IaaS, the OCCI group defines a RESTful [3] protocol. The goal is to create a simple and elegant interface, which can be easily extended by 3rd parties, and the RESTful approach supports this.

OCCI is a boundary protocol/API that acts as a service front-end to an IaaS provider’s internal infrastructure management framework. It is OCCI that provides for commonly understood semantics and syntax in the domain of customer-to-provider infrastructure management. More so, OCCI is focused on the management of infrastructure hosted in the cloud, in effect, utility computing. The following diagram shows OCCI’s place in the communications chain:

To give this view further context within the collaboration, below we show how RESERVOIR and SLA@SOI would both, quite naturally, integrate together using OCCI as their means for IaaS interoperability.

Further details of this particular integration study were made available in the joint technical report [4].

Open Architectural Issues & Proposed Solutions

As OCCI was identified early as the interface specification that each project would implement, it was not particularly difficult to integrate architecturally. From our review of OCCI, there were a number of issues that might hamper this effort. There were questions raised regarding the suitability of using HTTP headers as a means to transfer serialised data over the network. Where as HTTP headers are a reasonable place to transmit data that has a small payload, inserting data here that has a large payload is not practical. Typically, the most common data that is transferred to OCCI clients are collections of VM representations. This is currently being addressed by the OCCI group.

Also there has been demand for alternative serialisation formats, other than HTTP headers. The OCCI working group is also now investigating and aim to specify how to represent the OCCI model as RDFa [10] within XHTML documents. This would then allow OCCI serialisations rendered within a web browser. An advantage of exposing the attributes and relationships of OCCI managed resources through RDFa is that not only can a web browser consume and display the content but programmatic clients that can extract RDFa [11] can be used to reliably extract data to perform automated tasks and not be subject to issues associated with screen-scraping. A consequence of supporting RDFa is that the OCCI model must be reified as a RDF [12] ontology in order to support and validate RDFa declarations within a XHTML document. By defining a RDF ontology this too adds huge possibilities to the OCCI standard by not only providing a serialisation format that can support a richer and more extensible but could potentially further the cause of linked data and the semantic web.

From our collaboration work, it was found that an area that OCCI does not currently address is atomic, multiple resource provisionings. This means that with the current OCCI specification, it is only possible to provision one resource per request. For some use cases this is not sufficient, as they require that multiple resources be successfully provisioned through one request or not at all. The interim solution used by RESERVOIR was to utilise the Open Virtualisation Format (OVF) [13] specification to express many resources within one request. This work is an example of how other open specifications can be integrated within the OCCI specification. In reference to the previously mentioned OCCI developments, a RDF serialisation, indeed RDFa, format could support and solve this current limitation within OCCI as RDF easily supports multiple resources per request due to its XML heritage.

In order for any provider to be SLA-enabled by SLA@SOI, that provider should ideally offer a means to monitor each service provisioned by its systems. In this case, the provider would offer a monitoring service in parallel to it’s service offering. The exclusion of monitoring considerations in the OCCI specification was found to be an issue when SLA-enabling infrastructural services that implemented the OCCI specification. Although OCCI does not currently offer a means to perform monitoring, other than periodic pull requests to retrieve individual resource metrics, OCCI does not preclude other monitoring specification being used. It is at this point where the two projects, as currently implemented, diverge and so to allow for seamless inter-operable SLA management across the two projects requires that both projects select, just as was done for IaaS management, a standard or common specification for monitoring. Within SLA@SOI, interacting with a service manager is currently performed using access to messaging bus powered by the open standard XMPP [14]. Within, RESERVOIR monitoring information is accessed using the TCloud monitoring API [15]. If the two projects are ever to be interoperable from an SLA management perspective, through horizontal integration then this difference in monitoring approaches needs to be addressed. The suggestion from the horizontal integration working group is two-fold. First, select an API-based monitoring specification that allows asynchronous notifications pushed from the provider. Second, from the learning of implementing the selected API, contribute back to the OCCI working group a compatible specification for an OCCI monitoring extension.

As already noted, a number of OCCI implementations are being actively developed. Once implementations are ready for consumption, it would be appropriate firstly nominate reference implementations and secondly, with those agreed reference implementation perform interoperability tests and report on the results.

Completed Work

Resulting from the collaboration activity, a number of outputs both completed and on going were achieved. A joint technical report entitled “Using Cloud Standards for Interoperability of Cloud Frameworks” [4] was published. This introduced the two collaborating projects, OCCI and outlined a basic use case along with architecture on how the two projects can interoperate.

As RESERVOIR and SLA@SOI had vested interests in OCCI, this resulted in each project producing their own implementation of the OCCI specification. SLA@SOI has an infrastructure service manager, which allows the provisioning of infrastructural services atop its chosen provisioning system, Tashi [5]. RESERVOIR also has exposed OCCI interfaces both at the Service Manager level, through the Claudia project’s [6] implementation and the VEEM level, through the OpenNebula [7] implementation. This potentially allows OCCI interoperation at not only in a horizontal fashion but also, in the context of RESERVOIR’s architecture, a vertical fashion.

As each project worked independently on their implementation of OCCI but still with OCCI as the vehicle of collaboration this resulted in each project supplying feedback to the specification. To date this is largely captured in the section on open architectural issues. It should also be noted that there is another implementation of OCCI in use currently. This implementation belongs to the Istituto Nazionale di Fisica Nucleare (INFN) [8] and was presented at OGF28 [9].

Conclusions

By selecting standardised and commonly agreed interfaces, the integration of both architecture and technology was vastly expedited and simplified and reflects the benefits of standardisation. The use of standards as a tool for rapid and productive collaborations between large projects; be they EU-funded or commercial, cannot be understated. Standards allow for everyone to share a common baseline of functionality and level what would be otherwise an uneven, jagged technology landscape where vast amounts of time, funding and resources are spent just for basic communications to be achieved. With everyone sharing a common baseline of functionality, further functionality can be built upon that, for example in the case of IaaS, Interclouds of IaaS. IaaS cloud brokers with fail over intelligence can be rapidly developed. The horizontal integration working group provided good examples of how to quickly deal with deficiencies in specifications by not re-inventing the wheel, but rather, reusing existing standards e.g. OVF, TCloud. In general, this work showed that it is possible to let two large Cloud-oriented frameworks interoperate even with vastly different architectures and goals. This has the result of paving the way for possible proof of concept demonstrators that have functionality that is greater than the sum of its parts.
[1] Open Cloud Computing Interface working group website http://www.occi-wg.org
[2] Open Grid Forum http://www.ogf.org
[3] Fielding, R.T.: Architectural Styles and the Design of Network-based Software Architectures, Doctoral dissertation, University of California, Irvine (2000)
[4] Thijs Metsch, Andy Edmonds, Victor Bayon: “Using Cloud Standards for Interoperability of Cloud Frameworks”, http://sla-at-soi.eu/wp-content/uploads/2010/04/RESERVOIR-SLA@SOI-interop-techReport.pdf
[5] Apache Tashi website, http://incubator.apache.org/tashi
[6] The Claudia Platform website, http://claudia.morfeo-project.org
[7] OpenNebula website http://opennebula.org
[8] Istituto Nazionale di Fisica Nucleare website, http://www.infn.it
[9] Michele Orru, Developing Cloud Applications with OCCI, http://www.ogf.org/OGF28/materials/1914/DevelopingCloudapplicationswithOCCI-MicheleOrru-OGF28.pdf
[10] RDFa in XHTML: Syntax and Processing, http://www.w3.org/TR/rdfa-syntax
[11] PyRdfa: RDFa Distiller and Parser, http://www.w3.org/2007/08/pyRdfa/#distill_by_uri
[12] Resource Description Framework (RDF): Concepts and Abstract Syntax, http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/
[13] Open Virtualisation Format, http://www.dmtf.org/standards/published_documents/DSP0243_1.0.0.pdf

The pace of development within the OCCI community has been excitedly ever increasing over the past few months. It’s not only been so within the group of people defining the specification but also in the many groups of people and projects implementing OCCI. In our last blog post we mentioned that Eucalyptus will soon have an implementation of OCCI from the good work David Wallom and his FleSSR team in Oxford are doing. In the post we also hinted at something related to OCCI and OpenStack.

As you might be aware, OpenStack is one of the most exciting and vibrant open source Cloud activities on going currently. The OCCI working group has been engaged with OpenStack over the past 3 months with the aim of contributing an implementation of OCCI and we’re happy to say that this will happen with the “Bexar” release of OpenStack. Incidentally, that’s synchronised with the release schedule of Ubuntu 11.04. the You can see the OCCI blueprint on the OpenStack site, which will serve a point of communication for the implementation work.

Not only will OpenStack receive an implementation of OCCI but one of the mainstays of infrastructure management frameworks, libvirt, will also have an implementation of OCCI. This work is being carried out by a team lead by one OCCI community member, Alexander Papaspyrou from TU Dortmund University, Germany.

Platform Computing will provide an OCCI implementation for a German Research Project, DGSI, which allows developers to easily extend their existing applications with an OCCI compliant RESTful interface (RESTify your apps).

Given that OCCI is also implemented in OpenNebula and Apache Tashi (via the SLA@SOI implementation) amongst others (we’re running out of space for this post!), OCCI is fast becoming the API that can provide interoperability between the major Open Source infrastructure management frameworks.

As ever, the OCCI group is always hugely enthusiastic, welcoming and very supportive to people and groups of all types wishing to get involved with OCCI, whether that is through specification contributions or new implementations of it. Curious? Then head on over to IRC (irc.freenode.net #occi), drop a mail on the mailing list or ping some of us on twitter (@dizz, @befreax, @monadic, @papaspyrou).

Stay tuned for more news on OCCI and more implementations of it!

So yes we’ve been quiet but as they say “still waters run deep”. We in OCCI have been deep and active on everything from refining the Core model down through the infrastructure specification and out through the HTTP rendering specification document and, well, things couldn’t be healthier! Following an superb half-week at OGF30 there’s even more great OCCI-related news to share. Coming into OGF30, I was aware of seven OCCI implementations and coming away I knew of twelve! Most notable of those 12 is Eucalyptus who will soon have an implementation through the good work David Wallom and his team in Oxford are doing. You might have noticed a new logo (above) too contributed by Sam You might have also seen the various OCCI articles in the latest ERCIM news and if not go check it out! And there is more, especially in areas related to OpenStack, we’re only dying to share with the community but, soon, very soon you’ll know more!

Much of this work in advocating the adoption and support of OCCI has been carried out by our tireless co-chairs; Thijs, Alexis and I, as well superb support from many people within OGF including Craig Lee (OGF president) and Alan Sill (VP of Standards).

So what was I doing at OGF30 other than working hard and having great fun at the same time with the OCCI guys? Well I presented on the work we’re doing in SLA@SOI. I presented on “Standards-based, SLA-enabled Infrastructure Management”. You can check the presentation out here and I must apologies to those present if I bombarded you with architecture. At least I showed a real live demo! The live demo showed a number of SLA-guaranteed services all managed by OCCI. Incidentally, the OCCI implementation used is open source (BSD) and available on sourceforge. For those not present there’s some screen grabs at the end of the presentation. It’s implemented in the awesome Grails so if you’re interested, take a wander over there. Some interesting pieces coming from SLA@SOI related to OCCI include; a jClouds OCCI implementation, OCCI extensions on Advanced Scheduling and Monitoring.

So if you want to check out what’s going on in OCCI for yourself, why not have a look through the wiki, svn (it’s latex but you can build it ). Come over to IRC (iric.freenode.net #occi). There’s always an OCCI person or more hanging out there and ready to talk.

Finally, as if that wasn’t enough, there was a very interesting DCI-Fed session held where we discussed various use-cases. DCI-Fed (mailing list, wiki) , from a Cloud Computing perspective, is really interesting and exciting. It looks into how various different Cloud Computing providers can interoperate to provide federated services to their clients. Certainly the future!

Courtesy of Victor: “In the UK Computer museum, an ICL 2900 series (mainframe class, mid 70′s). They said that they had these displays to show customers that their computer were doing 4 things at the same time (P1…P4) and still have some juice left.”

• MenuEclipse – kills off any distracting trace of the Mac OS X menu bar.
• Isolator – Only allows one application run in the desktop foreground. All other applications take a back seat and the desktop is kept hidden.

What’s LTE Advanced?

• 3GPP Release 8 is what is known as Long Term Evolution (LTE). Release 10 is LTE Advanced (3GPP) and is the same as IMT Advanced (ITU).
• Backward compatible with Release 8.
• LTE Advanced satisfies ITU basic requirements and also introduces additional features.
• WiMax2 + LTE Advanced are very similar (I wonder how similar at the low level though?!).
• IMT Advanced is for 4G as IMT-2000 was for 3G.
• IMT Advanced deals only with the radio access network (RAN).
• Differences in spectrum.
• Specification to be released in early 2011.
• All aspects within are large areas. Up to 600 papers submitted in some topic areas.
• ITU to recommend specification, 3GPP to release in parallel all in early 2011.
• “Faster” – there’s lots of increased MHz rates.
• Target deployment example – micro-cellular (“urban micro”).
• General Arch: LTE terminal -> LTE radio access network -> SAE CN (?) -> ISP.
• Release 11 will enhance release 10.
• Release 12 – content open. This is where research-oriented input is required. Example: UE-2-UE (device) communications using network operator resources.
• QoS is sufficient in release 8 for release 10.
• My opinion – Seems to be a want to push carrier technology down into the home from the network (e.g. replace WiFi, with network as a service). You don’t own the equipment network operator does. Network operator has total control. Tiered network rears its head.

Select Discussed LTE Advanced Features

During the talk various features of LTE Advanced were highlighted. Here are some of them that had my ears pricked-up…

Carrier Aggregation

• Very cool. Virtual Carriers created on the fly. Something that was needed on a previous FP7 proposal related to the intersection of cloud computing and mobile networks.
• Compose concurrent carriers of differing bandwidths, no hand-overs needed as in the case of Release 8.
• Aggregation schemes intra-band and inter-band aka spectrum aggregation.
• Applicable to uplink and downlink – asymmetric.
• Cell symmetric but also per UE asymmetric.
• Dynamic allocation of bandwidth QoS.

Enhanced MIMO

• Interesting: access to multiple distributed APs from one UE and coordination.
• Problem: power, more connections to APs more power usage. Example of 3G power usage given (uses MIMO).

HetNet: Enhanced support for heterogeneous networks

• Mix of base stations – femto, pico, macro.
• Originally had hierarchical cell sys (HCS) but is unattractive from regulatory point of view in the case of dense cell structure.
• HetNet can give dense infrastructure.
• Heterogeneity by power output, not necessarily in specification uniformity (appears interoperability is not dealt with?).
• Closed subscriber group – similar to WiFi access point – related to access rights.
• Problem today is there’s not enough uplink in networks – solve perhaps with more pico in a HetNet deployment scenario.