diff --git a/doc/ref_model/README.md b/doc/ref_model/README.md index eef59248..59446111 100644 --- a/doc/ref_model/README.md +++ b/doc/ref_model/README.md @@ -4,22 +4,22 @@

** Note: This is a live (not released) document and is being updated regularly.

## Current Release -**Release: --** +**Release: 1.0** ## Current Version -**Version: 0.9** +**Version: 1.0** ## Overall Status | Chapter | Status | | --- | --- | -| Chapter 01 | Lots of SME feedback | -| Chapter 02 | Still Developing Content | +| Chapter 01 | Still Developing Content | +| Chapter 02 | Lots of SME feedback | | Chapter 03 | Lots of SME Feedback | -| Chapter 04 | Dickering over the fine points | +| Chapter 04 | Lots of SME feedback | | Chapter 05 | Lots of SME Feedback | | Chapter 06 | Lots of SME Feedback | -| Chapter 07 | Lots of SME Feedback | +| Chapter 07 | Still Developing Content | | Chapter 08 | Initial Framework Only | | Chapter 09 | Initial Framework Only | | Chapter 10 | Initial Framework Only | @@ -30,8 +30,8 @@ * [Chapter 02 - VNF requirements & Analysis](chapters/chapter02.md) * [Chapter 03 - Infrastructure Abstraction](chapters/chapter03.md) * [Chapter 04 - Catalogue](chapters/chapter04.md) -* [Chapter 05 - Reference NFVI SW profiles and configurations](chapters/chapter05.md) -* [Chapter 06 - Reference NFVI HW profiles and configurations](chapters/chapter06.md) +* [Chapter 05 - NFVI SW profiles](chapters/chapter05.md) +* [Chapter 06 - NFVI HW profiles](chapters/chapter06.md) * [Chapter 07 - APIs & Interfaces](chapters/chapter07.md) * [Chapter 08 - Security](chapters/chapter08.md) * [Chapter 09 - Operations (OA&M)](chapters/chapter09.md) @@ -41,17 +41,17 @@ ## Contributors -| Item/Chapter | Lead | Contributors list | Priority | -|-------------------------------|------------------------------------------|-------------------|----------| -| Overall Document & Rapporteur | Rabi Abdel (abdel.rabi@vodafone.com) | | | -| Chapter 1 - Introduction | Beth Cohen (beth.cohen@one.verizon.com) | | 1 | -| Chapter 2 - VNF requirements and analysis | Ahmed ElSawaf (aelsawaf.c@stc.com.sa) | | 1 | -| Chapter 3 - Infrastructure Abstraction | Mark Shostak (Mark.Shostak@att.com) | 3.1 Bernard Tsai (Bernard.Tsai@telekom.de), 3.2 Tom Kivlin (tom.kivlin@vodafone.com) | 1 | -| Chapter 4 - Catalogue | Burak Kazan (burak.kazan@turkcell.com.tr) | | 1 | -| Chapter 5 - SW Config | Karine Sevilla (karine.sevilla@orange.com) | | 1 | -| Chapter 6 - HW Config | Pankaj Goyal (pg683k@att.com) | | 1 | -| Chapter 7 - API | Pankaj Goyal (pg683k@att.com) | | 1 (subset) | -| Chapter 8 - Security | Beth Cohen (beth.cohen@one.verizon.com) | | >1 | -| Chapter 9 - Operations | Mark Shostak (Mark.Shostak@att.com) | | >1 | -| Chapter 10 - Compliance and Verification | Rabi Abdel (abdel.rabi@vodafone.com) | | >1 | -| Chapter 11 - GAPS | JONATHAN BELTRAN (jb788y@att.com) | | >1 | +| Item/Chapter | Lead | Priority | +|-------------------------------------------|---------------------------------------------------------------------------------------------------------------------|------------| +| Overall Document & Rapporteur | Rabi Abdel (abdel.rabi@vodafone.com) | | +| Chapter 1 - Introduction | Beth Cohen (beth.cohen@one.verizon.com) | 1 | +| Chapter 2 - VNF requirements and analysis | Ahmed ElSawaf (aelsawaf.c@stc.com.sa) | 1 | +| Chapter 3 - Infrastructure Abstraction | Mark Shostak (Mark.Shostak@att.com), Bernard Tsai (Bernard.Tsai@telekom.de), Tom Kivlin (tom.kivlin@vodafone.com) | 1 | +| Chapter 4 - Catalogue | Burak Kazan (burak.kazan@turkcell.com.tr) | 1 | +| Chapter 5 - SW Config | Karine Sevilla (karine.sevilla@orange.com) | 1 | +| Chapter 6 - HW Config | Pankaj Goyal (pg683k@att.com) | 1 | +| Chapter 7 - API | Pankaj Goyal (pg683k@att.com) | 1 (subset) | +| Chapter 8 - Security | Beth Cohen (beth.cohen@one.verizon.com) | >1 | +| Chapter 9 - Operations | Mark Shostak (Mark.Shostak@att.com) | >1 | +| Chapter 10 - Compliance and Verification | Rabi Abdel (abdel.rabi@vodafone.com) | >1 | +| Chapter 11 - GAPS | JONATHAN BELTRAN (jb788y@att.com) | >1 | \ No newline at end of file diff --git a/doc/ref_model/chapters/chapter01.md b/doc/ref_model/chapters/chapter01.md index 3fe5d392..743945d4 100644 --- a/doc/ref_model/chapters/chapter01.md +++ b/doc/ref_model/chapters/chapter01.md @@ -3,22 +3,22 @@

scope

## Table of Contents -* [1.1 Overview.](#overview) -* [1.2 Problem Statement.](#problemstatement) +* [1.1 Overview.](#1.1) +* [1.2 Problem Statement.](#1.2) * [1.3 Terminology.](#1.3) * [1.3.1 Software layers terminology.](#1.3.1) * [1.3.2 Hardware layers terminology.](#1.3.2) * [1.3.3 Operational and administrative terminology.](#1.3.3) * [1.3.4 Other terminology.](#1.3.4) * [1.4 Principles.](#1.4) -* [1.5 Scope.](#scope) -* [1.6 Relations to other industry projects.](#relation) -* [1.7 How this document works.](#docu) -* [1.8 What this document is not covering.](#notcovering) -* [1.9 Bogo-Meter.](#bogometer) -* [1.10 Roadmap.](#roadmap) - - +* [1.5 Scope.](#1.5) +* [1.6 Relations to other industry projects.](#1.6) +* [1.7 How this document works.](#1.7) +* [1.8 What this document is not covering.](#1.8) +* [1.9 Bogo-Meter.](#1.9) +* [1.10 Roadmap.](#1.10) + + ## 1.1 Overview The main concept of NFV (Network Function Virtualization) is the ability to use general purpose computer hardware and platforms that run multiple VNFs (Virtualised Network Functions) and hence achieving the desired CapEx and OpEx savings. However, one of big challenges NFV is facing with VNF vendors is that vendors, while building or designing their virtualized services (whether it's VoLTE, EPC, or enterprise services like SD-WAN (Software Defined Wide Area Network)), must bring their own set of infrastructure requirements and custom design parameters. This attitude from vendors triggered the creation of various vendor/function specific silos which are incompatible with each other and have different operating models. In addition, this makes the onboarding and certification processes of VNFs (coming from different vendors) hard to automate and standardise. @@ -39,7 +39,7 @@ The benefits of this approach are: - Better utilization - Mapping VNFs to flavours which are properly mapped to IaaS will bring better utilization, than current VNFs expressing variety of instance types as their needs on IaaS. - + ## 1.2 Problem Statement Analysis of On-Boarding and On-Going Support of ‘i’ in relation to the VNF Challenges - Identified Long-Poles @@ -125,14 +125,14 @@ This section specifies the principles of infrastructure abstraction and profilin - NFVI resources are configured on behalf of VNFs through standard and open APIs. - NFVI resources are discovered/monitored by management entities (such as orchestration) through standard and open APIs. 1. VNFs should be modular and utilise minimum resources. -1. NFVI shall support pre-defined and parameterised T-Shirt sizes. +1. NFVI shall support pre-defined and parameterized T-Shirt sizes. - T-Shirt sizes will evolve with time. 1. NFVI provides certain resources, capabilities and features and vApps should only consume these resources, capabilities and features. 1. VNFs that are designed to take advantage of NFVI accelerations should still be able to run without these accelerations with potential performance impacts. 1. An objective of CNTT is to have a single, overarching Reference Model and the smallest number of Reference Architectures as is practical. Two principles are introduced in support of these objectives: - **Principle #1 – Minimize Architecture proliferation by stipulating compatible features be contained within a single Architecture as much as possible:** - - Features which are compatible, meaning they are not mutually exclusive and can coexist in the same NFVI instance, shall be incorporated into the same Reference Architecture. For example, IPv4 and IPv6 should be captured in the same Architecture, because they don’t interfere with each other + - Features which are compatible, meaning they are not mutually exclusive and can coexist in the same NFVI instance, shall be incorporated into the same Reference Architecture. For example, IPv4 and IPv6 should be captured in the same Architecture, because they don't interfere with each other - Focus on the commonalities of the features over the perceived differences. Seek an approach that allows small differences to be handled at either the low level design or implementation stage. For example, assume the use of existing common APIs over new ones. - **Principle #2 – Create an additional Architecture only when incompatible elements are unavoidable:** @@ -141,10 +141,10 @@ This section specifies the principles of infrastructure abstraction and profilin *Depending on the relationships and substitutability of the component(s) in question, it may be possible to mitigate component incompatibility by creating annexes to a single Architecture, rather than creating an additional Architecture. With this approach, designers at a Telco would implement the Architecture as described in the reference document and when it came to the particular component in question, they would select from one of the relevant annexes, their preferred option. For example, if one member wanted to use Ceph, and another member wanted to use Swift, assuming the components are equally compatible with the rest of the Architecture, there could be one annex for the Ceph implementation and one annex for the Swift implementation. - + ## 1.5 Scope -There are three level of documents needed to fulfill the CNTT vision. They are, as highlighted in **Figure 1-4**: **Reference Model**, **Reference Architecture**, and **Reference Implementation**. +There are three level of documents needed to fulfil the CNTT vision. They are, as highlighted in **Figure 1-4**: **Reference Model**, **Reference Architecture**, and **Reference Implementation**.

scope

Figure 1-4: Scope of CNTT

@@ -153,7 +153,7 @@ There are three level of documents needed to fulfill the CNTT vision. They are, - **Reference Architecture**: High level NFVI system components and their interactions to deliver on the Reference Model goals. It is expected that at least one, but not more than a few, Reference Architecture will conform to the Reference Model. - **Reference Implementation**: Focuses on the design and implementation of a NFVI Reference Architecture. Each Reference Architecture is expected to be implemented by at least one Reference Implementation. -This document foucuses on the **Reference Model**. **Figure 1-5** below highlights its scope in more details. +This document focuses on the **Reference Model**. **Figure 1-5** below highlights its scope in more details.

scope

Figure 1-5: Scope of Reference Model

@@ -169,7 +169,7 @@ This document specifies: - **Certification programs**: Define the requirement for certification programs for both VNFs and NFVI. - **Test framework**: Provide test suites to allow compliance, certification, and verification of VNFs and NFVI against the defined set of profiles. Part of the framework is also developing a reference implementation of the defined profiles (with the defined configurations0 to be used as a reference for compliance, certification, and verification of NFVI and VNFs. - + ## 1.6 Relations to other industry projects (clarify ETSI discussion re: what part of ETSI NFVi arch) Software Stack Model (Abstracted) @@ -182,22 +182,22 @@ A mapping of the functional blocks considered in that document to that NFV archi Following ETSI model, **Figure 1-6**, the VIM, Virtualised Infrastructure Manager, which controls and manages the NFVI, is not included into NFVI. Nevertheless, the interactions between NFVI and VIM will be part of this document as infrastructure resources management and orchestration have a strong impact on NFVI. These interactions will be detailed in Chapter 7 "API & Interfaces". - + ## 1.7 How this document works How to engage with it How the model links to reference - + ## 1.8 What this document is not covering Separate document w/labels/artifacts Not part of model but will be applicable to architecture - + ## 1.9 Bogo-Meter -A carefully chosen “Bogo-Meter” rating at the beginning of each chapter indicates the completeness and maturity each chapter’s content, at a glance. +A carefully chosen “Bogo-Meter” rating at the beginning of each chapter indicates the completeness and maturity each chapter's content, at a glance. - + ## 1.10 Roadmap -What’s next in further releases/what’s the backlog and priority roadmap +what's next in further releases/what's the backlog and priority roadmap diff --git a/doc/ref_model/chapters/chapter02.md b/doc/ref_model/chapters/chapter02.md index 82232f4f..c294cbfa 100644 --- a/doc/ref_model/chapters/chapter02.md +++ b/doc/ref_model/chapters/chapter02.md @@ -1,6 +1,6 @@ [<< Back](../../ref_model) # 2 VNF requirements & Analysis -

scope

+

scope

## Table of Contents * [2.1 VNFs collateral (Sample).](#collateral) diff --git a/doc/ref_model/chapters/chapter03.md b/doc/ref_model/chapters/chapter03.md index 4f530088..a2825d5c 100644 --- a/doc/ref_model/chapters/chapter03.md +++ b/doc/ref_model/chapters/chapter03.md @@ -1,6 +1,6 @@ [<< Back](../../ref_model) # 3 Infrastructure Abstraction -

bogo

+

bogo

## Table of Contents * [3.1 Model.](#model) @@ -14,53 +14,53 @@ There is the necessity to clearly define which kind of infrastructure resources a shared network function virtualisation infrastructure (NFVI) will provide for hosting workloads including virtual network functions (VNFs) and/or cloud-native network functions (CNF), so that the requirements of the workloads match the capabilities of the NFVI. -The lack of a common understanding of which resources and corresponding capabilities a suitable NFVI should provide may lead to several issues which could negatively impact the time and cost for on-boarding and maintaining these solutions on top of a virtualised infrastructure e.g.: +The lack of a common understanding of which resources and corresponding capabilities a suitable NFVI should provide may lead to several issues which could negatively impact the time and cost for on-boarding and maintaining these solutions on top of a virtualised infrastructure. For Example: - supporting any kind of workload specific requirements (e.g. regarding network acceleration or API access) might result in having to establish different silo NFVIs for each workload type. - synchronising the release cycles of a large set of different technologies will sooner or later lead to situations in which required upgrades cannot be applied easily due to incompatibilities. The abstraction model presented in this chapter specifies a common set of virtual infrastructure resources which a NFVI will need to provide to be able to host most of the typical VNF/CNF workloads required by the operator community. -Although a couple of explicit and implicit abstraction models (e.g. in the context of ETSI/NFV) are already available they fall short when addressing the following design principles: -- **Scope**: the model should describe the most relevant virtualised infrastructure resources (incl. acceleration technologies) an NFVI needs to provide for hosting Telco VNF workloads -- **Separation of Concern**: the model should support a clear distinction between the responsibilities related to maintaining the network function virtualisation infrastructure and the responsibilities related to managing the various VNF workloads -- **Simplicity**: the amount of different types of resources (including their attributes and relationships amongst one another) should be kept to a minimum to reduce the configuration spectrum which needs to be considered -- **Declarative**: the model should allow for a declarative description of the required NFVI capabilities for on-boarding and maintaining workloads -- **Explicit**: the model needs to be rich enough to allow for a direct mapping towards the APIs of NFVIs for the instantiation of virtual infrastructure elements without requiring any additional parameters -- **Lifecycle**: the model must distinguish between resources which have independent lifecycles but should group together those resources which share a common lifecycle -- **Aligned**: the model should clearly highlight the dependencies between the elements to allow for a well-defined and simplified synchronisation of independent automation tasks. +Although a couple of explicit and implicit abstraction models (e.g. in the context of ETSI/NFV) are already available, they fall short when addressing the following design principles: +- **Scope:** the model should describe the most relevant virtualised infrastructure resources (incl. acceleration technologies) an NFVI needs to provide for hosting Telco VNF workloads +- **Separation of Concern:** the model should support a clear distinction between the responsibilities related to maintaining the network function virtualisation infrastructure and the responsibilities related to managing the various VNF workloads +- **Simplicity:** the amount of different types of resources (including their attributes and relationships amongst one another) should be kept to a minimum to reduce the configuration spectrum which needs to be considered +- **Declarative:** the model should allow for a declarative description of the required NFVI capabilities for on-boarding and maintaining workloads +- **Explicit:** the model needs to be rich enough to allow for a direct mapping towards the APIs of NFVIs for the instantiation of virtual infrastructure elements without requiring any additional parameters +- **Lifecycle:** the model must distinguish between resources which have independent lifecycles but should group together those resources which share a common lifecycle +- **Aligned:** the model should clearly highlight the dependencies between the elements to allow for a well-defined and simplified synchronisation of independent automation tasks. To summarise: the abstraction model presented in this document will build upon existing modelling concepts and simplify and streamline them to the needs of telco operators who intend to distinguish between infrastructure related and workload related responsibilities. ## 3.1 Model -The abstraction model for the NFVI makes use of the following layers (only the virtual infrastructure layer will be directly exposed to workloads such as VNFs/CNFs): +The abstraction model for the NFVI makes use of the following layers (only the virtual infrastructure layer will be directly exposed to workloads (VNFs/CNFs)):

NFVI model_layers

-

Figure 3-1:Layers of the NFVI Model.

+

Figure 3-1: NFVI Model Layers.

The functionalities of each layer are as follows: -- Physical Infrastructure Resources: This layer consists of physical hardware components such as servers, (including random access memory, local storage, network ports, and hardware acceleration devices), storage devices, network devices, etc. and the basic input output system (BIOS). -- NFVI Software: This layer consists of both the host Operating System (OS) responsible for managing the physical infrastructure resources as well as the virtualization/containerization technology which, on request, dynamically allocates hardware components and exposes them as virtual resources. -- Virtual Infrastructure Resources: This layer represents all the infrastructure resources (compute, storage and networks) which the NFVI provides to the workloads such as VNFs/CNFs. These virtual resources can be managed by the tenants and tenant workloads directly or indirectly via an application programming interface (API). -- Workloads (VNFs/CNFs): This layer consists of workloads such as virtualized and/or containerized network functions that run on top of a VM or as a Container. The virtual infrastructure resources provided by the NFVI can be grouped into four categories as shown in the diagram in Figure 3-2. +- **Physical Infrastructure Resources:** This layer consists of physical hardware components such as servers, (including random access memory, local storage, network ports, and hardware acceleration devices), storage devices, network devices, etc. and the basic input output system (BIOS). +- **NFVI Software:** This layer consists of both the host Operating System (OS) responsible for managing the physical infrastructure resources as well as the virtualization/containerization technology which, on request, dynamically allocates hardware components and exposes them as virtual resources. +- **Virtual Infrastructure Resources:** This layer represents all the infrastructure resources (compute, storage and networks) which the NFVI provides to the workloads such as VNFs/CNFs. These virtual resources can be managed by the tenants and tenant workloads directly or indirectly via an application programming interface (API). +- **Workloads (VNFs/CNFs):** This layer consists of workloads such as virtualized and/or containerized network functions that run on top of a VM or as a Container. The virtual infrastructure resources provided by the NFVI can be grouped into four categories as shown in the diagram in Figure 3-2. The virtual infrastructure resources provided by the NFVI can be grouped into four categories as shown in the diagram below:

virtual_resources

Figure 3-2: Virtual Infrastructure Resources provides virtual compute, storage and networks in a tenant context.

-- Tenants: represent an independently manageable logical pool of compute, storage and network resources -- Compute resources: represent virtualised computes for workloads and Operating and other Systems as necessary -- Storage resources: represent virtualised resources for persisting data -- Network resources: represent virtual resources providing layer 2 and layer 3 connectivity +- **Tenants:** represent an independently manageable logical pool of compute, storage and network resources +- **Compute resources:** represent virtualised computes for workloads and Operating and other Systems as necessary +- **Storage resources:** represent virtualised resources for persisting data +- **Network resources:** represent virtual resources providing layer 2 and layer 3 connectivity The virtualised infrastructure resources related to these categories are listed below: ### Tenant -A network function virtualisation infrastructure needs to be capable of supporting multiple tenants and has to isolate sets of infrastructure resources dedicated to specific workloads (VNF/CNF) from one another. Tenants represent an independently manageable logical pool of compute, storage and network resources abstracted from physical hardware. **Example**: a tenant within an OpenStack environment or a Kubernetes cluster. +A network function virtualisation infrastructure (NFVI) needs to be capable of supporting multiple tenants and has to isolate sets of infrastructure resources dedicated to specific workloads (VNF/CNF) from one another. Tenants represent an independently manageable logical pool of compute, storage and network resources abstracted from physical hardware. **Example**: a tenant within an OpenStack environment or a Kubernetes cluster. | Attribute | Description | |-----------|---------------------------------------------------------------------------------------------------------| @@ -72,7 +72,7 @@ A network function virtualisation infrastructure needs to be capable of supporti | `networks` | description of external networks required for inter-domain connectivity | | `metadata` | key/value pairs for selection of the appropriate physical context (e.g. location, availability zone, …) | -

Table 3.1: Attributes of a tenant.

+

Table 3-1: Attributes of a tenant.

### Compute A virtual machine or a container/pod belonging to a tenant capable of hosting the application components of workloads (VNFs). A virtual compute therefore requires a tenant context and since it will need to communicate with other communication partners it is assumed that the networks have been provisioned in advance. **Example**: a virtual compute descriptor as defined in TOSCA Simple Profile for NFV. @@ -87,7 +87,7 @@ A virtual machine or a container/pod belonging to a tenant capable of hosting th | `acceleration` | key/value pairs for selection of the appropriate acceleration technology | | `metadata` | key/value pairs for selection of the appropriate redundancy domain | -

Table 3.2: Attributes of compute resources.

+

Table 3-2: Attributes of compute resources.

### Storage A block device of a certain size for persisting information which can be created and dynamically attached to/detached from a virtual compute. A storage device resides in a tenant context and exists independently from any compute host. **Example**: an OpenStack cinder volume. @@ -100,7 +100,7 @@ A block device of a certain size for persisting information which can be created | `acceleration` | key/value pairs for selection of the appropriate acceleration technology | | `metadata` | key/value pairs for selection of the appropriate redundancy domain | -

Table 3.3: Attributes of storage resources.

+

Table 3-3: Attributes of storage resources.

_**Comments**: we need to be more specific regarding acceleration and metadata._ @@ -113,7 +113,7 @@ A layer 2 / layer 3 communication domain within a tenant. A network requires a t | `subnet` | network address of the subnet | | `acceleration` | key/value pairs for selection of the appropriate acceleration technology | -

Table 3.4: Attributes of network resources.

+

Table 3-4: Attributes of network resources.

## 3.2 Exposed vs Internal @@ -125,7 +125,7 @@ The following pertains to the context of NFVI Capabilities, Metrics and Constrai Internal: Effectively the opposite of Exposed; objects Internal to the NFVI, which are exclusively available for use by the NFVI and components within the NFVI control plane.

Exposed vs. Internal Scope

-

Figure 3-3:Exposed vs. Internal Scope

+

Figure 3-3: Exposed vs. Internal Scope

As illustrated in the figure above, objects designated as "Internal" are only visible within the area inside the blue oval (the NFVI), and only when the entity accessing the object has the appropriate permissions. Whereas objects designated as "Exposed" are potentially visible from both the area within the green oval (the Workload), as well as from within the NFVI, again provided the entity accessing the object has appropriate permissions. @@ -136,7 +136,7 @@ Note: The figure above indicates the areas from where the objects are visible ### 3.3.1 Exposed NFVI capabilities -This section covers a list of explicit NFVI capabilities and metrics that define an NFVI. These capabilities and metrics are well known to VNFs as they provide capabilities which VNFs rely on. +This section describes a set of explicit NFVI capabilities and metrics that define an NFVI. These capabilities and metrics are well known to VNFs as they provide capabilities which VNFs rely on. > _**Note**: It is expected that NFVI capabilities and metrics will evolve with time as more capabilities are added as technology enhances and matures._ @@ -216,8 +216,6 @@ The intent of those metrics is to be well known to VNFs. | e.nfvi.per.met.003 | External (persistent) storage IO | iops | Range (min, max) per VNF-C | | e.nfvi.per.met.004 | External (persistent) storage throughput | MB/s | Range (min, max) per VNF-C | -[COMMENT - Xavier Grall, Orange: the mapping table is removed since there are reference values that depend on architecture and implementation, and/or may be derived for different cases (eg w/ or w/o filtering rules for network throughput) ] - The following shows performance metrics per VNF-C, vNIC or vCPU. | Ref | NFVI metric | Unit | Definition/Notes | @@ -230,7 +228,7 @@ The following shows performance metrics per VNF-C, vNIC or vCPU. | e.nfvi.per.met.006 | Storage throughput | bytes/s or IO/s | Max throughput per virtual block storage unit assigned to VNF-C | | e.nfvi.per.met.007 | Processing capacity | test-specific | Processing capacity test-specific score per vCPU | -

Table 3-xx: Exposed performance metrics of NFVI.

+

Table 3-11: Exposed performance metrics of NFVI.

#### 3.3.2.2 Exposed resource management metrics @@ -250,11 +248,11 @@ The following table shows resource management metrics as aligned with ETSI GR NF | e.nfvi.rmt.met.008 | Time to create virtual router | second | | | e.nfvi.rmt.met.009 | Time to create external storage | second | | -

Table 3-xx: Exposed resource management metrics of NFVI.

+

Table 3-12: Exposed resource management metrics of NFVI.

## 3.4 Internal NFVI capabilities metrics, and constraints -This section covers a list of implicit NFVI capabilities and metrics that define the interior of NFVI. These capabilities and metrics determines how NFVI behaves internally. They are hidden from VNFs (i.e. VNFs may not know about them) but they will have a big impact on the overall performance and capabilities of a given NFVI solution. +This section covers a list of implicit NFVI capabilities and metrics that define the interior of NFVI. These capabilities and metrics determine how the NFVI behaves internally. They are hidden from VNFs (i.e. VNFs may not know about them) but they will have a big impact on the overall performance and capabilities of a given NFVI solution. >_**Note**: It is expected that implicit NFVI capabilities and metrics will evolve with time as more capabilities are added as technology enhances and matures._ @@ -265,20 +263,30 @@ This section covers a list of implicit NFVI capabilities and metrics that define | Ref | NFVI capability | Unit | Definition/Notes | |--------------------|---------------------------------------------------------------------------|------------------------|---------------------------------------------------------------------------------------------------------------------| -| i.nfvi.res.cap.001 | Number of vCPU cores consumed by NFVI software in a single compute nodes. | % (of total available) | This indicates the number of vCPU cores consumed (wasted) by NFVI components (including host OS) in a compute node. | -| i.nfvi.res.cap.002 | Amount of memory consumed by NFVI software in a single compute nodes. | % (of total available) | This indicates the amount of memory consumed (wasted) by NFVI components (including host OS) in a compute node. | +| i.nfvi.res.cap.001 | Percentage of vCPU cores consumed by NFVI overhead in a compute node. | % (of total available) | Indicates the percentage of vCPU cores consumed (wasted) by NFVI components (including host OS) in a compute node. | +| i.nfvi.res.cap.002 | Percentage of memory consumed by NFVI overhead in a compute node. | % (of total available) | Indicates the percentage of memory consumed (wasted) by NFVI components (including host OS) in a compute node. |

Table 3-13: Internal resource capabilities of NFVI.

+ + +

Table 3-14: RESERVED

#### 3.4.1.2 Internal SLA capabilities -Table 13 below shows SLA (Service Level Agreement) capabilities available by NFVI. These include capabilities required by VNFs as well as internal capabilities to NFVI. These capabilities will be determined by the standard instance type used by VNF-C. +**Table 3-15** below shows SLA (Service Level Agreement) capabilities available by NFVI. These include capabilities required by VNFs as well as internal capabilities to NFVI. Application of these capabilities to a given workload is determined by its instance type (e.g. T-Shirt size). | Ref | NFVI capability | Unit | Definition/Notes | |--------------------|------------------------------------------|--------|---------------------------------------------------------------------------------------------------------------------| @@ -310,7 +318,7 @@ Table 13 below shows SLA (Service Level Agreement) capabilities available by NFV

Table 3-18: Mapping of Internal performance optimisation capabilities to NFVI instance types.

#### 3.4.1.4 Internal monitoring capabilities -**Table 3-19** shows possible monitoring capabilities available by NFVI. The availability of these capabilities will be determined by the instance type used by VNFs. +**Table 3-19** shows possible monitoring capabilities available by NFVI. The availability of these capabilities will be determined by the instance type used by the workloads. | Ref | NFVI capability | Unit | Definition/Notes | |--------------------|-------------------------------------------|--------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| @@ -402,7 +410,7 @@ Table 13 below shows SLA (Service Level Agreement) capabilities available by NFV

Table 3-24: Mapping of Internal resource management metrics to NFVI instance types.

#### 3.4.2.2 Internal performance Metrics -**Table 3-26** shows performance metrics of NFVI. Some of these metrics are related to what VNFs sees from the infrastructure and some of them are internal to NFVI. These metrics are aligned with ETSI GS NFV TST-009 [2]. +**Table 3-25** shows performance metrics of NFVI. Some of these metrics are exposed by the infrastructure to the workloads, and some are internal to the NFVI. These metrics are aligned with ETSI GS NFV TST-009 [2]. | Ref | NFVI metrics | Unit | Definition/Notes | |--------------------|------------------------------------------------------|----------------|----------------------------------------------------------------------| @@ -412,13 +420,18 @@ Table 13 below shows SLA (Service Level Agreement) capabilities available by NFV | i.nfvi.per.met.004 | Network Latency | ms | ETSI NFV-TST 009[2]. | | i.nfvi.per.met.005 | ephemeral storage IO | iops | Range (min, max) | | i.nfvi.per.met.006 | ephemeral storage throughput | MB/s | Range (min, max) per VNF-C | +

Table 3-25: Internal resource management metrics.

+ #### 3.4.2.1 Internal performance metrics + The following table shows performance metrics per NFVI node. @@ -432,15 +445,19 @@ The following table shows performance metrics per NFVI node. | i.nfvi.per.met.006 | Network energy efficiency | W/bits/s | Energy consumption for the node max network throughput, normalized to the bit rate | | i.nfvi.per.met.007 | Processing energy efficiency | W/core | Energy consumption during the node processing capacity measurement (i.nfvi.per.met.004), normalized to physical cores usable by VNF-C | -

Table 3-xx: Internal performance metrics of NFVI.

+

Table 3-26: Internal performance metrics of NFVI.

It should be noted that energy-related metrics must only be considered for NFVI software implementations benchmarking on a same NFVI hardware implementation (since energy consumption may be very different for a same processor model due to foundry process spread). #### 3.4.2.2 Internal availability/reliability metrics + [COMMENT - Xavier Grall, Orange: the following table should be reviewed to only consider and probably detail the recovery-related metrics ; indeed, availability and MTBF metrics do not seem consistent with expected testbed measurement duration] + +_**Comment**: MXS - 13/7/2019 To-do: This table needs to be reworked and clarified w/ clear explanations and assumptions stated._ | Ref | NFVI metric | Unit | Definition/Notes | |--------------------|------------------|---------|-------------------------------------------| @@ -449,14 +466,4 @@ It should be noted that energy-related metrics must only be considered for NFVI | i.nfvi.arl.met.003 | MTBF AZ | days | Mean Time between Failure for an AZ | | i.nfvi.arl.met.004 | Recovery time | seconds | | -

Table 3-31: Internal availability/reliability metrics of NFVI.

- -| Ref | B Instance | N Instance | C Instance | -|--------------------|------------|------------|------------| -| `i.nfvi.arl.met.001` | | | | -| `i.nfvi.arl.met.002` | | | | -| `i.nfvi.arl.met.003` | | | | -| `i.nfvi.arl.met.004` | | | | - -

Table 3-32: Mapping of Internal availability/reliability metrics to NFVI instance types.

- +

Table 3-27: Internal availability/reliability metrics of NFVI.

\ No newline at end of file diff --git a/doc/ref_model/chapters/chapter04.md b/doc/ref_model/chapters/chapter04.md index 78f85c6b..39d1174c 100644 --- a/doc/ref_model/chapters/chapter04.md +++ b/doc/ref_model/chapters/chapter04.md @@ -1,6 +1,6 @@ [<< Back](../../ref_model) # 4 Catalogue -

scope

+

scope

## Table of Contents * [4.1 Compute flavours.](#4.1) diff --git a/doc/ref_model/chapters/chapter05.md b/doc/ref_model/chapters/chapter05.md index 76f92f4a..7e8a82d8 100644 --- a/doc/ref_model/chapters/chapter05.md +++ b/doc/ref_model/chapters/chapter05.md @@ -1,6 +1,6 @@ [<< Back](../../ref_model) # 5 Reference NFVI SW profiles and configurations -

scope

+

scope

## Table of Contents * [5.1 NFVI SW profile description.](#5.1) diff --git a/doc/ref_model/chapters/chapter06.md b/doc/ref_model/chapters/chapter06.md index 7dd0720b..1e2dea5f 100644 --- a/doc/ref_model/chapters/chapter06.md +++ b/doc/ref_model/chapters/chapter06.md @@ -1,6 +1,6 @@ [<< Back](../../ref_model) # 6 Reference NFVI HW profiles and configurations -

scope

+

scope

## Table of Contents * [6.1 Hardware Profile Model.](#6.1) diff --git a/doc/ref_model/figures/bogo_lsf.png b/doc/ref_model/figures/bogo_lsf.png new file mode 100644 index 00000000..e9e9bef6 Binary files /dev/null and b/doc/ref_model/figures/bogo_lsf.png differ