Tomograf
´
ıa de Internet: Adquisici
´
on y Estudio de Par
´
ametros Din
´
amicos de la Red
Mauricio Anderson Ricci
†1
†
Facultad de Ingenier
´
ıa, Universidad de Buenos Aires
Av. Paseo Col
´
on 850 - C1063ACV - Buenos Aires - Argentina
1
anderson@cnet.fi.uba.ar
Abstract—This work presents an Internet’s Topology study,
based on its tomography. Our objective was on the gathering
of data and their analysis, at both levels: routers and IP. To
do that, we developed an Open Source tool called Magallanes,
which uses PlaneLab platform for performing explorations
trough nodes around the world.
Resumen— En este trabajo hemos realizado un estudio
de la topolog
´
ıa de Internet, mediante lo que se conoce en
la bibliograf
´
ıa como Tomograf
´
ıa de Red. Nuestro objetivo
estuvo focalizado en la adquisici
´
on y an
´
alisis de datos
que nos permitiesen caracterizar a Internet, tanto a nivel
IP como a nivel de router. Para esto hemos desarrollado
Magallanes, un software de medici
´
on que opera sobre la
plataforma PlanetLab y nos permite realizar exploraciones
desde monitores distribuidos en todo el planeta.
I. INTRODUCCI
´
ON
En esta secci
´
on veremos los conceptos fundamentales
sobre lo que se basa este trabajo. Comenzaremos explicando
brevemente como funciona Internet para luego hablar sobre
lo que se entiendo por tomograf
´
ıa de red.
A. Funcionamiento de Internet
Los routers son elementos que operan en la capa de red.
Se encargan de dirigir los paquetes de datos desde el origen
hasta el destino entre las diversas redes que hay entre ambos.
La decisi
´
on de que ruta utilizar para enviar los paquetes
es tomada por el protocolo de enrutamiento configurado en
cada router.
Para ejemplificar la idea de rutas, hemos utilizado la
herramienta traceroute, la cual permite obtener informaci
´
on
del trayecto que siguen los paquetes entre dos ubicaciones,
desde un nodo de PlanetLab ubicado en Estados Unidos
hasta otro en Nueva Zelanda. Posteriormente, con los re-
sultados del traceroute y la ayuda de una herramienta de
geolocalizaci
´
on IP hemos generado la Figura 1, donde se
observa el camino seguido por el paquete a trav
´
es del
planeta. En cada uno de los punto donde se observa un
cambio de direcci
´
on lo que se encuentra es un router que
tom
´
o la decisi
´
on de enviar el paquete por uno u otro camino
dentro de los disponibles.
La importancia de estudiar las caracter
´
ısticas de estos
caminos se debe a que sobre Internet funcionan un gran
n
´
umero de servicio con alcance global. Estos servicios son
los hacen que esta sea indispensable para la sociedad actual.
Un ejemplo de estos servicios es la World Wide Web, el
cual es un servicio de distribuci
´
on de hipertexto que utiliza
Internet como medio de transmisi
´
on.
B. Tomograf
´
ıa de la red
Internet, al estar constituida por much
´
ısimas redes, pre-
senta continuas variaciones en su topolog
´
ıa. Estas varia-
Fig. 1: Ruta seguida por un paquete desde un nodo en
EEUU hasta otro en Nueva Zelanda
ciones son causadas principalmente por dos motivos: el
primero es que el protocolo TCP/IP es tolerante a fallas,
lo cual implica que ante la presencia de fallas el protocolo
sigue siendo capaz de entregar los paquetes de datos al
destinatario. La otra causa es que al ser operada de forma
aut
´
onoma por distintas empresas, las mismas pueden intro-
ducir cambios en su propia red sin justificar tales cambios
ante ninguna entidad.
Por lo ya mencionado, es importantes poder monitorear el
estado de la red y as
´
ı conocer y modelar sus caracter
´
ısticas.
Sin esta informaci
´
on resulta imposible desarrollar nuevas
tecnolog
´
ıas, protocolos y aplicaciones dado que no se podr
´
ıa
conocer ni prever el comportamiento de estos desarrollos al
momento de funcionar en entornos reales sobre Internet.
Es ac
´
a donde entra en juego el concepto de tomograf
´
ıa
de Red, o en nuestro caso, de Internet. Este termino hace
referencia al estudio de las caracter
´
ısticas de la red mediante
mediciones externas. Estas reciben el nombre de externas
por ser realizadas siempre en nodos de la red, sin estudiar
lo que sucede con los paquetes mientras viajan. Para ejem-
plificar, en el caso de la Figura 1 tenemos un paquete que
viaja desde un nodo en Estados Unidos hasta otro en Nueva
Zelanda a trav
´
es de distintos enlaces en Internet. Nosotros
medimos las caracter
´
ısticas de tales enlaces estando ubica-
dos en uno de los extremos del trayecto, sin necesidad de
acceder a cada uno de los enlaces.
C. Etapas de adquisici
´
on de datos
Existen dos pasos esenciales en todos los trabajos del
tema: la etapa de exploraci
´
on, en la que se adquieren datos
de los enlaces, las rutas, el tr
´
afico, etc; y el proceso de res-
oluci
´
on de aliases, que consiste en el mapeo de direcciones
IP previamente halladas en la etapa de exploraci
´
on a routers.
Dentro de la etapa de exploraci
´
on, las t
´
ecnicas utilizadas
se basan principalmente en los conocidos ping y traceroute,
y sus variantes. Estas herramientas nos permiten conocer
Revista elektron, Vol. 1, No. 1, pp. 38-47 (2017)
ISSN 2525-0159
38
Recibido: 04/07/2017; Aceptado: 22/07/2017
diferentes caracter
´
ısticas de las rutas que siguen los paquetes
a trav
´
es de la red.
Por otra parte, los routers poseen diferentes interfaces,
cada una de las cuales generalmente est
´
a conectada a una
red distinta y posee su propia direcci
´
on IP. Al realizar una
exploraci
´
on mediante traceroute, gran parte de las rutas
que se obtengan atravesar
´
an routers comunes a trav
´
es de
diferentes interfaces. Por lo tanto, es de inter
´
es conocer
cuales direcciones IP halladas pertenecen a cada uno de
estos routers con el fin de generar un mapa de la topolog
´
ıa
de un nivel de jerarqu
´
ıa mayor. Esta tarea de detectar cuales
IP pertenecen a un mismo router se conoce en la bibliograf
´
ıa
como resoluciones de alises.
En la resoluciones de alises se hace una primera dis-
tinci
´
on entre t
´
ecnicas activas y pasivas (o anal
´
ıticas) [1].
Las primeras realizan la asociaci
´
on de IP a router enviando
sondas (paquetes) a las direcciones a resolver y analizando
las respuestas de las mismas. Ejemplo de estas t
´
ecnicas
son Mercator [2], Ally [3] y MIDAR [4]. Luego, las
t
´
ecnicas pasivas realizan la inferencia sin la necesidad de
enviar paquetes a la direcciones en cuesti
´
on, en cambio
utilizan
´
unicamente la informaci
´
on adquirida en la etapa de
exploraci
´
on para inferir los alias. Ejemplos de estos m
´
etodos
son DisCarte [5] y Kapar [6].
II. ANTECEDENTE Y PROYECTOS DE INVESTIGACI
´
ON
ACTUALES
En primer lugar debemos mencionar a CAIDA [7], in-
stituci
´
on cuya finalidad es generar y recolectar datos de
Internet para su estudio. El primer proyecto desarrollado
en CAIDA fue denominado Skitter [8], en el cual se
desarroll
´
o una herramienta capaz de recolectar datos de
par
´
ametro de Internet. Esta herramienta basaba su operaci
´
on
en el comando traceroute [9] que, como resultado de su
ejecuci
´
on, devuelve par
´
ametros de la red asociados a una
ruta. Luego, a trav
´
es de las rutas se infieren los par
´
ametros
con los cuales se define el comportamiento de Internet.
Con Skitter se recolectaron datos para un gran n
´
umero
de trabajos de investigaci
´
on entre los cuales destaca Internet
tomography [10]. En este trabajo se sentaron las bases de
lo que denominamos tomograf
´
ıa de Internet. Los autores
explican que el termino tomograf
´
ıa es
´
util ya que, al igual
que en la pr
´
actica m
´
edica, se obtiene informaci
´
on del
objeto bajo estudio de forma poco invasiva. A su vez, se
sentaron cuatro ejes fundamentales al momento de hacer un
relevamiento de las caracter
´
ısticas de Internet. Estos son:
1) Determinar como se interconectan las redes
2) Determinar cu
´
anto demora y por cu
´
antos saltos pasa un
paquete entre origen y destino
3) Analizar la frecuencia y el patr
´
on que siguen el cambio
de las rutas
4) Visualizar a trav
´
es de un grafo las forma que toma
Internet
Luego del
´
exito de Skitter, CAIDA comenz
´
o un
nuevo proyecto denominado Archipielago [11] (abre-
viado como Ark). Este es un proyecto tiene continuidad
hoy en d
´
ıa y busca relevar datos de Internet a trav
´
es
de la herramienta paris-traceroute [12], generando
traceroutes desde varios puntos de medici
´
on alrededor del
planeta.
DIMES [13], al igual que los proyectos de CAIDA, surge
con el objetivo de determinar m
´
etricas para caracterizar In-
ternet tales como la capacidad de enlaces, distancias medidas
en cantidad de saltos o latencias. Sin embargo la arquitectura
de DIMES varia sustancialmente de la implementada en
Ark. DIMES se basa en lanzar traceroutes en paralelo desde
computadoras de usuarios voluntarios que han instalado el
software netDIMES. Este software habilita el uso de la
computadora dentro de la plataforma DIMES. Est
´
a dise
˜
nado
de tal forma de servir al proyecto pero al mismo tiempo
garantizarle al voluntario la seguridad de su equipo.
iPlane [14] es un proyecto desarrollado por la Univer-
sidad de Washington, con cerca de 250 puntos de medici
´
on.
Busca generar de mapas de Internet con el objetivo de
predecir el rendimiento de punta a punta entre dos nodos
cualesquiera, partiendo de ciertos enlaces cuyo rendimiento
es previamente conocido. T
´
ıpicamente los enlaces conocidos
se tratan de enlaces altamente transitados ubicados en la
backbone de Internet. El objetivo principal de este proyecto
es proveer informaci
´
on sobre la calidad de los enlaces
minimizando el n
´
umero de mediciones requeridas.
El
´
ultimo proyecto es Route Views [15]. Este es
coordinado por la universidad de Oregon y en la actualidad
recolecta y publica diariamente las tablas de ruteo BGP de
cientos de routers en todo el mundo. Esta tablas son de
gran utilidad para m
´
ultiples proyectos de investigaci
´
on de
Internet ya que a partir de las mismas de puede deducir
gran cantidad de informaci
´
on. Las tablas BGP cuentan con
un campo denominado AS-path que indica la secuencia de
ASN (Numero de sistema aut
´
onomo) para alcanzar la red
destino. Es decir, a trav
´
es de las tablas de ruteo se pueden
inferir la topolog
´
ıa de los sistemas aut
´
onomos.
III. HERRAMIENTA DE EXPLORACI
´
ON: MAGALLANES
Magallanes [16] es la herramienta de medici
´
on que
hemos desarrollado para realizar nuestras mediciones y
adquirir datos de la estructura de la red. En esta secci
´
on
veremos cu
´
al fue la motivaci
´
on que nos llev
´
o a su desarrollo,
el entorno de trabajo sobre el que funciona y los m
´
odulos
que lo componen. Por
´
ultimo, cerramos la secci
´
on comen-
tando sobre algunos algoritmos que hemos implementado
para lidiar con problemas t
´
ıpicos en mediciones de Internet.
A. Motivaci
´
on
Debido a la gran cantidad de problemas a afrontar
al momento de obtener datos de Internet, la comunidad
cient
´
ıfica no cuenta con una amplia variedad de herramientas
disponibles. En cambio, cuenta con un abanico de her-
ramientas para cada tarea individual, pero que no pueden
trabajar por si mismas en conjunto. Esto hace necesario
una plataforma con la que se puedan integrar diferentes
t
´
ecnicas, una especie de Todo en uno, que simplifique el
trabajo de adquisici
´
on de datos para el investigador. Por lo
tanto, nuestro objetivo es proveer a la comunidad cient
´
ıfica
de una herramienta flexible que permita la realizaci
´
on de
experimentos configurables.
En s
´
ıntesis, la filosof
´
ıa que hemos seguido al momento
del dise
˜
no de Magallanes se resume en lo siguiente:
1) Todo en uno: desde una
´
unica plataforma se puede
gestionar todos los pasos necesarios para la adquisici
´
on
Revista elektron, Vol. 1, No. 1, pp. 38-47 (2017)
ISSN 2525-0159
39
http://elektron.fi.uba.ar
de la informaci
´
on deseada, esto es, agregar nodos, in-
stalaci
´
on de software requerido en los mismos, generar
las exploraciones, resoluci
´
on de aliases, etc. Todo esto
sin necesidad de recurrir a programas externos.
2) Modular: se pueden agregar nuevas funcionalidades
sin realizar grandes cambios en el c
´
odigo principal.
Cualquier persona puede hacer un fork del repositorio
donde se aloja el programa y realizar las modificaciones
que se ajusten a sus necesidades.
3) Configurable: cada exploraci
´
on se puede configurar
seg
´
un los fines de cada exploraci
´
on. Dentro de los
par
´
ametros configurables estar
´
an, duraci
´
on de la ex-
ploraci
´
on, cantidad de nodos origen y destino, tipo de
traceroute, periodo de traceroute, etc.
B. Entorno de trabajo
Dada la filosof
´
ıa del grupo donde se realiz
´
o el tra-
bajo, la
´
unica restricci
´
on que se tomamos al momento de
dise
˜
nar Magallanes fue que se implementase utilizando
tecnolog
´
ıa open source.
Linux: es un sistema operativo de c
´
odigo abierto ampli-
amente utilizado en
´
ambitos acad
´
emicos y de investigaci
´
on.
Por lo tanto, el software fue dise
˜
nado para correr sobre este
sistema operativo, y en particular bajo distribuciones basadas
en Debian.
Python: es un lenguaje de programaci
´
on interpretado de
alto nivel, multiparadigma y de c
´
odigo abierto. Lo hemos
seleccionado como lenguaje de programaci
´
on por m
´
ultiples
motivos. Primero, se trata de un lenguaje con una amplia
comunidad de desarrolladores, lo que implica que existan
desarrolladas bibliotecas para multitud de tareas, entre las
cuales, las necesarias para nuestros prop
´
ositos. Entre estos
podemos mencionar la posibilidad de interactuar con el
sistema operativo y con la base de datos que utilizaremos. A
su vez, en el grupo donde se ha llevado a cabo este trabajo
se cuenta con una amplia experiencia en su utilizaci
´
on.
Postgres: ha sido el motor de base de datos elegido
por contar con los requerimientos esenciales de ser open
source, funcionar en entornos Linux, contar una API para
ser operado desde Python y ser de tipo relacional. Adi-
cionalmente, cuanta con caracter
´
ısticas extras que lo hacen
ideal para nuestro prop
´
osito como poseer tipos de datos
nativos orientado al uso en redes (direcciones IP y bloques
de direcciones con formato CIDR), y funciones para trabajar
con las mismas.
PlanetLab: es una plataforma distribuida geogr
´
aficamente
para el desarrollo, evaluaci
´
on y acceso a servicios de red a
escala planetaria [17]. Actualmente la misma es mantenida
por un grupo de investigadores en 300 sitios pertenecientes
a m
´
as de 30 pa
´
ıses, y posee 1.353 nodos en 717 sitios.
En la parte operativa, a cada uno de los servidores que
posee los denominaremos nodos. Los usuarios obtienen
acceso a los recursos de un nodo en forma de espacios
virtuales, los cuales son denominados slices. Los nodos son
asociados a un slice, y sobre estos se pueden instalar las
aplicaciones necesarias para correr diferentes experimentos.
GitHub: es una plataforma de desarrollo colaborativo
de software para alojar proyectos utilizando el sistema de
control de versiones GIT. Permite alojar en un repositorio
archivos de c
´
odigo y adem
´
as brinda herramientas muy
´
utiles
para el trabajo en equipo, como la posibilidad de hacer un
fork y solicitar pull request. Realizar un fork consiste clonar
un repositorio ajeno para eliminar alg
´
un bug o modificar
cosas de
´
el. Una vez realizadas las modificaciones se env
´
ıa
un pull request al due
˜
no del proyecto solicitando copiar las
modificaciones al c
´
odigo original.
´
Este podr
´
a analizar los
cambios que se han realizado, y si considera interesante las
contribuciones, aceptarlas.
Scamper: es una herramienta desarrollada por CAIDA
para la realizaci
´
on de diferentes tipos de mediciones en In-
ternet. Dentro estos tipos nos centraremos la implementaci
´
on
de traceroute por tener un rol central en la funcionalidad de
Magallanes.
La versi
´
on de traceroute que se implementa se denomina
Paris-Traceroute. Su principal aporte es que permite
lidiar con un fen
´
omeno presente en Internet conocido como
balanceo de carga, el cual, utilizando la versi
´
on cl
´
asica de
traceroute har
´
ıa que se infieran topolog
´
ıas err
´
oneas.
MIDAR: es un algoritmo de resoluci
´
on de aliases desar-
rollado por CAIDA que implementa varias caracter
´
ısticas
que logran hacer que se obtengan resultados m
´
as precisos
respecto de otros algoritmos. Tambi
´
en tiene la posibilidad
de ser utilizado con conjuntos de direcciones IP de gran
tama
˜
no. Basa su funcionamiento en sondear las direcciones
IP a resolver y analizar el campo IP-ID de los paquetes de
respuesta generadas por las interfaces de los routers.
C. M
´
odulos
El dise
˜
no de Magallanes lo hemos dividido en dos
m
´
odulos.
Por un lado, el modulo administraci
´
on se encarga de
la gesti
´
on del slice y dem
´
as tareas de mantenimiento. Las
acciones que se realizan desde ac
´
a son:
• Consultar el estado de los nodos
• Agregar nodos al slice
• Quitar nodos del slice
• Preparaci
´
on de los nodos para correr exploraciones
• Mantenimiento de la base de datos
Mientras que por otro lado tenemos el modulo explo-
raci
´
on. Este se encarga de:
• Programar nuevas exploraciones
• Cancelar exploraciones en ejecuci
´
on
• Almacenar exploraciones
• Realizar resoluci
´
on de aliases
• Eliminar datos de la base de datos
D. Algoritmos
En esta secci
´
on comentaremos algunos de los algoritmos
m
´
as relevantes que hemos implementado en Magallanes.
Selecci
´
on de target
Al momento de seleccionar las direcciones IP destinos
hacia las cuales se realizar
´
an los traceroutes hemos optado
por incluir cuatro opciones.
Las dos primeras opciones corresponder a usar como des-
tino nodos de PlanetLab, seleccionados espec
´
ıfica o aleatori-
amente. De este modo se permite ejecutar traceroutes desde
varios extremos entre si mismos. La tercera opci
´
on permite
indicar manualmente direcciones IP p
´
ublicas a utilizar como
destino.
Revista elektron, Vol. 1, No. 1, pp. 38-47 (2017)
ISSN 2525-0159
40
http://elektron.fi.uba.ar
La
´
ultima opci
´
on corresponde a tomar direcciones IP
publicas aleatorias. Como la idea es que una exploraci
´
on
abarque los m
´
as posible hemos decidido tratar de utilizar
direcciones distribuidas alrededor del planeta. Para esto
hemos empleado la base de datos libres GeoLite2 [18]
provista por la empresa MaxMind [19]. Esta base de datos
cubre todo el espacio de direcciones IPv4, incluyendo todas
las direcciones p
´
ublicas disponibles.
C
´
alculo de First-Hop
Un problema que se genera al realizar traceroutes desde
un monitor a m
´
ultiples destinos es que los primeros routers
para las distintas rutas ser
´
an siempre los mismos, y por
lo tanto a estos routers se los exigir
´
ıa mucho y podr
´
ıan
dejar de responder. A su vez, esto hace que no se obtengan
mediciones balanceadas de los enlaces, es decir, no se
obtendr
´
ıan la misma cantidad de mediciones en todos los
enlaces de la topolog
´
ıa bajo estudio.
Para mitigar este problema hemos implementado el Al-
goritmo 1 que se encarga de hacer que, en una ronda de
traceroutes, se muestree cada direcci
´
on IP descubierta en
la topolog
´
ıa una
´
unica vez. Para lograr esto, el algoritmo
realiza una primer ronda de traceroutes en la cual cada
traceroute es ejecutado con el par
´
ametro ttl-inicial igual 1,
es decir, se comienza a muestrear desde el primer hop. Una
vez finalizada esta ronda inicial, se analizan los resultados y
se averigua para cada direcci
´
on IP destino cual es el primer
hop que no es alcanzado en ning
´
un otro traceroute hacia
las restantes direcciones IP. Finalmente, se lanzan en los
siguientes traceroute configurando el par
´
ametro ttl-inicial
de modo que el primer paquete de cada traceroute alcance
a estos hops.
Algorithm 1 Calculo de first hop
Input: target: lista de IP a las cuales se har
´
an traceroutes
Output: f irst hop: vector con el TTL inicial a cada IP del
target
1: IP
found
= φ
2: f irst hop = φ
3: for i; i + +; |target| do
4: traceroute(IP = IP [i], T T L
initial
= 1)
5: for i; i + +; |target| do
6: trace = read traceroute(IP [i])
7: T T L
initial
= 1
8: for hop in trace do
9: if hop in IP
found
then
10: T T L
initial
+ +
11: else
12: IP
found
append hop
13: first hop[i] = T T L
initial
14: break
15: return first hop
Para comprobar los resultados de la implementaci
´
on de
este algoritmo hemos realizado un experimento que consisti
´
o
en tomar un monitor desde el cual se realizaron dos explo-
raciones. En ambas se realizaron 50 rondas de traceroutes
hacia las mismas 100 direcciones IP, es decir, se realizaron
5.000 traceroutes. En una primera exploraci
´
on se dej
´
o el
Fig. 2: Algoritmo de First-Hop desactivado
Fig. 3: Algoritmo de First-Hop activado
algoritmo desactivado, y luego en la siguiente exploraci
´
on
se lo activo. De cada una de estas exploraciones se tomaron
los resultados obtenidos considerando los cuatro primeros
hops hacia cada destino y se generaron las figuras 2 y 3.
En estas, cada barra vertical representa una direcci
´
on IP
hallada, mientras que la altura es la cantidad de veces que
la direcci
´
on IP es alcanzada. Se observa que en el segundo
caso hay una variaci
´
on mucho menor que en el primer caso
en la cantidad de veces que es alcanzada cada direcci
´
on IP.
Esto es justamente lo que se buscaba con la implementaci
´
on
del algoritmo.
Resoluci
´
on de aliases
Para la resoluci
´
on de aliases hemos utilizado MIDAR. Este
algoritmo tiene dos modos de funcionamiento:
1) Modo local: utiliza un
´
unico nodo para la resoluci
´
on,
y permite resolver hasta 40.000 direcciones IP por
ejecuci
´
on.
2) Modo distribuido: utiliza m
´
ultiples nodos en simult
´
aneo
y permite resolver conjuntos compuesto de millones de
direcciones IP.
Dado que nosotros tenemos que resolver conjuntos com-
puestos por m
´
as de 40.000 direcciones IP, el funcionamiento
en modo local no nos es
´
util. Luego, dado que contamos
con m
´
ultiples nodos que podr
´
ıamos emplear, lo ideal ser
´
ıa
utilizar MIDAR en modo distribuido, pero no hemos podido
implementarlo por problemas de compatibilidad de ciertas
bibliotecas necesarias con el sistema operativo Fedora 8
presente en los nodos de PlanetLab.
Ante este problema nos hemos puesto en contacto con
Revista elektron, Vol. 1, No. 1, pp. 38-47 (2017)
ISSN 2525-0159
41
http://elektron.fi.uba.ar
Ken Keys (CAIDA), quien es uno de los desarrolladores del
algoritmo. La soluci
´
on que nos propuso consisti
´
o en una
implementaci
´
on mixta.
Lo que finalmente hemos implementado el Algoritmo
2. Este divide inteligentemente nuestro conjunto en sub-
conjuntos no mayores a 40.000 direcciones IP que luego
son distribuidos en distintos nodos de PlanetLab. En cada
uno de estos nodos es ejecutado el algoritmo en modo
local, y luego transferido los resultados hacia el servidor
donde se ejecuta Magallanes. De esta forma logramos
minimizar la cantidad de direcciones IP alias que van a parar
a subconjuntos diferentes y por lo tanto se pierden.
Algorithm 2 Resoluci
´
on de aliases implementada en
Magallanes
Input: R
IP
: lista de IPs halladas;
R
node
: lista de nodos con Fedora 14
Output: aliases
1: aliases = φ
2: TCP = UDP = ICMP = φ
3: partitioned R
IP
in SR
IP
subsets / |SR
IP
(i)| ≤ 40000 ∀ i
4: for i = 1, j = 1; i + +; i ≤ max(|SR
IP
|) do
5: repeat
6: method(SR
IP
(i), R
node
(j))
7: j++
8: if j > j
max
then
9: j = 1
10: until method 6= φ
11: for n = 1; n + +; n = |SR
IP
(i)| do
12: select method(n)
13: if method(n) = tcp then
14: insert ordered(method(n), TCP)
15: else if method(n) = udp then
16: insert ordered(method(n), UDP)
17: else if method(n) = icmp then
18: insert ordered(method(n), ICMP)
19: for each l in {TCP, UDP, ICMP} do
20: select S
IP
(i) =
{x ∈ l/1
st
byte identical and |SR
IP
(i)| ≤ 40000}
21: j = 1
22: repeat
23: alias res(S
IP
(i), R
node
(j))
24: j++
25: if j > j
max
then
26: j = 1
27: until alias res 6= φ
28: aliases ← aliases + alias res
29: return aliases
Los criterios que hemos tomado para generar los subcon-
juntos, a sugerencia de Ken Keys, son:
1) Que las direcciones IP pertenecientes a un mismo sub-
conjunto responda al mismo tipo de sonda (UDP, TCP,
ICMP). Basado en mediciones de trabajo previos [20],
las direcciones IP que resultan ser alias y responden a
distintos tipos de sondas representan solo un 2% del
total de aliases.
2) Buscamos que todas las IP que vayan a parar a un
mismo subconjunto posean el mismo primer byte de
0.0
0.5
1.0
1.5
0 25 50 75 100
Monitores
Traceroutes [Millones]
Fig. 4: #Traceroutes realizados en cada monitor
su direcci
´
on IP con el objetivo de que las mismas
est
´
en geogr
´
aficamente cercanas entre s
´
ı. Esto se debe
a que es m
´
as probable que dos direcciones IP cercanas
geogr
´
aficamente sean alias, antes que dos direcciones
IP distantes.
IV. EXPLORACI
´
ON DE LA TOPOLOG
´
IA DE INTERNET
Ahora que hemos descrito el funcionamiento de
Magallanes realizaremos una exploraci
´
on general y
analizaremos los resultados obtenidos.
A. Objetivo y preparaci
´
on
El objetivo que nos hemos propuesto para la exploraci
´
on
es que sea lo m
´
as extensa posible a nivel de descubrimiento
de routers y enlaces, sin focalizar en otros aspectos como
la adquisici
´
on de datos de latencia o la variaci
´
on de la
topolog
´
ıa. Esto es debido a que en toda exploraci
´
on se debe
realizar una balance entre los distintos par
´
ametros seg
´
un el
objetivo que se busque. Finalmente, los par
´
ametros por los
que hemos optado son:
• Cantidad de monitores: 104
• Cantidad de destinos: 100.000 direcciones IP/monitor
• Tiempo entre rondas de traceroutes: 3600 seg
• Duraci
´
on: 12 horas
• Tasa de sondeo (packets-per-second): 350 pps
• Tipo de sonda: UDP-paris
• Rec
´
alculo First-Hop: S
´
ı (cada 6 horas)
• Resoluci
´
on de aliases: MIDAR
De esta manera esperamos generar idealmente en torno a
125 millones de traceroutes.
B. Resultados experimentales y an
´
alisis
Una vez descargado los datos de los 104 monitores,
lo primero que se observa es que 4 de estos han fal-
lado, mientras que otros 4 han generado una cantidad de
traceroutes muy inferior a la esperada. En la Figura 4 se
muestra la cantidad de traceroutes registrados por monitor,
ordenados por cantidad. Dado que los monitores que fallaron
representan menos de un 10% del total no nos detendremos
a analizar las causas de tales fallas.
La cantidad global de direcciones IP descubiertas es
1.318.872. Luego, cruzando los datos con la base de datos
GeoLite2 de MaxMind [19], en la Tabla I se muestra como
se distribuyen estas a nivel continental.
Revista elektron, Vol. 1, No. 1, pp. 38-47 (2017)
ISSN 2525-0159
42
http://elektron.fi.uba.ar
Continente #IP Proporci
´
on
Europa (EU) 578.800 43.9%
Am
´
erica del Norte (NA) 378.369 28.7%
Asia (AS) 231.092 17.5%
Am
´
erica del Sur (SA) 50.230 3.8%
Ocean
´
ıa (OC) 26.726 2.0%
´
Africa (AF) 21.577 1.6%
Ant
´
artida (An) 18 0.0%
no localizables 32.065 2.4%
TABLE I: Cantidad de direcciones IP halladas por continen-
tal
EU NA AS OC SA AF
EU 977.779 148.228 21.722 902 6.629 5.920
NA 148.228 517.006 35.590 5.352 14.193 5.179
AS 21.722 35.590 394.699 4.374 422 1.277
OC 902 5.352 4.374 34.792 12 294
SA 6.629 14.193 422 12 39.077 119
AF 5.920 5.179 1.277 294 119 19.367
TABLE II: Cantidad de enlaces hallados entre continente a
nivel IP
Luego, las 1,32 millones de direcciones IP halladas se vin-
culadas mediante 2,35 millones de enlaces. La distribuci
´
on
de los enlaces a nivel de continente se indica en la Tabla II.
Pasando a la resoluci
´
on de aliases obtenemos que, de las
1,32 millones de direcciones IP se han encontrado, hallamos
102.606 aliases agrupando en total a 402.562 direcciones IP
(31% del total). Una vez completado este paso ya poseemos
los grafos que caracterizan a la red: el grafo a nivel IP y el
grafo a nivel router.
Ahora continuaremos con el an
´
alisis del grafo a nivel
router, describi
´
endolo mediante las principales m
´
etricas
utilizadas en an
´
alisis de grafos. A este lo consideraremos de
ahora en m
´
as como no dirigido, es decir, no le asignamos
sentido al trafico de paquetes, y no le asociaremos peso a
sus enlaces.
Distribuci
´
on de grado
Dentro de grafos no dirigidos, se define como grado
de un nodo a la cantidad de enlaces que este posee. Una
caracterizaci
´
on natural de las propiedades estad
´
ısticas de los
grafos es proporcionada por la distribuci
´
on de grado de los
nodos que lo conforman, lo cual tambi
´
en se puede entender
como la probabilidad P (k) de que un nodo aleatorio tenga
grado k. De esta manera, la distribuci
´
on de grado se define
seg
´
un la expresi
´
on: P (k) =
1
n
P
k
i
=k
1, donde n es el
n
´
umero de nodos total y k
i
el grado del nodo i.
Estudios previos sobre el tema de redes complejas han
revelado que los grafos que muestran una distribuci
´
on de
probabilidad P (k) con cola pesada en muchos casos pueden
aproximarse con precisi
´
on por una distribuci
´
on con compor-
tamiento de ley de potencias, esto es P (K) ∼ k
−γ
, donde
2 ≤ γ ≤ 3. Esto ha llevado a la introducci
´
on del concepto de
red sin escala [21], las cuales se caracterizan por poseer un
peque
˜
no grupo de nodos altamente conectados, mientras que
el grado de conexi
´
on de los nodos es bastante bajo. Como
veremos, Internet presenta este tipo de comportamiento.
En la Figura 5 se muestra la distribuci
´
on de grado
de P (k) en funci
´
on de k para el grafo obtenido en
la exploraci
´
on y como el mismo efectivamente sigue
una ley de potencias. En particular, utilizando la funci
´
on
1e−04
1e−03
1e−02
1e−01
5e−01
1e+00
1 10 100
grado
Probabilidad
Fig. 5: Ajuste de distribuci
´
on de grado mediante
P (k) ∼ k
−2.162
, para k
min
= 5
power.law.fit{igraph} de R, la cual se basa en el
m
´
etodo de Newman [22], se observa que el valor de γ ronda
en torno a 2.16 para grado mayor a 5.
Distribuci
´
on del grado medio de los vecinos
El grado medio de los vecinos de un nodo se define, como
su nombre lo indica, como el promedio de grado de los
nodos vecinos a este:
k
nn
(k) =
1
n
k
X
j/k
j
=k
1
|V (j)|
X
i∈V (j)
k
i
d
´
onde V (j) es el conjunto de los vecinos del nodo j, |V (j)|
su cardinalidad, k
i
es el grado del nodo i, y n
k
el n
´
umero
de nodos de grado k.
Este par
´
ametro da una idea que de como est
´
an conectados
los nodos de un grafo. En el caso que los nodos de grado
elevado posean un k
nn
peque
˜
no, entonces ellos actuar
´
an
de concentradores, implicando que los nodos de grado
bajo tengan como vecinos otros de grado elevado. Este
comportamiento est
´
a definido como discordante [23] y se
observa en la topolog
´
ıa de los sistemas aut
´
onomos. En
cambio cuando los nodos de grado elevado tienen como
vecinos otros nodos de grado tambi
´
en elevado, se denominan
concordante [23]. Este
´
ultimo comportamiento es observado
en algunas redes sociales.
Las nociones de discordante o concordante tienen sentido
cuando las pendientes son marcadas, de otro modo las
peque
˜
nas variaciones pueden ser originadas por los sesgos
en la obtenci
´
on de los mapas [24]. En la Figura 6 se observa
justamente este
´
ultimo caso para el mapa de routers que
hemos hallado, las variaciones son peque
˜
nas (menos de una
d
´
ecada para grado menor que 100). Luego, en la Figura 7
se observa que la mayor
´
ıa de los nodos est
´
an conectados a
otros nodos de bajo grado. Esto se explica dada la estructura
jer
´
arquica de la red, en la que cada nodo est
´
a act
´
ua de puente
entre niveles jer
´
arquicos.
Distribuci
´
on de coeficiente de clustering
El coeficiente de clustering C
i
de un nodo mide el nivel
de interconexi
´
on de los vecinos de este, es decir, mide
la probabilidad de que los nodos vecinos a este est
´
en
conectados entre s
´
ı:
Revista elektron, Vol. 1, No. 1, pp. 38-47 (2017)
ISSN 2525-0159
43
http://elektron.fi.uba.ar
10
100
1 10 100 1000
Grado
Promedio del grado medio de los vecinos
Fig. 6: Promedio del grado medio de los vecinos en
funci
´
on del grado
0
25000
50000
75000
1 10 100 1000
Grado medio de los vecinos
#Nodos
Fig. 7: Histograma del grado medio de los vecinos
C
i
=
2 · n
enlace
k
i
· (k
i
− 1)
donde n
enlace
es el n
´
umero de conexiones entre los vecinos
del nodo i, y k
i
es el grado del nodo i. La funci
´
on de
distribuci
´
on del grado es:
C(k) =
1
n
k
·
X
j/k
j
=k
C
j
Por ejemplo, si el nodo est
´
a agrupado como un clique
su valor es 1 (m
´
aximo), mientras que un valor peque
˜
no
indica un nodo poco agrupado en la red. Formalmente,
el coeficiente de clustering de un nodo est
´
a dado por la
proporci
´
on entre los enlaces conectados con sus vecinos
respecte del n
´
umero de enlaces que habr
´
ıa en un clique en
el que la conectividad es m
´
axima.
En la Figura 8 se muestra el histograma del coeficiente
de clustering del grafo hallado. Se aprecia que en general
los nodos tienen un bajo nivel de interconexi
´
on en la red,
mientras que un grupo tienen un coeficiente cercano a 1.
Estos
´
ultimos son nodos de bajo grado en los que es m
´
as
probable encontrar que pertenecen a un clique. En cambio,
en los nodos de mayor grados, esto no se da en ning
´
un caso
dado la enorme cantidad de enlaces que se necesitar
´
ıan
para tal hecho. Estos conceptos se visualiza m
´
as claramente
en la Figura 9, donde vamos que a medida que aumenta
el grado de los nodos disminuye el coeficiente de clustering.
0
2500
5000
7500
10000
1e−04 1e−03 1e−02 1e−01 1e+00
clustering
#Nodos
Fig. 8: Histograma del coeficiente de clustering
1e−06
1e−04
1e−02
1 10 100 1000
grado
Promedio del coef. de clustering
Fig. 9: Promedio del coeficiente de clustering en funci
´
on
del grado
Centralidad
La centralidad de un nodo dentro de un grafo se refiere a
una medida posible de este en dicho grafo que determina su
importancia relativa en la red. Las medidas de centralidad
se pueden agrupar en dos categor
´
ıas: las medidas radiales y
mediales. Las primeras toman como punto de referencia un
nodo dado que inicia o termina recorridos por la red, mien-
tras que las segundas toman como referencia los recorridos
que pasan a trav
´
es de un nodo dado. Las medidas radiales
a su vez se pueden clasificar en medidas de volumen y de
longitud, seg
´
un el tipo de recorridos que consideran. Las
primeras miden el volumen (o el n
´
umero) de recorridos lim-
itados a dicha longitud prefijada, en tanto que las segundas
miden la longitud de los recorridos necesarios para alcanzar
un volumen prefijado. En base a esta clasificaci
´
on existen
cuatro medidas que son ampliamente utilizadas en an
´
alisis
de redes:
• La centralidad de grado (degree centrality)
• La cercan
´
ıa (closeness)
• La intermediaci
´
on (betweenness)
• La centralidad de vector propio (eigenvector centrality)
La primera y la
´
ultima son medidas radiales de volumen.
La segunda es una medida radial de longitud, y la tercera
una medida medial.
La centralidad de grado corresponde al n
´
umero de enlaces
que posee un nodo con los dem
´
as. Existen criterios que
son usados para normalizar esta medida: dividir el grado de
Revista elektron, Vol. 1, No. 1, pp. 38-47 (2017)
ISSN 2525-0159
44
http://elektron.fi.uba.ar
1e+01
1e+03
1e+05
1.2e−12 1.6e−12 2.0e−12
Coef de cercania
#Nodos
Fig. 10: Histograma de coeficiente de cercan
´
ıa
1.00e−12
1.25e−12
1.50e−12
1.75e−12
2.00e−12
1 10 100 1000
grado
Promedio del coef. de cercanía
Fig. 11: Promedio del coeficiente de cercan
´
ıa en funci
´
on
del grado
cada nodo por el m
´
aximo grado obtenido de la red, o bien
dividirlo por el n
´
umero total de nodos de la red. Como esta
medida es similar entregar
´
ıa resultados similares a la dis-
tribuci
´
on de grado que vimos previamente no ahondaremos
en la misma.
Respecto de la cercan
´
ıa, dada su definici
´
on, se espera
que los nodos presentes en el centro de la red (troncal o
backbone) presenten un nivel de cercan
´
ıa inferior que los
ubicados en las periferias. En la Figura 10 se observa el
histograma que presenta este par
´
ametro en nuestra explo-
raci
´
on. Como es de esperar, dada la forma jer
´
arquica de la
red, se obtiene una mayor densidad de nodos con valor bajo
de este par
´
ametro. Luego, en la Figura 11 se observa esta
misma caracter
´
ıstica. A medida que aumenta el grado de los
nodos, aumenta el coeficiente de cercan
´
ıa.
La intermediaci
´
on de un nodo es una medida que
cuantifica la frecuencia o el n
´
umero de veces que un
nodo act
´
ua como un puente a lo largo del camino m
´
as
corto entre cada par de nodos. Un nodo con un alto grado
de intermediaci
´
on tiene una gran influencia en el tr
´
afico
de la red, que en el caso de Internet corresponden a los
nodos ubicados en el centro de la red. En la Figura 12
se observa el histograma de este par
´
ametro utilizando una
escala logar
´
ıtmica sobre el eje horizontal. Luego, en la
Figura 13 se observa esto mismo. A medida que aumenta
el grado de los nodos, mayor tiende a ser su coeficiente de
intermediaci
´
on.
0
5000
10000
15000
20000
25000
1e+00 1e+03 1e+06 1e+09
Intermediación
#Nodos
Fig. 12: Histograma de coeficiente de intermediaci
´
on
1e+04
1e+06
1e+08
1 10 100 1000
grado
Promedio del coef. de intermediación
Fig. 13: Promedio del coeficiente de intermediaci
´
on en
funci
´
on del grado
Visualizaci
´
on de topolog
´
ıa
Para la visualizaci
´
on del grafo utilizaremos la herramienta
LaNet-vi [25], la cual se basa en la descomposici
´
on
en k-n
´
ucleos. Para esto introduciremos algunos conceptos
necesarios para describir los resultados obtenidos [26]:
• k-n
´
ucleo: un subgrafo H = (C, E|C) inducido por
el conjunto C ⊆ V en un k-n
´
ucleo (o un n
´
ucleo
de orden k) sii para todo ν ∈ C: grado
H
(ν) y
H es el m
´
aximo subgrafo con esta propiedad. Una
forma de obtener la descomposici
´
on en k-n
´
ucleos es
ir eliminando recursivamente todos los nodos de grado
menor que k, hasta que todos los nodos restantes tengan
grado mayor o igual que k.
• capa: un nodo tiene n
´
umero de capa c (Shell index) si
dicho nodo pertenece al c-n
´
ucleo pero no al (c + 1)-
n
´
ucleo. Lo importante de este par
´
ametro es su relaci
´
on
con la conectividad. Si bien un k-n
´
ucleo no es k-
conexo en general, en ciertos casos pr
´
acticos se puede
dar esta conectividad. Si un grafo es core-conexo,
entonces existen k caminos independientes entre todo
par de v
´
ertices que pertenecen a un k-n
´
ucleo. En otras
palabras, dado dos v
´
ertices u y v, existen al menos
min(c
u
, c
v
) caminos independientes entre ambos. En
lenguaje de redes de datos esto significa que si alguno
de esos caminos est
´
a obstruido, ya sea por congesti
´
on
o por una falla moment
´
anea, entonces se puede ele-
gir otro camino para llegar al destino. Incluso, si se
Revista elektron, Vol. 1, No. 1, pp. 38-47 (2017)
ISSN 2525-0159
45
http://elektron.fi.uba.ar
Fig. 14: Visualizaci
´
on del grafo obtenido con Lanet-vi:
Vista completa
necesita una red que cumpla con cierta calidad de
servicio, es decir que respete ciertas cotas m
´
ınimas para
alg
´
un par
´
ametro (demora, capacidad, etc.), cuanto m
´
as
caminos existan entre sus v
´
ertices, m
´
as posibilidades
tendr
´
a de encontrar aquel que verifique la calidad
deseada.
Entonces, en la Figura 14 se muestra el grafo obtenido
visualiz
´
andolo mediante esta t
´
ecnica. La idea de la visual-
izaci
´
on es ubicar en el centro la capa con el k
max
-n
´
ucleo
en forma de c
´
ırculo, donde su di
´
ametro es proporcional al
n
´
umero de elementos que lo componen y luego las otras
capas k en circunferencias conc
´
entricas que se alejan del
k
max
y donde la circunferencia exterior corresponde a la
capa con k
min
. De esta manera cada circunferencia corre-
sponde a cada capa k y todos los v
´
ertices que la conforman
se dibujan sobre ellas con el mismo color. A medida que
nos acercamos al n
´
ucleo se van solapando algunas de estas
circunferencias por lo cual puede parecer que poseen m
´
as
de un color, pero realmente son circunferencias solapadas.
Luego, si bien los v
´
ertices est
´
an ubicados inicialmente en
una circunferencia,
´
estos pueden desplazarse hacia el centro
seg
´
un el valor promedio de c
v
de sus vecinos v. Esto se
observa m
´
as notoriamente en las capas externas.
Sobre la derecha de la imagen se muestra una escala de
colores con el n
´
umero de capa c
i
, mientras que a la izquierda
una escala logar
´
ıtmica del grado de los v
´
ertices representado
por el tama
˜
no de los mismos. Los detalles de la visualizaci
´
on
se pueden encontrar extensivamente descritos en [27].
En estas visualizaciones se puede apreciar la propiedad
jer
´
arquica de Internet, en la cual cada una de las capas
est
´
a densamente poblada y las conexiones se producen
principalmente entre elementos de capas contiguas, y no
hacia la capa central como ocurre en otro tipos de redes tal
como la de los sistemas aut
´
onomos [24]. Otra observaci
´
on
importante es que no existe una fuerte correlaci
´
on grado-
capa. Esto
´
ultimo se puede ver ya que en las capas exteriores
tenemos v
´
ertices de gran tama
˜
no o grado elevado.
Fig. 15: Visualizaci
´
on del grafo obtenido con Lanet-vi:
Ampliaci
´
on sobre la zona central del grafo
V. CONCLUSIONES
A. Contribuciones
Este trabajo ha sido un resumen de mi tesis de grado de
Ingenier
´
ıa Electr
´
onica de la Universidad de Buenos Aires
[28]. Como resultado hemos desarrollado una herramienta,
Magallanes, para gesti
´
on de exploraciones de Internet
que cumple con los requisitos que nos propusimos ini-
cialmente. Con esta herramienta hemos realizado distintos
estudios.
En primer lugar realizamos una exploraci
´
on de la estruc-
tura de Internet que nos permiti
´
o hacer una caracterizaci
´
on
a rasgos generales de su topolog
´
ıa. A nivel cualitativo
los resultados obtenidos son consistentes con lo que es-
per
´
abamos a priori, demostrando como la red a nivel de
router presenta un comportamiento jer
´
arquico, donde los
nodos se comunican hacia el centro de la red a trav
´
es de
otros routes, y no directamente como sucede en otras redes
como la de los sistemas aut
´
onomos.
Sumado a esto, se utiliz
´
o Magallanes para llevar a
cabo trabajos de investigaci
´
on. Uno sobre la caracterizaci
´
on
del par
´
ametro RRT en los primeros hops de distintas redes,
y luego otro trabajo sobre la influencias de las redes MPLS
dentro de la estructura de Internet, que a su vez desemboc
´
o
en la publicaci
´
on [29].
B. Trabajos futuros
Para continuar con el desarrollo de este trabajo surgen
varias posibilidades de investigaci
´
on. Por un lado se podr
´
ıa
hacer un an
´
alisis de las redes por regiones geogr
´
aficas, es
decir, nosotros en el presente trabajo tratamos a la red como
un todo, pero podr
´
ıamos desear caracterizar a la red en
cada continente y luego comparar su estructura. A su vez se
podr
´
ıa ampliar el an
´
alisis de la topolog
´
ıa incluyendo peso
a los enlaces de modo que representen distintos par
´
ametros
como pueden ser latencias, disponibilidad o tase de perdida.
Otra posibilidad ser
´
ıa integrar una herramienta para mapear
el prefijo IP al ANS de cada nodo y luego, mediante la
informaci
´
on provista por el proyecto route views, realizar el
mapeo de cada nodo al sistema aut
´
onomo al que pertenece
y crear as
´
ı mapas a nivel de sistema aut
´
onomo.
REFERENCES
[1] K. Keys, “Internet-Scale IP Alias Resolution Techniques,” ACM
SIGCOMM Computer Communication Review (CCR), vol. 40, no. 1,
pp. 50–55, Jan 2010.
[2] R. Govindam and H. Tangmunarunkit, “Heuristics for internet map
discovery,” 2000.
[3] N. Spring, R. Mahajan, D. Wetherall, and T. Anderson, “Measuring
ISP topologies using rocketfuel,” IEEE/ACM Transactions on Net-
working, vol. 12, pp. 2–16, 2004.
[4] “Midar,” http://www.caida.org/tools/measurement/midar/.
Revista elektron, Vol. 1, No. 1, pp. 38-47 (2017)
ISSN 2525-0159
46
http://elektron.fi.uba.ar
[5] R. Sherwood, A. Bender, and N. Spring, “DisCarte: A Disjunctive
Internet Cartographer,” ACM SIGCOMM Computer Communication
Review, 2008. [Online]. Available: http://www.rob-sherwood.net/
discarte-sigcomm08.pdf
[6] “Kapar,” http://www.caida.org/tools/measurement/kapar/.
[7] “Caida:center for applied internet data analysis,” http://www.caida.
org/.
[8] “Skitter,” http://www.caida.org/tools/measurement/skitter/.
[9] V. Jacobson and S. Deering, “traceroute,” Feb 1989.
[10] K. Claffy, T. Monk, and D. McRobb, “Internet Tomography,”
Nature, January 1997. [Online]. Available: http://www.nature.com/
nature/webmatters/tomog/tomog.html
[11] “Archipelago (ark) measurement infrastructure,” http://www.caida.
org/projects/ark/.
[12] “Paris traceroute,” http://www.paris-traceroute.net/.
[13] E. S. Yuval Shavitt, “Dimes: Let the internet measure itself,” ACM
SIGCOMM Computer Communication Review, 2005.
[14] “iplane,” http://web.eecs.umich.edu/
∼
harshavm/iplane/.
[15] “University of oregon route views project,” http://www.routeviews.
org/.
[16] “Magallanes,” https://github.com/ihameli/magallanes.
[17] “Planetlab: An open platform for developing, deploying, accessing
planetary-scale services,” https://www.planet-lab.org/.
[18] “Geolite2,” http://dev.maxmind.com/geoip/geoip2/geolite2/.
[19] “Maxmind,” https://www.maxmind.com/es/home.
[20] K. Keys, Y. Hyun, M. Luckie, and k. Claffy, “Internet-Scale IPv4
Alias Resolution with MIDAR,” IEEE/ACM Transactions on Net-
working, vol. 21, no. 2, pp. 383–399, Apr 2013.
[21] R. Albert, H. Jeong, and A. Barabasi, “Diameter of the world-wide
web,” Nature, Sep 1999.
[22] A. Clauset, C. R. Shalizi, and M. E. Newman, “Power-law
distributions in empirical data,” SIAM, vol. 4, no. 51, pp. 661–703,
2009. [Online]. Available: http://arxiv.org/pdf/0706.1062.pdf
[23] M. E. J. Newman, “Assortative mixing in networks,” Phys.
Rev. Lett., vol. 89, p. 208701, Oct 2002. [Online]. Available:
http://link.aps.org/doi/10.1103/PhysRevLett.89.208701
[24] J. I. Alvarez-Hamelin, “Taxonomia de los Modelos de Topologia
de Internet,” in Mecanica Computacional, Interdisciplinary
Mathematical Methods, vol. XXV, no. 29. CIMEC, 2006,
pp. 2597–2612. [Online]. Available: http://www.cimec.org.ar/ojs/
index.php/mc/article/view/636/604
[25] “Lanet-vi,” http://lanet-vi.fi.uba.ar/.
[26] M. G. Beir
´
o, J. I. Alvarez-Hamelin, and J. R. Busch, “A low
complexity visualization tool that helps to perform complex systems
analysis,” New J. Phys, vol. 10, no. 12, p. 125003, 2008. [Online].
Available: http://dx.doi.org/10.1088/1367-2630/10/12/125003
[27] J. I. Alvarez-Hamelin, L. Dall’Asta, A. Barrat, and A. Vespignani,
“Large scale networks fingerprinting and visualization using the k-
core decomposition,” in Advances in Neural Information Processing
Systems 18, Y. Weiss, B. Sch
¨
olkopf, and J. Platt, Eds. Cambridge,
MA: MIT Press, 2006, pp. 41–50. [Online]. Available: http://cnet.fi.
uba.ar/ignacio.alvarez-hamelin/pdf/AH
D B V NIPS2006.pdf
[28] M. Anderson, “Tomograf
´
ıa de Internet: Adquisi
´
on y estudio de
par
´
ametros din
´
amicos de la red,” FIUBA, 2016. [Online]. Available:
http://cnet.fi.uba.ar/mauricio anderson/Tesis Mauricio Anderson.pdf
[29] F. D. Revelo, M. A. Ricci, B. Donnet, and J. I. Alvarez-
Hamelin, “Unveiling the MPLS Structure on Internet Topology,”
8th International Workshop on Traffic Monitoring, Analysis (TMA),
Apr 2016. [Online]. Available: http://orbi.ulg.ac.be/bitstream/2268/
194694/1/paper.pdf
Revista elektron, Vol. 1, No. 1, pp. 38-47 (2017)
ISSN 2525-0159
47
http://elektron.fi.uba.ar
Enlaces de Referencia
- Por el momento, no existen enlaces de referencia
Copyright (c) 2017 Mauricio Anderson Ricci
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License.
Revista elektron, ISSN-L 2525-0159
Facultad de Ingeniería. Universidad de Buenos Aires
Paseo Colón 850, 3er piso
C1063ACV - Buenos Aires - Argentina
revista.elektron@fi.uba.ar
+54 (11) 528-50889