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).
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.
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.
The purpose of this group is the creation of a practical solution to interface with Cloud infrastructures exposed as a service (IaaS). We will focus on a solution which covers the provisioning, monitoring and definition of Cloud Infrastructure services. The group should create this API in an agile way as we can have advantages over other groups if we deliver fast. Overlapping work and efforts will be contributed and synchronized with other groups.
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.
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.
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.
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 defines the artifacts and APIs that need to be offered by a Platform as a Service (PaaS) cloud to manage the building, running, administration, monitoring and patching of applications in the cloud. Its purpose is to enable interoperability among self-service interfaces to PaaS clouds by defining artifacts and formats that can be used with any conforming cloud and enable independent vendors to create tools and services that interact with any conforming cloud using the defined interfaces. Cloud vendors can use these interfaces to develop new PaaS offerings that will interact with independently developed tools and components.
This document defines the artifacts and APIs that need to be offered by a Platform as a Service (PaaS) cloud to manage the building, running, administration, monitoring and patching of applications in the cloud. Its purpose is to enable interoperability among self-service interfaces to PaaS clouds by defining artifacts and formats that can be used with any conforming cloud and enable independent vendors to create tools and services that interact with any conforming cloud using the defined interfaces. Cloud vendors can use these interfaces to develop new PaaS offerings that will interact with independently developed tools and components.
The following is a non-exhaustive list of the use cases which are supported by this specification.
Building and packaging an application in a local Application Development Environment (ADE)
Building an application in an ADE running in the cloud
Importing a Platform Deployment Package into the cloud
Uploading application artifacts into the cloud
Run, stop, suspend, snapshot, and patch an application
The present document focuses on unique aspects related to network and service resiliency in a virtualised network environment. The challenges result from failures of virtualised network functions, failures of the underlying hardware and software infrastructure arising from conditions such as design faults, intrinsic wear out, operational mistakes, or other adverse conditions, e.g. natural disasters, excessive traffic demand, etc.
The scope of the present document includes:
Usecase analysis for reliability and availability in a virtualised network environment.
Analysis of service availability levels.
Identification of requirements for maintaining network resiliency and service availability, the focus being additional requirements introduced by virtualisation. The mechanisms to be considered include the following:
Network function migration within and across system boundaries.
Failure detection and reporting at the various layers.
Failure prediction, prevention, and remediation.
State management.
Solving network availability issues caused by overload/call blocking conditions.
Engineering and deployment guidelines for maintaining network resiliency and ensuring service availability.
The present document specifies the interface requirements, the interfaces and the necessary information elements enabling the fault, configuration and information, performance, state and log management of NFV-MANO functional entities.
In addition, the present document also describes the framework to support the management of NFV-MANO functional entities.
The different aspects specified in the present document have been analysed firstly in ETSI GR NFV-IFA 021
Trust, as defined in ETSI GR NFV-SEC 003, is an important component of security. One weakness of software as opposed to hardware, is that software can be copied in whole or in part. Trust that is rooted in software may be less reliable than trust rooted in hardware, quickly, easily, and any number of times. For the particular case of sensitive workloads that have to be trusted, only the highest assurance in the root of trust is considered acceptable, thus for the purposes of the present document the root of trust shall be provided in hardware.
There is, however, a concomitant concern that when a device is subject to black box testing, it is impossible to determine if the responses to interrogation come from hardware or software. To counter this, a NFVI vendor shall be able to provide evidence on demand that the root of trust is a hardware element. The means by which the vendor provides such evidence is not considered in the present document but should be mutually agreed between the vendor and operator.
A vendor shall be able to provide evidence on demand to authorized parties of the security claims for the root of trust. The means by which the vendor provides such evidence is not considered in the present document, but should be mutually agreed between the vendor and operator. An examples of 3rd a party assurance programme is Common Criteria (defined in ISO/IEC 15408).
The host system, acting as a black box (closed) environment, shall provide access to authorized external entities only to those capabilities identified in the authorization agreement.
