UNIVERSIDAD DEL NORTE

DEPARTAMENTO DE INGENIERÍAS ELÉCTRICA Y ELECTRÓNICA

Asesor:Jairo Cardona.

Informe Final
PF05: José A. Samudio, Jonathan J Santis
{velaj, jjsantis} @uninorte.edu.co
18 de Noviembre de 2019

I.INTRODUCCIÓN
La arquitectura de las redes convencionales proveen “el mejor esfuerzo” lo que no garantiza
una calidad de servicio (Qos) efectiva. Sin embargo la organización internacional Grupo de
trabajo de Ingeniería de Internet (IETF) exploró diversas arquitecturas de Qos para lograr
una mejor calidad en base a las redes convencionales. Estas son IntServ y DiffServ; aunque
no han sido implementadas de manera global debido que se trabaja sobre las redes
actuales que carecen de recursos de red de extremo a extremo. El Internet está divido en
sistemas autónomos (AS), estos son los provedores de servicio de Internet (ISP),
Universidades y/o empresas comerciales. Para brindar calidad de servicio a nivel inter-AS
e Intra-AS, se hace de la siguiente manera: a nivel Intra, el protocolo de enrutamiento
OSPF tiene una extensión que brinda Qos pero a nivel Inter está el protocolo de
enrutamiento BGP4 no tiene soporte para la Qos. El foco de este protocolo es la
accesibilidad de la red[18]. Además los protocolos de enrutamiento a nivel dentro del
dominio autónomo no presentan calidad de servicio, lo que significa que a nivel de red
privada el flujo de tráfico no es soportado por calidad de servicio en base al Ancho de Banda
(BW) o retraso de paquetes (Delay).

Por lo anterior se da a conocer las redes definidas por Software (SDN) el cual brinda una
propuesta de una red centralizada, el cual desafía la arquitectura de red de hoy en dia y
ademas de los protocolos de red. Esto último es debido que separa el plano de datos
(forwarding) y el plano de control, lo que lleva a que ciertos algoritmos de enrutamiento
distribuidos tengan que ser replanteados, entre ellos los que se relacionan con Qos. Los
protocolos de enrutamientos de red se basan en la ruta más óptima en base al menor coste
del camino (menor número de saltos). Por lo tanto el presente proyecto busca implementar
una topología de red SDN (virtualizada) sobre el cual se emplea un algoritmo de
enrutamiento multicamino llamado UDIC que está basado en dos restricciones: Ancho de
Banda y retraso de los paquetes. Dicho enrutamiento básicamente consiste en identificar
entre dos tipos de flujos y enrutar uno de estos en base a los requerimientos de la red en
cuestión. Este proyecto de importante porque permite ir trabajando en el área y tendiendo
experiencia en la implementación y configuración de redes SDN, así como el desarrollo de
aplicaciones que permitan mejorar el enrutamiento de las redes.

1
II.OBJETIVO GENERAL
Diseño de un prototipo de algoritmo para el enrutamiento multicamino en Redes SDN.

III.OBJETIVOS ESPECÍFICOS
OE1. Implementación y configuración de la topología SDN en un ambiente virtual.

OE2. Diseño y desarrollo del algoritmo.

OE3. Validar el algoritmo propuesto con respecto a la ruta más corta.

2
IV.DELIMITACIÓN

A. ALCANCES

Para establecer cuáles serán los resultados que se esperan obtener al finalizar este
proyecto, se han definido los siguientes alcances.

❖ Recrear de manera virtual una red SDN.

❖ Crear un prototipo de aplicación que hallará la ruta más óptima para el tráfico de la
red con la restricción de Ancho de banda y retardo de paquetes.
❖ El tráfico a utilizar es VideoStreaming e ICMP.
❖ Se implementará solo un algoritmo.

B. LIMITACIONES

Estas son las contingencias del impacto que tendrán los

resultados del proyecto.

❖ El prototipo de la aplicación solo puede ser

❖ utilizada en una red SDN virtualizada.
❖ El rendimiento de la máquina en la funcionará la aplicación no será tenido en cuenta.
❖ Se trabajarán máximo 8 nodos.

C. ENTREGABLES

Los resultados del proyecto se verán plasmados en los

siguientes puntos.

❖ Manual de instalación.
❖ Manual de usuario.
❖ Código fuente en Github.
❖ Artículo.
❖ Vídeo.
❖ Póster.
❖ Presentación final.

3
V.ESTADO DEL ARTE
Con el establecimiento reciente del modelo de redes SDN, ha nacido la necesidad de
explorar alternativas que garanticen la calidad del servicio que se ofrece a los usuarios
finales. Una de estas propuestas apunta al desarrollo de algoritmos de enrutamiento que
aseguren que la información llegue de la manera más óptima a su destino. Estos algoritmos
tienen una gran versatilidad debido a la estructura misma de las redes SDN, ya que al tener
el control centralizado de toda la red, el algoritmo es capaz de enviar las directrices
necesarias para que el flujo de datos ocurra en las rutas que cumplan las restricciones o
las necesidades de cada tipo de dato.

Figura 1. Esquema de una topología SDN.

Muchos de estos algoritmos están basados en Dijkstra, que aunque fue uno de los métodos
más utilizados en las redes convencionales, debe ser modificado para cumplir con los
nuevos requerimientos de la red. Esto permite calcular múltiples caminos para el transporte
de paquetes. Estas rutas pueden ser guardadas en una Hashmap y el controlador puede
verificar periódicamente el estado de cada uno de los enlaces.
En HiQoS, separan los tipos de datos en colas y a estás se les asignan prioridades y un
cierto ancho de banda dependiendo de cada aplicación. Esto para garantizar el uso al
máximo del ancho de banda disponible en una ruta. Cuando un paquete llega, si el switch
que lo recibe no tiene una ruta preestablecida, el paquete será enviado al controlador para
que este decida en base al ancho de banda y al uso de las colas, la ruta más adecuada [8]
En este caso, el cálculo de los múltiples caminos se hace obedeciendo a la ecuación (1)
que sus diseñadores crearon para obtener el coste de transportar la información por ciertas
rutas.

𝐿𝑒 = 𝛼 ∙ 𝑝𝑟𝑖𝑐𝑒(𝑒) + 𝛽 ∙ 𝑑𝑖𝑠𝑡(𝑒) − 𝛾 ∙ 𝑏𝑤 …(1)

Dónde price(e) es un valor de combinación estimado por el precio para usar el enlace, la
estabilidad de este y su robustez. dist(e) y bw son la distancia física y el ancho de banda
del enlace respectivamente. α, β y γ son los pesos del costo respectivamente.

Esto da como resultado un menor retardo en el tiempo de llegada de los paquetes a su

destino, lo que corrobora la ruta calculada como la más adecuada para suplir las
necesidades de la red, garantizando que se cumple la restricción de ancho de banda
requerida para una excelente calidad de servicio.

4
Otro de los algoritmos basados en Dijkstra, que se han implementado en redes definidas
por software, es DFS. Este algoritmo hace un recorrido minucioso del grafo que representa
la red en cuestión y va asignándole pesos a cada enlace para al final calcular el coste de
uso de cada ruta posible.
Estos pesos obedecen a las prioridades del administrador de la red, quien define sus
valores dependiendo de la relevancia del paquete. Cuando se calcula el peso de un enlace,
teniendo en cuenta el ancho de banda que consume el enlace, los autores utilizan la
siguiente expresión basada en OSPF.

𝐶𝑜𝑠𝑡 (𝑙 ) =
𝐵𝑊𝑟𝑒𝑓𝑒𝑟𝑒𝑛𝑐𝑒
; 𝐵𝑊(𝑙 ) = 𝑚í𝑛(𝐵𝑊𝑠𝑤𝑖𝑡𝑐ℎ1 , 𝐵𝑊𝑠𝑤𝑖𝑡𝑐ℎ2 ) …(2)
𝐵𝑊(𝑙)

Dónde para un enlace l, Cost(l) es el coste del enlace, 𝐵𝑊𝑟𝑒𝑓𝑒𝑟𝑒𝑛𝑐𝑒 es el ancho de banda
de referencia, para el cual utilizan por defecto 1Gbps, BW(l) es el ancho de banda del enlace
y 𝐵𝑊𝑠𝑤𝑖𝑡𝑐ℎ es el ancho de banda de la interfaz del switch [5].

Para controlar el transporte de los paquetes, el controlador puede tomar todas las
decisiones de enrutamiento, pero a la larga se busca entrenar a los switches para que
reconozcan cierto tipo de flujo y lo encamine a una ruta ya preestablecida por el algoritmo
DFS, esto se logra instalando “OpenFlow rules” en cada switch.

La arquitectura del internet está diseñada para “mejor-esfuerzo” en la transmisión de datos

por lo que no puede garantizar o prometer sobre el retraso del paquete para la última milla
o la variación del retraso (jitter) entre paquetes consecutivos, lo cual es de suma importancia
para la transmisión multimedia. Debido a esto han desarrollado soluciones temporales que
brindan cierta calidad de servicio. El IEFT propone arquitecturas para Qos como IntServ y
Diffserv. MPLS da una solución parcial con switches altamente rápidos y capaces. Ahora
bien, para el modelo IntServ provee calidad de servicio usando RSVP, protocolo de reserva
de recurso, ya sea reserva o liberación de ancho de banda en un camino en específico de
la red. Pero a medida que crece el tráfico y la red se expande gradualmente el recurso de
consumo de cada enrutador también aumentará de manera rápida debido a su complejidad.
Por lo tanto, hará que los enrutadores se conviertan en un “cuello de botella” en rendimiento
por lo que reducirá la calidad del servicio de la red.

En consecuencia, no se garantiza Qos para última milla, ya que estos dos modelos no se
han desarrollado del todo en la Internet. Por esto se hace esta propuesta de Qos en redes
SDN a pequeña escala. Si bien los protocolos en a nivel Inter-AS no garantiza calidad de
servicio, como RIP, que su función es encontrar el mejor camino con el menor “peso” posible
en el menor número de saltos. Se propone protocolos o capas a nivel de red que, si lo
puedan garantizar, pero en las redes definidas por softwares (SDN). Se han realizado
estudios, tesis, proyectos sobre esta temática en los cuales encontramos a los
anteriormente mencionados HiQos [9]. El cual monitorea constantemente la red se
encuentra la ruta más óptima y dicha ruta se define como el camino con el menor uso de
ancho de banda para un nuevo flow. A su vez encontramos también DFS [5]. que realiza el
recorrido del grafo, guardando en una “pila” todos los recorridos existentes hasta el nodo
destino y utilizan el protocolo OSPF, para elegir el camino más corto. Además, encontramos
algoritmos más complejos, como OFMAQ Algorithm [11] el cual realiza una predicción de
ancho de banda y utilizan AIMD, el cual es un protocolo que define si se aumenta o
disminuye el ancho de banda dependiendo el BW necesario indicado por el switch en
cuestión. En caso que se congestione el enlace se utiliza el algoritmo NDSR [11] que re-
enruta los paquetes que no son de transmisión multimedia. También se han realizado
trabajos en operadores de nube (cloud) el cual garantiza calidad de servicio a los usuarios
5
de la nube usando Open vSwitch [8]. Además, encontramos trabajos que utilizan el Open
Flow para brindar calidad de servicio. El cual existen tres categorías en esta, tal como
desarrollo dinámico de Qos [12] [13], diversidad de Switch [14] e investigación sobre el
rendimiento de la red resultante de Qos con conmutadores habilitados para Open Flow [15].

6
VI.DESCRIPCIÓN

VI.I Requerimientos
Para llevar a cabo el presente proyecto es de suma importancia definir los requerimientos
necesarios para la realización de este. Primeramente, se emplea la red SDN en un entorno
virtualizado debido que no se contaba con switches SDN y/o controladores ya que el coste
de su implementación es elevado, además que el departamento no posee estos equipos,
por lo que se limitó a diseñar y realizar un prototipo de algoritmo de enrutamiento
multicamino UDIC en el emulador Mininet y Controlador Ryu.

VI.I.I Red SDN Virtualizada

La gran ventaja de implementar la red SDN en un entorno virtualizado es que se posee host
y equipos SDN que permiten su uso de manera ágil y eficaz. Se contempla la posibilidad
de utilizar máquinas físicas, pero aumenta los costes del proyecto ya que se necesita
interfaces físicas como enrutadores, conmutadores convencionales, entre otros. Antes de
entrar de lleno a los componentes de software que se utiliza en el proyecto, se procede a
explicar de manera concreta sobre la definición de una red SDN. Tal como se mencionó
anteriormente las redes SDN son una propuesta al enfoque arquitectónico de la
centralización de las redes con la finalidad de eliminar las limitaciones que presentan las
infraestructuras de las redes actuales [3]. Las redes tradicionales presentan protocolos que
se basan en tres planos: el de dato, control y administración. El plano de datos son todo el
tráfico que genera el usuario (host) hacia la red, pero para realizar dicho tráfico es necesario
tener un control de la cantidad de datagramas que se encuentran las redes. Por ello se
emplean ciertos protocolos para el enrutamiento (en diferentes niveles) para brindar una
correcta administración de los datos y pueda llegar a su destino. Existen ciertos mensajes
específicos para emplear estos protocolos los cuales son los mensajes de control que son
esenciales para la operación de la red. En cambio, la red SDN separar los dos planos bases
para la ejecución de los protocolos, lo cuales son los de datos y de control [2].

Figura 2. Separación de plano de datos y de control [4]

Una de las innovaciones clave de SDN es que el control debe estar separado del plano de
datos. El plano de datos consiste en reenviar los paquetes utilizando las tablas de reenvío
preparadas por el plano de control. La lógica de control está separada e implementada en
un controlador que prepara la tabla de reenvío. Los conmutadores implementan una lógica
de plano de datos (reenvío) que está muy simplificada. Esto reduce significativamente la
complejidad y el costo de los interruptores [2].

7
VI.I.I.I Protocolo OpenFlow

OpenFlow es un protocolo de comunicación en el Southbond API que permite la

comunicación entre los conmutadores OpenFlow y el controlador OpenFlow.

Figura 3. Interfaces de comunicación controlador y conmutador [20].

Tal como se observa en la figura 3 hay un canal OpenFlow de comunicación entre los
conmutadores y el controlador el cual se implementa haciendo uso de una conexión TLS
(Transport Layer Security) a través del protocolo TCP. Por este canal el controlador se
comunica con los conmutadores para la configuración de las tablas o grupos de tablas de
datos (flows), ya sea para bloqueo, acceso de estos o en su defecto reenvío de estos [20].

Cabe resaltar como es la dinámica de “conversación” entre el controlador y conmutador. No

todos los mensajes son enviados automáticamente o no todos son pedidos por el
controlador. Primero encontramos mensajes Asincrónicos los cuales son los mensajes
que el conmutador envía al controlador sin tener que haberlos solicitado el controlador. Este
tipo de mensajes informan al controlador sobre eventos que ocurren en la red o estados de
los puertos de estos, ya sea por alguna eventualidad de la red emulada. Ahora encontramos
los mensajes Sincrónicos que son los mensajes que determinan el tiempo de conexión
entre ellos. Y por último están los mensajes controlador-conmutador que son los
mensajes que permiten modificar, eliminar o instalar las tablas flows y programar
funcionalidades al switch [20]

VI.I.I.II Conmutador OpenFlow

Un conmutador OpenFlow cumple con la función de interconectar los equipos de una misma
red al igual que los conmutadores clásicos, la diferencia radica en que posee canales
OpenFlow que le permiten conectarse a un controlador externo que configura las rutas por
las que son enviados los flujos de datos. Este controlador inserta, edita o borra las tablas
de flujo y las tablas de grupo que posee el conmutador, las cuales contienen la información
de la ruta que debe seguir cada flujo de datos.[21]

8
 Figura 4. Esquema de componentes del Conmutador OpenFlow

VI.I.I.III Controlador OpenFlow

Para implementar el algoritmo UDIC se utiliza un software que permite acceder a los
recursos de red emulada e interactuar con las aplicaciones definidas o personalizadas. Tal
como se observa en la figura 2 el controlador se encarga del plano de control, el cual envía
mensajes OpenFlow a los conmutadores para obtener y/o realizar peticiones sobre los
recursos de la red. Este software permite realizar diversidad acciones hacia la red tales
como instalar, eliminar y configurar estados y acciones de los conmutadores referente al
flujo de datos. Básicamente el switch al recibir flujos de datos envía mensaje OpenFlow 1.X
al controlador para indicar qué acción debe de tomar y de acuerdo a la aplicación
configurada al tipo de controlador se realizará una acción en específico.

Existen diversos controladores que soportan el protocolo OpenFlow y de código abierto

(OpenSource) tales como POX, Ryu, OpenDayLight, entre otros. Para el proyecto se utiliza
el controlador Ryu debido a las características que posee: Rest API, Código Abierto y
virtualización, popularidad y documentación [19].

VI.I.I.IV Controlador Ryu

Ryu es un marco de red definido por software basado en componentes, [4], es decir, un
entorno de trabajo que proporciona componentes software que se utilizan en SDN, entre
ellos un controlador, con una API bien definida que facilita a los desarrolladores la creación
de nuevas aplicaciones de administración y control de red. Ryu es compatible con varios
protocolos para la gestión de dispositivos de red, como OpenFlow, Netconf, OF-config, etc.
Acerca de OpenFlow, Ryu admite totalmente las versiones 1.0, 1.2, 1.3, 1.4, 1.5 y Nicira.
Ryu ha sido escrito completamente en el lenguaje de programación Python y al ser un
proyecto opensource, todo su código está disponible gratuitamente bajo la licencia Apache
2.0. El controlador Ryu es el elegido para este trabajo y, mediante su Northbound API, se
creará una aplicación en forma de script en Python para balancear la carga de una red SDN
[5].

Para desarrollar aplicaciones en RYU se utiliza su API que permite programar aplicaciones
personalizadas teniendo en cuenta su funcionamiento. Este aplicativo es una entidad de un
solo subproceso que posee diversas funcionalidades. Al recibir mensajes OpenFlows del
9
conmutador este lo recibe como un evento y lo guarda en una cola. El procesamiento de
este último es FIFO (First In First Out) primer evento que entra, se procesa y luego se
termina. Ahora bien ¿Cómo se procesa este evento? Existe un manejador o controlador de
eventos que clasifica el evento en cuestión y define que tipo de evento es. Dependiendo
del evento que sea llamado en el aplicativo de RYU (aplicación desarrollada por definición
o personalizada) se ejecuta, es decir, el controlador puede recibir mucho eventos, pero
únicamente se observa en consola los eventos que son cargados por la aplicación. Al
finalizar de procesar dicho evento sigue el otro evento que se encuentre en la cola y así
sucesivamente. Más adelante se observará que la forma de cómo opera el aplicativo de
RYU es crucial para el desarrollo del algoritmo UDIC

VI.I.II Emulador Mininet

Debido a los altos costos de la implementación de una topología de red SDN física, se utiliza
el emulador Mininet como entorno de red virtualizada, ya que tiene la capacidad de emular
el comportamiento de los componentes que hacen parte de una red física como los son los
Switch, Host, enrutadores y los enlaces. Estos componentes pueden ser organizados de
acuerdo a las necesidades del proyecto, mediante un script de Python. De esta forma fue
creada la topología sobre la que se realizan las pruebas de nuestro algoritmo de
enrutamiento. Además, por medio de una terminal de cualquiera de sus host, Mininet
permite ejecutar sobre su interfaz cualquier programa que esté instalado en el equipo físico
y estos programas pueden enviar información a través de una interfaz de ethernet virtual
hasta los switch y enrutadores que son emulados por Mininet [1].

VI.I.III Topología de la red

Figura 5. Topología de Red.

Se procede a implementar la topología de red con cuatro conmutadores OpenFlow versión

1.3 y dos hosts. Se realiza esta topología debido que presenta dos posibles caminos para
llegar del host origen al host destino. Particularmente este tipo de topología presenta un

10
bucle, lo que en primera instancia presenta inconvenientes para la conectividad entre los
hosts, cuestión que más adelante se resolverá y ayudará para emplear el algoritmo UDIC.

VI.I.IV Enrutamiento Multicamino

Existen diversas técnicas para emplear este tipo de enrutamiento como lo son: el
descubrimiento de rutas, distribución de tráfico y mantenimiento de rutas. Para este
proyecto se utiliza la primera técnica, el cual es basada primordialmente en el enrutamiento
Dijkstra. Este básicamente consiste en determinar la ruta más corta de acuerdo a los costos
de los enlaces mapeando la red hasta determinar qué ruta posee el menor coste en
comparación con las otras [5]. Al hablar de enrutamiento es de crucial importancia la teoría
de grafo, ya que a nivel de desarrollo de aplicaciones de RYU es necesario tener
conocimiento sobre cómo funciona esta teoría ya que el enrutamiento multicamino depende
explícitamente de esta.

La teoría de grafo consiste básicamente en identificar el número de nodos o vértices que

se encuentra en la red y así mismo el número de aristas o enlaces en este. El grafo es una
función dependiente de dos variables m (nodos) y n (aristas). Estas dos variables son un
conjunto que tienen el número de nodos y número de aristas respectivamente. Al definir el
grafo de la topología se obtiene información sobre el número de nodos y cuales están
enlazados entre sí en base al conjunto de aristas que lo asocien.

VI.II Criterios de diseño

Paper Base Función

HiQos Dijkstra Monitorea constantemente la red. Se ejecuta el HiQos para la

ruta más óptima. Dicha ruta se define como el camino con el
menor uso de ancho de banda para un nuevo flow.[8]

DFS Dijkstra Realiza el recorrido del grafo, guardando en una “pila” todos
los recorridos existentes hasta el nodo destino. Utilizan el
protocolo OSPF, para elegir el camino más corto.[5]

OFMAQ Algorithm IP Multicast Algoritmo que realiza predicción de ancho de banda y utilizan
y NDSR (Multimedia) AIMD para definir si aumentar o disminuyen el BW
dependiendo del ancho de banda marcado por el switch SDN.
En caso de congestión re-enruta para descongestionar el
enlace.[9]

AMPS: Yen-K MLT utiliza un algoritmo de aprendizaje supervisado para

Application construir el clasificador de
awaremultipath árbol de decisión (DT) C4.5. Un conjunto de datos de
flow routingusing entrenamiento con 40
machine learning características se proporciona como entrada.
inSDN
Tabla 1. Algoritmos de enrutamientos

11
Se observa que de la tabla 1 se rescata varios algoritmos de enrutamiento multi camino del
estudio realizado sobre esta temática. Por el cual se toma uno de ellos para realizar el
contraste del algoritmo de enrutamiento UDIC con el elegido.

VI.II.I Algoritmo UDIC

Este algoritmo halla la ruta más óptima de la topología de la figura 4 donde el nodo inicial
corresponde al S1 que recibe el Flow del host1 y lo envía al host2, es decir, el nodo final es
S3. Tomaremos el camino S1-S3 como el camino (path) uno y tomaremos el path S1-S2-
S4-S3 como el dos. La funcionalidad de dicho algoritmo es que permite identificar los flujos
UDP e ICMP (no identifica los puertos de las aplicaciones). En base a los costes de los path
determina cual es la ruta más óptima para llegar a su destino. Para esta aplicación se están
priorizando los paquetes UDP, debido que el objetivo es brindar calidad de servicio a el
tráfico de VideoStreaming. Luego de esto el siguiente tráfico (ICMP) irá por la ruta con el
coste mayor al primero.

Figura 6. Diagrama de Bloques

Tal como se mencionó en la sección de RED SDN VIRTUALIZADA este tipo de red presenta
la Northbound y la Southbound, el cual el algoritmo se da en la Northbound, ya que se
agregan nuevos módulos de funcionamiento además de los definidos. Básicamente realiza
lo que indica el diagrama, se obtiene el grafo de la topología mediante los eventos
SwitchFeatures y EnterSwitch del controlador, incluyendo los pesos de los enlaces. Luego
Llama al módulo de enrutamiento y procede a instalar los flows respectivos a los switches
para realizar la comunicación entre los hosts.

12
VI.II.I.I Modular

El presente algoritmo posee varios bloques funcionales que son importados al main del
código, entre estos encontramos los siguientes.

❖ Módulo de identificación de número de enlaces de la topología.

❖ Módulo de ancho de banda entre dos enlaces.
❖ Módulo de obtención del grafo.
❖ Módulo de enrutamiento Dijkstra.
❖ Módulo de instalar Flows en los conmutadores.
❖ Módulo de identificar paquetes UDP e ICMP.

Alguno de estos módulos presentan escalabilidad, es decir que se puede aplicar para
cualquier topología ellos son: El módulo de identificar enlaces, módulo de obtención del
grafo y módulo de enrutamiento.

VI.II.I.II Medición de ancho de banda

Como se especifica en “”Introducción to mininet” [1] se recomienda utilizar bwm-ng para el

monitoreo de ancho de banda de cada uno de los puertos utilizados para transmitir
información en la red virtualizada. En base a esta herramienta de uso libre, se diseñó un
script en Python (getbw.py) que captura los datos que genera bwm-ng y los guarda en el
archivo bw.txt para luego enviarlos al algoritmo de enrutamiento que se encarga del análisis
de los datos y asignación de los pesos de cada enlace.

Figura 7. Resultados de getbw.py

En la figura 5. se puede apreciar los datos generados por getbw.py, el cual entrega el
número de bits enviados y recibidos desde cada puerto, por ejemplo, en la segunda línea
de la imagen 3, el nombre del elemento es s1-eth3, lo que significa que se está
monitoreando el puerto 3 del switch 1, y este análisis nos indica que este puerto envía en
ese instante 250611 bits y no está recibiendo ninguno.

Con respecto al delay, al igual que en las infraestructuras físicas, el monitoreo de este
parámetro es bastante complejo, por esto se tienen tablas que relacionan un valor de Delay
relacionado con el ancho de banda del enlace, elegimos el valor de 1000 us pues este es
el valor por default que cisco asigna a sus equipos para una conexión Ethernet [17]

VI.II.I.III Enrutamiento Multicamino

Para lograr que el algoritmo UDIC emplee un enrutamiento multicamino se utiliza los
módulos mencionados anteriormente. Primeramente, luego de obtener el grafo de la red, el
módulo de enrutamiento realiza el mapeo de la red según los datos obtenidos del grafo y
obtiene los posibles caminos que tiene. Luego de esto determina el camino más óptimo de
acuerdo al coste de los pesos de los enlaces, que está dado por esta ecuación:

13
 𝐵𝑊𝑟𝑒𝑓𝑒𝑟𝑒𝑛𝑐𝑒
𝐶𝑜𝑠𝑡(𝑙 ) = ; 𝐵𝑊(𝑙 ) = 𝑚í𝑛(𝐵𝑊𝑠𝑤𝑖𝑡𝑐ℎ1 , 𝐵𝑊𝑠𝑤𝑖𝑡𝑐ℎ2 )
𝐵𝑊(𝑙)
(3)

De acuerdo a la ecuación número uno se obtiene el coste por cada enlace presente en la
topología y luego determina el peso del path con la siguiente ecuación.

(4)

En base a la ecuación dos se determina el costo del camino donde n es el número de saltos
desde el nodo origen al nodo destino. Por lo que si se desea llegar al conmutador tres
existen dos posibles caminos.

Es importante mencionar que en base a la forma como opera el controlador RYU (explicado
en la sección anterior) el coste del camino es hallado al momento de iniciar la red, ya que
se conoce que tráfico UDP e ICMP son. Cada vez que se recibe un flow (el controlador
denota este evento como PacketIn) el presente algoritmo determina únicamente que tipo
de tráfico es y de acuerdo a eso halla el camino con mejor coste (el coste de los caminos
se mantiene constante). En la sección de resultado se explicará más en detalle los
parámetros y variables de los experimentos y los resultados obtenidos. Por último se
muestra el código de enrutamiento.

Figura 8. Algoritmo de camino más óptimo.

14
VI.II.I.IV Diseño de Grafo

Para obtener el grafo de cualquier topología se utiliza una estructuración de datos

Diccionario que permite asociar el ID de los conmutadores con el costo del enlace entre los
respectivos switches.

Figura 9. Algoritmo obtención de grafo.

El atributo self.grafo es el que contiene el diccionario padre con los cuatro keys que
representan los ID de los conmutadores. El atributo self.asti es la lista que posee los pares
de enlaces (1, 2) donde 1 es el ID del conmutador número 1 en base a la topología mostrada
y lo mismo es con el conmutador 2. Esto indica que el conmutador uno esta enlazado con
el conmutador dos. Y así sucesivamente sucede con el resto de los enlaces. Posteriormente
el módulo de enrutamiento recibe este grafo y presenta el camino con menor costo.

VI.II.I.V STP

Una trama capa 2 no posee un campo como el TTL (Time To Live) del protocolo IP que
disminuye en cada equipo de capa 3 por el que transita el paquete y cuando dicho campo
llega a cero, el paquete en cuestión es rechazado. Tal como se mencionó anteriormente,
nuestro proyecto presenta una topología de red en bucle por lo que la trama capa 2 puede
ser transmitida incontables veces, produciendo un loop que consume recursos de la red y
entorpece la transmisión de las demás tramas. Además, cuando se inicializa la red, los
conmutadores intentan llenar sus tablas MAC inundando de tramas ARP en broadcast toda
la red. Estas tramas ARP son replicadas por cada uno de los conmutadores y retransmitidas
por cada uno de sus puertos lo que satura la red e impide su correcto funcionamiento.[22]

15
 Figura 10. Existencia de un loop en topologías con estructuras de bucle [16]

Como una solución a esta problemática surge la función Spanning tree, que evita la
aparición de retransmisiones en una topología con un bucle en su estructura. Entre los
distintos tipos de Spanning tree que exiten ( STP, RSTP, PVST + y MSTP) en este proyecto
se implementó el STP (Spanning tree protocol)

El Spanning tree protocol (STP: IEEE 802.1D) configura los puertos de cada conmutador
asignando cuál de ellos puede transferir las tramas y cuáles no, de esta forma evita la
aparición de loops dentro de la estructura de bucle a causa del envío de broadcast,
transformando el bucle en una estructura de árbol.

En lugar de intentar llenar sus tablas MAC por si solos, cada conmutador con rol de puente
intercambia los paquetes de unidades de datos de protocolo de puente (BPDU) para
adquirir información y decidir que puertos tienen están habilitados para la transferencia de
paquetes, así como para definir el puente raíz. Luego de este intercambio inicial, el puente
raíz será quien transmita el mensaje BPDU con la asignación de los puertos y los otros
conmutadores se encargan de retransmitir las tramas BPDU provenientes de la raíz [16]

El papel de cada puerto se decide dependiendo de la distancia entre dicho puerto y el

conmutador puente raíz.

Root port: El puerto que tiene la menor distancia para llegar al conmutador puente raíz.
Este puerto recibe paquetes BPDU del conmutador puente raíz.

Designated ports: Estos son los puertos con una distancia considerable del conmutador
puente raíz y se encargan de retransmitir las tramas BPDU provenientes de la raíz.

Non designated ports: Es el puerto que no es ni puerto raíz, ni puerto designado, en estos
puertos se elimina el envío de tramas para evitar que se cree un loop, es decir estos puertos
sólo reciben data.

16
 Figura 11. Asignación de los roles por puerto.

Una vez que se decide la función del puerto (se completa el cálculo de STP), cada puerto
pasa al estado ESCUCHAR. Después de eso, el estado cambia como se muestra a
continuación y de acuerdo con la función de cada puerto, eventualmente se convierte en
estado ADELANTE o BLOQUEO. Los puertos configurados como puertos deshabilitados
en la configuración se convierten en estado DESACTIVADO y después de eso el cambio
de estado no tiene lugar.[16]

Figura 12. Estados de los puertos en distintas etapas del cálculo STP.

17
VII.PRUEBAS, RESULTADOS, ANÁLISIS DE RESULTADOS
Para mostrar los resultados del proyecto se llevan a cabo dos pruebas. La primera prueba
consiste en probar el algoritmo de enrutamiento DFS, el cual brinda los caminos posibles
en la red y muestra cual es el más optimo según el número de salto que deba realizar el
paquete desde el host de origen hasta el host destino. Por otra parte, se emplea el algoritmo
UDIC el cual se basa no en el número de saltos que tenga que realizar el paquete si no en
el menor coste del camino según el ancho de banda y retraso.

Cabe mencionar que se configuraron los siguientes parámetros para las pruebas.
❖ Dos host.
❖ Cuatro conmutadores ovsk- OpenFlow versión 1.3.
❖ Controlador remoto.
❖ Ancho de banda para camino 2 10M.
❖ Ancho de banda para camino 1 2M.
❖ Delay de 1ms, tomado referencia de Cisco.

Se recuerda que el camino 2 es s1-s2-s4-s3 y el camino 1 es s1-s3.

Prueba uno

Para esta prueba se utiliza el algoritmo DFS para determinar la ruta más óptima y muestra
lo siguiente.

Figura 13. Caminos disponibles y ruta óptima

De la figura trece se puede observar que realiza el enrutamiento en base al número de

saltos, ya que de acuerdo a la topología mostrada con anterioridad el conmutador 1 a 2 es
un solo salto y es lo que muestra en su costo de ese camino, en cambio para el otro camino
muestra que el coste es de tres, es decir tres saltos. Cabe mencionar que el conmutador
número dos en esta imagen corresponde al conmutador número tres de acuerdo a la
topología mostrada. Por lo tanto, el enrutamiento DFS no brinda múltiples camino para el
flujo de tráfico. Una vez hallada el camino más óptimo no varía a menos que se modifique
la topología agregando mas conmutadores o quitando respectivamente.

Prueba dos

Para esta prueba se utiliza el algoritmo UDIC para determinar la ruta más óptima de la red.

18
 Figura 14. Algoritmo UDIC ante tráfico UDP.

De a figura 14 se puede observar que el coste del segundo camino es de tres, debido que
el coste teniendo en cuenta el ancho de banda y Delay, obtuvo un valor de uno para cada
enlace en dicho camino. Ahora se procede a mostrar lo obtenido para el camino 1.

Figura 15. Tráfico ICMP.

De la figura 15 se observa que el camino para el tráfico ICMP es el uno con un coste de
cinco. Por lo que se muestra que el algoritmo UDIC no está en base a mejor esfuerzo, como
son las redes convencionales de hoy en día si no en base a las restricciones de ancho de
banda y delay, mencionados anteriormente. Mientras se esté generando tráfico UDP, el
camino que tomará es el dos y si simultáneamente se envía tráfico ICMP tomara el camino
uno. Esto es debido que este algoritmo prioriza el tráfico UDP (VideoStreaming) antes que
el tráfico ICMP, de acuerdo al camino con mayor ancho de banda disponible.

19
 Figura 16. Resultado de enrutamiento DFS y UDIC.

En base a los resultados obtenidos en las dos pruebas se observa que el algoritmo DFS
presenta menor Delay para llegar a su nodo destino, ya que en la prueba dos se mantuvo
constante un retraso de los paquetes debido que tomó más números de salto el paquete
comparado con la prueba uno. Sin embargo el algoritmo UDIC presentó mejor calidad en la
transmisión de video, con un delay constante en base al ancho de banda disponible en el
enlace para transmisión de video (tráfico UDP). En los resultados de la prueba uno no se
muestra el momento que se detiene el video por tener poco ancho de banda para
transmisión, por el cual se anexa un video con ambas pruebas para corroborar que aunque
se toma diferentes caminos la transmisión de video es mejor con el algoritmo UDIC ya que
esta en base a la restricción de ancho de banda. De alguna manera este enrutamiento
presenta calidad de servicio ya que los enrutamientos de hoy en dia RIP, BGP4 no
presentan priorización de paquetes o coste en base a ancho de banda, sino que únicamente
presenta un algoritmo en base al “mejor-esfuerzo” que garantiza conectividad y
accesibilidad pero no calidad de servicio.

20
VIII.CONCLUSIONES Y RECOMENDACIONES
Sin lugar a dudas la importancia de las redes SDN en el futuro de las telecomunicaciones es evidente,
la flexibilidad con la que se pueden reconfigurar las estructuras de la red nos ofrece un amplia gama
de posibilidades para la implementación de nuevas soluciones que garanticen al usuario final un
cierto grado de calidad y que por tanto promueva la evolución de muchos servicios. En este proyecto
se muestra un prototipo de algoritmo de enrutamiento UDIC que se basa en las restricciones de
ancho de banda y delay para presentar un enrutamiento multicamino priorizando los paquetes UDP,
para esto fue necesario un estudio a profundidad del funcionamiento de cada una de las
herramientas anteriormente descritas en este documento, así como el fortalecimiento de los
conceptos adquiridos durante las distintas materias cursadas en a lo largo del programa de
ingeniería electrónica y una búsqueda exhaustiva de documentación que nos permitió dar con las
soluciones presentadas. Con esto se presenta un algoritmo modular (escalable desde ciertos puntos)
que permite realizar enrutamiento, no en base a los costos tradicionales de las redes convencionales,
sino uno en base a las redes definidas por software, que replanteando ciertos protocolos, logra
brindar cierta calidad de servicio en la transmisión de video en una red con cuatro nodos a nivel de
enrutamiento. Por lo tanto se corrobora el objetivo de este proyecto, pues queda mucho material
por recorrer y emplear en este tipo de redes, tomando en base estas investigaciones, se pueden
formular muchos proyectos que apunten a ese fin último de garantizar siempre el bienestar del
consumidor del servicio.

IX.AGRADECIMIENTO

Queremos agradecer a todas las personas que se involucraron de alguna u otra manera para hacer
posible la culminación de este proyecto. También a la vida por darnos salud y capacidad de hacer
esta investigación realidad. Agradecemos a nuestras familia por darnos el apoyo y la oportunidad
de permitir estudiar en la Universidad del Norte para culminar este proyecto final de la carrera.

21
 Específicamente queremos dar gracias a Ivan mardini, Maria de Jesus ternera, Angélica Cueto, Luis
Solis y Daniela Polo por estar al pendiente de nuestro proyecto y ayudarnos cuando lo
necesitábamos. Sin ellos no hubiese sido posible la culminación de este proyecto.

También agradecemos a nuestro Tutor Jairo Cardona por su paciencia y dedicación para con
nosotros en las asesorías del proyecto, por guiarnos y ayudarnos para lograr los objetivos de este.
Nos respaldo y explico cuando era necesario ya que comenzamos con una temática a la que no
estábamos acostumbrados sin embargo estuvo allí para nosotros.

X.BIBLIOGRAFÍA
[1]GitHub. (2019). mininet/mininet. [online] Available at:
https://github.com/mininet/mininet/wiki/Introduction-to-Mininet [Accessed 18 Nov. 2019].
[2] Sdn.ieee.org. (2019). [online] Available at:
https://sdn.ieee.org/images/files/pdf/net_virt.pdf [Accessed 18 Nov. 2019].
[3]Ciena.com.mx. (2019). ¿Qué es SDN? - Ciena. [online] Available at:
https://www.ciena.com.mx/insights/what-is/What-is-SDN_es_LA.html [Accessed 18 Nov.
2019].
[4] rosa, A. (2019). Redes definidas por Software: el Administrador de Redes y la
Monitorización. [online] Pandora FMS - The Monitoring Blog. Available at:
https://pandorafms.com/blog/es/redes-definidas-por-software/ [Accessed 18 Nov. 2019].
[5]
M. B. García, «Estudio de técnica de Ingeniería de Tráfico,» Universidad de Cantabria,
Santander, 2018.
[6] Godsil, Chris and Royle, Gordon (2001). Algebraic Graph Theory. New York: Springer.
[7]Pdfs.semanticscholar.org. (2019). [online] Available at:
https://pdfs.semanticscholar.org/a503/452eeac9fb6b302e2d9af1a63361312da886.pdf
[Accessed 18 Nov. 2019].
[8] Jinyao, Y., Hailong, Z., Qianjun, S., Bo, L. and Xiao, G. (2019). HiQoS: An SDN-based
multipath QoS solution - IEEE Journals & Magazine. [online] Ieeexplore.ieee.org. Available
at: https://ieeexplore.ieee.org/document/7112035 [Accessed 26 Sep. 2019].
[9] Y.-M. H. S.-Y. K. P.-W. C. Tsung-Nan Lin, «OpenE2EQoS: Meter-based Method for End-
to-End,» 2016 IEEE 27th Annual International Symposium on Personal, Indoor, and Mobile
Radio Communications (PIMRC), pp. 1-6, 2016.
[10] S. T. V. Pasca, S. S. P. Kodali and K. Kataoka, "AMPS: Application aware multipath
flow routing using machine learning in SDN," 2017 Twenty-third National Conference on
Communications (NCC), Chennai, 2017, pp. 1-6.
doi: 10.1109/NCC.2017.8077095 URL:
http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=8077095&isnumber=8077030
[11] M. J. A. B. F. W. a. W. K. T. Zinner, «Dynamic application-aware resource management
using Software-Defined Networking: Implementation prospects and challenges,» 2014 IEEE
Network Operations and Management Symposium (NOMS), pp. 1-6, 2014.
[12]A. V. A. a. K. Xiong, «, "Quality of Service (Qos)-Guaranteed Network Resource
Allocation via Software Defined Networking (SDN),» 2014 IEEE 12th International
Conference on Dependable, Autonomic and Secure Computing, pp. 7-13, 2014.
[13]Y. E. M. B. Panagiotis Georgopoulos, «Towards Network-wide QoE Fairness Using,»
School of Computing and Communications, United Kingdom, 2013.

22
[14]A. V. A. I. a. P. B. V. Mann, «VMPatrol:Dynamic and automated QoS forvirtual machine
migrations,» 2012 8th international conference on networkand service management (cnsm)
and2012 workshop on systems virtualiztion management (svm), pp. 174-178, 2012.
[15]D. M. D. a. M. G. P. M. Mohan, «Performance study of TCP flows with QoS-supported
OpenFlow in data center networks,» 2013 19th IEEE International Conference on Networks
(ICON), pp. 1-6, 2013.

[16] Osrg.github.io. (2019). Spanning Tree — Ryubook 1.0 documentation. [online] Available
at: https://osrg.github.io/ryu-book/en/html/spanning_tree.html [Accessed 17 Nov. 2019].

[17] Learningnetwork.cisco.com. (2019). EIGRP Default Delay on outgoing Interfaces - 6116

- The Cisco Learning Network. [online] Available at:
https://learningnetwork.cisco.com/thread/6116 [Accessed 18 Nov. 2019].

[18] Hilmi E. Egilme, “Distributed QoS Architectures for Multimedia Streaming Over Software
Defined Networks” Student Member IEEE, 2014

[19] Osrg.hithub.io (2019). Ryu, RyuBook 1.0 documentation. [Online] Availale at:
https://osrg.github.io/ryu/ [Accessed 17 Nov. 2019]

[20] Open Network Fundation (2016), “OpenFlow” Version 1.0. [Online] Available at:
http://www.opennetworking.org/wp-content/uploads/2013/05/TR-
535_ONF_SDN_Evolution.pdf [Accessed 17 Nov. 2019]

[21] Opennetworking.org. (2019). OpenFlow Switch Specification. [online] Available at:

https://www.opennetworking.org/wp-content/uploads/2014/10/openflow-switch-v1.5.1.pdf
[Accessed 18 Nov. 2019].

[22] Enredando con redes ... (2019). Enredando con redes ...Tráfico broadcast. [online]
Available at: https://enredandoconredes.com/2012/06/20/trafico-broadcast/ [Accessed 18
Nov. 2019].

23