Cloud computing

Available (315)

Showing 217 - 228 per page



Study Group 11 - Signalling requirements, protocols and test specifications

ITU-T Study Group 11 (SG11) is responsible for 'signalling', producing international standards (ITU-T Recommendations) that define how telephone calls and other calls (such as data calls) are handled in the network.
 
SG11 is home to Signaling System 7 (SS7), the set of signalling protocols that underpins telephone calls in both fixed and mobile networks, without which telecom systems around the world would not interoperate. All telephone switching systems need signalling. It provides the means for monitoring the status of a line to see if it is busy or idle, the alerts that indicate the arrival of a call, and the addressing system that routes calls. Before SS7's implementation, not all nations were party to the standards agreements enabling international telephone calls. SS7's implementation thus paved the way for the efficient operation of international telecommunication networks.
 
SG11 is tasked with developing signalling requirements and protocols for Software-defined Networking (SDN), and this work aligns with the functional requirements and architectures developed by ITU-T Study Group 13 (Future networks). Considered a major shift in networking technology, SDN will give network operators the ability to establish and manage new virtualized resources and networks without deploying new hardware technologies. ICT market players see SDN and network virtualization as critical to countering the increases in network complexity, management and operational costs traditionally associated with the introduction of new services or technologies.
 
SG11 is also responsible for the development of test specifications. This work focuses on global interoperability testing and covers technical means, services, quality of service (QoS) and testing parameters. Activities encompass establishing benchmark testing procedures and investigating the testing of next-generation networks (NGN), ubiquitous sensor networks (USN) and emerging technologies such as the internet of things (IoT), distributed service network (DSN), home networking (HN), etc.
 
SG11 leads ITU’s work on conformance and interoperability (C&I) testing and is responsible for coordinating ITU’s C&I programme. Conformance with international standards is one of the core principles underlying the global interoperability of ICT networks and devices. The C&I programme was initiated at the request of ITU’s membership in light of the challenges faced by developing countries in improving interoperability. The programme rests on four central pillars: conformance assessment; interoperability events; human resource and capacity building; and assistance in the establishment of test facilities in developing countries. SG11 is also investigating whether the ITU C&I programme could play a role in battling counterfeit goods.
 
When meeting at ITU headquarters in Geneva, SG11 holds its meetings in collocation with SG13.

Joint Task Force Transformation Initiative Interagency Working Group

The Joint Task Force Transformation Initiative (JTFTI) is an Interagency Working Group working to produce a Unified Information Security Framework for the federal government. The JTFTI is made up of representatives from the Civil, Defense, and Intelligence Communities.
 
The Project Leader is Ron Ross of NIST.

OASIS Cloud Application Management for Platforms (CAMP) TC

The OASIS CAMP TC advances an interoperable protocol that cloud implementers can use to package and deploy their applications. CAMP defines interfaces for self-service provisioning, monitoring, and control. Based on REST, CAMP is expected to foster an ecosystem of common tools, plugins, libraries and frameworks, which will allow vendors to offer greater value-add.
 
Common CAMP use cases include:

  • moving on-premise applications to the cloud (private or public)
  • redeploying applications across cloud platforms from multiple vendors

For more information on CAMP, see the TC Charter.

Web Services Agreement Specification (WS-Agreement) Errata Update

This document describes Web Services Agreement Specification (WS-Agreement), a Web Services protocol for establishing agreement between two parties, such as between a service provider and consumer, using an extensible XML language for specifying the nature of the agreement, and agreement templates to facilitate discovery of compatible agreement parties. The specification consists of three parts which may be used in a composable manner: a schema for specifying an agreement, a schema for specifying an agreement template, and a set of port types and operations for managing agreement life-cycle, including creation, expiration, and monitoring of agreement states.
 
The goal of WS-Agreement is to standardize the terminology, concepts, overall agreement structure with types of agreement terms, agreement template with creation constraints and a set of port types and operations for creation, expiration and monitoring of agreements, including WSDL needed to express the message exchanges and resources needed to express the state.
 
During almost three years after the publication as GFD.107 in May 2007 a number of typos and formatting problems have been reported. None of them was affecting the normative part of the specification. This document is a revised version of GFD.107, which fixes all typos in the descriptive part of the document. The changes have been implemented during the GRAAP sessions at OGF 28 in Munich. Oliver Wäldrich, Philipp Wieder and Wolfgang Ziegler have prepared this version of the document.

GFD.192

WS-Agreement Negotiation Version 1.0

This document describes the Web Services Agreement Negotiation Specification (WS-Agreement Negotiation), a Web Services protocol for negotiating agreement offers between two parties, such as between a service provider and a service consumer. An agreement offer negotiation may then result in the creation of an agreement using the WS-Agreement specification (published as GFD.192). WS-Agreement Negotiation can also be used to renegotiate an existing agreement.
 
WS-Agreement Negotiation provides an additional layer to create agreements with WS-Agreement. To achieve this, it defines an extensible XML language for specifying agreement offers and agreement templates. These templates are WS-Agreement-compliant and include a negotiation context and a set of negotiation constraints that are used for the negotiation. The specification includes all schemas required for the negotiation and the necessary port types.
 
All information for creating, managing, and monitoring an agreement is not described in this document but in the WS-Agreement specification.

GFD.193

Distributed Resource Management Application API Version 2.2 (DRMAA)

This document describes the Distributed Resource Management Application API Version 2 (DRMAA). It defines a generalized API to Distributed Resource Management (DRM) systems in order to facilitate the development of portable application programs and high-level libraries.
 
The intended audience for this specification are DRMAA language binding designers, DRM system vendors, high-level API designers and meta-scheduler architects. Application developers are expected to rely on product-specific documentation for the DRMAA API implementation in their particular DRM system.
 
The Distributed Resource Management Application API Version 2 (DRMAA) specification defines an interface for tightly coupled, but still portable access to Distributed Resource Management (DRM) systems. The scope is limited to job submission, job control, reservation management, and retrieval of job and machine monitoring information.
 
This document acts as root specification for the abstract API concepts and the behavioral rules of a DRMAA- compliant implementation. The programming language representation of the API is defined by a separate language binding specification.

GFD.231

Distributed Resource Management Application API Version 2.2 (DRMAA) C Language Binding.

This document describes the C language binding for the Distributed Resource Management Application API Version 2 (DRMAA). The intended audience for this specification are DRMAA implementors.
 
The Distributed Resource Management Application API Version 2 (DRMAA) specification defines an inter- face for tightly coupled, but still portable access to the majority of DRM systems. The scope is limited to job submission, job control, reservation management, and retrieval of job and machine monitoring information.
 
The DRMAA root specification describes the abstract API concepts and the behavioral rules of a compliant implementation, while this document standardizes the representation of API concepts in the C programming language.

GFD.230

Data Format Description Language (DFDL) v1.0 Specification

This document provides a definition of a standard Data Format Description Language (DFDL). This language allows description of text, dense binary, and legacy data formats in a vendor- neutral declarative manner. DFDL is an extension to the XML Schema Description Language (XSDL).
 
DFDL is a language for describing data formats. A DFDL description allows data to be read from its native format and to be presented as an instance of an information set or indeed converted to the corresponding XML document. DFDL also allows data to be taken from an instance of an information set and written out to its native format.
 
DFDL achieves this by leveraging W3C XML Schema Definition Language (XSDL) 1.0.
 
An XML schema is written for the logical model of the data. The schema is augmented with special DFDL annotations. These annotations are used to describe the native representation of the data. This is an established approach that is already being used today in commercial systems.

GFD.207

OCCI 1.2 - Open Cloud Computing Interface – Core

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.

GFD.221

OCCI 1.2 - Open Cloud Computing Interface – Templates Profile

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 defines the OCCI Infrastructure Compute resource template profile 1.1 (hereafter, “the Profile”), consisting of a set of well defined instances of the OCCI compute resource types. Section 1 introduces the Profile, and explains its relationships to other profiles. Section 2, "Profile Conformance," explains what it means to be conformant to the Profile.
Each subsequent section addresses a component of the Profile, and consists of two parts: an overview detailing the component specifications and their extensibility points, followed by subsections that address individual parts of the component specifications. Note that there is no relationship between the section numbers in this document and those in the referenced specifications.

GFD.222

OCCI 1.2 - Open Cloud Computing Interface – HTTP Protocol

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 specifies the OCCI HTTP Protocol, a RESTful protocol for communication between OCCI server and OCCI client. The OCCI HTTP Protocol support multiple different data formats as payload. Data formats are specified in separate documents.

GFD.223

OCCI 1.2 - Open Cloud Computing Interface – Infrastructure

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 Infrastructure document details how an OCCI implementation can model and implement an Infrastructure as a Service API offering by utilizing 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 that represents an L2 networking resource. This is complemented 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 is complemented by an IPNet- workInterface Mixin.
    • StorageLink connects a Compute instance to a Storage instance.
GFD.224