Question

Critically analyze ‘Network function virtualization (NFV)’ with respect to telecommunication systems. Your analysis should cover below aspects:

a. Background information of this case study.   

b. Principles of the technology/specifications.

c. Literature Review/Theory/Reflection on Similar Case Studies.

d. Deployment issues of the technology.

e. Critical Reflection on Technology.

f. Conclusions.

g. Referencing

Answer 1

Abstarct

Network Function Virtualization (NFV) has drawn significant attention from both industry and academia as an important shift in telecommunication service provisioning. By decoupling Network Functions (NFs) from the physical devices on which they run, NFV has the potential to lead to significant reductions in Operating Expenses (OPEX) and Capital Expenses (CAPEX) and facilitate the deployment of new services with increased agility and faster time-to-value. The NFV paradigm is still in its infancy and there is a large spectrum of opportunities for the research community to develop new architectures, systems and applications, and to evaluate alternatives and trade-offs in developing technologies for its successful deployment. In this paper, after discussing NFV and its relationship with complementary fields of Software Defined Networking (SDN) and cloud computing, we survey the state-of-the-art in NFV, and identify promising research directions in this area. We also overview key NFV projects, standardization efforts, early implementations, use cases and commercial products

A. Background information of this case study.

The concept and collaborative work on NFV was born in October 2012 when a number of the world’s leading TSPs jointly authored a white paper calling for industrial and research action. In November 2012 seven of these operators (AT&T, BT, Deutsche Telekom, Orange, Telecom Italia, Telefonica and Verizon) selected the European Telecommunications Standards Institute (ETSI) to be the home of the Industry Specification Group for NFV (ETSI ISG NFV).

Now, more than two years later, a large community of experts are working intensely to develop the required standards for NFV as well as sharing their experiences of its development and early implementation. The membership of ETSI has grown to over 245 individual companies including 37 of the world’s major service providers as well as representatives from both telecoms and IT vendors. ETSI has successfully completed Phase 1 of its work with the publication of 11 ETSI Group Specifications. These specifications build on the first release of ETSI documents published in October 2013 and include an infrastructure overview, updated architectural framework, and descriptions of the compute, hypervisor and network domains of the infrastructure. They also cover Management and Orchestration (MANO), security and trust, resilience and service quality metrics.

Since ETSI is not a standards body, its aim is to produce requirements and potential specifications that TSPs and equipment vendors can adapt for their individual environments,and which may be developed by an appropriate standards development organization (SDO). However, since standards bodies such as the 3GPP are in liaison with the ETSI, we can expect these proposals will be generally accepted andenforced as standards. 3GPP’s Telecom Management working group (SA5) is also studying the management of virtualized 3GPP network functions.

B. Principles of the technology/specifications.

the NFV Architecture is composed of three key elements: Network Function Virtualization Infrastructure (NFVI), VNFs and NFV MANO.

(i) NFV Infrastructure (NFVI)

The NFVI is the combination of both hardware and software resources which make up the environment in which VNFs are deployed. The physical resources include commercial-offthe-shelf (COTS) computing hardware, storage and network (made up of nodes and links) that provide processing, storage and connectivity to VNFs. Virtual resources are abstractions of the computing, storage and network resources. The abstraction is achieved using a virtualization layer (based on a hypervisor), which decouples the virtual resources from the underlying physical resources. In a data center environment, the computing and storage resources may be represented in terms of one or more Virtual Machines (VMs), while virtual networks are made up of virtual links and nodes. A virtual node is a software component with either hosting or routing functionality, for example an operating system encapsulated in a VM. A virtual link is a logical interconnection of two virtual nodes, appearing to them as a direct physical link with dynamically changing properties.

(ii) Virtual Network Functions and Services

A NF is a functional block within a network infrastructure that has well defined external interfaces and well-defined functional behaviour . Examples of NFs are elements in a home network, e.g. Residential Gateway (RGW); and conventional network functions, e.g. DHCP servers, firewalls, etc. Therefore, a VNF is an implementation of an NF that is deployed on virtual resources such as a VM. A single VNF may be composed of multiple internal components, and hence it could be deployed over multiple VMs, in which case each VM hosts a single component of the VNF. A service is an offering provided by a TSP that is composed of one or more NFs. In the case of NFV, the NFs that make up the service are virtualized and deployed on virtual resources such as a VM. However, in the perspective of the users, the services−whether based on functions running dedicated equipment or on VMs−should have the same performance. The number, type and ordering of VNFs that make it up are determined by the service’s functional and behavioral specification. Therefore, the behaviour of the service is dependent on that of the constituent VNFs.

(iii) NFV Management and Orchestration (NFV MANO)

According to the ETSI’s MANO framework, NFV MANO provides the functionality required for the provisioning of VNFs, and the related operations, such as the configuration of the VNFs and the infrastructure these functions run on. It includes the orchestration and lifecycle management of physical and/or software resources that support the infrastructure virtualization, and the lifecycle management of VNFs. It also includes databases that are used to store the information and data models which define both deployment as well as lifecycle properties of functions, services, and resources. NFV MANO focuses on all virtualization-specific management tasks necessary in the NFV framework. In addition the framework defines interfaces that can be used for communications between the different components of the NFV MANO, as well as coordination with traditional network management systems such as Operations Support System (OSS) and Business Support Systems (BSS) so as to allow for management of both VNFs as well as functions running on legacy equipment.

C. Literature Review/Theory/Reflection on Similar Case Studies.

The need for innovativeness, agility and resource sharing is not new. In the past, the communications industry has invented and deployed new technologies to help them offer new and multiple services in a more agile, cost and resource effective way. In this section, we introduce two such concepts that are closely related to NFV; cloud computing and SDN. We also discuss the relationship between NFV and each of them, as well as current attempts to enable all three to work together.

(I) Cloud Computing & Its Essential Characteristics

According to NIST cloud computing is “a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction”. In a cloud computing environment, the traditional role of service provider is divided into two: the infrastructure providers who manage cloud platforms and lease resources according to a usage-based pricing model, and service providers, who rent resources from one or many infrastructure providers to serve the end users. The cloud model is composed of five essential characteristics and three service models.

(1) Essential Characteristics of Cloud Computing: On demand self-service, A consumer can unilaterally provision computing capabilities, such as server time and network storage, as needed automatically without requiring human interaction with each service provider.

• Broad network access: Capabilities (e.g. compute resources, storage capacity) are available over the network and accessed through standard mechanisms that promote use by heterogeneous thin or thick client platforms (e.g., mobile phones, tablets, laptops, and workstations).
• Resource pooling: The provider’s computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned according to consumer demand.
• Rapid elasticity: Capabilities can be elastically provisioned and released, in some cases automatically, to scale rapidly outward and inward commensurate with demand.
• Measured service: Cloud systems automatically control and optimize resource use by leveraging a metering capability at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts).

(2) Cloud Computing Service Models: The three service models of cloud computing are shown in Table below.

• Software as a Service (SaaS). The user is able to use the providers applications running on a cloud infrastructure. The applications are accessible from various client devices through either a thin client interface, such as a web browser (e.g., webbased email), or a program interface.
• Platform as a Service (PaaS). The user is able to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages, libraries, services, and tools supported by the provider.
• Infrastructure as a Service (IaaS). The user is able to provision processing, storage, networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which can include operating systems and applications.  

Model	Example
SaaS	Facebook, Google Apps, Twitter, ZenDesk, Saleforce.com, Zoho Office
PaaS	Heroku, Azure, Google AppEngine, RedHat OpenShift, force.com
IaaS	OpenStack, Azure, Amazon Web Services (EC2, S3, DynamoDB), GoGrid, Rackspace

• Relationship between Cloud Computing and NFV

  Issue	NFV	Cloud Computing
  Approach	Service/Function Abstraction	Computing Abstraction
  Formalization	ETSI NFV Industry Standard Group	DMTF Cloud Management Working Group
  Latency	Expectations for low latency	Some latency is acceptable
  Infrastructure	Heterogeneous transport (Optical, Ethernet, Wireless)	Homogeneous transport (Ethernet)
  Protocol	Multiple Control Protocols	OpenFlow
  Reliability	Strict 5 NINES availability requirements	Less strict reliability requirements
  Regulation	Strict Requirements e.g NEBS	Still diverse and changing

(II) Software Defined Networking (SDN)

SDN is currently attracting significant attention from both academia and industry as an important architecture for the management of large scale complex networks, which may require re-policing or re-configurations from time to time. SDN decouples the network control and forwarding functions. This allows network control to become directly programmable via an open interface (e.g., ForCES, OpenFlow, etc) and the underlying infrastructure to become simple packet forwarding devices (the data plane) that can be programmed. While the SDN control plane can be implemented as pure software which runs on industry-standard hardware, the forwarding plane requires an SDN agent, and may therefore require to be implemented in specialized hardware. However, depending on the performance and capacity needs of the SDN networking element, and depending on whether specialized hardware transport interfaces are required, the forwarding plane may also be implemented on commodity servers. For example, VMware’s NSX platform includes a virtual switch (vSwitch) and controller both of which implement SDN protocols without requiring specialized hardware.

SDN has the potential to dramatically simplify network management and enable innovation and evolution. According to the Open Network Foundation (ONF), SDN addresses the fact that the static architecture of conventional networks is ill-suited for the dynamic computing and storage needs of today’s data centers, campuses, and carrier environments.

• Relationship between SDN and NFV

Issue	NFV	SDN
Approach	Service/Function Abstraction	Networking Abstraction
Formalization	ETSI	ONF
Advantage	Promises to bring flexibility and cost reduction	Promises to bring unified programmable control and open interfaces
Protocol	Multiple control protocols (e.g SNMP, NETCONF)	OpenFlow is de-facto standard
Applications Run	Commodity servers and switches	Commodity servers for control plane and possibility for specialized hardware for data plane
Leaders	Mainly Telecom service providers	Mainly networking software and hardware vendors
Business Initiator	Telecom service providers	Born on the campus, matured in the data center

D. Deployment issues of the technology

• New technologies - Experience with the cloud can help operators with NFV deployments, but they may still find it difficult staying up-to-date with the latest technologies leading the switch. In addition, NFV operations stand in stark contrast to conventional operations. Operators will have to adjust to innovative systems for the management and orchestration (MANO) of virtual services and functions, which do not provider all the features necessary to ensure a smooth migration. To make the shift a success, service providers will need to consider automation, orchestration, policies and management.

• Legacy infrastructure - NFV has been heralded as a way to reduce capital expenses (CAPEX) and operating expenses (OPEX) by enabling administrators to spend less time managing data centers. Nevertheless, a significant challenge to adoption and scale is legacy networks. Several older products will not be upgraded to support the technology. Regardless, operators can still deploy NFV in several developing applications. Moreover, virtual network functions (VNF) can run virtually on legacy infrastructure. Operators can take the profit acquired from VNFs and invest it in more elaborate NFV related projects.

• Security issues - Although NFV provides a variety of new network functions, it also opens up a window for new security risks. Software is by its very nature less secure than hardware. Routers and firewalls on dedicated hardware are harder to crack from a security stance. Software is much more vulnerable to the Distributed Denial of Service (DDOS) attacks. The platform must be shielded from constant threats that can flood the network. A hypervisor can provide a high level of isolation for virtual machines (VMs), meaning if one VM is infected by a computer virus it may not spread to other VMs.

• Lack of standards - Another challenge facing the virtualized market is the need for standards for communications among NFV components. Developing standards for these types of systems usually takes many years, but the telecom industry is ready to start deployments now. The European Telecommunications Standards Institute (ETSI) is the main force setting standards for the market. Although competing standards have been proposed, the industry lacks an overall consensus on the matter. Operators can participate in developing these standards through the The ETSI Industry Specification Group, which is available to members and nonmembers.

• Not enough strong business cases - Another barrier to virtualization is a lack of carefully defined business cases. There are a host of reasons why this is so. Vendors have a proclivity to hyperbolize what NFV can do, which leads to disappointment among operators whenever a certain feature proves short. On the other hand, some vendors aren’t thinking big enough with respect to NFV. Although vendors are quick to boast the benefits of NFV, they are less inclined to set the scope of their solutions, failing to present a compelling business case in return. Moreover, several advantages of the technology, like quicker time-to-market, optimizing networks and innovative services, are hard to measure, making business cases based on those concepts even harder to define.

E. Critical Reflection on Technology

NFV is transforming the way the telecommunications infrastructure is deployed. Therefore, the way service is delivered by CSPs is going to change significantly. Thus, NFV is imposing new demands for OSS. Traditionally, the OSS/BSS system is oriented to a reasonably static networking environment. However, in today’s highly dynamic networking environment, The OSS/BSS system already needs some re-designing to adapt it to the dynamic nature of businesses. This is compounded by the need to provide the operational and business support of deploying services using software-defined infrastructure.

CSPs need to advance their OSS system to simplify and align with evolving software-defined infrastructure. Moreover, to control the dynamicity of NFV, new mechanisms to keep track of performance need an enhanced service assurance system to handle the dynamic nature of the NFV.

Resource allocation in NFV is also a challenging problem. When talking about resource allocation concerning the NFV architectural framework, NFVI and NFV-MANO blocks are mainly responsible for provisioning resource allocation for VNFs, because VNFs are deployed on the NFVI and resources are allocated through orchestration. According to resource allocation in NFV is accomplish in three stages as follows:

1) VNFs Chain Composition or SFC: SFC is the mechanisms to connect VNFs in such that they form a chain of service functions. This enables flexibility for CSPs to make the best use of virtualized software to define infrastructure. Moreover, it enables to compose a chain of VFNs dynamically. TSPs can get the benefit from the composed dynamic chain of VNFs and develop elastic network services according to their business needs. However, the main challenge arising while composing such chain is that how efficiently NFVI can be utilized to concatenate VNFs and control dynamicity.

2) VNFs Forwarding Graph Embedding: VNFs Forwarding Graph Embedding in NFV is a concept closely related to the Virtual Network Embedding (VNE) and Virtual Data Center Embedding (VDCE) as described above. A chain composed of VNFs is a connection of graphs to form end-to-end service. This end-to-end service is known as VNFs forwarding graph embedding.

3) VNFs Scheduling: VNFs are deployed using NFVI that comprised of several high volume servers. VNFs scheduling is the process of embedding VNFs in such a way to compose a chain of VNFs that minimize the total run time service execution. VNFs scheduling is carried out carefully without performance degradation and effecting high volume server in operating NFVI.

F. Conclusions

Due to user demands for real-time, on-demand, online, inexpensive, short-lived services, TSPs have been forced to look for new ways of delivering these services in ways that are agile, and with OPEX and CAPEX savings. NFV has emerged as a possible approach to make network equipment more open, and hence allow TSPs to become more flexible, faster at service innovations and reduce operation & maintenance (O&M) costs. It is clear that NFV, together with the closely related and complementary fields of SDN and cloud computing may be big parts of future telecommunication service provision.

NFV has attracted significant interest from academia and the telecommunications industry as a technology that will potentially revolutionize network-based services with low deployment costs for network operators. Virtualization approaches are paving the way for NFV from VMs, containers to more advanced techniques such as unikernels.

NFV standardization efforts have evolved in the last few years, but the standardization is still underway. NFV applicability and PoCs are progressed and NFV becoming a key enabler of the 5G network slicing concept

G. Reference

1. ETSI Industry Specification Group (ISG) NFV, “ETSI GS NFV 001 V1.1.1: Network Function Virtualization. Use Cases,” www.etsi.org/deliver/etsi gs/NFV/001 099/001/01.01.01 60/gs NFV001v010101p.pdf, October 2013.

2. ETSI, “European Telecommunications Standards Institute, Industry Specification Groups (ISG) - NFV,” http://www.etsi. org/technologies-clusters/technologies/nfv, 2015, Accessed: June 03, 2015.

3. IEEE, "Network Function Virtualization: State-of-the-art and Research Challenges", http://dx.doi.org/10.1109/COMST.2015.2477041, Accessed : September 25,2015.