The infrastructure service interface and the DCP interfaces and protocols are points of interoper- ability between providers. In some cases these may be relatively ad hoc or proprietary, such as integration interfaces agreed between neighbouring administrative domains, in others they need to be generally defined and are therefore candidates for standardisation. The infrastructure service interface used to delegate infrastructure management to providers is one such candidate.
The infrastructure service interface is based on web technologies like REST since full support is readily available from key working groups and forums such as Open Grid Forum (OGF) OCCI-
WG and Storage Networking Industry Association (SNIA) CDMI. This interface needs to be
compatible with the cloud computing technologies and communities and it has to use the right level of abstraction to simplify interactions with applications and users on the user API side. In
parallel, the interface needs to be useful for any lower level or domain specific technology via the lower level API. Several significant IaaS implementations implement the OCCI interface or are currently developing the interface, including OpenNebula [7] and OpenStack [20]. Most cloud resource and service tool and manager implementations today are compatible compatible with OCCI.
Figure 4.5: OCCI Protocol and API placement in a provider’s architecture from [1]
OCCI is a boundary protocol and API that acts as a service front-end to a provider’s internal
management framework. Figure 4.5 shows OCCI’s place in a provider’s architecture. Service
consumers can be both end-users and other system instances. OCCI is suitable for both cases. The key feature of OCCI is that it can be used as a management API for all kinds of resources while at the same time maintaining a high level of interoperability. For this reason it provides a possible starting point for CloNe to define an infrastructure service interface.
In the following we describe how OCCI can be extended to incorporate the CloNe capabilities. We call the extension Open Cloud Networking Interface (OCNI).
Figure 4.6: UML diagram of the OCCI Core and Infrastructure
by an OCCI infrastructure specification that views everything as a resource. The notion of resource in OCCI has a very broad meaning and describes a concrete resource that represents real world resources such as virtual machines, jobs in a job submission system, users, networks and even services (including applications, middleware services, network services, networking and connectivity services, etc.). The structure of the OCCI specification is depicted in Figure 4.6. The Mixin element allows the inclusion or integration of components from other domains or realms not originally
included in the OCCI specification scope or coverage space. Despite this Mixin feature, it is
essential to extend the framework to include cloud networking in the specification to move the clouds beyond cloud computing.
Figure 4.7: OCNI - An OCCI extension for cloud networking
The OCCI Core specification is enough to describe any cloud computing constituent or component in terms of attributes and characteristics but falls short of describing connectivity between these components. The OCNI extension depicted in Figure 4.7 is meant to fill this gap. OCNI is composed of two elements. The first and main one is a cloud networking centric extension to the OCCI core. This extension is in the same layer as the OCCI infrastructure extension which is compute centric. The second element consists of a number of specialized network Mixin that can be used in the OCCI Infrastructure extension as shown in Figure 4.7. Examples of such Mixins, most relevant to CloNe are for example VPN and OpenFlow network interface Mixins.
OCNI specifies an abstract data model taking into account expected and desired CloNe services to fill the existing gap in cloud computing by introducing cloud networking services. The ultimate goal is to merge networks and clouds to achieve convergence of cloud computing and operator networks and services. The details are depicted in Figure 4.8.
The OCNI extension adheres to and uses the OCCI original approach by adopting the same modelling framework but specialises the specification to the cloud networking domain by adding classes that relate to the CloNe networking resources and their relationships. These classes repre- sent abstract concepts that can be used to encapsulate common networking concepts such as the FNS, including the data models presented in Section 3, or technology specific such as the virtual networking technologies presented later in Section 6. As such, model transformation during the delegation process, as described in Section 3, can be used to refine an abstract model to a more specific model while continuing to use the same interface for delegation.
The components of the data model in Figure 4.8 comprise those related to the OCCI specifi- cation and to the OCNI extension. These elements are described in terms of roles, functions and relationships for the reader’s convenience and for broader comprehension of the data model. The OCCI Core and OCCI Infrastructure are repeated for reference as they are readily available and described in greater depth in [1] and [21]. The elements introduced though the OCNI extension use the same concepts as OCCI and are consequently compliant and compatible with the original
Figure 4.8: CloNe proposal for an OCNI extension of the OCCI framework
OCCI specification. This will enable natural integration OCNI and cloud networking concepts and facilitate the dynamic composition of FNSs to support the cloud community in setting on demand virtual and dedicated private and hybrid clouds. The components of the data model in Figure 4.8 are itemised below.
OCCI Core[1]
• Category: The Category type is the basis of the type identification mechanism used by the
OCCI classification system.
• Kind: The kind type, together with the Mixin type, defines the classification system of the
OCCI Core Model. The Kind type represents the type identification mechanism for all Entity types present in the model.
• Mixin: The Mixin type complements the Kind type in defining the OCCI Core Model type
classification system. The Mixin type represents an extension mechanism, which allows new resource capabilities to be added to resource instances both at creation-time and/or run-time.
• Entity: The Entity type is an abstract type of the Resource type and the Link type.
• Action: The Action type is an abstract type. Each sub-type of Action defines an invocable
operation applicable to an Entity sub-type instance or a collection thereof.
• Resource: The resource type inherits Entity and describes a concrete resource that can be
inspired and manipulated. A resource is suitable to represent real world resources, e.g. virtual machines, networks, services, etc. through specialisation
• Link: An instance of the Link type defines a base association between two Resource instances. A Link instance indicates that one Resource instance is connected to another.
OCCI infrastructure[21] Resource:
• Compute: Information processing resources.
• Network: Interconnection resource and represents a L2 networking resource. This is compli-
mented by the IPNetwork Mixin.
• Storage: Information recording resources.
Link:
• NetworkInterface: connects a Compute instance to a Network instance. This complimented
by an IPNetworkInterface Mixin.
• StorageLink: connects a Compute instance to a Storage instance.
OCNI
Resource:
• FlashNetworkSlice: a resource that provides a network service.
• CloNeNode: a networking resource of the Flash Network Slice.
• CloNeLink: a network link of the Flash Network Slice.
Link:
• FlashNetworkSliceInterface: connects a FlashNetworkSlice instance to a Resource instance.
• CloNeNetworkInterface: connects a CloNeNode instance to a CloNeLink instance.
• CloNeComputeLink: connects a CloNeNode instance to a Compute instance.
• CloNeStorageLink: connects a CloNeNode instance to a Storage instance.