Network function virtualization: Difference between revisions

Content deleted Content added
No edit summary
Wdpp (talk | contribs)
m Practical aspects: Modify an internal link
Line 29:
A service provider that follows the NFV design implements one or more virtualized network functions, or ''VNFs''. A VNF by itself does not automatically provide a usable product or service to the provider's customers. To build more complex services, the notion of ''service chaining'' is used, where multiple VNFs are used in sequence to deliver a service.
 
Another aspect of implementing NFV is the ''orchestration'' process. To build highly reliable and scalable services, NFV requires that the network be able to instantiate VNF instances, monitor them, repair them, and (most important for a service provider business) bill for the services rendered. These attributes, referred to as carrier-grade<ref name="CG">{{cite web|title=Don't Confuse "High Availability" with "Carrier Grade" | url=http://embedded.communities.intel.com/community/en/blog/2014/04/04/don-t-confuse-high-availability-with-carrier-grade|archive-url=https://web.archive.org/web/20170703015358/https://embedded.communities.intel.com/community/en/blog/2014/04/04/don-t-confuse-high-availability-with-carrier-grade|archive-date=2017-07-03|publisher=Embedded Community|first1=Charlie|last1=Ashton|date=April 2014}}</ref> features, are allocated to an orchestration layer in order to provide high availability and security, and low operation and maintenance costs. Importantly, the orchestration layer must be able to manage VNFs irrespective of the underlying technology within the VNF. For example, an orchestration layer must be able to manage an [[Session border controller|SBC]] VNF from vendor X running on [[VMware]] [[vSphere]] just as well as an [[IP Multimedia Subsystem|IMS]] VNF from vendor Y running on KVM.
 
==Distributed NFV==