Communication Networks and Service Management in the Era of Artificial Intelligence and Machine Learning

SDN is often associated with the OpenFlow protocol [38] that enables the remote communication with the network plane elements and the controller. However, for many companies, it is no longer an exclusive solution, and proprietary techniques are now available like the Open Network Environment and Nicira's network virtualization platform. They all offer the standard API to communicate via the southbound interface.

Network Functions Virtualization (NFV) is a network architecture that strongly builds on the top of virtualization concepts [39]. It offers the ability to virtualize network nodes and functions into building blocks which can be connected and chained to create more complex communication services. A virtualized network function (VNF) consists of one or more virtual machines and containers that run specific software to implement networking operations in software. Firewalls, access list controllers, load balancers, intrusions detection systems, VPN terminators, etc. can thus be implemented in software – without buying and installing expensive hardware solutions.

Figure 1.4 Network functions virtualization architecture.

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.

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.