Intercloud Architecture Framework for Interoperability,
Federation and Management
Yuri Demchenko, Rudolf Strijkers, Marc X. Makkes, Canh Ngo, Cees de Laat
Intercloud Infrastructure/Services Provisioning

User/Customer Side Functions and Resources

1Access/Delivery
Infrastructure

Endpoint Functions* Service Gateway* Portal/Desktop

Layer C6
User/Customer
side Functions

Administration andManagement Functions(Client)

Content/Data Services* Data * Content * Sensor * Device

Security InfrastructureManagement

User/Client Services* Identity services* Visualisation

Operations Support System(General use case: Enterprise/Scientific Workflow deployment onheterogeneous cloud infrastructure)

Multi-layer Cloud Service Model (CSM)

Layer C5
Services
Access/Delivery

Inter-cloud Functions* Registry and Discovery* Federation Infrastructure

Layer C4Cloud Services(Infrastructure,Platforms,Applications,Software)

Cloud Services (Infrastructure, Platform, Application, Software)
IaaS

SaaS

PaaS

PaaS-IaaS IF
PaaS-IaaS Interface
IaaS – Virtualisation Platform Interface

Cloud Management
Software(Functional Definition Proposed)

Cloud Management Platforms
OpenStack

OpenNebula

KVM

Virtualisation Platform

VM

VM

Layer C3
Virtual Resources
Composition andControl(Orchestration)

VPN

OtherCMS

XEN

Layer C2Virtualisation

NetworkVirtualis

VMwareLayer C1
PhysicalHardwarePlatform andNetwork

Proxy (adaptors/containers) - Component Services and Resources
StorageResources

Hardware/PhysicalResources

ComputeResources

Contrl&Mngnt Links

NetworkInfrastructure

Data Links

Cloud Services Model Layers

General requirements to Intercloud Architecture Framework (ICAF)• ICA should address the interoperability and integration issues in the current and emerging
heterogeneous multi-domain and multi-provider clouds, in particular:• ICA should support communication between cloud applications and services belonging todifferent service layers (vertical integration), between cloud domains and heterogeneous
platforms (horizontal integration).
• ICA should provide a possibility that applications could control infrastructure and related
supporting services at different service layers to achieve run-time optimization (Intercloudcontrol and management functions).
• ICA should support cloud services/infrastructures provisioning on-demand and their lifecycle
management, including composition, deployment, operation, and monitoring, involving
resources and services from multiple providers.

Layer C1 - Physical platform (PC hardware, network, and network infrastructure)
Layer C2 - Cloud virtualisation layer (e.g. VMware, Xen, KVM or Hyper-V virtualisation platforms)
Layer C3 - Cloud virtual resources composition and orchestration layer that is represented by the Cloud
Management Software (such as OpenNebula, OpenStack, or others)
Layer C4 - Cloud services layer that may include different type of cloud services IaaS, PaaS, SaaS
Layer C5- Access/Delivery infrastructure hosting components and functions to provide access to cloudservices/resources and interconnect multiple cloud domains
Layer C6 - User/customer side resources and services
CSM is compatible with the NIST Cloud Computing Reference Architecture (CCRA, NIST SP 800282), ITU-T FG-Cloud Cloud Reference Model and IETF I-Draft Cloud Reference Framework

General Model and Actors in (Inter)Cloud Federations(a) EnterpriseInfrastructure• Multilayer Cloud Services Model (CSM) for vertical cloud services interaction, integration andcompatibility that defines both relations between cloud service models (such as IaaS, PaaS, SaaS) andother required functional layers and components of the general cloud based services infrastructure.

UserUser2Management(Ops&Sec)• Intercloud Federation Framework (ICFF) to allow independent clouds and related infrastructure

Cloud
Provider A

Basic Use Cases for Intercloud Interoperability and Integration
Use Case 1: Enterprise IT infrastructure migration to cloud and its evolution• Integration of the cloud based components and legacy infrastructure• Evolution from general cloud infrastructure services to specialised proprietary cloud platform services
Use Case 2: Large project-oriented scientific infrastructures including dedicated transport network
infrastructure that need to be provisioned on-demand
Use Case 3: IT infrastructure disaster recovery that should include both data and supporting infrastructure
backup and recovery on possibly new computer/cloud platform

Related links
Intercloud Architecture Framework for Interoperability and Integration, Draft version 0.6, 15 Feb 2013. SNE Technical Report.
http://staff.science.uva.nl/~demch/worksinprogress/sne2012-techreport-12-05-intercloud-architecture-draft06.pdf
Cloud Reference Framework. Internet-Draft, version 0.4, December 27, 2012.
http://www.ietf.org/id/draft-khasnabish-cloud-reference-framework-04.txt
On-Demand Infrastructure Services Provisioning Best Practices, Version 1.3, 15 February 2013 (OGF ISOD-RG Deliverable)
https://forge.ogf.org/sf/docman/do/downloadDocument/projects.isod-rg/docman.root.drafts/doc16538
NIST SP 500-292, Cloud Computing Reference Architecture, v1.0.
http://collaborate.nist.gov/twiki-cloud-computing/pub/CloudComputing/ReferenceArchitectureTaxonomy/
NIST_SP_500-292_-_090611.pdf

Instantiated
IDP-A => IDP-Xa

UserUser
UserX
Xa.2Xa.1 a.3
IDP-XaCloud
Service Xa

CSP IDPA

Rsr
An1

Rsr
Am1

User sidefederation

Federation &Trust relations

Provider sidefederation

Inter-provider federation for resources sharing• Intercloud Operation Framework (ICOF) includes functionalities to support multi-provider
infrastructure operation including business workflow, SLA management, accounting. ICOF defines thebasic roles, actors and their relations in sense of resources operation, management and ownership.
ICOF requires support from and interacts with both ICCMP and ICFF.

Federation relations

Rsr
Ak2 Rsr
Ak1

components federation of independently managed cloud based infrastructure components belonging todifferent cloud providers and/or administrative domains; this should support federation at the level ofservices, business applications, semantics, and namespaces, assuming necessary gateway orfederation services.

(a) IDP-HO1(b) 3rd Party
IDPDirect or Dynamic link• Intercloud Control and Management Plane (ICCMP) for Intercloud applications/infrastructure
control and management, including inter-applications signaling, synchronization and session
management, configuration, monitoring, run time infrastructure optimization including VM migration,
resources scaling, and jobs/objects routing.

User3
User
User1

(a) HO or(b) Custmr1
MgntSystem

The Intercloud Architecture Framework components(b) External Users
User (Open Internet)

Rsr
K2

Rsr
Kn1
Cloud
Provider K

Rsr
IDP-K
M2

Rsr
N1

Rsr
M1
IDP-M

Cloud
Provider M

Main Actors in Cloud/Intercloud Federation• Cloud Service Provider (CSP) is an entity providing
cloud based services to customers, on their request
and based on the business agreement or SLA, withhigh degree of self-service and self-management• Customer is an entity that requests, creates, deploys
and manages cloud based services• User or consumer is an end-user consuming cloud
based services

Rsr
N2IDP-N
Cloud
Provider N• Cloud Broker is an entity that plays a role of thethird party in offering cloud service, adding value ofnegotiating with CSPs, optionally operating complexmulti-provider services• Identity Provider (IDP) is an entity providing
information about identities of all actors in cloudservices provisioning,• IDP-HO – by User Home Organisation• IDP-CSP by Cloud Service Provider

Contributing Projects
GEYSERS – Generalised Architecture for Infrastructure services - http://www.geysers.eu/
GEANT3 JRA3 Task 3 – Composable services (GEMBus) - http://www.geant.net/
COMMIT Project - http://www.commit-nl.nl/

Credits: Yuri Demchenko, Rudolf Strijkers, Marc X. Makkes, Canh Ngo, Cees de Laat
Contact: Yuri Demchenko <y.demchenko@uva.nl>