The ATIS Cloud Services Forum is examining a number of services that establish the foundation for development, operations, deployment, and management of cloud-based services. These include content delivery, telepresence, and virtual desktop. Video services, including the already-present one-way and growing two-way communications, will be a substantial catalyst for additional growth and expansion of the Internet. Telepresence services provide a business model and architectural model that are foundational to cloud services, and provide important elements of the Cloud Services Data Model for Cloud Service Enablers. This specification focuses on telepresence services, recognizing that telepresence services are an integral part of a broader unified communications solution set.
There are many aspects of the telepresence service. This is an evolving document establishing a foundation for continuing work efforts. The specification explores a provider-agnostic and product-agnostic implementation, and will consider two primary aspects of the telepresence service that are detailed here by the examination of use cases deployed today and those resulting in the application of "the cloud" and other aspects of business and technology architecture guiding service evolution in the future. First, a description of the telepresence service is provided. Second, a more detailed description of the two key aspects of the telepresence service is provided. Topics 2f and 2g detail aspects of telepresence interconnectivity which will be addressed in a future specification.
Virtual desktop services enable enterprise IT organizations to logically centralize desktop resources so as to reduce desktop management costs and support any-device, any-network access to desktops by end-users. The emergence of Virtual Desktop Infrastructure as a service additionally allows enterprise IT organizations to take advantage of cloud resources instead of building their own infrastructures. As a result, enterprises can further reduce IT costs.
This document describes the virtual desktop (VD) requirements for enterprise services and specifies a federation framework for deploying VD services across multiple networks and administrative domains. In particular, the framework allows cloud service providers to host VD services for enterprises and at the same time maintain seamless network connectivity to enterprise resources. For the sake of end-user experience, it is essential that VD sessions can be transparently moved between data centers or between service providers without compromising security and isolation. Such transparent migration of VD session poses significant requirements on the underlying networks, which are also addressed by this document.
With the emergence of Cloud Services spanning one or many cloud infrastructures managed by various providers, it is imperative that a checklist be developed that provides cloud services lifecycle guidance/requirements for service providers/developers as they integrate these lifecycle functions.
The goal driven checklist is to be developed with the purpose to facilitate the following six lifecycle functions from a cloud service provider. These lifecycle functions can be aggregated in the three categories of build, capture, and modify to facilitate a simpler description of the goals.
Assessment and acceptance (i.e., build) of services onto the cloud platform/infrastructure.
Ongoing audit (i.e., capture) of services on the cloud platform/infrastructure.
Augmentation, abridging, and annulment (i.e., modify) of services within the cloud platform/infrastructure.
The goal of the checklist is to realize greater efficiencies through formalization and automation of integrations between cloud service providers and their corollary actors during the cloud services lifecycle. While the focus in this document is on the cloud services lifecycle, note that the unique goal oriented approach and related paradigms described herein could also be applied elsewhere.
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 delivery1
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. 1An 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.
This document defines a set of Fetch metadata request headers that aim to provide servers with enough information to make a priori decisions about whether or not to service a request based on the way it was made, and the context in which it will be used.
This specification defines an API enabling the creation and use of strong, attested, scoped, public key-based credentials by web applications, for the purpose of strongly authenticating users. Conceptually, one or more public key credentials, each scoped to a given WebAuthn Relying Party, are created by and bound to authenticators as requested by the web application. The user agent mediates access to authenticators and their public key credentials in order to preserve user privacy. Authenticators are responsible for ensuring that no operation is performed without user consent. Authenticators provide cryptographic proof of their properties to Relying Parties via attestation. This specification also describes the functional model for WebAuthn conformant authenticators, including their signature and attestation functionality
This specification defines an API enabling the creation and use of strong, attested, scoped, public key-based credentials by web applications, for the purpose of strongly authenticating users. Conceptually, one or more public key credentials, each scoped to a given WebAuthn Relying Party, are created by and bound to authenticators as requested by the web application. The user agent mediates access to authenticators and their public key credentials in order to preserve user privacy. Authenticators are responsible for ensuring that no operation is performed without user consent. Authenticators provide cryptographic proof of their properties to Relying Parties via attestation. This specification also describes the functional model for WebAuthn conformant authenticators, including their signature and attestation functionality.
This specification describes an imperative API enabling a website to request a user’s credentials from a user agent, and to help the user agent correctly store user credentials for future use.
This document defines a mechanism by which web developers can control the resources which a particular page can fetch or execute, as well as a number of security-relevant policy decisions.
This document defines an imperative mechanism which allows web developers to instruct a user agent to clear a site’s locally stored data related to a host.
The Permissions Standard defines common infrastructure for other specifications that need to interact with browser permissions. It also defines an API to allow web applications to query and request changes to the status of a given permission.
