Internet eXchange points: current challenges and new opportunities

Abstract

Internet is defined by many as “The Network of Networks”. This is because we can imagine it as an interconnection of many components. Their name is Autonomous Systems (ASes) and they are networks connected to each other under the control of a unique administrative authority. Some Autonomous Systems offer Internet services directly to users or companies and they are called Internet Services Providers (ISPs). The main feature of an Autonomous System is that it communicates explicitly to the rest of the Internet which networks are under its control and which networks are reachable via its infrastructures. In the course of time, th Internet has become “unbalanced”: Big portions of the Internet have became reachable just by very big Autonomous Systems paid by smaller ones to provide them access the rest of Internet – the “ Big Internet”. In this context a special role is played by Internet eXchange Points, that are infrastructures that give ASes the opportunity to directly connect each other in order to exchange traffic without using other providers, thus reducing distances and costs. IXPs play a crucial role in the development of the Internet, encouraging ISPs to create a dense network of interconnections at low cost. Some of them (e.g., DE-CIX, AMS-IX, and LINX) have a throughput of many Tbit/sec. and are some of the most important building blocks of today’s Internet. IXPs have also been studied as one of the causes of the evolution from a traditional hierarchical Internet to a more “flattened” version with AS-path getting shorter over time. In this thesis, we deeply study Internet eXchange Points from a variety of view points:

• Recent trends say that major ISPs are canceling their peerings at IXPs (de-peering). In several occasions they justified such decision in terms of more efficient handling of IP traffic and improvement of the Quality of Services (QoS). In this thesis we try to claim the opposite, performing many measurements and showing how IXPs impact positively on Internet performance keys. We also study whether IXPs are effective in preserv- ing traffic locality, by checking which countries are traversed to reach frequently visited Italian destinations from Italian sources; • We comprehensively examine the evolution of IXPs over a long period of time, characterizing its evolution and quantifying the impact they have on end-to-end paths in particular with regards to the flattening phenomenon, i.e., the reduction in the number of the as-level hops. We believe that this analysis shed light on the impact over time of a critical Internet infrastructure and how it has shaped the current Internet, as well as estimates the impact of new IXPs in the Internet ecosystem; • Very often, Route Server functionalities are mainly leveraged by small providers and Content Delivery Networks since these players have strong interests in connecting to many IXP members by just setting up a single BGP peering with RS. On the other hand, big Internet players, with very few exceptions, tend to not have BGP peerings with an RS. We argue that this trend is the result of exposing an IXP member to a potential violation of privacy in terms of BGP policies when peering with an RS. We present a Route Server (RS) system that improves both the privacy guarantees of confidential peering information and the security of the RS; • Federated networks represent a collaborative operational way for Internet Service Providers (ISPs) to increase revenues by sharing resources. One of the main challenges in this architecture is finding a common physical place where members can connect to each other. In this thesis we claim and show how IXPs could play an important role in this sense, reducing costs for network operators and offering them many opportunities. In particular we present a Federated Network scenario where we use an IXP as a common point for the federation and we rely on Software Defined Network in order to address management and technological challenges in a flexible and customizable way. Furthermore, starting from the idea of Software Defined eXchange point(i.e. an IXP totally based on SDN) we study the applicability of many approaches proposed in literature. We study the impact of peering at IXPs on common network key metrics by collaborating with three medium-size ISPs, in order to actively control their BGP announcements and force the traffic to take specific routes for useful comparison. We perform experiments in which network paths between two ASes either traverse IXPs or rely only on upstream providers. Such experiments help us determine to which degree IXPs are actually beneficial for involved peers. We perform measurements regarding the following network metrics: round-trip time, hop count, packet-loss, and jitter. We try also to have an historical view on IXP: fuelled by an increasing demand for peering, IXPs grew in number, geographical scope and size, becoming a critical element of the Internet structure. In this thesis we study their evolution over a long period of time and quantify the disruptive impact of IXPs relying on comprehensive historical datasets covering a decade of the Internet evolution. We first study how the IXPs ecosystem has evolved. We then identify how the dependence on transit providers has changed over time by looking at the increasing reachability attainable by peering at existing IXPs. We show that even though nowadays there is more than the double of IXPs than ten years ago, the percentage of announced IPv4 addresses that can be reached through them has increased less than 10%, from approximately 70% to nearly 80% -even despite of the IPv4 exhaustion. Using this analysis as an starting point, we then quantify the specific impact of the emergence and growth of IXPs. By identifying IXPs in the historical traceroutes we quantify and characterize the specific impact of IXPs on how the flattening phenomenon is conflated with the stability in the average as-level path length. Organizations that offer Internet-based services (Internet Service Providers, Content Delivery Networks, etc.) join the Internet eXchange Points (IXPs) in order to quickly and easily reach a number of other parties networks, and gain the level of connectivity they need. Currently, IXPs offer a very useful service, called Route Server (RS). An RS allows each member connected to an IXP to easily exchange traffic with other members by establishing a peering session with the RS, instead of having one peering with each other member he wants to be connected to. Peering sessions are handled by the Border Gateway Protocol (BGP), the standard interdomain routing protocol. Surely, this functionality significantly reduces the effort needed by the IXP members to connect to the Internet. However, such organizations are usually concerned with business-critical aspects as privacy of the peering relationships, privacy of routing policies and security of the network infrastructure (links, devices). We present a Route Server system that improves both the privacy guarantees of confidential peering information and the security of the RS. Our key idea is to prevent the RS from locally storing any BGP policies. Instead, the RS queries routing policies in on-demand manner by means of a second communication channel that we instantiate between the RS and each IXP member. Internet eXchange Points can play an important role also in the future of Federated Network. Federated networks represent a remunerable opera- tional way allowing federated partners to increase their incomes through a sharing resource process. They have been primarily used in the context of cloud computing; nowadays they are also used to provide connectivity services, like Virtual Private Networks. Federated networks represent a collaborative operational way for Internet Service Providers (ISPs) to increase revenues by sharing resources [GGT10]. A federated network can be defined as a network in which federated partners or members (e.g. ISPs) share their own resources with any other federated member in order to satisfy growing demands from customers or possibly issue value-added services (e.g. services that could not be provisioned without the federated network itself). A federated PoP is a physical place in which all ISPs involved in a federation connect each other. In general, establishing a federated PoP needs many steps, consisting of different activities. For instance, there is the need of establishing connectivity (e.g. by using dark fiber), as well as overcoming technical difficulties (e.g. due to different physical layer technologies). Other steps regard the need of installing and using new hardware (e.g. switches) that will be used by each ISP to connect to each other and all equipments to monitor the services issued by the federation. The network hardware in a federated PoP can be either hardware owned by the provider itself or shared hardware owned by the federation. It is easy to note that the federated PoP architecture strictly recall that of any Internet eXchange Point (IXP), where providers are interconnected in order to allow their customers to exchange traffic. Relying on Software Defined Network and the idea of IXP as PoP for a federated network we present a SDN-based framework. Our framework is completely based on SDN. We choose to rely on that architecture since it brings flexibility in providing services and it also makes the provisioning phase easier. Such a choice allows us to overcome the challenges in current federated networks architecture. Indeed, we identify one main problem in the architecture, namely the federated PoP. On one hand, such an interconnection point brings several benefits (e.g. clear identification of a place in which providers can federate and clear responsibilities assignment to each federated provider). On the other hand, federated PoPs are duplicates of IXPs, requiring further effort for federated providers in terms of expenses and configurations (e.g. buying and managing devices used in the federated PoP). We argue that being connected to an IXP is enough to create a federation and this requirement is easily satisfied by providers. Often devil is in the details and also something that seems to be stable and working for years can suddenly break as we add new components. The Address Resolution Protocol (ARP) enables communication between IP-speaking nodes in a local network by reconstructing the hardware (MAC) address associated with the IP address of an interface. This is not needed in a Software-Defined Network (SDN), because each device can forward packets without the need to learn this association.We tackle the interoperability problem arising between standard network devices (end systems, routers), that rely on ARP, and SDN datapaths, that do not handle ARP packets natively. In particular, we propose a general approach to handle ARP in a SDN, that is applicable in several network scenarios, is transparent for existing devices, and can coexist with any packet forwarding logic implemented in the controller. A milestone in the research that combines Software Defined Network and Internet eXchange Points is an approach proposed in [GVS + ]. In order to foster the deployment of SDN in the network edge, the paper identifies Internet eXchange Points as a compelling place to start, given their central role in interconnecting many networks and their growing importance in bringing popular content closer to end users. It proposes an Internet eXchange Point totally based on SDN, namely a Software Defined eXchange point. Despite the fervent activity in the scientific community on devising novel network architectures and services that take advantage of SDN, most papers validate their proposals on ad- hoc testbeds, and little attention has been devoted to determining the practical applicability of these approaches using currently available devices. On the other hand, even if OpenFlow is now somewhat mature, vendors seem to lag behind in terms of functionalities supported on their devices. Without precise indications on which features are supported, network administrators interested in switching to SDN may have a hard time trying to find the selection of SDN-enabled devices that best fits their needs. Preserving this dual (scientific and technological) perspective, we contrast a selection of the most important contributions in the literature about SDN with publicly available documentation from device vendors, highlighting the consequent applicability issues that scientific contributions may incur. We define a methodology for testing the readiness of a device to operate in an SDN-based infrastructure, combining existing OpenFlow conformance test tools with other custom tests. In the end we draw a picture of the current status of OpenFlow implementations by applying our methodology to many devices.