First question that comes to mind is whether SDN and NFV are same or different or related technologies? SDN and NFV are independent technologies. SDN creates a separate management plane which sits a floor above the traditional control plane so as to get wider view of the network and orchestrate using network protocols like OpenFlow. So, with the SDN approach, network appliances with custom ASICs will get replaced by Open Software having vendor specific silicon. Protocols will get replaced with APIs and vendor specific releases will be replaced by innovative cycles. Essentially, SDN creates a programmable network.
The concept of NFV originated from SDN. So, NFV compliments SDN. NFV makes it possible to relocate the networking specific functions from dedicated appliances to generic servers. By definition, NFV is a network architecture concept which proposes to virtualize network node functions into blocks which can be connected or chained together as a service. You expect to see virtual machines running these services instead of dedicated network appliances. If a customer wants to add a new network function, the service provider can simply spin up a new virtual machine to perform that function. This collapses the network functions into single server which reduces the cost. Also, Network operators get tremendous opportunities to package services in different ways.
Listed below are small set of examples of network functions which can be virtualized:-
- Firewall:- This can be part of VM in customer’s network periphery.
- Load balancer
- VPN endpoint
- DNS:- This can be part of a VM on service provider network.
ETSI (European Telecommunications Standards Institute) for NFV is the driving factor behind NFV. It specifies NFV use cases in telecommunications and data communication domains. The use cases include Virtual Enhanced Packet Core (vEPC), Virtual Customer Premise Environments (vCPE) and Virtual Provider Edge (vPE) Solutions.
As multiple devices including handheld devices connect to increasing strained network, next generation telecom equipments should support cloud, NFV technologies. They need to meet rising demands of the data traffic and address service deployment challenges. With this momentum of NFV, there are advances being made at the Hardware as well as Software layers to cater to the fast processing needs of the networking functions.
- TCAMs which are used in integrated merchant silicon inside Network Appliances are getting higher capacities. These HW devices enhance packet processing capabilities for improved performances of packet processing for EM (Exact Match), LPM (Longest prefix Match for IP address), ACL (Access Control Lists), RM (Range Match).
- Hardware vendors have come up with Virtual Router (vRouter) devices, which provides IP based data forwarding.
- Various hardware based routing solutions include VPN, traffic engineering, firewalls, virtual customer premise equipment’s (vCPE) which are meant for use cases of Network Virtualization like VMware NSX.
NFV demands deployment of network services on virtual machines with a lot more improved performance. New virtualization techniques need to be used to deliver hardware performance speeds. e.g. A type 1 hypervisor running on native bare metal gives better performance than a type 2 hypervisor running on top of an operating system. There are many Software projects which are promoting acceleration for NFV deployment.
- Data Plane Development Kit: DPDK has added lots of improvement for faster packet processing. The following paragraph gives an idea about the kind of improvements needed at software layer to meet next generation packet processing requirements.
- BIOS configuration: DPDK recommends disabling power saving, enabling CPU performance, enabling VT-d virtualization option and appropriate choice of PCI bus.
- PMD (poll mode drivers): Instead of using Interrupt based mechanism for packet processing, DPDK uses poll mode drivers similar to Linux NAPI architecture.
- Huge Pages Mapping: In order to reduce packet processing overheads of Kernel networking stack, PMD enables direct transfer of packets between user space and networking device. The user space application layer gets complete packet visibility and can dissect the packet at will.
- CPU Isolation: In order to effectively make use of processor caches, DPDK binds network functions to logical processors. Virtualization profiles use Linux mechanisms like cpuset to control and present non-uniform memory access (NUMA) topology visible to guests.
- Performance Libraries: DPDK has developed libraries like Lockless Ring Buffers, Memory pools, Packet buffers, Cryptography, Timer, Hash, Packet distributor, Packet Fragmentor as part of application framework. Applications make use of these libraries and multi-threaded solutions. Each of these threads runs independently on logical processors of CPU to achieve maximum throughput.
These architecture changes enable to deploy wide variety of Virtual Network Functions. This gives an idea what sort of changes will help smooth ride of NFV.
- OPNFV: This facilitates the evolution and development of network functions across open source systems. There are multiple projects to cater to NFV requirements as part of OPNFV initiative. These projects cover various NFV aspects like
- Virtualized Network Function (VNF)
- Element Monitoring (EM)
- Infrastructure Virtualization layer Managers.
- VNF Manager
- Operations and Business support systems (OSS/BSS).
In addition to this, there are significant updates to open source projects like KVM, OpenStack, OpenvSwitch, OpenDayLight, NetMap kernel bypass.
To summarize, there are multiple challenges for NFV adoption. Here are the focus areas:-
- Standardized interface between the virtual machines and underlined hardware.
- Performance issues due to replacement of network appliance with commodity servers.
- Migration plan for coexistence of existing network appliances and VM based services.
- Simplification of network operations and management.
Latest posts by Kiran Divekar (see all)
- Principles of Cloud Native Applications: A Hybrid Approach - October 31, 2017
- OpenStack Summit, May 2017, Boston – An Experience - May 18, 2017
- Kubernetes Networking Internals - March 8, 2017