Cloud computing

ATIS Standard ATIS-0200003 [https://global.ihs.com/doc_detail.cfm?&csf=ASA&input_doc_number=%20&inpu... provided initial use cases and requirements for Content Distribution Network (CDN) Interconnection between two CDN providers via Cache-based Unicast delivery method – software download was the selected content type to drive these initial use cases and requirements. ATIS Standard ATIS-0200004 [https://global.ihs.com/doc_detail.cfm?&csf=ASA&input_doc_number=%20&inpu... developed use cases and requirements for content distribution via Multicast-based delivery.
In a multi-party Federated environment (multiple Service Providers (SP) acting as CDN Providers), CDN interconnections require additional functionality from service providers beyond the straightforward interconnection of IP transport networks. The interconnection and federation of CDN Providers is expected to evolve through a series of content distribution services. These services can be provided by a variety of different mechanisms including:

• Cache-based http unicast.
• Multicast.
• Publish subscribe mechanisms (e.g., RSS or named-data information-centric content routing).
• Content aggregation (e.g., from machine-machine interconnection).

The selection of the delivery method depends on the nature and type of content that is being requested for delivery¹
Thus, the purpose of this ATIS Standard is to extend the use cases and requirements developed in ATIS- 020000] and ATIS-0200004 for an environment involving multiple CDN providers joining together to form a CDN Federation with multiple available methods of content delivery. The interconnection life cycle use cases and requirements are re-examined for the impact arising from a Federation of multiple CDN providers. Additional emphasis is placed on the interconnection domain functionality such that guidance on the eventual development of Network-Network Interconnect (NNI) architectures and supporting protocol requirements can be derived.
Accordingly, the scope of this document includes the following:

• Multiple SPs forming a CDN Federation for the purpose of distributing content from Content Providers (CP) to End Users (EU) that individually request the content delivery. The multi-party Federation is strictly limited to a fully meshed structure where each SP/CDN Provider directly engages with other SPs/CDN Providers for the purpose of content distribution. Other structures are excluded from consideration in this document. Examples of alternate and/or add-on structures include the presence of a third party broker/exchange as well as the role of SPs who are not Federation members but who have independent agreements for assisting in content delivery with individual Federation members (see section 5). These alternate/add-on structures are for further study.
• Life cycle interactions are re-examined from the perspective of a Multi-Party Federation environment (see section 6)
• The delivery methods are restricted to cache/unicast (section 7) and multicast methods (section 8). All content types that can be delivered by these methods are in scope.
• Logical functionality associated with interconnection domains between pairs of CDN Providers are examined in detail (section 9). Appropriate requirements are derived in support of these functions.

Finally it should be noted that the protocol development work supporting all CDN-I functionality is being developed in the IETF. Appendix A provides a brief summary of this work.
¹An infinite length stream, for example, might be best suited to multicast delivery. Files of various sizes may be suitable for cache-based delivery. Finally, small content units may be appropriate for aggregation and delivery service.

The Cloud Security Alliance Cloud Controls Matrix (CCM) is specifically designed to provide fundamental security principles to guide cloud vendors and to assist prospective cloud customers in assessing the overall security risk of a cloud provider. The CSA CCM provides a controls framework that gives detailed understanding of security concepts and principles that are aligned to the Cloud Security Alliance guidance in 13 domains. The foundations of the Cloud Security Alliance Controls Matrix rest on its customized relationship to other industry-accepted security standards, regulations, and controls frameworks such as the ISO 27001/27002, ISACA COBIT, PCI, NIST, Jericho Forum and NERC CIP and will augment or provide internal control direction for service organization control reports attestations provided by cloud providers.

The Cloud Trust Protocol (CTP) is designed to be a mechanism by which cloud service customers can ask for and receive information related to the security of the services they use in the cloud, promoting transparency and trust.

The CTP document focuses on the definition of the CTP Data Model and Application Programming Interface (API), including:

• The format of CTP messages exchanged between cloud service customers and providers.
• The modelling of concepts such as “security attributes”, “objectives”, “measurement results” and “triggers” in machine readable  format.
• The means to define the scope of the service to which CTP monitoring queries apply.

However, the document does not provide a specification of the “security attributes” (and associated metrics) that are queried by CTP. Such a specification will be provided by the Cloud Security Alliance in a separate document, and will likely be influenced by upcoming standards such as [ISO_19086]. CTP also offers implementers the choice to define and adopt their own set of security attributes and related metrics. This document is organised as follows.
Section 2 provides some key terms and definitions that are used throughout this document, borrowing from relevant key standards.
Section 3 offers a general introductory overview of CTP.
Section 4 describes the CTP data model, defining the main concepts that are used to represent security information related to cloud services in CTP.
Section 5 specifies the RESTful CTP API that implements the model described in section 4. It also specifies the CTPScript language used in “triggers” and “objectives” and describes when they should be evaluated.
Section 6 provides requirements and recommendations for securing the CTP API.

The goal of CloudAudit is to provide a common interface and namespace that allows cloud computing providers to automate the Audit, Assertion, Assessment, and Assurance (A6) of their infrastructure (IaaS), platform (PaaS), and application (SaaS) environments and allow authorized consumers of their services to do likewise via an open, extensible and secure interface and methodology. CloudAudit provides the technical foundation to enable transparency and trust in private and public cloud systems.

Privacy Level Agreement - Version 2 is intended to be used as an appendix to a Cloud Services Agreement, and to describe the level of privacy protection that the CSP will provide. While Service Level Agreements (“SLA”) are generally used to provide metrics and other information on the performance of the services, PLAs will address information privacy and personal data protection practices.

The PLA [V2] is based only on EU personal data protection mandatory legal requirements. Coherently, the Working Group has stripped away elements derived from best practices and recommendations from the PLA [V1] (see further the ‘Methodology’ section of the standards document), and further clarifies core mandatory legal requirements.

The acute need of the multitude of smart, end-user IoT devices and near-user edge devices to carry out, with minimal latency, a substantial amount of data processing and to collaborate in a distributed way, triggered technology advancements towards adaptive, decentralized computational paradigms that complement the centralized cloud computing model serving IoT networks.
Researchers, computer scientists, system and network engineers developed innovative solutions to fill the technological gaps. These solutions provide faster approaches that gain better situational awareness in a far more timely manner. Such solutions or computational paradigms are referred to as fog computing, mist computing, cloudlets4, or edge computing5,6. Since no consensus exists on distinction among these concepts at the time this document was created, the authors considered it imperative to provide a conceptual model that can be used by practitioners and researchers to facilitate meaningful conversations on the topic.
This document provides the conceptual model of fog computing and its subsidiary mist computing, and aims to place these concepts in relation to cloud computing7 and edge computing.
Additionally, the document introduces the notion of a fog node and the nodes federation model composed of both, distributed and centralized, often hierarhical clusters of fog nodes operating in harmony. This model is introduced as a building-block architectural approach for constructing, enhancing or expanding the fog and mist computing layers.
Furthermore, the document characterizes important aspects of fog computing and is intended to serve as a means for broad comparisons of fog computing capabilities, service models and deployment strategies, and to provide a baseline for discussion of what fog computing is and the way it may be used.
The capabilities, service types and deployment models form a simple taxonomy that is not intended to prescribe or constrain any particular method of deployment, service delivery, or business operation.

The NIST Cloud Computing Security Working group was created to achieve broad collaboration between Federal and private stakeholders in efforts to address the security-related concerns expressed by Federal managers. One of the tasks of the NIST Cloud Computing Working Group is to design a Cloud Computing Security Reference Architecture that supplements SP 500-292: NIST Cloud Computing Reference Architecture (RA) with a formal model and identifies the core set of Security Components recommended for building a successful and secure cloud computing Ecosystem. The document provides for an understanding of the security interdependencies of cloud services, Actors, and requirements that USG agency technical planning and implementation teams and agency procurement offices should identify and address in order to acquire cloud services with security levels that meets agency needs.
Under development
(The group seems to be dormant after 2013)

Cloud computing is described at a high, conceptual level in the two foundational standards ISO/IEC 17788 Cloud computing – Overview and vocabulary and ISO/IEC 17789 Cloud computing – Reference Architecture.
However, as the use of cloud computing has grown, a set of commonly used technologies has grown to support, simplify and extend the use of cloud computing alongside sets of commonly used techniques which enable the effective exploitation of the capabilities of cloud services. Many of these common technologies and techniques are aimed at developers and operations staff, increasingly linked together in a unified approach called DevOps. The aim is to speed and simplify the creation and operation of solutions based on the use of cloud services.
This document aims to describe the common technologies and techniques which relate to cloud computing, how they relate to each other and how they are used by some of the roles associated with cloud computing.
This document describes a series of technologies and techniques commonly used to build applications and systems using cloud computing. These include:
- Virtual Machines (VMs) and Hypervisors
- Containers and Container Management systems
- “Serverless" computing
- Microservices architecture and automation
- Platform as a Service systems and their architecture
- Storage services
- Security, Scalability and Networking as applied to the above cloud computing technologies

The purpose of this technical report is to expand on the description of the interactions between cloud service partners (CSNs) and cloud service customers (CSCs), and between CSNs and cloud service providers (CSPs).
Cloud computing is in a position to offer solutions to many emerging technologies, and it offers many benefits to all cloud service users (CSUs) and CSCs.  The broader requirement for cloud solutions is to ensure organizations have the best capabilities to fulfil their business missions.  This has helped to drive the adoption of cloud services and the marketplace is adjusting to the increasing demands.
In finding and applying appropriate solutions and leveraging the many benefits of using cloud services, many CSCs use multiple CSPs and various deployment models, and include a global network.  In using, sharing, and assessing data, an understanding and clarification of roles, activities and responsibilities will help to maintain the security, privacy, confidentiality and confidence of cloud services.
Interactions of CSCs and CSPs with the various CSNs have caused a degree of concern and confusion in the cloud service marketplace, in some cases causing harm to CSCs through inappropriate security controls and the lack of proper cloud service agreements relating to the cloud services being used. This is in part caused by an inadequate understanding of the relationships involved and by the lack of standards which might apply to those relationships.
Interactions between CSCs and CSPs have been described in detail in standards documents – ISO/IEC 17789 [2], 19941 [7], 27017 [11], 27018 [12] and the 19086 series. Interactions of CSNs, a key role in the cloud service environment, with CSCs and CSPs have not been described in similar detail. This TR is to provide guidance and descriptions for those interactions.
This document provides clarification of the concepts provided in ISO/IEC 17789, 19086, and 19941 regarding CSNs, and CSN interactions with CSCs and CSPs with the help of a few of exemplary market scenarios.  Building on an expanded description of sub-roles and activities, this document provides guidance on using cloud service agreements (CSA) and cloud service level agreements (cloud SLAs) to provide more clarity for CSN interactions. 
This document provides an overview of and guidance on interactions between cloud service partners (CSNs), specifically cloud service brokers, cloud service developers and cloud auditors, and other cloud service entities. In addition, the document describes how cloud service agreements (CSAs) and cloud service level agreements (cloud SLAs) should be used to address those interactions including the following:
Define Terms and concepts, and provide an overview for interactions between CSNs and CSCs and CSPs 
Description of types of CSN interactions
Description of interactions between CSNs and CSCs
Description of interactions between CSNs and CSPs
Elements of CSAs and Cloud SLAs for CSN interactions, both with CSPs and with CSCs
 
Under development

Edge computing is increasingly used in systems that deal with aspects of the physical world. Edge computing involves the placement of processing and data storage near or at the places where those systems interact with the physical world, which is where the "edge" exists. One of the trends in this space is the development of increasingly capable IoT devices (sensors and actuators), generating more data or new types of data, which data benefits from processing close to the place where it is generated.
Cloud computing is commonly used in systems that utilise edge computing. This can involve the connection of both devices and edge computing nodes to centralized cloud services. However, it is the case that the locations in which cloud computing is performed are increasingly distributed in nature, with cloud services being implemented in locations that are nearer to the edge, for the purpose of supporting usecases that demand such close placement for reasons of reducing latency or avoiding the need to transmit large volumes of data over networks with limited bandwidth.
This document aims to describe edge computing and the significant elements which contribute to the successful implementation of edge computing systems, with an emphasis on the use of cloud computing and cloud computing technologies in the context of edge computing, including the virtualization of compute, storage and networking resources.
It is useful to read this document in conjunction with the ISO/IEC TR 30164 Edge Computing (under development in SC 41 - Internet of Things and related technologies), which takes a view of edge computing from the point of view of IoT systems and the IoT devices which interact with the physical world.
The scope of this technical report is to investigate and report on the concept of Edge Computing, its relationship to Cloud Computing and IoT, and the technologies that are key to the implementation of Edge Computing.  This report will explore the following topics with respect to Edge Computing:
- Concept of Edge Computing Systems
- Architectural Foundation of Edge Computing
- Edge Computing Terminology
- Software Classifications in Edge Computing – for example: firmware, services, applications 
- Supporting technologies such as Containers, Serverless, Microservices
- Networking for edge systems, including virtual networks
- Data – data flow, data storage, data processing in edge computing
- Management – of software, of data and of networks, resources, quality of service
- Virtual placement of software and data, and metadata
- Security and Privacy
- Real Time
- Mobile Edge Computing, Mobile Devices
 
Under development

As the adoption of cloud computing expands and the market grows, cloud service providers (CSPs) offer many different solutions of cloud services that can be classified as infrastructure, platform and application capabilities. Inevitably, CSPs, in designing solutions to meet the functionalities of cloud service customers (CSCs), put together diverse metering elements and billing modes that complement the cloud services offered to cloud service customers (CSCs).  It is challenging for CSCs to determine the differences of many diverse metering elements and billing modes from various CSPs as they navigate their journey to adopt cloud computing.
Measured service is one of the key characteristics of cloud computing (ISO/IEC 17788).  The feature is that a CSC may only be charged for the resources used.  To this end, it is necessary that usage can be monitored, controlled, reported, and billed for delivered cloud service.  Metering elements can be given and classified according to its cloud capabilities type.  Reasonable and scientific metering and billing results can be easily achieved if common operation practices apply.
The purpose of this TR is to provide basic clarity and guidance through a sample set of cloud service metering elements and billing elements for different cloud service capability types, including a discussion on billing function component and metering which is one of four main parts of billing function component. Such a sample set of metering and billing elements can help CSP better describe its billing and metering exercise, and can help CSC better understand the situation in order to make informed decisions.
The scope of this document is to describes a sample set of cloud service metering and billing elements.
 
Under development

This document establishes a set of building blocks (concepts, terms and definitions, including Data Level Objectives and Data Qualitative Objectives) that can be used to create Data Sharing Agreements  (DSAs). This document is applicable to DSAs where the data is intended to be processed using one or more cloud services or other distributed platforms.
 
Under development