Control Plane Compression

We develop an algorithm capable of compressing large networks into a smaller ones with similar control plane behavior: For every stable routing solution in the large, original network, there exists a corresponding solution in the compressed network, and vice versa. Our compression algorithm preserves a wide variety of network properties including reachability, loop freedom, and path length. Consequently, operators may speed up network analysis, based on simulation, emulation, or verification, by analyzing only the compressed network. Our approach is based on a new theory of control plane equivalence. We implement these ideas in a tool called Bonsai and apply it to real and synthetic networks. Bonsai can shrink real networks by over a factor of 5 and speed up analysis by several orders of magnitude.Comment: Extended version of the paper appearing in ACM SIGCOMM 201

Optimal route reflection topology design

An Autonomous System (AS) is a group of Internet Protocol-based networks with a single and clearly defined external routing policy, usually under single ownership, trust or administrative control. The AS represents a connected group of one or more blocks of IP addresses, called IP prefixes, that have been assigned to that organization and provides a single routing policy to systems outside the AS. The Internet is composed of the interconnection of several thousands of ASes, which use the Border Gateway Protocol (BGP) to exchange network prefixes (aggregations of IP addresses) reachability advertisements. BGP advertisements (or updates) are sent over BGP sessions administratively set between pairs of routers. BGP is a path vector routing protocol and is used to span different ASes. A path vector protocol defines a route as a pairing between a destination and the attributes of the path to that destination. Interior Border Gateway Protocol (iBGP) refers to the BGP neighbor relationship within the same AS. When BGP neighbor relationship are formed between two peers belonging to different AS are called Exterior Border Gateway Protocol (eBGP). In the last case, BGP routers are called Autonomous System Border Routers (ASBRs), while those running only iBGP sessions are referred to as Internal Routers (IRs). Traditional iBGP implementations require a full-mesh of sessions among routers of each AS

On constructing correct and scalable iBGP configurations

Thesis (S.M.)--Massachusetts Institute of Technology, Dept. of Electrical Engineering and Computer Science, 2006.Includes bibliographical references (p. 51-53).BGP (Border Gateway Protocol), the Internet's current inter-domain routing protocol, has two modes of operation: eBGP (external BGP, used to exchange routing information between autonomous systems (ASes)), and iBGP (internal BGP, used to propagate that information about external destinations to other BGP routers within an AS). Full-mesh iBGP and iBGP with route reflection are the two most common methods of configuring iBGP. Although a full-mesh iBGP guarantees correct and predictable routing, it requires a large number of iBGP sessions-approximately quadratic in the number of BGP routers. Such configurations do not scale well in the number of BGP routers in the AS because of the memory, bandwidth and CPU overhead involved in exchanging routes over a large number of iBGP sessions at each router. Hence configurations based on route reflectors are commonly used for intra-AS route dissemination in large ASes. However, researchers have found that configuring route reflectors in an unprincipled fashion can result in routing anomalies like forwarding loops and sub-optimal paths. Although previous work on iBGP configuration correctness gives sufficient conditions to check if a given iBGP configuration is correct, the problem of constructing correct and scalable iBGP configurations using route reflection has not received much attention.(cont.) This thesis proposes and analyzes the first (to our knowledge) algorithm to construct iBGP session configurations that are both correct and more scalable than a full-mesh iBGP. Our algorithm, BGPSep, uses the notion of a graph separator--a small set of nodes whose removal partitions a graph into connected components of roughly equal sizes--to choose route reflectors and iBGP sessions in a way that guarantees correctness. We evaluate an implementation of the BGPSep algorithm on several real-world network topologies and find that iBGP configurations generated by BGPSep have between 2.5 to 5 times fewer iBGP sessions than a full-mesh.by Mythili Vutukuru.S.M

BGP-XM: BGP eXtended Multipath for Transit Autonomous Systems

Multipath interdomain routing has been proposed to enable flexible traffic engineering for transit Autonomos Systems (ASes). Yet, there is a lack of solutions providing maximal path diversity and backwards compatibility at the same time. The BGP-XM (Border Gateway Protocol-eXtended Multipath) extension presented in this paper is a complete and flexible approach to solve many of the limitations of previous BGP multipath solutions. ASes can benefit from multipath capabilities starting with a single upgraded router, and without any coordination with other ASes. BGP-XM defines an algorithm to merge into regular BGP updates information from paths which may even traverse different ASes. This algorithm can be combined with different multipath selection algorithms, such as the K-BESTRO (K-Best Route Optimizer) tunable selection algorithm proposed in this paper. A stability analysis and stable policy guidelines are provided. The performance evaluation of BGP-XM, running over an Internet-like topology, shows that high path diversity can be achieved even for limited deployments of the multipath mechanism. Further results for large-scale deployments reveal that the extension is suitable for large deployment since it shows a low impact in the AS path length and in the routing table size

Multi-path BGP: motivations and solutions

Although there are many reasons towards the adoption of a multi-path routing paradigm in the Internet, nowadays the required multi-path support is far from universal. It is mostly limited to some domains that rely on IGP features to improve load distribution in their internal infrastructure or some multi-homed parties that base their load balance on traffic engineering. This chapter explains the motivations for a multi-path routing Internet scheme, commenting the existing alternatives and detailing two new proposals. Part of this work has been done within the framework of the Trilogy research and development project, whose main objectives are also commented in the chapter.Part of this work has been done within the framework of the Trilogy research and development project. The different research partners of this project are: British Telecom, Deutsche Telekom, NEC Europe, Nokia, Roke Manor Research Limited, Athens University of Economics and Business, University Carlos III of Madrid, University College London, Universit Catholique de Louvain and Stanford University.European Community's Seventh Framework ProgramEn prens

Seedemu: The Seed Internet Emulator

I studied and experimented with the idea of building an emulator for the Internet. While there are various already available options for such a task, none of them takes the emulation of the entire Internet as an important feature in mind. Those emulators and simulators can handle small-scale networks pretty well, but lacks the ability to handle large-size networks, mainly due to: - Not being able to run many nodes, or requires very powerful hardware to do so,- Lacks convenient ways to build a large emulation, and - Lacks reusability: once something is built, it is very hard to re-use them in another emulation I explored, in the context of for-education Internet emulators, different ways to overcome the above limitations. I came up with a framework that enables one to create emulation using code. The framework provides basic components of the Internet. Some examples include routers, servers, networks, Internet exchanges, autonomous systems, and DNS infrastructure. Building emulation with code means it is easy to build emulation with complex topologies since one can make use of the common control structures like loops, subroutines, and functions. The framework exploits the idea of ``layers.\u27\u27 The idea of ``\emph{layers}\u27\u27 can be seen as an analogy of the idea of ``layers\u27\u27 in image processing software, in the sense that each layer contains parts of the image (in this case, part of the emulation), and need to be ``rendered\u27\u27 to obtain the resulting image. There are two types of layers, base layers and service layers. Base layers describe the ``base\u27\u27 of the topologies, like how routers, servers, and networks are connected, how autonomous systems are peered with each other; service layers describe the high-level services on the Internet. Examples of services layers are web servers, DNS servers, ethereum nodes, and botnet nodes. No layers are tied to any other layers, meaning each layer can be individually manipulated, exported, and re-used in another emulation. One can build an entire DNS infrastructure, complete with root DNS, TLD DNS, and deploy it on any base layer, even with vastly different underlying topologies. The result of the rendered layer is a set of data structures that represents the objects in a network emulation, like host, router, and networks. These representations can then be ``compiled\u27\u27 into something that one can execute using a compiler. The main target platform of the framework is Docker. The source of the SEEDEMU project is publicly available on Github: https://github.com/seed-labs/seed-emulator

Formal Analysis of Network Protocols

Today’s Internet is becoming increasingly complex and fragile. Current performance centric techniques on network analysis and runtime verification have became inadequate in the development of robust networks. To cope with these challenges there is a growing interest in the use of formal analysis techniques to reason about network protocol correctness throughout the network development cycle. This talk surveys recent work on the use of formal analysis techniques to aid in design, implementation, and analysis of network protocols. We first present a general framework that covers a majority of existing formal analysis techniques on both the control and routing planes of networks, and present a classification and taxonomy of techniques according to the proposed framework. Using four representative case studies (Metarouting, rcc, axiomatic formulation, and Alloy based analysis), we discuss various aspects of formal network analysis, including formal specification, formal verification, and system validation. Their strengths and limitations are evaluated and compared in detail