Aprovechamiento de la topología y reparto de carga

ARP-Path, al igual que SPB y TRILL, y al contrario de RSTP, no excluye ningún enlace de la topología a la hora de poder ser usado en las comunicaciones, es decir, por definición aprovecha los recursos de la topología al completo. Pero no sólo eso, dado que construye caminos de baja latencia, los nuevos caminos tenderán a utilizar partes de la topología no utilizadas, repartiendo de manera natural la carga a lo largo de la red.

Para demostrar este punto, a continuación se muestran resultados experimentales:

Demostración de reparto de carga mediante emisión de tráfico UDP en la implementación de ARP-Path en OMNeT++:

A la hora de demostrar el reparto de carga que realiza de manera nativa ARP- Path se escogió primero la aplicación de un generador de flujos (Apéndice F) aleatorio en SimPy [SimPy], paquete de simulación basado Python, cuyos resultados fueron tan satisfactorios que se decidió pasar el modelo a OMNeT++, que simula paquetes y tráfico en realidad de flujos y simulación un poco más a alto nivel. La topología utilizada fue la misma que para SimPy, que es la malla de 3x3 que se mostraba en la Figura 72.

Así pues, se realizaron 6 simulaciones de 15000 segundos cada una, para hacer la media, todas con enlaces de 100Mbps, frecuencia de generación de flujos 1.6 segundos uniforme entre todos los hosts, y se midieron las rutas generadas entre los hosts del puente 0 y el puente 8 en ambos sentidos (en verde se muestra el porcentaje de rutas totales que escogió cada enlace) y la utilización del enlace en cada sentido de recepción (en negro). Como se ve en la siguiente figura, tanto el porcentaje de rutas, como la utilización están bastante equilibrados a lo largo de la red. De hecho, en el puente 0 se divide casi en 50% y 50% entre el puente 1 y 3, y estos a su vez dividen de nuevo entre dos (25% y 25%) para los puentes que continúan el camino, y al llegar al puente 8 tenemos más o menos 50% desde el puente 5 y 50% desde el 7. El hecho de que no sea exactamente 50% y 50% (como sucedía con SimPy) posiblemente se debe a que no se haya alcanzado un estado transitorio de la simulación y entonces algunas rutas llevan flujos mayores.

Figura 74. Reparto de carga en topología de malla para OMNeT++ con generador de flujos uniforme de frecuencia 1.6 segundos y enlaces a 100Mbps

Demostración de reparto de carga mediante emisión de tráfico UDP en la implementación de ARP-Path en NetFPGA:

Tras demostrar el reparto de carga con el simulador OMNeT++, se decidió probar dicho reparto en una plataforma real, en este caso las tarjetas NetFPGA. Lógicamente, es imposible transformar el generador de flujos (Apéndice F) a un generador real con tantos hosts, por lo que en su lugar se utilizaron máquinas virtuales y flujos de vídeo streaming UDP, tal y como se adelantaba gracias a la estancia de colaboración en el Cambridge Computer Laboratory. Eso sí, la topología en malla se mantuvo, para comparar directamente unos resultados con otros.

El escenario realizado es el mismo ya descrito para el apartado de latencia mínima en un único sentido. En el switch 0 hay un servidor VLC y en el 8 están los clientes VLC y se emite tráfico streaming de vídeo UDP desde servidor a cada cliente, uno a uno. En la Figura 75 se muestra los resultados obtenidos para una media de 4 repeticiones en las que el número de clientes en el puente 8 es 4, mientras que en la Figura 76 se muestran los resultados para una media de 4 repeticiones también, pero con 8 clientes en el puente 8, en lugar de 4. Nótese que, a diferencia del caso anterior, una vez creados los 4 y 8 flujos (respectivamente), ya se miden las rutas y que el tiempo de ejecución no es un parámetro (pues no se crearán más flujos). Además, no es posible medir la utilización del canal en este caso (de ahí los valores a cero).

Figura 75. Reparto de carga en topología de malla para switches ARP-Path

implementados en tarjetas NetFPGA con tráfico streaming UDP de vídeo entre los

puentes 0 y 8 (1 servidor y 4 clientes)

Figura 76. Reparto de carga en topología de malla para switches ARP-Path

implementados en tarjetas NetFPGA con tráfico streaming UDP de vídeo entre los

Como es posible apreciar, en ambos casos existe reparto de carga y es incluso similar a los resultados obtenidos en OMNeT++ en los que el tráfico se va dividiendo entre dos en cada bifurcación, es decir, en cada puente el 50% del tráfico que llega va por un enlace al siguiente puente y el 50% restante al otro. Es cierto que en este caso todos los flujos tienen el mismo tamaño, entonces el número de rutas encaja más porque todas las rutas llevan flujos iguales (cosa que no sucede en OMNeT++), pero también es cierto que con sólo 4 y 8 flujos existe un reparto de carga muy bueno, similar al reparto que sucede con un mayor número de flujos (cientos, en el caso de simulaciones de OMNeT++ de más de 10000 segundos) y mayor tráfico.

Finalmente, como curiosidad, a continuación se muestran algunas imágenes del montaje realizado en el CCL que consistía en:

 9 switches ARP-Path, que eran PCs con sistema operativo CentOS y la tarjeta NetFPGA instalada con el proyecto de ARP-Path

 1 pantalla para arrancar y monitorizar los switches anteriores

 1 host servidor VLC y 1 host con 4/8 máquinas virtuales clientes VLC

Figura 77. Algunos de los switches ARP-Path (cada switch es un PC con una tarjeta NetFPGA instalada en él) del montaje en malla realizado en el CCL

Figura 78. Host conectado al switch 8 que contiene las 8 máquinas virtuales que

actúan como clientes VLC, en las que se ve como reciben el tráfico streaming de vídeo