Modelado de la topologa de una red multicast:

Anlisis e implementacin

Guillermo Dalla Vecchia

Diego Corbo
Florencio Alonso

-20051

ndice
1 Introduccin .................................................................................................................... 3
2 Objetivos ......................................................................................................................... 3
3 Algoritmo de inferencia del rbol.................................................................................. 4
3.1 Criterio de Seleccin ................................................................................................ 5
3.2 rboles Binarios....................................................................................................... 8
3.3 Topologas de rbol Arbitrarias............................................................................... 8
3.4 Clculo de las Prdidas Hacia los Receptores.......................................................... 9
3.5 Condiciones de Borde y Patologas........................................................................ 11
4 Protocolos de Ruteo Multicast ...................................................................................... 11
5 Programas utilizados en la implementacin de la red y mediciones ............................ 14
5.1 VMWare Workstation (www.vmware.com) .......................................................... 15
5.2 VLC (VideoLAN Client, www.videolan.org)........................................................ 16
5.3 Demonios de Ruteo Descartados............................................................................ 17
5.4 XORP (eXtensible Open Router Platform, www.xorp.org)................................... 17
6 Configuracin de la Red Virtual ................................................................................... 18
7 Obtencin de los Nmeros de Secuencia de los Paquetes de Video............................. 20
8 Resultados Obtenidos.................................................................................................... 22
8.1 Red Real ................................................................................................................. 22
8.2 Red Simulada ......................................................................................................... 23
8.2.1 Proceso de reconstruccin del rbol de la red simulada .................................. 24
9 Conclusiones ................................................................................................................ 27
10 Referencias................................................................................................................... 28
11 Anexo 1: Programas de Matlab Realizados ................................................................. 29
12 Anexo 2: Archivo de configuracin utilizado para el router XORP............................ 35

1 Introduccin
El servicio de IP Multicast brinda una manera eficiente de enviar paquetes a
mltiples receptores. Un nico paquete transmitido por la fuente es recibido por un
nmero arbitrario de receptores a lo largo de un rbol de distribucin (en cuya cima se
encuentra el transmisor), mediante la replicacin de los paquetes en determinadas
interfaces de salida de los routers. En principio el servicio de IP Multicast brinda un
servicio de mejor esfuerzo, sin embargo existe un cierto nmero de aplicaciones como
actualizaciones de software, artculos de noticias, etc., que requieren transporte de
paquetes confiable. Para cumplir con este requerimiento se han desarrollado una serie de
protocolos de transporte sobre el servicio no confiable, de los cuales no entraremos en
detalle por carecer de inters para este trabajo.
Uno de los principales retos en el diseo de un protocolo de transporte multicast
confiable es su algoritmo de recuperacin frente a prdidas. Esto ha probado ser difcil de
escalar a un nmero grande de receptores, ya que los paquetes retransmitidos hacia cada
receptor terminan llegando a todos ellos, contaminando la red con una mayora de
paquetes intiles. Para solucionar este problema se han propuesto una serie de ideas que
intentan restringir el alcance del trfico de recuperacin de errores (retransmisiones), a un
mbito local. La idea principal detrs de la recuperacin local es identificar a los grupos
de receptores que compartan patrones de prdida similares, para luego confinar la
recuperacin de errores a estos grupos sin perturbar el resto del rbol. Esencialmente se
requiere que cada receptor descubra a que grupo pertenece y despus busque dentro de
este grupo a los candidatos que puedan retransmitirle el paquete faltante.

2 Objetivos
El objetivo de este trabajo es implementar un algoritmo para obtener una buena
aproximacin de la topologa del rbol de distribucin multicast. Esto se llevar a cabo
estrictamente usando medidas realizadas en las puntas del rbol a las que se tiene acceso
a partir de estadsticas de prdidas realizadas en cada receptor.
Para tal fin, nos basamos en lo expuesto en [1], donde se propone un algoritmo
de inferencia de rbol a partir de medidas multicast. Es importante observar que el
medio ms corto para determinar caminos a travs de Internet es utilizar el comando
traceroute, el mismo es equivalente a enviar n+1 paquetes unicast de eco (ping) a cada
receptor variando el campo ttl, donde n es la cantidad de routers entre la fuente y el
receptor. Por lo tanto si tenemos m receptores, teniendo en cuenta que el comando ping
transfiere dos paquetes (ida y vuelta), estamos inundando la red con 2(n+1)m paquetes, lo
cual puede ser muy perjudicial al trabajar a gran escala en redes con un nmero alto de
receptores. Debido a lo antes mencionado se recurre a enviar paquetes multicast, que por
su naturaleza hacen un uso ms eficiente de la red. (Ver [2]).
Para implementar el algoritmo, nos propusimos trabajar sobre una red fsica real
de modo de enfrentarnos a los pormenores de las mediciones reales, as como tambin
para aprender a configurar una red multicast y trabajar con un flujo real de informacin,
en contraposicin a trabajar con una red simulada. Como no disponamos de una red

fsica real del tamao mnimo indispensable para probar el algoritmo (unas siete
mquinas), optamos por la alternativa de utilizar una red virtual. En esta, si bien no hay
mquinas fsicas, interfaces de red, ni cables que conectar, a todos los otros efectos la
situacin es idntica a la de una red real, necesitndose para ella la instalacin y
configuracin de sistemas operativos, routers multicast, servidores y receptores de video
multicast, capturadores y procesadores de trfico, etc., lo cual se detallar ms adelante.

3 Algoritmo de Inferencia del rbol

Los paquetes multicast fluyen a lo largo de un rbol de distribucin con raz en el
transmisor. Los receptores se encuentran en las puntas del rbol, los enrutadores son los
nodos internos del rbol y los enlaces conectan entre si a los nodos con el transmisor y
los receptores. Un paquete que se pierde en cualquiera de los enlaces del rbol de
distribucin, se pierde para todos los receptores pertenecientes al sub rbol con raz en
ese enlace. El transporte de paquetes estructurado en forma de rbol introduce
correlaciones entre las prdidas de paquetes vistas por distintos receptores. Esta
correlacin entre receptores puede ser explotada para inferir la topologa del rbol que
caus los patrones de prdida observados.

Fig. 1: rbol bsico

El algoritmo reconstruye una representacin lgica del rbol multicast, en la
cual cada nodo interior es simplemente el ancestro comn ms cercano de todos los
receptores por debajo de l en el rbol. En realidad cada rama del rbol lgico podra ser
un conjunto de enlaces. Para reconstruir la topologa exacta del rbol tendra que contarse
con acceso a todos los enrutadores intermedios a lo largo del camino, sin embargo eso
por lo general no es posible, por lo que un rbol lgico es lo mejor que puede obtenerse
con medidas realizadas desde los receptores. Empero, el conocimiento del rbol lgico es
suficiente para determinar grupos de prdidas similares, dado que todos los receptores
que se encuentren por debajo de una cierta rama del rbol lgico vern las mismas

caractersticas del camino (como ancho de banda de los cuellos de botella y tasas de
prdidas).
El algoritmo de inferencia de rbol intenta reconstruirlo desde los receptores hacia
la fuente, usando informacin de los patrones de prdida en los primeros. Receptores que
tengan patrones de prdida similares, son agregados y representados por un nico nodo
un nivel por arriba del anterior. El nodo agregado puede ser visto a partir de ese momento
como un nico nodo para posteriores agregaciones. El rbol entero ha sido reconstruido
cuando todos los receptores han sido agregados en un nico nodo.
La aplicacin de las tcnicas de agregacin descritas anteriormente requiere el
conocimiento de dos factores: un criterio de seleccin que sea indicativo de cuan cerca se
encuentran los receptores entre s en el rbol, y segundo la necesidad de conocer cuantos
receptores sern agregados juntos en un nico macro nodo representativo en cada paso
del proceso de construccin del rbol.

3.1 Criterio de Seleccin

Se asocia con cada receptor X, un patrn de prdida Lx que es una lista ordenada
de los nmeros de secuencia de los paquetes perdidos por el receptor X. En un rbol,
cualquier par de receptores A y B ven las prdidas descritas por sus patrones La y Lb
respectivamente. Estos patrones podran tener potencialmente un cierto nmero de
prdidas en comn, se llama a estas prdidas comunes prdidas compartidas entre los
receptores A y B.
Criterio de Seleccin: Prdidas Compartidas
A primera vista las prdidas compartidas entre un par de receptores parecera ser
un indicador ideal de cuan cerca se encuentran los receptores en el rbol. Esto podra no
ser tan as, vase por ejemplo la figura 2 y considrese el caso en que el enlace R2-A tiene
una alta tasa de prdida. En ese caso A podra tener un alto nmero de prdidas en comn
con cualquier otro receptor. En particular si el enlace R1-R2 tiene una baja tasa de
prdida, es posible que las prdidas compartidas entre A y C excedan las de A y B, lo que
podra resultar en una agregacin incorrecta. La falla en el uso de prdidas compartidas
como criterio de seleccin es fcilmente entendible si se tiene en cuenta la manera en la
que ellas se producen.
Las prdidas compartidas se producen de dos maneras. Un par de receptores A y
B comparten el camino desde la raz hasta su ancestro comn ms cercano. Cualquier
paquete perdido a lo largo de este camino compartido, aparecer en el patrn de prdidas
de A y B. stas prdidas son causadas por la estructura del rbol y son verdaderamente
indicativas de la estructura del rbol subyacente. Se le llaman a este tipo de prdidas
prdidas compartidas verdaderas. Adems de las prdidas compartidas verdaderas,
cada patrn de prdida de cada receptor, incluir tambin los paquetes que se perdieron a
lo largo de caminos separados desde el ancestro comn ms cercano a cada receptor. Es
posible que dos copias del mismo paquete sea perdido independientemente a lo largo de

Fig. 2: Criterio de Seleccin

Caminos distintos, se le llaman a este tipo de prdidas prdidas compartidas falsas. Es
gracias a este tipo de prdidas que se pueden producir los errores de agregacin.
Criterio de Seleccin: Prdidas Compartidas Verdaderas
Cuanto mayor es el camino compartido entre dos pares de receptores, mayor es la
probabilidad de las prdidas compartidas verdaderas. Por lo tanto la probabilidad de ver
prdidas compartidas verdaderas entre un par de receptores, es una buena medida de cuan
cercanos se encuentran en el rbol y se usa esta probabilidad como criterio de seleccin
para identificar el par de receptores a agregar.
En el receptor no hay nada que distinga una prdida compartida verdadera de una
falsa. Para permitir al receptor estimar el nmero aproximado de prdidas compartidas
verdaderas desde el total del patrn de prdidas, se aplica el siguiente modelo:
A y B son receptores arbitrarios del conjunto de todos los receptores con patrones
de prdida La y Lb respectivamente. Sea n el nmero total de paquetes
transmitidos desde la fuente.
A y B comparten una parte del camino desde la fuente. Sea Ptab la probabilidad de
ver prdidas a lo largo de este camino.
Cualquier prdida vista por el receptor A pero no por el B ocurre a lo largo del
camino entre el ancestro comn ms cercano de A y B hacia A. Sea Pa la
probabilidad de prdida en este camino. Se define anlogamente Pb para el
receptor B.

El modelo anterior se representa en la siguiente figura:

Fig. 3: Modelo de Prdida

Usando el modelo anterior es posible deducir las siguientes ecuaciones:

Sea Pab la probabilidad de ver una prdida compartida (verdadera o falsa) entre A
y B. Entonces:
Pab = Pabt + (1 Pabt ) Pa Pb

Donde el primer termino del lado de la derecha es la probabilidad de ver prdidas

compartidas verdaderas. El segundo trmino es la probabilidad de ver prdidas
compartidas falsas.

Sea Pab la probabilidad de ver una prdida en A pero no en B. Entonces

Pab = (1 Pabt ) Pa (1 Pb )

Anlogamente se define Pa b .
Resolviendo las ecuaciones anterior para Ptab se llega a:
Pabt =

Pab Pba + Pba Pab + Pab Pab + Pab2 Pab

Pab + Pba + Pab 1

Sea Lab=La Lb el nmero de prdidas compartidas medidas entre A y B. Se

aproxima Pab como Lab/n (anlogamente para el resto de las probabilidades). A

medida que n crece, estas aproximaciones deberan converger al valor verdadero
de las probabilidades antes definidas.

3.2 rboles Binarios

Un rbol binario es uno en el cual todo nodo interior del rbol tiene a lo sumo dos
hijos. A medida que se van agregando pares de receptores en cada paso, el algoritmo
reconstruye un rbol binario lgico en el que cada nodo interior tiene exactamente dos
descendientes.
Usando el criterio de seleccin definido anteriormente, el algoritmo queda de la
siguiente manera:
Entrada: Un conjunto de receptores S={1,,N] con patrones de prdida L1Ln.
1. Se calcula la probabilidad de ver prdidas compartidas verdaderas entre todos los
pares de receptores del conjunto S.
2. El par de receptores A y B, con la mxima probabilidad de ver prdidas
compartidas verdaderas son combinados juntos en un nico nodo (AB). Sea
L(AB)=La Lb el nuevo patrn de prdida, y reemplcese A y B por (AB) en S.
3. Repetir los pasos anteriores, hasta que todos los receptores en S hayan sido
agregados en un nico macro nodo que represente todo el rbol.

3.3 Topologas de rbol Arbitrarias

En el rbol binario reconstruido en la seccin anterior, cada nodo interior tiene
exactamente dos interfaces de salida, por lo tanto el par de nodos agregado en un paso
determinado siempre termina siendo representado por el nodo padre en el rbol. En una
topologa arbitraria los nodos interiores tienen dos o ms interfaces de salida. Esto podra
provocar que hubiera dos o ms receptores con patrones de prdida iguales (o muy
similares al menos), por lo que seguir con la estrategia de agrupacin por pares podra
arrojar resultados errneos. En la siguiente figura se ilustra el concepto:

Fig. 4: Posibles casos de agregacin entre tres receptores.

Las dos alternativas mostradas son agrupar los tres receptores en un nico macro
nodo, o agrupar primeramente dos de ellos, y luego agrupar el resultado con el restante.
8

La habilidad para distinguir entre estos dos casos, se desprende de la observacin

de que en el caso 1, la probabilidad de ver prdidas compartidas verdaderas entre A y B
debera en circunstancias ideales, igualar la probabilidad de verlas entre el macro nodo
(AB) y el C (Pt(ab)c=Ptab). En el caso 2, la probabilidad Ptab ser mayor que Pt(ab)c, porque
A y B comparten un enlace adicional no compartido por C. Este enlace adicional aporta a
las prdidas compartidas verdaderas entre A y B, por lo cual Ptab> Pt(ab)c. Se podra
distinguir entre los dos casos de subrboles realizando la siguiente comprobacin:

Si Ptab= Pt(ab)c entonces los nodos son agregados como en el caso 1, de otra manera
se agregan como en el caso 2.

En realidad dado que se usan prdidas medidas para aproximar las probabilidades
Pab , Pab , Pba , el criterio de igualdad para el caso 1 es demasiado rgido. Un cumplimiento
estricto de la regla expuesta anteriormente resultara en agregaciones incorrectas. Para
tener en cuenta una cierta variacin, se define el margen de error y se modifica la regla
anterior de la siguiente manera:

Si Pt(ab)c est dentro de % de Ptab, entonces los nodos son agregados como en el
caso 1, de otra manera se lo hace como en el caso 2.

Esta regla de decisin podra resultar en agregaciones incorrectas hechas para

subrboles como en el caso 2, si las prdidas compartidas verdaderas adicionales entre A
y B son responsables de menos de % de la probabilidad de ver prdidas compartidas
verdaderas entre A y B. Como ser tpicamente pequeo, tales errores solo ocurrirn si
la tasa de prdida a lo largo de un enlace compartido es muy baja. Como el propsito de
estas agregaciones es identificar nodos que puedan ser agrupados juntos para el propsito
de recuperacin frente a errores locales, tales agregaciones aunque no sean exactas son
aceptables, porque los enlaces problemticos que causan las prdidas se encuentran aguas
arriba y son compartidos por el receptor C.

3.4 Clculo de las Prdidas Hacia los Receptores

Notamos que el algoritmo de inferencia del rbol, obtiene para cada nodo una
estimacin de las prdidas aportadas por las conexiones por encima de su nodo directo
superior (dadas por Ptab), y que se puede obtener una estimacin de las prdidas totales
hacia un receptor como #L/n (o sea, paquetes perdidos sobre paquetes enviados por la
fuente). Por lo tanto parece lgico pensar que con estos datos se pueda obtener mediante
un clculo sencillo los porcentajes de prdida en cada enlace.
Esto se lograra mediante el siguiente desarrollo:
Como se indica en la figura 5, para calcular las prdidas en el enlace desde el
receptor a hacia el nodo directamente superior, se considera a todos los otros receptores
conectados al mismo nodo como un solo receptor b. Lo que nos interesa conocer es Pa.

Fig. 5: Para calcular Pa, consideramos el resto de sus compaeros de nodo como
uno solo (b).
Siendo entonces que conocemos una estimacin de Ptab, dada por las prdidas
compartidas reales entre a y b (tomamos la mnima entre todos los receptores del mismo
nivel, que ser la ms prxima a la realidad), el problema se reduce a calcular Pa en
funcin de Ptab y las prdidas totales hacia a, Ptota, estimadas por las prdidas totales de a
divididas por la cantidad de paquetes enviados.
La probabilidad de que un paquete llegue hacia a es:

(1 Patot ) = (1 Pabt )(1 Pa )

De aqu se deduce que:
Pa =

Patot Pabt
1 Pabt

Este clculo sin embargo no funciona cuando a, en vez de ser un receptor real, es
un macro nodo del modelo de rbol determinado por el algoritmo de inferencia. Esto se
debe a que dichos macro nodos tienen asignadas las prdidas conjuntas totales de los
receptores hijos debajo de ellos, y no las prdidas conjuntas reales, por lo tanto en esos
casos el Pa calculado no es vlido.
Se utiliz este clculo en las rutinas utilizadas y se verific esto ltimo. Las
prdidas calculadas fueron muy precisas para la ltima rama de cada nodo, pero
invlidas para las ramas que terminan en routers como se esperaba.
Para calcular las prdidas en los routers, lo que se hace es tomar la mnima Ptab de
sus nodos hijos, que ser la probabilidad de prdidas totales desde ese router hasta la
fuente. Como el rbol se construye de abajo hacia arriba hay que esperar a calcular las
prdidas de los tramos superiores, para luego calcular las subsiguientes por diferencias.

10

Esto se ejemplifica mejor en el anlisis de la red simulada. En cualquier caso, los

resultados obtenidos mediante este procedimiento fueron muy buenos.

3.5 Condiciones de Borde y Patologas

Algunos detalles que hubo que tener en cuenta en la solucin del problema (varios
de los cuales recin los reconocimos en la prctica) fueron los siguientes:

Los nmeros de secuencia de los paquetes multicast podran tener saltos e

incluso repetirse (debido al reuso que se hace de los mismos en los
protocolos de transporte usados).
Si tenemos bajas prdidas hacia los routers y altas hacia los receptores, el
enfoque estadstico comienza a fallar (ver anlisis de la red simulada)
Cuando dos receptores no tienen segmento en comn y por lo tanto
carecen de prdidas compartidas reales, igualmente vamos a calcular una
pequea Ptab ya que solo podemos tener estimadores de esta cantidad (que
incluso pueden llegar a dar pequeos valores negativos cuando no hay
correlacin real entre dos receptores) y no el valor verdadero. Por lo tanto
hay que tener en cuenta en el algoritmo, que no siempre hay que unir los
dos receptores con mayor correlacin, sino que hay que exigir un mnimo
de Ptab para combinar dos o ms nodos. Si se llega a una situacin en que
ningn par de nodos y/o macronodos tienen un Ptab que supere un mnimo
preestablecido (por ej. 1%), entonces finalizamos la integracin del rbol y
asumimos que todos los nodos y macronodos obtenidos hasta el momento,
se conectan independientemente al servidor.

4 Protocolos de Ruteo Multicast

El ruteo de paquetes multicast no es algo tan simple como lo puede ser el ruteo de
paquetes unicast mediante un ruteo esttico o dinmico, sobre todo debido a la
complejidad que agregan los protocolos de transmisin del tipo multicast. Existen
mltiples esquemas de ruteo de este tipo, hoy en da los ms usados son los que
implementan los protocolos PIM-DM, y PIM-SM (ver [5]).
En todos los protocolos de ruteo multicast se parte de la premisa de que existe una
ruta viable (unicast) que permita hacer llegar los datagramas de los emisores a los
receptores.
El problema del ruteo multicast es en cierto modo inverso al que se planteaba en
el ruteo unicast. En el caso unicast la interfaz de salida se decida en funcin de la
direccin de destino. En el ruteo multicast la interfaz de salida se elige en funcin tanto
de la direccin de destino como de la direccin de origen.
Una vez que el router sabe (por IGMP, ver [3]) en que grupos multicast estn
interesados los hosts de su LAN, debe ponerse de acuerdo con los dems routers para

11

conseguir que dichos paquetes le lleguen desde cualquier sitio donde se estn
produciendo.
El principal problema del ruteo multicast es el descubrimiento mutuo de emisores
y receptores. Existen dos estrategias bsicas para esto:

Modo denso: Consiste en difundir los datagramas multicast por toda la red y
esperar a que los routers que no los deseen lo indiquen explcitamente. Este
proceso se conoce como podado del rbol y se realiza mediante mensajes
prune (prune: podar en ingls).
Modo disperso: Consiste en difundir la informacin nicamente a los routers que
previamente la han solicitado. Los routers que deseen adherirse al grupo deben
indicarlo mediante una peticin explcita (mensajes Join).

El modo denso presupone que la mayora de los routers de la red estn interesados
en la emisin en curso. Es adecuado para redes pequeas con una gran capacidad
sobrante, pero no para grandes redes como es el caso de Internet o cuando el ancho de
banda es reducido. No es escalable a redes con muchos routers o con muchos grupos
multicast, pues requiere que cada router mantenga informacin de estado sobre las
emisiones que no quiere recibir.
El modo denso es el ms sencillo de implementar; fue el primero que se utiliz en
Internet y el primero que se estandariz.
El modo disperso requiere que los emisores y receptores indiquen de forma
explcita su deseo, ya que en caso contrario no se les difunde ningn datagrama multicast.
El modo disperso es el ms utilizado actualmente, pues los routers solo han de
mantener informacin de estado cuando realmente deba pasar por ellos trfico multicast,
lo cual se considera que ser en general el caso minoritario.
El protocolo DVMRP (ver [4]), es el protocolo multicast ms antiguo y ms
conocido. Existen implementaciones de DVMRP para muchos routers, y programas que
permiten convertir un host en un router DVMRP. Por ejemplo el programa mrouted es
una implementacin de DVMRP que ha sido adaptada para muchas versiones de UNIX
(Linux, FreeBSD, SunOS, SGI y HP entre otras).
DVMRP ha sido el protocolo multicast mayoritario en MBone (backbone
multicast de Internet), hasta que en 1999-2000 se inici una migracin hacia otros
protocolos ms modernos, fundamentalmente PIM-SM.
DVMRP est diseado a imagen y semejanza de RIP, el tradicional protocolo de
ruteo unicast y adolece de sus mismos problemas, por lo que no debera utilizarse en una
red grande o en produccin. Se encuentra basado en el algoritmo de vector distancia, y a
diferencia de todos los otros protocolos de ruteo multicast construye sus propias rutas
unicast de forma independiente al protocolo de ruteo unicast utilizado, repitiendo por
tanto el trabajo de ste. Su mtrica es nicamente nmero de saltos (como en RIP) y el
valor mximo permitido es de 32. No es posible por tanto crear una red DVMRP en la
que dos routers estn a ms de 32 saltos de distancia. Esto no suele ser un problema ya
que DVMRP permite hacer uso de tneles, con lo que siempre es posible reducir el
nmero de saltos.
La principal diferencia entre DVMRP y PIM-DM es que este ltimo no incluye
un algoritmo para la localizacin de las rutas ptimas hacia los emisores, sino que delega

12

esta tarea en el protocolo de ruteo unicast, cualquiera que este sea (de ah lo de Protocol
Independent). As PIM-DM puede funcionar en combinacin con OSPF. IS-IS, EIGRP,
etc. Incluso es posible utilizar PIM-DM en una red que emplee rutas estticas
nicamente. En realidad DVMRP tambin era independiente del protocolo, ya que
aunque se basa en el algoritmo del vector distancia, realiza su propio clculo de rutas
unicast, no basndose para nada en la informacin suministrada por el protocolo de ruteo
unicast cualquiera que este sea.
Por lo dems el funcionamiento de PIM-DM es bastante similar al de DVMRP.
La informacin se difunde inicialmente a todos los routers de la red por inundacin,
siendo stos los encargados de solicitar el podado (comando prune) si lo desean, y el
posterior injerto (comando graft), si ms tarde desean recibir de nuevo la emisin. La
nica diferencia entre PIM-DM y DVMRP, estriba en la inundacin inicial: mientras que
DVMRP sigue el rbol broadcast truncado, que permite una distribucin ptima en la red
llegando a todos los routers con un nmero mnimo de envos, PIM-DM utiliza
inundacin con lo que se realizan algunos envos innecesarios. Para evitar la creacin de
bucles PIM-DM utiliza la tcnica del encaminamiento por el camino inverso o RPF
check. El RPF check es un mecanismo de seguridad para evitar en lo posible la creacin
de bucles. Su funcionamiento es el siguiente: cuando un router recibe un paquete, obtiene
la direccin de origen del mismo y analiza si la interfaz por la que lo ha recibido,
coincide con la interfaz que el propio router tiene identificada como la de la ruta ptima
hacia ese destino. Si la comprobacin es satisfactoria el paquete se acepta y se
redistribuye por inundacin. Por el contrario si la comprobacin falla, es decir si el
paquete no lleg por la ruta ptima hacia su direccin de origen, el paquete es descartado
por sospecharse que se pueda tratar de un duplicado.
A continuacin se presentan las principales diferencias (algunas ya mencionadas)
entre los protocolos PIM-DM, y DVMRP:

DVMRP repite el trabajo del protocolo unicast; PIM-DM se aprovecha del

existente.
DVMRP tiene un lmite de 32 saltos. PIM-DM no tiene lmite.
PIM-DM se basa completamente en el RPF check para la supresin de bucles.
PIM-DM es algo mejor y ms escalable que DVMRP, pero an as no es apto para
grandes redes por la gran cantidad de trfico y de informacin de estado.

Sin embargo el modo denso tampoco es satisfactorio, sus principales problemas son:

Cada router de la red ha de mantener:

La topologa del SPT (la relacin de las ramas que cuelgan de l en el
rbol). Para cada red emisora y cada grupo hay un rbol diferente.
La relacin de las ramas que han sido podadas para cada emisor y cada
grupo (cada par (S,G), Source, Group).
La gran cantidad de informacin de estado hace difcil establecer un servicio
multicast en una red grande para un nmero elevado de emisores y grupos.
Para construir el SPT inicial se procede por inundacin. Para adaptarse a cambios
en la red el proceso se repite cada 2-3 minutos, lo cual genera mucho trfico.

13

La solucin a los problemas antes mencionados fue el modo disperso, cuyas

principales caractersticas son:

Se basa para construir rboles en la tabla de ruteo unicast. Puede usar OSPF, ISIS, EIGRP, etc., incluso rutas estticas.
Al funcionar en modo disperso no se hace inundacin de la informacin.
Problema: como localizamos a los emisores.
Solucin: establecemos un punto de encuentro donde los emisores se registren y
los receptores vayan a preguntar. El punto de encuentro es un router que
denominamos Rendezvous Point.
Es el ms complejo de los protocolos de ruteo multicast en uso actualmente.
Debido a su flexibilidad y escalabilidad PIM-SM es el protocolo que tiene ms
futuro en Internet. MBone est evolucionando hacia PIM-SM.

No vale la pena hacer aqu una descripcin detallada del funcionamiento de este
protocolo (ver [5]).
Los principales problemas que tiene el trfico multicast son los siguientes:

Firewalls: no permiten el paso de paquetes multicast.

Rutas asimtricas: falla el RPF check y el multicast no funciona.
Routers que no soportan o no tienen configurado el ruteo multicast.
Ataques de virus. Los mensajes join y prune de PIM-SM cargan mucho los
routers.

La solucin a los tres primeros problemas es la creacin de tneles para que el

cortafuegos, los routers de la ruta asimtrica, o el router sin soporte multicast vean
solo paquetes unicast.

5 Programas utilizados en la implementacin de la red

y mediciones
Si bien el principal objetivo de nuestro trabajo fue implementar el algoritmo de
inferencia de rbol multicast; adems fue necesario armar una red de difusin multicast
en tres niveles, configurar routers multicast, simular prdidas en los enlaces durante una
transmisin de video, capturar y procesar los paquetes recibidos por cada Terminal, etc.
Esta puesta a punto nos costo la mayor parte del tiempo de trabajo, y por lo tanto,
consideramos pertinente explicarla, adems de profundizar en los experimentos
realizados. Ahondaremos en ciertos detalles que nos resultaron difciles de resolver para
que el lector interesado en realizar futuras experiencias, no se tope con los mismos
problemas.

14

5.1 VMWare Workstation (www.vmware.com)

En principio necesitamos conseguir siete mquinas para formar una red LAN.
Para nosotros no era fcil disponer de dicha cantidad de mquinas, sobre todo porque son
bastante caras y tampoco podamos pedirlas prestadas del laboratorio de nuestra facultad,
por un tema de disponibilidad de las mismas. Por lo tanto la solucin ms prctica a este
problema fue realizar una red de mquinas virtuales. Es relevante aclarar para los lectores
no familiarizados con este trmino, que al hablar de mquinas virtuales no nos referimos
a una simulacin por software, se trata de siete o ms sistemas operativos y sus
aplicaciones corriendo en paralelo, alojados sobre una nica mquina. Esto se puede
realizar gracias a la versin beta (que es gratuita por ser de prueba) de un potente
software llamado VMWare Workstation, cuyo funcionamiento bsico se describe a
continuacin.
Como ya mencionamos antes el Workstation permite correr mltiples sistemas
operativos y sus aplicaciones simultneamente sobre una nica mquina. Cada sistema
operativo instalado es aislado en lo que se llama una mquina virtual. Todas las mquinas
virtuales trabajan sobre una capa de virtualizacin, cuya funcin es mapear los recursos
de hardware de la mquina real hacia los recursos de hardware asignados a las mquinas
virtuales, logrando as que cada mquina virtual tenga su propia CPU, memoria, discos,
dispositivos de entrada y salida, etc. El esquema a continuacin, muestra la estructura en
capas que crea el software para el funcionamiento de las mquinas virtuales:

Fig. 6: Modelo de capas que utiliza Workstation

El Workstation adems nos permite asignar a cada mquina virtual tarjetas de red
(hasta un mximo de tres), realizar el cableado virtual entre las distintas tarjetas de red y
asignarle cierta probabilidad de prdida al bus de cada subred LAN virtual. Sobre este

15

punto vale aclarar que el disponer de tan solo tres tarjetas de red por cada mquina,
result ser una limitante importante en los tipos de topologas que podamos implementar
para la realizacin de nuestras pruebas.
Otra ventaja significativa del Workstation, es que permite clonar mquinas
virtuales ya existentes, o sea que a partir de una nica mquina virtual es posible crear
copias idnticas diferenciales en las que solo se guardan las diferencias con la mquina
base (en la configuracin del kernel, en las distintas aplicaciones instaladas y en dems
cambios). Esto implica un ahorro de espacio en disco y en el tiempo de instalacin,
considerables.

5.2 VLC (VideoLAN Client, www.videolan.org)

En nuestro proyecto de fin de carrera estamos utilizando un software de streaming
de video llamado VLC, que puede trabajar tanto de servidor como de cliente, y tiene la
capacidad de realizar IP multicast (tanto de servidor como de reproductor).
Aprovechando el conocimiento que tenemos sobre dicho software y de que se trabaj con
un trfico multicast real y no simulado, es que usamos este software para la realizacin de
nuestras pruebas.
El VideoLAN es una solucin de software para el streaming de video, que fue
creada por estudiantes del Ecole Centra de Paris (Francia) y bajo la licencia GNU puede
ser desarrollado por todas las personas del mundo que deseen o necesiten hacerlo. Video
LAN presenta 2 tipos de soluciones:
1. VLS (VideoLAN servidor): En teora es capaz de hacer el stream de archivos
MPEG-1, MPEG-2 y MPEG-4 (ubicados en cualquier disco rgido o
removible accesible), DVDs, canales digitales satelitales y canales digitales de
televisin terrestre (que sean obtenidos por tarjetas DVB-S o DVB-T) y
videos en vivo sobre redes (que sean obtenidos por una tarjeta de codificacin
MPEG). Trabaja bajo Linux o Windows.
2. VLC (VideoLAN cliente): ste puede utilizarse al igual que el VLS como
servidor para hacer el stream de archivos MPEG-1, MPEG-2 y MPEG-4,
DVDs y videos en vivo sobre redes (Notar que comparado con el servidor,
solo le faltan las posibilidades de streaming de canales digitales de satlite y
canales de televisin terrestre digital). Tambin puede ser usado como cliente
para recibir, decodificar y mostrar streams de MPEG bajo mltiples sistemas
operativos (Linux, Windows, Mac OS X, BeOS, *BSD, Solaris, Familiar
Linux, Yopy/Linupy y QNX).
Ambas soluciones en su funcin de servidor envan el stream hacia una IP unicast
o multicast soportando tanto IPv4 como IPv6.
El VLC tiene casi todas las funcionalidades del VLS y ha sido ms desarrollado
en general, fue creciendo rpidamente en popularidad teniendo muchos desarrolladores
en todo el mundo lo que implica mayor informacin disponible y soporte, adems de
tener la ventaja de ser reproductor y servidor al mismo tiempo.

16

Luego de instalar el software en cada mquina virtual de las puntas de nuestra red,
solo se necesit saber como enviar el stream desde la fuente y como recibirlo en cada
destino.

5.3 Demonios de Ruteo Descartados

En el transcurso de nuestro trabajo insumimos una gran cantidad de tiempo en la
bsqueda de demonios ruteo multicast para Linux. Se analizaron y descartaron los
siguientes programas: smc-route, mrouted, y pimd.
Smc-route
Este sencillo demonio le permite a un enrutador Linux unicast rutear paquetes
multicast definiendo rutas estticas. El inconveniente que tiene es que no toma en cuenta
al protocolo IGMP, por lo que el trfico llega a todas las subredes configuradas en la
tabla esttica independientemente de si existe alguna aplicacin interesada en la
informacin, provocando que no escale a redes grandes.
Mrouted
Este demonio implementa DVMRP que fue explicado en la seccin anterior, sus
aspectos en contra son los ya mencionados para este protocolo.
Pimd
El pimd es un demonio para Linux que implementa los protocolos PIM-DM y
PIM-SM, lamentablemente no pudimos probarlo ya que lo nico que pudimos encontrar
en Internet fue el cdigo fuente para compilar, el cual haba sido actualizado por ltima
vez en el ao 2003 y ni siquiera fue posible compilarlo con las versiones ms nuevas del
compilador gcc (compilador C bajo la licencia GNU) que tenamos disponibles.

5.4 XORP (eXtensible Open Router Platform, www.xorp.org)

Finalmente luego de una larga bsqueda descubrimos el XORP, que tiene como
propsito ser un software de plataforma de router de cdigo abierto, que sea estable y lo
suficientemente completo para su uso en produccin. Para este propsito XORP
implementa protocolos de ruteo unicast y multicast tanto para IPv4, como para IPv6 con
una unificada forma de configurarlos a travs de un archivo de configuracin estndar
(aunque si se desea es posible usarlo mediante lnea de comandos).
Una de las principales ventajas del XORP es que es gratuito y esta cubierto bajo
la licencia pblica BSD, que permite el desarrollo y uso pblico por toda aquella persona
que as lo desee.
El XORP fue desarrollado por el International Computer Science Institute en
Berkeley, California, pero tambin cuenta con la contribucin adicional proveniente de
programadores de todas partes del mundo.

17

Inicialmente descargamos, compilamos, e instalamos la versin 1.0 disponible

para bajar en la pgina web del programa, pero encontramos que esta versin tena
problemas en la implementacin del protocolo PIM-SM que lo hacan intil para nuestros
propsitos. Luego de preguntar en la lista de correo correspondiente del programa acerca
del tema, se nos inform que el problema haba sido arreglado en la versin en desarrollo
disponible a travs de CVS (Concurrent Versions System), por lo que el siguiente paso
fue instalar el CVS en Linux y configurarlo para nuestro propsito, para esto se debe
configurar la variable de entorno CVSROOT lo que se logro con las siguientes lneas de
comando:
CVSROOT=:pserver:xorpcvs@cvs.xorp.org:/cvs
export CVSROOT
Por ltimo para descargar el cdigo fuente desde el CVS se deben ejecutar las
siguientes lneas de comando:
cvs login
cvs checkout xorp
Luego de haber compilado e instalado el XORP (de la manera usual en Linux) en
las mquinas virtuales que trabajaran como routers, se modific el archivo de
configuracin segn nuestras necesidades (en el anexo 2 se incluye el archivo de
configuracin utilizado) para que realizara el ruteo multicast basado en el protocolo PIMSM (ver [5]). La forma de poner en funcionamiento el router es escribir en la lnea de
comandos:
/usr/local/xorp/bin/xorp_rtrmgr b config.boot

6 Configuracin de la Red Virtual

La mquina fsica utilizada fue un AMD Athlon XP 1800, con 512mb de memoria
RAM.
A continuacin de la instalacin del Workstation, creamos una mquina virtual
asignando los recursos de hardware necesarios (64mb de RAM, interfaces Ethernet, etc.),
luego procedimos a instalar el sistema operativo (en nuestro caso, elegimos trabajar con
Mandrake Linux 10, ya que cuenta con el kernel 2.6 nativo), el XORP, el VLC, y el
TcpDump (para realizar la captura de los paquetes), adicionalmente se requiere tener
habilitadas a nivel del Kernel de Linux las siguientes opciones a efectos de que el ruteo
multicast pueda funcionar:

IP: multicasting.
IP: forwarding/gatewaying.
IP: multicast routing.
IP: tunneling.
PIM-SM.

18

A partir de la mquina virtual descrita anteriormente, creamos 6 clones de la

misma. Inmediatamente despus de tenerlos operativos configuramos nuestra red virtual,
asignando las tarjetas de red y creando los enlaces necesarios para armar la siguiente
topologa:

Fig. 7: Topologa de la red virtual con los porcentajes de prdida usados.

Cabe aclarar que lo que se muestra como un enlace es en realidad el bus de una
LAN (es decir que podran colocarse mquinas adicionales si as se deseara), en donde el
Workstation permite configurar las probabilidades de prdida en cada uno. En una red
real estas prdidas se generan a causa de las colas que se producen en los enrutadores por
lo que los porcentajes no seran estticos, sin embargo a los efectos de inferir el rbol de
prdidas fue suficiente.
El siguiente paso fue configurar las interfaces de red y crear las tablas de ruteo
esttico. En un principio editamos los archivos de configuracin que Linux tiene a tales
efectos para cargar la configuracin en el arranque luego de un reset, pero algunos
problemas que tuvimos nos llevo a configurar las interfaces y las tablas de ruteo con los
comandos ifconfig y route agregando las lneas correspondiente al archivo /etc/rc.local
(configuracin local del sistema), de manera que se cargaran al inicio ya que de haberlo
hecho solamente desde lnea de comando se hubieran borrado luego de reiniciar el
sistema.
Las interfaces y tablas de ruteo se configuraron con la siguiente sintaxis (ver [7]):
ifconfig <Nombre de la interfaz> <IP asignada a la interfaz>
broadcast <Direccin IP de broadcast de la subred> netmask
<Mscara de subred>
route add net <Direccin IP de red> netmask <Mscara de
subred> <Nombre de la interfaz de salida>
A continuacin hicimos la prueba de enviar paquetes de eco (ping) entre las
mquinas, para corroborar el correcto funcionamiento y corregir posibles errores de
ruteo. As vimos que los ping entre mquinas de la misma subred respondan sin

19

problemas, aunque no los de mquinas localizadas en otras subredes a pesar de estar los
gateways correctamente configurados. Lo que nos estaba faltando era habilitar el
forwarding de los paquetes entre interfaces a nivel del Kernel de Linux, lo que se hizo
con la siguiente lnea de comando:
echo 1 > /proc/sys/net/ipv4/ip_forward
Para asegurarnos de que esta lnea se ejecutara al iniciarse el sistema tambin la
colocamos en el ya mencionado archivo /etc/rc.local.

7 Obtencin de los Nmeros de Secuencia de los Paquetes de

Video
El algoritmo implementado necesita el conocimiento previo de los patrones de
prdida de paquetes multicast en cada receptor, estos patrones de prdida son
bsicamente vectores compuestos por los nmeros de secuencia de los paquetes que
lograron efectivamente arribar a ellos.
Para el envo del stream de video se utiliz el protocolo RTP (Real Time Protocol,
ver [6]), que entre otras cosas provee a los paquetes UDP de secuenciamiento para
descartar paquetes que lleguen fuera de orden.
La metodologa para la obtencin de los susodichos nmeros de secuencia fue la
siguiente:
1. Ejecutar en una consola de Linux de cada receptor el VLC como cliente, de
manera que este se asocie a una de las interfaces del router multicast ms cercano
provocando que los paquetes lleguen al receptor. Esto se logr con la siguiente
lnea de comandos:
vlc udp:@ <IP del grupo multicast> --noaudio --novideo
Nota: se ejecut el VLC con los modificadores noaudio y novideo porque lo nico que necesitbamos era
que los paquetes de video llegaran a los receptores.

2. Ejecutar al mismo tiempo que el VLC en otra consola de cada receptor, el

capturador de paquetes para consola TcpDump (programa libre para Linux y
Windows, ampliamente utilizado), con la siguiente lnea de comando:
tcpdump vv w < Nombre del Archivo donde se guardaran los datos de
los paquetes capturados >
3. El TcpDump se basa en la utilizacin de la librera Pcap para leer los cabezales de
los paquetes directamente de la tarjeta de red, cuando este guarda los datos
capturados lo hace en el formato de esta librera que es ilegible a simple vista.
Para obtener los datos en formato ASCII se utilizo la lnea de comando que se
muestra a continuacin:

20

 tcpdump r < Nombre del archivo donde previamente se guardo la

captura > -T rtp A >
< Nombre del archivo de la captura en
formato ASCII >
Donde los modificadores significan:
-r: lee un archivo de captura especificado en el formato de la librera
Pcap creado con el modificador -w.
-T: decodifica los paquetes UDP como RTP.
-A: Convierte los datos ledos a formato ASCII.

Nota: no es posible realizar la captura y simultneamente desplegar la informacin en formato ASCII en

pantalla, ya que la capacidad de procesamiento requerida por el sistema usado para este propsito es
insuficiente, provocando que el Kernel del sistema descarte paquetes adicionales (adems de los que se
pierden en los enlaces).

4. El archivo obtenido anteriormente consta de mltiples lneas por paquete, adems

de informacin adicional de otros tipos de paquete como IGMP (Internet Group
Management Protocol, ver [3]), y PIM-SM (Protocol Independent Multicast, el
protocolo de ruteo multicast utilizado, ver[5]) que no eran relevantes para nuestro
propsito. Nosotros necesitbamos obtener del citado archivo solamente las lneas
correspondientes a los paquetes RTP que contuvieran la informacin del nmero
de secuencia, lo que logramos con el comando de Linux egrep que lo que hace es
tomar como entrada un archivo de texto y devolver todas las lneas que contengan
una cadena de caracteres dada. La lnea de comando usada para este propsito
fue:
egrep udp/rtp < Nombre del archivo de captura en formato ASCII> >
< Nombre del archivo recortado>
5. Una vez que logramos obtener el archivo con todas las lneas del archivo ASCII
correspondientes a paquetes de video RTP conteniendo el nmero de secuencia,
era necesario obtener de cada una de esas lneas el mencionado nmero, para ello
usamos el comando de Linux awk que entre sus muchas funcionalidades permite
contar una cantidad de espacios dada en una lnea de texto y obtener la cadena de
caracteres que empiece a partir de esa cantidad y termine en el siguiente espacio.
La sintaxis utilizada fue:
awk {print $ <Nmero de espacios>} < Nombre del archivo a recortar>
> < Nombre del archivo con los nmeros de secuencia deseados>
Con el mtodo descrito anteriormente, logramos obtener los vectores de nmeros
de secuencia ordenados de los paquetes arribados a cada receptor sobre los cuales
probamos el algoritmo de inferencia de rbol multicast (el cual fue realizado
ntegramente en Matlab).

21

8 Resultados Obtenidos
8.1 Red Real
Con los nmeros de secuencia obtenidos, implementamos el algoritmo propuesto
(no vale la pena entrar aqu en los detalles de la programacin, el cdigo realizado se
encuentra en el anexo 1).
La primera prueba que hicimos fue con una topologa de rbol binario como la
que se muestra a en la figura 7.
A continuacin se muestra el procedimiento que realiza en cada paso el algoritmo
para reconstruir el rbol:
Paso 0: la informacin con la que se cuenta a priori son los receptores, y los
patrones de prdida de cada uno de ellos.

Fig. 8: Proceso de agregacin de nodos en el rbol binario de cuatro receptores.

Paso 1: En el primer paso el algoritmo agrega los nodos A y B en un nico
macronodo como se muestra en la siguiente figura:

Fig. 9: Paso 1 de agregacin

Paso 2: En el segundo paso el mtodo agrupa los receptores C y D en otro
macronodo, como se puede ver en la figura que sigue a continuacin:

Fig. 10: Paso 2 de agregacin

Paso 3: En el tercer paso la nica posibilidad es agregar los dos macronodos
hallados en uno solo, finalizando el algoritmo.
La siguiente prueba que quisimos realizar fue conectar otro router a R2 al cual a
su vez se encontraran conectados dos receptores ms, pero en este punto nos vimos

22

limitados por el VMWare Workstation que solo le permite tener a cada mquina virtual un
mximo de tres adaptadores de red, y para la topologa propuesta necesitbamos que R2
tuviera cuatro interfaces. Como nos pareca fundamental probar el algoritmo en
topologas ms complicadas que un rbol binario, donde por ejemplo pueda darse el caso
de tres receptores conectados a un mismo enrutador, decidimos simular los vectores de
nmeros de secuencia con Matlab y generar prdidas aleatorias en ellos.

8.2 Red Simulada

Luego de haber comprobado la metodologa y probado y documentado las
herramientas necesarias para implementar el algoritmo de inferencia de rbol en una red
multicast real, cremos conveniente exigir un poco ms al algoritmo, trabajando con datos
simulados que corresponderan a una red con una topologa ms compleja.
La topologa elegida fue la siguiente:

Fig. 11: Red simulada con topologa ms compleja

23

Este diseo intenta probar la robustez del algoritmo frente a las condiciones de
red que por la naturaleza inherente del mismo aparecen como ms desafiantes:

Un nmero considerable de terminales (que no podamos tener en la red

virtual construida en Workstation, por limitaciones en el PC utilizado).
Nodos con ms de dos conexiones de salida (agrupar tres o ms terminales
y/o macronodos es ms complejo que hacerlo con dos).
Prdidas bajas hacia los routers y altas hacia las terminales.

ste ltimo punto aparece a priori como el ms desafiante para el algoritmo,

debido a que el algoritmo trabaja en base a correlacionar prdidas entre receptores,
entonces tener un bajo porcentaje de prdidas hacia un router, hace que la estimacin de
Ptab sea ms difcil, ya que hay pocos paquetes perdidos reales en comn entre los
terminales, y tener un alto porcentaje de prdidas totales desde la fuente al destino, deja
al algoritmo con pocos datos sobre los cuales trabajar, adems de que una gran cantidad
de paquetes perdidos en comn entre terminales sern casuales.
Vale aclarar que se modificaron las prdidas del rbol varias veces y con cada una
de estas configuraciones se generaron varias veces los datos simulados, ya que en cada
ejecucin se obtuvieron nuevas muestras. En todos los casos realistas el algoritmo
funcion correctamente reconstruyendo el rbol conocido. Para un peor caso no
realista, o sea con prdidas del orden del 70% hacia alguna de las terminales, el
algoritmo comienza a fallar. De todos modos en estos casos tenemos una situacin de
conectividad deficiente que no permitira a dicha terminal acceder a una corriente de
datos del servidor de un modo mnimamente aceptable, y quedara fuera de los objetivos
del algoritmo.
En este modelo simulado, se gener un vector de 20.000 nmeros
correspondientes a los nmeros de secuencia de los paquetes enviados por la fuente, y
luego se gener el vector correspondiente a cada nodo descartando paquetes del vector de
su antecesor, aleatoriamente con una probabilidad igual a la que se detalla en el esquema.

8.2.1 Proceso de reconstruccin del rbol de la red simulada

A continuacin se detalla el orden en que el algoritmo agrup los nodos en una de
las simulaciones con los parmetros especificados anteriormente. Este orden puede tener
variaciones con cada simulacin, pero lo importante es que el rbol final siempre es el
mismo.
Paso 0: Contamos simplemente con la informacin de qu paquetes no recibi
cada una de las terminales.

Fig. 12: Receptores sin informacin de topologa

24

Paso 1: Al correr una vez la rutina agregarNodo.m, el algoritmo detecta que los
dos nodos con mayor probabilidad de prdidas comunes reales son los D1 y D2,
combinndolos en un macro nodo. Adems nuestro algoritmo calcula con excelente
precisin las prdidas de los enlaces desde el router C2 hacia estos receptores, y estima
en 4,64% las prdidas totales comunes reales entre D1 y D2, que corresponden a las
prdidas desde el router C2 hasta la fuente, esto se pone en una lnea punteada porque
hasta aqu no sabemos si se agregarn ms nodos antes de llegar a la fuente.

Fig. 13: Paso 1 de agregacin

Paso 2: Al combinar las prdidas de los nodos D1 y D2, la segunda pasada de la
rutina detecta que la mayor correlacin entre prdidas se da entre el macronodo D1D2 y
el nodo C1. Adems, casi tan alta como esta correlacin es la que se da entre estos
nodos con el C3. El parmetro de tolerancia (establecido mediante pruebas al 10%), es lo
que permite la agrupacin de nodos en grupos mayores a dos. Observar que si este
parmetro es demasiado grande, corremos el riesgo de combinar nodos errneamente.
Adems, uno puede achicarlo ms si se cuenta con ms muestras, ya que las correlaciones
entre nodos adyacentes tienden a igualarse (tendiendo a la probabilidad real de prdidas
compartidas reales). En este paso todava no se despeja la incgnita de las prdidas desde
el router de D1 y D2 (C2) hasta el router conectado a C1 y C3 (B1). Finalmente, se
calcula tambin en este paso las prdidas desde el router agregado hacia la fuente (3,1%),
con lo cual calculamos por diferencias las prdidas entre los dos routers agregados hasta
ahora (ver flechas azules).

25

Fig. 14: Paso 2 de agregacin

Paso 3: Se combinan los nodos C4 y C5, obteniendo la informacin de las
prdidas de C4 y C5 hasta su nodo comn, y las prdidas totales de este hacia la fuente
(tambin en una lnea punteada, dado que no sabemos si habr ms nodos en el camino).

Fig. 15: Paso 3 de agregacin

26

Paso 4: Se combinan los macronodos D1D2-C1C3, C4C5 y el nodo B3. En el

siguiente paso (6), simplemente se agregan todos los macronodos existentes hasta el
momento, y se calcula desde ellos una prdida despreciable hacia la fuente. De este modo
podemos ahora calcular las prdidas entre los routers C2 y B1 por diferencias, como se
indica en la figura

Fig. 16: Paso 4 de agregacin

Finalmente, ahora se ve con claridad que la topologa as determinada es equivalente
a la conocida a priori de la red simulada, y los valores de prdidas deducidos estn dentro
de los lmites esperados. El que se aleja ms de su valor real es el de las prdidas entre C2
y B1, esto se debe a que el valor es muy pequeo, por lo que se requerir de ms
muestras para estimarlo mejor, pero esto no es necesario ya que lo importante en este
caso es saber que las prdidas son muy bajas.

9 Conclusiones
A lo largo de este trabajo nos enfrentamos con problemticas relacionadas a dos
aspectos distintos. Por un lado, tuvimos que programar el algoritmo de inferencia de
rbol de Ratnasamy y McCanne y luego idear un mtodo para calcular las prdidas en
cada rama del rbol as construido. Por otro lado, la puesta en funcionamiento de la red
multicast virtual, as como la realizacin de las medidas, fueron un trabajo en si mismo
(de hecho lo que nos llev la mayor parte del tiempo insumido en la realizacin de este
trabajo).
Con respecto a la puesta en funcionamiento y medicin sobre la red multicast, se
obtuvo un buen conocimiento prctico puntual de varios de los problemas relacionados
que hay que resolver en estos casos. El ruteo multicast est llamado a ser el estndar para
la difusin masiva de contenido, sobre todo el de tiempo real, y es til tener una idea ms

27

concreta de su funcionamiento. Hay que admitir tambin, sin embargo, que el mtodo
empleado para las mediciones fue seguramente demasiado manual, y si en la prctica uno
no tiene realmente acceso directo a los receptores sino que estos pertenecen a clientes, se
hara necesaria la automatizacin del conteo de paquetes y el envo de los nmeros de
secuencia hacia la fuente, para su posterior anlisis. Adems, enviar un flujo de video,
como hicimos en nuestra experiencia, resultara altamente ineficiente por tratarse de
paquetes pesado que congestionan la red. En la prctica esto se podra realizar con los
mismos paquetes del servicio que se esta prestando (podra ser video, claro est) siempre
que sea un flujo RTP (por contar con nmeros de secuencia pero sin confirmacin) o
alguna transmisin especial con paquetes vacos.
En relacin al testeo de los algoritmos propiamente, podemos afirmar que su
desempeo fue muy bueno, tanto el de inferencia de la estructura de red como el que
ideamos nosotros para calcular los porcentajes de prdida. Sin embargo, lo que faltara
ver es su utilidad en una red real, utilidad que variara segn la movilidad que tenga la
red (los caminos de la misma), ya que lgicamente, estos algoritmos lo que intentan
modelar es la red en un determinado instante.

10 Referencias
[1] S. Ratnasamy, S. McCanne, Inference of Multicast Routing Tree Topologies and
Bottleneck Bandwidths Using End-to-end Measurements, Proc IEEE Infocom 99, 1999.
[2] J. Goyeneche, Multicast over TCP/IP HOWTO, http://jungla.dit.upm.es/~jmseyas/,
1998.
[3] RFC 2236, Internet Group Management Protocol, version 2, 1997.
[4] RFC 1075, Distance Vector Multicast Routing Protocol, 1988.
[5] RFC 2362, Protocol Independent Multicast-Sparse Mode (PIM-SM), 1998.
[6] RFC 3550, "RTP: A Transport Protocol for Real-Time Applications", 2003.
[7] Pginas MAN, http://man.he.net/ .
[8] R. Montaana, Multicast, http://www.uv.es/~montanan/.

28

11 Anexo 1: Programas de Matlab Realizados

*********

*TIA.m*
*********
% Tree Inference Algorithm
clear all
close all
%Cargamos en memoria los archivos, cada uno es una columna con los nmeros
%de secuencia de los archivos recibidos por un receptor.
load rtp1awk.txt %datos obtenidos de la fuente (completos)
ref=rtp1awk;
casosPosibles=length(ref);
load rtp4awk.txt
a1=rtp4awk;
load rtp5awk.txt
a2=rtp5awk;
load rtp6awk.txt
a3=rtp6awk;
load rtp7awk.txt
a4=rtp7awk;
VectoresCargados=4; %Sin contar el de referencia
PTabMin=0.005; %Mnimas perdidas compartidas reales entre dos receptores para
juntarlos
MatBin=zeros(length(ref),VectoresCargados); %Matriz binaria donde la posicin (m,n)
indica si el paquete m se perdi en el receptor n+1
%Completo la matriz con los vectores que indican las prdidas de cada receptor
MatBin(:,1)=lostPaks(ref,a1);
MatBin(:,2)=lostPaks(ref,a2);
MatBin(:,3)=lostPaks(ref,a3);
MatBin(:,4)=lostPaks(ref,a4);
MatBin2=MatBin;
margenError=0.12;
while size(MatBin2,2)>1
MatBin2=agregarNodo(MatBin2,margenError,PTabMin);
pause
end
disp('END')
29

************
*TIAsim.m*
************
% Tree Inference Algorithm - Usando red simulada
% clear all
% close all
PTabMin=0.005; %Mnimas perdidas compartidas reales entre dos receptores para
juntarlos
%Creamos la topologia:
%Nodos interiores:
A1=[1:1:20000];
B1=enlace(A1,0.03);
disp('cre B1')
B2=enlace(A1,0.05);
disp('cre B2')
C2=enlace(B1,0.02);
disp('cre C2')
%Extremos:
B3=enlace(A1,0.20);
disp('cre B3')
C1=enlace(B1,0.25);
disp('cre C1')
C3=enlace(B1,0.30);
disp('cre C3')
C4=enlace(B2,0.35);
disp('cre C4')
C5=enlace(B2,0.20);
disp('cre C5')
D1=enlace(C2,0.25);
disp('cre D1')
D2=enlace(C2,0.30);
disp('cre D2')
VectoresCargados=7; %Sin contar el de Referencia
MatBin=zeros(length(A1),VectoresCargados); %Matriz binaria donde la posicin (m,n)
indica si el paquete m se perdi en el receptor n+1
%Completo la matriz con los vectores que indican las prdidas de cada receptor
MatBin(:,1)=lostPaks(A1,B3)';
MatBin(:,2)=lostPaks(A1,C1)';

30

MatBin(:,3)=lostPaks(A1,C3)';
MatBin(:,4)=lostPaks(A1,C4)';
MatBin(:,5)=lostPaks(A1,C5)';
MatBin(:,6)=lostPaks(A1,D1)';
MatBin(:,7)=lostPaks(A1,D2)';
MatBin2=MatBin;
margenError=0.15;
while size(MatBin2,2)>1
MatBin2=agregarNodo(MatBin2,margenError,PTabMin);
end
disp('END')
******************
*AgregarNodo.m*
******************
function MatBin2=agregarNodo(MatBin,margenError,PTabMin)
largo=size(MatBin,2);
casosPosibles=size(MatBin,1);
Pab=zeros(largo);
PAB=zeros(largo);
PTab=zeros(largo);
MatBin2=[];
for m=1:largo
for n=1:largo
if m~=n
AND=MatBin(:,m).*MatBin(:,n);
Pab(m,n)=sum(AND)/casosPosibles;
PAB(m,n)=sum(MatBin(:,m)-AND)/casosPosibles;
end
end
end
%Matriz de true shared losses
for m=1:largo
for n=m+1:largo
PTab(m,n)=(Pab(m,n)*PAB(n,m)+PAB(n,m)*PAB(m,n) + PAB(m,n)*Pab(m,n) +
Pab(m,n)^2-Pab(m,n))/(Pab(m,n) + PAB(n,m)+PAB(m,n)-1);
end
end

31

%Busco los dos nodos con mxima correlacin

PtNodo=max(max(PTab));
auxPtNodo=PtNodo;
if PtNodo>PTabMin
[terminal1,terminal2]=find(PTab==PtNodo);
agregados=[terminal1 terminal2];
%Busco algn otro nodo para asociar debido a que entra dentro del margen de error
for m=1:largo
for n=m+1:largo
if m==terminal1 & n~=terminal2
if abs(PTab(m,n)PTab(terminal1,terminal2))/PTab(terminal1,terminal2)<margenError &
isempty(find(agregados==n))
agregados=[agregados n];
auxPtNodo=[auxPtNodo PTab(m,n)];
end
end
if m~=terminal1 & n==terminal2
if abs(PTab(m,n)-PTab(terminal1,terminal2)) / PTab(terminal1,terminal2) <
margenError & isempty(find(agregados==m))
agregados=[agregados m];
auxPtNodo=[auxPtNodo PTab(m,n)];
end
end
end
end
else
agregados=[1:size(MatBin,2)];
end
agregados=sort(agregados);
%Clculo de las prdidas en el ltimo tramo de cada receptor.
%Esto solo sirve para el ltimo tramo de conexin, no para los tramos de los macronodos
PerdidasLinea=zeros(length(agregados),1);
PerdidasShared=min(auxPtNodo);
for i=1:length(agregados)
PerdidasTotales=sum(MatBin(:,agregados(i)))/casosPosibles;
PerdidasLinea(i)=(PerdidasTotales-PerdidasShared)/(1-PerdidasShared);
end
%Combino las columnas de los nodos que quiero agrupar

32

YaCombine=0; %Me indica si ya combin las columnas

MatBin2(1:size(MatBin,1),1)=0;
aux=0;
for n=1:largo
if ismember(n,agregados)==1 & YaCombine==0 %Al encontrar la primera columna a
combinar, le combino todas las otras
MatBin2(:,n)=1;
for i=2:length(agregados) %Este for va combinando las columnas
MatBin2(:,n)=MatBin2(:,n) & MatBin(:,agregados(i));
end
YaCombine=1;
aux=1;
elseif ismember(n,agregados)==0 %Copio las columnas que no hay que combinar
MatBin2(:,size(MatBin2,2)+aux)=MatBin(:,n);
aux=1;
end
end
disp('junt nodos:')
disp(agregados)
disp('las perdidas de cada nodo (solo vlido para receptores) son:')
disp(PrdidasLinea)
disp('Prdidas desde nodo padre hasta la fuente')
disp(PrdidasShared)
disp('*---------------------------------------------------------*')
*************
*recibido.m*
*************
function recibido=enlace(enviado, prdida)
recibido=[];
for i=1:length(enviado),
if rand(1)>perdida,
recibido=[recibido enviado(i)];
end
end

33

*************
*lostPaks.m*
*************
function lostPaks=lostPaksV2(ref,paks)
lostPaks=ref*0;
pointer=1;
%------Loop principal que busca paquetes perdidos------%
for m=1:length(paks)
while paks(m)~=ref(pointer)
lostPaks(pointer)=1;
pointer=pointer+1;
end
pointer=pointer+1;
end
%Condicin de borde final: relleno si se perdieron paquetes justo al final
if paks(length(paks))~=ref(length(ref)),
pointer=pointer+1;
lostPaks(pointer:length(lostPaks))=1;
end

34

12 Anexo 2: Archivo de configuracin utilizado para el

router XORP
/* $XORP: xorp/rtrmgr/config.boot.sample,v 1.16 2004/06/21 18:06:05 hodson Exp $ */
interfaces {
interface eth0 {
description: "Salida a red 0"
enabled: true
default-system-config
}
interface eth1 {
description: "Salida a red 1"
enabled: true
default-system-config
}
}
/* "El forwarding ya lo tenemos"*/
/*fea {
enable-unicast-forwarding4: true
}
*/
plumbing {
mfea4 {
enabled: true
interface eth0 {
vif eth0 {
enabled: true
}
}
interface eth1 {
vif eth1 {
enabled: true
}
}
interface register_vif {
vif register_vif {
/* Note: this vif should be always enabled */
enabled: true
}
35

}
traceoptions {
flag all {
enabled: true
}
}
}
}
protocols {
igmp {
enabled: true
interface eth0 {
vif eth0 {
enabled: true
}
}
interface eth1 {
vif eth1 {
enabled: true
}
}
traceoptions {
flag all {
enabled: true
}
}
}
}
protocols {
pimsm4 {
enabled: true
interface eth0 {
vif eth0 {
enabled: true
/* dr-priority: 1 */
/* alternative-subnet 10.40.0.0/16 */
}
}
interface eth1 {
vif eth1 {
enabled: true
/* dr-priority: 1 */
/* alternative-subnet 10.40.0.0/16 */
}

36

}
interface register_vif {
vif register_vif {
/* Note: this vif should be always enabled */
enabled: true
}
}
static-rps {
rp 192.168.0.3 {
group-prefix 224.0.0.0/4 {
/* rp-priority: 192 */
/* hash-mask-len: 30 */
}
}
}
bootstrap {
enabled: true
cand-bsr {
scope-zone 224.0.0.0/4 {
/* is-scope-zone: false */
cand-bsr-by-vif-name: "eth0"
bsr-priority: 1
hash-mask-len: 30
}
}
cand-rp {
group-prefix 224.0.0.0/4 {
/* is-scope-zone: false */
cand-rp-by-vif-name: "eth0"
rp-priority: 192
rp-holdtime: 150
}
}
}
switch-to-spt-threshold {
/* approx. 1K bytes/s (10Kbps) threshold */
enabled: true
interval-sec: 100
bytes: 102400
}
traceoptions {
flag all {

37

enabled: true
}
}
}
}
/*
* Note: fib2mrib is needed for multicast only if the unicast protocols
* don't populate the MRIB with multicast-specific routes.
*/
protocols {
fib2mrib {
enabled: true
}
}

/*
* See xorp/mibs/snmpdscripts/README on how to configure Net-SNMP in your host
* before uncommenting the snmp section below.
* Also check that the "bgp4_mib_1657.so" exists in the correct location.
*/
/*
*protocols {
* snmp {
*
mib-module bgp4_mib_1657 {
*
abs-path: "/usr/local/xorp/mibs/bgp4_mib_1657.so"
*
}
* }
*}
*/

38