Cloud computing

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.
 
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 complementary documents, which together form the complete specification. The documents are divided into four categories consisting of the OCCI Core, the OCCI Protocols, the OCCI Renderings and the OCCI Extensions.

• The OCCI Core specification consists of a single document defining the OCCI Core Model. OCCI interaction occurs through renderings (including associated behaviors) and is expandable through extensions.
• The OCCI Protocol specifications consist of multiple documents, each describing how the model can be interacted with over a particular protocol (e.g. HTTP, AMQP, etc.). Multiple protocols can interact with the same instance of the OCCI Core Model.
• 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.

The current specification consists of seven documents. This specification describes version 1.2 of OCCI and is backward compatible with 1.1.
 
The OCCI JSON Rendering specifies a rendering of OCCI instance types in the JSON data interchange format as defined in "The application/json Media Type for JavaScript Object Notation (JSON), RFC 4627 (Informational), Internet Engineering Task Force".
 
The rendering can be used to render OCCI instances independently of the protocol being used. Thus messages can be delivered by, e.g., the HTTP protocol as specified in “Open Cloud Computing Interface – HTTP Protocol”.
 
The following media-type MUST be used for the OCCI JSON Rendering:
application/occi+json
 
The OCCI JSON Rendering consists of a JSON object containing information on the OCCI Core instances OCCI Kind, OCCI Mixin, OCCI Action, OCCI Link and OCCI Resource. The rendering also include a JSON object to invoke the operation identified by OCCI Actions..

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.
 
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 complementary documents, which together form the complete specification. The documents are divided into four categories consisting of the OCCI Core, the OCCI Protocols, the OCCI Renderings and the OCCI Extensions.

• The OCCI Core specification consists of a single document defining the OCCI Core Model. OCCI interaction occurs through renderings (including associated behaviors) and is expandable through extensions.
• The OCCI Protocol specifications consist of multiple documents, each describing how the model can be interacted with over a particular protocol (e.g. HTTP, AMQP, etc.). Multiple protocols can interact with the same instance of the OCCI Core Model.
• 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.

The current specification consists of seven documents. This specification describes version 1.2 of OCCI and is backward compatible with 1.1.
 
The OCCI Platform document details how an OCCI implementation can model and implement a Platform as a Service API offering by extending the OCCI Core Model. This API enables the provisioning and management of PaaS resources. For example, it allows to deploy an application on one or more PaaS components. The application itself could be composed of different components. The main platform types defined within OCCI Platform are:
 
Application. Which defines the user-defined part of the overall service.
 
Component. A configured instance of a piece of code providing business functions that are part of the execution of the application or responsible of hosting the application.
 
ComponentLink. Connects an Application instance to a hosting Component or connects two components

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.
 
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 complementary documents, which together form the complete specification. The documents are divided into four categories consisting of the OCCI Core, the OCCI Protocols, the OCCI Renderings and the OCCI Extensions.

• The OCCI Core specification consists of a single document defining the OCCI Core Model. OCCI interaction occurs through renderings (including associated behaviors) and is expandable through extensions.
• The OCCI Protocol specifications consist of multiple documents, each describing how the model can be interacted with over a particular protocol (e.g. HTTP, AMQP, etc.). Multiple protocols can interact with the same instance of the OCCI Core Model.
• 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.

The current specification consists of seven documents. This specification describes version 1.2 of OCCI and is backward compatible with 1.1.
 
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 in relation with the Service Level Agreements extension of the OCCI Core Model.
 
The OCCI Service Level Agreements (OCCI SLAs) document describes how the OCCI Core Model can be extended and used to implement a Service Level Agreement management API. This API allows for the creation and management of resources related with the realization of agreements between an OCCI-enabled cloud service provider and potential consumers of the provider’s resources. The introduced types and Mixins defined in this OCCI SLAs document are the following:
 
Agreement: This resource represents the Service Level Agreement between the provider and the consumer. It includes the basic information for this contract and with the appropriate extensions (Mixins) it can be populated with further information. To this end, we introduce the AgreementTemplate and the AgreementTerms Mixins which complement the SLAs with template tagging and terms specification respectively.
AgreementLink: This is a link entity that associates an Agreement instance with any other Resource instance.

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.
 
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 complementary documents, which together form the complete specification. The documents are divided into four categories consisting of the OCCI Core, the OCCI Protocols, the OCCI Renderings and the OCCI Extensions.

• The OCCI Core specification consists of a single document defining the OCCI Core Model. OCCI interaction occurs through renderings (including associated behaviors) and is expandable through extensions.
• The OCCI Protocol specifications consist of multiple documents, each describing how the model can be interacted with over a particular protocol (e.g. HTTP, AMQP, etc.). Multiple protocols can interact with the same instance of the OCCI Core Model.
• 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.

The current specification consists of seven documents. This specification describes version 1.2 of OCCI and is backward compatible with 1.1.
 
This document presents the text-based renderings. To be complaint, OCCI implementations MUST implement the three renderings defined in sections 6, 7 and 8.
The following specification of the text-based renderings is in the process of being deprecated and will be removed or significantly changed in the next MAJOR release of the standard.
The document is structured by defining base ABNFs, which can then be combined into renderings, which will be rendered over a protocol (e.g., HTTP) by the specific rendering definitions.

The aim of this working group is to define an XML-based language, the Data Format Description Language (DFDL), for describing the structure of binary and textual files and data streams so that their format, structure, and metadata can be exposed.

• Projekt-Homepage: http://www.ogf.org/dfdl
• GridForge Project (historical): http://redmine.ogf.org/projects/dfdl-wg

The 'Distributed Resource Management Application API (DRMAA)' working group develops and maintains a set of API specifications for tightly coupled and portable programmatic access to cluster, grid, and cloud systems. The DRMAA working group deliverables are intended to facilitate the development of portable application programs and high-level libraries such as SAGA or OGSA-BES. DRM system vendors can provide a standardized access to their product through a DRMAA implementation. High-level API designers, meta-scheduler architects and end users can rely on such DRMAA implementations for a unified access to execution resources. The scope of the API standardization is focused on job submission, job control, reservation management, and retrieval of job and machine monitoring information.

• Project-Homepage: http://www.drmaa.org/
• Subprojects: DRMAAv1, DRMAAv2 C Binding, DRMAAv2 Go Binding, DRMAAv2 OCCI Binding, DRMAAv2 Root Specification
• GridForge Project (historical): https://forge.ogf.org/sf/projects/drmaa-wg

The goal of the GRAAP Working Group is to produce a set of specifications and supporting documents which describe methods and means to establish Service Level Agreements between different entities in a distributed environment. The WS-Agreement Specification V1.0, a Web Services protocol to establish agreements between two services, has been published May 2007 as an OGF Proposed Recommendation: Just recently an errata version has been published fixin a few typos in the non-normative part. The new version supercedes the version of 2007 (see GFD.192). Along with this document the group has published the specification for extended negotiation and renegotiation on top of WS-Agreement as WS-Agreement Negotiation (see GFD.193).

• Projekt-Homepage: http://www.ogf.org/
• GridForge Project (historical): https://forge.ogf.org/sf/projects/graap-wg

This standard defines topology, functions, and governance for cloud-to-cloud interoperability and federation. Topological elements include clouds, roots, exchanges (which mediate governance between clouds), and gateways (which mediate data exchange between clouds). Functional elements include name spaces, presence, messaging, resource ontologies (including standardized units of measurement), and trust infrastructure. Governance elements include registration, geo-independence, trust anchor, and potentially compliance and audit. The standard does not address intra-cloud (within cloud) operation, as this is cloud implementation-specific, nor does it address proprietary hybrid-cloud implementations.

The present document presents an architectural description of the Infrastructure Network domain of the infrastructure which supports virtualised network functions. It sets out the scope of the infrastructure domain acknowledging the potential for overlap between infrastructure domains, and between the infrastructure and the virtualised network functions. Its also sets out the nature of interfaces needed between infrastructure domains and within the infrastructure network domain.
 
The present document does not provide any detailed specification but makes reference to specifications developed by other bodies and to potential specifications, which, in the opinion of the NFV ISG could be usefully developed by an appropriate standards developing organisation (SDO).

The present document outlines the requirements for integrity and authenticity protection by signing VNF Package artifacts and verifying these artifacts during instantiation. The present document also considers the confidentiality of VNF Package artifacts and outlines a process for the service provider to provide confidentiality during onboarding. The present document expands on requirements for security and integrity of a VNF Package that is defined in ETSI GS NFV-IFA 011, clause 6.2.4 and ETSI GS NFV-SOL 004, clause 5.
 
VNF Package security validation check during the onboarding is a crucial factor for the successful deployment of VNFs. During the onboarding, the authenticity and integrity of the VNF Package is verified against the signature provided by the VNF provider. There are more potential ways to exploit the VNF Packages while it is in the NFV- MANO domain (i.e. while the VNF package is stored within different NFV-MANO catalogues). The existing methods do not ensure that the operator has the opportunity and means to authorize VNF Packages for deployment on their network (e.g. avoid a VNF intended for one deployment scenario with a valid VNF provider certificate being loaded by an attacker into another network operator's catalogue). Furthermore, some operators might wish to undertake additional security validation of the VNF Package during the onboarding process and operator's signing could be used to certify the VNF as authorized to onboard into the operator's network.

The present document defines the access tokens and related metadata for RESTful protocols and data model for ETSI NFV management and orchestration (MANO) interfaces. It defines also the process for the token verification by the API Producer.
 
For this aim, the present document:

• Analyses the security threat arising from the misuse of the access token and defines the security requirements associated to access token.
• Analyses existing specifications related to access token for API access and their compliancy with the requirements defined.
• Defines the token request and generation profile, the token format and associated metadata considering the result of existing access token specifications analysis.
• Defines the token verification procedures for the API Producer.