Paris F2F Relese 1.0 Cleanup

doc/ref_model/README.md

@@ -1,26 +1,34 @@
 [<< Back](https://cntt-n.github.io/CNTT/)
-# Common NFVi for Telco Reference Model
+# Common NFVI for Telco Reference Model
 
 <p><span style="color: #ff0000;"><strong>** Note:</strong> This is a live (not released) document and is being updated regularly.</span></p>
 
-## Current Release
-**Release: --**
+## Release Information
+**Release: _1.0_**
+
+**Version: _1.0_**
+
+**Release Date: _16th July 2019_**
+
+## Version History
+
+| Version | Date | Note
+| --- | --- | --- |
+| 1.0 | 16th July 2019 | First Release|
 
-## Current Version
-**Version: 0.9**
 
 ## 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 08 | Initial Framework Only |
+| Chapter 07 | Still Developing Content |
+| Chapter 08 | Still Developing Content |
 | Chapter 09 | Initial Framework Only |
 | Chapter 10 | Initial Framework Only |
 
@@ -30,8 +38,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 +49,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 |

doc/ref_model/chapters/chapter02.md

@@ -1,19 +1,116 @@
 [<< Back](../../ref_model)
 # 2	VNF requirements & Analysis
-<p align="right"><img src="../figures/bogo_sdc.png" alt="scope" title="Scope" width="35%"/></p>
+<p align="right"><img src="../figures/bogo_lsf.png" alt="scope" title="Scope" width="35%"/></p>
 
 ## Table of Contents
-* [2.1 VNFs collateral (Sample).](#collateral)
-* [2.2 Analysis of requirements.](#analysis)
-* [2.3 NFVI Profiles.](#profiles)
+* [2.1 VNFs collateral.](#2.1)
+* [2.2 Analysis.](#2.2)
+* [2.3 NFVI Profiles.](#2.3)
 
-The NFV Infrastructure (NFVI) is the totality of all hardware and software components which build up the environment in which VNFs are deployed, managed and executed.
+The NFV Infrastructure (NFVI) is the totality of all hardware and software components which build up the environment in which VNFs/VAs are deployed, managed and executed. It is, therefore, inevitable that different VNFs/VAs would require different capabilities and have different expectations from it.
 
-It is inevitable that different VNFs require different capabilities from the underlying infrastructure and therefore metrics that define those capabilities are needed.
+One of the main targets of the CNTT is to define an agnostic NFVI and removes any dependencies between VNFs/VAs and the deployed Infrastructure (NFVI) and offer NFVI to VNFs/VAs in an abstracted way with defined capabilities and metrics.
+
+This means, operators will be able to host their Telco Workload (VNF) with different traffic types, behaviour and from any vendor on a unified consistent Infrastructure.
+
+Additionally, a well defined NFVI is also needed for other type of workloads than NFV such as IT, Machine learning, Artificial Intelligence, etc. 
+
+In this chapter we try to analyse various VNF types used in telco and examine their requirements. We will also highlight some of the NFVI parameters needed to achieve the desired performance expected by various workloads.
+
+<a name="2.1"></a>
+# 2.1 VNFs collateral
+
+There are many ways that VNFs can be classified, for example: 
+
+- **By Traffic Type:** 
+    - User Plane (Data Plane)
+    - Control Plane (Signalling Plane).  
+    - Management Plane.
+-	**By Service offered:**
+    - Mobile broadband service: vEPC, vDPI, vGI-FW 
+    - Fixed broadband Service vBNG, vDPI
+    - VoLTE / VoWifi : vIMS , UDC , HSBC , vEPDG. 
+    - VASs : vSMS-C ,  vCDN , vCGNAT 
+-	**By Technology:** (2G, 3G, 4G, 5G, Fixed...)  
+
+Below is a list of Network Functions that covers almost _**95%**_ of the Telco workload (and the most likely to be virtualized/moved to cloud). They don't follow any specific categorisation.
+
+_**Note:** definition of some of the VNFs below is based on 3GPP definitions._
+
+
+- EPC Nodes (Evolved Packet Core Nodes) – 3GPP TS 23.002 R15 Network architecture
+  - MME: MME is the control plane entity within EPS supporting functions Mobility Management,[ Control Plane ]
+  - SGW (With CUPS, Control Plane & User Plane Separation, they will be split to SGW-C & SGW-U)
+  - PGW (With CUPS, Control Plane & User Plane Separation, they will be split to PGW-C & PGW-U)
+  - Serving GW: The Serving GW is the gateway which terminates the interface towards E-UTRAN. [  Control / Data Plane ] forwarding traffic from/toward RAN, Mobility anchor for 3GPP access [ Control / Data Plane ]
+  - The PDN GW is the gateway which terminates the SGi interface towards the PDN. [ User Plane], mobility anchor for non 3GPP ( Wifi) [ User Plane].
+  - EPDG : evolved packet data gateway (ePDG) : interconnect non 3GPP access with 3GPP core ( VoWifi ) [ User Plane / Control Plane ]
+  - 3GPP AAA: Authentication, Authorization, and Accounting
+  - PCRF: Policy and Charging Rules Function (PCRF) to provide subscription and policy management for 3G and 4G mobile networks [Control Plane ]
+  - OCS: Online Charging system  [Control Plane]
+  - HSS: The Home Subscriber Server, The HSS is the master database for a given user. It is the entity containing the subscription-related information to support the network entities actually handling calls/sessions. [Control Plane ]
+  - HLR: The Home Location Register (HLR) [Control Plane ]
+  - DRA: Diameter Routing Agent  [Control Plane ]
+  - SCEF: Service Capability Exposure Function, to securely expose the services and capabilities provided by the 3GPP network interfaces.
+  - Circuit Switched - Media Gateway Function (CS-MGW)
+  - MSC Server
+  - Serving GPRS Support Node (SGSN); The location register function in the SGSN stores two types of subscriber data needed to handle originating and terminating packet data transfer:
+  - Gateway GPRS Support Node (GGSN); The location register function in the GGSN stores subscriber data received from the HLR and the SGSN
+
+  - Deep packet inspection (DPI) for network data processing for reporting and other services on mobile and fixed networks.
+  - SBC: Session Border Controller (SBC): Secures voice over IP (VoIP) infrastructures while providing interworking between incompatible signalling messages and media flows (sessions) from end devices or application servers. [ Payload ] 
+  - SMS-C : SMS Center [Control Plane ]
+
+- Other Core/Main VNFs - 3GPP TS 23.002 R15 Network architecture
+  - cRAN – Centralized Unit (CU) BBU, in 5G will be DU and CU 
+  - IMS (IP-Multimedia Subsystem ):
+    - CSCF :  Call Session Control Function [ control ] 
+    - MTAS mobile telephony application server[ control ] 
+    - MRF: Media Resource Function [ user plane ]
+    - Enum : [ control ]
+    - BGCF : Border gateway control function [ control ] . interconnect
+    - MGCF: Media Gateway control function :
+  - DNS Domain Name System 
+  - AAA: Authentication, authorization, and accounting (AAA) services
+  - UDC: User Data Convergence
+    - HSS-FE: Home Subscriber Server) is a database that contains user-related and subscriber-related information
+    - HLR–FE: Home Location Register
+    - AAA-FE
+    - MNP-FE: Mobile Number Portability
+    - EIR–FE: Equipment Identity Register 
+    - UDR: User Data Repository  is a functional entity that acts as a single logical repository that stores converged user data
+  - Carrier-Grade Network Address Translation (CG-NAT) for IPv4 optimization of mobile and fixed networks.
+  - Transmission Control Protocol (TCP) optimization for improved customer experience in 3G/4G mobile networks
+  - Gi Firewall
+  - IPSEC GW
+  - IPS/IDS
+  - DDOS
+  - Access : 
+    - OLT 
+    - BNG: Border Network Gateway  / broadband remote access server
+    - RGW: Residential gateway
+    - Wifi Controller [Control Plane ]
+  - CDN: Content delivery network 
+
+- **For 5G:**
+  - Core nodes: Virtualized by nature and strong candidate to be onboarded onto Telco Cloud as "cloud-native application"  
+    - AMF: The Access and Mobility Management function (AMF)
+    - SMF The Session Management function (SMF)
+    - UPF: The User plane function (UPF)
+    - NSSF: The Network Slice Selection Function (NSSF)
+    - NRF: The Network Repository Function (NRF)
+    - NEF: The Network Exposure Function (NEF)
+    - UDM: The Unified Data Management (UDM)
+    - UDR: The Unified Data Repository (UDR
+    - PCF: The Policy Control Function (PCF)
+    - AUSF: The Authentication Server Function (AUSF)
+    - AF: The Application Function (AF) interacts.
+
+    >_**Note:** for 5G Service-based Architecture (SBA) all Network Functions are stateless (store all sessions/ state on unified data repository UDR)_
+
+<!--
+The following is a list of VNFs that are considered for analysis in this chapter:
 
-<a name="collateral"></a>
-## 2.1	VNFs collateral (Sample)
-The following is a list of VNFs that have been taken as samples and used to understand requirements and to drive the NFVI metrics definition.
 - **Management and Control Plane**: EPC (MME, P/S-GW, S/G-GSN), IMS, SBC, PCRF, SDM, mVAS, DRA
 - **User Plane and network**: RAN, BBU, MRF, BNG, CDN, PE, Switch, Router, RR, CPE
 - **Security & testing**: FW, LB, DNS, AES, DPI, NAT/CGN, SecGW, Probe
@@ -41,26 +138,77 @@ The following is a list of VNFs that have been taken as samples and used to unde
   - BNG, CPE
 - **Radio (Cloud RAN)**.
 
+-->
+
+<a name="2.2"></a>
+# 2.2 Analysis
+
+Studying various requirements of VNFs helps understanding what expectation they will have from the underlying NFVI. Following are _some_ of the requirement you might expect by various workloads:
+
+- Number of VNFC
+- Networking between VNFC
+- Enhanced Platform awareness (EPA)
+  - CPU Pinning 
+  - SR-IOV
+  - Affinity / Anti-affinity rules
+  - Huge Pages 
+  - NUMA alignment
+  - DPDK
+- Hyper-Threading/SMT
+-	Packet per Second
+-	User Space 
+- Security
+  - Advanced Encryption Standard – New Instructions (Intel® AES – NI).
+  - SELinux 
+- Storage requirements  
+  - Ephemeral or Persistence.
+  - Number of IOPS required 
+  - Volume 
+
+By trying to categorise VNF components into different categories based on the requirement observed, below are the different profiles concluded:
+
+- **Profile One -** Signalling / Control traffic profile/ Management OSS/BSS and Non-Telco workload:  
+  -	Low throughput
+  -	A small number of Network cards
+  - Low PPS 
+  - EPA enabled (in some cases)
+  - _**Example:**  (PCRF, IMS, NMS)_
 
-<a name="analysis"></a>
-## 2.2	Analysis of requirements 
-(Key Assumptions and Rationale)
-Capturing performance characteristics.
+- **Profile Two -** Network Intensive Workloads:
+  - High throughput
+  - Multiple Network Interfaces.
+  - High PPS 
+  - EPA enabled 
+  - _**Example:** BNG,  CDN, EPC_
+
+- **Profile Three -** Compute Intensive Workloads:
+  - Algorithmic Intensive
+  - GPU.
+  - Smart NIC / FPGA
+  - _**Example:** SEC-GW, Firewall, DPI_
+
+- **Profile Four -** Storage Intensive Workloads:
+  -	Hight IOPS 
+  -	Hight capacity
+  -	EPA enabled 
+  - _**Example:** UDR_
+
+
+<a name="2.3"></a>
+# 2.3 NFVI Profiles
+
+Based on the above analysis, following NFVI profiles are proposed (Also shown in **Figure 2-1** below)
 
-<a name="profiles"></a>
-## 2.3	NFVI Profiles
-By examining the list of VNFs provided in Section 2.1(VNFs collateral (Sample)) and understand their various requirements of NFVI capabilities and metrics, they can be categorised into the following categories.
 - **Basic**: VNFs with VNF-Cs that perform basic compute operations. 
 - **Network intensive**: VNFs with VNF-Cs that perform network intensive operations with high throughput and low latency requirements.
 - **Compute Intensive**: VNFs with VNF-Cs that perform compute intensive operations with low latency requirements.
-
-**Figure 2-1** shows proposed list of NFVI profiles to match those VNF categories.
+- **Storage Intensive**: VNFs with VNF-Cs that perform storage intensive operations with high IPOS requirements. (_**Note:** Storage Intensive Profile will not be defined in initial CNTT releases_)
 
 >_**Note**: 	This is an initial set of proposed profiles and it is expected that more profiles will be added as more requirements are gathered and as technology enhances and matures._
 
 <p align="center"><img src="../figures/ch02_infra_profiles.PNG" alt="infra_profiles" title="Infrastructure Profiles" width="100%"/></p>
 <p align="center"><b>Figure 2-1:</b> Infrastructure profiles proposed based on VNFs categorisation.</p>
 
-In the next chapter, Infrastructure profiles catalogue, those infrastructure profiles will be offered to VNFs in form of different instance types: B (Basic), N (Network intensive), and C (Compute intensive) respectively.
+On **Chapter 4** later in the document, those infrastructure profiles will be offered to VNFs in form of instance types: **B (Basic)**, **N (Network intensive)**, and **C (Compute intensive)** respectively.