M A S T E R ' S T H E S I S
Simulating the Monotonic Paths Protocol as a Solution to the
Stable Paths Problem
Mauel Gômes Dekker
Luleå University of Technology MSc Programmes in Engineering Computer Science and Engineering
Department of Computer Science and Electrical Engineering Division of Computer Science
2006:043 CIV - ISSN: 1402-1617 - ISRN: LTU-EX--06/043--SE
Simulating the Monotonic Paths Protocol as a Solution to the Stable
Paths Problem
Manuel G´ omez Dekker
Lule˚ a University of Technology
Dept. of Computer Science and Electrical Engineering
November 23, 2005
R ESUMEN EN E SPA NOL ˜
Introducci ´ on
Internet est´a dividida en Sistemas Aut´onomos. El protocolo de encaminamiento que se usa en Internet entre ellos es el Border Gateway Protocol, m´as conocido c´omo BGP. BGP destaca por la libertad que ofrece a los administradores de implementar una pol´ıtica sobre los caminos seleccionados a ciertos destinos en Internet. Este grado de libertad es tambi´en el causante de uno de los mayores problemas: la inestabilidad a la hora de recuperarse de ca´ıdas de nodos o enlaces de la red. A ´este problema se le conoce c´omo Stable-Paths Problem (SPP) o Problema de Estabilidad en Rutas.
El siguiente Proyecto de Fin de Carrera (Master Thesis, seg´un la Universidad de Tec- nolog´ıa de Lule˚a o LTU) pretende implementar una de las solucciones al SPP. Nos refe- rimos a la soluci´on propuesta por Jorge A. Cobb, Mohamed G. Gouda y Ravi Musunuri del Departamento de Inform´atica de la Universidad de Texas en [1]. Para ello, usaremos RouteSim [2], un simulador de BGP desarrollado por Johan Nykvist para su Master The- sis en LTU. El prop´osito de este proyecto es estudiar el comportamiento y el rendimiento de la soluci´on propuesta por Cobb, Gouda y Musunuri sobre una abstracci´on de BGP.
“Simulando el Monotonic Paths Protocol c´omo soluci´on al Problema de de Estabili- dad en Rutas” fue realizado por Manuel G´omez Dekker, y supervisado por Lenka Carr Motyck´ova, en la Lule˚a Tekniska Universitet en Suecia, c´omo parte del programa de intercambio Erasmus. Fue presentado el 5 de Diciembre de 2005, y evaluado por Lenka Carr Motyck´ova y Per Lindgren.
Encaminamiento en Internet
Internet comprende un n´umero muy elevado de ordenadores. Para mantenerla f´acilmente administrada, Internet est´a dividia en subredes por medio de Routers. Encaminamiento o Routing es la forma mediante la cual los routers descubren nuevos caminos y se ha- cen accesibles entre ellos. Para poder llevar a cabo esta tarea, se utilizan protocolos de encaminamiento din´amicos, ya que le n´umero de redes hace imposible mantener a
iii
en un algoritmo del segundo tipo: Path Vector Routing, o encaminado seg´un el vector camino. En ´este tipo de encaminado, los nodos comunican a sus vecinos m´as inmediatos los caminos escogidos para cada red de destino. Seg´un lo recibido, cada nodo elige un camino a cada destino y lo comunica a su vez. Ejemplos de ´este tipo de algoritmos pueden encontrarse en el cap´ıtulo 2.
El encaminamiento tendr´a lugar entre Sistemas Aut´onomos (AS, siglas del t´ermino saj´on Autonomous Systems), y el protocolo a estudiar ser´a BGP. Los AS son las m´aximas subredes con un mismo administrador en Internet. Generalmente, un AS puede compren- der un Proveedor de Servicios de Internet (ISP), una red corporativa o gubernamental, etc. Los ASs usan dos protocolos de encaminamiento: uno interior (OSPF, RIP) y otro exterior. El est´andar actual define BGP c´omo protocolo de encaminamiento externo.
Para el buen funcionamiento de las redes, cada AS debe mostar una imagen consistente de su estructura interna, independientemente del protocol utilizado internamente.
BGP es un protocol basado en el Path Vector Routing. El ´exito de BGP radica en la libertad de implementar pol´ıticas y m´etricas sobre las decisiones de los routers en torno a los caminos elegidos para cada destino; BGP obedece a los intereses tecnol´ogicos y sociales del administrador de cada AS.
BGP basa su funcionamiento en cuatro tipos de mensajes: OPEN, usado para comenzar una sesi´on BGP entre dos interlocutores); UPDATE, usado para intercambiar informaci´on de encaminamiento; KEEPALIVE, que mantiene la conexi´on “viva”, y NOTIFICATION, usada para informar de posibles errores en la transmisi´on.
El Problema de Estabilidad en Rutas
BGP muestra un comportamiento inestable en algunas topolog´ıas de red y situaciones.
Las razones principales son tres: pol´ıticas de encaminado locales, que obedecen a intereses privados; pol´ıticas de encaminado secretas, que no permiten su an´alisis para descubrir topolog´ıas conflictivas; y la introducci´on de t´ecnicas que no soluccionan el problema, y que incluso lo agravan m´as (Route-Flap-Damping, [3]).
Para soluccionarlo, hasta ahora se han estudiado tres tipos de aproximaciones: el an´alisis de las rutas escogidas por cada AS, imposible de llevar a cabo, ya que restringir´ıa el grado de libertad de BGP; el an´alisis de las rutas escogidas por cada router en tiempo de ejecuci´on, lo cual m´as dif´ıcil de implementar, ya que necesitar´ıa una mejora del hard- ware sobre el que se ejecutan los protocolos y algoritmos de encaminamiento; y el es- tablecimiento de una estructura jer´arquica en Internet, restringiendo de nuevo el grado de libertad de BGP.
La solucci´on propuesta por [1] mantiene el grado de libertad de BPG, a cambio de un cambio en la cabecera de los mensajes intercambiados. Trabajaremos sobre una abstracci´on de BGP para probar esta soluci´on. Para ello, implementamos el Greedy
iv
Protocol (GP), una abstracci´on de BGP en su estado actual, y el Monotonic Paths Protocol (MPP), el protocolo modificado.
El MPP se basa en una propiedad que enuncia que si la elecci´on de caminos de todos los nodos de una red es consistente con un sistema de costes de enlace, la configuraci´on de la red converge a un estado estable. El MPP no puede garantizar que la elecci´on de caminos de los nodos sea consistente, pero s´ı que las decisiones tomadas por cada nodo sean consistentes. Para ello, antes de tomar una decisi´on, cada nodo llevar´a a cabo un c´alculo distribuido de la consistencia de la nueva elecci´on, obteniendo as´ı la estabilidad de la configuraci´on de red.
Simulaci ´ on
La simulaci´on de la abstracci´on de BGP se llev´o a cabo sobre RouteSim, un simulador de c´odigo abierto desarrollado enteramente en JAVA, usando dos paquetes: Mirage y Cortex. RouteSim es un simulador de eventos sobre tiempo discreto, y modela las redes sobre cuatro objetos b´asicos: nodos (que har´an las veces de ASs), enlaces, mensajes y eventos. Los protocolos involucrados en el proyecto fueron desarrollados c´omo paquetes JAVA independientes.
La abstracci´on sobre la que trabajaremos tendr´a ciertas limitaciones: los ASs ser´an representados por un s´olo nodo, sin importar el n´umero de interlocutores que ´estos pudieran tener; tambi´en tendremos en cuenta que cada escenario de simulaci´on estar´a compuesto por un nodo destino y varios nodos que intentar´an construir rutas hacia ´el.
Esta ´ultima propiedad simplifica los escenarios, y concuerda con el comportamiento que BGP tiene: BGP establece un an´alisis independiente para cada destino al que el nodo debe encontrar una ruta.
Casos Simulados y An ´alisis
Dividimos el estudio del MPP en tres ´areas:
1. Escenarios B´asicos: en los cuales probaremos el MPP sobre topolog´ıas exponiendo los casos m´as sencillos a los que se puede enfrentar el protocolo: c´alculo distribuido sobre un nodo sin subredes, sobre subredes independientes, sobre subredes inter- conectadas. De ´estos escenarios obtuvimos los resultados m´as interesantes: nuevos requisitos de ejecuci´on, condiciones de bloqueo no detectadas en la descripci´on te´orica, y condiciones de error graves; para paliar los inconvenientes modificamos el protocolo introduciendo nuevos conceptos seg´un fueron siendo necesarios.
2. Comparaci´on del GP y el MPP: exponemos ambos protocolos a varios escenarios presentados en [4]. De estos escenarios concluimos que aunque el MPP obtiene configuraciones estables, no siempre son ´optimas, y ´estas dependen de condiciones
v
3. Pruebas de rendimiento: enfrentamos al MPP contra dos escenarios en los cuales la topolog´ıa de red crec´ıa tanto en vertical (aumentando el nivel de profundidad del c´alculo distribuido en forma de ´arbol binario) c´omo en horizontal (creando una rueda de nodos). Observamos, por un lado, un incremento lineal con el nivel de profundidad del c´alculo distribuido, lo cual es un dato positivo de cara a una futura implementaci´on.
Conclusiones y Discusi ´ on
Se ha implementado una regla recomendada para el Border Gateway Protocol. Creemos que es un necesario primer paso hacia su implementaci´on en Internet. Tras su prueba en varios escenarios, observamos que aunque el Monotonic Paths Protocol converge hacia una configuraci´on estable para cualquier tipo de topolog´ıa, lo hace de forma aleatoria, no siempre llegando a la forma ´optima, y s´olo tras ciertas correcciones. Se proveen una serie de modificaciones al MPP que corrigen ciertos fallos no detectados en su enunciado te´orico. Adem´as, el MPP muestra, frente a pruebas contra escenarios de prueba de rendimiento un comportamiento excepcional.
Creemos que el MPP supone una modificaci´on efectiva para BPG en la b´usqueda de soluciones al Problema de Estabilidad en Rutas, destacando las siguientes propiedades:
simplicidad, fiabilidad, persistencia de la libertad sobre implementaci´on de pol´ıticas (y la privacidad de las mismas), as´ı c´omo el buen rendimiento ofrecido.
Futuras ´areas de investigaci ´ on
Este proyecto es una buena base para seguir investigando sobre la conveniencia o no de la implementaci´on del MPP sobre BGP. Ser´ıa interesante, por un lado, seguir estudiando el protocolo desde un punto de vista abstracto, buscando la manera de obtener estabilidad sin limitar configuraciones ´optimas; aqu´ı cabe destacar la observaci´on de Per Lindgren, realizada durante la presentaci´on del proyecto, sobre la introducci´on de oscilaciones vol- untarias para asegurar una asignaci´on justa de las rutas.
Por otro lado, ser´ıa interesante implementar el MPP sobre una red real para obtener datos m´as fidedignos de su rendimiento; para ello, un buen comienzo es la lectura del Proyecto de fin de Carrera de Gonzalo P. Rodrigo ´Alvarez [5], en el cual se implementa la t´ecnica Ghost-Flushing sobre el software de encaminamiento Zebra.
vi
A BSTRACT
The Border Gateway Protocol, commonly known as BGP, in its latest version, is consid- ered the “glue that holds Internet together”. BGP is the protocol that the Autonomous Systems, the largest entities in which Internet is divided, use to exchange routing infor- mation on the Internet. The importance of a well behavior of the protocol is as important as the Internet itself.
However, the behavior of the protocol sometimes differ from what is expected. Among others, BGP lacks some stability in the choice of paths that each of the Autonomous Systems do. This is referred to as the “Stable Paths Problem”, and although the problem has been thoroughly studied, and solutions have been proposed, most of them do so through limitations on the high liberty degree of the protocol.
This thesis analyzes and tests one of the proposed solutions, a modification on BGP at its most abstract levels, called the “Monotonic Paths Protocol”; a solution that does not limit the liberty degree of BGP.
vii
P REFACE
This Master Thesis was developed during a Erasmus Exchange Program between the Technic University of Madrid (UPM, Spain) and the Lule˚a University of Technology (LTU), during 2005.
I want to start thanking my parents, for their support during this year and a half, and of course, for the opportunity to be here in Sweden for all this time. I want to thank my brother Javier, too, for he was always there when I needed support, or just a good laugh.
On a more professional note, I would like to thank my supervisor Lenk Carr Motyckov´a and Johan Nykvist, for their incredible patience on my working habits, for the help provided on my work, and of course, for allowing me to work on Internet Protocols for this Master Thesis.
I won’t forget to thank all of my fellow exchange students, for this year wouldn’t have been the same without them. I would specially like to thank Josemi, Karoline, Marta, Davey, and Luis. You really made possible that I will always consider Lule˚a and Sweden a second home.
Thank you all.
Manuel G´omez Dekker, November 2005
ix
C ONTENTS
Chapter 1: Introduction 1
1.1 Motivation, purpose and goal . . . 2
1.2 Chapter overview . . . 2
Chapter 2: Routing on the Internet 5 2.1 Introduction . . . 5
2.2 Link State Routing . . . 6
2.3 Distance Vector Routing . . . 7
2.4 Path Vector Routing . . . 8
2.5 Autonomous Systems . . . 9
2.6 The Border Gateway Protocol . . . 10
2.6.1 Introduction . . . 10
2.6.2 Summary of Operation . . . 11
2.6.3 Protocol Overview . . . 12
Chapter 3: The Stable Paths Problem 15 3.1 Overview . . . 15
3.2 Notation . . . 16
3.3 Ordered Paths . . . 18
3.3.1 Introduction . . . 18
3.3.2 Paths . . . 18
3.3.3 The Greedy Protocol . . . 20
3.3.4 The Stable Paths Problem . . . 21
3.4 Monotonic Path Orderings . . . 22
3.4.1 Monotonic Paths . . . 22
3.4.2 Monotonic Path Protocol . . . 23
Chapter 4: Simulation 27 4.1 Simulation . . . 27
4.1.1 Introduction . . . 27
4.1.2 Simulators . . . 27
4.2 Routesim . . . 28
4.2.1 Overview . . . 28
4.2.2 The simulation engine . . . 28
4.2.5 Usage and output reading . . . 32
Chapter 5: Cases Simulation 35 5.1 Overview . . . 35
5.2 Basic Scenarios . . . 35
5.2.1 Childless diffusing computation . . . 36
5.2.2 Agreeing, disconnected subtrees diffusing computation . . . 38
5.2.3 Agreeing, connected subtrees diffusing computation . . . 43
5.2.4 Disagreeing subtrees diffusing computation . . . 46
5.3 Greedy vs. Monotonic Scenarios . . . 48
5.3.1 Disagree . . . 48
5.3.2 Shortest . . . 50
5.3.3 Good Gadget . . . 50
5.3.4 Naughty Gadget . . . 51
5.3.5 Bad Gadget . . . 52
5.4 Complex Scenarios and benchmarking . . . 53
5.4.1 Binary tree topology . . . 53
5.4.2 Race Wheel topology . . . 54
Chapter 6: Conclusions and Discussion 57 6.1 Quality of the results . . . 57
6.2 The Monotonic Paths Protocol . . . 57
Chapter 7: Future Work 59 7.1 Implementing the Monotonic Paths Protocol . . . 59
7.2 Analysis of the fairness of the Monotonic Paths Protocol . . . 59
Appendix A:Figures 61
Appendix B:Time Figures from Simulation Output 63
Appendix C:Routesim BGP/MPP Input Script Example 67
Appendix D:Routesim BGP/MPP Debug Level 3 Output Example 69
xii
L IST OF F IGURES
2.1 An Example topology to study. . . 6
2.2 Internal vs. External Gateway Protocols. . . 10
3.1 Arranging a real case into abstract scenarios. . . 19
3.2 Unstable path selection . . . 21
3.3 Diffusing computation example . . . 25
5.1 Childless diffusing Computation scenario. . . 36
5.2 Agreeing, disconnected subtrees diffusing computation scenario. . . 39
5.3 Message duplication. . . 42
5.4 Agreeing, connected subtrees diffusing computation. . . 43
5.5 Agreeing, connected subtrees diffusing computation with slow link. . . 44
5.6 Disagreeing subtrees diffusing computation with slow link. . . 47
5.7 The Disagree scenario. . . 48
5.8 The Shortest scenario. . . 50
5.9 The Good Gadget scenario. . . 51
5.10 The Naughty Gadget scenario. . . 52
5.11 The Bad Gadget scenario. . . 52
5.12 The binary tree topology. . . 54
5.13 The Race Wheel topology. . . 55
A.1 Agreeing, connected subtrees difussing computation timeline. . . 61
A.2 Agreeing, connected subtrees with slow link difussing computation timeline. 62 B.1 Delay in the stabilization time as function of the relative delay in the Tentative Path of node 3. . . 63
B.2 Delay in the stabilization time as function of the relative delay in the Current Path of node 3. . . 64
B.3 Delay in the stabilization time as function of the depth level for the di- fussing computation. . . 64
B.4 Delay in the stabilization time as function of the number of nodes in the Race Wheel Topology. . . 65
L IST OF T ABLES
2.1 Link State: Routing Table in each of its steps. . . 7
2.2 Distance Vector: Initial Cost Table. . . 8
2.3 Distance Vector: Cost Table after receiving table from C. . . 8
2.4 Distance Vector: Final Cost Table. . . 8
2.5 Path Vector: Received Paths Table. . . 9
2.6 Path Vector: Chosen Paths for Node A. . . 9
3.1 Unstable Path Selection . . . 22
C HAPTER 1 Introduction
Internet is, without the shadow of a doubt, the largest network ever conceived by man.
It comprises a vast number of smaller independent interconnected networks. In order to connect these networks forming a world-wide community, one of the key concepts was to provide a reliable network that could operate and remain active even if one of their nodes disconnected, or malfunctioned. In order to understand the importance of this feature, we must look back into the early days of the Internet and its predecessor, ARPANET.
With the Cold War as a menacing background, and the need of communication between computer networks as the main goal, the research led to protocols which were aimed toward decentralized, packet switching networks. The element that makes the intercon- nection between different networks is the router; a protocol is the language that routers speak, and makes the understanding between routers possible. It is unnecessary to state that two routers that wish to speak to each other must use the same protocol.
Internet is now divided into Autonomous Systems, commonly referred as A.S. An A.S. is a collection of routers and networks under the control of one or more entities that presents a common routing policy toward the Internet. Internet’s de-facto standard protocol for the exchange of routing information between routers is the Border Gateway Protocol, also referred as BGP. BGP, among other properties, allows each A.S. to define local routing policies. This degree of freedom is also the main trouble source, as the entities in charge of the Autonomous Systems (often, Internet Service Providers, or ISPs) are not willing to share these policies. This leads to instabilities in the path selections. Autonomous systems do not reach a stable configuration whenever any of the neighbor nodes goes down. This is often referred as the ”stable-paths problem”.
Various attempts to solve this problem have been carried out. The main approaches for a solution to this problem often restrict the freedom that BGP allows. Other solu- tions increase the protocol complexity and imply a need for memory storage and message overhead in communications. However, there has been proposed what it seems to be a stabilizing solution to the stable-paths problem. This solution allows Autonomous Sys-
1
tems to remain free to choose their path policies. This project implements the stabilizing solution and observes its behavior and performance.
1.1 Motivation, purpose and goal
The Border Gateway Protocol in its last version (BGP4) is the”glue that holds Internet together”. This is true both for its performance and for its wide spread use. However, it has been demonstrated that there are still a moderate number of problems that need to be solved.
Jorge A. Cobb, Mohamed G. Gouda, and Ravi Musunuri from the Department of Computer Science in the University of Texas have theorized a ”Stabilizing Solution to the Stable-Paths Problem” [1]. The relevance of the solution proposed by Cobb, Gouda and Musunuri relies on the fact that freedom over policies is kept at a very low cost in terms of message overhead and router internal computation.
In order to test this solution, a simulator had to be chosen. The main suggestion for the simulator choice was RouteSim, a java-based BGP simulator, implemented by Johan Nykvist for his Master Thesis in December 2002, developed for this same University.
The use of this simulator posed both the challenge of testing the protocol enhancements and the further development of the simulator. However, the access to the simulator’s full source code (released under the GPL license) made it a very interesting choice. The purpose of this project is to test the validity, study the behavior and performance of the solution proposed by Cobb, Gouda and Musunuri for the stable-paths problem in an abstraction of the BGP Protocol.
1.2 Chapter overview
The rest of the thesis is organized as follows:
• Chapter 2 gives an overview on the current state of routing on the Internet. It describes the main routing protocols used both inside and outside Autonomous Systems.
• Chapter 3 gives a description of the stable-paths problem. It also presents the solution to the problem proposed by Cobb, Gouda and Musunuri. There will be presented as well the Greedy and Monotonic protocols, and the notation that will be used to describe them.
• Chapter 4 gives an overview on RouteSim, the simulator implemented by Johan Nykvist, and that was used to test and simulate both the Greedy and the Monotonic Path protocols.
• Chapter 5 shows and comments the output from the simulations, as well as the parameters used and the topologies analyzed.
1.2. Chapter overview 3
• Chapter 6 lists the conclusions obtained from the development of this Master Thesis, as well as a summary of the properties that were observed for the Monotonic Paths Protocol.
• Chapter 7 discusses where the research should be headed for future work in this area, as a continuation of this Master Thesis.
C HAPTER 2 Routing on the Internet
2.1 Introduction
Internet is a vast computer network. Computers are identified by an Internet Protocol (IP) Address, which should be unique (NAT translation, although allowing more than one computer to have the same IP address, limits their addressing). In order to maintain a manageable Internet structure, computers are divided into smaller networks. These networks can range from a few computers (a small company or home network, what is called LAN) to vast, big enterprise networks (composed by hundreds of end systems).
Routing is the means of discovering paths in computer networks along which informa- tion can be sent. Routing on the Internet does not rely on end hosts, rather than that, it is carried out by specific. In the early days of ARPANET (the network that would later become Internet) dynamic routing was not a common term, rather than that, the few number of computer networks where statically and manually routed. However, the growing number of hosts connected to the Internet rendered that option obsolete.
Nowadays, dynamic protocols are involved in routing. Nodes using dynamic routing protocols make themselves aware of their network environment by exchanging information so that they can decide which the best path to any given destination is. Also, the chance of a link or node failing makes recovery a priority when dealing with routing protocols.
If a designated path is no longer available, the remaining nodes must determine a new path to allow data to reach its final destination. The algorithms that calculate these paths are referred to as routing protocols.
The methods which a router uses to acknowledge his paths to other nodes, the proto- cols, can be sorted according to different criteria. The most important aspect of a routing protocol is whether the decisions are taken only in certain points, and with all the in- formation of the network situation at hand; these are called global routing algorithms
5
or Link State routing. If the choices for routing are done independently, with only some information available (typically, the information of each node’s nearby enviroments), the routing is classified as decentralized routing algorithms [6]
2.2 Link State Routing
Also called broadcast routing, this kind of path selection requires that each node knows the situation of the entire network in order to take a decision. On every iteration of the protocol, each node broadcasts the status of its neighbor nodes and channels to all processes in the network. From these broadcasts, each node or process recreates in its memory the network topology. From this topology, the process can analyze and decide which should be the next hop for each of the destinations. The link state routing shows a higher degree of robustness toward other kinds of routing; since the computation of each node’s path choices are done individually with information from the entire network.
We will see how link-state routing works with an example, based on the topology on the following figure:
Figure 2.1: An Example topology to study.
Let’s have a look at the analysis of the network from the point of view of the A node.
The algorithm used in the following example is the Dijkstra’s algorithm. Each node checks the links to its neighbors, and assigns them a cost. The lower the value, the
2.3. Distance Vector Routing 7 more preferable the link is. The cost assigned to a link is calculated based on the link’s congestion, distance, speed, etc. In the first place, node A examines the path cost to each of its neighbors, and assigns as the cost to reach them the cost of the link that connects A with them. Then, node A will repeat the operation starting with the closest neighbor, recursively, until the cost of the closest recursive neighbor is higher than the cost of a direct neighbor to A. Once every node is checked, the routing list is completed. Until a node is acknowledged reachable, its cost is considered infinite. Next to the cost, the preceding node is registered, so we can always trace the route going backwards from the node we want to know the destiny to.
The following table shows, step-by-step, how the route tables are computed:
Step N odesAcknowledged B C D
0 A 3,A 1,A 6,A
1 AC 2,C 5,C
2 ACB 4,B
3 ACBD
Table 2.1: Link State: Routing Table in each of its steps.
2.3 Distance Vector Routing
In distance-vector routing each node or process calculates the path to a given destination with the information that is received from neighboring process only. Also, the results of the next-hop calculation are then forwarded only to its neighboring processes. Therefore, less information is spread through the network and the links are not saturated with control messages. Another advantage is that a node does not need to know the situation in the entire network, therefore demonstrating a better startup performance. The principal data structure in distance-vector algorithms is the distance table maintained at each node. Distance vector routing has a less complex message system; messages are only sent when a change in the network occurs, and the messages are only forwarded to neighboring nodes. Using the topology shown in figure 2.1, we see how the table is constructed from the point of view of the A node. First of all, node A will compute the costs to its neighbors and keep them in its routing table. On the first step, node A’s routing table should look like this:
When we receive the routing table from a neighboring node, we introduce the new acknowledge costs adding the costs that the neighbor node sends to the cost to reach it.
If the routing table was to be received by C, the updated table would look like:
Therefore, node A calculates the cost to reach the rest of the nodes through C, and
Destination Cost through B Cost through C Cost through D
B 3 infinite infinite
C infinite 1 infinite
D infinite infinite 6
Table 2.2: Distance Vector: Initial Cost Table.
Destination Cost through B Cost through C Cost through D
B 3 2 infinite
C infinite 1 infinite
D infinite 5 6
Table 2.3: Distance Vector: Cost Table after receiving table from C.
choses according to the new costs. We can see that the cost through C to D is five, that is because node C has not yet discovered that there is a path to D through B that has a cost of 3. The final routing table for A would be:
Destination Cost through B Cost through C Cost through D
B 3 2 8
C 4 1 10
D 5 4 6
Table 2.4: Distance Vector: Final Cost Table.
2.4 Path Vector Routing
Path Vector routing is similar to distance vector routing in the sense that it is decen- tralized, asynchronous routing. However, instead of sending messages with the costs to neighbor nodes, what is send through the network is the path that each node has selected to reach a certain node, with or without the cost assigned to that path. The routing table to each destination is formed from the available paths and the metric used on each node to decide which path should be taken [7]. Keeping the same example topology as in the two previous sections (figure 2.1), we construct the routing table for node A.
From this table, A will choose its paths to each destination. If a cost is not send along
2.5. Autonomous Systems 9 Destination P ath chosen by B P ath chosen by C P ath chosen by D
B B C B D B
C B C C D B C
D B D C B D D
Table 2.5: Path Vector: Received Paths Table.
with the paths from each of the neighbor nodes, then a local metric or policy must be enforced in order to choose from the available paths to each of the nodes.
Destination P ath chosen by A
B A C B
C A C
D A C B D
Table 2.6: Path Vector: Chosen Paths for Node A.
The paths chosen by A must be consistent with the next node’s path choice. For example, in the topology given, it would not be possible for A to choose a path to D through C without going through B, since C’s choice to reach D is through B.
2.5 Autonomous Systems
An Autonomous System is a set of routers under a single technical administration. Au- tonomous Systems use at least one interior gateway protocol and common metrics to route packets within the AS, and another protocol to communicate with other ASs. While an AS can use several metrics and interior protocols to communicate between nodes inside the AS, it should appear to the exterior that only a clear set of rules is used, therefore presenting a consistent picture of what destinations are reachable through it [8].
The concept of”autonomous system” came from a time in which the number of networks on the Internet made difficult to apply routing protocols. Routers were overwhelmed with the information they had to deal with. Therefore, a decision to divide the Internet into Autonomous Systems was made. Routing was divided into internal and external routing. As previously stated, internal routing is done inside an autonomous system, and the choice on the internal gateway protocol (IGP) is done by the Autonomous System administration. Among others, the most used protocols are the Routing Information Protocol (RIP) and the Open Shortest Path First (OSPF) protocol. External routing is
Figure 2.2: Internal vs. External Gateway Protocols.
done by routers on the autonomous system’s frontiers to other ASs using external gateway protocols (EGP). In this case, the de-facto standard for external routing is BGP.
2.6 The Border Gateway Protocol
2.6.1 Introduction
The Border Gateway Protocol is an inter Autonomous System routing protocol. BGP-4, the latest version of BGP, is a very robust and scalable routing protocol, being the”de- facto” standard on the Internet for routing between Internet service providers (ISP) [9]. When BGP is used between different Autonomous Systems on the Internet, it is referred as EBGP or External BGP. If a service provider is using BGP to exchange routes within the interior of an AS, then it is referred as Internal BGP or IBGP. BGP in its latest version supports class interdomain routing (CIDR), eliminating the concept of network class, and significantly reducing the amount of information passed between neighboring Autonomous Systems. BGP also only advertises the routes that it itself uses, reflecting the”hop-by-hop” routing paradigm used throughout the current Internet. This means that any given AS cannot advertise to its neighbors intending that that traffic from a neighbor AS takes a different route. It can, however, support any policy that conforms to the”hop-by-hop” routing paradigm. BGP runs over TCP, meaning that it run over reliable transport on the Internet. This avoids the necessity to implement fragmentation, retransmission, acknowledgment or sequencing of the messages. In BGP,
2.6. The Border Gateway Protocol 11 routers exchange routing information over semi-permanent TCP connections using port 179. There is typically one BGP-TCP connection for each pair that connects two routers in two different AS’s. There are also semi-permanent TCP connections between gateway routers within an AS. For each TCP connection, the two routers connected are called BGP-peers, and the TCP connection over those routers is called BGP Session. The session can be either external (eBGP: between routers from two different ASs) or internal (iBGP: between routers of a same AS). BGP routers have to worry about politics a great deal. For example, a corporate AS might want the ability to send packets to any Internet site and receive packets from any Internet site. However, it might be unwilling to carry transit packets originating in a foreign AS and ending in a different foreign AS. Policies are manually configured into each BGP router. They are not part of the protocol itself.
BGP is extremely complex; entire books have been devoted to the subject. Even after reading about BGP, it is difficult to really understand what’s going on if not for months (if not years) of experience with it (as a top-notch ISP administrator) [10]. Nevertheless, it is critical for the well-functioning of the Internet. BGP allows each AS to learn which destinations are reachable via its neighboring AS’s. In BGP, destinations are not hosts;
but CDIRized prefixes. When one AS advertises a prefix to another AS, the advertising AS is promising that it will forward any datagram destined for the prefix a long a path toward the prefix.
In BGP, each AS is identified by its globally unique autonomous system number (ASN).
AS numbers, like IP addresses, are assigned by the ICANN regional registries. When a router advertises a prefix across a BGP session, it includes with the prefix a number of BGP attributes. In BGP jargon, a prefix with its attributes is called a route. Thus, BGP peers advertise routes to each other.
When a gateway router receives a router advertisement, it uses import policy to decide whether to accept or filter the route and whether to set certain attributes such as the router preference metrics. The import policy may filter a route because the AS may not want to end traffic over on of the AS’s in the route’s AS-PATH. The gateway router may also filter a route because it already knows a preferable route to the same prefix.
2.6.2 Summary of Operation
BGP is a protocol that acts in pairs, that is, information is exchanged between two BGP peers. They exchange messages to open and confirm the connection parameters. The first network data that is being sent is the whole BGP routing table. Further data will only be sent once there are changes in the routing table; this will be done through the exchange of update messages. This means that any BGP peer must retain the current version of the entire BGP routing tables of all its peers during the session. In order to maintain a connection active, keepalive messages are sent periodically; allowing both peers to know that the connection is still valid and alive. Last, notification messages are sent when errors occur or special conditions are met. For error conditions, the default
behavior is to close the connection. If a particular AS has multiple BGP speakers (that is, many frontier routers), it must ensure a consistent view of the interior routing of the AS toward the outside [9] [11]. This should be granted by the interior routing protocol;
although it can also be achieved by setting BGP connections between all frontier routers.
Using a common set of policies, the BGP speakers arrive at an agreement as to which border routers will serve as exit/entry points for particular destinations outside the AS.
The information unit that describes how information is reached from a certain BGP speaker, including the path to the destination, is called a route. Routes are advertised to BGP speakers by UPDATE messages. Routes are stored in the Routing Information Bases (RIBs). There are three different RIBs in a BGP speaker:
• Adj-RIB-In: this is the routing information base that stores routes that have been learned from neighbor speaker’s UPDATE messages. The routes that are stored in this RIB represent the routes available to the BGP speaker.
• Loc-RIB: this information base stores the routes that are obtained by selection of learned routes (Adj-RIB-In) applying its local policies; that is, the routes stored in this RIB are the ones that both comply with the speaker’s availability and preferrability.
• Adj-RIB-Out: The Adj-RIB-Out stores the routes that the local speaker has selected for advertisement to its peers through UPDATE messages.
Although defined in [9] as three different information bases, there is no specification on how they must be implemented, moreover, the implementation does not require that they are implemented as three different information entities.
2.6.3 Protocol Overview
The BGP protocol sends four different kinds of messages: OPEN, UPDATE, KEEPALIVE and NOTIFY. Message is only processed when it has been entirely received. The the minimum and maximum message sizes are 19 and 4096 bytes, and it is required that all implementations of the protocol allow such message size. The four message types are structured as follows:
• The OPEN message is used to open a BGP session between two neighboring peers.
Once an OPEN message has been sent, and a KEEPALIVE message is received as confirmation, the connection is considered established, and messages from other types can be received. The following information is sent in an OPEN message:
– The version of BGP in use.
– Autonomous system identifying the local system.
– Hold time, to be used with the KEEPALIVE messages.
2.6. The Border Gateway Protocol 13 –
• The UPDATE message is used to transfer routing information between BGP peers.
The information that is transferred from an UPDATE message can be later used to build a graph of the network, filter loop and anomalies for inter-AS routing, etc. Each UPDATE message sends ONE feasible route to a BPG peer, or withdraws several unfeasible ones from service. The data included in an UPDATE message is:
– Unfeasible routes length (in octets). If the length equals 0, then there is no routes to withdraw from service
– Withdrawn routes, identified with the IP address for the route that is being withdrawn.
– Path length: if there is a path to be added.
– Path attributes: many fields specifying more aspects of the paths to be with- drawn or added.
• The KEEPALIVE messages are sent from BGP peers that wish not to update a connection, in order to keep that connection alive. KEEPALIVE messages should not be sent more frequently than one per second. The frequency is determined by the Hold Time Interval.
• Last, but not least, is the NOTIFICATION message. As we know, it is used when there is some kind of error in the message exchange between two BGP peers. The NOTIFICATION message contains the following fields:
– Error Code and Subcode: identify the kind of error occurred; it points out the kind of message received (if possible to identify) or the internal failure that caused the error (expiration of Hold Time, for example).
– Data: if applicable, the message causing the event may be sent back.
C HAPTER 3 The Stable Paths Problem
3.1 Overview
BGP, as stated in previous chapters, is the de-facto standard for exchanging routing in- formation between Internet Service Providers. This protocol, however, shows an unstable behavior. The reasons for this behavior are:
• Local-chosen routing policies: BGP allows each of the participating processes to define their own set of rules on who to avoid sending messages, the preferred paths to use, etc.
• Secret (none shared between ISP’s) routing policies: The above mentioned policies do not need to be shared; therefore there is chance for a third party evaluation, review and/or modification enforcement.
• Introduction of simple techniques that don’t solve the problem, rather than that, makes it worse. For example, route-flap-damping not only does not solve the prob- lem, but simply increases the oscillation period [3]. It may also increase the con- vergence times of stable routes.
The stable paths problem can be described as an undirected graph (that is, a given structure composed of nodes and links between them), with a distinguished node called the origin [4]. All the other nodes have a set of permitted paths to the origin. This set of permitted paths is what we call a policy, and it can be seen as the degree of liberty that BGP allows Autonomous Systems to implement freely. Each node has also a ranking function of their own that specifies the preference of a given path against the others. Nodes will always try to use the highest-ordered path among the available from neighbor nodes. A solution to the stable paths problem, according to their authors, is an
15
assignment of permitted paths to nodes so that each node’s assigned path is its highest ranked path extending any of the assigned paths at its neighbors. There are three main approaches to reaching a solution for this stable-paths problem:
1. The first one analyzes the local routing policies of all processes and decides whether the routing policy is safe.This approach removes the degree of liberty that BGP has; AS’s administrators would have to share their routing policies, which would be something that some organisms (mainly, ISP’s and big companies) would not be willing to do. And even if that would be feasible, it was been proved that deciding the safety of a routing policy is an NP-complete problem [4].
2. The second one maintains path histories during runtime to determine if the network is oscillating (and not converging) [12] [13]. This would mean that the the memory and processing capabilities for routing entities on the Internet would increase in a very significant way, forcing AS’s to upgrade their routers to meet the new hardware requirements, something that may have a large impact on AS routing and must be had into consideration. Further can be read at [8].
3. The third one restricts the routing policy to a hierarchical structure, eliminating the choice of routing policies. This is similar to the first stated solution, and has the same main drawback: the AS’s may not want to switch to a protocol that restricts their liberties on path choices.
The solution proposed in [1] allows the routers to choose their routing policies, just as it had been done until now, in exchange of a small header overhead. The solution is not implemented on the BGP protocol itself, rather than that, it will be done over an abstraction of BGP.
3.2 Notation
In order to describe the procedures of the protocols that will be implemented, some new notation will be used in following sections:
• A channel (also referred as link) between two processes (also referred as nodes indistinctly through this paper) p and q is denoted as ch(p, q).
• There is only one message type: path, which is the equivalent to the AS PATH message. There will be no message of another kind, since we won’t be simulating message loss or error.
• The number of path messages in any given channel ch(p, q) is #ch(p, q).
• If there is a channel from p to q, there is a channel from q to p.That is, every channel or link is considered to have a full duplex capability, and therefore, it is
3.2. Notation 17 possible to send and receive at the same time. However, for this version of the protocols introduced it is not strictly necessary, since both protocols act in a ¨send, then receive¨fashion; and for a correct behavior of the protocol there should never be two messages in the same channel at the same time.
Each process consists of inputs, variables, parameter and a set of actions. Inputs can be read, variables can be read/written by the owning process’ actions.
• Actions: An action is the relationship that is established between a guard and a command, and it’s the basic execution unit that defines the behavior of a certain process.
• Guards: A guard is a set of conditions that if met, will trigger one or many commands. Guards can be of three types: local, receiving and timeout.
– A local guard is a Boolean expression over the inputs, variables and parameters of the node.
– A receiving guard at process p is of the form:
rcv path from q
An action with this guard is enabled if (and only if) there is a message of type path in channel ch(p, q). If this action is chosen for execution, then this message is removed from channel ch(q, p).
– A timeout guard at process p is of the form:
timeout #ch(p, q) = 0 ∧ #ch(q, p) = 0
where q is a neighbor of p. This guard is activated iff there is no messages in either channel. A timeout guard is intented to be implemented with timer events.
• Commands: Commands are a sequence of conditional statements that are exe- cuted if meeting certain expression: ¡variable¿ := ¡expression¿ if ¡boolean¿ If there is no ¡boolean¿ expression, the assignation is done unconditionally.
• Parameters: A parameter declared in a process is used to write a set of actions as a single action, with one action for each possible value of the parameter. For example, after the following declaration of the parameter g:
par g : element of {r, s}
Whenever a message is received from an element that belongs to g, the same action will be executed.
rcv path from g → send path to g
=
rcv path from r → send path to r rcv path from s → send path to s
3.3 Ordered Paths
3.3.1 Introduction
We define the routing policy of a process to be an ordering on all paths originating at the process. We also present a greedy protocol, where each process attempts to improve the order of its paths without regard for other processes. This greedy behavior, in combination with certain network topologies, originates the stable paths problem.
3.3.2 Paths
A path is a sequence of processes, being two consecutive processes neighbor ones neces- sarily. Paths have the following properties:
• | P | denotes the number of processes in the path.
• λ denotes the empty (or null) path, that is, the absence of a path choice for any given process. Process should only be assigned the null path in the absence of allowed alternatives to reach the destiny node.
• Pi denotes the ith process in path P . P1 and P|P | are the first and last processes in P .
• p : P denotes the concatenation of process p with path P .
• Process root is a distinguished process. A path is rooted iff it is simple and its last process is root.
• A path is a network path iff, for every pair of consecutive processes p and q along the path; p and q are neighbors.
Any processes will be assigned one or more paths to be its allowed paths. Among the available ones, each node will choose the one with highest order. We will estab- lish a relationship between paths called ordering, that will comply with the following statements:
• For every pair of rooted paths P and Q:
(P1 = Q1) ⇒ (P Q ∨ Q P )
3.3. Ordered Paths 19
(P ≺ Q) ≡ (P Q ∧ Q P )
• For every path P , P root
• For every rooted path P , λ ≺ P
In every topology we will have two kinds of nodes or processes. There will be normal and root processes. In every scenario, the objective of every node is to find a path to the root node. The idea of the root node is to divide the problem of finding a path to each destination into independent, parallel layers of abstraction. For each layer of abstraction, the root node will represent the node to which all remaining network nodes want to be reachable by a path. This stems from the fact that BGP makes routing decisions on a per-destination basis only. That is, the routing decisions made for one destination are not affected by the routing decisions made for another destination [2]. That is, root node represents a certain network that wants to be reached from the rest of the BGP speakers.
Figure 3.1: Arranging a real case into abstract scenarios.
Each scenario will be independent from the rest; for each of them, each node will enforce a different routing policy. In Figure 3.1, we can see how a certain topology is divided into different scenarios. In Routing Scenario 1, node A is assigned the root role;
the rest of the nodes will communicate among themselves to find a suitable route to root.
Whether conflict will arise or not depends strictly on the policies enforced by each ASn’s network administrators.
3.3.3 The Greedy Protocol
The greedy protocol is a set of rules in which each process chooses the highest ordered path from those offered by its neighbors. To do so, each pair of neighboring processes exchange a single path message between them. This message contains the current rooted path chosen by the process.
The specification consists of two processes: root and non-root process p. There will be two different specific behaviors: one for the normal processes or nodes, and another for the root node. The specification goes as follows; notation and semantics are from [1]
process p
inp N : set of neighbors
var P : path, // path of p //
G : path // path from neighbor g //
par g : element of N // any neighbor //
begin
rcv path(G) from g →
P := p : G if (P ≺ p : G) ∨ (g = P2);
P := λ if ¬sound(P );
send path(P ) to g;
timeout #ch(p; g) = 0 ∧ #ch(g; p) = 0 → send path(P ) to g
end
process root
inp N : set of neighbors
var P : path, // path of p //
G : path // path from neighbor g //
par g : element of N // any neighbor //
begin
rcv path(G) from g →
P := root; send path(P ) to g
timeout #ch(p; g) = 0 ∧ #ch(g; p) = 0 → send path(P ) to g
end
To put it in another way:
• For the process p, to take a new path received from a neighbor, the path must have
3.3. Ordered Paths 21 a higher order, and the neighbor sending the path has to be part of that path. An empty path is chosen if the current path is not sound ; or there is no path available that fits the process’ policy. Since there is no coordination on the choice of paths, the path that a certain node selects may trigger further changes in the rest of the network, causing instability.
• For the process root, it all comes down to fixing its path to itself, and sending that path to its neighbors. Only enough interaction is provided in order to aware its neighbors of the awake condition of the node.
In order to understand the protocol, we must define the term sound. We say that a path is sound if three conditions are met: first, the selected path must originate in itself;
second, the second node must be a neighbor node, and third, it must end at the root node. Those are the three key elements for a path to be valid and usable. A path P is sound if:
sound(P ) ≡ (P1 = p ∧ P2 ∈ N ∧ rooted(P )).
Both nodes have timeouts that are triggered if a message is lost or delayed.
3.3.4 The Stable Paths Problem
Stable-paths problem are often caused by conflicts in the policies of neighbors applied to the greedy protocol. Other times, the problem is caused by what it would seem a safe configuration that turns problematic after a link or node is connected/disconnected from the network. The stable paths problems may cause a network to never achieve a stable configuration. Some work has been done in order to identify the topologies that lead to the stable paths problem [12] [13]. In general, we can state that the network will not achieve an unstable solution if no dispute wheel can be constructed or obtained from the current topology [4]. A dispute wheel is a topology which has a path ordering which is not consistent with a cost function; that is, processes prefer paths that have a higher cost function. Furthermore, we know that any topology different from a dispute wheel has a unique solution.
a) b) c)
Figure 3.2: Unstable path selection
process lowest order medium order highest order
p p : root p : r : root
q q : root q : p : root
r r : s : root r : root r : s : q : root s s : root s : r : root s : q : root
Table 3.1: Unstable Path Selection
Figure 3.2 presents a dispute wheel topology. Each node is represented by a number;
the root node is always represented by the number 0. Next to each of the nodes is the list of their preferred paths; and the arrows point towards their selected path at a current state.
As we can see, the path selection for the nodes creates a dispute wheel. Starting at Figure 3.2 (a), node2 notices that path through 1 is not only preferred, but available also. N ode2 changes its path, and so must nodes 3 and 4 since the path through 2 is no longer available. N ode3 has to take a less preferred path: 30, and so node4 chooses path through 3. The topology becomes the one shown on figure 3.2 (b). After that, node1 notices path through 3, forcing node 2 to take the path directly to root ; node 4 notices the new path through 2, so it changes it’s path again, leaving the topology as shown on figure 3.2(c). From that last one, node 3 will notice a path trough 2 and 4, forcing node 1 to choose the direct path to root ; this will leave us in the same position as in the first figure. As we can see, there is no stop to this cycle being repeated over and over with the current protocol.
3.4 Monotonic Path Orderings
3.4.1 Monotonic Paths
As we know, if a path ordering is consistent with a cost function, then a stable con- figuration is always achieved [1]. The solution to the Stable Paths Problem resides in establishing a Monotonic Path Ordering:
A path ordering is said to be monotonic if and only if, for every pair of processes p and q, and for every pair of rooted paths Q and Q0 originating at q, such that p ∈ Q and p
∈ Q0 ./
Q Q0 ⇒ p : Q p : Q0
It is said that if a network has a monotonic path ordering, then a stable state is guaranteed to be reached. However, since BGP is a protocol that implements liberty of policies on each node, it is not possible to ensure that all the processes in the network are going to
3.4. Monotonic Path Orderings 23 comply with a Monotonic Path Ordering. We will modify the protocol so that even if the network path ordering is not Monotonic, it will reach a stable state. The modified protocol will be called Monotonic Path Protocol
3.4.2 Monotonic Path Protocol
If a path ordering is monotonic, then the order of the paths chosen by each process is nondecreasing, and stability is assured. This is done modifying and strengthening the protocol. The modus operandi of the protocol will be as follows: before choosing a new path, any process will ask other processes at its subtrees whether the change of path will cause their order to decrease. If that would be the case, the node would refrain from accepting the new path.
The coordination between p and q is performed via a diffusing computation along the routing tree. Diffusing computation means that the decision of adopting a new path is done between several nodes, recursively, having to be all in agreement. Whenever a node wants to change to a higher order path, it must ask its neighbors for its consent. However, we will not ask all neighbors, we will only have into account for the final computation the ones that belong to the routing tree.
For any node p and it’s next hop along the path, q , we will say that p and q are neighbors. Also, we will say that q is parent to p, and p is a descendant of q. Whenever a diffusing computation is started by a certain node, it will have to wait for agreement from all descendants, that is, from all the nodes whose paths to the root node have itself as next hop. At the same time, those descendants will have to ask their own descendants, and so on. If a node is asked about a path from a node that is neither parent or descendant, it should always agree; a node should not interfere into a diffusing computation that does not interfere with its behavior.
In order to keep track of the diffusing computation, any process p maintains two vari- ables: P and P ∗, that store the current and tentative path of process P . The current path is the path that is using the node; the tentative path is the one to whom it wants to change. It also maintains a set of flags called clean, which identifies which neighbors have allowed p to change the path and which haven’t.
The technical, precise behavior of the protocol is as follows:
process p
inp N : set of neighbors
var P, P∗ : path, // path and tentative path of root p //
G, G∗ : path // path and tentative path of neighbor g //
b : boolean // boolean reply bit from neighbor g //
wait : subset of N // ignore next message //
clean : subset of N // neighbors in agreement with root //
par g : element of G//
begin
rcv path(G, G∗, b) from g →
P := p : G if g = P2 ∨ (clean = N ∧ P∗ = p : G ∧ G = G∗);
P∗ := P if (g = P2∗ ∧ P∗ 6= p : G∗) ∨
(p = G2 ∧ G∗ 6= g : P∗ ∧ G = G∗ ∧ g /∈ wait);
P∗ := G∗ if P = P∗ ∧ P p : G∗ ∧ (g 6= P2 ⇒ P ≺ p : G∗);
P, P∗ := λ, λ if ¬sound(P ) ∧ ¬sound(P∗);
wait := wait - {g};
clean := cleanS{g} if p 6= G2 ∨ (G = g : P ∧ G∗ = g : P∗ ∨ b);
send path(P, P∗, clean = N ) to g;
timeout #ch(p; g) = 0 ∧ #ch(g; p) = 0 → send path(P, P∗, clean = N ) to g end
process root
inp N : set of neighbors
var P, P∗ : path, // path and tentative path of root p //
G, G∗ : path // path and tentative path of neighbor g //
b : boolean // boolean reply bit from neighbor g //
wait : subset of N // ignore next message //
clean : subset of N // neighbors in agreement with root //
par g : element of G//
begin
rcv path(G, G∗, b) from g →
P, P∗, wait, clean := root, root, 0, N ; send path(P, P∗, true) to g if p < g timeout #ch(p; g) = 0 ∧ #ch(g; p) = 0 →
send path(P, P∗, true) to g if p < g end
As we can see, the root node doesn’t change his behavior, it just adapts to the new message format that we’ll be handling. The big changes come in the behavior of the generic node p.
3.4. Monotonic Path Orderings 25 The following example should explain briefly what the behavior of the protocol:
a) b) c)
Figure 3.3: Diffusing computation example
In the first figure, we see the paths selected by node 1. Path P is the current path, and P* is his tentative path, the preferred one. He sends a message to his descendants, 2 and 3. His descendants then propagate to their descendants and neighbors the corre- sponding tentative paths recursively. In the second figure, we see that every node in the graph accepts the tentative path that they received from their respective parents, and acknowledges it to neighbors. In the third figure, all nodes have adopted the new path.
C HAPTER 4 Simulation
4.1 Simulation
4.1.1 Introduction
A simulation is an imitation of some real device or state of affairs. A simulation attempts to represent certain features of behavior of a physical or abstract system. In engineering and technology, the goal of simulation is to predict the behavior of some real world scenario. These scenarios are often complex systems. Simulations can save time, money, and effort, and provide results safely (if the nature of the real world scenario could pose a potential security threat).
Traditionally, the formal modeling of systems has been through a mathematical model.
A mathematical model attempts to provide and analytical solution which allows to know the behavior of the model before conducting experiments. The main reason for not using analytical methods is that certain systems are very hard to model mathematically and even harder to provide a solution. In those cases, a simulation on an abstract model of the complex system is suggested. The main difference between an analytical model and a simulation is that, while analytical solutions can provide the state of a system for any given time, a simulation must be run from a predefined initial state and calculated through every middle step to the desired final state.
4.1.2 Simulators
in order to perform simulations, a device called simulator is used. A simulator is often a piece of software designed to represent a certain system that will be the target of the simulation. The system will be referred to as target system, and the way it is described, the system model. The model is composed of system entities, that is, the objects in the
27
system.
The desired values that we want to obtain from the simulation describe how the system model will be built. The number of values dictate the complexity of the simulator. It is important to know what values we want in order not to make the simulation too complicated, otherwise it will increase the computing needs of the hardware running the simulation software, needing more time to compute the whole simulation. The output should express what those desired values should be at any time during the simulation.
4.2 Routesim
4.2.1 Overview
Routesim [2] is a discrete-time system simulator, implemented in Java [14], under the General Public License [15]. The simulator is divided into two parts: the simulation engine, and the system model. The simulation engine is what runs the simulator, the actual program. The system model is the part of the program which will try to describe how the protocols described in chapter 3. The focus of this thesis was to develop a system model to match the protocols specified in [1]. In further episodes, we will discuss the behavior of the protocol.
Routesim works as any other discrete-time simulator: an input file is injected, and an output is received, either in clear text on the console or in a file. Further analysis of the output must be done manually from the output files. One of the main reasons of not using a commercial simulator was to avoid interaction with underlying protocols and stay on a control plane in first stage of our work.
4.2.2 The simulation engine
The simulation engine is programmed in Java [14], and relies on two specific frameworks:
Mirage [16] and Cortex. While the Mirage framework is used in the simulator engine, the Cortex package is used to parse the input files and instantiate Java objects from script.
This allows us to specify different topologies without having to recompile the simulator.
Also, it allows to call Java functions directly from the script, using script-created objects as arguments or targets. This allows a very intuitive interaction between the simulator and a programmer, since the syntaxes is very similar to the one in Java.
The scheduler executes the time advance algorithm and stores all pending events in the queue. The scheduler also integrates the simulation clock. The author made the simulator in a layered manner, therefore the core can be reused without modification and recompilation, just by interfacing the simulation engine to the system model.
4.2. Routesim 29
4.2.3 The System Model
The system model was developed under Windows XP as an independent Java package that is later called from the system file. The development was carried out using Netbeans [17] and jGrasp [18]. The system model consists of nodes, links, messages and events, each of them implemented as a different Java class.
4.2.3.1 Nodes
Nodes (also called processes) are the most important entities in the simulation. They represent the Autonomous Systems on the topologies that we intent to simulate, with some limitations. Only one BGP speaker will be allowed per ASn, to maintain some simplicity. Nodes will follow the “process p” part of both the Greedy and Monotonic Paths Protocols. Nodes will only exchange one kind of messages: path messages.
4.2.3.2 Root Node
The root node will represent the destination node that all the rest of the nodes want to reach. Since it’s the destiny node, it has a different behavior from the rest of the nodes, as explained in chapter 3. It will follow the “process root” part of both protocols.
4.2.3.3 Links
Links are the entities that connect nodes. They are the information channels through which the nodes send the path messages. The links will not be able to loose any kind of information on them; links will be defined by a few parameters:
• Minimum Latency: The minimum amount of time that a message will be delayed before it is delivered at the other side of the link.
• Maximum Latency: The maximum amount of time that a message is expected to be delayed before it is delivered at the other side of the link
• Nodes to which it is connected: a link will only connect two nodes.
Links will be implemented as two FIFO (First In, First Out ) queues in which messages will be stored until their arrival time. Since RouteSim is a discrete-event simulator, the message will trigger events in the simulation core engine that will call the node’s message-processing functions.
4.2.3.4 Messages
Messages are entities that contain:
• The data relevant to routing.
• An event that will be triggered by the time the message is expected to arrive.
4.2.3.5 Events
Since Routesim is a discrete-event simulator, all objects will act as reactive objects, that is, objects will remain in a dormant state until some kind of event triggers any of their functions. Events, at the current version of the simulator and system model, are used in two specific moments:
• A Link Delivery Event will be triggered at the time a message is expected to arrive
• A TimeOut Event will be triggered when a node does not receive a path message in the specified time.
4.2.4 The System File
The system file describes the portion of reality that we would like to see simulated. In other words, the system file contains the description of all the network entities (nodes) that will take part in the routing simulation, their properties, and their communications channels (links).
We will also establish the limits of the simulation in the system file. The simulation is finished if there is no more events scheduled in the queue, or certain time limit is reached.
The system file possesses a certain structure that must be met; otherwise the execution of the script will fail. Since we’re in some way declaring and implementing Java objects, certain order must be kept. As referred in appendixB typical system file should follow the next structure:
1. Simulation and Console declaration and initialization: The lines on this section declare and initialize the console, the simulation; the last two lines set the time limit for the simulation, and the debug level. The debug level is set depending on the amount of feedback we want from the simulation. Level 3, for example, is the highest level, giving out a high debugging level information, which was used when the protocol did not behave according to the theory.
2. Node declaration and initialization: These lines are intented for the simulation entities to be declared. First, we will declare, initialize and identify the nodes.
Root node should always be node 0, and although it is not necessary to initialize it, redundancy makes the script easier to understand.
3. Link declaration and initialization: Links must be also initialized, for they will be needed later, when connecting entities. Although in manual-created scripts it is handy to declare nodes and links in the same section, when we meta-program script generators, sometimes separating this two sections will come in handy.
4. Path setup : In this section, each node is assigned the starting path and their policies. A policy is enforced by suc
