GFD-P-R.

184 Thijs Metsch, Platform Computing

OCCI-WG Andy Edmonds, Intel
April 7, 2011
Errata Update: June 21, 2011

Open Cloud Computing Interface - Infrastructure

Status of this Document

This document provides information to the community regarding the specification of the Open Cloud Com-
puting Interface. Distribution is unlimited.
Copyright Notice
Copyright c Open Grid Forum (2009-2011). All Rights Reserved.
Trademarks
OCCI is a trademark of the Open Grid Forum.
Abstract
This document, part of a document series, produced by the OCCI working group within the Open Grid Forum
(OGF), provides a high-level definition of a Protocol and API. The document is based upon previously gathered
requirements and focuses on the scope of important capabilities required to support modern service offerings.
GFD-P-R.184 June 21, 2011

Contents
1 Introduction 3

2 Notational Conventions 3

3 Infrastructure 4
3.1 Compute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2 Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2.1 IPNetworking Mixin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3 Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.4 Linking Infrastructure Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.4.1 Linking to Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.4.2 Linking to Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.4.3 Linking to CDMI Managed Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.5 Infrastructure Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.5.1 OS Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.5.2 Resource Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4 Security Considerations 12

5 Glossary 13

6 Contributors 13

7 Intellectual Property Statement 15

8 Disclaimer 15

9 Full Copyright Notice 15

occi-wg@ogf.org 2
GFD-P-R.184 June 21, 2011

1 Introduction
The Open Cloud Computing Interface (OCCI) is a RESTful Protocol and API for all kinds of management
tasks. OCCI was originally initiated to create a remote management API for IaaS1 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 interoperability 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 PaaS and SaaS.
In order to be modular and extensible the current OCCI specification is released as a suite of complimentary
documents, which together form the complete specification. The documents are divided into three categories
consisting of the OCCI Core, the OCCI Renderings and the OCCI Extensions.

• The OCCI Core specification consists of a single document defining the OCCI Core Model. The OCCI
Core Model can be interacted with renderings (including associated behaviours) and expanded through
extensions.

• The OCCI Rendering specifications consist of multiple documents each describing a particular rendering
of the OCCI Core Model. Multiple renderings can interact with the same instance of the OCCI Core
Model and will automatically support any additions to the model which follow the extension rules defined
in OCCI Core.
• The OCCI Extension specifications consist of multiple documents each describing a particular extension
of the OCCI Core Model. The extension documents describe additions to the OCCI Core Model defined
within the OCCI specification suite. They do not require changes to the HTTP Rendering specifications
as of this version of the specification.

The current specification consists of three documents. This specification describes version 1.1 of OCCI. Future
releases of OCCI may include additional rendering and extension specifications. The documents of the current
OCCI specification suite are:

OCCI Core describes the formal definition of the the OCCI Core Model [1].

OCCI HTTP Rendering defines how to interact with the OCCI Core Model using the RESTful OCCI API
[2]. The document defines how the OCCI Core Model can be communicated and thus serialised using
the HTTP protocol.
OCCI Infrastructure contains the definition of the OCCI Infrastructure extension for the IaaS domain [3].
The document defines additional resource types, their attributes and the actions that can be taken on
each resource type.

OCCI makes an ideal interoperable boundary interface between the web and the internal resource management
system of infrastructure providers.

2 Notational Conventions
All these parts and the information within are mandatory for implementors (unless otherwise specified). The
key words ”MUST”, ”MUST NOT”, ”REQUIRED”, ”SHALL”, ”SHALL NOT”, ”SHOULD”, ”SHOULD
NOT”, ”RECOMMENDED”, ”MAY”, and ”OPTIONAL” in this document are to be interpreted as described
in RFC 2119 [4].
1 Infrastructure as a Service

occi-wg@ogf.org 3
GFD-P-R.184 June 21, 2011

3 Infrastructure
The OCCI Infrastructure document details how an OCCI implementation can model and implement an In-
frastructure as a Service API offering by utilising the OCCI Core Model. This API allows for the creation and
management of typical resources associated with an IaaS service, for example, creating a Compute instance
and Storage instance and then linking them with StorageLink. The main infrastructure types defined within
OCCI Infrastructure are:

Compute Information processing resources.

Network Interconnection resource and represents a L2 networking resource. This is complimented by the
IPNetwork Mixin.
Storage Information recording resources.

Supporting these Resource types are the following Link sub-types:

NetworkInterface connects a Compute instance to a Network instance. This complimented by an IPNet-

workInterface Mixin.
StorageLink connects a Compute instance to a Storage instance.

cd: Infrastructure

Resource Link
(from occi ::core ) target (from occi :: core )
+ summary :String [0..1 ] *

+ source
links

Network Storage NetworkInterface

+ occi.network.vlan :Integer [0..1 ] + occi.storage.size :int + occi.networkinterface.interface :String
Compute
+ occi.network.label :Token [0..1 ] + occi.storage.state :Enum + occi.networkinterface.mac :String
+ occi.network.state :Enum + occi.compute.architecture :Enum [0..1 ] + occi.networkinterface.state :Enum
+ occi.compute.cores :Integer [0..1 ]
+ occi.compute.hostname :String [0..1 ]
StorageLink
+ occi.compute.speed :Float [0..1 ]
+ occi.compute.memory :Float [0..1 ] + occi.storagelink.deviceid :String
+ occi.compute.state :Enum + occi.storagelink.mountpoint :String [0..1 ]
+ occi.storagelink.state :Enum

Figure 1. Overview Diagram of OCCI Infrastructure Types.

These infrastructure types inherit the OCCI Core Model Resource base type and all their attributes. The HTTP
Rendering document [2] defines how to serialise and interact with these types using RESTful communication.
Implementers are free to choose what Resource and Link sub-types to implement. Those that are supported
by an implementation will be discoverable through the OCCI Query Interface.
As REQUIRED by the OCCI Core Model specification, every type instantiated that is a sub-type of Resource
or Link MUST be assigned a Kind that identifies the instantiated type. Each such Kind instance MUST
be related to the Resource or Link base type’s Kind. That assigned Kind instance MUST always remain
immutable to any client.
Table 1 describes the Kind instances defined for each of the infrastructure Resource or Link sub-types. For
information on extending these types, please refer to the OCCI Core Model document [1].
The following sections on Compute, Storage and Network types detail the attributes, Actions and states
defined for each of them, including type-specific mixins (IPNetwork and IPNetworkInterface) where appro-
priate. Following those, the definition of infrastructure-related Link sub-types are given and finally OS and
Resource Templates are defined. Figure 1 gives an overview of the various types involved in this infrastructure
specification.

occi-wg@ogf.org 4
GFD-P-R.184 June 21, 2011

Table 1. The Kind instances defined for the infrastructure sub-types of Resource, Link and related Mixins. The base URL
http://schemas.ogf.org/occi has been replaced with <schema> in this table for a better readability experience.

Term Scheme Title Related Kind

compute <schema>/infrastructure# Compute Resource <schema>/core#resource
storage <schema>/infrastructure# Storage Resource <schema>/core#resource
storagelink <schema>/infrastructure# StorageLink Link <schema>/core#link
network <schema>/infrastructure# Network Resource <schema>/core#resource
ipnetworking <schema>/infrastructure/network# IP Networking Mixin –
networkinterface <schema>/infrastructure# NetworkInterface Link <schema>/core#link
ipnetworkinterface <schema>/infrastucture/networkinterface# IP NetworkInterface Mixin –

3.1 Compute
The Compute type represents a generic information processing resource, e.g. a virtual machine. Compute
inherits the Resource base type defined in OCCI Core Model [1]. Compute is assigned the Kind instance
http://schemas.ogf.org/occi/infrastructure#compute. A Compute instance MUST use and expose this Kind.

Table 2. Attributes defined for the Compute type.

Attribute Type Multi- Mutability Description

plicity
occi.compute.architecture Enum {x86, x64} 0. . . 1 Mutable CPU Architecture of the instance.
occi.compute.cores Integer 0. . . 1 Mutable Number of CPU cores assigned to the instance.
occi.compute.hostname String 0. . . 1 Mutable Fully Qualified DNS hostname for the instance.
occi.compute.speed Float, 109 (GHz) 0. . . 1 Mutable CPU Clock frequency (speed) in gigahertz.
occi.compute.memory Float, 109 (GiB) 0. . . 1 Mutable Maximum RAM in gigabytes allocated to the in-
stance.
occi.compute.state Enum {active, inac- 1 Immutable Current state of the instance.
tive, suspended}

Table 2 describes the attributes2 defined by Compute through its Kind instance. These attributes MUST be
exposed by an instance of the Compute type.

Table 3. Actions applicable to instances of the Compute type. The Actions are defined by the Kind instance
http://schemas.ogf.org/occi/infrastructure#compute. Every Action in the table is identified by a Category instance using the
http://schemas.ogf.org/occi/infrastructure/compute/action# categorisation scheme. “Action Term” below refers to the term
of the Action’s Category identifier.

Action Term Target state Attributes

start active –
stop inactive method={graceful, acpioff, poweroff}
restart active (via stop and start chain) method={graceful, warm, cold}
suspend suspended method={hibernate, suspend}

Table 3 describes the Actions defined for Compute by its Kind instance. These Actions MUST be exposed
by an instance of the Compute type of an OCCI implementation. Figure 2 illustrates the state diagram for a
Compute instance.

3.2 Network
The Network type represents a L2 networking entity (e.g. a virtual switch). It can be extended using the
mixin mechanism (or sub-typed) to support L3/L4 capabilities such as TCP/IP etc. For the purposes of
this specification we define an OCCI mixin so that IP networking can be supported where required. Network
inherits the Resource base type defined in OCCI Core Model [1].
2 See the “attributes” attribute defined by the Category type and inherited by Kind [1].

occi-wg@ogf.org 5
GFD-P-R.184 June 21, 2011

Figure 2. State Diagram for a Compute instance.

The Network type is assigned the http://schemas.ogf.org/occi/infrastructure#network Kind. A Network

instance MUST use and expose this Kind.

Table 4. Attributes defined for the Network type.

Attribute Type Multiplicity Mutability Description

occi.network.vlan Integer: 0-4095 0. . . 1 Mutable 802.1q VLAN Ientifier (e.g. 343).
occi.network.label Token 0. . . 1 Mutable Tag based VLANs (e.g. external-dmz).
occi.network.state Enum {active, inactive} 1 Immutable Current state of the instance.

Table 4 describes the attributes3 defined by Network through its Kind instance. These attributes MUST be
exposed by an instance of the Network type.

Table 5. Actions applicable to instances of the Network type. The Actions are defined by the Kind instance
http://schemas.ogf.org/occi/infrastructure#network. Every Action in the table is identified by a Category instance using the
http://schemas.ogf.org/occi/infrastructure/network/action# categorisation scheme. “Action Term” below refers to the term of
the Action’s Category identifier.

Action Term Target State Attributes

up active –
down inactive –

Table 5 describes the Actions defined for Network by its Kind instance. These Actions MUST be exposed
by an instance of the Network type of an OCCI implementation. Figure 3 illustrates the state diagram for a
Network instance.

Figure 3. State Diagram for a Network instance.

3.2.1 IPNetworking Mixin

In order to support L3/L4 capabilities (e.g. IP, TCP etc.) an OCCI mixin is herewith defined.
The IPNetworking mixin is assigned4 the “scheme” of http://schemas.ogf.org/occi/infrastructure/network#
and the “term” value ipnetwork. An IPNetworking mixin MUST support these values.
3 See the “attributes” attribute defined by the Category type and inherited by Kind [1].
4 Both assignments use data members from the inherited Category type [1].

occi-wg@ogf.org 6
GFD-P-R.184 June 21, 2011

Table 6 define the attributes introduced by the IPNetworking mixin. A Network instance associated with the
IPNetworking mixin Mixin instance MUST implement these attributes.

Table 6. Attributes defined by the IPNetworking mixin. A Network instance associated with this Mixin instance MUST expose
these attributes.
Attribute Type Multi- Mutability Description
plicity
occi.network.address IPv4 or IPv6 Address range, 0. . . 1 Mutable Internet Protocol(IP) network address
CIDR notation (e.g. 192.168.0.1/24, fc00::/7)
occi.network.gateway IPv4 or IPv6 Address 0. . . 1 Mutable Internet Protocol(IP) network address
(e.g. 192.168.0.1, fc00::)
occi.network.allocation Enum {dynamic, static} 0. . . 1 Mutable Address allocation mechanism: dynamic
e.g. uses the dynamic host configuration
protocol, static e.g. uses user supplied
static network configurations.

In Figure 4 a UML object diagram depicts how Network would be associated with an IPNetwork Mixin when
both are instantiated.

net1 : Network
occi.network.vlan = 332
occi.network.label = dmz
occi.network.state = active without Mixin

net2 : Network
occi.network.vlan = 431
occi.network.label = private
occi.network.state = active
occi.network.address = 192.168.1.1/24
occi.network.gateway = 192.168.1.1
occi.network.allocation = dynamic with Mixin

IPNetwork : Mixin
term = ipnetwork
scheme = http://schemas.ogf.org/occi/
infrastructure/network#
title = "An IP Network Mixin"

Figure 4. Object Diagram of a Network Instance and its Associated IPNetwork Mixin.

3.3 Storage
The Storage type represent resources that record information to a data storage device. Storage inherits the
Resource base type defined in the OCCI Core Model [1]. The Storage type is assigned the Kind instance
http://schemas.ogf.org/occi/infrastructure#storage. A Storage instance MUST use and expose this Kind.

Table 7. Attributes defined for the Storage type.

Attribute Type Multiplicity Mutability Description

occi.storage.size Float, 109 (GiB) 1 Mutable Storage size in gigabytes of the instance.
occi.storage.state Enum {online, offline, 1 Immutable Current status of the instance.
backup, snapshot, re-
size, degraded}

Table 7 describes the attributes5 defined by Storage through its Kind instance. These attributes MUST be
exposed by an instance of the Storage type.
Table 8 describes the Actions defined for Storage by its Kind instance. These Actions MUST be exposed
by an instance of the Storage type of an OCCI implementation. Figure 5 illustrates the state diagram for a
Storage instance.
5 See the “attributes” attribute defined by the Category type and inherited by Kind [1].

occi-wg@ogf.org 7
GFD-P-R.184 June 21, 2011

Table 8. Actions applicable to instances of the Storage type. The Actions are defined by the Kind instance
http://schemas.ogf.org/occi/infrastructure#storage. Every Action in the table is identified by a Category instance using the
http://schemas.ogf.org/occi/infrastructure/storage/action# categorisation scheme. “Action Term” below refers to the term of
the Action’s Category identifier.

Action Term Target State Attributes

online online –
offline offline –
backup None –
snapshot None –
resize None size = Float 109 (GiB)

Figure 5. State Diagram for a Storage instance.

OCCI can be used in conjunction with the SNIA cloud storage standard, Cloud Data Management Interface
(CDMI) [5] to provide enhanced management of the cloud computing storage and data. For storage managed
through CDMI, see the section on StorageLink

3.4 Linking Infrastructure Resources

In order to create entities like virtual data centres or virtual clusters, it is necessary to allow the linkage of
the previously defined infrastructure Resource sub-types. This is accomplished by extending (sub-typing) the
OCCI Core Model Link base type. This is done as the Link base type cannot fully represent specific types of
infrastructure links (e.g. links to storage or networks). These infrastructure links require additional attributes
(e.g. network interface name) which can only be supported by sub-typing the Link base type.

3.4.1 Linking to Network

The NetworkInterface type represents an L2 client device (e.g. network adapter). It can be extended using the
mix-in mechanism or sub-typed to support L3/L4 capabilities such as TCP/IP etc. NetworkInterface inherits
the Link base type defined in the OCCI Core Model [1].
The NetworkInterface type is assigned the Kind instance http://schemas.ogf.org/occi/infrastructure#networkinterface.
A NetworkInterface instance MUST use and expose this Kind. The Kind instance assigned to the Network-
Interface type MUST be related to the http://schemas.ogf.org/occi/core#link Kind.
Table 9 describes the attributes6 defined by NetworkInterface through its Kind instance. These attributes
MUST be exposed by an instance of the NetworkInterface type. Figure 6 illustrates the state diagram for a
NetworkInterface instance.

3.4.1.1 IPNetworkInterface Mixin In order to support L3/L4 capabilities (e.g. IP, TCP etc.) with the
NetworkInterface type, an OCCI Mixin instance is herewith defined.
6 See the “attributes” attribute defined by the Category type and inherited by Kind [1].

occi-wg@ogf.org 8
GFD-P-R.184 June 21, 2011

Table 9. Attributes defined for the NetworkInterface type.

Attribute Type Multiplicity Mutability Description

occi.networkinterface.interface String 1 Immutable Identifier that relates the link to the
link’s device interface
occi.networkinterface.mac String 1 Mutable MAC address associated with the link’s
device interface
occi.networkinterface.state Enum {active, 1 Immutable Current status of the instance.
inactive}

Figure 6. State Diagram for a NetworkInterface instance.

The IPNetworkInterface mixin is assigned7 the “scheme” of http://schemas.ogf.org/occi/infrastructure/networkinterface#

and the “term” value ipnetworkinterface. An IPNetworkInterface mixin MUST support these attributes.
Table 10 define the attributes introduced by the IPNetworkInterface mixin. A NetworkInterface instance
associated with the IPNetworkInterface mixin Mixin instance MUST expose these attributes.

Table 10. Attributes defined by the IPNetworkInterface mixin. A NetworkInterface instance associated with this Mixin instance
MUST expose these attributes.

Attribute Type Multi- Mutability Description

plicity
occi.networkinterface.address IPv4 or IPv6 Address 1 Mutable Internet Protocol(IP) network address
(e.g. 192.168.0.1/24, fc00::/7) of the
link
occi.networkinterface.gateway IPv4 or IPv6 Address 0. . . 1 Mutable Internet Protocol(IP) network address
(e.g. 192.168.0.1/24, fc00::/7)
occi.networkinterface.allocation Enum {dynamic, static} 1 Mutable Address mechanism: dynamic e.g. uses
the dynamic host configuration protocol,
static e.g. uses user supplied static net-
work configurations.

In Figure 7 a UML object diagram depicts how NetworkInterface would be associated with an IPNetworkIn-
terface Mixin when both are instantiated.

3.4.2 Linking to Storage

The StorageLink type represents a link from a Resource to a target Storage instance. This enables a Storage
instance be attached to a Compute instance, with all the prerequisite low- level operations handled by the
OCCI implementation. Storage inherits the Link base type defined in the OCCI Core Model [1].
The StorageLink type is assigned the Kind instance http://schemas.ogf.org/occi/infrastructure#storagelink.
A StorageLink instance MUST use and expose this Kind. The Kind instance assigned to the StorageLink type
MUST be related to the http://schemas.ogf.org/occi/core#link Kind.
Table 11 describes the attributes8 defined by StorageLink through its Kind instance. These attributes MUST
be exposed by an instance of the StorageLink type. Figure 8 illustrates the state diagram for a StorageLink
instance.
7 Both assignments use data members from the inherited Category type [1].
8 See the “attributes” attribute defined by the Category type and inherited by Kind [1].

occi-wg@ogf.org 9
GFD-P-R.184 June 21, 2011

netIface1 : NetworkInterface
occi.networkinterface.interface = eth0
occi.networkinterface.mac = 00:24:64:17:a0:23
occi.networkinterface.state = active without Mixin

netIface2 : NetworkInterface
occi.networkinterface.interface = eth0
occi.networkinterface.mac = 00:24:64:37:a1:25
occi.networkinterface.state = active
occi.networkinterface.address = 192.168.0.65
occi.networkinterface.gateway = 192.168.0.1
occi.networkinterface.allocation = dynamic with Mixin

IPNetworkInterface : Mixin
term = ipnetworkinterface
scheme = http://schemas.ogf.org/occi/
infrastructure/networkinterface#
title = "An IP Network Interface Mixin"

Figure 7. Object Diagram of a NetworkInterface Instance and its Associated IPNetworkInterface Mixin.

Table 11. Attributes defined for the StorageLink type.

Attribute Type Multi- Mutability Description

plicity
occi.storagelink.deviceid String 1 Mutable Device identifier as defined by the OCCI
service provider.
occi.storagelink.mountpoint String 0. . . 1 Mutable Point to where the storage is mounted in
the guest OS.
occi.storagelink.state Enum {active, 1 Immutable Current status of the instance.
inactive}

Figure 8. State Diagram for a StorageLink instance.

3.4.3 Linking to CDMI Managed Storage

As previously stated, OCCI can be used in conjunction with the SNIA cloud storage standard, Cloud Data
Management Interface (CDMI) [5] to provide enhanced management of the cloud computing storage and
data. In order to integrate the two, the use of StorageLink should be used. This will link OCCI managed
Resources to CDMI resources. The ’occi.storagelink.deviceid’ attribute of StorageLink, defined above, should
be set to the CDMI Object ID of an exported CDMI Container.

3.5 Infrastructure Templates

Infrastructure Templates allow clients of an OCCI implementation to quickly and conveniently apply pre-
defined configurations to OCCI Infrastructure defined types. They are implemented using Mixin instances.
There are 2 supported infrastructure template types in OCCI Infrastructure.

3.5.1 OS Template

OS (Operating System) Templates allow clients specific what operating system must be installed on a re-
quested Compute resource. OCCI implementations SHOULD support this, otherwise what they provision will

occi-wg@ogf.org 10
GFD-P-R.184 June 21, 2011

be merely offer Resources without any available execution environment (e.g. operating system). Of the two
supported template types, this is the most basic and necessary template that a provider SHOULD offer.
Its construction is a Mixin instance consisting of a provider specific “scheme” and a descriptive “title” detailing
the OS. The “term” value of the template Mixin is a provider-specific identifier that corresponds to a particular
virtual machine image configuration. Where an implementation requires additional attributes associated with
the OS Template, it can do so using “attributes” value inherited from the Category type.
A implementation-defined OS Template Mixin MUST be related to the OCCI OS Template Mixin in order to
give absolute type information.
The OCCI OS Template is defined by the http://schemas.ogf.org/occi/infrastructure#os tpl Mixin and MUST
be supported SHOULD OS Templates be offered by the OCCI implementation.

os_tpl : Mixin
term = os_tpl
scheme = http://schemas.ogf.org/occi/infrastructure#

related

c1 : Compute ubuntu : Mixin

occi.compute.cores = 2 term = ubuntu-9.10
occi.compute.memory = 0.5 scheme = http://provider.com/templates/os#

cmp : Kind
term = compute
scheme = http://schemas.ogf.org/occi/infrastructure#

Figure 9. Object Diagram of a Compute Instance and its Associated OS Template Mixin.

A typical example of using such a Mixin is shown in figure 9 using a UML object diagram. In the example a
provider has defined an OS template which offers the ability to run Ubuntu Linux, verson 9.10, upon a client’s
provisioned compute resource.
How a provider manages their set of OS templates will be determined by themselves and so implementation-
specific.

3.5.2 Resource Template

The Resource Template Mixin builds upon the concept of OS Templates. A Resource Template is a provider-
defined Mixin instance that refers to a preset Resource configuration.
The preset Resource configuration is not visable through the OCCI Discovery mechanism. The Mixin.attributes
(inherited from Category) is empty for a Resource Template Mixin. The side-effect of initialising Resource
attributes with pre-defined values is handled by the implementation.
The OCCI implementation associates a set of Resource attributes (via Category’s ’attributes’) with a particular
term identifier.
An implementation-defined Resource Template Mixin MUST be related to the OCCI Resource Template Mixin
in order to give absolute type information. The OCCI Resource Template is defined by the Mixin instance
http://schemas.ogf.org/occi/infrastructure#resource tpl and MUST be supported SHOULD Resource Tem-
plates be offered by the OCCI implementation.
A typical example of such a Mixin’s use is shown in figure 10) using a UML object diagram. In this example,
the provider offers Compute Resources based on different sizes (i.e. small, medium, large). Each “size” of
Compute (i.e. the term) corresponds to a predetermined set of OCCI Resource-specific attributes. In the
example below a ’small’ Compute instance is created. Specifying ”small” as the term corresponds to an
implementation-specific Compute Resource-specific attribute set9 that is shown by the object instance named
“attributes” in figure 10.
From the administrative point of view, how an OCCI service provider manages their set of Resource Templates
will be determined by themselves and so is implementation-specific.
9 This attribute set is implementation-specific and is not related to Mixin.attributes inherited from the Category type [1].

occi-wg@ogf.org 11
GFD-P-R.184 June 21, 2011

os_tpl : Mixin
term = os_tpl
scheme = http://schemas.ogf.org/occi/infrastructure#

related
c2 : Compute
occi.compute.arch = x86 ubuntu : Mixin
occi.compute.cores = 2 term = ubuntu-9.10
occi.compute.speed = 2.4 scheme = http://provider.com/templates/os#
occi.compute.memory = 1.0

cmp : Kind
term = compute
scheme = http://schemas.ogf.org/occi/infrastructure#

smallInstance : Mixin
term = small
scheme = http://provider.com/templates/compute#

attributes : Set related

occi.compute.arch = x86
occi.compute.cores = 2
occi.compute.speed = 2.4
occi.compute.memory = 1.0

resource_tpl : Mixin
term = resouce_tpl
scheme = http://schemas.ogf.org/occi/infrastructure#

Figure 10. Object Diagram of a Compute Instance and its Associated OS Template Mixin and Resource Template Mixin.

4 Security Considerations
The OCCI Infrastructure specification is an extension to the OCCI Core and Model specification [1]; thus the
same security considerations as for the OCCI Core and Model specification apply here.

occi-wg@ogf.org 12
GFD-P-R.184 June 21, 2011

5 Glossary
Term Description
Action An OCCI base type. Represent an invocable operation on a Entity sub-type instance
or collection thereof.
Category A type in the OCCI model. The parent type of Kind.
Client An OCCI client.
Collection A set of Entity sub-type instances all associated to a particular Kind or Mixin
instance.
Entity An OCCI base type. The parent type of Resource and Link.
Kind A type in the OCCI model. A core component of the OCCI classification system.
Link An OCCI base type. A Link instance associate one Resource instance with another.
mixin An instance of the Mixin type associated with a resource instance. The “mixin”
concept as used by OCCI only applies to instances, never to Entity types.
Mixin A type in the OCCI model. A core component of the OCCI classification system.
OCCI Open Cloud Computing Interface.
OCCI base type One of Entity, Resource, Link or Action.
OGF Open Grid Forum.
Resource An OCCI base type. The parent type for all domain-specific resource types.
resource instance An instance of a sub-type of Entity. The OCCI model defines two sub-types of
Entity, the Resource type and the Link type. However, the term resource instance
is defined to include any instance of a sub-type of Resource or Link as well.
Tag A Mixin instance with no attributes or actions defined.
Template A Mixin instance which if associated at resource instantiation time pre-populate
certain attributes.
type One of the types defined by the OCCI model. The OCCI model types are Category,
Kind, Mixin, Action, Entity, Resource and Link.
concrete type/sub-type A concrete type/sub-type is a type that can be instantiated.
URI Uniform Resource Identifier.
URL Uniform Resource Locator.
URN Uniform Resource Name.

6 Contributors

occi-wg@ogf.org 13
GFD-P-R.184 June 21, 2011

We would like to thank the following people who contributed to this document:
Name Affiliation Contact
Michael Behrens R2AD behrens.cloud at r2ad.com
Mark Carlson Oracle mark.carlson at oracle.com
Andy Edmonds Intel - SLA@SOI project andy at edmonds.be
Sam Johnston Google samj at samj.net
Gary Mazzaferro OCCI Counselour - AlloyCloud, Inc. garymazzaferro at gmail.com
Thijs Metsch Platform Computing, Sun Mi- tmetsch at platform.com
crosystems
Ralf Nyrén Aurenav ralf at nyren.net
Alexander Papaspyrou TU Dortmund University alexander.papaspyrou at tu-
dortmund.de
Alexis Richardson RabbitMQ alexis at rabbitmq.com
Shlomo Swidler Orchestratus shlomo.swidler at orchestratus.com
Next to these individual contributions we value the contributions from the OCCI working group.

occi-wg@ogf.org 14
GFD-P-R.184 June 21, 2011

7 Intellectual Property Statement

The OGF takes no position regarding the validity or scope of any intellectual property or other rights that
might be claimed to pertain to the implementation or use of the technology described in this document or the
extent to which any license under such rights might or might not be available; neither does it represent that
it has made any effort to identify any such rights. Copies of claims of rights made available for publication
and any assurances of licenses to be made available, or the result of an attempt made to obtain a general
license or permission for the use of such proprietary rights by implementers or users of this specification can
be obtained from the OGF Secretariat.
The OGF invites any interested party to bring to its attention any copyrights, patents or patent applications,
or other proprietary rights which may cover technology that may be required to practice this recommendation.
Please address the information to the OGF Executive Director.

8 Disclaimer
This document and the information contained herein is provided on an “As Is” basis and the OGF disclaims all
warranties, express or implied, including but not limited to any warranty that the use of the information herein
will not infringe any rights or any implied warranties of merchantability or fitness for a particular purpose.

9 Full Copyright Notice

Copyright c Open Grid Forum (2009-2011). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment
on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in
whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this document itself may not be modified in
any way, such as by removing the copyright notice or references to the OGF or other organizations, except
as needed for the purpose of developing Grid Recommendations in which case the procedures for copyrights
defined in the OGF Document process must be followed, or as required to translate it into languages other
than English.
The limited permissions granted above are perpetual and will not be revoked by the OGF or its successors or
assignees.

References
[1] R. Nyrén, A. Edmonds, A. Papaspyrou, and T. Metsch, “Open Cloud Computing Interface – Core,”
GFD-P-R.183, April 2011. [Online]. Available: http://ogf.org/documents/GFD.183.pdf
[2] T. Metsch and A. Edmonds, “Open Cloud Computing Interface – HTTP Rendering,” GFD-P-R.185,
April 2011. [Online]. Available: http://ogf.org/documents/GFD.185.pdf
[3] ——, “Open Cloud Computing Interface – Infrastructure,” GFD-P-R.184, April 2011. [Online]. Available:
http://ogf.org/documents/GFD.184.pdf
[4] S. Bradner, “Key words for use in RFCs to Indicate Requirement Levels,” RFC 2119
(Best Current Practice), Internet Engineering Task Force, Mar. 1997. [Online]. Available:
http://www.ietf.org/rfc/rfc2119.txt
[5] D. Slik, M. Siefer, E. Hibbard, C. Schwarzer, A. Yoder, L. N. Bairavasun-
daram, S. Baker, M. Carlson, H. Nguyen, and R. Ramos, “Cloud data man-
agement interface (cdmi) v1.0,” http://www.snia.org/, Apr. 2010. [Online]. Available:
http://www.snia.org/tech activities/standards/curr standards/cdmi/CDMI SNIA Architecture v1.0.pdf

occi-wg@ogf.org 15