Evaluación de Algoritmos de Ruteamiento Multipunto en Redes de ...

UNIVERSIDAD TECNICA FEDERICO SANTA MARIA
DEPARTAMENTO DE ELECTRONICA
Evaluación de Algoritmos de Ruteamiento
Multipunto en Redes de Computadores
Tesis de Grado presentada por:
Verónica Andrea Gacitúa Decar
como requisito parcial para optar al grado de
Magíster en Electrónica mención Telecomunicaciones y Sistemas Computacionales
Profesor Guía
Ph.D. Reinaldo Vallejos

Índice
Índice..........................................................................................................................................................2
Listado de Figuras....................................................................................................................................3
Listado de Tablas .....................................................................................................................................5
1 Introducción......................................................................................................................................8
2 Taxonomía de la Comunicación Multipunto ............................................................................10
2.1 Caracterización del Grupo ...................................................................................................10
2.2 Estructura de las Rutas de Comunicación.........................................................................11
2.3 Construcción de las Rutas de Comunicación....................................................................13
2.4 Manejo de la Información.....................................................................................................13
3 Modelo de Red y Formulación del Problema de Ruteamiento Multipunto........................15
3.1 Modelo de Red .......................................................................................................................15
3.2 Funciones Objetivo y Restricciones ....................................................................................16
3.3 Problemas en el Ruteamiento Multipunto ........................................................................18
3.4 Algunos Problemas Particulares .........................................................................................18
3.4.1 Definiciones ....................................................................................................................18
3.4.2 Árboles de Camino más Corto sin Restricciones .....................................................19
3.4.3 Árboles de Steiner sin Restricciones...........................................................................20
3.4.4 Árboles de Camino más Corto con Restricción de Retardo ...................................20
3.4.5 Árboles de Steiner con Restricción de Retardo.........................................................20
3.4.6 Compromiso entre Costo y Retardo...........................................................................20
3.4.7 Eficiencia Multicast .......................................................................................................20
4 Algoritmos de Ruteamiento Multipunto ...................................................................................22
4.1 Protocolos de Ruteamiento Multicast y Algoritmos Asociados ....................................22
4.1.1 DVMRP [23]....................................................................................................................22
4.1.2 MOSPF [25] .....................................................................................................................23
4.1.3 CBT [26] ...........................................................................................................................23
4.1.4 PIM ...................................................................................................................................24
4.1.5 BGMP [32] .......................................................................................................................27
4.1.6 Algoritmo RPF................................................................................................................29
4.1.7 Algoritmo Dijkstra.........................................................................................................29
4.1.8 Algoritmo Bellman‐Ford ..............................................................................................29
4.2 Algoritmos de Ruteamiento aparecidos en la Literatura................................................30
4.2.1 KMB [35]..........................................................................................................................30
4.2.2 BC [36]..............................................................................................................................32
4.2.3 CDKS [37]........................................................................................................................38
4.2.4 CAO [38]..........................................................................................................................38
4.2.5 BSMA [39] .......................................................................................................................40
4.2.6 KPP [14] ...........................................................................................................................42
4.2.7 QDMR [40]......................................................................................................................45
5 Métodos de Comparación de Algoritmos .................................................................................48
5.1 Analítica...................................................................................................................................48
5.2 Simulación...............................................................................................................................49
5.2.1 Generación de Escenarios de Simulación..................................................................52
5.2.2 Implementación de Algoritmos ..................................................................................52
5.2.3 Configuración de los Experimientos de Simulación ...............................................53
5.3 Experimental...........................................................................................................................54
2

6 Comparación de Algoritmos mediante Simulación.................................................................56
6.1 Herramienta de Simulación .................................................................................................56
6.2 Algoritmos Evaluados ..........................................................................................................57
6.3 Medidas de Rendimiento .....................................................................................................58
6.3.1 Costo del árbol ...............................................................................................................58
6.3.2 Retardo Promedio entre fuente y destino..................................................................58
6.3.3 Número de Conexiones Exitosas ................................................................................58
6.4 Configuración de los Experimentos de Simulación.........................................................58
6.4.1 Primer Experimento ......................................................................................................58
6.4.2 Segundo Experimento...................................................................................................60
7 Resultados de la Simulación ........................................................................................................61
8 Conclusiones...................................................................................................................................77
9 Agradecimientos ............................................................................................................................78
10 Referencias ......................................................................................................................................78
ANEXO A : Función Complejidad de Tiempo & NP Completitud...............................................82
ANEXO B: Breve Tutorial de NS‐2......................................................................................................85
ANEXO C: Breve Manual de Uso MCRSIM....................................................................................101
ANEXO D: Código BC para MCRSIM .............................................................................................104
Listado de Figuras
Fig. 1 Ejemplo que ilustra la diferencia entre árboles de fuente específica y árboles compartidos. ..... 12
Fig. 2 Taxonomía de Comunicación Multipunto ................................................................................... 14
Fig. 3 Ejemplo de Red representada por un grafo................................................................................... 16
Fig. 4 Ejemplo que muestra el árbol compartido y rama de fuente específica que el protocolo BGMP
puede construir entre sistemas autónomos, los cuales pueden estar utilizando algún otro protocolo
multicast al interior de ellos...................................................................................................................... 28
Fig. 5 Ejemplo Pasos Algoritmo KMB .................................................................................................. 31
Fig. 6 Iteraciones Heurística BC con función de contribución que considera una métrica de saltos ... 34
Fig. 7a Pseudocódigo Heurística BC...................................................................................................... 36
Fig. 8b Pseudocódigo Heurística BCL ................................................................................................... 37
Fig. 9 Ejemplo para visualizar la operación del algoritmo CDKS. ....................................................... 39
Fig. 10 Red utilizada como ejemplo de visualización de las iteraciones de BSMA .............................. 40
Fig. 11 Refinamiento de los caminos Fuente a Destinos condicionado al límite de retardo. ............... 41
Fig. 12 Red de ejemplo para ilustrar la operación de KPP y el árbol de Steiner asociado al grupo
multicast .................................................................................................................................................... 43
Fig. 13 Grafo cerrado G’, las sucesivas iteraciones y el árbol final encontrado utilizando la función
objetivo fC.................................................................................................................................................. 43
Fig. 14 Sucesivas iteraciones y el árbol final encontrado utilizando la función objetivo fCD ............... 44
Fig. 15 Ejemplo que muestra la diferencia entre DMMC y QDMR: (a) Ejemplo de red y Árbol
DDMC; (b) Árbol de menor Retardo (LDT); (c) Árbol DDMC + LDP (Least Delay Path); (d) Árbol
QDMR....................................................................................................................................................... 46
Fig. 16 Costo del Árbol en red de 20 nodos, grado promedio igual a 4 y ocupación de enlaces entre 5
y 125 Mbps. (Algoritmos No Restringidos)............................................................................................. 64
Fig. 17 Exceso sobre KMB para la medida costo del Árbol en red de 20 nodos, grado promedio igual
a 4 y ocupación de enlaces entre 5 y 125 Mbps. (Algoritmos No Restringidos) ................................... 64
Fig. 18 Costo del Árbol en red de 20 nodos, grado promedio igual a 4 y ocupación de enlaces entre 45
y 85 Mbps. (Algoritmos No Restringidos)............................................................................................... 65
3

Fig. 19 Exceso sobre KMB para la medida costo del Árbol en red de 20 nodos, grado promedio igual
a 4 y ocupación de enlaces entre 45 y 85 Mbps. (Algoritmos No Restringidos) ................................... 65
Fig. 20 Costo del Árbol en red de 20 nodos, grado promedio igual a 4 y ocupación de enlaces entre
100 y 120 Mbps. (Algoritmos No Restringidos)...................................................................................... 66
Fig. 21 Exceso sobre KMB para la medida costo del Árbol en red de 20 nodos, grado promedio igual
a 4 y ocupación de enlaces entre 100 y 120 Mbps. (Algoritmos No Restringidos) ................................ 66
Fig. 22 Costo del Árbol en red de 20 nodos, grado promedio igual a 4 y ocupación de enlaces entre 5
y 125 Mbps. (Algoritmos Restringidos)................................................................................................... 67
Fig. 23 Exceso sobre BSMA para la medida costo del Árbol en red de 20 nodos, grado promedio
igual a 4 y ocupación de enlaces entre 5 y 125 Mbps. (Algoritmos Restringidos) ................................. 67
Fig. 24 Costo del Árbol en red de 20 nodos, grado promedio igual a 4 y ocupación de enlaces entre 45
y 85 Mbps. (Algoritmos Restringidos)..................................................................................................... 68
Fig. 25 Exceso sobre BSMA para la medida costo del Árbol en red de 20 nodos, grado promedio
igual a 4 y ocupación de enlaces entre 45 y 85 Mbps. (Algoritmos Restringidos) ................................. 68
Fig. 26 Costo del Árbol en red de 20 nodos, grado promedio igual a 4 y ocupación de enlaces entre
100 y 120 Mbps. (Algoritmos Restringidos)............................................................................................ 69
Fig. 27 Exceso sobre BSMA para la medida costo del Árbol en red de 20 nodos, grado promedio
igual a 4 y ocupación de enlaces entre 100 y 120 Mbps. (Algoritmos Restringidos)............................. 69
Fig. 28 Resumen: Exceso sobre KMB para la medida costo del Árbol (Algoritmos Restringidos y No
Restringidos). Red de 20 nodos, con grado promedio igual a 4 y ocupación de enlaces entre: 5 y 125
Mbps; 45 y 85 Mbps; 100 y 120 Mbps..................................................................................................... 70
Fig. 29 Costo del Árbol en red de 100 nodos, grado promedio igual a 4 y ocupación de enlaces entre
100 y 120 Mbps. (Algoritmos Restringidos y No Restringidos) ............................................................. 71
Fig. 30 Exceso sobre KMB para la medida costo del Árbol en red de 100 nodos, grado promedio igual
a 4 y ocupación de enlaces entre 100 y 120 Mbps. (Algoritmos Restringidos y No Restringidos)........ 71
Fig. 31 Retardo promedio entre Fuente y Destinos en red de 20 nodos, grado promedio igual a 4 y
ocupación de enlaces entre 5 y 125 Mbps. (Algoritmos Restringidos y No Restringidos)..................... 72
Fig. 32 Exceso sobre BSMA para la medida retardo promedio entre Fuente y Destinos en red de 20
nodos, grado promedio igual a 4 y ocupación de enlaces entre 5 y 125 Mbps. (Algoritmos Restringidos
y No Restringidos) .................................................................................................................................... 72
Fig. 33 Retardo promedio entre Fuente y Destinos en red de 20 nodos, grado promedio igual a 4 y
ocupación de enlaces entre 45 y 85 Mbps. (Algoritmos Restringidos y No Restringidos)..................... 73
Fig. 34 Exceso sobre BSMA para la medida retardo promedio entre Fuente y Destinos en red de 20
nodos, grado promedio igual a 4 y ocupación de enlaces entre 45 y 85 Mbps. (Algoritmos Restringidos
y No Restringidos) .................................................................................................................................... 73
Fig. 35 Retardo promedio entre Fuente y Destinos en red de 20 nodos, grado promedio igual a 4 y
ocupación de enlaces entre 100 y 120 Mbps. (Algoritmos Restringidos y No Restringidos) ................ 74
Fig. 36 Exceso sobre BSMA para la medida retardo promedio entre Fuente y Destinos en red de 20
nodos, grado promedio igual a 4 y ocupación de enlaces entre 100 y 120 Mbps. (Algoritmos
Restringidos y No Restringidos)............................................................................................................... 74
Fig. 37 Retardo promedio entre Fuente y Destinos en red de 100 nodos, grado promedio igual a 4 y
ocupación de enlaces entre 100 y 120 Mbps. (Algoritmos Restringidos y No Restringidos) ................ 75
Fig. 38 Exceso sobre BSMA para la medida retardo promedio entre Fuente y Destinos en red de 50
nodos, grado promedio igual a 4 y ocupación de enlaces entre 100 y 120 Mbps. (Algoritmos
Restringidos y No Restringidos)............................................................................................................... 75
Fig. 39 Número de Conexiones Exitosas frente a Solicitudes. Red de 20 nodos con grado promedio
igual a 4. Número total de solicitudes igual a 3000. ................................................................................ 76
Fig. 40 Número de Conexiones Exitosas frente a Solicitudes. Red de 50 nodos con grado promedio
igual a 4. Número total de solicitudes igual a 3000. ................................................................................ 76
4

Listado de Tablas
Tabla 1 Problemas en el Ruteamiento Multipunto............................................................................18
Tabla 2: Algoritmos y Protocolos de ruteamiento Multicast. ...........................................................47
Tabla 3 Escalamiento dimensional y su efecto en el consumo de recursos computacionales. ........50
Tabla 4 Algunas Herramientas de Simulación para Redes de Computadores ................................51
Tabla 5 Algunas Herramientas de Monitoreo Multicast existentes..................................................55
Tabla 6 Ejemplo de Orden de complejidad de Varios Algoritmos hipotéticos................................83
Tabla 7 Varias Funciones de complejidad de Tiempo en función del Tamaño de un Problema.....83
Tabla 8 Archivos de MCRSIM.......................................................................................................103
5

6
A mi familia e Iván
por su constante apoyo y compresión

Miembros de la Comisión
Ph.D. Reinaldo Vallejos
Ph.D. Marta Barría
Ph.D. Hector Allende
7

H
1 Introducción
istóricamente las telecomunicaciones se desarrollaron bajo dos paradigmas: la
comunicación punto a punto (industria de la telefonía y las redes de computadores)
y la comunicación broadcast (industria de la televisión). Sin embargo, en la última
década, bajo la masificación de las redes de computadores, se han estado desarrollando
aplicaciones que involucran a un grupo que puede consistir de uno o más emisores y uno
o más receptores. El tipo de comunicación que permite ejecutar estas aplicaciones es
conocida como comunicación multipunto. La comunicación multipunto es algo natural
para miembros de un grupo que se encuentran en un mismo lugar, sin embargo, replicar
esta situación para miembros que se encuentran geográficamente distantes, involucra un
estado en la tecnología de las comunicaciones que aún dista de ser eficiente.
Los avances en el desarrollo de la tecnología que permite establecer la comunicación
multipunto ha abierto posibilidades más concretas a algunas ideas que han surgido
desde hace ya más de una década, tal como: la educación y trabajo a distancia,
telemedicina, videoconferencias, simulación interactiva distribuida o DIS, entre otras
aplicaciones.
La comunicación multicast permite que un paquete dirigido a un grupo se transmita a
través de una única ruta hasta ciertos puntos en la red en donde tal paquete debe ser
replicado para permitir alcanzar a todos los destinos. La comunicación multicast, a
diferencia de muchas conexiones unicast desde la fuente a todos los destinos, es ventajosa
principalmente porque hace uso de un menor de los recursos de la red (especialmente:
ancho de banda). Sin embargo, una desventaja de multicast y broadcast es que sólo son
soportadas en transmisiones UDP, perdiendo la confiabilidad que transmisiones TCP
pueden otorgar. Hay iniciativas que intentan otorgar extensiones multicast a TCP, tal
como SCE [1], TCP‐SMO [2], M/TCP [3], TCP‐XM [4].
Multicast fue probado a gran escala en 1992 durante un “audiocast” a 20 sitios en
Internet desde una reunión del Internet Engineering Task Force (IETF) [5]. Desde esta
época se han realizado numerosos esfuerzos para sobrellevar los desafíos que la
comunicación multipunto presenta. Mientras se desarrollan nuevos servicios multicast
para la Internet, las demandas por una infraestructura que soporte adecuadamente tales
servicios se hacen cada vez más presentes. Sin embargo ¿Son mayores los beneficios que
los servicios multicast aportan, comparados con las exigencias que impone sobre la
infraestructura?. Esta pregunta es abierta y debería responderse tomando en cuenta las
economías de escala naturales en Internet.
Uno de los desafíos básicos de la comunicación multipunto, es el establecimiento de las
rutas por donde la información debe fluir. Este problema es conocido con el nombre de
ruteamiento multipunto (RM), y cuando éste involucra restricciones sobre ciertas
medidas de interés para los usuarios, tal como límite en el retardo desde fuente a destino,
jitter, etc., se habla de RM con calidad de servicio (QoS). El problema de RM no es nuevo,
sin embargo las soluciones implementadas en Internet tienden a generar árboles de
distribución (responsables de conectar a los miembros del grupo) que cargan algunos
sectores de la red más que otros. Al saturar algunos enlaces de la red, es posible que un
mayor número de solicitudes de conexión sean rechazadas. La capacidad de algortimos
8

de ruteamiento multipunto (ARM) para permitir un mayor número de conexiones frente
a solicitudes es una capacidad deseada. Esta capacidad parece ser menor en soluciones
implementadas en protocolos de ruteamiento multicast, en comparación con algunas
propuestas en la literatura. Los algoritmos de ruteamiento multipunto, y en particular la
comparación de éstos son el foco del estudio de este trabajo.
El resto del escrito está organizado como sigue: en el capítulo 2, se expone una
taxonomía para la comunicación multipunto, la cual permite clasificar los algoritmos.
Dicha taxonomía basa sus dimensiones en una taxonomía propuesta en [6]. En el capítulo
3 se describe el modelo de red y se define formalmente el problema de ruteamiento
multipunto. Luego, en el capítulo 4 se describen algunos algoritmos de RM: algunos
vinculados a protocolos de RM y otros propuestos en la literatura. En el capítulo 5 se
describen los métodos de comparación de algoritmos de RM. En el capítulo 6 se realiza
una comparación de algunos de los algoritmos descritos en 4 mediante simulación.
Finalmente, en los capítulos 7 y 8 se presentan los resultados, interpretación y
conclusiones del trabajo.
9

E
2 Taxonomía de la Comunicación Multipunto
n las redes de computadores, ya sea en redes de datagramas o en redes que están
orientadas a la conexión, la comunicación multipunto consiste en la transmisión de
paquetes a un subgrupo de nodos en la red [7]. Dicha transmisión se efectúa a
través de rutas que generalmente son construidas de diferentes maneras y que poseen
diversas estructuras. A su vez, el subgrupo de nodos de la red que recibe los paquetes es
heterogéneo, y puede ser clasificado en cada caso según sus características.
Con el fin de ayudar a clasificar los algoritmos de ruteamiento estudiados en este
trabajo, se describirá una taxonomía que permite: caracterizar el grupo multipunto; la
estructura y construcción de las rutas que la información debe seguir; y conocer como se
realiza el manejo de la información.
Las dimensiones en la taxonomía fueron escogidas a partir de los requerimientos y
naturaleza de las aplicaciones existentes, las cuales han dirigido el desarrollo de varios
algoritmos y protocolos de ruteamiento. Se debe aclarar que ésta taxonomía no pretende
ser exhaustiva, y se focaliza en el tema de ruteamiento multicast. Trabajos más completos
en este ámbito pueden examinarse en [8], [9], [10], [11].
2.1 Caracterización del Grupo
La caracterización del grupo está definida bajo cinco lineamientos, los cuales se
describen a continuación:
Tipo de aplicación: los integrantes del grupo pueden cumplir diferentes roles según la
aplicación. Pueden ser emisores (fuentes) o receptores (destinos). En este contexto la
comunicación puede realizarse de:
Uno a Muchos (One‐to‐Many), tal como en audio y video broadcast, actualizaciones de
bases de datos, entre otras.
Muchos a Muchos (Many‐to‐Many), como las video conferencias, Educación a
distancia, juegos multiplayer, etc.
Muchos a Uno (Many‐to‐One). Como en aplicaciones para búsqueda de recursos
(normalmente algún programa automatizado para examinar el contenido de sitios Web),
recolección de datos, remates.
Variación en el Tiempo: Los grupos pueden ser permanentes, en cuyo caso existen
siempre o permanecen por un largo tiempo. Estos grupos permanecen aún cuando el
número de miembros sea cero. El complemento a estos grupos son los grupos
transientes.
Origen de los Datos: Los grupos abiertos son aquellos en los cuales los emisores
(fuentes) no necesitan ser miembros del grupo. A su vez los grupos cerrados son aquellos
en que sólo se les permite a los miembros enviar información al grupo.
Ubicación en la Red: Un grupo es denso cuando los miembros del grupo están sobre la
mayor parte de los enlaces o subredes en la red, por lo contrario, un grupo disperso
(sparse) mantiene miembros sólo sobre una pequeña porción de la red, y estos se
encuentran separados ampliamente.
10

Dinámica: Los grupos estáticos son aquellos en donde los miembros permanecen
constantes. Los grupos dinámicos permiten a los miembros dejar o adjuntarse (join/leave)
al grupo. Se debe notar que a diferencia de la variación en el tiempo de los grupos, que
se relaciona con la asignación de direcciones a los grupos multicast en el tiempo, la
dinámica tiene que ver con la entrada y salida de miembros del grupo en el tiempo.
La comparación de algoritmos de ruteamiento multipunto los conceptos de mayor
relevancia en la caracterización del grupo son la dinámica del grupo y la ubicación de
los miembros del grupo en la red.
2.2 Estructura de las Rutas de Comunicación
El envío de información a todos los receptores de un grupo puede realizarse de dos
modos básicos: a través de tantas conexiones punto a punto como receptores del grupo
existen (comunicación multicast a partir de conexiones unicast) o utilizar un árbol de
distribución multipunto (multicast distribution tree). En un árbol de distribución
multipunto un paquete de información dirigido desde una fuente a un grupo de destinos
es replicado tantas veces como sea necesario, cada vez que llega a una bifurcación del
árbol. Los árboles de distribución pueden clasificarse en:
Árbol de Fuente Especifica (Source‐Specific Tree): Se basan en una comunicación donde
un solo nodo envía datos a todos los nodos receptores del grupo.
Árbol de Grupo compartido (Group‐Shared Tree): Cada nodo en el grupo puede enviar
o recibir datos de otros nodos del grupo.
La principal diferencia entre estas dos categorías de árbol, es que los árboles de fuente
específica, tal como su nombre lo indica, se diseñan para una comunicación que fluye
desde un sólo nodo (la fuente) hacia los destinos. En cambio, los árboles compartidos
están diseñados para una comunicación en donde cualquiera de los nodos puede actuar
como fuente o destino en diferentes instantes. La Fig. 1 ilustra un ejemplo de la
diferencia entre estas dos categorías de árboles. El grafo en la Fig. 1 representa una red,
donde los nodos A, F, G y J pertenecen a un mismo grupo. La primera coordenada en los
vectores escritos sobre cada enlace corresponde al retardo, y la segunda coordenada
corresponde al costo del enlace. El árbol de fuente específica de la Fig. 1 b, establecido
desde el nodo A, posee un retardo promedio para los caminos desde la fuente a cada
destino igual a 2.33. La Fig. 1 c, muestra un árbol compartido, donde el retardo
promedio de los caminos desde el nodo A a los otros nodos pertenecientes al grupo es
3.33. Sin embargo, si se calcula el retardo promedio de los caminos de fuente a destino,
donde cualquier nodo del grupo puede tomar el rol de fuente, el resultado del árbol en la
Fig. 1 b es igual a 3.5 y en la Fig. 1 c es 2.67. Adicionalmente, el costo del árbol (definido
como las suma de los costos de los enlaces pertenecientes a él) considerando una
comunicación desde el nodo A (fuente) a los destinos F, G y J en la Fig. 1 b es igual a 9.8,
y a 5.8 en la Fig. 1 c.
Árboles compartidos y árboles basados en la fuente tienen sus propias ventajas y
desventajas. Una ventajas de un árbol compartido es que el mantenimiento de dicho
árbol durante la sesión multicast es menos costoso en términos de la computación
requerida, pues cuando una fuente comienza a transmitir o un nuevo nodo quiere unirse
al grupo, éste sólo debe encontrar un camino para unirse al árbol ya existente. En cambio,
en el caso de árboles basados en la fuente, cuando una fuente comienza a transmitir, un
nuevo árbol es generado a partir de ésta.
11

En el caso donde existen varias fuentes en una misma sesión multicast, las ventajas de
los árboles basados en la fuente es que diversifican los flujos sobre los diferentes enlaces,
pues exiten tantos árboles de distribución como fuentes. En cambio, en árboles
compartidos, el tráfico tiende a concentrarse sólo en los enlaces del único árbol asociado a
la sesión.
Una desventaja de los árboles compartidos frente a árboles basados en la fuente, es que
los primeros están diseñados para obtener un bajo costo global del árbol (o alguna otra
medida), por ello pueden ser inconvenientes respecto a algunas medidas evaluadas
desde la fuente a todos los destinos, tal como se ilustró anteriormente con el retardo fin a
fin en el ejemplo de la Fig. 1.
(a) Grafo que modela la red
(b) Árbol de fuente específica A (en línea segmentada)
(c) Árbol compartido (en doble línea segmentada)
Fig. 1 Ejemplo que ilustra la diferencia entre árboles de fuente específica y árboles compartidos.
12

2.3 Construcción de las Rutas de Comunicación
Para cualquiera de las estructuras de las rutas multipunto, la construcción de éstas
depende de cuál sea el criterio usado para lograr un uso eficiente de los recursos. En el
caso de construcción de árboles multipunto que busquen encontrar caminos mínimos
desde la fuente a cada miembro del grupo, el árbol resultante es llamado árbol de
camino más corto (shortest path tree). Otra categoría, son los árboles de Steiner (Steiner
trees), en donde el costo total del árbol multipunto es minimizado.
El problema del árbol de Steiner es un problema NP completo [12], [13]. Si en la
construcción del árbol de Steiner, el grupo de nodos destinos incluye a todos los nodos de
la red, el problema se reduce a la construcción de un árbol de mínima expansión
(minimum spanning tree), el cual puede ser resuelto en tiempo polinomial [15].
En ambos casos anteriores (shortest Path & Steiner trees) existe la posibilidad de incluir
restricciones en la construcción de las rutas del árbol (límite en el retardo fin a fin, límite
de ancho de banda utilizado en los enlaces, etc). En estos casos se habla de árboles de
camino más corto restringidos (Constrained shortest path tree) y árboles de Steiner
restringidos (Constrained Steiner tree).
2.4 Manejo de la Información
La construcción del árbol de distribución que conecta a los miembros de un grupo
multicast puede realizarse en función de información local o global. Información de
ruteamiento puede ser por ejemplo: la topología de la red, la utilización de los enlaces, el
retardo, o las distancias de los caminos entre los nodos, etc.
Construir un árbol de distribución con información global requiere de algún
mecanismo de intercambio de datos que permita al nodo o los nodos que realizarán el
ruteamiento tomar decisiones con información global de la red, y no sólo información
que él o sus vecinos posean. El intercambio de datos necesario cuando se requiere
información global para el ruteamiento puede producir problemas de escalabilidad, por
ejemplo cuando hay muchos grupos, muchas fuentes, cuando los miembros pertenecen a
distintos sistemas autónomos, etc.
Debido a los problemas de escalabilidad asociados al manejo de información global, las
implementaciones de algoritmos de ruteamiento normalmente operan a partir de
información local. Por otro lado, la información de ruteamiento puede estar almacenada
en forma centralizada o distribuida dependiendo del algoritmo utilizado como motor del
protocolo o los protocolos de ruteamiento presentes en una red particular. Esta
característica es relevante en términos del mantenimiento de información en cada router.
La Fig. 2 muestra un esquema de la taxonomía presentada en este capítulo.
13

Fig. 2 Taxonomía de Comunicación Multipunto
14

A
3 Modelo de Red y Formulación del Problema de
Ruteamiento Multipunto
ntes de definir formalmente el modelo de red y formular el problema de
ruteamiento multipunto, se describen las características deseadas de un algoritmo de
ruteamiento multipunto:
• La carga que impone el algoritmo sobre la red debería ser la menor posible.
• Debería facilitar la transmisión confiable. (Una transmisión confiable garantiza que
todos los datos llegarán a todos los destinos).
• Debería ser capaz de seleccionar rutas tendientes a las óptimas, tomando en cuenta
diferentes funciones de costo y restricciones impuestas por aplicaciones y/o usuarios.
Las rutas debieran mantenerse tendientes a las óptimas, a pesar de ocurrir cambios
en el grupo o la red.
• El algoritmo debería minimizar la cantidad de información que almacena en los
routers, de tal forma que más grupos puedan ser soportados sin incurrir en
problemas de escalabilidad.
• La transmisión de los datos debería alcanzar sólo a los miembros del grupo.
Una vez presentadas las características ideales de un algoritmo de ruteamiento
multipunto, se define ahora formalmente el problema de ruteamiento multipunto.
3.1 Modelo de Red
La red es representada por un grafo dirigido G = (V, E), donde V denota al conjunto de
nodos y E al conjunto de enlaces dirigidos que conectan a los nodos. |V| y |E| denotan el
número de nodos y enlaces en la red, respectivamente. Asociado a cada nodo y enlace
existen parámetros que describen su estado. Por ejemplo, para un enlace los parámetros
podrían ser: la ocupación de ese enlace, el costo de su utilización, el retardo que un
paquete sufre al atravesarlo, etc.
Se denota por W(d1,d2) al vector que representa al conjunto de parámetros que describen
el estado del enlace e = (d1, d2) que une al nodo d1 con el nodo d2, con d1, d2 ∈ V.
Análogamente, se llama Wd al vector de estado del nodo d ∈ V. La dimensión de los
vectores de estado (nodo y enlace) depende de cuantos parámetros sean considerados.
El conjunto de vectores de estado de enlaces y nodos es llamado estado global de la
red.
En la Fig. 3 el vector de estado de enlace W(a, b) = (1, 0.02, 10), tiene dimensión tres. Su
primera componente corresponde al costo en $/hr, que indica el precio (en alguna
moneda) de utilizar el enlace durante una hora; la segunda componente corresponde al
retardo promedio (en mseg) de un paquete atravesando el enlace; y finalmente, la tercera
componente corresponde a la capacidad del enlace en Mbps.
15

Fig. 3 Ejemplo de Red representada por un grafo
Sea M ⊆ V un conjunto de nodos participantes en una comunicación multipunto, al
cual se le llamará grupo. Los paquetes originados en un nodo fuente vs son enviados al
conjunto de nodos receptores M – {vs}.
Se debe notar que puede suceder que aplicaciones corriendo sobre la máquina que vs
representa, podrían requerir que la información también fluya hacia la misma vs, sin
embargo, esto no es relevante para el problema de ruteamiento multipunto, pues interesa
establecer las rutas para los paquetes que salen desde una máquina (fuente) hacia otras
máquinas (destinos) pertenecientes al grupo.
Un árbol multipunto T es un subgrafo de G que se expande a todos los nodos en M, es
decir, conecta a todos los miembros del grupo. T puede incluir nodos que no son
miembros del grupo, pero que son necesarios para establecer la comunicación.
P T( vs
, d)
denota el camino desde un nodo fuente vs a un nodo destino d ∈ M – {vs} en el
árbol T.
3.2 Funciones Objetivo y Restricciones
Dado un grupo M, un conjunto de funciones objetivo de optimización O y un conjunto
de restricciones R, el ruteamiento multipunto es el proceso de construir, basado en la
topología y estado de la red, un árbol multipunto T que optimice las funciones objetivo
en O y respete al conjunto de restricciones R.
Se debe notar que optimizar las funciones objetivo, sujeto o no a restricciones,
normalmente conlleva una gran utilización de recursos computacionales. Esto obliga a,
en la práctica, utilizar heurísticas que provean de una buena solución, siendo ésta no
óptima.
En el capítulo 4 se describen variadas heurísticas para solucionar el problema de
ruteamiento multipunto.
Funciones Objetivo y Restricciones: Los objetivos de optimización usualmente se definen
en términos de minimizar el costo de un árbol multipunto, donde el costo podría ser: la
suma de los anchos de banda ocupados por cada enlace que forma parte del árbol; el
precio de los enlaces que conforman el árbol; el retardo promedio entre la fuente y los
receptores; la eficiencia multipunto (δ), la cual representa el porcentaje de ganancia de la
eficiencia multicast sobre la unicast (ver 3.4.7); entre otras medidas.
Las restricciones impuestas para la construcción de los árboles multipunto pueden
16

clasificarse en dos categorías principales: Restricciones de enlace (link constraints) y,
Restricciones de árbol (tree constraints).
Las restricciones de enlace son restricciones sobre el uso de enlaces en la selección de
las rutas del árbol. Por ejemplo, el ancho de banda utilizado en un enlace puede estar
cercano a un límite previamente establecido, y por lo tanto, establecer un camino a través
de éste violaría las restricciones impuestas, en cuyo caso tal enlace es descartado como
parte del árbol.
Las restricciones de árbol, pueden ser tanto límites sobre una medida de rendimiento a
lo largo de los caminos individuales desde fuente a receptores, como pueden ser límites
sobre la “diferencia” de medidas de rendimiento a lo largo de los caminos de una misma
fuente a cualquier par de destinos diferentes. Por ejemplo, se define como límite de retardo
entre paquetes hacia un par de receptores como la “diferencia” entre los retardos fin a fin en
los caminos desde una misma fuente a esos dos destinos. La medida descrita es conocida
como Inter‐receiver delay‐jitter bound.
Según [10], dependiendo de cómo es derivado un árbol restringido a partir de las
métricas de enlace, se pueden clasificar tres tipos de restricciones:
A) Restricciones de Árbol Aditivas:
Para cualquier camino P T(
u,
v)
= (u, i, j, ..., k, v), se dice que el árbol es aditivamente
restringido si:
m(u, v) = m(u, i) + m(i, j) + ... + m(k, v)
donde m(x, y) representa una medida entre un par de nodos cualquiera x, y ∈ T. Por
ejemplo, el retardo fin a fin denotado por d(u, v) desde el nodo u al nodo v, es aditivo, e
igual a la suma del retardo de los enlaces individuales d(i, j) sobre el camino P T(
u,
v)
.
B) Restricciones de Árbol Multiplicativas:
Se dice que un árbol es multiplicativamente restringido si:
m(u, v) = m(u, i) x m(i, j) x ... x m(k, v)
donde m(x, y) representa una medida entre un par de nodos cualquiera x, y ∈ T. Así por
ejemplo, la probabilidad de que un paquete alcance al nodo v desde el nodo u a través del
camino P T(
u,
v)
, denotada por 1 – pL(u, v), es multiplicativa e igual al producto de las
probabilidades de los enlaces individuales (1 ‐ pL(i, j)) sobre el camino P T(
u,
v)
, suponiendo
que la congestión en cada uno de los enlaces individuales pertenecientes al árbol son
independientes entre sí.
C) Restricciones de Árbol Cóncavas:
Se dice que un árbol tiene restricciones cóncavas si:
m(u, v) = min[m(u, i), m(i, j), ... , m(k, v)]
donde m(x, y) representa una medida entre un par de nodos cualquiera x, y ∈ T. Por
ejemplo, el ancho de banda disponible en un camino desde el nodo u al nodo v, denotado
por bw(u, v), es cóncavo e igual al mínimo ancho de banda disponible entre todos los
enlaces pertenecientes al camino P T(
u,
v)
.
17

3.3 Problemas en el Ruteamiento Multipunto
Los problemas de ruteamiento multipunto pueden visualizarse como una coordenada
dentro de una tabla multidimensional [10]. La Tabla 1 permite clasificar de forma simple
los problemas de ruteamiento multipunto a partir de dos dimensiones: tipo de
optimización y tipo de restricción. Cada uno de los elementos en la tabla puede adoptar
una tercera dimensión relativa a la cantidad de restricciones o funciones objetivo que se
desean respetar o alcanzar, respectivamente.
Tipo de Optimización
Tipo de Restricción
Tabla 1 Problemas en el Ruteamiento Multipunto
No existe optimización Optimización de enlaces Optimización de árbol
Sin restricciones Un problema de
optimización de enlace
(orden polinomial)
Restricciones de Enlace
Restricciones de Árbol
Restricciones de Enlace
y de Árbol
Un problema de
restricción de enlace
(orden polinomial)
Un problema de
Múltiples Restricciones
de enlace (orden
polinomial)
Un problema de
restricción de árbol
(tiempo polinomial)
Un problema de
Múltiples Restricciones
de árbol (NP‐completo)
Un problema de
restricción de enlace y
restricción de árbol
(tiempo polinomial)
3.4 Algunos Problemas Particulares
18
Un problema de
restricción de enlace y
optimización de enlace
(orden polinomial)
Un problema de
restricción de árbol y
optimización de enlace,
(orden polinomial)
Un problema de
optimización de árbol
(NP‐completo)
Un problema de
restricciones de enlace y
optimización de árbol
(NP‐completo)
Un problema de
restricciones de árbol y
optimización de árbol
(NP‐completo)
Un problema de
restricciones de enlace y
árbol, y optimización de
árbol (NP‐completo)
En esta sección se presentan algunos problemas particulares asociados a la
construcción de árboles de distribución para grupos multipunto.
3.4.1 Definiciones
Sean dos funciones con valores no negativos asociadas a cada enlace e ∈ E: R(e) y C(e).
+
El retardo de enlace R(e), con R : E → ℜ , es el retardo medio que los paquetes de
datos experimentan en el correspondiente enlace (retardo de propagación +
encolamiento).
+
El costo de enlace C(e), con C : E → ℜ , es una medida de la utilización de los recursos
en el correspondiente enlace. Mayor utilización implica mayor costo.

En general, los enlaces de la red son asimétricos, por lo tanto el costo y retardo de un
enlace desde un nodo u a un nodo v, e = (u, v), es distinto al costo y retardo del enlace
desde el nodo v al nodo u, e’ = (v, u).
+
Se define δ : R → ℜ como la función restricción de retardo. La restricción es válida
para los caminos desde la fuente a cada destino. El retardo desde la fuente vs al destino i,
δ (i)
, puede ser diferente a δ (j)
(retardo desde la fuente vs al destino j), con
i ≠ j,
i,
j ∈ M − { vs
} .
Cuando la restricción de retardo es la misma para todos los destinos, entonces
δ ( i) = ∆,
∀i
∈ M − { vs
} .
Para un nodo fuente vs y un nodo destino d, el grupo de enlaces: e1 = (vs, v1), e2 = (v1, v2),
..., ek = (vk, d), constituyen un camino dirigido P(vs, d) desde vs a d. El costo del camino
dirigido P(vs, d) se define como:
C ( P(
v , d))
=
s
19
∑
C(
e)
e∈P(
vs
, d)
Análogamente, el retardo fin a fin (o retardo fuente a destino) del camino P(vs, d) se
define como:
R ( P(
v , d))
=
s
∑
R(
e)
e∈P(
vs
, d)
La definición que sigue se aplica a sesiones multicast con una sola fuente. Sea un
grupo multicast M = { d1
,..., dn
} ⊆ V , con n = M ≤ V . Sea vs ∈ V una fuente multicast
para el grupo M. Un árbol de fuente especifica T( vs
, M)
es un árbol con raíz en vs y que
se expande a todos los miembros del grupo M. El costo total del árbol T( vs
, M)
es
simplemente la suma de los costos de todos los enlaces pertenecientes a él:
Costo ( T(
v , M))
=
s
∑
C(
e)
e∈T
( vs
, M)
En general, un algoritmo que intente minimizar el costo total del árbol multicast
promoverá la existencia de enlaces que se dirijan hacia más de un miembro en M.
3.4.2 Árboles de Camino más Corto sin Restricciones
La construcción de estos árboles intenta reducir la suma de los largos (en términos de
saltos) de los caminos desde la fuente a cada uno de los destinos. Las propiedades del
árbol dependen de la métrica de interés sobre cada enlace. Por ejemplo, si la métrica de
enlace es costo, entonces la función objetivo es:
min C T s
T( vs
, M)
∈τ
( vs
, M)
( P ( v , d))
∀ d ∈ M ,
donde τ(vs, M) es el conjunto de los posibles árboles que se expanden desde la fuente vs
a todos los destinos en M.
Se debe notar que el costo total de un árbol de camino más corto no necesariamente es
mínimo, dado que el objetivo en este caso es minimizar el largo de los caminos desde la
fuente a los destinos y no el costo total.

3.4.3 Árboles de Steiner sin Restricciones
La función objetivo del árbol de Steiner corresponde a minimizar el costo total del
árbol multicast:
min Costo s
T( vs
, M)
∈τ
( vs
, M)
20
( T(
v , M))
Es conocido el hecho de que el árbol de Stenier mínimo es un problema NP completo.
Para probar la NP completitud del problema del árbol de Stenier éste puede ser
transformado al problema clásico de la cubierta exacta de 3 grupos (Exact Cover by 3‐
sets) [13].
3.4.4 Árboles de Camino más Corto con Restricción de Retardo
Estos árboles minimizan la suma de los largos de los caminos individuales desde
fuente a cada uno de los destinos, sujetos a un límite de retardo. La función objetivo es la
misma que en 3.4.2 , pero sujeto a la restricción:
R T s
s
s
( P ( v , d))
≤ ∆ ∀d
∈ M,
T(
v , M)
∈τ
( v , M)
.
Donde ∆ es el límite de retardo para todos los caminos desde la fuente a cada destino.
3.4.5 Árboles de Steiner con Restricción de Retardo
La función objetivo en este caso es minimizar el costo total del árbol como en 3.4.3,
pero sin violar la restricción de retardo impuesta, tal como en 3.4.4.
El problema de árbol de Steiner de fuente específica con restricción de retardo fue
formulado por primera vez en [14], allí los autores prueban que el problema es NP
completo.
3.4.6 Compromiso entre Costo y Retardo
De acuerdo a [34] encontrar un único árbol multicast de fuente específica que optimice
al mismo tiempo costo y retardo no es posible. Por ejemplo, para un árbol de Steiner de
fuente específica encontrado con la heurística KMB descrita en 4.2.1, el retardo promedio
del árbol está limitado a (|M|‐1)/2 veces el promedio mínimo, donde |M| es el tamaño
del grupo multicast. Similarmente, el árbol de camino más corto que minimiza el retardo
promedio árbol puede ser |M| veces más costoso que el árbol Steiner, aun cuando datos
empíricos muestran que los árboles de camino más corto son levemente (20%) más
costosos que los árboles de Steiner encontrados con algoritmos aproximados, tal como
KMB. Por otro lado, el retardo promedio del árbol de fuente especifica encontrado con
KMB, típicamente es 50% mayor que un árbol de camino más corto.
3.4.7 Eficiencia Multicast
En la introducción de este trabajo se mencionó las ventajas que multicast ofrece sobre
unicast, resaltando el hecho de que multicast reduce la utilización del recurso ancho de
banda de la red, dado que multicast utiliza árboles de distribución para el envío de los
paquetes de datos a los destinos de un grupo. Las secciones previas se refirieron a
distintos problemas respecto a la construcción de los árboles multicast. Sin embargo, ¿son
suficientes las métricas de costo y retardo, consideradas en variadas heurísticas, para
configurar la construcción de los árboles multicast?.

Por otro lado, aparentemente la ventaja de multicast sobre unicast se ve opacada por el
hecho de que muchas aplicaciones multicast involucran grupos dinámicos, donde
miembros pueden unirse o dejar al grupo muy frecuentemente. Este hecho lleva a
preguntarse acerca de la eficiencia que multicast tiene sobre unicast para manejar el
recurso de ancho de banda.
En [20] por primera vez se provee de una comparación definitiva entre multicast y
unicast, asignando un valor monetario a multicast. El trabajo se focaliza en la razón entre
el número total de enlaces multicast en el árbol de distribución y el largo promedio de los
caminos unicast. Los autores determinan que esta razón puede ser concisamente
expresada como una ʺpower lawʺ en términos del número de recibidores.
L m k
= N , donde N es el número de destinos, L u es el largo promedio de un camino
Lu
entre un par de nodos cualesquiera, L u es el número total de enlaces multicast en el
árbol, y k es un factor de escala económica que varía entre 0 y1.
Para evaluar efectivamente la validez de la relación definida en [20] en redes reales, en
[22] se realizó un trabajo experimental. En este trabajo se encontró que en grupos de 20 a
40 recibidores, multicast ofrece de un 60 a 70% de reducción de la utilización de enlaces,
en comparación con el envío de información en flujos unicast separados a cada destino.
La métrica utilizada en [22] no es precisamente la relación definida en [20], pero se basa
en ésta. La eficiencia multicast es representada como el porcentaje de ganancia de
multicast sobre unicast, definida como:
Lm
δ = 1−
, donde Lm es el número de enlaces multicast y Lu la suma de los largos de
Lu
los caminos unicast.
Existen numerosas heurísticas que intentan encontrar solución a los problemas
descritos en esta sección. La sección 4.2 describe algunos protocolos de ruteamiento
multicast y diversas propuestas aparecidas en la literatura. En el capítulo 6 se muestra
una comparación mediante simulación de varios algoritmos de ruteamiento multipunto.
21

E
4 Algoritmos de Ruteamiento Multipunto
n este capítulo se describen algunos protocolos de ruteamiento multicast (4.1) y
algunos algoritmos de ruteamiento multipunto aparecidos en la literatura (4.2), tales
como KMB, CAO, KPP o BSMA.
Entre los algoritmos propuestos en la literatura se menciona una heurística propuesta
recientemente en [36] llamada Best Contribution (BC). El capítulo 6 es dedicado a la
comparación de variadas heurísticas, centrando el interés en BC.
La descripción de los protocolos de ruteamiento multicast (PRM) en 4.1 no incluye una
descripción de los protocolos de ruteamiento unicast (PRU) sobre los cuales los PRM se
basan. Sólo se hace mención de ellos.
4.1 Protocolos de Ruteamiento Multicast y Algoritmos Asociados
A inicios del año 1997 se comenzó a adoptar la concepción de Internet como un
conjunto enlazado de sistemas autónomos (SAs). Desde esa fecha, los protocolos de
ruteamiento desarrollados hasta ese momento pasaron a ser las propuestas de
ruteamiento al interior de los Sas. Adicionalmente, se comenzaron a realizar esfuerzos
para construir estándares en el ruteamiento entre SAs [18]. A continuación se describen
algunos protocolos de ruteamiento multicast que operan tanto al interior de un sistema
autónomo (SA), como entre SAs.
4.1.1 DVMRP [23]
El Distance Vector Multicast Routing Protocol (DVMRP) es un protocolo de vector
distancia, utilizado en el Mbone, y que originalmente fue derivado del protocolo de
ruteamiento unicast RIP (Routing Information Protocol). RIP calcula cada próximo paso
hacia un destino utilizando el algoritmo Bellman‐Ford, en cambio DVMRP computa cada
paso desde los destinos hacia la fuente (hacia atrás), basándose en las tablas unicast que
RIP provee. DVMRP construye árboles de fuente específica, basándose en una métrica de
saltos. Los árboles son construidos bajo demanda, y su creación se inicia cuando una
fuente envía su primer paquete usando el algoritmo Reverse Path Forwarding (RPF).
RPF usa la técnica de “Inundar y Podar” (Flood and Prune). Esta técnica consiste en el
envió de paquetes desde la fuente a todos los routers en la red (flood) bajo un árbol de
expansión mínima (minimum spanning tree) conformado por dichos routers. Tal árbol es
construido como un árbol de camino más corto inverso (reverse‐shortest path tree o
RSPT). El algoritmo RPF toma ventaja de las tablas unicast existentes, y utilizando la
información de estado existente en estas tablas, realiza las siguientes tareas:
(a) Cuando un paquete multicast es recibido, se graba la dirección de la fuente y el
identificador de la conexión de llegada (I).
(b) Si I es una conexión utilizada para enviar un paquete unicast de regreso a la fuente
(RPF check), entonces el paquete es enviado a todas las conexiones, excepto por
donde llegó. Cuando un router detecta que un paquete no está dirigido a ninguno
de los hosts en su subred, entonces él envía un mensaje de “poda” (prune) al router
padre dentro del RSPT. El mensaje de podado tiene una edad asociada, y es
actualizado cada vez que se supera un umbral de tiempo, inundando nuevamente
la red. Esto se realiza con la esperanza de que nuevos miembros puedan unirse
22

(join) al grupo, y además permita al protocolo adaptarse a cambios topológicos de
la red. El Internet Group Management Protocol (IGMP) [24] es usado para detectar
cuando un miembro deja (leave) el grupo. Esta información se pasa “hacia arriba”,
a los router padres, para podar las ramas del árbol que no tengan miembros.
4.1.2 MOSPF [25]
El protocolo Multicast Open Shortest Path First (MOSPF) es una extensión del
protocolo unicast Open Shortest Path First (OSPF), usado al interior de un SA. Cada
router OSPF mantiene una base de datos con el estado de los enlaces en el SA. Esta base
de datos es construida a partir de cinco tipos de “anuncios” llamados LSAs (link‐state
advertisements) que inundan al SA. Cada uno de estos anuncios describe información
local del router o la red. En MOSPF se agrega un nuevo LSA que describe la membresía
del grupo (membership group). Esta información es obtenida a partir del protocolo
IGMP. Cuando un router recibe un paquete multicast, éste computa un árbol de camino
más corto con el algoritmo Dijkstra desde la fuente que envío el paquete, y lo reenvía (el
paquete) a través del árbol que recién computó. Los árboles en cada router son
computados bajo demanda, sin embargo, aun bajo esta consideración, tal situación
resulta poco escalable en el caso de mucha interactividad de los grupos multicast sobre la
red (muchas fuentes).
4.1.3 CBT [26]
El protocolo de ruteamiento multicast Core Based Tree (CBT) es un intento para
mejorar la poca escalabilidad de los protocolos DVMRP y MOSPF, los cuales requieren
mantener información para el ruteamiento, por fuente y por grupo. Además,
periódicamente deben inundar sectores de la red con el fin de activar la etapa de podado.
CBT construye el árbol de distribución basándose en un núcleo, el cual es el centro del
grupo multicast. Cada vez que un nuevo miembro envía un mensaje para unirse al
grupo, este se envía a través del camino más corto hacia el centro, actualizando la
información en los routers a lo largo de este camino. Si un router intermedio recibe de
algún nodo un mensaje de petición de unión al grupo, y este router ya pertenece al árbol,
entonces un acuse de recibo a esta petición (join‐acknowledgement) es enviado hacia
atrás por el mismo camino desde donde se inició la petición. Cada nodo en este camino
agrega a sus interconexiones de entrada y salida las interconexiones para el grupo, y crea
una nueva entrada en la tabla de rutas. En CBT no se distingue entre padres e hijos, aquí
un router está o no está en el árbol. Cuando una fuente envía un paquete a un grupo del
cual no es miembro, esté es direccionado hacia el centro del árbol (que reúne al grupo), y
cuando alcanza al primer nodo en el árbol, desde allí es enviado a todos los miembros del
grupo excepto desde donde llegó. De esta manera no todos los paquetes necesitan ir al
centro del árbol.
El algoritmo de ruteamiento asociado a CBT es equivalente a construir un árbol de
expansión mínima que alcanza a todos los miembros del grupo más el centro. El árbol
que forma CBT es un árbol compartido (entre todas las fuentes del grupo multicast). La
ventaja de utilizar un árbol compartido entre varias fuentes, en vez de usar un árbol de
fuente específica por cada una de ellas, es que la información que deben mantener los
router es sólo información por cada grupo, y no por cada par (fuente, grupo), como
DVRMP o MOSPF lo hacen. Además, CBT usa las tablas unicast de cualquier protocolo
unicast, en contraste con DVMRP y MOSPF que utilizan exclusivamente RIP y OSPF
23

espectivamente. El problema con CBT es la concentración de tráfico que se genera en las
diversas fuentes que depositan sus flujos sólo sobre los enlaces del árbol compartido.
La selección óptima del centro es un problema NP completo [27] y usualmente se
requiere conocer la totalidad de la topología de la red y detalles exactos de la membresía
del grupo.
4.1.4 PIM
Protocol Independent Multicast (PIM) es un protocolo de ruteamiento multicast que
fue creado buscando las características deseables de las dos categorías de estructuras de
árbol: árbol compartido y árbol de fuente específica. PIM tiene dos modos de operación
PIM Dense Mode (PIM‐DM), el cual emplea un árbol de camino más corto inverso,
similar a DVMRP, y PIM Sparse‐Mode (PIM‐SM) el cual emplea un árbol compartido
unidireccional. A continuación se describe en más detalle ambos modos de operación de
PIM.
4.1.4.1 PIM‐DM [28]:
Protocol Independent Multicast – Dense Mode (PIM‐DM) es un protocolo que fue
diseñado para ser usado en grupos con un gran número de miembros, de allí el nombre
PIM de “modo denso”. Tal como en DVRMP, PIM‐DM utiliza el algoritmo RPF con la
técnica “inundar y podar”. Sin embargo, PIM‐DM es independiente del protocolo
unicast presente en la red, él simplemente asume que las tablas de ruteamiento unicast
existen y que son simétricas.
En PIM‐DM, inicialmente los datagramas multicast son inundados a todas las áreas de
la red. El algoritmo RPF es utilizado para prevenir ciclos mientras se produce la
inundación. Si alguna de las áreas de la red no tiene miembros del grupo, PIM‐DM
podará las ramas de esta zona. Cuando un nuevo miembro aparece en un área podada,
un router puede “injertar” una nueva rama en el árbol. PIM‐DM tiene un diseño más
simple comparado con los protocolos de ruteamiento multicast que tienen mecanismos
embebidos de descubrimiento de la topología de la red, tal como DVRMP. PIM‐DM no
requiere de información topológica de la red. Sin embargo, esta simplificación hace que
PIM‐DM incurra en una mayor sobrecarga a causa de las “inundaciones y podas” que le
ocurren a algunos enlaces, que no lo necesitarían si se tuviese mayor información acerca
de la topología de la red, como por ejemplo, si una conexión es útil o no para alcanzar a
miembro del grupo. Básicamente, la diferencia entre DVMRP y PIM‐DM es que en
DVMRP, antes del envío de los paquetes por un cierta conexión, se cerciora de que dicha
conexión conduzca a un nodo que reconozca el nodo local como nodo que está en la
trayectoria más corta entre él y la fuente (esto asegura que en DVRMP el envío de
paquetes se realice a través del camino más corto desde la fuente al destino). A diferencia
de DVMRP, PIM‐DM sacrifica una sobrecarga adicional sobre la red con el fin de
simplificar el algoritmo de envío de paquetes. Aparte de esto, el protocolo es muy
similar a DVMRP y así, todo lo indicado para DVMRP también se aplica a PIM‐DM.
4.1.4.2 PIM‐SM [29]:
El Protocol Independent Multicast – Sparse Mode (PIM‐SM) tal como su nombre lo
indica está diseñado para grupos esparcidos. PIM‐SM es un protocolo que puede usar la
información unicast de ruteamiento subyacente o construir su propia base de
información para el ruteamiento. PIM‐SM construye por cada grupo un árbol
24

compartido unidireccional basados en un punto de encuentro (Rendezvous Point, RP).
Además, opcionalmente construye un árbol de camino más corto por cada fuente. La
principal función de las tablas de rutas en PIM‐SM es proveer el próximo paso en la ruta
a lo largo de un posible camino multicast hacia cada subred destino. La información de
las tablas de rutas es usada para determinar el próximo paso que debe seguir un mensaje
de unión o poda hacia un router vecino. Los datos fluyen a través del camino inverso de
los mensajes de unión. Los mensajes de unión fluyen desde destino a fuente,
normalmente a través del RP. Análogamente a todos los protocolos de ruteamiento que
implementan el modelo de servicio del RFC 1112 [30], PIM‐SM debería ser capaz de
rutear los paquetes desde la fuente hasta los destinos sin que cualquiera de las fuentes o
destinos conozca a priori la existencia de los otros. Esto se realiza esencialmente en tres
fases, aun cuando fuentes y destinos podrían irse en cualquier momento, ocurriendo las
tres fases al mismo tiempo.
Primera fase, Árbol RP (RP Tree): Los destinos expresan su interés en recibir tráfico
destinado a un cierto grupo multicast. Esto se hace típicamente usando IGMP o MLD
(Multicast Listener Discovery [31]. Alguno de los routers locales del destino es elegido
como el “router designado” (DR‐ Designated Router) de la subred. Cuando el DR recibe
un mensaje que expresa el interés del destino por unirse a un grupo G, entonces él envía
un join message que es conocido como (*, G) Join. El * indica que el grupo no tiene
solamente una fuente específica. El mensaje (*, G) Join viaja salto a salto hacia el RP del
grupo, y cada vez que este mensaje pasa por un router, el estado del árbol multicast para
el grupo G es actualizado. Generalmente el mensaje (*, G) Join alcanzará el RP o algún
router que ya a recibido un mensaje (*, G) Join. Cuando varios destinos han pedido
unirse al grupo G, y sus mensajes de unión han convergido al RP, éstos formarán un
árbol de distribución para el grupo G, con origen en el RP. Este árbol es conocido como
RP Tree (RPT), el cual es compartido por todas las fuentes que envían datos a un mismo
grupo. Los mensajes de unión son reenviados periódicamente a los destinos que
permanecen en el grupo. Cuando todos los destinos sobre una red hoja dejan el grupo, el
DR envía un mensaje de poda (PIM (*, G) Prune) hacia el RP del grupo multicast. No
obstante, si por alguna razón el mensaje de poda no es enviado, el estado del árbol
caduca, ya que éste tiene un tiempo de expiración asociado. Cuando una fuente
multicast comienza a enviar paquetes destinados a un grupo, el router local a la fuente
(DR) toma aquellos datos, los encapsula como unicast, y los envía directamente al RP. El
RP destino entonces recibe los paquetes de datos encapsulados, los desencapsula, y los
envía sobre el árbol compartido. Los paquetes entonces siguen las rutas establecida por
el árbol multicast del grupo (*, G), siendo replicados en todas las ramas del tal árbol. Así
normalmente los paquetes alcanzarán todos los destinos del grupo multicast. El proceso
de encapsulamiento de los paquetes de datos es llamado “registering” (registro) y los
paquetes encapsulados son llamados “PIM register packets”. Al final de la fase uno, el
tráfico multicast esta fluyendo encapsulado al RP, y desde éste a los destinos multicast.
Fase dos, Parada de Registro (Register Stop): El registro de la encapsulación resulta
ineficiente por dos razones:
1) La encapsulación y desencapsulación podría ser una operación relativamente
costosa de ejecutar para un router, dependiendo si el router tiene o no un hardware
apropiado para esta tarea.
2) Viajar a través de todo el camino al RP, y sólo entonces volver al árbol compartido
podría provocar que los paquetes viajen una distancia relativamente larga para alcanzar
los destinos que están cercanos a una fuente. Para algunas aplicaciones el incremento de
25

la latencia (tiempo que transcurre hasta recibir correctamente un paquete) es indeseable.
Dado que el proceso de registro podría continuar indefinidamente, el RP elegirá soportar
un envío nativo. Esto significa que cuando el RP recibe un paquete de datos de registro
encapsulado desde una fuente S en un grupo G, entonces será iniciado un mensaje (S, G)
Source‐Specific Join hacia S. Este mensaje viaja salto a salto hacia S, instanciando el árbol
multicast (S, G) en los routers a lo largo del camino. La información de rutas del árbol
multicast (S, G) es usada sólo para enviar paquetes al grupo G si es que aquellos paquetes
provienen de la fuente S. Los mensajes de unión que alcancen la subred de S o algún
router que ya tiene la información del árbol multicast (S, G), entonces los paquetes de S
comienzan a fluir siguiendo por las rutas del árbol (S,G) hacia el RP. Estos paquetes de
datos podrían alcanzar routers con estado (*, G) a lo largo del camino hacia RP, si esto
ocurre, ellos pueden tomar un atajo sobre el árbol RP a éste punto. Mientras el RP está en
proceso de unir al árbol de fuente específica de S, los paquetes de datos continuarán
siendo encapsulados y enviados al RP. Cuando los paquetes de S también comienzan a
llegar “nativamente” al RP, el RP estará recibiendo dos copias de cada paquete. En este
instante, el RP comienza a descartar las copias encapsuladas, y envía un mensaje
Register‐Stop (hacia atrás) al DR de S para prevenir el encapsulamiento innecesario de
paquetes. Al final de la etapa dos, el tráfico estará fluyendo nativamente desde S a través
de un árbol de fuente específica hacia los destinos. En el lugar donde los dos árboles se
interceptan, el tráfico podría ser transferido del árbol de fuente específica al árbol RP, y
así se evita tomar la bifurcación a través del RP. Se debe tener en cuenta que una fuente
podría comenzar a enviar datos antes o después que un destino se una al grupo, y de esta
manera la fase dos podría suceder antes de que el árbol compartido hacia los destinos sea
construido.
Fase tres, Árbol de Camino más Corto (Shortest‐Path Tree): Aun cuando se ha
removido el overhead de encapsulación, esto no significa que las rutas elegidas sean
optimas. Para muchos destinos, la ruta a través del RP podría significar un desvío
significativo comparado con el camino más corto de la fuente a tal destino. Para obtener
baja latencia, un router sobre una LAN de un destino, típicamente el DR, podría
opcionalmente iniciar la transferencia del árbol compartido a un árbol de fuente
específica, de camino más corto (SPT). Al hacer esto, él envía un (S, G) Join hacia S. Este
mensaje instancia la situación en los routers a lo largo del camino a S. Cuando el mensaje
de unión alcanza la subred de S o algún router que ya tiene la información del estado de
(S, G), los paquetes de datos de S comienzan a fluir siguiendo el las rutas del árbol de (S,
G) hasta alcanzar los destinos. En este instante los destinos (o un router camino a los
destinos) estarán recibiendo dos copias de datos, una desde el SPT y otra desde el RPT.
Cuando el primer tráfico comienza a llegar del SPT, el DR o router en el camino
(upstream) comienza a descartar los paquetes para G desde S que llegan vía el árbol RP.
Además, él envía un (S, G) Prune message (mensaje de poda (S, G)) hacia el RP. Esto se
conoce como (S, G, rpt) Prune. El mensaje de poda viaja salto a salto, instanciando el
estado a lo largo del camino hacia el RP indicando que el tráfico de S para G no debería
ser enviado por este camino. El mensaje de poda es propagado hasta que alcanza al RP o
a un router que requiera el tráfico de S para otros destinos. Por ahora, los destinos
estarán recibiendo tráfico de S a través del árbol de camino más corto entre los destinos y
S. Además, el RP estará recibiendo el tráfico de S, pero tal tráfico ya no estará alcanzando
a los destinos a través del árbol RP. Para los destinos, el árbol de camino más corto es el
árbol de distribución final.
26

4.1.5 BGMP [32]
Border Gateway Multicast Protocol (BGMP) es un protocolo que permite realizar
ruteamiento entre dominios. BGMP construye árboles compartidos para grupos multicast
activos, y opcionalmente permite a dominios destino construir ramas de fuente específica
distribuidas entre dominios si es necesario.
Este protocolo sugiere que los árboles multicast construidos bajo una política de árbol
compartido, tienen un mejor comportamiento cuando utilizan algún mecanismo que
opera con un representante del grupo, en donde los miembros reciben los paquetes de
datos desde las fuentes sin que exista una inundación global, tal como PIM‐DM y
DVRMP que inicialmente inundan la red con paquetes de datos, o MOSPF que inunda la
red con información de membresía del grupo.
PIM‐SM y CBT usan árboles compartidos, en donde todos los miembros del grupo
reciben noticias de todas las fuentes, pero los nodos que no son miembros no tienen
información acerca de las fuentes. Los árboles que construye BGMP siguen el concepto
de construcción de PIM‐SM y CBT (árbol compartido). BGMP requiere que cada grupo
multicast global sea asociado con una sola raíz o representante del dominio, más que un
solo router, para construir los árboles compartidos entre dominios. BGMP asume que un
determinado rango del espacio de direcciones ha sido asociado a un cierto grupo de
dominios seleccionados. Así, cada dominio tendrá un representante (o raíz) en el árbol
compartido (entre dominios). En la Fig. 4 el dominio raíz corresponde al dominio D. La
figura muestra como BGMP implementa multicast entre seis sistemas autónomos. El
grupo multicast existente consiste de las fuentes S1 y S2 en los dominios B y A
respectivamente, más los destinos R1, R2 y R3. El dominio B es el dominio raíz del grupo
multicast, y el árbol compartido (en línea continua bidireccional) es creado a partir de él.
Puesto que el dominio C no tiene nodos pertenecientes al grupo, este no es incluido en el
árbol compartido. Se debe notar que los paquetes generados en el dominio B atraviesan
el dominio F para alcanzar a los dominios A y E. Los paquetes originados en la fuente S2
en el dominio A alcanzan al destino R3 en el dominio E vía el router borde en el dominio
F. Como los router bordes en el dominio A y E están directamente conectados, el destino
R3 puede establecer una rama de fuente específica (en línea segmentada) a partir del
camino más corto desde la fuente S2 al él. El destino R3 podrá recibir paquetes desde la
fuente S2 por la rama de fuente específica, y desde otras fuentes a través del árbol
compartido.
27

Fig. 4 Ejemplo que muestra el árbol compartido y rama de fuente específica que el protocolo BGMP puede
construir entre sistemas autónomos, los cuales pueden estar utilizando algún otro protocolo multicast al interior
de ellos.
Los protocolos antes descritos son protocolos que operan en la capa de red, en cambio
BGMP es un protocolo que opera en la capa de aplicación, y utiliza TCP (Transport
Control Protocol) como protocolo de capa de transporte. Esta situación elimina la
necesidad de implementar mensajes de fragmentación, retransmisión, acuses de recibo y
secuenciación. BGMP usa el puerto 264 de TCP para establecer las conexiones. Cada
conexión TCP intercambia mensajes para abrir y confirmar los parámetros de la conexión.
Entonces, se envían incrementalmente actualizaciones de Join/Prune según los cambios
en la membresía del grupo. BGMP no requiere refrescar periódicamente las entradas
individuales. Existen mensajes de expiración que son enviados periódicamente para
asegurar la subsistencia de una conexión. También existen mensajes de notificación que
son enviados en respuesta a errores o condiciones especiales. Si una conexión encuentra
una condición de error, un mensaje de notificación es enviado y la conexión se cierra si se
trata de un error con status de “fatal”.
28

A continuación se mencionan tres algoritmos que son utilizados por protocolos de
ruteamiento.
4.1.6 Algoritmo RPF
El algoritmo RPF, reverse path forwarding fue propuesto en [33] y usa la técnica de
inundar la red. Cada paquete es enviado desde la fuente a los destinos sobre el camino
más corto inverso (de destino a fuente). RPF puede crear un árbol de camino más corto
sólo en redes simétricas.
Dos extensiones de RPF, el algoritmo TRPB (Truncated Reverse Path Broadcasting) y
RPM (Reverse Multicast Path) son propuestas en [7]. RPF, TRPB y RPM son algoritmos
distribuidos que se basan en información limitada de los nodos en la red, y tienen
implementaciones que permiten operar con grupos dinámicos. Las características de
estos algoritmos les permiten ser soluciones escalables, aunque en muchos casos no sean
eficientes. Las características de escalabilidad en una algoritmo resultan (en la práctica)
ser una factor determinante para su futura implementación.
4.1.7 Algoritmo Dijkstra
Dijkstra es un algoritmo bastante conocido en el ámbito de los algoritmos que
construyen árboles de fuente específica y camino más corto. El protocolo PIM‐DM se
basa en este algoritmo para encontrar el camino más corto desde un destino al RP. La
estructura del árbol resultante es un árbol de mínima expansión que alcanza a todos los
nodos de la red, y se ejecuta en tiempo polinomial. Una implementación simple de este
algoritmo se encuentra en [12].
4.1.8 Algoritmo Bellman‐Ford
El algoritmo Bellman‐Ford, al igual que el algoritmo Dijkstra es un algoritmo bastante
conocido en el ámbito de los algoritmos que construyen árboles de camino más corto y
fuente específica.
El protocolo DVMRP basa sus tablas de ruteamiento en la tablas del protocolo de
ruteamiento unicast RIP, las cuales son construidas a partir del algoritmo Bellman‐ Ford.
La diferencia de este algoritmo con Dijkstra, es que considera pesos negativos y
positivos para los enlaces del grafo que representa la red. Una implementación simple de
este algoritmo se encuentra en [12].
29

4.2 Algoritmos de Ruteamiento aparecidos en la Literatura
En la sección 3.4 se mencionaron diversos problemas asociados a la construcción del
árbol de distribución para un grupo multipunto. En la literatura han aparecido diversas
propuestas que mediante heurísticas intentan resolver el problema de minimizar el costo
total del árbol, con o sin restricciones. Esta sección, a diferencia de la anterior que
presenta protocolos de ruteamiento multicast, describe algunos de los algoritmos de
ruteamiento multipunto propuestos en la literatura.
4.2.1 KMB [35]
Este algoritmo es una heurística que utiliza como función objetivo minimizar el costo
del árbol multicast, sin tomar en cuenta alguna restricción. KMB se aprovecha del hecho
que la construcción de un árbol de expansión mínima se realiza en tiempo polinomial.
Sea G = (V, E) el grafo que representa la red. Sea M el conjunto de nodos destino. El
algoritmo opera bajo cinco pasos fundamentales:
1. Usando los nodos del grupo multicast, se construye un grafo cerrado no dirigido G1,
tal que para cada par de nodos (u, v) pertenecientes al grupo multicast M, G1 tenga un
camino P(u, v) tal que su costo sea igual al costo del camino más corto entre u y v en
G.
2. Se encuentra el árbol de mínima expansión T1 del grafo cerrado G1. (Si hay más de
uno se selecciona cualquiera).
3. Se construye un grafo G2 que reemplaza cada enlace de T1 por el correspondiente
camino más corto en G. (si hay más de un camino más corto se elige alguno
arbitrariamente).
4. Se encuentra el árbol de mínima expansión T2 del grafo G2. (Si hay más de uno se
selecciona cualquiera).
5. Se construye el árbol de Steiner Tm, borrando enlaces en T2, tal que las hojas de Tm
alcancen a todos los destinos del grupo M.
La Fig. 5 ejemplifica las iteraciones de KMB. El grupo corresponde a M = {1, 2, 3, 4}. En
Fig. 5a se muestra al grafo G que representa la red. En Fig. 5b se muestra al grafo G1. En
Fig. 5c se muestra árbol de mínima expansión T1 del grafo G1. En Fig. 5d se muestra el
grafo G2. En Fig. 5e se observa el correspondiente árbol de mínima expansión T2 del
grafo G2. Finalmente en la Fig. 5e se muestra el árbol resultante Tm.
(a) Grafo que representa la red
30

(b) Grafo G1 (c) Árbol T1 de G1
(d) Grafo G2 de G (e) Árbol T2 de G2
(f) Árbol Tm
Fig. 5 Ejemplo Pasos Algoritmo KMB
31

4.2.2 BC [36]
BC (Best Contribution) es una familia de heurísticas donde cada una de ellas utiliza
distintas funciones objetivo. La metodología para construir árboles de distribución es la
misma para todas las heurísticas en la familia y no son consideradas restricciones.
BC se basa en la idea de que cada enlace en el árbol de distribución es un enlace que
fue agregado porque en algún momento ofreció la mejor contribución para acercar a
todos los miembros del grupo simultáneamente. BC opera bajo tres pasos
fundamentales:
1. Inicialmente se escoge en forma aleatoria algún miembro del grupo, el cual
constituye el árbol parcial inicial, que se va expandiendo hacia los demás miembros
del grupo.
2. Se elige el enlace frontera del árbol parcial que mejor contribuya a acercar a todos
los miembros del grupo que aun no forman parte del árbol parcial. El enlace que
mejor contribuye es aquel que maximiza (o minimiza) una función objetivo
escogida. Si existen dos o más enlaces con la misma contribución se elige
cualquiera. Nunca es elegido un enlace que conecta a un nodo que ya está en el
árbol. Esta operación se repite hasta que todos los miembros del grupo forman
parte del árbol de distribución.
3. Finalmente, en caso que el árbol de distribución posea algunas hojas que no son
miembros del grupo, entonces éstas son podadas del árbol.
Sea G = (V, E) el grafo que representa la red, M el conjunto de nodos destino, T el árbol
parcial que conecta uno o más miembros del grupo, B el conjunto de enlaces (u, v) tal que
u ∈ T y v ∉ T, con B ⊆ E. A los enlaces pertenecientes a B se les llama enlaces frontera. Se
denominan nodos frontera los nodos conectados a un enlace frontera, pero que no están en
T.
Sea O el conjunto de miembros aún no conectados a T y c(b) la contribución del enlace b
∈ B para conectar un nodo o ∈ O a T, entonces:
∑
o∈O
1
c(
b)
= ,
f ( b,
o)
donde f(b, o) es alguna función que corresponde al costo del camino desde T a O que
comienza en el enlace frontera b y termina conectando al nodo o ∈ O. El costo c(b) puede
contener diferentes métricas (suma de los anchos de banda del camino, retardos de fuente
a destinos, cantidad de saltos del camino, etc.). Cada término de la suma, 1/f(b, o),
corresponde a la contribución que el enlace b aporta para acercar el nodo o ∈ O a T.
Si b* ∈ B es el enlace que es usado para expandir el árbol de distribución parcial,
entonces b* cumple la condición:
c(
b*)
=
max{
c(
b)}
b∈B
32

A modo de ejemplo, tres funciones f(b, o) son descritas a continuación:
f1(b, o) = 1 + d(adj(b), o), donde adj(b) es un nodo frontera que se contecta a T por medio
de un enlace fontera b ∈ B. La distancia d(adj(b), o) es medida por el número de saltos en
el camino más corto que comienza en el nodo frontera adj(b) y termina en el nodo o ∈ O.
f2(b, o) = BW(adj(b),o), donde BW(adj(b), o) es la suma de los anchos de banda que están
siendo utilizados en cada enlace que conforma el camino desde el nodo adj(b) hasta el
nodo o ∈ O.
f3(b, o) = (1 + d(adj(b), o))⋅BW(adj(b)), donde BW(adj(b)) es el ancho de banda que está
siendo utilizado por el enlace frontera b que conecta un nodo de T al nodo adj(b).
Las heurísticas que utilizan funciones objetivo como f1(b, o) o f3(b, o), sólo requieren
información local para operar (utilizan como base las tablas de ruteamiento de algún
protocolo unicast activo en la red), sin embargo si una heurística utiliza a f2(b, o) como su
función objetivo, ésta requiere de información global para la operación, correspondiente
al ancho de banda utilizado en todos los enlaces de la red. El mantenimiento de esta
información no sólo utiliza memoria en los routers en la red, si no que también carga los
enlaces al realizar las actualizaciones de información. A su vez, el manejar información
global de la red, permite a la heurística tomar decisiones que pueden ser más cercanas a
la obtención de un árbol de mínimo costo. En consecuencia, la elección de la función de
contribución será un compromiso entre el desempeño que logre el algoritmo y el manejo
que éste efectúe de la información.
Para ejemplificar la secuencia de iteraciones que realiza BC, se considera como ejemplo
la red (grafo) de la Fig. 1. La Fig. 6 muestra como la heurística BC con f1(b, o)
correspondiente a 1 + d(adj(b), o) construye el árbol de distribución desde A hacia los
destinos F, J y G agregando un enlace al árbol parcial en cada iteración. Así por ejemplo,
para el enlace b1 definido como el enlace que conecta los nodos A y B, se tiene que f1(b1, F)
= 2, f1(b1, G) = 3, f1(b1, J) = 4, y por lo tanto:
c ( b )
1
= ∑
o∈O
1
=
f ( b , o)
Análogamente para b2 = (A, D), b3 = (A, C) se tiene que:
1
1
1
2
33
+
1
3
+
1
4
=
1.
083
1 1 1 1
c ( b2
)
= + + = 0.
999 ,
f ( b , o)
3 3 3
c ( b
= ∑
o∈O
1
2
1
=
f ( b , o)
3 ) = ∑
o∈O
1 3
+ + = 1.
083
En consecuencia, cualquiera de los enlaces b1 y b3 puede ser elegido como el enlace que
ofrece la mejor contribución para expandir el árbol parcial (en la primera iteración) que
contiene solamente al nodo A, debido a que c ( b1)
= c(
b3)
. Suponiendo que se elige el
enlace b1, la Fig. 6, (a), (b), (c), (d) y (e), ilustran las decisiones que toma el algoritmo
sucesivamente hasta generar completamente el árbol de distribución.
1
2
1
3
1
4

(a) (b)
(c) (d)
Fig. 6 Iteraciones Heurística BC con una función de contribución que considera una métrica de saltos
34
(e)

4.2.2.1 Simplificación Heurística BC
La ejecución de BC en condiciones donde la red es de gran tamaño y el grupo multicast
es relativamente pequeño y disperso en la red, tiende a realizar muchas más iteraciones
que en el caso de grupos densos y redes de tamaño menor. Esto se debe a que en cada
iteración se evalúa la contribución de todos los nodos frontera al árbol parcial para
acercar a destinos que aun no son parte del árbol de distribución. Con el fin de disminuir
la cantidad de información que se procesa para ejecutar BC, se realizó una simplificación
que consiste en evaluar sólo la contribución de los nodos frontera al último nodo
agregado al árbol parcial, en el caso de que éste no sea un destino. Si el último nodo
agregado al árbol parcial es un destino, entonces se evalúa la contribución de todos los
nodos frontera al árbol parcial, tal como BC opera en cada una de sus iteraciones. Se
debe notar que la simplificación recién descrita no requiere efectuar el tercer paso de la
operación de BC.
Esta simplificación se fundamenta en que cuando se ha elegido agregar un cierto
enlace frontera que conecta a un determinado nodo, es bastante probable que el enlace
que se agregará en la próxima iteración emane desde el nodo recién agregado. Esto es así
debido a que el algoritmo evalúa una función objetivo ʺglobalʺ, que considera acercarse a
todos los destinos aun no agregados al árbol parcial, por lo tanto, si se ha elegido agregar
un cierto nodo, en la siguiente iteración la contribución de los enlaces que son adyacentes
a él, tendrán una contribución aun mayor que el enlace recién agregado pues se está más
cerca del objetivo global (acercar a todos los destinos el árbol de distribución parcial).
Intuitivamente la simplificación que da origen a BCL acelerará el proceso de
generación del árbol de distribución final, dado que cada destino es agregado en un
menor tiempo debido a que las iteraciones de la heurística disminuyen. Por ejmplo, el
número de iteraciones que la heurística BCL ejecuta para construir el árbol de
distribución final de la Fig. 6 es 31, a diferencia de las 37 que ejecuta BC. Además, ambas
heurísticas obtienen el mismo árbol final. Se espera que para grupos dispersos y redes
amplias la reducción en las iteraciones sea mucho más drástica.
La Fig. 7 muestra el pseudocódigo de la heurística BC, y la Fig. 8
Fig. 8 muestra el pseudocódigo de la heurística recién descrita, a la que se ha
denominado Best Contribution Light (BCL).
35

Pseudocódigo Huerística BC
INPUT
G(V, E) : Grafo que representa la red
s : nodo fuente
M : conjunto de nodos destino
Tj : Árbol parcial en la iteración j.
Adyij : nodo adyacente al ni(Tj).
ni(Tj): nodo i perteneciente a Tj. Note que i puede tomar valores entre 0 y el número total de nodos en Tj.
Tf : Árbol de distribución final: correspondiente a Tj en la última iteración del algoritmo después de
aplicar la PODA.
Contr(Adyij) : Contribución de Adyij
ElMejor : Nodo conectado a través del enlace frontera con la mayor contribución en la iteración j
MayorContr : Valor de la contribución de ElMejor
Max : Contribución de un nodo Adyij cuando es inalcanzable desde ni(Tj), (por saturación de enlaces por
ejemplo).
FUNCIONES
EVALCONTRIBUCION : Función que evalúa la contribución de un nodo según la HEURISTICA que defina a BC.
(HEURISTICA define la función f.o. que se utilizará para acercarse a un árbol de Steiner que minimice el objetivo)
PODA : Función que poda las hojas del árbol parcial en la última iteración. Su objetivo es eliminar aquellos nodos ʺhojaʺ que
no son destinos.
OUTPUT
Árbol de Distribución que alcanza a todos los nodos en M y a la fuente (Tf)
BC
j ← 0;
T0 ← s;
MayorContr ← 0;
AllDest ← 0;
Termino = False;
while (Termino = False ) {
do {
while (Adyij ≠ NULL) {
if (Adyij ∈ Tj) then
i++;
end if
else
Contr(Adyij) ← EVALCONTRIBUCION(Adyij);
if (MayorContr

Pseudocódigo Huerística BCL
INPUT
G(V, E) : Grafo que representa la red
s : nodo fuente
M : conjunto de nodos destino
Tj : Árbol parcial en la iteración j.
Adyij : nodo adyacente al ni(Tj).
ni(Tj): nodo i perteneciente a Tj. Note que i puede tomar valores entre 0 y el número total de nodos en Tj.
Tf : Árbol de distribución final: correspondiente a Tj en la última iteración del algoritmo después de
aplicar la PODA.
Contr(Adyij) : Contribución de Adyij
ElMejor : Nodo conectado a través del enlace frontera con la mayor contribución en la iteración j
MayorContr : Valor de la contribución de ElMejor
Max : Contribución de un nodo Adyij cuando es inalcanzable desde ni(Tj), (por saturación de enlaces por
ejemplo).
FUNCIONES
EVALCONTRIBUCION : Función que evalúa la contribución de un nodo según la HEURISTICA que defina a BC.
(HEURISTICA define la función f.o. que se utilizará para acercarse a un árbol de Steiner que minimice el objetivo)
OUTPUT
Árbol de Distribución que alcanza a todos los nodos en M y a la fuente (Tf)
BCL
j ← 0;
T0 ← s;
MayorContr ← 0;
AllDest ← 0;
Termino = False;
DifBC = False;
while (Termino = False ) {
do {
while (Adyij ≠ NULL) {
if (Adyij ∈ Tj) then
i++;
end if
else
Contr(Adyij) ← EVALCONTRIBUCION(Adyij);
if (MayorContr

4.2.3 CDKS [37]
Este algoritmo es una heurística que utiliza como función objetivo minimizar el costo
del árbol multicast, tomando en cuenta una restricción de retardo para los caminos de
fuente a destinos.
Sea G = (V, E) el grafo que representa la red, M el conjunto de nodos destino, ∆ el límite
de retardo para los caminos de fuente a destino. El algoritmo opera bajo tres pasos
fundamentales:
1. Se intenta computar un árbol de bajo costo T1 = (V1, E1) con raíz en la fuente vs y que
se expanda a todos los nodos destinos pertenecientes a M usando el algoritmo
Dijkstra de camino más corto y respetando el límite ∆ para el retardo de los
caminos.
2. Se computa el árbol basado en la fuente con camino de menor retardo T2 = (V2, E2)
que se expande a aquellos nodos destino en M que no están en V1 (usando el
algoritmo Dijkstra de camino más corto basado en la métrica de retardo).
3. Se combinan T1 y T2 para construir el árbol multicast final que incluye todos los
miembros del grupo. Se debe notar que podrían aparecer ciclos al combinar T1 y
T2. Esto ocurre porque T2 podría ser incluido en el árbol final, y algunos de los
enlaces en T1 podrían ser removidos cuando los ocurren los ciclos. Los ciclos
pueden detectarse fácilmente chequeando si T1 y T2 contienen algún nodo en
común.
La Fig. 9 muestra la operación el algoritmo mediante los pasos recién descritos.
4.2.4 CAO [38]
CAO (Constrained Adaptive Ordering) es una de las heurísticas (la de mejor
rendimiento) propuestas en [38]. CAO es siempre capaz de construir un árbol de Steiner
restringido, si es que este existe, ya que el algoritmo realiza una búsqueda exhaustiva.
CAO utiliza como base el algoritmo CMIC (Constrained Minimum Incremental Cost),
también propuesto en [38]. El algoritmo CMIC utiliza la estrategia de costo cero de la
heurística MIC (Minimum Incremental Cost) [38].
La heurística MIC toma ventaja del hecho que el costo de un enlace perteneciente a
varios caminos dirigidos a diversos destinos es compartido (se contabiliza una sola vez).
Cuando un enlace de este tipo es elegido para ser parte del árbol, el costo que este enlace
tiene para los siguientes cálculos será considerado cero. Para minimizar el impacto del
costo de alcanzar un destino no conectado al árbol, el algoritmo debería encontrar un
camino de mínimo costo incremental para que un destino no conectado alcance el árbol.
Esto se hace eligiendo el camino de menor costo entre el destino y todos los nodos
existentes en el árbol parcial.
En CMIC, se ejecuta CBF (Constrained Bellman Ford) [38] para cada destino es un
orden arbitrario. Después de cada ejecución el costo del camino resultante es establecido
a cero para el resto de los destinos. El algoritmo CBF encuentra caminos independientes
de mínimo costo entre la fuente y un grupo de nodos destinos, donde cada destino
establece una cierta restricción de retardo. CBF utiliza una búsqueda por cercanía
(breadth‐first search), encontrando los caminos a partir de incrementar monotónicamente
el retardo, mientras se registra y actualiza el camino de menor costo a cada nodo visitado.
CMIC termina cada iteración con CBF cuando se excede la mayor restricción.
38

(a) Grafo que representa la red
(b) Paso 1
(c) Paso 2
(d) Paso 3
Fig. 9 Ejemplo para visualizar la operación del algoritmo CDKS.
39

4.2.5 BSMA [39]
BSMA (Bounded Shortest Multicast Algorithm) es una heurística que utiliza como
función objetivo minimizar el costo del árbol multicast, tomando en cuenta una
restricción de retardo para los caminos de fuente a destinos.
Sea G = (V, E) el grafo que representa la red, M el conjunto de nodos destino y δi la
restricción de retardo asociada a cada camino desde fuente a destino. Note que si δi tiene
el mismo valor para todos los destinos, entonces δi = ∆, ∀ i ∈ M.
BSMA opera bajo los siguientes tres pasos fundamentales:
1. Se construye un árbol inicial T0 basado en la fuente con camino de menor retardo a
cada uno de los nodos en M, utilizando el algoritmo Dijkstra.
2. Se evalúa si cada uno de los caminos desde fuente a destino computados en (1)
cumple la restricción de retardo impuesta.
3. Si uno o más caminos no cumplen las restricciones, se negocia con los destinos un
alza en la restricción. Si todas las restricciones son cumplidas, T0 es refinado
iterativamente para construir un árbol de bajo costo, sin violar las restricciones de
retardo.
El árbol obtenido en cada refinamiento en (3) es llamado árbol de configuración y el j‐
ésimo árbol de configuración se denota por Tj. El refinamiento de Tj a Tj+1 (donde
inicialmente j = 0) es llevada a cabo por una operación llamada “delay‐bounded path
switching” (cambio de camino limitado en retardo).
La Fig. 10 muestra la red utilizada como ejemplo para describir la operación de las
iteraciones que BSMA realiza para disminuir el costo del árbol T0. La Fig. 11 ilustra las
iteraciones llevadas a cabo por la operación “delay‐bounded path switching”.
Fig. 10 Red utilizada como ejemplo de visualización de las iteraciones de BSMA
40

(a)
(b)
Fig. 11 Refinamiento de los caminos Fuente a Destinos condicionado al límite de retardo. (a) Árbol de camino
de menor retardo (T0). Remoción del camino fuente‐destino de mayor costo 〈s, d, c〉 desde T0. (b) Remoción del
camino fuente‐destino s c . T0 es particionado en dos árboles disjuntos 1
T y 2
0 T . (c) Se agrega el camino fuente‐
0
destino f c . Se reconecta 1
T y 2
0 T a través del camino más corto 〈f, a, c〉 y entre los dos árboles se obtiene T1.
0
41

4.2.6 KPP [14]
KPP es una heurística que utiliza como función objetivo minimizar el costo del árbol
multicast, tomando en cuenta una restricción de retardo para los caminos de fuente a
destinos. KPP asume que la restricción de retardo toma un valor entero, mientras que el
costo de un enlace puede tomar valores reales.
Sea el camino más barato restringido (constrained cheapest path) entre el nodo u y v, el
camino de menor costo desde u a v, tal que el retardo sea menor que δ(u,v) (restricción). Sea
G’ un grafo en G = (V, E), tal que G’ cubre todos los nodos en V y los enlaces son del tipo
constrained cheapest path.
Dada una fuente s y un conjunto de nodos destinos M, KPP ejecuta fundamentalmente
los siguientes tres pasos:
1. Se construye un grafo cerrado G’ sobre {vs} ∪ M, restringido en retardo.
2. Usando el algoritmo Prim [15] se obtiene el árbol de expansión mínima del grafo
cerrado G’. Comenzando con el nodo fuente vs, el árbol es incrementado
expandiéndose, agregando un enlace a la vez, hasta que todos los destinos estén
incluidos. El enlace seleccionado en cada iteración cumple con: (a) conectar a un
nodo que esta en el árbol con uno que está fuera de él. (b) no viola la restricción de
retardo. (c) minimiza una cierta función objetivo.
3. Se reemplazan los enlaces en el árbol de expansión mínima con los caminos del
grafo original.
KPP propone dos funciones objetivo: una de costo de enlace (fC) y otra que encuentra
un compromiso entre minimización de retardo y costo (fCD). KPP tiene una versión
centralizada y otra distribuida.
Las funciones fC y fCD se muestra a continuación:
f CD
⎧ C(
v,
w)
⎪
( v,
w)
= ⎨∆
− ( P(
v)
+ D(
v,
w))
⎪
⎩ ∞
⎧C(
v,
w)
fC ( v,
w)
= ⎨
⎩ ∞
donde
C(v,w) : Costo del enlace (v,w)
P(v) : Retardo del camino desde la fuente a v
D(v,w) : Retardo desde el nodo v al nodo w
∆ : Restricción de retardo
si P(v) + D(v,w) < ∆
en cualquier otro caso
si P(v) + D(v,w) < ∆
en cualquier otro caso
La Fig. 12 muestra la red utilizada como ejemplo para ilustrar la operación del
algoritmo KPP con ambas funciones objetivo y el árbol de Steiner asociado al grupo
multicast conformado por los nodos A, B, D, E y H, más la fuente F. Las Fig. 13 y Fig. 14
muestran las sucesivas iteraciones para encontrar el árbol final, con ambas funciones
objetivo: fC y fCD.
42

Fig. 12 Red de ejemplo para ilustrar la operación de KPP y el árbol de Steiner asociado al grupo multicast
Fig. 13 Grafo cerrado G’, las sucesivas iteraciones y el árbol final encontrado utilizando la función objetivo fC.
43

Fig. 14 Sucesivas iteraciones y el árbol final encontrado utilizando la función objetivo fCD
44

4.2.7 QDMR [40]
Esta heurística utiliza como función objetivo minimizar el costo del árbol multicast,
tomando en cuenta una restricción de retardo para los caminos de fuente a destinos.
QDMR (QoS Dependent Multicast Routing) se basa en otra heurística llamada DDMC
(Destination‐Driven Multicasting) [42] que genera árboles multicast de bajo costo, pero
que no cumplen alguna restricción. La idea básica de DDMC es dar prioridad a los
caminos de bajo costo que van a través de un destino que ya está en el árbol, con el fin de
alcanzan un destino aun no agregado. De esta manera, los árboles resultantes utilizando
la heurística DDMC tienen el aspecto de largas cadenas que incluyen a los nodos
miembros del grupo. En términos de eficiencia multicast (3.4.7) está heurística tiene buen
desempeño, dado que intenta utilizar los mismos caminos para conectar la mayor
cantidad de destino, sin embargo en términos de retardo (fuente a destino) puede tener
bastantes dificultades. QDMR intenta corregir la dificultad de retardo de DDMC, en
desmedro de la eficiencia multicast. La función de costo que DDMC utiliza para evaluar
si agrega al árbol un cierto nodo está dada por:
Costo[ v]
= I D ( u)
Costo[
u]
+ C(
u,
v)
, donde C(u,v) es el costo del camino desde u a v, y
donde la función indicadora ID(u): V → {0,1} está definida como:
⎧0
si u ∈ D
I D (u)
= ⎨
(ID(u) para DDMC)
⎩1
en cualquier otro caso
QDMR ajusta dinámicamente la política de construcción de árbol de DDMC, de
acuerdo a qué tan lejos se encuentre un nodo destino de superar el límite de retardo.
QDMR actúa como DDMC cuando no hay problemas de retardo, en cambio cuando se
superan los límites impuestos por las restricciones, QDMR construirá un árbol de ʺmayor
forestaʺ (más ramificado) con tal de cumplir con las restricciones. La función de costo
que QDMR utiliza para evaluar si agrega al árbol un cierto nodo está dada por:
Costo[ v]
= I D ( u)
Costo[
u]
+ C(
u,
v)
, donde C(u,v) es el costo del camino desde u a v, ∆ es
la restricción de retardo desde fuente a destino, y la función indicadora ID(u): V → {0,1}
está definida como:
⎧Delay( u)
/ ∆ si u ∈ D
I D ( u)
= ⎨
(ID(u) para QDMR)
⎩ 1 en cualquier otro caso
Debido a que QDMR está utilizando una estrategia “oportunista” (greedy) con el fin de
minimizar el costo del árbol, éste podría fallar en encontrar un camino que cumpla las
restricciones de retardo aplicando el indicador ID(u) definido arriba. Por ello, QDMR
considera una fase de adhesión (merge fase) posterior, la cual intercambia los caminos
que han superado el límite de retardo por caminos de menor retardo fuente a algún nodo
en el árbol parcial (en el peor caso el camino reemplazante es un camino de menor
retardo desde fuente a destino). Finalmente QDMR incluye una fase de podado (prune
fase) que elimina las ramas que no alcanzan a ningún destino (producto de la fase de
adhesión).
La Fig. 15 muestra un ejemplo del árbol que generaría QDMR respecto al que
generaría DDMC. Además se muestra el árbol de mínimo retardo (LDT).
45

Fig. 15 Ejemplo que muestra la diferencia entre DMMC y QDMR: (a) Ejemplo de red y Árbol DDMC; (b) Árbol
de menor Retardo (LDT); (c) Árbol DDMC + LDP (Least Delay Path); (d) Árbol QDMR.
46

RESUMEN
En la Tabla 2 se muestra a modo de resumen, una clasificación según la taxonomía
propuesta en 2, que muestra para qué están mejor diseñados los algoritmos vistos en 4.2
y los protocolos vistos en 4.1.
Características del
Grupo
DVMRP Denso, Dinámico,
Local
MOSPF Denso, Dinámico,
Global
Tabla 2: Algoritmos y Protocolos de ruteamiento Multicast.
Estructura de las Rutas Construcción de las
Rutas
Árbol de fuente específica Árbol de Camino más
corto
Árbol de fuente específica Árbol de Camino más
corto
CBT Dinámico, Local Árbol compartido Árbol de Camino más
corto
PIM‐DM Denso, Dinámico,
Local
PIM‐SM Esparcido, Dinámico,
Local
BGMP Esparcido, Dinámico,
Local
Árbol de fuente específica Árbol de Camino más
corto
Árbol compartido/ Árbol
de fuente específica
Árbol compartido/ ramas
de fuente específica
KMB Denso, Global Árbol de fuente
Específica
CDKS Denso, Dinámico,
Global
Árbol de fuente
Específica
CAO Denso, Global Árbol de fuente
Específica
BSMA Denso, Dinámico Árbol de fuente
Específica
KPP Denso Árbol de Fuente
Específica
QDMR Denso Árbol de fuente
Específica
BC Esparcido, Dinámico,
Local/Global
Árbol de fuente
Específica / Árbol
compartido
47
Árbol de Camino más
corto
Árbol de Camino más
corto
Árbol de Steiner sin
Restricciones
Árbol de Camino más
corto con Restricciones
Árbol de Steiner con
Restricciones
Árbol de Steiner con
Restricciones
Árbol de Steiner con
Restricciones
Árbol de Steiner con
Restricciones
Árbol de Steiner sin
Restricciones
Manejo de la
Información
Distribuido
Global / Distribuido
Local / Distribuido
Distribuido
Local / Distribuido
Local / Distribuido
Local / Centralizado
Global / Centralizado
Global / Centralizado
Global / Centralizado
Local / Centralizado y
Distribuido
Global / Centralizado
Global / Centralizado

E
5 Métodos de Comparación de Algoritmos
xisten tres maneras fundamentales de evaluar el rendimiento de un algoritmo:
analíticamente, por simulación y experimentalmente (monitoreo).
La evaluación del desempeño de un algoritmo de ruteamiento multipunto requiere
obtener valores para las medidas que representan la eficiencia con que éste opera. Las
medidas de rendimiento son diversas, sin embargo normalmente se refieren al costo del
árbol y al retardo desde la fuente a los destinos. Otras medidas de rendimiento de
relevancia son por ejemplo:, la probabilidad de bloqueo (rechazo) de solicitudes de
conexión, el número de conexiones exitosas frente a solicitudes de conexión, el tiempo de
ejecución y la cantidad de memoria utilizada por el algoritmo (siendo estas últimas
medidas relativas a la utilización de recursos computacionales), la eficiencia multicast
sobre unicast (3.4.7), entre otras.
Las siguientes secciones describen las tres maneras recién mencionadas que permiten
evaluar algoritmos de ruteamiento multipunto.
5.1 Analítica
En la sección 3.1 se presentó un modelo clásico para representar una red de
computadores. Éste se basa en un grafo conectado, donde los vértices de él representan
los nodos de la red, y los arcos representan los enlaces de la red. Sin mebargo, ¿existe
algún otro modelo que represente la red, de tal forma que permita la utilizacíon de
herramientas matemáticas para comparar algoritmos de ruteamiento multicast?, ¿qué
variables de la red son relevantes para la ejecución de un algoritmo de ruteamiento?.
En el contexto de algoritmos de ruteamiento multicast, las variables que interesan de la
red son básicamente las que permiten describir la topología y utilización de los enlaces en
función del tiempo.
Suponiendo que fuera posible capturar la información del estado de la red (topología y
utilización de los enlaces) en un instante dado. Entonces, este estado ¿depende del
estado anterior?. Además, el permanecer en un determinado estado, ¿depende de cuánto
tiempo haya transcurrido?. Si la respuesta a estas dos últimas preguntas fuese
afirmativa, entonces la red y su dinámica (caracterizada por la operación de algún
algoritmo de ruteamiento) podrían ser representadas en una cadena de Markov.
Una cadena de Markov es un proceso estocástico que describe el comportamiento
probabilístico de un sistema conforme varía el parámetro tiempo. Las componentes
fundamentales de una cadena de Markov son: el espacio de estados (posibles situaciones
en las que se puede encontrar el sistema), el parámetro (tiempo en este caso) y la
dinámica del sistema. La dinámica corresponde al conjunto de transiciones entre estados
de la cadena.
Si bien es posible utilizar una cadena de Markov como herramienta analítica de
comparación entre algoritmos de ruteamiento, en la práctica, su utilización trae consigo
dificultades tales como: se requiere manejar un gran número de estados, y por lo tanto
una gran cantidad de recursos computacionales; se necesita conocer las tasas de
transición entre estados, lo cual significa conocer la naturaleza probabilística de los
48

cambios topológicos, del tráfico, de los instantes de inicio y término de conexiones, etc.;
además, se requiere saber interpretar la solución de la cadena en términos de medidas de
rendimiento, propias de la evaluación de algoritmos.
En [41] existen estudios sobre la evaluación de algoritmos de ruteamiento multipunto
mediante cadenas de Markov.
Hasta aquí se ha mencionado sólo una alternativa para comparar (analíticamente) el
rendimiento de algoritmos de ruteamiento. Sin embargo, cabe destacar la existencia de
un concepto conocido como “time complexity function” (función de complejidad de un
algoritmo) que permite conocer acerca de la factibilidad que un algoritmo tiene para
encuentrar una solución a medida que el tamaño del problema aumenta. Algunos
detalles acerca de la función de complejidad de un algoritmo se encuentran en el Anexo
A.
5.2 Simulación
La simulación es una imitación de las operaciones que efectúa un sistema o proceso
real, normalmente sistemas complejos, e involucra la generación de una historia artificial
del comportamiento del sistema. A partir de dicha historia se efectúan inferencias
relativas a las características operacionales del sistema real que se está representando.
Se debe tener en cuenta que los resultados obtenidos mediante simulación no son
excatos y que el modelo creado para representar la realidad debe ser validado.
La simulación se puede realizar considerando o no el tiempo en el modelo. Si el
tiempo es considerado, la simulación será dinámica, si no los es, la simulación será
estática. A su vez, se puede considerar el tiempo como una variable continua o discreta.
Adicionalmente, la simulación será catalogada de estocástica o determinista, si que existe
o no incertidumbre en algunas variables del modelo.
El tipo de simulación requerida para realizar estudios sobre ruteamiento multipunto,
considera tiempo discreto y aleatoriedad en algunas de las variables del modelo. Por
ejemplo: tiempo entre solicitudes de conexión, cambios topológicos de la red, tráfico de
paquetes, etc. En consecuencia, se puede decir que el tipo de simulación utilizada en este
trabajoo es: dinámica, discreta y estocástica.
Existen variadas herramientas de simulación para el estudio de redes de
computadores. La Tabla 4 menciona algunas de las herramientas disponibles
actualmente.
La selección de la herramienta utilizada en este trabajo se efectuó a partir la oferta
disponible gratuitamente en Internet. En particular, las herramientas estudiadas fueron:
Ns‐2 [49], Mars [50], OMNet++[51] y MCRSIM [59]. A partir de este estudio se generó
una breve documentación sobre Ns‐2 (Anexo B) y acerca de la realización de
experimentos de simulación involucrados en esta tesis, utilizando el simulador MCRSIM
(Anexo D).
La dimensión (tamaño) de las variables involucradas en la simulación de algoritmos y
protocolos de redes de computadores es un elemento clave para poder obtener resultados
a gran escala. La Tabla 3 obtenida de [47], muestra el efecto en el consumo de recursos
computacionales en función del incremento de las dimensiones de las variables
involucradas en el modelo de simulación.
49

Tabla 3 Escalamiento dimensional y su efecto en el consumo de recursos computacionales.
Factor Clase Recurso Afectado Crecimiento
Nodo (N) Nodos, mensajes de control, estados para el ruteamiento. O[N2] Topología
Enlace (L) Enlaces, mensajes de control, estados para el ruteamiento
multicast y paquetes. 1
O[L]
Capacidad de
Enlaces (C)
Paquetes sobre enlaces O[C]
Tamaño del
Buffer (B)
Paquetes en las Colas O[B]
Fuente (S) Paquetes sobre enlaces, estados de conexión y estados multicast O[S]
Grupo (G) Paquetes sobre enlaces, mensajes de control y estados multicast O[G]
Miembros (M) Paquetes sobre enlaces, mensajes de control, estados multicast2 Tráfico
O[M]
Tasa de Tx
Datos (D)
Paquetes sobre enlaces. O[D]
Según [47], los recursos totales consumidos (RT) para una simulación de redes de
computadores pueden ser expresados aproximadamente como:
RT = O[N 2 ] + O[L] + O[C] + O[B] + O[S⋅G⋅M⋅D]
1 Potencialmente los grupos multicast con la misma cantidad de miembros se expanden en árboles más grandes
para topologías más grandes.
2 El overhead depende de la distribución de los miembros.
50

Tabla 4 Algunas Herramientas de Simulación para Redes de Computadores
NOMBRE DEL
SIMULADOR MODO CLASE ESCALA MÓDULOS DISPONIBLES
NEST
Secuencial General
Multi –hilos, 100
nodos
REAL Secuencial General 100 nodos TCP, Telnet, ftp, routing, scheduling
Ns‐2 (VINT
Project) Secuencial Emulación
Abstracción, 50.000
nodos sobre PC
Pentium
51
Abundante Librería TCP, unicast routing, multicast transport,
multicast, mecanismos de scheduling, y fuentes de tráfico
NIST Net Secuencial Emulación Varias condiciones de Red (p.e. retardo y pérdida)
Ns‐2 Emulation
(Vint Project)
OPNET
Secuencial Comercial Interfaces UDP y TCP entre simulación y mundo real
Secuencial Comercial
Abundantes librerías y soporte de Servicio. Pueden ser pedidos
a los proveedores más módulos o herramientas de desarrollo
COMNET III Secuencial Comercial Idem OPNET
BONes Secuencial Comercial Idem OPNET
MaRS
PIMSIM
MCRSIM
QRS
(Desarrollado
sobre MaRS)
QuoSar
‐‐
INSANE
Secuencial
Secuencial
Secuencial
Secuencial
Secuencial
Secuencial
Secuencial
ATM Simulator Secuencial
TCP con
PTOLEMY
Secuencial
Dedicados
(Ruteamiento)
Dedicados
(Ruteamiento)
Dedicados
(Ruteamiento)
Dedicados
(Ruteamiento)
Dedicados
(Ruteamiento)
Dedicados
(Ruteamiento)
Dedicados
(IP/ATM)
Dedicados
(IP/ATM)
Dedicados
(TCP)
Ns‐2 (VINT
Project) Abstracción Abstracción
DistREAL Paralelo Paralelo
&Distribuido &Distribuido
Parsec (Maisie) Paralelo Paralelo
&Distribuido &Distribuido
S3 Paralelo Paralelo
&Distribuido &Distribuido
Ns‐2 (VINT
Project &
Georgia Tech)
Paralelo
&Distribuido
Paralelo
&Distribuido
OO
Híbrido Híbrido
Abstraction
50.000 nodos
sobre PC Pentium
Routing, Telenet, ftp, fuentes Poisson, y TCP simplificado
‐‐
PIM‐SM y PIM‐DM
Ruteamiento Multicast, fuentes de video y voz
QoS routing, QoS routing basado en redes IP
QoS Routing (sobre Windows NT)
‐‐
Transporte básico IP y mecanismos de scheduling, IP y capa de
enlace ATM, encolamiento y señalamiento ATM
Switches ATM, host, aplicaciones, capa de enlace y
ruteamiento de circuitos virtuales
TCP
Abundante Librería TCP, unicast routing, multicast transport,
multicast, mecanismos de scheduling, y fuentes de tráfico
2000 nodos 3 TCP, Telnet, ftp, routing, scheduling
100.000 nodos
wireless 5
Modelo analitico de
1024 nodos
Wireless 4 , TCP
ATM, multicast confiable, wireless, radio movil network, TCP
Abundante Librería de protocolos unicast y Multicast y
componentes de Red
Ruteamiento, Modelo de filas del tiempo de servicio (FIFO
solamente)
3 Los desarrolladores especulan que se pueden realizar simulaciones con 2000 nodos sobre 20 Sun
Workstations.
4 La simulación de redes Wireless es una de las mayores aplicaciones de Pársec.
5 Los autores de S3 afirman que se pueden efectuar simulaciones con 100.000 nodos sobre 1000 máquinas.

La simulación del comportamiento de algoritmos de ruteamiento multicast requiere de
tres etapas fundamentales: la generación de escenarios (modelo) que sean lo más cercanos
al sistema real en donde los algoritmos operan, la implementación de los algoritmos y la
configuración de los experimentos de simulación.
5.2.1 Generación de Escenarios de Simulación
Respecto de la generación de escenarios de simulación, la literatura apunta a utilizar
topologías aleatorias de Waxman [48] como topología de red para evaluar los algoritmos
de ruteamiento. Un software bastante popular (Ns‐2 [49] ‐ Anexo B) utiliza el generador
de topologías GT‐ITM [52], que incluye las topologías de Waxman. Sin embargo, algunos
generadores de topologías ([53], [54]) intentan generar escenarios que se aproximen
mayormente a redes reales, considerando por ejemplo el hecho de la naturaleza
jerárquica de Internet o la existencia de sistemas autónomos.
En [48] se proponen dos modelos de grafos aleatorios de Waxman. El método para la
generación del grafo se basa en generar distancias aleatorias entre cada par de nodos. A
partir de esa distancia se define, con una cierta probabilidad, la existencia de un enlace.
Esto se realiza para cada par de nodos del grafo. Los enlaces resultantes con sus nodos
respectivos conforman un grafo aleatorio de Waxman. La probabilidad de que un enlace
exista entre un par de nodos u y v está dada por:
−d(
u,
v)
β Lα
P[(
u,
v)]
= e , donde d(u,v) es la distancia entre los nodos u y v, L es la máxima
distancia posible entre dos nodos, α y β son dos parámetros entre 0 y 1, donde el
aumento de α indica un aumento en la proporción de enlaces largos sobre enlaces cortos
(en distancia), y un aumento en β implica un aumento en el grado6 de los nodos.
Una problemática de los grafos de Waxman es que entre los grafos resultantes se
pueden generar también grafos disconexos, a pesar de adecuar sus parámetros. La
segunda problemática es que entre ellos se generan grafos con nodos terminales, o sea,
nodos de grado uno. En caso de una falla en un enlace que conecta un nodo terminal, el
nodo quedaría desconectado del resto de la red, lo que no representa bien la realidad, ya
que en las redes reales los nodos presentan al menos dos enlaces emanando de ellos,
propiedad que se conoce como Two‐connected (2‐conectada). En [55] se muestra que el
rendimiento de algoritmos de ruteamiento multicast cuando estos son aplicados a redes
reales es idéntico al rendimiento cuando aquellos son aplicados a redes 2‐conectadas.
En el presente trabajo, la evaluación de algoritmos se realizó bajo topologías de
Waxman modificadas , donde los grafos resultantes son siempre redes conexas, con
grado mayor o igual a dos en cada nodo.
5.2.2 Implementación de Algoritmos
La implementación de los algoritmos depende de varios factores, por ejemplo: quién
los está implementando, en qué lenguaje, sobre qué máquina, etc. En este trabajo se
utilizó una herramienta de simulación disponible en Internet que ya posee varios
algoritmos implementados, sin embargo tuvieron que ser implementados algunos otros.
Para más detalles ver 6.1.
6 El grado de un nodo de un grafo simple es la cantidad de aristas o lados que concurren a él.
52

5.2.3 Configuración de los Experimientos de Simulación
La configuración de los experimentos de este trabajo se adecuó para permitir la
cuantificación de las medidas de rendimiento escogidas para la comparación entre
algoritmos (6.3). Para ello se elegieron parámetros adecuados para los escenarios de
simulación. Esto es, ocupación de enlaces de la red, cantidad de solicitudes de conexión,
cantidad de nodos en la red, grado de los nodos, límite de retardo permitido, etc.
Una vez que configurados los experimentos de simulación, estos son ejecutados. Pero,
¿cuántos experimentos ejecutar?. Si se ejecuta una sola vez el experimento, no se tendrá
certeza de la validez del valor encontrado para la medida evaluada. Por otro lado, es
imposible realizar infinitas veces el experimento para considerar como válido algún valor
promedio para la medida.
Si se tiene que las muestras del experimiento son estadísticamente independientes, y la
distribución de la población de muestras es normalmente distribuida con media µ y
varianza σ 2, entonces la expresión:
θ − µ
T =
S n
ˆ
se distribuye con una t‐Student con n‐1 grados de libertad, donde:
• θˆ n
es el estimador de la media del sistema simulado, definido por: ˆ 1
θ = ∑ Yi
.
n i=
1
• Yi es cada una de las observaciones de la muestra y θˆ es un estimador sin sesgo [63]
E ˆ θ = µ
cuando [ ] .
• S2 es el estimador para la varianza σ2 n
2 1
y está dada por: S = ∑
n − 1 i=
1
• µ es la media de la población de las muestras.
• n es el número de observaciones.
53
2
( Y − ˆ θ )
La probabilidad de que la cantidad T se encuentre en el intervalo [‐t, t] es
P −t ≤ T ≤ t = 1−
. Desarrollando la desigualdad al interior del paréntesis se tiene que:
[ ] α
⎡ S
S ⎤
1 −α
= P ˆ
⎢θ
− t ≤ µ ≤ ˆ θ + t ⎥
⎣ n
n ⎦
La expresión al interior del paréntesis corresponde al intervalo de confianza para el
promedio de la población de las muestras con una certeza o nivel de confianza de (1‐
α)⋅100%.
Entonces, si se quiere utilizar esta expresión para encontrar el promedio de una
medida de rendimiento para un algoritmo en una simulación, dentro de un intervalo de
confianza dado y un determinado nivel de confianza, entonces se puede implementar los
siguientes pasos al configurar los experimentos:
n
1. Calcular la media muestral del sistema como ˆ
1
θ = ∑ Yi
, en cada una de la n
n i=
1
observaciones en el experimento. Donde Yi es el valor de la medida en cada
observación.
i

2. Calcular la varianza a partir de la expresión:
observación.
54
S
2
=
n
∑
i=
1
( Y )
i
2
ˆ2
− n ⋅θ
n − 1
en cada
3. Encontrar t en una tabla con la distribución t‐Student y reemplazar el valor
numérico de t en la expresión para el intervalo de confianza del paso 4.
4. Calcular la expresión para el intervalo de confianza (IC) como: IC = θ ± t ⋅ S n
)
.
El experimento de simulación termina su ejecución al alcanzar el intervalo de confianza
especificado para un determinado nivel de confianza.
5.3 Experimental
Evaluar el rendimiento de un algoritmo de ruteamiento en forma experimental
requiere de alguna herramienta para monitorear su comportamiento en una red real
(física). La red del experimento debe operar en la mayor cantidad de escenarios posibles
para reflejar ampliamente la operación del algoritmo (distintas ocupaciones de enlaces,
fallas de nodos o enlaces, etc.).
Algunos análisis de algoritmos de ruteamiento mediante experimentación se basan en
estadísticas de datos monitoreados en la Internet. Algunas herramientas de monitoreo
disponibles para el análisis de protocolos de ruteamiento multicast se muestran en la
Tabla 5 [58].
El presente trabajo tiene el objetivo de comparar el rendimiento de algoritmos de
ruteamiento multipunto, por ello se requiere que los algoritmos operen en la mayor
cantidad de escenarios posibles. En consecuencia, la metodología experimental no es una
buena alternativa en este caso.

Tabla 5 Algunas Herramientas de Monitoreo Multicast existentes
Fuente de Recolección de los datos Tipo de Monitoreo Ámbito de análisis y monitoreo Salida
Router/Red/
Sesión SubRed Tiempo
Herramienta SNMP7 Aplicación Otras Tráfico & Ruta Sesión
Texto Archivo GUI
Herramientas
Una Múltiple Intra Inter Online Histórico
MantaRay X X X X X
Mantra X X X X X X X X X X X
Mhealth X X X X X X X X X X
Mlisten X X X X X X X X
Mrinfo X X X X X
Mtrace X X X X X X
MultiMON X X X X X X X X
RM X X X X X X X
RTPmon X X X X X X
SDR‐Monitor X X X X X X X
SM X X X X X X X X X
7 Simple Network Managment Protocol
55

E
6 Comparación de Algoritmos mediante Simulación
n la sección 5.2 se explicó que la comparación de algoritmos de ruteamiento mediante
simulación, involucra principalmente tres fases: la generación de escenarios que
representen la red, la implementación de los algoritmos a evaluar y la configuración de los
experimentos de simulación. Las siguientes secciones detallan acerca de la implementación
de estas tres fases, previa explicación de la herramienta de simulación utilizada en el presente
trabajo y las medidas de rendimiento consideradas.
6.1 Herramienta de Simulación
En la Tabla 4 se nombran una serie de herramientas de simulación de redes. Una de ellas:
MCRSIM [59] está especializada en la simulación de algoritmos de ruteamiento multicast.
MCRSIM está escrito en C++ y usa funciones de las librerías Motif y X para implementar la
interfase gráfica. El software opera sobre máquinas Unix que soportan un ambiente
Xwindows. Este simulador es un paquete de software que crea y edita grafos que
representan redes de computadores, aplica algoritmos de ruteamiento multicast a estos
grafos, y simula un flujo de celdas ATM sobre el árbol resultante para obtener estadísticas de
transmisión de paquetes en un archivo de salida. El archivo de salida del simulador entrega
la siguiente información: dirección del grupo, identificación de la fuente, identificación del
miembro del grupo, número de celdas recibidas, número de celdas perdidas, tasa promedio
de pérdida, número de celdas que superar el deadline, mínimo retardo fin a fin, máximo
retardo fin a fin, jitter, promedio del retardo fin a fin, intervalo de confianza alcanzado para
el retardo, intervalo de confianza alcanzado para la tasa de pérdida.
Algunas de las flexibilidades del software son que se puede configurar el tamaño de las
celdas, las capacidades individuales de los enlaces, la topología de la red (según un modelo
de Waxman modificado [5.2]), los grupos multicast pueden ser elegidos aleatoriamente (sólo
debe escogerse un nombre y cantidad de miembros para el grupo).
MCRSIM implementa dos tipos de fuentes tráfico: voz y video [60]. Se puede agregar a los
enlaces de la red tráfico background consistente de muchas fuentes de video transmitiendo,
con el fin de representar una red cargada. El tráfico background que se agrega
opcionalmente, puede representar tanto cargas simétricas como asimétricas sobre los enlaces.
Los algoritmos originalmente implementados en este software son:
1. Minimum Steiner Tree Algorithm, OPT: un algoritmo optimo según [56] que minimiza
el costo total del árbol multicast.
2. KMB [35].
3. LD (Least Delay), algoritmo que minimiza el retardo de los caminos individuales de
fuente a destino. Según [56] es un algoritmo óptimo.
4. LC‐DKS (Dijkstra Least Cost), algoritmo que minimiza el costo de los caminos
individuales de fuente a destino. Según [56] es un algoritmo óptimo.
5. LC‐BF (Bellman Ford Least Cost), algoritmo que minimiza el costo de los caminos
individuales de fuente a destino. Según [56] es un algoritmo óptimo.
56

6. PRUNED (pruned minimum spanning tree heuristic), una heurística simple para
construir un árbol mínimo de Steiner mediante inundación de la red. [56].
7. RPM (Reverse Path Multicasting) [7]
8. SC (Semiconstrained Heuristic) ‐‐WATERS. [61].
9. MSC‐SC (Modified semiconstrained Heuristic). [56].
10. Constrained Steiner Tree Algorithm, COPT. Éste minimiza el costo total del árbol
multicast sin exceder el límite de retardo impuesto para el retardo entre fuente y
destino. [56].
11. KPP (heuristics for constrained Steiner tree). [14].
12. CAO (Constrained Adaptive Ordering). [38].
13. BSMA (Bounded Shortest Multicast Algorithm). [39].
14. BDB (Pruned Bounded Delay Broadcasting Heuristic). [57].
15. CDKS (Delay Constrained Dijkstra Shorted Path Algorithm). [37].
En este trabajo se hicieron algunas modificaciones al software original, entre ellas: adaptar
la versión 2 de MCRSIM disponible en [59] a Linux y al idioma español, corregir algunos
detalles de implementación en los algoritmos LC‐BF y BSMA, habilitar el algoritmo asociado
al protocolo PIM (4.1.4), agregar los algoritmos QDMR [40] y BC [36] y permitir la
importación de archivos del generador de topologías aleatorias BRITE [53] que permite
trabajar con topologías jerárquicas.
6.2 Algoritmos Evaluados
Los algoritmos evaluados en el presente trabajo se escogieron según si eran considerados
en la literatura como dentro de los más eficientes, comparados respecto de las medidas de
rendimiento vistas en 6.3. Un estudio bastante amplio sobre evaluación de algoritmos de
ruteamiento multicast [62] revela que el mejor representante de los algoritmos que
construyen árboles de Steiner no restringidos es el algoritmo KMB, y BSMA para árboles de
Steiner restringidos en retardo, por lo tanto, estos dos algoritmos fueron evaluados. Además,
se eligió un algoritmo como representante de los protocolos de ruteamiento multicast
existentes. El protocolo escogido fue PIM‐DM. Adicionalmente se evaluó el algoritmo
PRUNED disponible en MCRSIM. Este algoritmo es una heurística que construye árboles
mediante la poda de un árbol de expansión mínima (MST). El motivo de evaluar este
algoritmo es tener una referencia entre éste y los demás algoritmos en evaluación cuando el
tamaño del grupo es cercano al tamaño de la red. Un MST es un árbol de Steiner en el caso
particular e donde el grupo es toda la red. Otros dos algoritmos que fueron considerados son
KPP y CAO, pues éstos son utilizados para comparación en varias heurísticas propuestas en
la literatura. Finalmente, cinco heurísticas del algoritmo BC también fueron implementadas
y evaluadas. Las heurísticas evaluadas corresponden a:
• BC‐SAL, cuya función objetivo [4.2.2] intenta minimizar la cantidad de saltos
requeridos para alcanzar a los destinos que no se han agregado al grupo.
• BC‐BW, cuya función objetivo [4.2.2] intenta minimizar la cantidad de ancho de banda
utilizado por los enlaces que conforman el árbol requerido para alcanzar a todos los
57

destinos.
• BCL‐SAL, heurística [4.2.2.1] que reduce el número de iteraciones para agregar cada
enlace del árbol de distribución y cuya función objetivo intenta minimizar la cantidad
de saltos requeridos para alcanzar a los destinos que no se han agregado al grupo.
6.3 Medidas de Rendimiento
Las medidas de rendimiento escogidas fueron las siguientes:
6.3.1 Costo del árbol
La medida “costo del árbol” ya vista en 3.4.1, refleja la habilidad que un algoritmo tiene
para construir árboles multicast, en cuanto más pequeño es el valor obtenido menor es la
utilización de los recursos de la red para permitir la comunicación multicast.
En este trabjo se consideró como equivalentes: el costo del enlace y el ancho de banda
reservado, dado que se trata de una medida representativa de la utilización de los recursos
de enlace, tanto de ancho de banda como espacio en las buffers.
6.3.2 Retardo Promedio entre fuente y destino
Esta medida, es el promedio de los retardos individuales desde fuente a destinos (ver
3.4.1). Ésta refleja la habilidad que un algoritmo tiene para satisfacer las exigencias de
retardo que impone una aplicación o un nivel de servicio del usuario.
6.3.3 Número de Conexiones Exitosas
El número de conexiones exitosas corresponde al número de conexiones que han sido
aceptadas para una determinada cantidad de solicitudes de conexión. Una conexión no es
exitosa (o falla), si algún enlace del árbol generado por una nueva conexión supera la
capacidad del enlace o supera el límite impuesto para la ocupación de éste. A su vez, para
algoritmos que incluyen restricciones en el retardo fin a fin, otra causa de falla en la solicitud
de conexión, es que el árbol generado supere el límite de retardo impuesto por la restricción.
Esta medida permite estimar (de forma indirecta) la capacidad que un algoritmo tiene para
balancear la carga en la red, pudiendo visualizar las facultades que el algoritmo tiene para
administrar los recursos de la red.
6.4 Configuración de los Experimentos de Simulación
Fueron efectuados tres tipos de experimentos de simulación. Cada uno de ellos se focaliza
en alguna medida de rendimiento.
6.4.1 Primer Experimento
En el primer experimento se evaluó el costo del árbol y el retardo promedio entre fuente y
destinos generado por un algoritmo en función del tamaño del grupo multicast. Cada
ejecución del experimento considera una red, grupo y fuente multicast aleatorios.
Este experimento consiste básicamente en:
58

1. Generar un grupo aleatorio en una red aleatoria,
2. Solicitar una nueva conexión para una sesión multicast con el nuevo grupo,
3. Ejecutar el algoritmo que se esté evaluando (esto implica que se sumará la carga de la
fuente multicast activa al tráfico existente en el árbol de distribución);
4. Cerrar la sección activa; y finalmente,
5. Repetir la operación desde 1).
A continuación se describe en detalle el escenario de simulación.
Para cada observación se generó un grafo aleatorio de Waxman con parámetros α = 0.15,
β = 0.22, y grado promedio en los nodos igual a 4 para representar la red. La topología de red
fue establecida en un espacio de la pantalla equivalente a 3000x2400Km.
Se escogieron distintos tamaños de red para distintos experimentos. En cada observación
se escogió un grupo y una fuente multicast aleatoriamente. La fuente multicast corresponde
a una fuente de video VBR (Variable Bit Rate) que sigue el modelo B de Maglaris [60]. Una
sesión multicast activa genera un árbol en cuyos enlaces se reserva un determinado ancho de
banda para permitir el tráfico de la fuente VBR del correspondiente grupo. Para representar
la carga de la red debido a otros grupos multicast activos se agregó tráfico background. El
tráfico background corresponde a muchas fuentes de video VBR que agregan tráfico sobre
los enlaces de la red. Cada fuente de una sesión multicast tiene una tasa pico igual a 1.5
Mbps, y una razón sobre el promedio (relación entre el valor pico y el valor promedio) igual
a 0.33.
La utilización de los enlaces en la red se consideró uniformemente distribuido entre 5 y 125
[Mbps], entre 45 y 85 [Mbps], o entre 100 y 120 Mbps para un tamaño de red de 20 nodos.
Esto permitió evaluar la tendencia del rendimiento de los algoritmos según distintas cargas
en la red. La condición más exigente para los algoritmos es cuando la red se encuentra
altamente saturada (tráfico background entre 100 y 120 Mbps). El mismo tipo de experimento
fue realizado para una red de 100 nodos.
La capacidad de los enlaces en la red se configuró para ser igual a 155,2 Mbps 8 . Los
enlaces fueron configurados para que cuando la ocupación de éstos superase el 85% (132
Mbps) se los considerara saturados.
En el caso de algoritmos que consideran restricciones de retardo se estableció un limite
para el retardo igual a 0.03 segundos.
Las medidas fueron obtenidas con un intervalo de confianza de 5% para un nivel de
confianza de 95%.
Se debe notar que los valores de los parámetros de simulación intentan acercar la
simulación a la realidad y además replicar trabajos de la literatura anteriores. Esto último
permite validar los resultados obtenidos en este trabajo al compararlos con los publicados en
la literatura.
8 Las velocidades de transmision de ATM mas frecuentemente usadas son STM1 u OC3 (SDH, SONET
respectivamente) que son 155.2 MBps. Esta velocidad se puede transmitir tanto por fibra optica como por cable del
tipo STP5.
59

6.4.2 Segundo Experimento
El segundo tipo de experimento considera un escenario de simulación muy similar al
primer experimento. Las diferencias son: la red comienza sin tráfico (“en vacío”). Además
no se genera una nueva red en cada ejecución, si no que se utiliza la misma red durante todo
el experimento. La red escogida es una red aleatoria de Waxman con los mismos parámetros
del primer experimento. Las medidas obtenidas están dentro de un intervalo de confianza
del 5% para un nivel de confianza de 95%.
Sucesivamente, en cada nueva ejecución del experimento, la red es cargada con nuevas
sesiones multicast escogiendo cada vez un grupo y fuente aleatorias. Las sesiones no son
desconectadas hasta el final de la ejecución del experimento. La medida de interés en este
caso es el número de conexiones exitosas. Se realizan 3000 solicitudes de conexión y cada
algoritmo evaluado es capaz de responder o no a estas solicitudes según su capacidad de
administración de los recursos de la red. Una solicitud es rechazada en dos casos: cuando se
viola el límite de retardo en el caso de algoritmos con restricciones de retardo, o cuando los
enlaces se encuentran saturados (condición para todos los algoritmos).
60

A
7 Resultados de la Simulación
continuación se detalla acerca de los resultados de los experimentos refiriéndose a
cada medida en particular.
Los resultados obtenidos coinciden con los publicados en la literatura para un rango
dentro del intervalo de confianza definido en un 5%, y para los algoritmos y configuraciones
de escenarios de simulación equivalentes en trabajo y en [62] (red de 20 nodos y tráfico
background entre 45 y 85 Mbps, y entre 5 y 125 Mbps).
Costo del Árbol
Parte de los resultados obtenidos para el primer experimento, los que se ilustran desde la
Fig. 16 a la Fig. 21, muestran que la heurística BC‐BW tiene el mejor desempeño de todos los
algoritmos no restringidos evaluados. A sí mismo la Fig. 28 muestra un resumen con los
algoritmos restringidos y no restringidos considerados, ilustrando la relación de los
desempeños respecto del rendimiento de KMB para la medida costo del árbol. Allí se puede
observar que BC‐BW es el algoritmo de mejor rendimiento para una red de 20 nodos,
independientemente de la carga de la red. La heurística BC‐SAL se comporta similarmente a
BC‐BW cuando la utilización de los enlaces de la red debido al tráfico background varia entre
un 75% y 90% (Fig. 20). Se puede observar que la tendencia de BC‐SAL es a mejorar su
desempeño a medida que la carga de la red aumenta y el desbalance entre la utilización de
los enlaces disminuye. Se debe notar que la familia de heurísticas BC tienden a empeorar su
rendimiento a medida que el grupo se acerca al tamaño de la red. Esto da una indicación de
que las heurísticas BC son más adecuadas en grupos dispersos. Cabe destacar que el tamaño
de los grupos multicast normalmente son una pequeña fracción de la red [58], por lo tanto las
heurísticas BC son adecuadas en la práctica.
Para la red de 100 nodos (Fig. 29 y Fig. 30) las tres heurísticas BC tienen mejor
rendimiento que los otros algoritmos evaluados para grupos hasta cerca de un 85% del
tamaño de la red.
Los algoritmos BSMA, CAO, KPP y QDMR tienen un comportamiento bastante similar
para las condiciones de ilustradas desde la Fig. 22 a la Fig. 27. En el peor caso,
correspondiente a QDMR, éste no supera el 10% sobre el rendimiento de BSMA (Fig. 23).
La heurística MST (PRUNED en [56]) genera árboles de distribución a partir de podar un
árbol de mínima expansión (Minimum Spanning Tree), por lo tanto resulta natural que su
rendimiento mejore cuando el tamaño del grupo se acerca al tamaño de la red (y en general
obtenga un buen desempeño en dicho caso), tal como se observa en la Fig. 16 a la Fig. 21.
Para una red cargada entre un 75% y un 90% (Fig. 20) la tendencia de todos los algoritmos
evaluados es presentar un rendimiento dentro de un 5% igual al de MST cuando el grupo
multicast (fuente más destinos) es igual al tamaño de la red, lo cual indica que el desempeño
de los algoritmos en esos casos es aceptable en términos absolutos.
El algoritmo asociado al protocolo PIM claramente mejora su rendimiento en cuanto la
carga de la red crece. Esta característica es útil desde el punto de vista de redes que operan
61

normalmente en el límite de la saturación. Sin embargo a pesar de que su rendimiento
mejora cuando la carga aumenta, aun en su mejor situación, éste no supera a KMB, BC‐SAL,
BC‐BW o BCL‐SAL tal como se observa en la Fig. 28. El rendimiento de los protocolos
multicast puede aun mejorar bastante. Técnicamente sólo se requiere de algoritmos
distribuidos y que utilicen información local para operar. Estas características son algunas de
las requeridas en la práctica para la implementación de algún protocolo multicast.
Al igual que PIM, BC‐SAL muestra un mejor desempeño a medida que la carga de la red
aumenta y se balancea, logrando hasta un 20% menos que el costo del árbol que genera KMB
para un grupo de tamaño igual al 25% de la red (Fig. 20).
En general, el buen comportamiento de BC‐BW se debe a que está sintonizado a la medida
costo de árbol, pues la función objetivo que lo define intenta minimizar la suma de la
utilización de los enlaces que conforman el árbol de distribución. Así mismo, a pesar de que
BC‐SAL y BCL‐SAL operan básicamente de la misma manera, su rendimiento es en
promedio cercano a un 80% peor para el caso de BCL‐SAL, y de un 60% peor para el caso de
BC‐SAL, para la situación más desfavorable, que corresponde a la red con mayor desbalance
de tráfico (Fig. 16) y tamaño de grupo igual a un 95% de los nodos de la red. Esto se debe a
que las funciones objetivo de BCL‐SAL y BC‐SAL buscan obtener un bajo número saltos del
árbol de distribución final, en vez del ancho de banda utilizado por tal árbol. Esto mismo
explica porqué BC‐SAL y BCL‐SAL tienen un buen desempeño para la medida retardo
promedio entre fuente y destinos, tal como se aprecia en desde la Fig. 31 a la Fig. 38.
Retardo Promedio entre Fuente y Destinos
BC‐SAL resultó ser el algoritmo con mejor rendimiento, superando a BSMA en cerca del
30% para las distintas situaciones de tráfico y en una red de 20 nodos, tal como se observa
desde la Fig. 31 a la Fig. 36. Se observa que QDMR mejora su desempeño a medida que el
tamaño del grupo aumenta y se acerca al tamaño de la red.
Se debe notar que QDMR opera dando prioridad a los caminos de bajo costo que van a
través de un destino que ya está en el árbol para agregar a los destinos faltantes, respetando
el límite de retardo impuesto para los caminos desde fuente a destinos. Así, es posible
generar un árbol de bajo costo que nunca alcance el límite de retardo. Por otro lado BSMA
itera para encontrar un árbol de menor costo a partir de un árbol de menor retardo. Los
caminos elegidos en las iteraciones, que permiten disminuir el costo del árbol, están sujetos a
las restricciones de retardo impuestas. De esta manera, los árboles generados por BSMA
están más cercanos al límite del retardo impuesto para los caminos desde fuente a destinos
que los árboles generados por QDMR.
La Fig. 37 y Fig. 38 correspondientes a una red de 100 nodos, muestran que las heurísticas
BC generan árboles de menor retardo que BSMA. Esto es razonable de pensar para las
heurísticas BC‐SAL y BCL‐SAL, ya que los árboles encontrados por BC tienen un menor
número de enlaces. Nótese que, a pesar de que no parece intuitivo que BC‐BW deba obtener
un bajo retardo, dado que su función objetivo apunta a encontrar enlaces que tengan una baja
utilización del ancho de banda, en la Fig. 29 se observa que el costo de los árboles generados
por BC‐BW es bajo respecto de las otras heurísticas. Esto se debe a que BC‐BW elige, por una
parte enlaces más desocupados para generar el árbol, pero por otro lado elige una menor
cantidad de enlaces respecto de los otros algoritmos. Como la Fig. 29 muestra una situación
en donde los enlaces de la red se encuentran utilizados entre un 75% y 90%, los árboles
62

generados por BC‐BW tienen menos enlaces que otras heurísticas, y por lo tanto el retardo
entre fuente y destinos también es menor que otros algoritmos.
Número de conexiones Exitosas frente a solicitudes
La eficiencia de un algoritmo puede ser medida a través del costo del árbol generado o el
retardo promedio entre fuente y destinos. Sin embargo, antes de conocer qué tan eficiente es
un algoritmo, se espera saber si este éste es o no efectivo. Una medida de la efectividad de
un algoritmo es el número de conexiones que el algoritmo admite antes de saturar los enlaces
de la red. En consecuencia, el número de conexiones exitosas frente a solicitudes es una
medida que refleja la capacidad que un algoritmo tiene para administrar los recursos de la
red. Tanto desde el punto de vista de los proveedores de servicios de red, como de los
usuarios de éstos, se espera que un algoritmo acepte la mayor cantidad de sesiones multicast.
El segundo experimento comienza con una red vacía y progresivamente se carga de
sesiones multicast, con un total de 3000 solicitudes. La heurística BC‐BW es la mejor
evaluada para esta medida. Permitiendo cerca de un 30% más de conexiones para un grupo
igual a un 25% de la red (20 nodos), como se observa en la Fig. 39 y cerca de un 35% más de
conexiones para un grupo igual a 10% del tamaño de la red (50 nodos), tal como se ilustra en
la Fig. 40. Las heurísticas BC‐SAL y BCL‐SAL también tienen un buen comportamiento
frente a esta medida, aun cuando siempre están por debajo de BC‐BW.
63

Trafico Background 5 - 125 [Mbps]
Costo del Arbol
2.00E+09
1.50E+09
1.00E+09
5.00E+08
KMB BCL BCBW BCSAL PIM MST
0.00E+00
5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
Tamaño del Grupo
Fig. 16 Costo del Árbol en red de 20 nodos, grado promedio igual a 4 y ocupación de enlaces entre 5 y 125 Mbps.
(Algoritmos No Restringidos)
Trafico Background 5 - 125 [Mbps]
Exceso sobre KMB
BCL KMB BCBW BCSAL PIM MST
1.75
1.55
1.35
1.15
0.95
0.75
0.55
5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
Tamaño del Grupo
Fig. 17 Exceso sobre KMB para la medida costo del Árbol en red de 20 nodos, grado promedio igual a 4 y ocupación
de enlaces entre 5 y 125 Mbps. (Algoritmos No Restringidos)
64

Trafico Background 45 - 85 [Mbps]
Costo del Arbol
2.00E+09
1.50E+09
1.00E+09
5.00E+08
KMB BCL BCBW BCSAL PIM MST
0.00E+00
5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
Tamaño del Grupo
Fig. 18 Costo del Árbol en red de 20 nodos, grado promedio igual a 4 y ocupación de enlaces entre 45 y 85 Mbps.
(Algoritmos No Restringidos)
Exceso sobre KMB
Trafico Background 45 - 85 [Mbps]
1.75
1.55
1.35
1.15
0.95
0.75
BCL KMB BCBW BCSAL PIM MST
0.55
5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
Tamaño del Grupo
Fig. 19 Exceso sobre KMB para la medida costo del Árbol en red de 20 nodos, grado promedio igual a 4 y ocupación
de enlaces entre 45 y 85 Mbps. (Algoritmos No Restringidos)
65

Trafico Background 100 - 120 [Mbps]
Costo del Arbol
2.00E+09
1.50E+09
1.00E+09
5.00E+08
KMB BCL BCBW BCSAL PIM MST
0.00E+00
5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
Tamaño del Grupo
Fig. 20 Costo del Árbol en red de 20 nodos, grado promedio igual a 4 y ocupación de enlaces entre 100 y 120 Mbps.
(Algoritmos No Restringidos)
Exceso sobre KMB
Tráfico Background 100 -120 [Mbps]
BCL KMB BCBW BCSAL PIM MST
1.75
1.55
1.35
1.15
0.95
0.75
0.55
5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
Tamaño del Grupo
Fig. 21 Exceso sobre KMB para la medida costo del Árbol en red de 20 nodos, grado promedio igual a 4 y ocupación
de enlaces entre 100 y 120 Mbps. (Algoritmos No Restringidos)
66

Trafico Background 5 - 125 [Mbps]
Costo del Arbol
1.90E+09
1.70E+09
1.50E+09
1.30E+09
1.10E+09
9.00E+08
7.00E+08
5.00E+08
KPP CAO BSMA QDMR
3.00E+08
5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
Tamaño del Grupo
Fig. 22 Costo del Árbol en red de 20 nodos, grado promedio igual a 4 y ocupación de enlaces entre 5 y 125 Mbps.
(Algoritmos Restringidos)
Exceso sobre BSMA
Trafico Background 5 - 125 [Mbps]
1.09E+00
1.07E+00
1.05E+00
1.03E+00
1.01E+00
9.90E-01
KPP CAO BSMA QDMR
9.70E-01
5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
Tamaño del Grupo
Fig. 23 Exceso sobre BSMA para la medida costo del Árbol en red de 20 nodos, grado promedio igual a 4 y
ocupación de enlaces entre 5 y 125 Mbps. (Algoritmos Restringidos)
67

Trafico Background 45 - 85 [Mbps]
Costo del Arbol
1.90E+09
1.70E+09
1.50E+09
1.30E+09
1.10E+09
9.00E+08
7.00E+08
5.00E+08
KPP CAO BSMA QDMR
3.00E+08
5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
Tamaño del Grupo
Fig. 24 Costo del Árbol en red de 20 nodos, grado promedio igual a 4 y ocupación de enlaces entre 45 y 85 Mbps.
(Algoritmos Restringidos)
Exceso sobre BSMA
Trafico Background 45 - 85 [Mbps]
1.09E+00
1.07E+00
1.05E+00
1.03E+00
1.01E+00
9.90E-01
KPP CAO BSMA QDMR
9.70E-01
5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
Tamaño del Grupo
Fig. 25 Exceso sobre BSMA para la medida costo del Árbol en red de 20 nodos, grado promedio igual a 4 y
ocupación de enlaces entre 45 y 85 Mbps. (Algoritmos Restringidos)
68

Trafico Background 100 - 120 [Mbps]
Costo del Arbol
1.90E+09
1.70E+09
1.50E+09
1.30E+09
1.10E+09
9.00E+08
7.00E+08
5.00E+08
KPP CAO BSMA QDMR
3.00E+08
5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
Tamaño del Grupo
Fig. 26 Costo del Árbol en red de 20 nodos, grado promedio igual a 4 y ocupación de enlaces entre 100 y 120 Mbps.
(Algoritmos Restringidos)
Exceso sobre BSMA
Trafico Background 100 - 120 [Mbps]
1.09E+00
1.07E+00
1.05E+00
1.03E+00
1.01E+00
9.90E-01
KPP CAO BSMA QDMR
9.70E-01
5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
Tamaño del Grupo
Fig. 27 Exceso sobre BSMA para la medida costo del Árbol en red de 20 nodos, grado promedio igual a 4 y
ocupación de enlaces entre 100 y 120 Mbps. (Algoritmos Restringidos)
69

Trafico Background 5 - 125 [Mbps]
KMB BCL BCBW BCSAL PIM
KPP CAO BSMA QDMR MST
Exceso sobre KMB
1.750
1.550
1.350
1.150
0.950
0.750
0.550
5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
Tamaño del Grupo
70
Trafico Background 45 - 85 [Mbps]
Trafico Background 100 - 120 [Mbps]
KMB BCL BCBW BCSAL PIM
KPP CAO BSMA QDMR MST
Exceso sobre KMB
1.750
1.550
1.350
1.150
0.950
0.750
0.550
5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
Tamaño del Grupo
Exceso sobre KMB
1.750
1.550
1.350
1.150
0.950
0.750
KMB BCL BCBW BCSAL PIM
KPP CAO BSMA QDMR MST
0.550
5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
Tamaño del Grupo
Fig. 28 Resumen: Exceso sobre KMB para la medida costo del Árbol (Algoritmos Restringidos y No Restringidos). Red de 20 nodos, con grado promedio igual a 4 y ocupación de
enlaces entre: 5 y 125 Mbps; 45 y 85 Mbps; 100 y 120 Mbps.

Trafico Background 100 - 120 [Mbps]
KMB BCL BCBW BCSAL KPP
CAO BSMA
Costo del Arbol
1.00E+10
8.00E+09
6.00E+09
4.00E+09
2.00E+09
0.00E+00
5 15 25 35 45 55 65 75 85
Tamaño del Grupo
Fig. 29 Costo del Árbol en red de 100 nodos, grado promedio igual a 4 y ocupación de enlaces entre 100 y 120 Mbps.
(Algoritmos Restringidos y No Restringidos)
Exceso sobre KMB
Trafico Background 5 - 125 [Mbps]
1.20
1.10
1.00
0.90
0.80
0.70
0.60
0.50
KMB BCL BCBW BCSAL KPP
CAO BSMA
0.40
5 15 25 35 45 55 65 75 85
Tamaño del Grupo
Fig. 30 Exceso sobre KMB para la medida costo del Árbol en red de 100 nodos, grado promedio igual a 4 y
ocupación de enlaces entre 100 y 120 Mbps. (Algoritmos Restringidos y No Restringidos)
71

Trafico Background 5 - 125 [Mbps]
BCL KMB BCBW BCSAL PIM
MST KPP CAO BSMA QDMR
Retardo Promedio entre Fuente y Destinos[s]
2.100E-02
1.900E-02
1.700E-02
1.500E-02
1.300E-02
1.100E-02
9.000E-03
7.000E-03
5 7 9 11 13 15 17 19
Tamaño del Grupo
Fig. 31 Retardo promedio entre Fuente y Destinos en red de 20 nodos, grado promedio igual a 4 y ocupación de
enlaces entre 5 y 125 Mbps. (Algoritmos Restringidos y No Restringidos)
Trafico Background 5 - 125 [Mbps]
BCL KMB BCBW BCSAL PIM
MST KPP CAO BSMA QDMR
Exceso sobre BSMA
1.600
1.400
1.200
1.000
0.800
0.600
5 7 9 11
Tamaño del Grupo
13 15 17 19
Fig. 32 Exceso sobre BSMA para la medida retardo promedio entre Fuente y Destinos en red de 20 nodos, grado
promedio igual a 4 y ocupación de enlaces entre 5 y 125 Mbps. (Algoritmos Restringidos y No Restringidos)
72

Trafico Background 45 - 85 [Mbps]
BCL KMB BCBW BCSAL PIM
MST KPP CAO BSMA QDMR
Retardo Promedio entre Fuente y Destinos[s]
2.100E-02
1.900E-02
1.700E-02
1.500E-02
1.300E-02
1.100E-02
9.000E-03
7.000E-03
5 7 9 11 13 15 17 19
Tamaño del Grupo
Fig. 33 Retardo promedio entre Fuente y Destinos en red de 20 nodos, grado promedio igual a 4 y ocupación de
enlaces entre 45 y 85 Mbps. (Algoritmos Restringidos y No Restringidos)
Trafico Background 45 - 85 [Mbps]
Exceso sobre BSMA
1.600
1.400
1.200
1.000
0.800
BCL KMB BCBW BCSAL PIM
MST KPP CAO BSMA QDMR
0.600
5 7 9 11 13 15 17 19
Tamaño del Grupo
Fig. 34 Exceso sobre BSMA para la medida retardo promedio entre Fuente y Destinos en red de 20 nodos, grado
promedio igual a 4 y ocupación de enlaces entre 45 y 85 Mbps. (Algoritmos Restringidos y No Restringidos)
73

Trafico Background 100 - 120 [Mbps]
Retardo Promedio entre Fuente y Destinos[s]
2.10E-02
1.90E-02
1.70E-02
1.50E-02
1.30E-02
1.10E-02
9.00E-03
BCL KMB BCBW BCSAL PIM
MST KPP CAO BSMA QDMR
7.00E-03
5 7 9 11 13 15 17 19
Tamaño del Grupo
Fig. 35 Retardo promedio entre Fuente y Destinos en red de 20 nodos, grado promedio igual a 4 y ocupación de
enlaces entre 100 y 120 Mbps. (Algoritmos Restringidos y No Restringidos)
Trafico Background 100 - 120 [Mbps]
BCL KMB BCBW BCSAL PIM
MST KPP CAO BSMA QDMR
Exceso sobre BSMA
1.600
1.400
1.200
1.000
0.800
0.600
5 7 9 11 13 15 17 19
Tamaño del Grupo
Fig. 36 Exceso sobre BSMA para la medida retardo promedio entre Fuente y Destinos en red de 20 nodos, grado
promedio igual a 4 y ocupación de enlaces entre 100 y 120 Mbps. (Algoritmos Restringidos y No Restringidos)
74

Trafico Background 100 - 120 [Mbps]
KMB BCL BCBW BCSAL
KPP CAO BSMA
Retardo promedio entre Fuente y Destinos [s]
3.90E-02
3.30E-02
2.70E-02
2.10E-02
1.50E-02
9.00E-03
3.00E-03
5 15 25 35 45 55 65 75 85
Tamaño del Grupo
Fig. 37 Retardo promedio entre Fuente y Destinos en red de 100 nodos, grado promedio igual a 4 y ocupación de
enlaces entre 100 y 120 Mbps. (Algoritmos Restringidos y No Restringidos)
Trafico Background 100 - 120 [Mbps]
KMB BCL BCBW BCSAL
KPP CAO BSMA
Exceso sobre BSMA
2.00E+00
1.80E+00
1.60E+00
1.40E+00
1.20E+00
1.00E+00
8.00E-01
6.00E-01
4.00E-01
5 15 25 35 45 55 65 75 85
Tamaño del Grupo
Fig. 38 Exceso sobre BSMA para la medida retardo promedio entre Fuente y Destinos en red de 50 nodos, grado
promedio igual a 4 y ocupación de enlaces entre 100 y 120 Mbps. (Algoritmos Restringidos y No Restringidos)
75

Número de Conexiones Exitosas
2.75E+03
2.27E+03
1.79E+03
1.31E+03
8.30E+02
BSMA KPP BCL BCBW BCSAL KMB CAO
3.50E+02
5 7 9 11 13
Tamaño del Grupo
15 17 19
Fig. 39 Número de Conexiones Exitosas frente a Solicitudes. Red de 20 nodos con grado promedio igual a 4.
Número total de solicitudes igual a 3000.
Número de Conexiones Exitosas
3.00E+03
2.70E+03
2.40E+03
2.10E+03
1.80E+03
1.50E+03
1.20E+03
9.00E+02
6.00E+02
BCL KMB BCBW BCSAL
3.00E+02
10 15 20 25 30 35 40 45 50
Tamaño del Grupo
Fig. 40 Número de Conexiones Exitosas frente a Solicitudes. Red de 50 nodos con grado promedio igual a 4.
Número total de solicitudes igual a 3000.
76

L
8 Conclusiones
os protocolos actualmente implementados utilizan como motor de funcionamiento
algoritmos generan árboles menos eficientes que varios de los algoritmos propuestos
en la literatura. Algunas de las razones por las cuales las propuestas en la literatura no
han sido implementadas es que requieren de información global para operar, no existen
implementaciones distribuidas para éstas o requieren de muchos recursos computacionales
en su ejecución.
En este trabajo se efectuó una comparación entre variados algoritmos, para conocer su
rendimiento en términos de la efectividad y eficiencia con que manejan los recursos de la red.
Los resultados de los experimentos realizados indican que la familia de heurísticas BC en
general tiene un mejor desempeño respecto a los otros algoritmos evaluados, tal como KMB o
BSMA, los cuales han sido evaluados favorablemente en la literatura. Además BC presenta la
ventaja de poder implementarse en forma distribuida y utilizar la información local existente
en las tablas de ruteamiento unicast de cada router. Esta información es necesaria para
evaluar la contribución de un enlace respecto a formar parte del árbol de distribución final.
Los resultados positivos de las heurísticas BC impulsan trabajos futuros tales como:
descripción detallada de una implementación distribuida para BC y BCL; incursiones acerca
de implementaciones de alguna heurística de la familia BC para redes inalámbricas y/o
ópticas; evaluación de otras medidas tales como: DCBR 9 (Diferencial Cal Blocking Rate), y
eficiencia multicast [3.4.7]; evaluación de los algoritmos en topologías tipo Internet
(utilizando generadores de topologías tales como: BRITE o GT‐ITM, entre otros); simulación
de tráfico y evaluación de medidas tales como: delay, jitter, pérdida de paquetes, etc., a partir
de algún experimento de simulación basado en la funcionalidad de MCRSIM.
9 La medida DCBR se basa en la medida Call Blocking Rate (CBR), que representa la capacidad que el
algoritmo tiene para establecer numerosas conexiones multicast antes de saturar los enlaces de la red. CBR
corresponde a la fracción de conexiones rechazadas sobre el total de solicitudes realizadas, es decir:
k
∑
i=
1
aceptada ( C i )
CBR = 1 −
, donde k es el número de solicitudes de conexión generadas por el simulador en cada
k
experimento, Ci corresponde a la i‐ésima solicitud de conexión, y aceptada(Ci) es una función que retorna 1 si Ci es
aceptada y 0 si es rechazada. DCBR es análogo a CBR pero obtener ésta medida se consideran solamente una cierta
cantidad de las últimas solicitudes de conexión.
77

S
9 Agradecimientos
e agradece a Carlos Gaule y Christian Bravo, administradores de ATMLAB de la
Universidad Técnica Federico Santa María, y Manuel Jander por ser habilitantes en la
obtención de las herramientas de simulación. A D. Reeves de N.C. State University por el
envío de un experimento de simulación utilizado en [56]. A L. Guo de Boston University por
el envío del código de QDMR utilizado en [40] para ser incorporado en MCRSIM. A Patricio
Moya y Ezequiel Muñoz, por posibilitar los viajes necesarios para la finalización de este
trabajo de tesis.
10 Referencias
[1] R. Talpade, M. Ammar, ʺSingle Connection Emulation (SCE): An Architecture for
Providing a Reliable Multicast Transport Service,ʺ 15th IEEE International Conference on
Distributed Computing Systems, 1995.
[2] S. Liang, D. Cheriton, “TCP‐SMO: Extending TCP to Support Medium‐Scale Multicast
Applications”, INFOCOM 2002.
[3] V. Visoottiviseth, T. Mogami, N. Demizu, Y. Kadobayashi, S. Yamaguchi, “M/TCP: The
Multicast‐extension to Transmission Control Protocol”, Muju, Korea, ICACT 2001.
[4] K. Jeacle, “TCP‐XM: Multicast Transport for Grid Computing” Cosener’s House,
Abingdon, Multi‐Service Networks 2003.
[5] S. Casner, S. Deering, “First IETF Internet Audiocast”, ACM Computer Communication
Review, Vol. 22, no.3, pp. 92‐97. July 1992.
[6] R. Vallejos, A. Zapata. ʺ“A Conceptualization for Classifying Multicast Routing
Algorithms”. Universidad Técnica Federico Santa María, 2000.
[7] S. Deering, D. Cheriton, “Multicast Routing in Datagram Internetworks and Extended
LANs”, ACM Transactions on Computer Systems, vol 8, no2, May 1990.
[8] A. Streigel, G. Manimaran, “A Survey of QoS Multicasting Issues”, IEEE
Communications Magazine, Jun 2002.
[9] M. Ramalho, “Intra‐ and Inter‐Domain Multicast Routing Protocols: A Survey and
Taxonomy”, IEEE Surveys & Tutorials, vol3, no.1, First Quarter 2000.
[10] B. Wang, J. Hou, “Multicast Routing and Its Extension: Problems, algorithms, and
Protocols”, IEEE Network, Jan/Feb 2000.
[11] P. Pragyansmita, S. V. Raghavan, “Survey of Multicast Routing and Protocols”, Indian
Institute of Technology Madras.
[12] T. Cormen, C. Leiserson, R. L. Rivest, C. Stein, “Introduction to algorithms”, Second
Edition MIT, 2001
[13] M. Garey, D. Jonson, “Computers and Intractability. A Guide to the Theory of NP‐
Completeness”, 22th Edition, 2000.
[14] V. Kompella, J. Pasquale, G. Polyzos, “Multicast Routing for Multimedia
Communication”, IEEE/ACM Transactions on Networking, vol.1, no. 3, Jun 1993.
[15] R. Prim, “Shortest Connection Networks and Some Generalizations”, The Bell Technical
Journal, vol 36, no. 6. pp 1389‐1401, Nov 1957.
78

[16] M. Barría, R. Vallejos, “Algoritmo para Recuperación de Errores en Comunicaciones
Multipunto”, Informe Técnico UTFSM ‐ UV, Ago 2003.
[17] A. El‐Sayed, V. Roca, “A survey of Proposals for an Alternative Group Communication
Service”, IEEE Network, Jan/Feb 2003.
[18] K. C. Almeroth, “The Evolution of Multicast: From the Mbone to Interdomain
Multicast to Internet2 Deployment”, IEEE Network, Jun 2000.
[19] R. Chalmers, K. C. Almeroth, “On Topology of Multicast Trees”, IEEE/ACM
Transanctions on Networking, Jun 2003.
[20] J. Chuang, M. Sirbu, “Pricing Multicast Communications: A Cost Based Approach”.
Proceedings of INET, 1998.
[21] M. Faloutsos, P. Faloutsos, C. Faloutsos, ʺOn Power‐Law Relationships of the Internet
Topologyʺ, Proceedings of the ACM SIGCOMM, Sept. 1999.
[22] R. Chalmers, K. Almeroth, “Modeling the Branching Characteristics and Efficiency
Gains in global Multicast Trees”, IEEE INFOCOM 2001.
[23] D. Waitzman, C. Partridge, S. Deering, “Distance Vector Multicast Routing Protocol”,
RFC 1075, 1988.
[24] B. Cain, S. Deering, I. Kouvelas, B. Fenner, A. Thyagarajan, “Internet Group
Management Protocol, Version 3”, RFC 3376, 2002.
[25] J. Moy, “Multicast Extensions to OSPF”, RFC 1584, 1994.
[26] A. Ballardie, “Core Based Trees (CBT) Multicast Routing Architecture”, RFC 2201, 1997.
[27] D. Thaler, C. Ravishankar, ʺDistributed Center Location Algorithmsʺ, IEEE JSAC,
vol.15, no.3, pp.291‐303, Apr. 1997.
[28] A. Adams, J. Nicholas, W. Siadak, “Protocol Independent Multicast ‐ Dense Mode
(PIM‐DM): Protocol Specification (Revised)”, Draft IETF, Feb 2003.
[29] B. Fenner, M. Handley, H. Holbrook, I. Kouvelas, “Protocol Independent Multicast ‐
Sparce Mode (PIM‐SM): Protocol Specification (Revised)”, Draft IETF, Mar 2003.
[30] S. Deering, “Host Extensions for IP Multicasting”, RFC 1112, August 1989.
[31] S. Deering, W. Fenner, B. Haberman, “Multicast Listener Discovery (MLD) for IPv6”,
RFC 2710, (Update by RFC3590, Sep 2003) October 1999.
[32] D. Thaler, “Border Gateway Multicast Protocol (BGMP)”, Internet Draft, June 2003.
[33] Y. Dalal, R. Metcalfe, “Reverse Path forwarding of Broadcast Packets” ACM
Communications, vol.21, no. 12, pp. 1040‐1048. Dec 1978.
[34] L. Sahasrabuddhe , B. Mukherjee, “Multicast Routing Algorithms and Protocols: A
Tutorial”, IEEE Network, Jan/Feb 2000.
[35] L. Kuo, G. Markowsky, L. Berman, “A Fast Algorithm for Steiner Trees”, Acta
Informatica 15, pp. 141 – 145, 1981.
[36] R. Vallejos, W. Creixell, A. Zapata, “A Multicast Routing Algorithm based on Link
Contribution”, 9th IFIP Conference on Performance Modelling and Evaluation of ATM & IP
Networks, Budapest, 2001.
[37] Q. Sun, H. Langendörfer, ʺEfficient Multicast Routing for Delay‐Sensitive
Applicationsʺ, Proceedings of the second Workshop on Protocols for Multimedia Systems
(PROMSʹ95), pp. 452‐458, October 1995.
[38] R. Widyono, ʺThe Design and Evaluation of Routing Algorithms for Real‐‐time
Channels.ʺ Technical Report (TR‐94‐024), International Computer Science Institute, UC
Berkeley, 1994.
[39] Q. Zhu, M. Parsa, J. Garcia‐Luna‐Aceves, ʺA Source‐Based Algorithm for Delay‐
Constrained Minimum‐Cost Multicastingʺ, Proceeding of IEEE INFOCOMʹ95, pp. 337 ‐
385, 1995.
79

[40] L. Guo, I. Matta, ʺQDMR: An Efficient QoS Dependent Multicast Routing Algorithmʺ,
Proceeding of 5 th IEEE realtime technology and application symposium (RTAS ʹ99),
Vancouver, Canada, June 1999.
[41] M. Aravena. Tesis de Magister (en Desarrollo). Universidad Técnica Federico Santa María,
Dic 2003.
[42] A. Shaikh, K. Shin, ʺDestination‐Driven Routing for Low‐Cost Multicastʺ, IEEE JSAC,
vol.15, no.3, pp. 373 ‐ 381, April 1997.
[43] A. Cobhan, ʺThe Intrinsic Computational Difficulty of Functionsʺ. Proc. International
Congress for Logic Methodology and Philosophy of Science, North Holland, Amsterdam. 1964.
[44] J. Edmonds, ʺPaths, Trees and Flowersʺ, Canad. J. Math. 1965.
[45] S. Cook. “The complexity of Theorem‐Proving Procedures”. Proc. 3 rd Ann. ACM Symp.
On Theory of computing, Association for Compiting Machinery, N.Y. 1971.
[46] R. Karp, “Reducibility Among Combinatorial Problems”, Complexity of Computer
Compatations, Plenum Press, N.Y. 1972.
[47] P. Huang, “Enabling Large‐scale Network Simulations: Selective Abstraction
Approach”, Ph.D. Thesis, University Of Southern California, Dec 1999.
[48] B. Waxman. “Routing of Multipoint Connections”. IEEE Journal on Selected Areas in
Communications, 6(9):1671‐‐1622, 1988.
[49] The Network Simulator ‐ ns‐2, http://www.isi.edu/nsnam/ns/.
[50] Mars Software, http://www.ccs.neu.edu/home/matta/software.html
[51] OMNet++, Discrete Events Simulation System, http://www.omnetpp.org/index.php.
[52] M. Thomas, E. Zegura. ʺGeneration and Analysis of Random Graphs to Model
Internetworks.ʺ Technical Report GIT‐CC‐94‐46, College of Computing, Georgia Tech, 1994.
(Software: GT‐ITM: Georgia Tech Internetwork Topology Models).
[53] A. Medina, A. Lakhina, I. Matta, J. Byers, “BRITE: An Approach to Universal Topology
Generation”, in Proceedings of MASCOTS 2001.
[54] J. Winick, S. Jamin, “Inet‐3.0: Internet Topology Generator”, Tech Report UM‐CSE‐TR‐
456‐02, Department of EECS, University of Michigan, 2002.
[55] C. Noronha, F. Tobagi ʺEvaluation of Multicast Routing Algorithms for Multimedia
Streamsʺ IEEE ITS94 Proceeding, Rio de Janeiro, Brazil,pp.1‐8 Aug. 1994.
[56] H. Salama ʺMulticast Routing for Real‐Time Communication on High‐Speed
Networksʺ, Ph.D. thesis, Department of Electrical and Computer Engineering, N.C. State
University, November 1996.
[57] H. Salama, D. Reeves, Y. Viniotis, ʺThe Delayed‐Constrained Minimum Spanning Tree
Problemʺ, Procs. Of 2 nd IEEE Symposium on Computers and Comunications (ISCCʹ97),
Alexandria, Egypt, July 1997.
[58] http://imj.ucsb.edu/mantra/
[59] H. Salama, “MCRSIM: The Multicast Routing Simulator. Version 2”,
http://rtcomm.csc.ncsu.edu/qos.htm, released September 1997.
[60] B. Maglaris, D. Anastassiou, P. Sen, G. Karlsson, J. Robbins, ʺPerformance Models of
Statistical Multiplexing in Packet Video Communications,ʺ IEEE Trans. on Comm., vol.
36, pp. 834‐843, July 1988.
[61] A.G. Waters, “A new heuristic for ATM multicast routing”. 2nd IFIP Workshop on
Performance Modelling and Evaluation of ATM Networks, pages 8/1‐8/9. University of
Bradford, July 1994.
[62] H. Salama, D. Reeves, Y. Viniotis. “Evaluation of Multicast Routing Algorithms for
Real‐Time Communication on High‐Speed Networks”. IEEE Journal on Selected Areas in
Communications, 15(3):332‐345, (p 77), April 1997.
80

[63] S. Ross. “Simulation”. Academic Press N.Y. 1997.
[64] R. Guérin. “Equivalent Capacity and Its Application to Bandwidth Allocation in High
Speed Networks”. IEEE Journal on Selected Areas in Communications, vol. 9, no 7, 1991.
81

ANEXO A : Función Complejidad de Tiempo & NP
Completitud
En simples palabras se puede decir que un algoritmo es una secuencia de pasos que
permiten resolver un problema. Normalmente, esta resolución involucra traducir el
algoritmo a algún lenguaje para computador. Esto último ya es una limitante en términos de
la comparación de algoritmos, pues el resultado de los algoritmos depende de la máquina en
la cual se trabaje, el lenguaje de programación utilizado, etc. Entonces ¿Cómo comparar
algoritmos de una manera objetiva?. En términos de la ejecución del algoritmo, un aspecto de
importancia es el tiempo que éste tarda en encontrar una solución. Se hace notar que en otros
ámbitos, tal como la ingeniería de software, lo que puede interesar es la compresión del
algoritmo. Sin embargo, teniendo en cuenta sólo el tiempo de ejecución del algoritmo: ¿cómo
juzgar cuál algoritmo se ejecuta más rápido?. En rigor esto no es posible, tal como se
menciona anteriormente, ya que el tiempo de ejecución depende del procesador de la
máquina, el lenguaje utilizado, el estilo de programación, etc. A pesar de esto es posible
medir cuantos pasos de computación elementales (operaciones básicas) realiza cada
algoritmo para encontrar una solución. Se asume que las operaciones básicas son aquellas
que demoran una unidad de tiempo de máquina, tales como: sumar, multiplicar, comparar,
etc.
Si se considera un algoritmo como una secuencia de pasos que se sigue para resolver un
problema, dada una cierta entrada de datos, el número de pasos del algoritmo depende del
tamaño de dicha entrada. Considerando un tamaño específico de la entrada, un algoritmo se
puede evaluar de distintas maneras. Algunas de estas formas de evaluación pueden
corresponder al peor caso, al mejor caso o al caso promedio.
Peor caso: El peor caso de tiempo de ejecución es el límite superior para el tiempo de
ejecución considerando cualquier entrada. El algoritmo no supera este valor en ningún caso.
Mejor caso: tiene definición análoga a la de peor caso.
Caso promedio: La idea es obtener el valor esperado para el tiempo. Normalmente se obtiene
suponiendo todas las entradas posibles con igual probabilidad.
Cada problema tiene asociado un tamaño, y el concepto exacto que mide el tamaño del
problema depende de su naturaleza. Así, para una entrada correspondiente a un vector, el
tamaño corresponde a su longitud; para una matriz, el número de elementos que la
componen; para un grafo, puede ser el número de nodos (a veces es más importante
considerar el número de arcos, dependiendo del tipo de problema a resolver); en un archivo
se suele usar el número de registros, etc. En general no es posible dictar una regla general,
pues cada problema tiene su propia lógica de costo.
El ʺtime complexity functionʺ (función de complejidad de un algoritmo) es una función
que depende del tamaño de la entrada al algoritmo, y expresa la mayor cantidad de tiempo
que el algoritmo requeriría para resolver el problema.
Casi siempre los problemas pequeños pueden resolverse de manera simple y de diversas
formas, sin embargo las limitaciones aparecen cuando se abordan problemas más grandes.
En consecuencia, interesa estudiar el comportamiento de un algoritmo cuando el tamaño del
problema crece, esto es cuando tiende a infinito.
82

Sea g(n) una función que determina el uso de recursos de un algoritmo en función del
tamaño n del problema. Es posible identificar familias de funciones según su
comportamiento asintótico. A un conjunto de funciones que comparten un mismo
comportamiento asintótico se les denomina un orden de complejidad. Habitualmente se
denota un orden de complejidad como O[ ] y se identifica por un miembro f(n) que se utiliza
como representante de la clase. Entonces, O[f(n)] define un orden de complejidad.
Por ejemplo, suponga que un problema puede resolverse con algoritmos de diferentes
complejidades. Para los algoritmos entre sí, se supone que todos ellos requieren 1 hora de
máquina para resolver un problema de tamaño N = 100.
¿Cuánto tiempo se requiere para resolver un problema de tamaño 2N?
¿Qué tamaño de problema puede resolverse si se dispone del doble de tiempo? La Tabla
6 muestra los resultados de las dos preguntas anteriores.
Tabla 6 Ejemplo de Orden de complejidad de Varios Algoritmos hipotéticos
O(f(n)) N = 100 N = 200 t = 2 h
log n 1 h 1.15 h 10000
n 1 h 2 h 200
n log n 1 h 2.30 h 199
n 2 1 h 4 h 141
n 3 1 h 8 h 126
2 n 1 h 10 30 h 101
Tal como ya se había mencionado, caracterizar un algoritmo clasificándolo como eficiente
o ineficiente en términos de su tiempo de ejecución, dependerá de la situación particular. Sin
embargo, especialistas en la materia [13] reconocen que existe una distinción simple para
clasificar un algoritmo. Esta distinción se realiza entre algoritmos de tiempo polinomial y
algoritmos de tiempo exponencial. Un algoritmo de tiempo polinomial está definido como
uno de orden O[p(n)], donde p(n) es alguna función polinomial. En cambio un algoritmo cuya
función de complejidad de tiempo (time complexity function) no pueda ser limitada, es
llamado un algoritmo de tiempo exponencial. Se debe notar que en esta última definición se
incluyen ciertas funciones de complejidad de tiempo no polinomiales, tal como n (log n) , las
cuales son normalmente consideradas como funciones no exponenciales. Esta distinción
fundamental entre algoritmos fue inicialmente discutida en [43], [44].
La Tabla 7 muestra en forma evidente porqué algoritmos de tiempo polinomial son más
“eficientes” a medida que el tamaño del problema aumenta.
Tabla 7 Varias Funciones de complejidad de Tiempo en función del Tamaño de un Problema
Función de
Tamaño del problema
complejidad
de Tiempo
10 20 30 40 50 60
N 0.00001 seg 0.00002 seg 0.00003 seg 0.00004 seg 0.00005 seg 0.00006 seg
n2 0.0001 seg 0.0004 seg 0.0009 seg 0.0016 seg 0.0025 seg 0.0036 seg
n3 0.001 seg 0.008 seg 0.027 seg 0.064 seg 0.125 seg 0.216 seg
n5 0.1 seg 3.2 seg 24.3 seg 1.7 min 5.2 min 13 min
2n 0.01 seg 1 seg 17.9 min 12.7 días 35.7 años 366 centurias
3 n 0.59 seg 58 min 6.5 años 3855
centurias
83
2x10 8
centurias
1.3x10 13
centurias

La distinción entre algoritmos “eficientes” e “ineficientes” en términos de su función de
complejidad de tiempo (polinomial o exponencial) es realizada tomando en cuenta una
medida de peor caso. Por ejemplo, un algoritmo con una función de complejidad de tiempo
2 n es más rápido que uno con función n 5 para problemas de tamaño menor a 20.
Sin bien algoritmos de tiempo polinomial son “deseables”, existen problemas que no
pueden ser resueltos con algoritmos de este tipo. O simplemente no se ha encontrado algún
algoritmo que los resuelva en tiempo polinomial. A este tipo de problemas se les llama
“problemas intratables”. Existen esfuerzos de teóricos para probar y encontrar cuales
problemas son intratables, y como relacionarlos entre ellos. Este trabajo se basa en la teoría de
la NP‐completitud, iniciada a comienzos de los 70s [45]. Uno de los tópicos de interés en [45]
es sobre una clase de problema: la clase NP de problemas de decisión (un problema de
decisión es aquel cuya solución es “sí” o “no”). Allí se sugiere que estos problemas pueden
ser resueltos en tiempo polinomial por computadores no deterministas, de allí el nombre NP
(no determinista polinomial). Esto insinúa que con la computación común existente hoy,
puede decirse que cuando se habla de un problema de decisión, se está hablando de un
problema intratable. Además, se menciona que existen problemas de la clase NP que tienen
una cierta particularidad, la cual permite que si a un problema de esta clase se le encuentra
alguna solución de tiempo polinomial, entonces todos los otros problemas en NP que tengan
esta particularidad podrán ser resueltos en tiempo polinomial. A sí mismo, si un problema en
NP es intratable, entonces todos los demás lo serán. A esta clase de problemas se les llama
NP “resistentes” (NP‐hard), dado que se resisten a permanecer en la clase NP. En [46] se
prueba que muchas versiones de problemas de decisión de problemas combinacionales
bastante conocidos, son NP resistentes. Existe una gama amplia de problemas con una
dificultad equivalente a los NP resistentes, los cuales se han categorizado en una clase de
problemas llamada NP‐completos. Sin embargo, hasta ahora existe la siguiente pregunta:
¿Son los problemas NP completos intratables?. Esta es una pregunta abierta, y por ahora, en
la práctica se utilizan heurísticas para resolver los llamados problemas NP‐completos, dado
que no se conoce algún algoritmo que pueda resolverlos en tiempo polinomial con
computadores deterministas.
En 3.3 se mencionó que varios problemas de ruteamiento multicast son problemas NP
completos, y por ello normalmente son utilizadas heurísticas.
84

ANEXO B: Breve Tutorial de Ns‐2
1 Introducción
Ns (versión 2) es un software orientado a objetos. Es un simulador desarrollado en la
universidad de Berkely, orientado al trabajo en redes. Está escrito en C++ y OTcl. Ns es
especialmente útil para simular redes de área amplia y local. Aunque el Ns es bastante fácil
de utilizar una vez que se ha familiarizado con el simulador, es bastante difícil trabajar la
primera vez, pues hay pocos manuales simples y breves. Aunque hay mucha documentación
escrita por los desarrolladores, que explican en profundidad el simulador, normalmente
están orientados a usuarios experimentados en el trabajo de Ns.
Esta ayuda intenta apoyar a los nuevos usuarios en una introducción rápida al uso del
simulador. Se verán tópicos tales como: configuración de las redes para la simulación; donde
buscar información adicional sobre componentes de red (en códigos del simulador); cómo
crear nuevos componentes de red; etc.
2 Contexto
Ns es un simulador que maneja una amplia variedad de redes IP. Incluye protocolos de
red, tales como TCP y UPD, considera el comportamiento de las fuentes de tráfico, tal como
ftp, telnet, Web, CBR y VBR, maneja mecanismos de administración de filas en los
ruteadores, tal como: DropTail, RED and CBQ, maneja algoritmos de ruteamiento tales como
Dijkstra, y otros. También considera redes multicasting y algunos protocolos de capa MAC
para simulaciones de LANs. El proyecto que inició Ns ahora es parte del VINT project que
desarrolla herramientas para la exhibición de los resultados de la simulación, el análisis de
los datos y herramientas que convierten al formato de Ns las topologías de red generadas por
software conocidos.
Actualmente está disponible la versión 2 de Ns, que está escrita en C++ y OTcl (lenguaje
orientado a objeto que se basa en el lenguaje Tcl, desarrollado en el MIT).
Este documento habla brevemente sobre la estructura básica del Ns, y explica
detalladamente cómo utilizar el Ns en base a ejemplos. La mayoría de las figuras utilizadas
para describir la estructura básica del Ns y los componentes de red, provienen de la siguiente
fuente: 5th VINT/Ns Simulator Tutorial/Workshop.
Figura 1: Una visión de usuario simplificada para Ns
85

La
Figura 1 muestra una visión de usuario de Ns simplificada. Ns es un intérprete de scripts
en lenguaje Tcl orientado a objeto (OTcl). Ns tiene un planificador de eventos para la
simulación, librerías de objetos que son componentes de red y librerías de módulos de
configuración de red (plumbing modules). Actualmente los módulos plumbing están
implementados como funciones miembros del objeto simulador base.
Para configurar y correr una simulación de una red el usuario deberá escribir un script en
OTcl que inicie un programa de eventos, configure una topología de red usando los objetos
de red y las funciones plumbing de la librería, y finalmente deberá anunciar el comienzo y
término de la transmisión de paquetes de las fuentes de tráfico dentro del planificador de
eventos.
Cuando un usuario quiere hacer un nuevo objeto de red, él puede hacerlo escribiendo un
nuevo objeto o haciendo un objeto compuesto a partir de la librería de objetos, junto con
conectar los datos entre objetos.
Otro componente importante de Ns, junto a los objetos de red, es el planificador de
acontecimientos (scheduler event). Un acontecimiento o evento en Ns es la identificación de
un único paquete en un tiempo programado, junto con un puntero a un objeto que maneja
dicho evento. En Ns, un scheduler event supervisa el tiempo de simulación e inicia todos los
eventos que hay programados en la cola de eventos para el instante actual, invocando los
componentes apropiados de red, que son generalmente los que solicitaron los eventos, y los
deja hacer las acciones apropiadas asociadas al paquete señalado por el evento.
Los componentes de la red se pasan paquetes a través de la comunicación existente entre
ellos, no obstante, esta actividad no consume tiempo real de simulación. Todas las
componentes de la red que necesitan dejar pasar un cierto tiempo de simulación para el
procesamiento de un paquete (es decir que consideran retardos en la componente), invocan
un evento que retarda la acción del evento que correspondía al paquete justo antes de pasar
por la componente.
Por ejemplo, para un componente de red correspondiente a un switch que posee un
retardo de conmutación de 20 microsegundos, solicita los eventos para los paquetes 20
microsegundos más tarde en la simulación. Luego de estos 20 microsegundos, el planificador
desencolará el evento para un paquete dado e iniciará la componente de red (switch), la cual
pasará el paquete a otro componente, que naturalmente corresponderá a un enlace.
Otro uso del planificador de eventos es el llevar la cuenta del tiempo. Por ejemplo, en TCP
se necesita un contador para saber cuando una transmisión de paquete a superado el time
out establecido en el protocolo, y así retransmitir el paquete. (La retransmisión del paquete se
realizará con el mismo número de transmisión TCP pero distinta identificación de paquete
para Ns).
Los contadores usan el planificador de eventos de manera similar a los retardos. La única
diferencia es que los contadores miden el tiempo asociado a un paquete y hacen la acción
apropiada relativa a ese paquete después de un tiempo específico, sin ser esto la simulación
de un retraso.
Ns no sólo está escrito en OTcl, si no que también en C++. Por razones de eficiencia, Ns
separa para la implementación los path de datos y control. A modo de reducir los paquetes y
el tiempo de procesamiento (no el tiempo de simulación), el planificador de eventos y los
86

objetos que son componentes básicos de red en el path de datos están escritos y compilados
usando C++. Estos objetos compilados están disponibles para el interprete de OTcl a través de
un una vinculación entre pares de objetos OTcl y objetos C++, además de hacer actuar a las
funciones de control y variables configurables especificadas por un objeto C++ como
funciones y variables miembro del correspondiente objeto OTcl. De este modo, se da el
control de los objetos C++ a OTcl. Esto hace posible también agregar funciones y variables
miembros a un objeto OTcl vinculado a C++. Los objetos C++ que no necesitan ser
controlados en una simulación o internamente usados por otro objeto, no necesitan ser
vinculados a OTcl. Análogamente, un objeto (que no está en el path de datos) puede ser
implementado completamente en OTcl. La Figura 2 muestra un ejemplo de objeto jerárquico
en C++ y OTcl. Se debe notar que para los objetos que forman una jerarquía en C++ y que
tienen vínculos con OTcl, existe una dualidad con una jerarquía muy similar de objetos OTcl
Figura 2: Dualidad entre C++ y OTcl
Figura 3: Arquitectura de Ns
La Figura 3 muestra la arquitectura general de Ns. En esta figura un usuario general (no un
desarrollador) puede considerar quedarse trabajando en la esquina izquierda inferior de la
figura, diseñando y corriendo simulaciones en Tcl usando el simulador de objetos de la
librería.
El planificador de eventos y la mayor parte de las componentes de red están
implementadas en C++ y están disponibles para OTcl a través de un vinculador OTcl (OTcl
linkage) que se implementa usando tclcl. El conjunto de todas estas cosas conforman el Ns, el
cual es un intérprete Tcl extendido a OO, con librerías para simulación de redes.
Esta sección examina brevemente la estructura general y la arquitectura de Ns. A esta
altura, uno podría preguntarse como obtener los resultados de la simulación en Ns. Como se
87

muestra en la
Figura 1, cuando una simulación finaliza, y si se ha especificado en el script de entrada Tcl
(o más específicamente OTcl), Ns produce uno o más archivos de salida en formato de texto
que contienen los datos de simulación detallados. Los datos pueden ser utilizados para
análisis de simulación (en secciones posteriores se muestran dos ejemplos de análisis de
simulación) o como entrada para la visualización gráfica de la simulación en la herramienta
llamada Network Animator (NAM) que fue desarrollada como parte del proyecto VINT,
como una interfase amigable similar a un CD player (con play, rewind, fase fordward, pausa,
etc.), y también con un controlador de la velocidad. Además, esta herramienta también
puede presentar información gráficamente, tal como throughput y el número de paquetes
que pasan por cada enlace, aunque ésta no pueda ser utilizada para análisis exactos.
3 Conceptos Básicos
3.1 OTcl, el leguaje de usuario
Como ya se menciono anteriormente, el Ns es básicamente un intérprete de OTcl con
librerías de objetos que permiten simular la red. Es muy útil saber programar en OTcl para
utilizar el Ns. Esta sección muestra un ejemplo en lenguaje Tcl y OTcl, que permite entender
la idea básica de la programación en OTcl. Se supone que el usuario ya ha instalado (ver
Anexo 1) Ns y maneja los conceptos de C y C++.
El ejemplo 1 es un script general en Tcl que muestra cómo crear y llamar un
procedimiento, cómo asignar valores a las variables, y cómo hacer un loop. Sabiendo que
OTcl es una extensión orientada a objeto de Tcl, es obvio que todos los comandos de Tcl
también trabajan en OTcl. La relación entre Tcl y Otcl es tal como la de C y C++. Para correr el
script se debe descargar el archivo ex‐tcl.tcl, y escribir ʺns ex‐tcl.tclʺ en la línea de comandos.
La sentencia “ns” inicia el Ns (que es un intérprete de OTcl). Se obtienen los mismos
resultados si se escribe ʺtcl ex‐tcl.tclʺ, siempre y cuando el tcl8.0 está instalado en la máquina.
Figura 4: Ejemplo de script Tcl
En Tcl, el comando proc se utiliza para definir un procedimiento, esta debe ir seguida
por un nombre y entre llaves escribir los argumentos del procedimiento. El comando set se
utiliza para asignar un valor a una variable. La sentencia [expr ...] es para hacer que el
88

intérprete calcule el valor de la expresión que está dentro del paréntesis cuadrado, después
del comando. Note que esto es para obtener el valor asignado a una variable, el comando $ es
usado con el nombre de la variable. El comando put imprime en la salida la secuencia escrita
entre comillas (“ ”). A continuación se muestran los resultados del ejemplo 1.
El próximo ejemplo está en escrito en OTcl. Este ejemplo es muy simple, pero muestra la
forma en la cuál se crea y utiliza un objeto OTcl. Como usuario común y corriente de Ns, sólo
en raras ocasiones escribirá su propio objeto. Sin embargo, puesto que todos los objetos del
Ns que utilizará están escritos en C++ (vinculados a OTcl) o puramente en OTcl, es bastante
útil que entienda este lenguaje.
Figura 5: Ejemplo Script OTcl
89

El ejemplo 2 es un script OTcl que crea dos objetos de diferentes clases, clase “mom”
(ʺmamaʺ) y clase “kid” (ʺniñoʺ). La clase “kid” es una clase hijo de la clase ʺmomʺ. Además,
este script define una función miembro llamada “greet” (ʺsaludoʺ) en cada clase.
En el ejemplo, después de las definiciones de clases, se establecen los valores de la
variable “age” para cada objeto creado, que se fijará en 45 para el objeto de clase “mom” y en
15 para el objeto de clase “kid”. Luego, se llamará a la función miembro ʺgreetʺ para cada
objeto.
El comando Class es para crear una clase de objeto e instproc es para definir una
función miembro para una clase de objeto. La herencia de clases es especificada usando el
comando superclass. En la definición de funciones miembro, $self actúa como el
puntero ʺthisʺ en C++, e instvar verifica si el nombre de la variable está declarada en su
clase o en la superclase. Si el nombre de la variable ya está declarado, la variable es
referenciada, si es que no se ha declarado nuevamente. Finalmente el comando new se utiliza
para crear un objeto, tal como muestra el ejemplo. Al descargar y ejecutar este ejemplo, que
corresponde al archivo ex‐otcl.tcl, se obtienen los siguientes resultados:
(Recuerde que para correr el ejemplo debe escribir en la línea de comando “ns ex‐
otcl.tclʺ).
3.2 Un ejemplo simple de simulación
Esta sección muestra un script muy simple de una simulación con Ns, aquí se explica lo
que hace cada línea del código. El ejemplo 3 es un script en OTcl que crea una configuración
de red bastante simple, tal como se observa en el esquema de la Figura 6. Para echar a correr
esta simulación, se debe descargar el archivo ns‐simple.tcl y escribir en la línea de comandos
ʺns ns‐simple.tclʺ.
90

Figura 6: Ejemplo de una topología de red simple y su escenario de simulación
La red de la Figura 6 se conforma de 4 nodos (n0, n1, n2 y n3). Los enlaces duplex entre
el nodo n0 y n2, y entre el nodo n1 y n2 tienen un ancho de banda de 10 Mbps y un retardo
de 10 ms. El enlace duplex entre n2 y n3 tiene un ancho de banda de 1.7 Mbps y 20 ms de
retardo. Cada nodo utiliza una metodología DropTail para el manejo de sus filas, las cuales
tienen un tamaño máximo de 10 unidades. Para este ejemplo se adjunta un agente “tcp” al
nodo n0, y se establece una conexión con el nodo n3, al cual se le ha adjunto un agente “sink”
tcp. Por defecto, el máximo tamaño de un paquete generado por un agente “tcp” es 1Kbyte.
Un agente “sink” tcp genera y envía paquetes ACK al emisor (agente tcp) y rescata los
paquetes recibidos.
Un agente “udp” es adjunto al nodo n1, el cual se conecta con el nodo n3, que tiene
adjunto un agente “null”. Note que un agente “null” solamente rescata los paquetes
recibidos. El esquema de red también considera generadores de tráfico “ftp” y “cbr” que son
adjuntos a los agentes “tcp” y “udp” respectivamente. El generador “cbr” es configurado
para generar paquetes de 1Kbyte a una tasa de 1 Mbps, y está configurado para comenzar a
los 0.1 seg. y parar a los 4.5 seg. Así mismo, el generador “ftp” está configurado para partir
justo después de 1 seg. y parar a los 4.0 seg.
91

Figura 7: Un Ejemplo simple de un script para simulación en Ns
A continuación se explica el script de la Figura 7.
92

En general, un script de Ns comienza con la creación de un objeto de clase simulador.
Set ns [new Simulator]: genera un objeto de Ns de clase simulador, y lo asigna a
la variable ns. (en esta sección se usa letra itálica para variables y valores). A continuación se
explica lo que esta línea hace:
• Inicializa el formato de los paquetes
• Crea un scheduler o planificador
• Selecciona el formato de direcciones por defecto
El objeto “Simulator” tiene una función miembro que hace lo siguiente:
• Crea objetos compuestos tal como nodos y enlaces (descritos más adelante)
• Conecta los objetos creados que son componentes de la red (con attach-agent)
• Establece los parámetros de las componentes de la red (en su mayor parte para
objetos compuestos)
• Crea la conexiones entre agentes (entre un agente “tcp” y un agente “sink” por
ejemplo)
• Especifica las opciones de despliegue de NAM
• Etc.
La mayoría de las funciones miembro son para configurar la simulación (vistas en la
sección “Contexto” como plumbing functions) y hacer la planificación para los eventos, sin
embargo algunas de estas funciones son para el visualizador NAM. Las implementaciones de
las funciones miembros del objeto “Simulator” están localizadas en el archivo ʺns‐2/tcl/lib/ns‐
lib.tclʺ.
$ns color fid color: especifica el color de los paquetes para un flujo de paquetes
especificado por fid. Esta función miembro del objeto “Simulator” es para el visualizador
NAM, y no tiene efecto sobre la simulación actual.
$ns namtrace-all file-descriptor: Esta función miembro dice al simulador que
registre las rutas de simulación en el formato de entrada de NAM. También da el nombre al
archivo de aquella ruta que será escrita después por el comando $ns flush-trace.
Similarmente, la función miembro trace-all es para registrar la ruta de simulación en el
formato general.
proc finish {}: es llamada después de la simulación y depués del comando $ns at
5.0. (Se llama al procedimiento después de 5 segundos del tiempo de simulación). En esta
función son especificados los procesos de post‐simulación.
set n0 [$ns node]: La función miembro node crea un nodo. Un nodo es un objeto
compuesto en Ns, hecho de direcciones y clasificadores de puerto (se describen en la sección
posterior). Los usuarios pueden crear un nodo creando por separado los objetos dirección y
clasificador de puerto, y luego conectándolos. Sin embargo, esta función miembro del objeto
Simulator ahorra un poco de trabajo. Para conocer como se crea un nodo, se pueden ver los
archivos: ʺns‐2/tcl/libs/ns‐lib.tclʺ y ʺns‐2/tcl/libs/ns‐node.tclʺ.
93

$ns duplex-link node1 node2 bandwidth delay queue-type: crea dos
enlaces simples de un ancho de banda y retardo específico, y conecta a dos nodos dados. En
Ns, la cola de salida de un nodo es implementada como parte de un enlace, en consecuencia
los usuarios podrían especificar el tipo de cola en el momento que crean un enlace. En el
script de simulación mostrado arriba, se usa una cola de tipo DropTail. Si se quisiera utilizar
un tipo de cola RED, simplemente se debe reemplazar la palabra Drop Tail por RED. La
implementación de un enlace en Ns se muestra en la sección posterior. Análogamente a un
nodo, un enlace es un objeto compuesto, y los usuarios pueden crearlo con subobjetos que se
conectan. El código fuente de los enlaces se puede encontrar en los archivos “ns‐2/tcl/libs/ns‐
lib.tclʺ y ʺns‐2/tcl/libs/ns‐link.tcl”. Cabe destacar que pueden insertarse módulos de error en
un componente de un enlace, con el fin de simular una pérdida de enlace (actualmente los
usuarios pueden hacer e insertar algún objeto de red). Para más detalles se puede ver la
documentación oficial de Ns.
$ns queue-limit node1 node2 number: Esta línea establece el límite de la cola (al
número especificado, number) para los dos enlaces simples que conectan al nodo n1 con el
nodo n2. Seguramente muchas de las cosas que están disponibles para las funciones
miembros del objeto Simulator no se han visto ni se verán en las siguientes secciones. Para
más detalles se pueden ver los archivos ʺns‐2/tcl/libs/ns‐lib.tclʺ y ʺns‐2/tcl/libs/ns‐link.tclʺ, o
bien la documentación oficial de Ns.
$ns duplex-link-op node1 node2 ...: después de esta sentencia, el próximo par
de líneas son usadas por el visualizador NAM. Para ver los efectos de estas líneas de código
los usuarios pueden comentarlas y ver que pasa en la simulación.
Ahora que está hecha la configuración básica de la red, el próximo paso es configurar los
agentes de tráfico tales como TCP y UDP, las fuentes de tráfico, tales como FTP y CBR, y
adjuntarlos a los nodos y agentes respectivamente.
set tcp [new Agent/TCP]: Esta línea muestra como crear un agente TCP. En
general, los usuarios pueden crear algún agente o fuente de tráfico de esta manera. Los
agentes y fuentes de tráfico son de hecho objetos básicos (no compuestos), la mayoría de ellos
están implementados en C++ y vinculados a OTcl. En consecuencia, no hay funciones
miembros específicas del objeto Simulator que creen estas clases de objetos. Para crear
agentes o fuentes de tráfico, un usuario debería conocer el nombre de la clase de estos objetos
(Agent/TCP, Agent/TCPSink, Application/FTP y así sucesivamente). Esta información se
puede obtener en la documentación oficial del Ns. Un atajo es ver el archivo ʺns‐2/tcl/libs/ns‐
default.tclʺ. Este archivo contiene los valores de los parámetros configurables por defecto
para los objetos de red disponibles.
$ns attach-agent node agent: La función miembro attach-agent adjunta un
objeto agente creado para un objeto nodo. Actualmente, lo que hace esta función es llamar a
la función miembro “attach” de un nodo específico, el cual adjunta el agente dado para el. En
consecuencia, un usuario puede hacer la misma cosa, por ejemplo, $n0 attach $tcp.
Similarmente, cada objeto agente tiene una función miembro attach-agent que adjunta un
objeto fuente de tráfico a si mismo.
$ns connect agent1 agent2: Después que los dos agentes creados están
comunicados, el próximo paso a seguir es establecer la conexión lógica de red entre ellos.
94

Esta línea establece una conexión de red al especificar las direcciones destino de cada red y
las direcciones de los puertos del par de agentes.
Suponiendo que toda la configuración de red ya está hecha, lo siguiente es escribir un
escenario de simulación (e.d. un planificador de eventos).
El objeto Simulator tiene muchas funciones miembro para la planificación de eventos.
Sin embargo, una de las más usadas es la siguiente:
$ns at time "string": Esta función miembro del objeto Simulator hace la
planificación (scheduler 10 ) para la ejecución de un cierto plan de eventos restringido al
tiempo de simulación. Por ejemplo, $ns at 0.1 "$cbr start" hace que el planificador
llame a la función miembro start del objeto fuente de tráfico CBR, el cual comienza a
transmitir datos en el tiempo 0.1 segundos de la simulación.
En Ns, usualmente las fuentes de tráfico no transmiten los datos actuales, pues estos
notifican al agente por debajo de ellos que tienen que transmitir una cierta cantidad de datos,
y ellos saben exactamente que cantidad de datos transmitir, así que crean los paquetes y los
envían.
Después de toda la configuración, se realizan la planificación y los procedimientos de
post‐simulación. La única cosa necesaria para correr la simulación es escribir $ns run.
10 scheduler_ es la variable que apunta al objeto planificador creado por el comando [new Scheduler] que
normalmente va al comienzo del script
95

4 ¿Cómo instalar Ns en Windows?
Existen varias maneras de instalar Ns, y cada una dependerá de la plataforma en donde
se quiera trabajar. Si se quiere seguir trabajando en Windows, es necesario tener un emulador
de linux en el PC. Para ello se puede bajar Cygwin para Microsoft Windows
9x/ME/NT/2000/XP.
Otro aspecto que debe considerarse, es saber si se quiere instalar Ns, paquete por
paquete o todo de una vez. Existe un paquete de instalación de Ns llamado “allinone” (todo
en uno), el cual corre un script que crea automáticamente el makefile necesario para dejar
andando Ns de una vez.
Para correr NAM en tu Cygwin ya instalado es necesario tener algún servidor X
corriendo. Para ello se debe instalar Cygwin XFree86 Server .
¿Cómo comienzo?
• Para ns‐allinone‐2.26
o Necesitas ns‐allinone‐2.26, disponible en http://www.isi.edu/nsnam/dist/ns‐
allinone‐2.26.tar.gz
o Todos los parches para Cygwin tienen que ser incluidos en la distribución
base. Necesitaras bajar nam-1.9.configure, disponible aquí.
• Para ns‐allinone‐2.1b9a
o Necesitas ns-allinone-2.1b9a y el parche para gcc‐3.2, disponible en
http://www.isi.edu/nsnam/dist/ns‐allinone‐2.1b9a‐gcc32.tar.gz
o El parche se localiza en http://www.cs.virginia.edu/~nicolas/software/ns‐
allinone‐2.1b9a‐gcc32‐cygwin.patch
• Para instalar ns‐2
• ns‐allinone‐2.26
o Pon el archivo ns-allinone-2.26.tar.gz en el directorio home de tu
Cygwin (típicamente algo como C:\cygwin\home\vero)
o Pon también el archivo nam-1.9.configure en tu directorio home de
Cygwin.
o Hecha a andar Cygwin, y comienza un XFree86 server para ver
adecuadamente (usando startx)
o De la línea de comandos Cygwin, corre los siguientes comandos:
o gzip -d -c ns-allinone-2.26.tar.gz | tar xvf -
o mv nam-1.9.configure ns-allinone-2.26/nam-1.9/configure
o Ahora puedes instalar todo haciendo lo siguiente:
o cd ns-allinone-2.26
o ./install
Puedes correr algunos test de validación (Esto es opcional). Así se hace:
cd ns-2.26; ./validate
Después se debe actualizar el PATH, y las variables de ambiente
LD_LIBRARY_PATH, y el TCL_LIBRARY tal como se indica al final del
proceso de instalación. Por ejemplo, asumiendo que ya está instalado ns‐2 en
el directorio home, se deberían escribir los siguientes comandos para
actualizar las variables:
96

export NS_HOME=$HOME/ns-allinone-2.26
export
PATH=$NS_HOME/tcl8.3.2/unix:$NS_HOME/tk8.3.2/unix:$NS_HO
ME/bin:$PATH
export
LD_LIBRARY_PATH=$NS_HOME/tcl8.3.2/unix:$NS_HOME/tk8.3.2/
unix:\
$NS_HOME/otcl-
1.0a8:$NS_HOME/lib:$LD_LIBRARY_PATH
export TCL_LIBRARY=$NS_HOME/tcl8.3.2/library
(Reemplaza el contenido de NS_HOME con el directorio donde instaló ns)
Para evitar retipear este comando todas las veces se puede poner lo
anterior en el archivo ~/.bashrc tal que se ejecute automáticamente cada
vez que entra con el login.
• ns‐allinone‐2.1b9a
•
o Ponga el archive ns-allinone-2.1b9a-gcc32.tar.gz en el directorio
home de Cygwin (típicamente algo como C:\cygwin\home\vero)
o También ponga el archivo parche ns-allinone-2.1b9a-gcc32cygwin.patch
en el directorio home.
o Inicie Cygwin, y comience un XFree86 server para ver adecuadamente
(usando startx)
o De la línea de comandos de Cygwin, corra los siguientes comandos:
o gzip -d -c ns-allinone-2.1b9a-gcc32.tar.gz | tar xvf -
o cd ns-allinone-2.1b9a
o patch -p0 < ../ns-allinone-2.1b9a-gcc32-cygwin.patch
Se debería obtener la siguiente salida:
patching file ./gt-itm/src/Makefile
patching file ./install
patching file ./nam-1.0a11a/config.sub
patching file ./nam-1.0a11a/configure
patching file ./ns-2.1b9a/bin/raw2xg
patching file ./ns-2.1b9a/diffusion3/lib/nr/nr.hh
patching file ./ns-2.1b9a/tcl/test/test-suite-simplefull.tcl
patching file ./sgb/Makefile
patching file ./tcl8.3.2/generic/tcl.h
patching file ./tcl8.3.2/unix/Makefile.in
Si se está corriendo la versión de Cygwin entre 1.3.12 y 1.3.16‐1, se
requiere modificar el archivo install en el directorio top de la distribución.
Se debe reemplazar lo siguiente:
cd ./xgraph-$XGRAPHVER
./configure
por
97

5 Routing Module
cd ./xgraph-$XGRAPHVER
./configure
touch stamp-h
Si los parches funcionaron exitosamente, entonces se puede correr el script
de instalación:
./install
Si los parches fallaron, esto probablemente significa que ha modificado
previamente el árbol de ns tratando de aplicar el parche, o no usó nsallinone-2.1b9a-gcc32.
Para ver detalles respecto de esto puede visitar
el sitio: what the patch actually does y hacer los cambios a mano.
Los test de validación opcionales se corren así:
cd ns-2.1b9a; ./validate
Después debe actualizarse el PATH, y las variables de ambiente
LD_LIBRARY_PATH, and TCL_LIBRARY como se indica al final del proceso
de instalación. Asumiendo que ya ha finalizado el proceso de instalación
debería anotarse lo siguiente:
export NS_HOME=$HOME/ns-allinone-2.1b9a
export
PATH=$NS_HOME/tcl8.3.2/unix:$NS_HOME/tk8.3.2/unix:$NS_HO
ME/bin:$PATH
export
LD_LIBRARY_PATH=$NS_HOME/tcl8.3.2/unix:$NS_HOME/tk8.3.2/
unix:\
$NS_HOME/otcl-
1.0a8:$NS_HOME/lib:$LD_LIBRARY_PATH
export TCL_LIBRARY=$NS_HOME/tcl8.3.2/library
En general, cualquier implementación de ruteamiento en ns consiste de tres bloques de
función:
Routing agent intercambia los paquetes de ruteamiento con los vecinos,
Route logic usa la información recogida por los agentes de ruteamiento (o la base de datos de
la topología global en el caso de ruteamiento estático) para ejecutar el cómputo de la ruta
actual,
Classifiers situado dentro de un Nodo. Ellos usan la tabla de ruteamiento calculada para
realizar el envío de los paquetes.
Note que cuando se implementa un nuevo protocolo de ruteamiento, no necesariamente
deberán alterarse estos tres bloques de función. Por ejemplo, al implementar un protocolo de
ruteamiento de estado de enlace, se podría sólo implementar un agente de ruteamiento que
intercambie información del estado de enlaces y un route logic que efectúe Dijkstra sobre la
base de datos con la topología resultante. Entonces, se puede usar los mismos classifiers que
otro protocolo de ruteamiento unicast.
98

Cuando la implementación de un nuevo protocolo de ruteamiento incluye más que un
bloque de función, especialmente cuando este contiene un nuevo classifier, conviene crear un
nuevo objeto, al cual se le llama routing module. Este puede manejar todos los bloques de
función y ser una interfase con el nodo para organizar los classifiers. La Figura 8 muestra la
relación funcional entre estos objetos. Note que el routing module podría tener una relación
directa con los bloques de computo de las rutas, es decir, route logic y/o routing agents. Sin
embargo, el cómputo de las rutas no necesariamente se instala en el routing module, pues allí
podrían existir otros módulos que estén interesados en conocer las nuevas rutas. Esto no es
un requerimiento, sin embargo, es posible que algún cómputo de las rutas este especificado
para un routing module particular, como por ejemplo la utilización de label en un módulo
MPLS.
Figure 8: Interacción entre nodo, routing module, y routing. La línea segmentada indica
el detalle de un routing module.
Un módulo de ruteamiento contiene tres funcionalidades principales:
1. Un routing module que inicializa la conexión a un nodo a través de un register{}, y
desactiva un conexión mediante unregister{}. Usualmente, en un register{} un routing
module (1) llama al nodo si éste está interesado en conocer las actualizaciones de rutas y
adjunta un transport agent, además (2) crea los classifiers y los instala en el nodo. En el
unregister{} un routing module hace exactamente lo opuesto: los classifiers son eliminados,
se remueven las ligas sobre las actualizaciones en los nodos.
2. Si un routing module está interesado en conocer las actualizaciones de ruteamiento, el
nodo informará al módulo vía un RtModule::add‐route{dst, target} y RtModule::delete‐
route{dst, nullagent}.
3. Si un routing module está interesado en conocer acerca de las ligas y desuniones con
un transport agent en un nodo, el nodo informará al módulo vía RtModule::attach{agent,
port} y RtModule::detach{agent, nullagent}.
Existen dos pasos para escribir un módulo propio:
99

1. Se requiere declarar en C++ parte de el routing module propio (ver
~ns/rtmodule.{cc,h}). Para muchos módulos esto sólo significa declarar un método virtual
name() el cual entrega un descriptor de string del módulo. Sin embargo, existe la libertad
tantas funcionalidades como C++ lo permita; pero necesariamente se deberá enlazar después
esta funcionalidad con OTcl para un mejor rendimiento.
2. Si se desea se puede ir más allá de las implementaciones de interfaces en el módulo de
ruteamiento básico (ver ~ns/tcl/lib/ns‐rtmodule.tcl) y decidir utilizar algún módulo ya
existente, sobreescribirlo, y ponerle las interfase Otcl en para su propio módulo.
Hay varios módulos de ruteamiento de ejemplo en ~ns/tcl/lib/ns‐rtmodule.tcl, los cuales
puede servir como una plantilla para sus propios módulos
Actualmente existen seis módulos implementados en ns:
100

ANEXO C: Breve Manual de Uso MCRSIM
MCRSIM es una herramienta de software especializada en la simulación de algoritmos de
ruteamiento multicast. MCRSIM está escrito en C++ y usa funciones de las librerías Motif y X
para implementar la interfase gráfica. El software opera sobre máquinas Unix que soportan
un ambiente Xwindows.
MCRSIM permite a los usuarios crear y editar redes, agregando o borrando nodos y
enlaces. El usuario puede tambien crear grupos y fuentes multicast. Se pueden establecer
conexiones desde una fuente a varios miembros de un grupo, aplicando los diferentes
algoritmos de ruteamiento que provea el simulador. También es posible simular flujos de
paquetes en la red para medir por ejemplo retardos fin a fin y pérdidas de paquetes sobre el
árbol resultante. Las estadísticas de transmisión de paquetes son escritas en un archivo de
salida.
El archivo de salida del simulador entrega la siguiente información: dirección del grupo,
identificación de la fuente, identificación del miembro del grupo, número de celdas recibidas,
número de celdas perdidas, tasa promedio de pérdida, número de celdas que superar el
deadline, mínimo retardo fin a fin, máximo retardo fin a fin, jitter, promedio del retardo fin a
fin, intervalo de confianza alcanzado para el retardo, intervalo de confianza alcanzado para
la tasa de pérdida.
A partir del motor de simulación de MCRSIM se pueden programar experimentos que
evalúen la calidad de los árboles generados por los distintos algoritmos implementados en él,
y la efectividad que éstos algoritmos tienen para manejar los recursos de la red.
Para obtener resultados como los presentados en esta tesis se debe manejar los
componentes del simulador.
La Tabla 8
101

Tabla 8muestra una descripción de los archivos de MCRSIM.
Los experimentos de simulación son efectuados por los archivos router15.c y router1.noh.c
para el primer y segundo experimento respectivamente.
Las entradas para router1.noh.c (segundo experimento) son:
1. Archivo con red inicial para el experimento, con una determinada cantidad de
nodos. A esta tesis se adjunta un CD con los archivos de MCRSIM y adicionalmente
cuatro archivos con redes de Waxman con 20, 50, 100 y 200 nodos (net20, net50,
net100 y net200 respectivamente).
2. Nombre del archivo de salida del experimento
3. Intervalo de confianza (en este trabajo el intervalo de confianza utilizado fue de 0.05)
4. Cantidad de tráfico Background Mínima en los enlaces de la red, medida en Mbps
5. Cantidad de tráfico Background Máxima en los enlaces de la red, medida en Mbps
6. Porcentaje de admisión de tráfico sobre los enlaces de la red (0.85 en este trabajo)
7. Límite de Retardo máximo entre fuente y destinos (0.03 segundos en este trabajo)
8. Número asignado al algoritmo, definido en node2.h
9. Definición de si el algoritmo es o no restringido (0 para no restringidos, 1 para
restringidos)
Asignación de números a algoritmos en node2.h:
#define dksld 0 //Dijkstra's least-delay
#define kmb 1 //KMB heuristic for unconstrained Steiner tree
#define atm2 2 //Modified Waters ATM heuristic
#define cao 3 //Tenet constrained adaptive routing algorithm
#define bsma 4 //UCSC constrained algorithm
#define cstc 5 //2nd constrained MC heuristic by Polyzos //KPP COST
#define cstcd 6 //1st constrained MC heuristic by Polyzos //KPP COST&DELAY
#define atm 7 //Waters ATM heuristic
#define bf 8 //Bellman-Ford least-cost alg.
#define dks 9 //Dijkstra's least-cost alg.
#define pim 10 //PIM routing alg.
#define mst 11 //MST heuristic
#define dcdimst 12 //delay-constrained directed MST
#define copt 13 //optimal branch and bound based constr. Steiner tree alg.
#define opt 14 //optimal branch and bound based unconstr. Steiner tree alg.
#define dimst 15
#define dvmrp 16
#define bfnoadm 17
#define cdks 18
#define qdmr 20 //define the QDMR algorithm
#define bc 21 //define algortimo BestContribution:heuristica=ANCHOBANDA
#define bcal 22 //define algortimo BestContribution:heuristica=ALCANCE
#define bcsal 23 //define algortimo BestContribution : heuristica = SALTOS
#define bcdvir 24 //define algortimo BestContribution:heuristica = DISTVIRTUAL
#define bcl 25 //define algortimo BestContribution "Light": heuristica=SALTO
Ejemplo: Para ejecutar el segundo experimento con el algoritmo KMB, con una red de 20
nodos, intervalo de confianza igual a 0.05, tráfico background entre 100 y 120 Mbps,
porcentaje máximo de ocupación de los enlaces de la red igual a 85% y 0.03 segundos como
límite máximo de retardo entre fuente y destinos, se debe escribir lo siguiente en la línea de
comandos:
%bash:~$ ./router1.noh net20 nombre_archivo_salida.txt 0.05 100 120 0.85 0.03 1 0
102

Tabla 8 Archivos de MCRSIM
NOMBRE DESCRIPCIÓN
Adicional.c Archivo con funciones complementarias para: localizar un nodo dentro de
un área de 5 pixeles a una determinada localización; refrescar el área
dibujada; dibujar las fuentes multicast.
data.h Define un paquete de datos para propositos de simulaión en una red de
computadores.
Event.c / event.h Define las clases C++: Event; EvenListEntry; TheEventList; para usarlas en
un simulador de ventos discretos para redes de computadores.
Graphics.c / graphics.h Librería de clases C++ para representar nodos, enlaces, caminos, etc., de la
red gráficamente.
Makefile Archivo para compilación y generación de ejecutable
Node2.h / node2.c Librería que define: nodo; tabla de ruteamiento; fuentes; lista de
adyacentes; y la administración para la operación de la red. node2.c
contiene: la función de simulación; el generador de grafos y enlaces
aleatorios; funciones para leer de un archivo y escribir a un archivo; y otras
funciones.
Queue.c / queue.h Librería de clases C++ para representar las colas FIFO y prioridades de
cola.
RoutATM.c, routBC.c, routBF.c, Algortimos de ruteamiento implementados para el simulador.
routBFNOADM.c, routBCL.c,
routBSMA.c, routCAO.c, routCDKS.c,
routCST.c, routDCDIMST.c,
routDVMRP.c, routKMB.c, routLD.c,
routQDMR.c, routOPT.c
sim.c Programa principal, llamadas Motif y manejador de eventos.
sim.h Archivo de cabecera para el programa principal.
Source.c Funciones para crear y modelar diferentes fuentes de tráfico.
stats.c / stats.h Librería de clases C++ usada para colectar las estadísticas del simulador de
eventos discretos.
traf.c Funciones para manejar las llegadas y partidas de paquetes desde y hacia
un nodo.
Windos.c / windows.h Librería de componentes Motif encapsulados en clases C++
103

ANEXO D: Código BC para MCRSIM
A continuación se muestra el código en C++ para las distintas heurísticas de la familia
BC. El código de BCL es análogo y sólo se modifican un par de líneas. Para ello se puede
revisar el pseudocódigo en 4.2.2.
//define Heuristicas
#define ANCHOBANDA 1
#define ALCANCE 2
#define SALTOS 3
#define DISTVIRTUAL 4
double TheNodeList::routerBC(int alg, Node *source, int addr, double &d,
double &maxd, double &mind, double &h,
double &nodes) {
//Primero se borra cualquier ruteamiento previo para este grupo y fuente.
removeTree(source, addr);
int heuristica;
//TIPO HEURISTICA
if (alg == bc) heuristica = 1;
if (alg == bcal) heuristica = 2;
if (alg == bcsal) heuristica = 3;
if (alg == bcdvir) heuristica = 4;
//Localiza la fuente y obtiene el peak rate
SourceList *ss = source->sourceList();
int Foundd = False;
while ((ss != NULL) && (Foundd == False)) {
if ((ss->source()->type() != Background) &&
(ss->source()->address() == addr)) Foundd = True;
else ss = ss->next();
};
double pk = ss->source()->peak();
double avg = ss->source()->average();
//Localiza el grupo Mcast que contiene el grupo de destinos
MCGroup *group = groupsHd;
while ((group != NULL) && (group->address() != addr))
group = group->next();
if (group == NULL) {
//printf("Group = NULL");
return(NOGROUP);
}
//si el grupo tiene solo a la fuente, el costo del arbol es 0
if ((group->count() == 1) &&
(group->headm()->nodePtr()->name() == source->name())) {
source->addRoutingEntry(addr, source);
h = d = maxd = mind = 0;
nodes = 1;
return(0);
};
////variables ///////////////////
double CostAdy = 0.0;
double CostoAd = 0.0;
double *CostAdj = new double[num]; //arreglo con costos de los nodos adyacentes
int AllDestinInTree = False;
104

NodeListEntry *Entra1;
int NumDestAgreg = 0;
int elmejor;
int fromBC;
int nodosBC;
///
int seg1, seg2;
int ArbolParcialId;
int AdjEvalId;
double contrib = 0.0;
double suma = 0.0;
double invsuma = 0.0;
double *Contribucion;
double *CostMatrixBC;
CostMatrixBC = new double[num*num];
int *desde;
desde = new int[num];
double *CostLCMatrix;
CostLCMatrix = new double[num];
Contribucion = new double[num];
int i,j;
short *pVisitedBC = new short[num]; // Indicador de visitado
short *flagDestin2 = new short [num]; // 1 si es un destino, 0 en cualquier otro
caso
short *pAgreg = new short[num]; // Indicador de Agregado al Arbol;
//////////end variables /////
//////////////////////////Ahora_BestContribution /////////////////////////////////////
//Inicio Para Marcar a los nodos agregados al arbol
for (int bb = 0; bb < num; bb++) {
pAgreg[bb] = 0; //marca como no agregado a todos los nodos excepto la fuente
if ( bb == source->name() ) {
pAgreg[bb] = 1; //marca a la fuente como agregada
//printf("Fuente : %d \n", bb);
}
}
/////////fin marca nodos agregados
//La fuente es el primer miembro en el arbol
NodeListEntry *Entra0 = new NodeListEntry;
NodeListEntry *UltEntra = new NodeListEntry; //Ultima entrada
Entra0->nodePtr(source);
source->addRoutingEntry(addr, source);
UltEntra = Entra0;
////fin fuente primer miembro en el arbol
///////////Marca los Destinos
short *flagDestin = new short [num]; // 1 si es un destino, 0 en cualquier otro caso
NodeListEntry *Marca;
Marca = group->headm();
while(Marca != NULL) {
flagDestin[Marca->nodePtr()->name()] = 1;
//printf("Miembro : %d\n", Marca->nodePtr()->name());
Marca = Marca->next();
}
///////////fin marca Destinos
///Ahora se va armando el arbol final a partir de atachar cada nodo
//adjunto que mejor contribuye al arbol parcial
///Para experimentos en donde la fuente puede salir como un miembro por
aleatoriedad///
if ( flagDestin[source->name()] == 1 ) {
NumDestAgreg = 1;
//printf("OJO FUENTE ES UN MIEMBRO\n");
105

eturn(0);
//break;
}
////fin de esta exepcion
//loop de mientras no se complete el arbol final (con todos los miembros)
while(AllDestinInTree == False) {
//loop de todos los miembros del arbol parcial en busca del mejor adyacente
do {
AdjacencyListEntry *adj = Entra0->nodePtr()->adjacentNodes(); //la ultima
entrada en el arbol
//loop de todos los adyacentes a cada miembro del arbol parcial
while (adj != NULL) {
int fuenteDKS = adj->nodePtr()->name(); //para DIJKSTRA
//un adyacente al arbol parcial
if ( pAgreg[adj->nodePtr()->name()] == 1) {
//si el adyacente ya está en el arbol
adj=adj->next();
}
else if ( pAgreg[adj->nodePtr()->name()] == 0 ) {
//si el adyacente no está en el arbol
// se evalua su contribucion
///////////////////////////////////////DIJKSTRA--A--ADJ //////////////////////////////
//Inicializo la matriz con la informacion de los costos
//de los enlaces de cada nodo y los indicadores de visitado y destino
//+ dos matrices para el calculo del arbol dijktra
for (i = 0; i < num; i ++) {
for (j = 0; j < num; j ++)
*(CostMatrixBC + i * num + j) = DBL_MAX;
flagDestin2[i] = 0;
pVisitedBC[i] = 0; //UNVISITED;
CostLCMatrix[i] = DBL_MAX;
desde[i] = INT_MAX;
};
//Fin inicio matriz costos enlaces
//Marco con 1 a los nodos que son destinos
NodeListEntry *tmpp2;
tmpp2 = group->headm();
while(tmpp2 != NULL) {
flagDestin2[tmpp2->nodePtr()->name()] = 1;
//printf("Miembro en DIJKSTRA : %d \n", tmpp2->nodePtr()->name());
tmpp2 = tmpp2->next();
};
//Fin marcado destinos
//Para obtener el costo promedio por enlace
//e inicializar la matriz de costos desde cada nodo a sus adjacentes
int nLinkCount = 0;
double avgLkCost = 0.0;
double factor = 0.0;
NodeListEntry *tmpp = nodeListHd; //la cabeza de la lista de nodos (de la red)
while (tmpp != NULL) {
i = tmpp->nodePtr()->name();
AdjacencyListEntry *adjac = tmpp->nodePtr()->adjacentNodes();
while (adjac != NULL) {
j = adjac->nodePtr()->name();
switch (heuristica) {
case ANCHOBANDA:
if (fn == PEAK) {
*(CostMatrixBC + (i * num) + j) = adjac->peak();
106

nLinkCount ++;
avgLkCost += adjac->peak();
adjac = adjac->next();
};
if (fn == AVERAGE) {
*(CostMatrixBC + (i * num) + j) = adjac->average();
nLinkCount ++;
avgLkCost += adjac->average();
adjac = adjac->next();
};
break;
case ALCANCE:
*(CostMatrixBC + (i * num) + j) = adjac->delay();
nLinkCount ++;
avgLkCost += adjac->delay();
adjac = adjac->next();
break;
case SALTOS:
*(CostMatrixBC + (i * num) + j) = 1;
nLinkCount ++;
avgLkCost += 1;
adjac = adjac->next();
break;
case DISTVIRTUAL:
*(CostMatrixBC + (i * num) + j) = 1;
nLinkCount ++;
avgLkCost += adjac->peak();
adjac = adjac->next();
break;
}; //fin case heurisitca
};
tmpp = tmpp->next();
};
assert(nLinkCount);
avgLkCost = (double)avgLkCost / nLinkCount;
//Fin costo promedio y llenado matriz de costos de enlace
////////// Se computa el arbol de minimo costo con Dijkstra
*(CostLCMatrix + fuenteDKS) = 0; //dijkstra desde fuenteDKS
//= adyacente del arbol parcial
evaluandoce
//printf("ADJ evaluandose : %d desde : %d\n", fuenteDKS, Entra0->nodePtr()-
>name());
int numOnTreeGroupMembers = 0;
double minCost;
int min, u, v;
for (i = 0; i < num; i ++) {
// El loop del for se ejecuta exactamente |V| veces;
// Extrae el nodo con el minimo costo
//En la primera iteracion parte de fuenteDKS (porque tiene costo cero)
minCost = DBL_MAX;
for (u = 0; u < num; u ++) {
if (pVisitedBC[u] == 0) { //UNVISITED
if (CostLCMatrix[u] < minCost) {
minCost = CostLCMatrix[u];
min = u;
};
};
};
u = min;
pVisitedBC[u] = 1; //VISITED
if (flagDestin2[u] == 1) numOnTreeGroupMembers ++;
if (numOnTreeGroupMembers == group->count()) break;
for (v = 0; v < num; v ++) {
if (pVisitedBC[v] == 0) { //UNVISITED
if (CostLCMatrix[v] > CostLCMatrix[u] + CostMatrixBC[u *
num + v]) {
Node *ndd = nodeOf(v);
107

adjacentNodes();
adjacen->next();
pk))) ||
nodePtr() != ndd) adjacen =
//chequea la capacidad de los links
if (((fn == PEAK) && (adjacen->peak() linkCapacity() * ADMITRATIO) -
((fn == AVERAGE) && (adjacen->average()
((adjacen->linkCapacity() * ADMITRATIO) -
//CostLCMatrix va almacenando el costo de
//pto pto de fuenteDKS a cada nodo
CostLCMatrix[v] = CostLCMatrix[u] +
//'desde' es un arreglo que indica el
//(por la ruta pto a pto).
desde[v] = u;
///////////INICIO///////CASO ALCANCE//////////////// (Steiner restringido a retardo)
// Find the maximum minimum delay of all dest nodes;
// Important for making routing policy;
double maxMinDelayBC = 0.0;
switch (heuristica) {
case ANCHOBANDA:
//nada
break;
case ALCANCE:
for (int ur = 0; ur < num; ur ++) {
if (flagDestin2[ur] == 1) {
if (CostLCMatrix[ur] > maxMinDelayBC)
maxMinDelayBC = CostLCMatrix[ur];
};
};
if (maxMinDelayBC > DELAYBOUND) {
delete [] pAgreg;
delete [] Entra0;
delete [] Entra1;
delete [] UltEntra;
delete [] flagDestin;
//delete [] temp;
//delete [] temp1;
//delete [] temp2;
delete [] CostAdj;
delete [] Contribucion;
delete [] desde;
delete [] CostMatrixBC;
delete [] flagDestin2;
delete [] CostLCMatrix;
delete [] pVisitedBC;
return (DBVIOL);
}
break;
case SALTOS:
//nada
break;
case DISTVIRTUAL:
//nada
break;
};
108

FIN/////////CASO ALCANCE//////////////// (Steiner restringido a retardo)
///////////////////Fin Dijkstra /////////////////////////////
//Asignacion de Contribucion del nodo Adjacente evaluandose /////
Contribucion[fuenteDKS] = 0.0;
double menordelay = DBL_MAX;
double factor2 = 0.0;
//printf("ADJ en asignacion de contribucion = %d\n", adj->nodePtr()->name());
//fuente DKS
for (int vv = 0; vv < num; vv ++) {
if (flagDestin2[vv] == 1) {
(padre fuenteDKS)
//adjace = fuenteDKS
miembros
al miembro con menor retardo
los nodos del arbol
contribucion
miembros (medido en saltos)
//test para succ 22 de spt 03
if (CostLCMatrix[vv] >= DBL_MAX) {
if (pAgreg != NULL) delete [] pAgreg;
//if (Entra0 != NULL) delete [] Entra0;
//if (Entra1 != NULL) delete [] Entra1;
//if (UltEntra != NULL) delete [] UltEntra;
if (flagDestin != NULL) delete [] flagDestin;
if (CostAdj != NULL) delete [] CostAdj;
//if (Contribucion != NULL) delete [] Contribucion;
if (desde != NULL) delete [] desde;
if (CostMatrixBC != NULL) delete [] CostMatrixBC;
if (flagDestin2 != NULL) delete [] flagDestin2;
if (CostLCMatrix != NULL) delete [] CostLCMatrix;
if (pVisitedBC != NULL) delete [] pVisitedBC;
return(LINKSAT);
}
ArbolParcialId = Entra0->nodePtr()->name(); //desde Arb. parc.
AdjEvalId = adj->nodePtr()->name(); //fuenteDKS
Node *AdjEval = nodeOf(AdjEvalId);
Node *deArbolParcial = nodeOf(ArbolParcialId);
AdjacencyListEntry *adjace = deArbolParcial->adjacentNodes();
while (adjace->nodePtr() != AdjEval) adjace = adjace->next();
switch (heuristica) {
//enlace que mejor contribuye a acercar a todos los
//(medido en costo del enlace = BW ocupado)
case ANCHOBANDA:
suma = adjace->peak() + CostLCMatrix[vv]; //fuenteDKS
//printf("Aporte [%d] = %.5e\n", vv, suma);
invsuma = 1/suma;
//printf("Invsuma = %.5e\n", invsuma);
Contribucion[fuenteDKS] += invsuma;
break;
//Esrategia Greeddy MinDelay{miembros}, agrega primero
//es util en caso de requerir info rapida desde todos
case ALCANCE:
suma = adjace->delay() + CostLCMatrix[vv]; //fuenteDKS
//printf("Aporte [%d] = %.5e\n", vv, suma);
if ( menordelay >= suma) {
menordelay = suma;
invsuma = 1/suma; //menor delay -> mayor
//printf("Invsuma = %.5e\n", invsuma);
Contribucion[fuenteDKS] = invsuma;
}
break;
//enlace que mejor contribuye a acercar a todos los
case SALTOS:
109

fuenteDKS
suma = (1 + CostLCMatrix[vv]); //fuenteDKS
//printf("Aporte [%d] = %.5e\n", vv, suma);
invsuma = 1/suma;
//printf("Invsuma = %.5e\n", invsuma);
Contribucion[fuenteDKS] += invsuma;
break;
case DISTVIRTUAL:
suma = adjace->peak()*(1 + CostLCMatrix[vv]);
//printf("Aporte [%d] = %.5e\n", vv, suma);
invsuma = 1/suma;
//printf("Invsuma = %.5e\n", invsuma);
Contribucion[fuenteDKS] += invsuma;
break;
}; //fin case heuristica
};
//printf("Contribucion parcial = %.5e\n", Contribucion[fuenteDKS]);
};
////Fin Asignacion //////
//Borrado Memoria
/*
delete [] desde;
delete [] CostMatrixBC;
delete [] flagDestin2;
delete [] CostLCMatrix;
delete [] pVisitedBC;
*/
////////////////////////////////////FIN--DIJKSTRA--A--ADJ////////////////////////////
CostAdj[adj->nodePtr()->name()] = Contribucion[fuenteDKS];
//printf("Contribucion de ADJ: %d = %.5e \n", fuenteDKS,
Contribucion[fuenteDKS]);
//printf("Mayor Aporte hasta este Momento -> %.4e // y //
Contribucion de %d evaluandose ahora -> %.4e\n", CostAdy, adj->nodePtr()->name(),
CostAdj[adj->nodePtr()->name()]);
if (CostAdy nodePtr()->name()]) {
//se mantiene la mayor contribucion en CostAdy
CostAdy = CostAdj[adj->nodePtr()->name()];
elmejor = adj->nodePtr()->name(); //e.d. quien va siendo
"el mejor"
fromBC = Entra0->nodePtr()->name(); // de donde viene el
adyacente "mejor"
//printf("RESUMEN: Desce %d al Mejor Parcial %d >>
CONTRIBUCION(%d) = %.5e \n", fromBC, elmejor, elmejor, CostAdy);
};
//if ((adj->next()) == NULL) break;
adj=adj->next();
}
else return(9999); //Esto no debiera pasar
}; //end loop [while] de todos los adyacentes a cada miembro del arbol parcial
Entra0 = Entra0 -> next();
//if (Entra0->next()==NULL) break;
} while (Entra0 != NULL); //end loop [do] de todos los miembros del arbol parcial
//Una vez elegido el nodo adyacente que mejor contribuye a la expacion del arbol
parcial
//se agrega tal nodo al arbol
Entra0 = UltEntra; //para recorrer la lista desde la ultima entrada de el mejor
nodo adj al arbol parcial
////////////////////PREVIENE CREACION DE ARBOL CON ENLACES SATURADOS //////////////
if ( CostAdj[elmejor] == DBL_MAX) {
if (pAgreg != NULL) delete [] pAgreg;
if (Entra0 != NULL) delete [] Entra0;
if (Entra1 != NULL) delete [] Entra1;
if (UltEntra != NULL) delete [] UltEntra;
if (flagDestin != NULL) delete [] flagDestin;
if (CostAdj != NULL) delete [] CostAdj;
110

if (Contribucion != NULL) delete [] Contribucion;
if (desde != NULL) delete [] desde;
if (CostMatrixBC != NULL) delete [] CostMatrixBC;
if (flagDestin2 != NULL) delete [] flagDestin2;
if (CostLCMatrix != NULL) delete [] CostLCMatrix;
if (pVisitedBC != NULL) delete [] pVisitedBC;
return(LINKSAT);
}
//////////////////////////////////////////////////////////////////////////////////////
//se_agrega_"el_mejor"_al_arbol///////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////////////////////////////
Node *ndBC = nodeOf(elmejor);
//printf("El MEJOR en esta ronda = %d\n", elmejor);
Node *fromBCNd = nodeOf(fromBC);
//printf("DESDE = %d en el Arbol parcial\n", fromBC);
Entra1 = new NodeListEntry;
Entra1->nodePtr(ndBC);
Entra1->next(Entra0);
Entra0 = Entra1; //Entra0 es ahora la entrada recien agegada
UltEntra = Entra0; //UltEntra es ahora la ultima entrada en la lista enlazada
CostAdy = 0;
ndBC->addRoutingEntry(addr, source); //define al mejor nodo de esta ronda como una
entrada a la tabla de ruta del arbol
//update the link cost: dado que el mejor fue agregado a la ruta del arbol
AdjacencyListEntry *adja = fromBCNd->adjacentNodes();
while (adja->nodePtr() != ndBC) adja = adja->next();
if (adja == NULL)
assert(0);
double wght = adja->peak() + pk;
adja->peak(wght); //ocupa el link recien agregado con el ancho de banda de la
fuente
double average = adja->average() + avg;
adja->average(average);
//and add it to the routing table
//agrega al mejor adyacente a la tabla de ruta desde fromBC
fromBCNd->addChild(addr, source, ndBC);
//////////////////////////////////////////////////////////////////////////////////////
////////fin_agregar_mejor_nodo_adyacente//////////////////////////////////////////////
//////////////////////////////////////////////////////////////////////////////////////
//si "el mejor" es un destino, se marca este destino como agregado al Arbol
//e incrementa contador de miembros en el arbol
if ((flagDestin[elmejor]) == 1) {
pAgreg[elmejor] = 1;
//printf("DESTINO ---> %d %d

calcula_el_delay_y_saltos_para_resultados_generales//////////////////////
int dbViolation = False;
maxd = 0;
mind = DBL_MAX;
//calculate the expected end-to-end delay and the average number of hops
//and the cost per destination
NodeListEntry *tmp2BC;
tmp2BC = group->headm();
double avgDelay = 0;
double avgHops = 0;
while (tmp2BC != NULL) {
int gotit = False;
int hops = 0;
double delay = 0;
if (source != tmp2BC->nodePtr())
results(source, addr, source, tmp2BC->nodePtr(), delay, hops, gotit);
if (delay > DELAYBOUND) dbViolation = True;
if (delay > maxd) maxd = delay;
if (delay < mind) mind = delay;
avgDelay += delay;
avgHops += hops;
tmp2BC = tmp2BC->next();
};
avgDelay /= group->count();
avgHops /= group->count();
d = avgDelay;
h = avgHops;
///////////////////fin_calcula_el_delay_y_saltos_para_resultados_generales////////////
/////////////////////////////////////////////////////////////////
//Calcula el costo total del arbol y borra el arbol temporal/////
/////////////////////////////////////////////////////////////////
double totalCost = 0.0;
nodosBC = 0;
NodeListEntry *temp1BC, *temp2, *temp = new NodeListEntry;
temp1BC = UltEntra;
while (temp1BC != NULL) {
nodosBC++;
RoutingTableEntry *rout = temp1BC->nodePtr()->routingTable();
int Found = False;
while ((rout != NULL) && (Found == False)) {
if ((rout->address() == addr) && (rout->source() == source))
Found = True;
else rout = rout->next();
};
NodeListEntry *temp = rout->children();
while (temp != NULL) {
AdjacencyListEntry *adjj = temp1BC->nodePtr()->adjacentNodes();
int Found2 = False;
while ((adjj != NULL) && (Found2 == False)) {
if (adjj->nodePtr() == temp->nodePtr()) Found2 = True;
else adjj = adjj->next();
};
if (adjj != NULL) {
if (fn == PEAK) totalCost += (adjj->peak() - pk);
else totalCost += (adjj->average() - avg);
};
temp = temp->next();
};
temp2 = temp1BC->next();
delete temp1BC;
temp1BC = temp2;
};
///Limpia memoria dinamica
if (pAgreg != NULL) delete [] pAgreg;
112

if (Entra0 != NULL) delete [] Entra0;
//if (Entra1 != NULL) delete [] Entra1;
//if (UltEntra != NULL) delete [] UltEntra;
if (flagDestin != NULL) delete [] flagDestin;
if (temp != NULL) delete [] temp;
if (temp1BC != NULL) delete [] temp1BC;
if (temp2 != NULL) delete [] temp2;
if (CostAdj != NULL) delete [] CostAdj;
if (Contribucion != NULL) delete [] Contribucion;
if (desde != NULL) delete [] desde;
if (CostMatrixBC != NULL) delete [] CostMatrixBC;
if (flagDestin2 != NULL) delete [] flagDestin2;
if (CostLCMatrix != NULL) delete [] CostLCMatrix;
if (pVisitedBC != NULL) delete [] pVisitedBC;
/////////Fin limpia Memoria///////
//printf("COSTO TOTAL = %.6e\n", totalCost);
return(totalCost);
////////////////////////////////////////////////////////////////////////
}; //end RoutBC
113