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 @@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.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 -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: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.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 NFVTable 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 NFVTable 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 -