NFV (Network Function Virtualization)
Last updated
Last updated
NFV (Network Function Virtualization) is the decoupling of the function that a network appliance preforms, from its hardware. NFV is basically a software implementation of networking functions, such as routers, switches, firewalls, load balancers, etc.
To that end, you might be tempted to say: “OK, I am familiar with the CSR1000v, ASAv, etc. so I understand what NFV is and that’s all I need to know.”
However there is more to NFV that simply putting networking functions into software. NFV is largely driven by the ETSI (Eurpoean Telecommunication Standards Institute), which writes specifications for NFV and the management and orchestration of NFV. The idea behind this, is that separate vendors must conform to an agreed-upon method of deploying and managing NFV solutions.
The broader picture behind NFV is that a service provider can quickly provision new services for customers and begin billing immediately. Instead of a service provider needing to purchase hardware for a service, schedule a technician to install it, etc., the provider can use their NFV Orchestration tool to immediately provision and chain together VNFs (Virtual Network Functions) to provide a service to a customer.
Around 10 years ago, members from several telecoms and vendors came together to write a whitepaper titled Network Functions Virtualization: An Introduction, Benefits, Enablers, Challenges & Call for Action. You can find it here: https://docbox.etsi.org/isg/nfv/open/Publications_pdf/White Papers/NFV_White_Paper1_2012.pdf
This spurred the NFV working group in the ETSI, and work to standardize NFV commenced.
The ETSI defines the NFV architecture as the following:
The NFVi is the resource pool of hardware and virtual resources for the environment. This includes RAM, NAS, NICs, etc. The NFVi gaurantees allocation of resources on a per-VNF basis and contains the hypervisor. Simply put, the NFVi is the physical infrastructure and the virtualization technology.
A single virtualized network function is called a VNF. However, the process of virtualization of network function is called NFV. This can be a little difficult to get straight at first. An ASAv would be a VNF in the overall architecture of an NFV solution. Multiple VNFs map together in a process called service chaining.
Each VNF has an EM (Element Manager) which manages the VNF itself through its proprietary interface.
This manages and orchestrates the virtualized infrastructure (NFVi) and the VNFs. There are three separate categories:
NVF Orchestrator
This is the highest level orchestrator which is responsible for the entire NFV solution.
The NVF orchestrator is concerned with higher level services. These services may involve multiple VNFs that need to be chained together.
VNF Manager
This is a level lower than the NVF orchestrator, which manages the life cycle of individual VNFs.
VIM (Virtualized Infrastructure Manager)
The is the lowest level manager, which manages the NFVi itself.
This is a general term for the management of the NFV (config management, service management, fault management, etc) and the integration of business goals (managing the customer allocations, orders, billing based on usage, etc.). The BSS can drive the NVF orchestrator by requesting for new services to be spin up, etc.
The VNF manager is responsible for the virtualization of the VNF, such as starting and stopping VNFs and scaling them up and down. The EM is responsible for managing the function of a VNF, for example manging the firewall policies on an ASAv.
This is a VNF manager that preforms lifecycle management. ECS can scale VNFs up/down as needed and provide VM recovery.
NSO acts as a NFV Orchestrator, and can integrate with ECS and Openstack (a possible NFVi). NSO can define higher level services using YANG models.
ASAv, CSR1000v, XR9000v, WLCv, etc.
NFV as a technology hasn’t quite taken off like people thought it would 10 years ago. NFV isn’t quite the buzzword that it used to be. Migrating to NFV is quite difficult, and in many cases the cost savings isn’t quite enough to justify the complexity and potentially additional speacialized staff to support and operate NFV.
Check out this blog post from Cisco: https://blogs.cisco.com/sp/3-pathways-to-nfv-success-or-how-to-tame-the-nfv-sdn-monster
Cisco has an incentive to sell NFV products and services, so you could argue that they have an incentive to push people towards NFV. This response to that blog post is very entertaining to read and brings up some great points as to why we don’t see greater NFV adoption today: https://blog.cimicorp.com/?p=3047
https://www.youtube.com/watch?v=FrLWS0GBcRw&ab_channel=JoeJames
Good down-to-earth explaination of NFV
https://www.youtube.com/watch?v=pGLPUqVFP0o&ab_channel=A10Networks
Good basic overview of NFV archiecture
https://www.youtube.com/watch?v=xsd5nhG0RBs&ab_channel=xFlowResearch
Very quick overview of NFV architecture. I would only recommend it as a refresher.
https://www.youtube.com/watch?v=Vl5UJUR1uV4&ab_channel=TelecomTutorialinfo
This is quite a lengthy description of NFV. You can get these concepts elsewhere, but if you want something longer format you might be interested in this. It is a bit long winded and in my opinion doesn’t contain anything not present in the previous videos and subsequent articles below.
https://en.wikipedia.org/wiki/Network_function_virtualization
https://www.redhat.com/en/topics/virtualization/what-is-nfv
https://www.reddit.com/r/networking/comments/ipcsnd/whats_the_difference_between_a_nfv_orchestrator/
The blog from Cisco linked in the comments is dead, use this link: https://web.archive.org/web/20200311164804/https://www.cisco.com/c/en/us/solutions/software-defined-networking/sdn-vs-nfv.html
https://telcocloudbridge.com/blog/a-cheat-sheet-for-understanding-nfv-architecture/
