Cloud computing

The present document has been developed to describe the security and trust guidance that is unique to NFV development, architecture and operation. Guidance consists of items to consider that may be unique to the environment or deployment. Supplied guidance does not consist of prescriptive requirements or specific implementation details, which should be built from the considerations supplied.
 
Guidance is based on defined use cases, included in the present document, that are derived from the Security Problem Statement and are unique to NFV. Relevant external guidance will be referenced, where available.

The present document provides a problem statement on implementing LI in NFV and identifies the necessary capabilities to be provided in NFV to meet the requirements outlined for telecommunications capabilities in general in ETSI TS 101 331.
 
The present document identifies the challenges of providing LI in an NFV. The present document is intended to give guidance to the NFV community and to the wider LI community on the provision of LI in an NFV.

The present document is a guide to developers of NFV related documents and applications in means to address the security aspects and regulatory concerns as they impact the security of deployed networks that conform with these documents and applications. The present document contains detailed descriptions of security concerns, attacks, as well as an overview of regulatory concerns and how they can be treated in system design to give the highest level of assurance that the resultant system is secure and complies with current regulation and best practice. The present document is intended for use by developers of NFV documents and the guidance is given in a manner that assists non-experts in security and regulation to prepare such documents.
 
In addition to the guidance and explanatory text the present document contains, in annex A, a pro forma template for use in ETSI ISG NFV documents to capture the security concerns and mitigations that apply.

The present document addresses multi-layer administration use cases and technical approaches, an issue identified in the Security Problem Statement, ETSI GS NFV-SEC 001. Multi-layer administration seeks to provide methods, capabilities, procedures and assurances - of various strengths based on requirements and available technologies and techniques - that safeguard Virtual Machines or Containers running on a virtualisation host ("hosted applications") - from interference (of various types) by the host system or platform ("hosting service”).
 
The scope of the present document is generally the system comprising the hosting service, associated hardware (including TPM, GPU, etc.), software and configuration, and the hosted application. Some requirements and measures outside this context are also considered, but not necessarily in equal depth.

The present document is designed to support Retained Data functionality. For the present document, "Retained Data functionality" is defined as situations in which CSPs, or their equivalent in NFV provisioning architectures, are performing the following tasks:

1. store data (either in their existing business stores, or in dedicated stores of data); and
2. at a later point, when presented with an appropriate request, make available the data that meets the request to the appropriate authority.

The present document is not a legal document. It does not define when or whether these tasks should take place, nor does it define what counts as an appropriate request or appropriate authority. The definition of what is or is not a "Communications Service Provider" (from the point of view of Retained Data) is out of scope. It is a pre-requisite to the present document that Retained Data functionality is in line with appropriate and relevant legislation on privacy and data protection.
 
The term "Data" in the present document is used to describe information which is collected, stored or queried as part of Retained Data functionality.
 
NOTE: In some jurisdictions, Retained Data may include "customer or subscriber data" (i.e. records with information about the customer (e.g. name, address) and their subscription) and "usage data" (i.e. records describing how the service was used). This note is included for background information but is not a definition.

The present document specifies a set of RESTful protocols and data models fulfilling the requirements specified in ETSI GS NFV-IFA 031 for the interfaces that enable the management of NFV-MANO functional entities.
It defines the protocol and data model for the interfaces used for the management of NFV-MANO functional entities, in the form of RESTful Application Programming Interface (APIs) specifications:

• NFV-MANO configuration and information management interface;
• NFV-MANO performance management interface;
• NFV-MANO fault management interface;
• NFV-MANO state management interface;
• NFV-MANO log management interface. The interfaces are produced by the NFV-MANO functional entity, which acts as API producer, and can be consumed by an authorized external entity, which acts as API consumer. For more information, clause 4.2 of ETSI GS NFV-IFA 031 defines the framework for the management of NFV-MANO.

ISG NFV has developed over 80 different reports and specifications for the virtualisation of network functions. NFV publications describe and specify virtualisation requirements, architecture framework, functional components and their interfaces, as well as the protocols and the APIs for these interfaces. ISG NFV also studies VNF performance, reliability, and resiliency matters, analyses the security challenges linked to virtualisation (trust, attestation, regulation). NFV specifies requirements for Management and Orchestration, for hardware acceleration, etc. And a lot is ongoing!

The goal of TC CLOUD is to address issues associated with the convergence between IT (Information Technology) and Telecommunications. The focus is on scenarios where connectivity goes beyond the local network. This includes not only Cloud computing but also the emerging commercial trend towards Cloud computing which places particular emphasis on ubiquitous network access to scalable computing and storage resources.
 
Since TC CLOUD has particular interest in interoperable solutions in situations which involve contributions from both the IT and Telecom industries, the emphasis is on the Infrastructure as a Service (IaaS) delivery model. TC CLOUD focuses on interoperable applications and services based on global standards and the validation tools to support these standards. Evolution towards a coherent and consistent general purpose infrastructure is envisaged. This will support networked IT applications in business, public sector, academic and consumer environments.
 
The approach is to complement existing activities in ETSI and other standards development organisations. TC CLOUD is expected to fulfil a specific role as a forum in which to develop consensus within the telecommunications sector which can then be represented in other bodies. It can also act to introduce new requirements into networking (e.g. NGN) standards which support new application paradigms such as Grid and Cloud.

The present document enumerates metrics for NFV infrastructure, management and orchestration service qualities that can impact the end user service qualities delivered by VNF instances hosted on NFV infrastructure. These service quality metrics cover both direct service impairments, such as IP packets lost by NFV virtual networking which impacts end user service latency or quality of experience, and indirect service quality risks, such as NFV management and orchestration failing to continuously and rigorously enforce all anti-affinity rules which increases the risk of an infrastructure failure causing unacceptable VNF user service impact. Performance relationships exist between the metrics described in this document and in other specifications such as draft-ietf-ippm-model-based-metrics-02 (work in progress) (February 2014): "Model Based Bulk Performance Metrics", M. Mathis and A. Morton.
 
The present document does not consider:

• Units of measurement for reporting, such as whether VM premature release rates should be expressed as hourly rate (e.g. 0,0001 premature VM release events per hour), annualized rate (e.g. 0,88 premature VM release events per year), hours between events (e.g. 10 000 hour mean time between premature release events), or events per other unit of time (e.g. 100 000 FITs, meaning 100 000 premature release events in one billion hours of operation).
• Methods of Measurement which stipulate exactly how metrics will be measured.
• Rigorous counting and exclusion rules, like the precise details given in the TL 9000 Measurements Handbook TL 9000 Measurements Handbook, release 5.0, July 2012, QuestForum (http://www.tl9000.org/handbooks/measurements_handbook.html)
• Metrics that do not directly or indirectly impact VNF user service quality, like power efficiency.

The present document describes how Network Functions Virtualisation (NFV) related interfaces and abstractions are to be derived and specified. It describes the concepts associated with these interfaces and abstractions. It covers the specification process / methodology in general. It presents a cross-cutting framework which covers compute, hypervisor and infrastructure network domains, also data, control and management planes.
 
The present document does not specify all the interfaces and abstractions as these are covered by other documents, e.g. the NFV INF domain specific documents. Examples of interfaces and abstractions are nevertheless supplied to illustrate the methodology.
 
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 development organization (SDO). Furthermore the NFV INF domain specific documents will not provide detailed specifications either.

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 presents the architecture of the Hypervisor Domain of the NFV Infrastructure which supports deployment and execution of virtual appliances. The present document will primarily focus on the use of hypervisor for virtualisation, due to time and resource constraints, However, the hypervisor requirements are similar if not the same for implementing linux containers or other methods for virtualisation.
 
NOTE: From WikiArch: "Linux Containers (LXC) are an operating system-level virtualisation method for running multiple isolated server installs (containers) on a single control host. LXC does not provide a virtual machine, but rather provides a virtual environment that has its own process and network space. It is similar to a chroot, but offers much more isolation".
 
There needs to be further research w.r.t to Linux Containers, including developing the ecosystem.
 
As well as presenting a general overview description of the NFV Infrastructure, the present document sets the NFV infrastructure and all the documents which describe it in the context of all the documents of the NFV. It also describes how the documents which describe the NFV infrastructure relate to each other.
 
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).