Source: Courteously from Juniper Networks.
NFV consists of three main components as sketched in Figure 1.4: On the top, the VNFs to be implemented, using a software solution; the network functions virtualization infrastructure (NFVI) sits in the middle and offers the hardware components over which deploy the VNFs. It includes the physical servers and the network devices that build the NFV infrastructure; at last, the NFV MANagement and Orchestration (MANO) framework allows to manage the platform offering data repositories and standard interfaces to exchange information. To build a complex function, basic blocks can be chained so that a processing pipeline is built. This is called “service chaining” and allows the reuse of highly specialized and efficient blocks to build complex functionalities.
Considering the management operations, clearly NFV requires the network to instantiate, monitor, repair, and bill for the services it offers. NFV targets indeed the large carrier scenario, being it a data center manager, or an internet service providers. These functionalities are allocated to the orchestration layer, which must manages VNFs irrespective of the actual hardware and software technology sitting below.
NFV is a means to reduce cost and accelerate service development and deployment. Instead of requiring the installation of expensive hardware with dedicated functionalities, service providers rely on inexpensive network devices, storage systems, and servers to run virtual machines that implement the desired network function. When a customer asks for a net functionality, the service provider can simply spin up a new virtual machine to implement that function. This has also the benefit to reduce the dependency on dedicated hardware devices, and improve robustness via migration capabilities that move services in case of failures or maintenance operations.
Clearly, NFV calls for standard to allow interoperability of solutions. Since 2012, over 130 of the world's leading network operators have recently joined together to form a European Telecommunications Standards Institute (ETSI) Industry Specification Group (ISG) for NFV (https://www.etsi.org/technologies/nfv). NFV is also fundamental in the 5G arena, where all the advanced functionalities offered by the network like network slicing, edge computing, or decentralized radio management functions are implemented on the top of NFV.
Bibliography
1 1 Caruso, R.E. (1990). Network management: a tutorial overview. IEEE Communications Magazine 28 (3): 20–25.
2 2 Klerer, S.M. (1988). The OSI management architecture: an overview. IEEE Network 2 (2): 20–29.
3 3 (1984). Specification of Signalling System No. 7.
4 4 Case, J.D., Fedor, M., Schoffstall, M.L., and Davin, J. (1990). RFC 1157: simple network management protocol (SNMP). Request for Comments, IETF.
5 5 Case, J., McCloghrie, K., Rose, M., and Waldbusser, S. (1996). RFC 1901: introduction to community‐based SNMPv2. Request for Comments, IETF.
6 6 Harrington, D., Presuhn, R., and Wijnen, B. (2002). RFC 3411: an architecture for describing simple network management protocol (SNMP) management frameworks. Request for Comments, IETF.
7 7 Gerhards, R. (2009). RFC 5424: the syslog protocol. Request for Comments, IETF.
8 8 Claise, B., Bryant, S., Sadasivan, G. et al. (2008). RFC 5101: specification of the IP flow information export (IPFIX) protocol for the exchange of IP traffic flow information. Request for Comments, IETF.
9 9 Paxson, V., Almes, G., Mahdavi, J., and Mathis, M. (1998). RFC 2330: framework for IP performance metrics. Request for Comments, IETF.
10 10 Almes, G., Kalidindi, S., and Zekauskas, M. (1999). RFC 2679: a one‐way delay metric for IPPM. Request for Comments, IETF.
11 11 Hedayat, K., Krzanowski, R., Morton, Al. et al. (2008). RFC 5357: a two‐way active measurement protocol (TWAMP). Request for Comments, IETF.
12 12 Bajpai, V. and Schönwälder, J. (2015). A survey on internet performance measurement platforms and related standardization efforts. IEEE Communication Surveys and Tutorials 17 (3): 1313–1341.
13 13 Hanemann, A., Boote, J.W., Boyd, E.L. et al. (2005). PerfSONAR: a service oriented architecture for multi‐domain network monitoring. In: International Conference on Service‐Oriented Computing ( A. Hanemann, J.W. Boote, E. L. Boyd et al.), 241–254. Springer.
14 14 RIPE NCC Staff (2015). Ripe atlas: a global internet measurement network. Internet Protocol Journal 18 (3). http://ipj.dreamhosters.com/wp-content/uploads/2015/10/ipj18.3.pdf
15 15 Malkin, G. (1998). RFC 2453: RIP version 2. Request for Comments, IETF.
16 16 Savage, D., Ng, J., Moore, S. et al. (2016). RFC 7868: Cisco's enhanced interior gateway routing protocol (EIGRP). Request for Comments, IETF.
17 17 Moy, J. (1998). RFC 2328: OSPF version 2. Request for Comments, IETF.
18 18 Vasseur, J.P., Shen, N., and Aggarwal, R. (2007). RFC 4971: intermediate system to intermediate system (IS‐IS) extensions for advertising router information. Request for Comments, IETF.
19 19 Shalunov, S., Teitelbaum, B., Karp, A. et al. (2006). RFC 4656: a one‐way active measurement protocol (OWAMP). Request for Comments, IETF.
20 20 Meyer, D. (1997). University of Oregon Route Views Project. http://www.routeviews.org/routeviews/.
21 21 Orsini, C., King, A., Giordano, D. et al. (2016). BGPStream: a software framework for live and historical BGP data analysis. Proceedings of the 2016 Internet Measurement Conference, pp. 429–444.
22 22 Giotsas, V., Dietzel, C., Smaragdakis, G. et al. (2017). Detecting peering infrastructure outages in the wild. Proceedings of the Conference of the ACM Special Interest Group on Data Communication, pp. 446–459.
23 23 Luckie, M. and Beverly, R. (2017). The impact of router outages on the AS‐level internet. Proceedings of the Conference of the ACM Special Interest Group on Data Communication, pp. 488–501.
24 24 Sermpezis, P., Kotronis, V., Dainotti, A., and Dimitropoulos, X. (2018). A survey among network operators on BGP prefix hijacking. ACM SIGCOMM Computer Communication Review 48 (1): 64–69.
25 25 Padmanabhan, R., Dhamdhere, A., Aben, E. et al. (2016). Reasons dynamic addresses change. Proceedings of the 2016 Internet Measurement Conference, pp. 183–198.
26 26 Livadariu, I., Elmokashfi, A., and Dhamdhere, A. (2017). On IPv4 transfer markets: analyzing reported transfers and inferring transfers in the wild. Computer Communications 111: 105–119.
27 27 Rosen, E., Viswanathan, A., and Callon, R. (2001). RFC 3031: multiprotocol label switching architecture. Request for Comments, IETF.
28 28 Xiao, X., Hannan, A., Bailey, B., and Ni, L.M. (2000). Traffic engineering with MPLS in the internet. IEEE Network 14 (2): 28–33.
29 29 Pepelnjak, I. and Guichard, J. (2002). MPLS and VPN Architectures, vol. 1. Cisco Press.
30 30 Huang, C., Sharma, V., Owens, K., and Makam, S. (2002). Building reliable MPLS networks using a path protection mechanism. IEEE Communications Magazine 40 (3): 156–162.
31 31 Enns, R., Bjorklund, M., Schoenwaelder, J., and Bierman, A. (2011). RFC 6241: network configuration protocol (NETCONF). Request for Comments, IETF.
32 32 Bjorklund, M. (2010). RFC 6020: Yang ‐ a data modeling language for the network configuration protocol (NETCONF). Request for Comments, IETF.
33 33 Yavatkar, R., Pendarakis, D., Guerin, R. et al. (2000). RFC 2753: a framework for policy‐based admission control. Request for Comments, IETF.
34 34 Martin‐Flatin, J.‐P., Znaty, S., and Hubaux, J.‐P. (1999). A survey of