Improving flexibility, provisioning, and manageability in intra-domain networks

Internet has a hierarchical structure, in which network devices (e.g., routers) are grouped into logical areas. Each area is called Autonomous System (AS) and it is typically under the control of a single organization, also called Internet Service Provider (ISP). An ISP takes decisions in terms of routing protocols to use for forwarding traffic. Routing inside intradomain networks is typically realized combining several protocols, which collaborate in order to provide services, even basic like connectivity. This makes protocols specialized on a specific task (e.g., guarantee certain levels of quality of service) giving to network administrators the possibility to choose among different protocols in order to accomplish a specific activity (e.g., computing paths in the network). Such coexistence surely aims at improving flexibility, but it also leads to problems in terms of network’s manageability, making the provisioning of services more difficult. The main goal for an ISP consists in having a fine-grade control over the routing paths in the network, which gives to the ISP itself the opportunity of exploiting its network efficiently; at the same time, making the management of the network simpler, for example reducing both the configuration and troubleshooting effort, is also a desirable target. In this thesis, four different contributions are presented, aimed at: 1) making routing flexible; 2) simplifying the provisioning of the services; 3) making the manageability of the network sustainable for network administrators. The emphasis is on how flexibility and manageability can be improved using both distributed and centralized approaches. On the other hand, provisioning can be significantly improved by using a centralized paradigm, like Software-Defined Networking (SDN): having a single logic place in which to locate the entire control for a service allows network administrators to also decrease the configuration effort in the setup of that service, as well as to have very high levels of flexibility. Adopting the novel approaches proposed by SDN raises new challenges: after showing the benefits brought by it, interoperability issues are addressed, as well as a review of the most relevant state of the art contributions on SDN, checking whether they are applicable on real OpenFlowenabled switches. The thesis is organized as follows. The chapters from 2 to 4 describe respectively three contributions aimed at making the routing as flexible as possible, as well as reducing configuration and troubleshooting problems; chapter 5 describes contribution in terms of how the most relevant SDN state of the art is not applicable on current OpenFlow-enabled switches. 1 The first contribution is referred to a distributed control plane aiming to improve flexibility and manageability. This control plane relies on approaches like multipath and source routing in order to provide to network administrators tools that make the manageability of the network simpler; moreover, exploiting multipath and source routing, the control plane also improves flexibility in the network. The second contribution is a solution aiming at improving provisioning, as well as flexibility and manageability. The idea behind this contribution is the following: can OpenFlow, the most used protocol enabling SDN, replace many protocols in order to provide a service? Starting from a well known and widely used service in production networks, Virtual Private Networks, a rethinking activity has been performed, in order to make its provisioning and manageability faster and simpler, by reducing the number of protocols involved in setting up this service and, consequently, the configuration effort. Indeed, setting up a Virtual Private Network is not trivial: many protocols are typically involved, each of which has a specific task; being flexible is not simple as well, because the interaction among protocols is realized by tuning some configuration parameters; also the management of the service itself is hard, because the configuration of a Virtual Private Network is scattered among many devices; this makes troubleshooting hard as well. As a consequence of using just one protocol based on a centralized approach like OpenFlow, and observing that it typically has a complete view of the network, a new centralized specification language for setting up Virtual Private Network is also defined. The third contribution addresses an interoperability problem. Indeed, today’s networks strongly rely on the Address Resolution Protocol (ARP), a protocol for building the association between IP and MAC addresses; this protocol is also executed by end-systems, that do not play any active role in the operation of an SDN, like computers; hence an interoperability mechanism is needed, allowing OpenFlow-enabled switches to correctly handle ARP packets. This protocol generates broadcast traffic that typically traverses local networks: the simpler and most adopted solution for handling this kind of traffic using OpenFlow is to re-implement the ARP protocol behavior. However, this choice does not take into account the power of SDN. Exploiting the SDN approach, a solution that prevents broadcast ARP packets from passing through the local SDN-enabled networks has been proposed; in particular, these packets can be bounded at the edge of the network, making the handling of ARP traffic more efficient. The fourth contribution is an investigation on the readiness of real devices to run centralized protocols like OpenFlow. The idea is very simple: OpenFlow 1.0.0 is the first standard, and it was released in 2009; the most recent, OpenFlow 1.5.1, has been released around the half of 2015; is the SDN state of the art applicable using real devices? Moreover, which is the level of compliance of the real network devices with the OpenFlow standard after six years? The former question arises because many evaluations and experiments of SDN papers have been conducted in a simulated environment. We reviewed the most relevant state of the art talking about SDN, aiming at understanding if they are applicable. We also investigated features in terms of functions and performance of those devices