Category: Research Approach (page 3 of 4)


Equinix: Global Data Centers that Protect, Connect and Power the Digital Economy


How can we ensure the vitality of the digital economy? This is the question Equinix’s founders asked in 1998 when the Web was revolutionizing information-sharing between businesses.

Their answer was to offer businesses a place to reliably run and grow their operations and securely exchange critical information – and this is exactly what Equinix continues to do today.

We do this by building and operating large-scale data centers around the world that offer the highest levels of reliability and security and, more importantly, give major networks and businesses a place to interconnect. This growing community of customers – spanning networks, enterprises, financial companies, technology service providers, digital media, social media and cloud applications – forms a thriving information ecosystem. We call this Platform EquinixTM.

Platform Equinix delivers:

  • A global footprint of International Business Exchange™ (IBX®) data centers in 31 major business markets across 15 countries and 5 continents
  • Access to more than 900 public and private networks to optimize service performance and reduce latency
  • Specialized exchanges for Internet, Ethernet and mobility
  • On-demand access to the space, power and network connectivity needed to scale cloud services and IT services and grow revenue streams
  • Facilities designed to support the requirements of high-density computing
  • Direct access to a complete cloud services ecosystem for rapid integration of services, technologies and customer opportunities, including more than 300 cloud and 500 IT service providers
  • Access to the Equinix Marketplace to market services to more than 4,000 enterprises and financial, network and content companies

Equinix is constantly evolving and seeks to act upon industry trends that will significantly impact the businesses of our customers. At the foundation of this effort is the Equinix Promise, which starts with a common purpose: to protect, connect and power the digital economy inspired by our dream that Equinix will be the interconnection point for the world’s leading businesses.

As the company looks forward into 2013 and beyond, we will continue to dedicate ourselves to help power the digital economy. This means that we will:

  • Constantly strive to evolve, cultivate and share our industry insights with our customers;
  • Seek opportunities to continue to expand in key markets;
  • Act upon industry trends that will affect our business and the businesses of our customers.



CloudSigma: Innovative Infrastructure-as-a-Service (IaaS) through high availability, flexible cloud servers and cloud hosting Europe and the US.

CloudSigma is an highly innovative Infrastructure-as-a-Service (IaaS) provider based in Zurich, Switzerland. CloudSigma was founded to meet the growing need for a pure IaaS that places little or no restrictions on how its users deploy their computing resources. CloudSigma has been chosen as one of the top 25 European cloud companies for 2010.

The founders of CloudSigma were frustrated with the current market offerings which required users to jump through hoops to migrate their current server setups to the cloud. Further, many other IaaS offerings placed restrictions on the operating systems that could be used, the size of servers available and more; servers that disappear when stopped, storage that wasn’t persistent etc. The CloudSigma product was developed to directly address these issues.

“We are 100% focused on delivering world class computing performance and service to our customers in a flexible and straightforward manner. Choosing CloudSigma as your cloud hosting partner means choosing a company that genuinely cares about its working relationships. We view our role very much a partnership, providing a solid foundation on which our customers build out their computing infrastructure and businesses over time. Having a valued partner who understands your business and is able to assist and support when needed is critical.”

Above all, CloudSigma aims to make its service accessible to all. Very technical users will find the full featured API easy to use and automate along with the greater freedom our system affords them. Less technically inclined users will find the web interface intuitive and the CloudSigma community an invaluable resource in exploring cloud computing further.

The founders of CloudSigma chose Switzerland as a location due to the following key advantages:

  • Excellent networking connectivity to all of Europe and the rest of the world
  • One of the world’s most reliable and clean electricity grids (95% green electrical generation)
  • A highly developed and respected legal framework for privacy and data protection
  • A multi-lingual local environment
  • Zurich as a vibrant and rapidly growing technology hub

The CloudSigma cloud is housed in the Interxion data centre in Glattbrugg near Zurich. Interxion’s data centre is the carrier neutral location of choice for high end data hosting in Switzerland. CloudSigma’s headquarters are located at the Interxion data centre also enabling our engineers to gain immediate physical access to our cloud. If you have an idea or product suggestions just drop an email to

CloudSigma is the trading name and registered trademark of CLOUDSIGMA AG, a company incorporated in the canton of Zurich, Switzerland. The software used as part of the CloudSigma product was developed during the course of 2008 and early 2009. CLOUDSIGMA AG was incorporated in late 2009 to bring the product to market.

PaaS on OpenStack


In this initiative we focus on bringing Platform as a Service (PaaS) to the ICCLab testbed, on top of OpenStack. We are investigating and evaluating all the requirements for running various open source PaaS solutions like Cloud Foundry (, OpenShift ( and Cloudify ( and extend the testbed for monitoring, rating, charging and billing on PaaS level.

Plattform as a Service (PaaS) is focusing on developers as customers by providing them a platform containing the whole technology stack to run applications and services supporting all the typical cloud characteristics like On-Demand Self-Service, Rapid Elasticity, Measured Service, Resource Pooling etc.  Typically these platforms consist of:

  • Runtime environments (Java, Ruby, Python, NodeJs, .Net, …),
  • Frameworks (Spring, JEE, Rails, Django, … ) and
  • Services like
    • Datastores (SQL, NoSQL, Key-Value-Stores, File-/Object-Storage,…),
    • Messaging (Queuing, PubSub, EventProcessing,…)
    • Management Services (authentication, logging, monitoring,…)

Our full PaaS (mid-longterm) mission is described in the PaaS research theme page

Problem Statement

PaaS technologies and offerings are still in early stages. Lot of hype and movement in the market. Standards are not yet established. Lots of the open source tools like CloudFoundry and OpenShift are still in beta stages and not mature. Moving the responsibility for the operation of runtimes, frameworks and services to the cloud provider creates many new challenges. First of all the deployment and operation has to be totally automated and tooling for operation and management is needed. New parameters for monitoring and rating are required and new charging models to be developed and evaluated.  Other challenges are the automated interfacing with the underlying infrastructure layer (in our case OpenStack), to provide and guarantee the requested performance and scalability. Last but not least we have to investigate how to extend the frameworks with new services and runtimes.

Articles and Info

There are a number of presentations about PaaS in general and CloudFoundry/BOSH specifically used in the ICCLab:

Contact Point

Cloud Performance


Virtualisation is at the core of Cloud Computing and therefore its performance are crucial to be able to deliver a top-of-the-class service. Also, being able to provide the adequate virtualised environment based on the user requirements is key for cloud providers.

SmartOS, a descendant of Illumos and OpenSolaris, presents features such as containers and KVM virtualisation and network virtualisation through Crossbow that makes it particularly interesting in this context.

This research initiative aims to:

  • Evaluate performance of SmartOS virtualisation in respect to compute, i.e. containers and KVM, storage and networking
  • Compare SmartOS virtualisation with other techniques (Linux KVM, VMware, Xen)
  • Identify use cases and workloads that best suits the different techniques

Problem Statement

Cloud providers must be able to offer a single server to multiple users without them noticing that that they are the only user of that machine. This means that the underlying operating system must be able to provision and deprovision, i.e. create and destroy, virtual machines in a very fast seamless way; it should also allocate physical resources efficiently and fairly amongst the users and should be able to support multithreaded and multi-processor hardware. Lastly, the operating system must be highly reliable and, in case something doesn’t work as it should, it must provide a way to quickly determine what the cause is. at the same time, a customer of the cloud provider will also expect the server to be fast, meaning that the observed latency should be minimal. The provided server should also give the flexibility to get extra power when needed, i.e. bursting and scaling – and be secure, meaning that neighboring users must not interfere with each other.

Articles and Info

Contact Point

Cloud Monitoring


A monitoring system especially in a Infrastructure as a Service environment should be considered indispensable and required. Knowing which resources are used by which Virtual Machines (and tenants) is crucial for cloud computing providers as well for their customers.

Customers want to be sure they get what they pay for at any time whereas the cloud provider needs the information for his billing and rating system. Furthermore this information can be useful when it comes to dimension and scalability questions.

For monitoring a Cloud environment there are different requirements:

  • An Cloud monitoring tool must be able to monitor not only physical machines but also virtual machines or network devices.
  • The information of the monitored resources must be assignable to its tenant.
  • The metered values must be collected and correlated automatically
  • The monitoring tool must be as generic as possible to ensure support of any device.
  • The monitoring tool must offer an API.

Problem Statement

Many of the available monitoring tools allows to collect data from particular devices such as physical devices or virtual machines. However, most of these tools don’t monitor newly created instances of a Cloud environment automatically. For this reason the ICCLab decided to use Ceilometer to monitor their OpenStack installation. Ceilometer is a core project of OpenStack but doesn’t collect data from physical devices like network switches. Therefore, the ICCLab extends Ceilometer to allow it to collect data from physical devices.

Articles and Info

Contact Point

Cloud Automation & Orchestration


At the heart of the ICCLab is the Management Server, which provides an easy way to stage different setups for different OpenStack instances (productive, experimental, etc.). The Management Server provides a DHCP, PXE and pre-configured processes which allow a bare metal computing unit to be provisioned automatically, using Foreman, and then have preassigned roles installed, using a combination of Foreman and Puppet. This provides a great deal of flexibility and support for different usage scenarios. Puppet is a key enabler. Puppet is an infrastructure automation system for the efficient management of large scale infrastructures. Using a declarative approach puppet can manage infrastructure lifecycles from provisioning, configuration, update and compliance management. All of these management capabilities are managed logically in a centralised fashion, however the system itself can be implemented in a distributed manner. A key motivation in using puppet is that all system configuration is codified using puppet’s declarative language. This enables the sharing of “infrastructure as code” not only through out an organisation but outside of an organisation by following open source models.

Problem Statement

With the infinite resources available today through cloud computing it is very possible to have large numbers of cloud resources (e.g. compute, storage, networking) delivering services to end users. Managing these cloud resources and the software stacks deploy on top is a huge challenge when the number of resources to configure and mange increase beyond single digits. The only way forward here is to investigate, adopt, improve automated management, configuration and orchestration tools. With automation comes increased testability, reliability (when done right) and ultimately faster times to market as exemplified by continuous integration and DevOps practices.

Articles and Info

There are a number of blog posts detailing how foreman and puppet are used in the ICCLab:

Contact Point

Cloud Interoperability


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 bring 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, 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:

  • Standardised specifications for the import and export of virtualised infrastructure service instances
  • Standardised runtime specification to allow the run-time and life cycle management of virtualised infrastructure service instances
  • Standardised data access, import and export capabilities to the data that created and was generated by the virtualised service instances

Problem Statement

There are many challenges to cloud computing but one core to enabling further value is the removal of lock-in and enabling of interoperability between cloud services. Typical approaches to providing interoperability include setting standards through standards defining organisations such as DMTF, OGF, SNIA. The other approach is providing software tool kits and frameworks such as jClouds, Apache libcloud and that provide abstract programmatic APIs who’s implementation carries out the semantic and syntactical mapping from the abstract interface to the target cloud service provider’s interface. Where as both approaches provide some uniformity to operating with cloud services, they do not cover other life cycle aspects. One area of investigation within the ICCLab is how to relocate services using one of the two (or potentially both).

Articles and Info

Contact Point

Andy Edmonds

Academic Services

The members of ICCLab and SPLab are actively contributing to the academic cloud computing and service-oriented application communities to stay at the forefront of technology. The following list contains some of the community services and involvements.

Editorial Boards

Professional Service

  • Program Committee Chair and Tutorials Chair, IEEE/ACM International Conference on Utility and Cloud Computing (IEEE/ACM UCC 2016)
  • Workshops Chair, IEEE Symposium on Service-Oriented System Engineering (IEEE SOSE 2016)
  • Workshops Chair, IEEE/ACM International Conference on Utility and Cloud Computing (IEEE/ACM UCC 2015)
  • Workshops Chair, IEEE International Conference on Communications (IEEE ICC 2013)
  • General Chair, 2nd International Workshop on Data Center Performance (DCPerf 2012)
  • Symposium Chair, Int. ICST Conference on Communications Infrastructure, Systems and Applications in Europe (EuropeComm 2011)

Steering and Advisory Committees

  • Architecture and Steering Board Member of the European Future Internet Public-Private-Partnership (FI-PPP)
  • Steering Committee Member of the European Future Internet Public-Private-Partnership Technology Foundation (FI-WARE)
  • Steering Committee Member of the EU FP7 IP GEYSER project (GEYSER)
  • Steering Committee Member of the European Technology Platform (ETP) eMobility (eMobility), finished 2013
  • Advisory Board Member of the EU FP7 NOVI project (NOVI), finished 2013

Workshop Organization

  • International Workshop on Cloud Robotics (IWCR’16), co-located with CLOSER 2016
  • First International Workshop on Cloud Native Applications Design and Experience (CNAX’16), co-located with IEEE SOSE 2016
  • International Workshop on Automated Incident Management in Cloud (AIMC’15), co-located with EuroSys’15
  • Cloud Automation, Intelligent Management and Scalability Workshop (CAIMS’14), co-located with IEEE/ACM UCC’14
  • 1st IEEE MobileCloud Networking Workshop, Budapest, Hungary, co-located with IEEE ICC 2013
IEEE Broadband Wireless Access Workshop Series

Reviewer Activities

Members of the ICCLab and SPLab are frequently serving as reviewers for renowned conferences and journals, e.g. CloudCom, CLOSER, NetSoft, UCC, FGCS, TCC and TPDS.


We here in the ICCLab are very much interested in all activities related to standardisation in the Cloud. Standardisation forms part of our overall strategy in bringing impact to the communities we take part in.


One of the standardisation activities on going in the ICCLab is our participation in the Open Cloud Computing Interface (OCCI). OCCI is a standardisation activity ran out of the Open Grid Forum. Briefly OCCI is:

a Protocol and API for all kinds of Management tasks. OCCI was originally initiated to create a remote management API for IaaS model based Services, allowing for the development of interoperable tools for common tasks including deployment, autonomic scaling and monitoring. It has since evolved into a flexible API with a strong focus on integration, portability, interoperability and innovation while still offering a high degree of extensibility. The current release of the Open Cloud Computing Interface is suitable to serve many other models in addition to IaaS, including e.g. PaaS and SaaS.

Apart from contributing to the OCCI specifications, the ICCLab is contributing to the OCCI implementation for OpenStack and it is with this implementation that we take part in the various Cloud Plugfest events, which “is a co-operative community project designed to promote interoperability efforts on cloud-based software, frameworks, and standards among vendors, products, projects and implementations“.

Open Source


Source: OpenStack Website

OpenStack is a cloud operating system that controls large pools of compute, storage, and networking resources throughout a datacenter, all managed through a dashboard that gives administrators control while empowering their users to provision resources through a web interface.

Learn more about OpenStack’s computestoragenetworking, or take a tour of the dashboard.

Who’s behind OpenStack?
Founded by Rackspace Hosting and NASA, OpenStack has grown to be a global software community of developers collaborating on a standard and massively scalable open source cloud operating system. Our mission is to enable any organization to create and offer cloud computing services running on standard hardware.

How can YOU take part?

The ICClab is coordinating the Swiss OpenStack user group. We will be running regular  for anyone with an interest in IaaS and PaaS to come along learn, participate and hopefully have some fun too!

ICCLab Contributions

The ICCLab contributes to the implementation of the OCCI API for OpenStack. This provides a python egg which can be easily deployed in OpenStack and will thereby add the 3rd party OCCI interface to OpenStack.

The ICCLab contributes to the OpenStack ceilometer project. The contribution made here is in providing monitoring metrics for physical host machines in an OpenStack deployment.

Many OpenStack puppet modules used to deploy and manage the ICCLab’s OpenStack testbed are also available. Those modules include:

Software Defined Networking


Ryu is a component-based software defined networking framework.


source: RYU Website Repository

contributors: Philipp Aeschlimann

Ryu provides software components with well defined API that make it easy for developers to create new network management and control applications. Ryu supports various protocols for managing network devices, such asOpenFlow, Netconf, OF-config, etc. About OpenFlow, Ryu supports fully 1.0, 1.2, 1.3 and Nicira Extensions.


NTT laboratories OSRG group started Ryu project and the members are actively involved in the development. Our aim is developing an Operating System for SDN that has high quality enough for use in large production environment.



The contributions by the ICCLab are in the general field of the OpenFlow Meter Modification messages as well as the OpenFlow Queuing messages. We are contributing in this field to the implementation of the OpenFlow protocol itself for the RYU-controller. RYU was with this contribution the first known controller that supports MeterModification messages for OpenFlow. All the contributions for RYU are in python.


The OpenFlow 1.3 software switch is built upon the Stanford OpenFlow 1.0 reference switch andEricsson’s Traffic Lab OpenFlow 1.1 switch and is intended for fast experimentation purposes.


source: CPqD Repository

contributors: Philipp Aeschlimann

OpenFlow has brought the opportunity to perform a wide range of new experiments in a network. Currently there is a good number of hardware switches to try OpenFlow, but most of them still implements only the version 1.0 of the protocol, lacking the new features from the most recent versions. So, in order to not have innovation dependent of hardware software switches are being deployed since the most primitive OpenFlow versions.


The ICCLab contributed minor Bug Fixes for the current implementation of the softswitch13.

« Older posts Newer posts »