Merge pull request #2 from pgoyal01/patch-10

Update Chapter03.md

doc/ref_model/chapters/chapter03.md

@@ -7,21 +7,18 @@
 * [3.2 Exposed vs Internal.](#expint)
 * [3.3 Exposed NFVI capabilities, metrics, and constraints.](#expcap)
 
-There is the necessity to clearly define which kind of infrastructure resources a shared network function virtualisation infrastructure (NFVI) will provide for hosting virtual network functions (VNFs) and/or cloud-native network functions (CNF), so that the requirements of each of the VNFs and CNFs match the capabilities of the NFVI.
-
-<p align="center"><img src="../figures/ch03_model_layers.PNG" alt="model_layers" title="Model Layers" width="65%"/></p>
-<p align="center"><b>Figure 3-1:</b> VNFs/CNFs manage and consume NFVI infrastructure resources.</p>
+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 onboarding and maintaining these solutions on top of a virtualised infrastructure e.g.:
-- supporting any kind of VNF specific requirements (e.g. regarding network acceleration or API access) might result in having to establish different silo NFVIs for each VNF
+- 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 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 address 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 onboarding and maintaining VNFs
+-	**Declarative**: the model should allow for a declarative description of the required NFVI capabilities for onboarding 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.
@@ -30,31 +27,31 @@ To summarise: the abstraction model presented in this paper will build upon exis
 
 <a name="model"></a>
 ## 3.1	Model
-The abstraction model for the NFVI makes use of following layers (only the virtual infrastructure layer will be directly exposed to the VNFs/CNFs):
+The abstraction model for the NFVI makes use of following layers (only the virtual infrastructure layer will be directly exposed to the workloads such as VNFs/CNFs):
 
-<p align="center"><img src="../figures/ch03_layers_of_nfvi.PNG" alt="nfvi_layers" title="NFVI Layers" width="65%"/></p>
-<p align="center"><b>Figure 3-2:</b> Layers of NFVI.</p>
+<p align="center"><img src="../figures/figure_3.1_NFVI-Model.png" alt="NFVI model_layers" Title="NFVI MOdel Layers" width="65%"/></p>
+<p align="center"><b>Figure 3.1:</b> NFVI Model Layers.</p>
 
 The functionalities of each layer are as follows:
-- NFVI hardware profile: This layer consists of physical hardware components such as servers, random access memory, storage devices, network ports, hardware acceleration devices, etc. and their corresponding basic operating systems (BIOS).
-- NFVI software profile: This layer consists of both the host Operating System (OS) responsible for managing the hardware resources of the layer below as well as the virtualization/containerization technology which turns hardware components into a pool of logical resources and dynamically allocates them to the layer above.
-- Virtual infrastructure resources: This layer represents all the infrastructure resources which the NFVI provides to the VNFs/CNFs such as tenants, compute hosts, storage and networks These resources can be managed by the layer above directly or indirectly via an application programming interface or graphical user interface.
-- VNFs/CNFs: This layer consists of 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 below:
+- 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 their corresponding basic operating systems (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 turns them into 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 Figure 3.2.
 
-<p align="center"><img src="../figures/ch03_virtual_resources.PNG" alt="virtual_resources" title="Virtual Resources" width="65%"/></p>
-<p align="center"><b>Figure 3-3:</b> Virtual infrastructure resources.</p>
+<p align="center"><img src="../figures/figure_3.2_Virtual_Infra_Resources.png" alt="virtual_resources" Title="Virtual Infrastructure Resources" width="65%"/></p>
+<p align="center"><b>Figure 3.2:</b> Virtual Infrastructure Resources provides virtual compute, storage and networks in a tenant context.</p>
 
-- tenant: tenants represent an independently manageable logical pool of compute, storage and network resources
-- compute resources: represent virtualised hosts for operating systems and applications
+- 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 VNF/CNF workloads 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 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                                                                                             |
 |-----------|---------------------------------------------------------------------------------------------------------|
@@ -66,10 +63,10 @@ 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, …) |
 
-<p align="center"><b>Table 3-1:</b> Attributes of a tenant.</p>
+<p align="center"><b>Table 3.1:</b> Attributes of a tenant.</p>
 
-### Compute Host
-A virtual machine or a container/pod belonging to a tenant capable of hosting the application components of VNFs. A compute host 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.
+### 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.
 
 | Attribute | Description |
 | --- | --- |
@@ -81,10 +78,10 @@ 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 |
 
-<p align="center"><b>Table 3-2:</b> Attributes of compute resources.</p>
+<p align="center"><b>Table 3.2:</b> Attributes of compute resources.</p>
 
 ### Storage
-A block device of a certain size for persisting information which can be created and dynamically attached to/detached from a compute host. A storage device resides in a tenant context and exists independently from any compute host. **Example**: an OpenStack cinder volume.
+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.
 
 | Attribute | Description |
 | --- | --- |
@@ -94,7 +91,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 |
 
-<p align="center"><b>Table 3-3:</b> Attributes of storage resources.</p>
+<p align="center"><b>Table 3.3:</b> Attributes of storage resources.</p>
 
 _**Comments**: we need to be more specific regarding acceleration and metadata._
 
@@ -107,7 +104,7 @@ A layer 2 / layer 3 communication domain within a tenant. A network requires a t
 | `subnet` | classless inter-domain routing of the subnet |
 | `acceleration` | key/value pairs for selection of the appropriate acceleration technology |
 
-<p align="center"><b>Table 3-4:</b> Attributes of network resources.</p>
+<p align="center"><b>Table 3.4:</b> Attributes of network resources.</p>
 
 <a name="expint"></a>
 ## 3.2	Exposed vs Internal