Chapter 3. ETSI
European Telecommunications Standards Institute(ETSI) is a standards body that is responsible for or desires to standardize the NFV architecture. Telecoms/SPs around the world as well as all major network equipment manufacturers have representation at ETSI.
It is important to understand that ETSI provides a framework and not necessarily a strict standard that should be followed by all vendors. More details about ETSI/NFV can be found at http://www.etsi.org/technologies-clusters/technologies/nfv.
Figure 1 shows the NFV architectural framework as defined by ETSI. The figure has components that make up the NFV on the left such as NFV Infrastructure(NFVI), VNF etc and the Management and Orchestration (MANO) sitting on the right. ETSI/NFV defines all aspects of the architecture including:
- NFVI - NFV Infrastructure: NFVI is the infrastructure that includes the compute (servers), storage and networking as well as the hypervisors that offers the virtualization. It is an abstraction that allows us to simply install VNFs without having to worry about the details of the underlying hardware. NFVI forms the foundation for the NFV stack. It supports multi-tenancy and is managed by the Virtual Infrastructure Manager (VIM). In deployments today the VIM is OpenStack®. The virtualization layer is typically KVM.
- MANO - NFV Management and Orchestration: One of the main goals of NFV is to decouple the hardware and the software. This decoupling requires additional layer of management. This management is addressed by the MANO spec from ETSI. MANO defines the VNFM - Virtual Network Function Manager which manages the lifecycle of the VMs/VNFs either by interacting directly with the VMs/VNFs or through Element Management System (EMS) that work with various VMs/VNFs. The other important component defined by MANO is the Orchestrator also known as NFVO. NFVO is the overall orchestrator that interfaces with various databases and systems including OSS/BSS on the north and with the VNFM on the south. If the NFVO wants to create an instance of a VNF/VM, it requests to VNFM to create one such instance.
- NFV Software Architecture - This section deals with the transition of network functions from hardware-based to software-based. It describes software architecture that can be leveraged when decoupling software from the hardware.
- NFV Reliability and Availability - as the name suggests deals with reliability and availability of VNFs/VMs. There are a lot of challenges in making such a complex system resilient. It is a key requirement for all Telcos/SPs. The reliability and availability group studies the requirements and provides guidelines of how they should be incorporated in NFV deployments.
- NFV Performance and Portability - One of main goals of NFV is to support a framework that will allow existing industry network applications to be represented with their existing requirements and characteristics. i.e The throughput, performance, scale attributes of these network functions. Additionally they should be portable, meaning we should be able to instantiate these VMs/VNFs in a cloud.
- NFV Security - Security of the cloud that houses mission critical applications of the SPs and their customers is of paramount importance. NFV security group was formed to focus on this aspect of NFV. Telcos are known to require customer aware (Policy, Authentication etc) VNFs to run in a separate DMZ and other non-customer-aware VNFs to be zoned off and have firewalls separating the zones. NFV architecture has to take into account such requirements from telcos.
Figure 1: ETSI/NFV Architectural Framework (Source:ETSI GS NFV 002 V1.1.1 (2013-10))
Figure 2 shows a mapping of Red Hat® products to the ETSI/NFVI architecture.
Figure 2: Red Hat product mapping to ETSI NFV
3.1. NFVI
The high-level goals of NFV is to abstract the compute, storage and network from the application - decoupling the software functions from the hardware. At an architectural level we should not be concerned about what type of compute, storage or networking is being used. However, characteristics of each of these components need to be addressed in order to elicit the most optimal performance that is required by Telcos in the NFV architecture.
- Compute
- Storage
- Network
3.1.1. Compute
From a compute perspective it is important for a VNF to be able to clearly specify the “quantity” and “quality” required by that VNF of the underlying NFVI in order to be able to function optimally
Often NFV performance optimizations are required that include but not limited to:
- CPU Pinning
- Huge pages
- NUMA nodes
- NOVA scheduler
- Realtime Kernel-based Virtual Machine (KVM)/Kernel (RT-KVM)
- Tweaking/disabling overcommit?
3.1.2. Storage
Storage can be local or cloud storage. Most VNFs are new. We have not had years of experience to be able to quantify and qualify the storage characteristics such as IOPS (Input/Output Operations Per Second), Latency etc. As a result, VNF vendors may tend to be conservative and design their VNFs assuming local storage. Although we have seen mostly local block storage being used (Cinder) as well as Ceph, it is too early to be able to create benchmarks for storage as it relates to NFV. However, NFV architecture should discuss the pros and cons of different models.
Red Hat OpenStack Platform supports storage plug-ins including Cinder. This allows 3rd party storage to be directly integrated into OpenStack. This is very important as many Telcos may have been using storage from storage vendors (EMC, NetApp and others). Certified plug-ins for Cinder can be found at: https://access.redhat.com/articles/1535373
3.1.3. Network
Within NFV, the networking can get fairly convoluted because of the nesting nature of what is being conducted. NFV architecture should discuss the various models and the pro & cons of using each type and their recommended usage. The following network topics will be discussed as relevant to mobile virtualization:
- Provider networks
- Tenant networks
- Flat networks
- VLANs
- VXLANs
- PCI Passthrough
- Single Root Input/Output Virtualization (SR-IOV)
- Data Plane Development Kit (DPDK)
- Commercial SDNs using Neutron plugins
Where did the comment section go?
Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.