communicate each other to exchange information that allows them to get the current network topology and compute the paths to reach possible destinations. Routing protocols give the Internet the ability to dynamically adjust to changing conditions such as topology changes, links and node failures, and congestion situations. There are two main classes of routing protocols in use on IP networks. Interior gateway protocols based distance‐vector routing protocols, such as Routing Information Protocol (RIP) [15], Enhanced Interior Gateway Routing Protocol (EIGRP) [16], or based on link‐state routing protocols, such as Open Shortest Path First (OSPF) [17], Intermediate System to Intermediate System IS‐IS [18], are used in networks that belong to the same administrator domain, i.e. within the same Autonomous System (AS). Interior gateways protocols base their decision on the minimization of the path costs, defined as the sum of link costs. As such, they aim at minimizing the cost of routing the traffic, i.e. maximizing the performance. Exterior gateway protocols aim instead at exchanging routing information between Autonomous Systems and finding the most convenient path – in terms of Autonomous Systems – to reach the destination. Here, Border Gateway Protocol (BGP) [19] is the de facto only choice. It is a path‐vector routing protocol and it makes routing decisions based on network policies and rules and not based on cost functions. BGP allows network operators to define routing policies that reflects administrative costs and political decisions in terms of agreements between Autonomous Systems.
Given the importance of optimizing exterior routing policies and the partial view that each network operator can get of the global Autonomous System (AS) level topology, several mechanisms are in place to gain visibility on the current Internet routing. Among those, the University of Oregon Route Views Project [20] leverages information provided by collectors, vantage points that expose their partial view of the BGP data, to create interactive maps, which are historized and made browsable via an ecosystem of tools and software that simplify the management and query of the information [21]. Thanks to Routeviews and the information exposed by BGP, it is possible to observe Internet‐wide outages [22, 23], routing hijacking [24], routing anomalies [25], or check the IPv4 address space utilization [26].
All the above‐mentioned routing protocols implement closed loop mechanisms – from monitoring to actions. Another category of routing protocols enable traffic engineering and network management opportunities. Among those, Multiprotocol Label Switching (MPLS) [27] is a routing technique based on the label swapping principle. Each node along the path reads the incoming packets' label and uses it to quickly route the packets to the next hop. Before the forwarding operation, the packet label is replaced with a new label that indicates the next forwarding operation to be done at the next node. Via a concatenation of labels, packets follow a pre‐computed path (a so called MPLS tunnel), which is distributed to all the nodes along the path prior the actual transmission. This on the one hand avoids complex look‐ups in the routing table, and on the other hand it enables the definition of explicit and well‐controlled paths that traffic flows will follow. By computing explicit tunnels is then possible to implement complex traffic engineering policies [28], setup end‐to‐end virtual private networks (VPNs) [29], and design specific protection mechanisms that quickly recover connectivity in case of failures [30].
1.3 Network Configuration Protocol
As said, while there has been a standardized means to collect information about the status of devices and of traffic, each vendor typically offers its own mechanisms to distribute configurations. The heterogeneity of devices, vendors, and versions makes indeed it difficult to define a common and flexible structure able to support and fit different requirements. This hampered the adoption of standard protocols, which are confined to a mostly academic design, with little deployment.
1.3.1 Standard Configuration Protocols and Approaches
The NETCONF protocol is an example of a standard mechanisms that allow to install, manipulate, and delete the configuration of network devices [31]. It uses an XML‐based data encoding for the configuration data as well as the protocol messages. A key aspect of NETCONF is that it allows the functionality to closely mirror the native command‐line interface of the device. It provides a standard way for authentication, data integrity, and confidentiality. For this, it depends on the underlying transport protocol for this capability. For example, connections can be encrypted in TLS or SSH, depending on the device support. Along with NETCONF, a data modeling language defining the semantics of operational and configuration data, notifications, and operations has been defined via the introduction of the YANG modeling language [32]. Neither NETCONF nor YANG ever succeed in becoming an actual standard, given the difficulty to find a common and flexible ground that fits all requirements.
The Internet Engineering Task Force (IETF) defined a general policy framework for managing, sharing, and reusing policies in a vendor‐independent, interoperable, and scalable manner [33]. The Policy Core Information Model (PCIM) is an object‐oriented information model for representing policy information. It specifies two main architectural elements: the Policy Enforcement Point (PEP) and the Policy Decision Point (PDP). Policies allow an operator to specify how the network is to be configured and monitored by using a descriptive language. It allows the automation of management tasks, according to the requirements set out in the policy module. The IETF Policy Framework has been accepted by the industry as a standard‐based policy management approach and has been adopted by the third Generation Partnership Project (3GPP) standardization as well.
The Common Open Policy Service (COPS) is a protocol that provides a client/server model to support policy control. The COPS specification is independent of the type of policy being provisioned (QoS, security, etc.) but focuses on the mechanisms and conventions used to distribute information between PDPs and PEPs. COPS has never been widely deployed because operators found its use of binary messages complicates the development of automated scripts for simple configuration management tasks.
1.3.2 Proprietary Configuration Protocols
As previously said, each vendor has implemented its own solution to collect, change, distribute configurations and system updates. Big vendors such as Cisco Systems, Juniper Networks, Huawei, etc. provide different suites that range from solutions for simple local area networks (LANs), to internet provider scale solutions. The so called Network Management Systems [34] simplify the management of the administered network offering centralized solutions that allow one to perform device discovery, monitoring and management, network performance analysis, intelligent notifications, and customizable alerts. To interact with devices, they build on standard protocols such as SNMP or syslog, but often use also custom solutions based on Command Line Interfaces (CLI) that can be reached via SSH or telnet (deprecated for security reasons). For instance, the Cisco Configuration Professional is a Graphical User Interface (GUI)‐based device management tool for Cisco access routers. This tool simplifies routing, firewall, Intrusion Prevention System (IPS), VPN, unified communications, wide area network (WAN) and LAN configurations through GUI‐based easy‐to‐use wizards.
1.3.3 Integrated Platforms for Network Monitoring
As previously said, vendors and third party companies offer a portfolio of management solutions, which range to simple network management for small deployments, to Internet Service Provider scale solutions, from LAN to Data Center Networks.
The main goal of these platforms is to offer a unified view of the network and service status. These platforms are able to collect data from devices belonging to an administration domain via SNMP, Syslog, IPFIX, and proprietary solutions. Often they implement an automatic discovery mechanism to find and add devices to their collection base so to minimize administrator intervention. Via a GUI, they present views of the status of the network, showing time series of link and CPU load, divided by applications or origin‐destination of the traffic. The administrator is thus offered a unified view of the network status, with the ability to drill down into more details directly interacting with the GUI. They can also detect network
