Network Function Virtualisation or NFV aims to transform the way network operators architect their networks, by evolving standard IT virtualisation technology to consolidate many network equipment types onto industry standard high volume equipment, which could be located in data centres, network nodes and at end user premises.
Telecommunication is the backbone of today’s world and it has become an integral part of our day-to-day life. As competition increases, it is important for telecom vendors to be cost effective and offer highly efficient connections with greater speed. Telecom data centres and infrastructure are governed by standards, protocols and service quality norms. Also, they are over populated by a large and increasing variety of proprietary hardware appliances. Therefore, to launch a new network service, it often requires the introduction of yet another variety of proprietary hardware, a task that is becoming increasingly difficult.
This is further compounded by the increasing costs of energy, capital, technically-trained manpower, etc. The variety of skills necessary to design, integrate and operate complex hardware-based appliances poses a real challenge to both the developer and the network operator. Moreover, hardware-based appliances rapidly reach end-of-life. Other cost-oriented issues result in little or no revenue benefits. These constraints/limitations of hardware-based appliances (e.g., routers, firewalls, etc) has triggered the need for a new radical approach.
Network function virtualisation
Network function virtualisation (NFV) is a new way to design, deploy, and manage networking services by decoupling the physical network equipment from the functions that run on them. It replaces hardware centric and dedicated network devices with software running on general-purpose CPUs or virtual machines, operating on standard servers.
NFV aims to transform the way network operators architect their networks, by evolving standard IT virtualisation technology to consolidate many network equipment types onto industry standard high volume servers, switches and storage, which could be located in data centres, network nodes and at end user premises, as illustrated in Figure 2.
These virtual appliances can be instantiated on demand without installing new equipment. For example, network operators may run an open source software-based firewall in a virtual machine (VM). This involves the implementation of network functions in software that can run on a range of industry standard servers and be moved to or instantiated in various locations in the network, as required. In other words, NFV promotes the implementation of network functions in software that can run on a range of standard IT hardware in data centres and be managed (moved, or replicated) without the need to modify the physical infrastructure.
The need for NFV
Traditional physical network hardware has always been difficult to change and upgrade. Introducing a software patch or rolling out a new service on a physical network can take months to complete and costs a lot.
NFV is a catalyst for structural market changes. It first started with mobile telecom networks, with the promise of making them more flexible and far easier to upgrade or change and to reduce hardware-related capex and opex.
As NFV developed further, service agility has become one of the main drivers in this space.
Compared with the current practices, NFV introduces the following major positive shifts:
- Separation of software from hardware: This enables the software to evolve independently from the hardware, and vice versa.
- Flexible deployment of network functions: NFV can automatically deploy network-function software on a pool of hardware resources, which may run different functions at different times in different data centres.
- Dynamic service provisioning: Network operators can scale the NFV performance dynamically and on a grow-as-you-need basis with fine granularity, based on the current network conditions.
Salient features of NFV
- Virtualisation: Uses network resources without worrying about where the network is physically located, how big it is, how it is organised, etc.
- Orchestration: Manages thousands of devices.
- Programmable: Can change behaviour on-the-fly.
- Dynamic scaling: Can change size and quantity.
- AutomationVisibility: Monitors resources and connectivity.
- Performance: Optimises network device utilisation.
- Requires less space for network hardware.
- Reduced network power consumption and network maintenance costs.
- Easier network upgrades.
- Longer life cycles for network hardware.
NFV architecture
1. VNF (virtual network function): A VNF is the basic block in NFV architecture. It is the virtualised network element.
2. EM (element management): EM is responsible for the functional management of VNF, i.e., fault, configuration, accounting, performance and security management (FCAPS). This may manage the VNFs through proprietary interfaces. There may be one EM per VNF or one EM can manage multiple VNFs.
3. VNF manager (VNFM): This manages one or more VNFs, i.e., it does the life cycle management of VNF instances, which includes setting up/maintaining and tearing down VNFs. Additionally, VNFM does the FCAPS for the virtual part of the VNF. The difference between the EM and VNFM is that the former manages functional components, while the VNFM manages the virtual components.
4. NFVI (network function virtualisation infrastructure): NFVI is the environment in which VNFs run. This includes physical resources, virtual resources and the virtualisation layer, described below:
- Compute, memory and networking resources: This is the physical part in NFVI. Virtual resources are instantiated on these physical resources.
- Virtual compute, virtual memory and virtual networking resources: This is the virtual part in NFVI. The physical resources are abstracted into virtual resources that are ultimately used by VNFs.
- Virtualisation layer: This layer is responsible for abstracting physical resources into virtual resources. The common industry term for this layer is ‘Hypervisor’. This layer decouples software from hardware, which enables the software to progress independently from hardware.
5. VIM (virtualised infrastructure manager): This is the management system for NFVI. It is responsible for controlling and managing the NFVI compute, network and storage resources within one operator’s infrastructure domain. It is also responsible for collecting performance measurements and events.
6. NFV orchestrator: This creates, maintains and tears down the network services of VNF. If there are multiple VNFs, the orchestrator will enable the creation of end-to-end services over them. NFV orchestrator is also responsible for global management of NFVI resources like compute, storage and networking resources among multiple VIMs in the network.
The orchestrator performs its functions by not talking directly to VNFs but through VNFMs and VIMs. The VNF manager, VIM and NFV orchestrator, together form the NFV management and orchestration (MANO) entity.
7. OSS/BSS (operation support system/business support system): OSS deals with network management, fault management, configuration management and service management. BSS deals with customer management, product management, order management, etc.
In the NFV architecture, the current OSS/BSS of an operator may be integrated with the NFV management and orchestration, using standard interfaces.
Challenges
What NFV can offer service providers in terms of benefits is clear, but there are challenges for operations and operation support systems (OSS). Unless addressed appropriately, these challenges can impact a successful transformation. Some network experts argue that a new network management model is needed for NFV and its implied orchestration.
- Infrastructure challenges: The infrastructure challenges with NFV transformation are connected to the introduction of new types of components in the network, originating from the technical world and based on industry-standard platforms. These components need to provide telco-grade availability and high performance, while meeting the stringent SLAs that are typical in the communications service providers (CSP) world. Additionally, there is a large installed base of legacy telco equipment. Although much of this current infrastructure will eventually be replaced by virtualised entities, either through an NFV transformation initiative or normal life cycle management, a hybrid environment will always exist. Virtualisation of certain telco equipment won’t necessarily be feasible or desirable in every deployment situation.
- Operational challenges: A significant operational challenge of the NFV transformation is how to maintain the customer and services views that are tied to the underlying infrastructure. This requires integration within existing OSS/BSS environments and end-to-end automation to enable agility and faster service velocity. By decoupling functions from the infrastructure, NFV warrants new procedures for testing, validation, acceptance and troubleshooting. Another important operational challenge is to manage operations costs while deploying NFV. Factors contributing to this challenge include the complexity associated with managing a hybrid environment of virtualised and legacy equipment and that of managing functions implemented by a distributed set of software entities.NFV creates an elastic relationship between services and resources, that makes SLAs and problem resolution more difficult.
- Service challenges: The transformation to NFV will eventually create a CSP infrastructure that is programmable in real-time and is highly automated. In order to take full advantage of the investments in the infrastructure, CSPs will have to revamp the way they offer services to their customers. The challenges in the service domain will mainly be in the area of managing a dynamic service offering and its integration to the underlying infrastructure and real-time analytics.
Open standards for NFV
The standards for NFV are under development by ETSI (the European Telecommunications Standards Institute). Though the concept and benefits of NFV are simple enough, implementing NFV gets complicated. In order to realise the full benefit of NFV, some level of cooperation and interaction between various network solutions providers and network operators is needed.That’s where industry groups like ETSI come into play. Over 130 of the world’s leading network operators have recently joined together to form an ETSI Industry Specification Group (ISG) for NFV. Literally dozens of groups — some open source and others more traditional standards organisations — are putting together pieces of the (large) puzzle needed to make NFV a reality. And operators (large and small) are engaging in proofs-of-concept exercises and evaluating the business case for what is surely the industry’s largest transformation in decades.
OPNFV – An open platform to accelerate the NFV transformation
Open Platform for NFV (OPNFV) is an open source project that provides network operators an open source reference platform to validate multi-vendor, interoperable NFV solutions. OPNFV facilitates the development and evolution of NFV components across various open source ecosystems. Through system level integration, deployment and testing, OPNFV creates a reference NFV platform to accelerate the transformation of enterprise and service provider networks. OPNFV will work closely with ETSI’s NFV ISG, among other standards bodies, to drive the consistent implementation of an open and standard NFV reference platform.
The initial scope of OPNFV provides NFV infrastructure (NFVI), virtualised infrastructure management (VIM), and APIs to other NFV elements, which together form the basic infrastructure required for virtualised network functions (VNFs) and the management and network orchestration (MANO) components. Increasingly, standards are being drafted in conjunction with major open source projects. OPNFV will work with many of these projects to coordinate the continuous integration and testing of NFV solutions.
Participation is open to anyone, whether you are an employee of a member company or just passionate about network transformation. Some of the major open source projects for which collaboration with OPNFV is important are:
- Virtual infrastructure management: OpenStack, Apache CloudStack (https://github.com/apache/cloudstack)
- Network controller and virtualisation infrastructure: OpenDaylight (https://github.com/opendaylight)
- Virtualisation and hypervisors: KVM, Xen, libvirt and LXC (https://git.kernel.org/pub/scm/virt/kvm/kvm.git)
- Virtual forwarder: Open vSwitch (OVS) and Linux bridge
- Data-plane interfaces and acceleration: Data plane development kit (DPDK), Open data plane (ODP), etc. (http://dpdk.org/dev)
Open Source MANO
Open Source Mano is an ETSI-hosted initiative to develop an open source NFV management and orchestration (MANO) software stack aligned with ETSI NFV.
ETSI’s Open Source Mano (OSM) group is developing an open source NFV management and orchestration stack using well established open source tools and working procedures. The activity is closely aligned with the evolution of ETSI NFV and will provide a regularly updated reference implementation of NFV MANO. OSM aims at enabling an ecosystem of NFV solution vendors to rapidly and cost-effectively deliver solutions to their users.
Anybody who is interested can contribute here: https://github.com/nfvlabs/openmano
Open vSwitch
Open vSwitch (OVS) is a production quality, multi-layer virtual switch licensed under the open source Apache 2.0 licence. It is designed to enable massive network automation through programmatic extension, while still supporting standard management interfaces and protocols (e.g., NetFlow, sFlow, IPFIX, RSPAN, CLI, LACP, 802.1ag). In addition to exposing standard control and visibility interfaces to the virtual networking layer, it is designed to support distribution across multiple physical servers. Open vSwitch supports multiple Linux-based virtualisation technologies including Xen/XenServer, KVM and VirtualBox.
The bulk of the code is written in platform-independent C and is easily ported to other environments. The latest release of Open vSwitch has the following features:
- Standard 802.1Q VLAN model with trunk and access ports
- NIC bonding with or without LACP on upstream switch
- NetFlow, sFlow(R), and mirroring for increased visibility
- QoS (Quality of Service) configuration, plus policing
- Geneve, GRE, VXLAN, STT and LISP tunnelling
- 802.1ag connectivity fault management
- OpenFlow 1.0 plus numerous extensions
- Transactional configuration database with C and Python bindings
- High-performance forwarding using a Linux kernel module
Open vSwitch can also operate entirely in user space without assistance from a kernel module. This user space implementation should be easier to port than the kernel-based switch. OVS in user space can access Linux or DPDK devices. Note that Open vSwitch, with the user space data path and non-DPDK devices, is considered experimental and comes at the cost of performance.
Anybody who is interested can contribute here: https://github.com/openvswitch/ovs
The introduction of network function virtualisation (NFV) is a core structural change in the telecommunications infrastructure. NFV will bring about cost efficiencies, time-to-market improvements, new business models and services, and increased innovation to the telecommunications industry’s infrastructure and applications. The evolution of NFV is real and is happening now; therefore, the telecom industry needs to consider leveraging this opportunity by heading down the migration path to NFV to start reaping the benefits.
As an emerging technology, NFV may present several challenges to network operators, such as the inability to guarantee network performance for virtual appliances, their dynamic instantiation and migration, and their efficient placement. Therefore, the challenge for network operators may be how to migrate their operations and skill base to a software based networking environment while carefully re-targeting investment to maximise the reuse of existing systems and processes. NFV may require investments in time, resources, education and operational transformation, but it may also be the most efficient strategy going forward—to keep pace with the rapid growth of the telecommunications networks of tomorrow.
