UNIVERSIDAD DISTRITAL FRANCISCO JOSE DE CALDAS FACULTAD DE...
Transcript of UNIVERSIDAD DISTRITAL FRANCISCO JOSE DE CALDAS FACULTAD DE...
-
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS
FACULTAD DE INGENIERÍA
INGENIERÍA ELECTRÓNICA
Evaluación de la calidad de servicio en redes móviles 5G implementandosegmentación de recursos basada en arquitectura SDN
Modalidad: Monograf́ıa
Autor: Kevin Sneider Ibarra Lancheros
Director: Dr. Gustavo Adolfo Puerto Leguizamón
Bogotá, Abril 2018
-
Dedicado ami familia.
III
-
Agradecimientos
En primer lugar a mis padres Alexandra e Iván quienes me inculcaron el valor de laresponsabilidad, mostrándome que con esfuerzo los objetivos se cumplen.
A mis hermanos, con quienes he compartido momentos muy felices.
Finalmente, a Gustavo Puerto por su tiempo y dedicación para elaborar este trabajo degrado, que me permite culminar un ciclo de estudios.
¡Muchas gracias a todos!
IV
-
Índice general
Agradecimientos IV
Índice de figuras VIII
Indice de tablas IX
Introducción 1
1 Planteamiento del problema 3
2 Justificación 4
3 Objetivos 53.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53.2 Espećıficos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4 Marco de Referencia 64.1 Redes definidas por software SDN . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1.1 Arquitectura de Red . . . . . . . . . . . . . . . . . . . . . . . . . . . 74.2 Segmentación de Hardware para redes 5G . . . . . . . . . . . . . . . . . . . 10
4.2.1 Segmentación de Hardware . . . . . . . . . . . . . . . . . . . . . . . . 114.3 Protocolo OpenFlow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144.4 Tablas de flujo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.5 Mininet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.6 Controlador Floodlight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.6.1 Módulos del controlador . . . . . . . . . . . . . . . . . . . . . . . . . 254.7 Calidad de Servicio (QoS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.7.1 Arquitectura básica . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.7.2 Niveles de servicio . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.7.3 Tipos de tráfico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.7.4 Mecanismos para garantizar calidad de servicio . . . . . . . . . . . . 294.7.5 Técnicas de encolamiento . . . . . . . . . . . . . . . . . . . . . . . . 29
4.8 Aplicación de la arquitectura SDN en la segmentación de hardware (Slicing)en redes 5G . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5 Estado del Arte 335.1 Redes Activas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335.2 Separación del plano de control y el plano de datos . . . . . . . . . . . . . . 345.3 OpenFlow y Sistema operativo de red . . . . . . . . . . . . . . . . . . . . . . 35
V
-
5.4 Actualidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6 Metodoloǵıa 376.1 Máquina Virtual Floodlight . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.1.1 Módulo de Calidad de Servicio . . . . . . . . . . . . . . . . . . . . . . 376.2 Generador de tráfico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436.3 Analizador de tráfico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446.4 Escenarios Planteados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
7 Resultados 507.1 Análisis de resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 787.2 Evaluación del Slicing para diferentes tipos de tráfico . . . . . . . . . . . . . 81
8 Conclusiones 85
Bibliograf́ıa 86
Anexos 89
-
Índice de figuras
4.1. Representación gráfica de la arquitectura SDN, provista por la ONF. . . . . 84.2. Virtualización de red superpuesta. . . . . . . . . . . . . . . . . . . . . . . . . 104.3. Representación de las caracteŕısticas de 5G Slicing . . . . . . . . . . . . . . . 124.4. Esquema conceptual de segmentación de hardware. . . . . . . . . . . . . . . 134.5. OpenFlow en la arquitectura SDN. . . . . . . . . . . . . . . . . . . . . . . . 144.6. Diagrama de flujo que detalla el flujo de paquetes a través de un Open vSwitch. 184.7. Información para hacer coincidencias OpenFlow 1.3 . . . . . . . . . . . . . . 194.8. Emulación de redes en Mininet . . . . . . . . . . . . . . . . . . . . . . . . . 214.9. Interfaz Gráfica para crear topoloǵıas en Mininet. . . . . . . . . . . . . . . . 234.10. Ubicación de Floodlight Controller en la arquitectura SDN. . . . . . . . . . . 244.11. Diagrama de la arquitectura de Floodlight. . . . . . . . . . . . . . . . . . . . 254.12. Encolamiento de prioridad. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.13. Redes SDN al servicio de la segmentación de recursos de red. . . . . . . . . . 31
5.1. Desarrollo de redes programables últimos 20 años . . . . . . . . . . . . . . . 34
6.1. Directorio que se crea al descargar el controlador que contiene el modulo QoS. 386.2. Directorio donde se encuentran los scripts que conforman el módulo de QoS. 396.3. Campos de una poĺıtica de QoS. . . . . . . . . . . . . . . . . . . . . . . . . . 426.4. Software jperf, en modo servidor. . . . . . . . . . . . . . . . . . . . . . . . . 436.5. Software jperf, en modo cliente. . . . . . . . . . . . . . . . . . . . . . . . . . 446.6. Analizador de tráfico Wireshark. . . . . . . . . . . . . . . . . . . . . . . . . . 456.7. Topoloǵıa en estrella de 1 switch y 4 hosts. . . . . . . . . . . . . . . . . . . . 466.8. Topoloǵıa 2 switches y 4 hosts. . . . . . . . . . . . . . . . . . . . . . . . . . 486.9. Topoloǵıas con múltiples saltos. . . . . . . . . . . . . . . . . . . . . . . . . . 49
7.1. Ancho de banda percibido por los hosts. . . . . . . . . . . . . . . . . . . . . 507.2. Ancho de banda para la topoloǵıa de 1 switch sin QoS. . . . . . . . . . . . . 517.3. Retardo en la topoloǵıa de 1 switch sin QoS. . . . . . . . . . . . . . . . . . . 527.4. Paquetes perdidos en la topoloǵıa de 1 switch sin QoS. . . . . . . . . . . . . 537.5. Ancho de banda para la topoloǵıa de 1 switch con QoS. . . . . . . . . . . . . 547.6. Retardo en la topoloǵıa de 1 switch con QoS. . . . . . . . . . . . . . . . . . 557.7. Paquetes perdidos en la topoloǵıa de 1 switch con QoS. . . . . . . . . . . . . 567.8. Cambio de ancho de banda de un flujo, capturado con jperf. . . . . . . . . . 577.9. Ancho de banda para la topoloǵıa de 2 switches sin QoS. . . . . . . . . . . . 587.10. Retardo en la topoloǵıa de 2 switches sin QoS. . . . . . . . . . . . . . . . . . 597.11. Paquetes perdidos en la topoloǵıa de 2 switches sin QoS. . . . . . . . . . . . 607.12. Ancho de banda para la topoloǵıa de 2 switches con QoS, canal limitado. . . 617.13. Retardo en la topoloǵıa de 2 switches con QoS, canal limitado. . . . . . . . . 62
VII
-
7.14. Paquetes perdidos en la topoloǵıa de 2 switches con QoS, canal limitado. . . 637.15. Ancho de banda para la topoloǵıa de 2 switches con QoS, excediendo el canal. 647.16. Retardo en la topoloǵıa de 2 switches con QoS, excediendo el canal. . . . . . 657.17. Paquetes perdidos en la topoloǵıa de 2 switches con QoS, excediendo el canal. 667.18. Ancho de banda para la topoloǵıa de 2 switches con QoS. . . . . . . . . . . . 677.19. Retardo en la topoloǵıa de 2 switches con QoS. . . . . . . . . . . . . . . . . 687.20. Paquetes perdidos en la topoloǵıa de 2 switches con QoS. . . . . . . . . . . . 697.21. Métricas para la topoloǵıa con 3 Switches sin QoS. . . . . . . . . . . . . . . 707.22. Resumen métricas para la topoloǵıa con 3 Switches sin QoS. . . . . . . . . . 717.23. Métricas para la topoloǵıa con 3 Switches con QoS. . . . . . . . . . . . . . . 727.24. Resumen métricas para la topoloǵıa con 3 Switches con QoS. . . . . . . . . . 737.25. Métricas para la topoloǵıa con 5 Switches sin QoS. . . . . . . . . . . . . . . 747.26. Resumen métricas para la topoloǵıa con 5 Switches sin QoS. . . . . . . . . . 757.27. Métricas para la topoloǵıa con 5 Switches con QoS. . . . . . . . . . . . . . . 767.28. Resumen métricas para la topoloǵıa con 5 Switches con QoS. . . . . . . . . . 777.29. Relación entre el porcentaje asignado y el ancho de banda. . . . . . . . . . . 787.30. Relación entre el porcentaje asignado y el retardo. . . . . . . . . . . . . . . . 797.31. Relación entre el porcentaje asignado y las pérdidas. . . . . . . . . . . . . . . 807.32. Topoloǵıa ejemplo para 5G Slicing. . . . . . . . . . . . . . . . . . . . . . . . 81
-
Índice de tablas
4.1. Acciones requeridas para el protocolo OpenFlow. . . . . . . . . . . . . . . . 174.2. Acciones opcionales para el protocolo OpenFlow. . . . . . . . . . . . . . . . 174.3. Tipos de mensaje del protocolo OpenFlow. . . . . . . . . . . . . . . . . . . . 19
7.1. Descripción de los flujos para el ejemplo de 5G Slicing. . . . . . . . . . . . . 827.2. Resultados sin calidad de servicio para 5G Slicing. . . . . . . . . . . . . . . . 837.3. Poĺıticas de calidad de servicio para el ejemplo de 5G Slicing. . . . . . . . . . 837.4. Resultados con calidad de servicio para 5G Slicing. . . . . . . . . . . . . . . 84
IX
-
Introducción
El elevado número de paquetes producido en las redes actuales, de ámbito empresarial,
doméstico y académico, entre otros, ha generado que la gestión de las mismas por el ad-
ministrador de red sea cada vez más dif́ıcil de llevar a cabo. Lo anterior a derivado en la
necesidad de reinventar el modelo de las redes, siendo este el momento de pensar en una
solución que permita al encargado realizar las tareas de gestión de una red, sin que sea nece-
sario el tratamiento individual de los dispositivos que participan en ella, es decir, centralizar
la administración de un red compleja, evitando la tediosa labor de verificar y validar uno
por uno los parámetros de direccionamiento y calidad de servicio (QoS), en cada uno de los
equipos que se están configurando, lo cual implica un avance significativo en la escalabilidad
en este tipo de sistemas.
Para cumplir con estos requerimientos se planteó el paradigma de redes definidas por
software (SDN, por sus siglas en inglés), el cual consiste en separar el plano de control (inteli-
gencia) y el plano de datos (información), dentro de cada uno de los dispositivos intermedios
de la red (p, ej. switches), con la finalidad de implementar entre ellos un controlador cen-
tralizado, es decir, común para un segmento de red y con ello facilitar el enrutamiento de
información de un extremo a otro, eliminando el uso que conocemos en dispositivos como
los routers [1]. De esta manera el controlador debe ser capaz de comunicarse tanto con el
plano de control (Aplicaciones) y con el plano de datos (Data). Para ello utiliza una serie
estándares definidos en los protocolos. Dentro de los primeros y más usados se encuentra
OpenFlow, que es un protocolo abierto que ofrece los parámetros que permiten la comunica-
ción del controlador con los nodos de las red (switches), conocido como Southbound y con los
dispositivos de nivel superior (Centros de gestión, Host de administración, etc) denominado
en la literatura cómo el Northbound.
De manera paralela en la industria de las comunicaciones se viene planteando una nueva
generación posterior a 4G (tecnoloǵıa recientemente implementada) que se ha denominado
5G (quinta generación), que consiste en un sistema de comunicaciones, principalmente móvi-
les, que ofrece la posibilidad real de dar sustento a las necesidades del mundo hiperconectado
hacia el cual se avanza. De tal forma que cada vez los requerimientos de las redes son mucho
1
-
mas exigentes y variados, dando como resultado perfiles o tipos de usuarios con necesida-
des bien definidas aunque diversas[2]. Es alĺı donde el concepto segmentación de recursos
hardware (o ”Slicing”, como es mencionado en la bibliograf́ıa) juega un papel sumamente
importante, pues permite el desarrollo del modelo ajustándose a una idea basada en la seg-
mentación virtual de los recursos que ofrece una infraestructura f́ısica.
De esta forma el modelo 5G con segmentación de recursos y el paradigma SDN convergen
y se complementan. Ya que las redes SDN ponen a disposición una arquitectura capaz de
hacer gestión de manera virtual de una infraestructura (compuesta por recursos y lógica),
proporcionando caracteŕısticas dinámicas a una red que no cambia en sus elementos f́ısicos
mas allá de la configuración. Por su parte 5G con segmentación de recursos ofrece un uso
comercial realmente poderoso para las redes SDN [3].
En este proyecto se busca mediante ejemplos y aplicaciones en el simulador de redes Mi-
ninet analizar capacidades de las SDN para cumplir con las necesidades de una red de quinta
generación (5G) aplicando el concepto de segmentación de recursos, planteando perfiles de
usuarios con necesidades especificas en cuando a parámetros como retardos, encolamientos,
paquetes perdidos y ancho de banda, que son las principales métricas usadas para definir
calidad de servicio en una red.
2
-
1 Planteamiento del problema
En el área de las redes de datos se ha generado un crecimiento constante en la cantidad de
dispositivos (cada vez en mayor proporción móviles)[4], que se conectan a través de medios
inalámbricos a redes empresariales, institucionales, e incluso a Internet; un ejemplo claro es
la implementación de sistemas como IoT 1, el cual posee requerimientos diversos y parti-
culares [5]. Consecuencia de ello, el tráfico de datos generado en una red actual es dif́ıcil
de administrar y gestionar [6]. Sin mencionar el alto impacto que implica la instalación de
nuevos equipos o la modificación en la topoloǵıa de la red usando el hardware instalado,
debido a las caracteŕısticas de la arquitectura actual. En consecuencia se requiere un modelo
en el cual con la infraestructura disponible el administrador tenga la posibilidad de gestionar
el rendimiento de diferentes segmentos de la red, para que un usuario de necesidades parti-
culares tenga la mejor experiencia con el servicio, en un momento y lugar espećıficos[2].
Como solución al escenario actual, se trabaja para desarrollar y mejorar el paradigma
de redes definidas por software (SDN por sus siglas en inglés)[6], el cual pretende mediante
el uso de aplicaciones y protocolos (como Openflow) adaptados a los dispositivos interme-
dios de la red (switches, módems, etc), virtualizar funciones de red en múltiples ambientes.
Para el presente trabajo solo se tiene en cuenta la aplicación de controladores sobre Open
vSwitches (Switches virtuales), dispositivos que son capaces por medio de ciertas reglas, de-
finidas por un controlador central, determinar rutas según el tipo de datos que utilizan los
usuarios de la red e incluso implementar mejoras en diferentes aspectos según la necesidad
de negocio sobre la cual se está trabajando, mediante la virtualización de las funciones de red.
En el presente proyecto se propone la emulación en el software Mininet de una red SDN
con un controlador Floodlight, basado en el protocolo Openflow, que toma decisiones de
acuerdo a perfiles de usuarios predeterminados por el administrador de red, sobre topoloǵıas
particulares. Con la intención de controlar recursos de ancho de banda que permitan ga-
rantizar valores de latencia y confiabilidad, según el tipo de servicio. Para ello se deben
determinar las caracteŕısticas de los usuarios tipo y una cantidad de perfiles adecuado para
el alcance del proyecto, sobre el escenario que sea seleccionado.
1Internet de las cosas, por sus siglas en inglés
3
-
2 Justificación
El aumento en el tráfico de información en las redes hace evidente que su administración
y gestión se ha tornado cada vez más compleja, sumado a la necesidad de tener un método
sencillo que permita modificar la distribución de los recursos de red sin alterar la infraestruc-
tura f́ısica implementada. Estas condiciones han conducido a proponer como solución a las
necesidades de 5G Slicing un modelo de red basado en el paradigma SDN, que dé solución a
este problema y le permita al administrador asignar los recursos de forma dinámica, lo cual
es fundamental para crear la segmentación virtual que se propone en 5G Slicing.
Por otra parte, el paradigma SDN es un modelo poco experimentado en Colombia, y por
supuesto mucho menos su aplicación en redes de 5G, tecnoloǵıa se espera sea implementada
hacia el año 2020 de forma comercial por las grandes empresas de telecomunicaciones a nivel
mundial [7], de este modo aunque no es la finalidad del proyecto producir un servicio que
ingrese directamente en el mercado, el proceso investigativo y técnico que se requiere para
desarrollar este proyecto aporta habilidades espećıficas en una de las áreas con mayor déficit
en el páıs, tanto de profesionales como de empresas nacionales[8].
Desde una perspectiva personal la motivación para realizar este proyecto se deriva del
deseo por conocer a fondo el comportamiento y gestión de las redes de datos con las cuales
la sociedad interactúa a diario, considerando la mayor cantidad posible de variables que
participan en el correcto funcionamiento de estos sistemas. Este proyecto permite realizar
un vistazo hacia el futuro de las redes y los novedosos sistemas que se pretenden implementar,
con los retos que esto conlleva.
4
-
3 Objetivos
3.1. General
Evaluar la calidad de servicio en redes móviles 5G implementando segmentación de
recursos hardware basada en arquitectura SDN.
3.2. Espećıficos
Reconocer la arquitectura y caracteŕısticas de los sistemas SDN y 5G aśı como las
propiedades derivadas de la segmentación de recursos hardware.
Determinar las caracteŕısticas de calidad de servicio para diferentes perfiles de usuario
en sistemas 5G.
Implementar un modelo de segmentación de recursos hardware usando SDN para di-
ferentes perfiles de usuario.
Validar la calidad del sistema 5G realizando pruebas de rendimiento y mediciones para
cada perfil de usuario.
5
-
4 Marco de Referencia
A continuación se puntualizan algunos conceptos alrededor de las redes definidas por
software (SDN) y las redes de quinta generación (5G), además de un breve repaso sobre
funciones de la estructura clásica de las redes que son primordiales para describir estos
paradigmas. Asimismo, se presenta una corta introducción al fundamento teórico acerca de
calidad de servicio (QoS) en redes de datos.
4.1. Redes definidas por software SDN
Las redes definidas por software son una arquitectura emergente que se compone de un
grupo de técnicas usadas para facilitar el diseño, desarrollo y operación de servicios de red de
una manera determinista, dinámica y escalable, separando el plano de control y el plano de
datos [1]. Siendo esta una definición tentativa propuesta por la IETF 1, indicando que no es
una descripción final para el paradigma que se encuentra en desarrollo, sino una presentación
general del tema.
Algunas caracteŕısticas de esta arquitectura son la adaptabilidad, la escalabilidad y el
bajo costo de implementación, cualidades que la hacen ideal para las aplicaciones actuales de
ancho de banda elevado. La separación del plano de control y el plano de datos, provee una
arquitectura programable que permite administrar la red, ya que las funciones de env́ıo y
recepción de datos están desacopladas de los procesos de administración quedando abstráıda
la infraestructura subyacente para las aplicaciones y los servicios de red.
Las SDN proponen una estructura de administración centralizada que posee una visión
general de la red, propiedad especialmente práctica en topoloǵıas complejas. Abstraer toda
la gestión de un segmento de red en pocos equipos permite configurar y administrar los
recursos de forma dinámica. Esta arquitectura es independiente de los protocolos, ya que las
decisiones dentro de la red son tomadas por controladores centralizados, generalmente de
código abierto.
1Grupo de trabajo de Ingenieŕıa de Internet, por sus siglas en inglés
6
-
Además de la abstracción de la red, la arquitectura SDN soporta una serie de API’s 2,
que hacen posible implementar servicios de red comunes, incluyendo enrutamiento, env́ıo de
tráfico multicast, seguridad y control de acceso, gestión del ancho de banda, ingenieŕıa de
tráfico, calidad de servicio, optimización de recursos f́ısicos, gestión de enerǵıa y en definitiva,
cualquier tipo de poĺıtica de gestión personalizada que sirva para conseguir los objetivos de
negocio, determinado por el tipo de controlador que se pretenda utilizar [9].
4.1.1. Arquitectura de Red
La arquitectura de los dispositivos intermedios en una red de datos convencional consta
de dos componentes lógicos principales: El plano de datos y el plano de control, a continuación
se describen este par de conceptos:
4.1.1.1. Plano de Datos
Es el tráfico de datos generado por los usuarios (multimedia, video, audio, archivos,
etc.) y demás encabezados agregados por las capas del modelo OSI que transitan por una
red determinada, en otras palabras es la “data en bruto”, que se transmite en una red.
La principal función del plano de datos es el env́ıo de paquetes espećıficamente sobre el
receptor. En las redes SDN el proceso que se lleva a cabo inicia con la identificación de las
reglas de env́ıo basados en direcciones IP o MAC, determinados por el controlador, el cual
debe coincidir con el próximo salto del paquete [10].
4.1.1.2. Plano de Control
Es el encargado de bosquejar la topoloǵıa de la red, de modo que cada dispositivo re-
conozca los caminos que debe recorrer un paquete con un destino determinado, es decir, la
“inteligencia de la red”. En las redes definidas por software (SDN), los switches o routers,
comparan con su tabla de flujos para determinar los caminos de los paquetes. Cuando un
mensaje no coincide con las reglas propias del dispositivo este se comunican con el contro-
lador central que almacena las rutas, las decisiones y los protocolos que debe cumplir cada
uno de los dispositivos intermedios.
2Interfaz de programación de aplicaciones
7
-
Figura 4.1: Representación gráfica de la arquitectura SDN, provista por la ONF.
Fuente: Open Network Foundation, Software-Defined Networking: The New Norm for Networks [figura 1].
En la figura 4.1 se presenta una visión lógica de la arquitectura de SDN. La inteligencia
de la red es centralizada en controladores SDN basados en software. Como resultado de es-
to, las empresas y los carriers ganan independencia y control sobre toda la infraestructura
de red desde un único punto lógico, simplificando el diseño y la operación. SDN también
simplifica los dispositivos de red, debido a que no tienen que procesar cientos de protocolos
estándares. Solo deben aceptar las instrucciones desde los controladores SDN [9].
Aplicaciones del negocio: Esto se refiere a las aplicaciones que son directamente
utilizables por los usuarios finales. Las posibilidades incluyen v́ıdeo conferencias, gestión
de la cadena de suministro y gestión de relaciones con clientes.
Red y Servicios de Seguridad: Esto se refiere a la funcionalidad que permite a las
aplicaciones del negocio rendir de forma eficiente y segura. Las posibilidades incluyen
una amplia gama de funcionalidades L4 – L7 incluyendo ADC, WOC y capacidades de
seguridad tales como firewall, IDS/IPS y protección DDoS.
SDN Switch puro: En un Switch SDN, si todas las funciones de control de un switch
tradicional (es decir, protocolos de enrutamiento que se utilizan para construir las
bases de datos de información de reenv́ıo) se ejecutan en el controlador central, la
funcionalidad en el switch se restringe exclusivamente al nivel de los datos.
8
-
Switch h́ıbrido: En un switch h́ıbrido, si las tecnoloǵıas SDN y los protocolos de
conmutación tradicionales funcionan simultáneamente, un responsable de red puede
configurar el controlador SDN para descubrir y controlar ciertas corrientes de tráfico
mientras que los protocolos de redes tradicionales y distribuidas continúan dirigiendo
el resto del tráfico en la red.
Northbound API: Relativa a la figura 4.1, northbound API es la API que permi-
te la comunicación entre la capa de control y la capa de aplicaciones empresariales.
Actualmente no hay una northbound API basada en estándares.
Southbound API: Relativa a la figura 4.1, southbound API es la API que permite
la comunicación entre la capa de control y la de infraestructura. Los protocolos que
pueden permitir estas comunicaciones incluyen OpenFlow, el protocolo de mensajeŕıa
y presencia extensible (XMPP) y el protocolo de configuración de red.
Seguramente, lo más importante es que los operadores y los administradores pueden
programar la configuración de esta red abstracta y simplificada en lugar de tener que poner
a mano cientos de ĺıneas de código en N cantidad de dispositivos de red. Adicionalmen-
te, aprovechando la inteligencia centralizada de los controladores SDN, es posible alterar el
comportamiento de la red en tiempo real y desplegar nuevas aplicaciones y servicios en solo
horas o d́ıas. Con la centralización de las capas de estado y control, SDN les brinda a los
administradores de red la flexibilidad para configurar, administrar y brindar seguridad a los
recursos a través la automatización dinámica v́ıa instrucciones al software de SDN [9].
La arquitectura describe una serie de funciones internas del controlador SDN. Los blo-
ques espećıficos que realizan estas funciones se ilustran para ayudar a la descripción, pero
no obligatorios para una implementación. Las interfaces a estos bloques funcionales internos
no están especificadas [11].
Hoy d́ıa la implementación de redes virtualizadas se realiza bajo un enfoque denominado
por las empresas de tecnoloǵıa como Virtualización de red basada en la infraestructura, en
la cual un controlador se comunica con los dispositivos intermedios utilizando un protocolo,
normalmente OpenFlow. La aplicación es en apariencia similar a la arquitectura mostrada
en la figura 4.1, en la cual el controlador se comunica con vSwitches o vRouters, dependiendo
si la red es de capa 2 o de capa 3 [11].
9
-
Figura 4.2: Virtualización de red superpuesta.
Fuente: CITRIX-SDN 101: Introducción a Software Defined Networking[imagen 3].
En la figura 4.2 se muestra un enfoque en el cual el controlador presenta una funciona-
lidad que le permite al dispositivo de entrada implementar una operación de asignación que
determina dónde debeŕıa ser enviado el paquete encapsulado para llegar a su máquina virtual
de destino. Con la superposición, el encabezado exterior incluye un campo que generalmente
es de 24 bits de longitud y estos 24 bits pueden utilizarse para identificar aproximadamente
16 millones redes virtuales. Sin embargo, los ĺımites prácticos están entre 16,000 y 32,000
redes virtuales [11].
4.2. Segmentación de Hardware para redes 5G
Las redes 5G o de quinta generación hacen referencia a la nueva era de las comuni-
caciones, principalmente móviles inalámbricas, para ambientes comerciales, empresariales,
académicos, etc. Se conciben las redes 5G como sistemas capaces de manipular el tráfico de
diversos tipos y fuentes, administrando los recursos limitados con los que se disponen. Sin
embargo, algunas de estas funciones estaban implementadas en generaciones anteriores, la
diferencia de las redes de quinta generación radica en la forma en que lo hacen, es alĺı donde
la aplicación de “Slicing.o segmentación de hardware se constituye como el pilar sobre el cual
se basa todo el desarrollo conceptual y técnico de esta novedosa propuesta, que se espera sea
10
-
insertada en el mercado en el año 2020 [2].
5G Slicing, como es conocida por la grandes empresas de tecnoloǵıa en el mundo, es una
propuesta con mucho potencial, debido a las caracteŕısticas de velocidad que presenta y que
son superiores a sus predecesoras. De esta forma se ofrecen aplicaciones de alto valor social
y económico, lo que lleva a una “sociedad hiperconectada” en la que los dispositivos móviles
tendrán un papel cada vez más importante en la vida de las personas [2].
La implementación real de esta tecnoloǵıa tiene como meta garantizar retardos menores
a 1 ms y anchos de banda mayores a 1 Gbps en enlaces extremo-extremo, para lo cual se debe
plantear un verdadero cambio generacional y no simplemente una mejora en las tecnoloǵıa
existentes. Esto sin duda propone un reto para los investigadores y empresarios del sector
de las telecomunicaciones, quienes ya se han visto en la necesidad continua de avanzar con
ese tipo de desarrollos. Por ejemplo, el cambio de generación de 2G a 3G fue motivado por
la necesidad de mejorar la experiencia de Internet de los usuarios de dispositivos móviles, ya
que los rangos de ancho de banda disponibles en aquel entonces representaban verdaderas
limitaciones. Algo similar sucedió cuando surgió el cambio desde 3G hacia 4G, ya que el
tráfico estaba constituido principalmente por “streaming”de video y audio, por ese motivo
la latencia de los enlaces en las redes 3G no era apropiado para que los usuarios finales
tuvieran la experiencia deseada [2].
4.2.1. Segmentación de Hardware
Debido a la diversidad y complejidad de los requerimientos de las redes móviles 5G, se
anticipa que la arquitectura actual no será suficiente por su naturaleza estática, ya que se
requiere de un sistema flexible y escalable capaz de ofrecer la disponibilidad requerida. La
introducción de nuevos servicios debe ser sencilla, sin que sea obligatorio modificar toda la
infraestructura instalada, teniendo en cuenta que 5G tiene casos de uso en ámbitos novedo-
sos como la conducción autónoma de veh́ıculos, en realidad virtual y aumentada, además de
otros ambientes ya explorados como las video llamadas grupales y la computación en la nube.
Teniendo en mente la naturaleza heterogénea del entorno en el cual se desenvuelven las
redes modernas, con diversidad de necesidades se propone un forma particular de gestionar
el tráfico producido por las diferentes fuentes, tal como se muestra en la figura 4.3. La
propuesta consiste en segmentar de forma lógica un enlace f́ısico con recursos limitados,
creando canales o “Slices” que permitirán diferenciar las necesidades de negocio de acuerdo
a niveles de servicio.
11
-
Figura 4.3: Representación de las caracteŕısticas de 5G Slicing
Fuente: Network slicing unleashes 5G opportunities, when service quality can be assured – Part 2.
El concepto de segmentación de Hardware o Slicing en una red 5G consta de 3 capas:
1. Capa de instancia de servicio
2. Capa de instancia de segmento de red
3. Capa de recurso.
La capa de instancia de servicio representa los servicios (de usuario final o empresariales)
que van a ser admitidos. Cada servicio está representado por una instancia de servicio. Nor-
malmente los servicios pueden ser proporcionados por el administrador de red o por terceros.
De acuerdo a esto, una instancia de servicio puede representar un servicio del administrador
o un servicio proporcionado por terceros.
Un administrador de red utiliza un plan de sectores para crear una instancia de segmen-
to, la cual proporciona las caracteŕısticas de los recursos de red que son requeridas por una
instancia de servicio. También se puede compartir una instancia de segmento de red a través
de múltiples instancias de servicio proporcionadas por el administrador.
La instancia de segmento de red puede estar compuesta por ninguna, una o más instan-
cias de sub-red, que pueden ser compartidas por otra instancia de segmento [12].
12
-
Figura 4.4: Esquema conceptual de segmentación de hardware.
Fuente: NGMN Alliance, Description of Network Slicing Concept [figura 1]
A continuación se presentan algunas definiciones técnicas que permiten entender de me-
jor forma la figura 4.4:
Instancia de servicio: es una instancia de un servicio para el usuario final o un servicio
empresarial que se realiza dentro o por una Red 5G.
Instancia de Segmento de red: un conjunto de funciones y recursos para ejecutar
estas funciones de red, formando una red lógica completa y configurada para cumplir con
ciertas caracteŕısticas requeridas por las instancias de servicio.
Plan de segmentación de red: una descripción completa de la estructura, la confi-
guración y los flujos de trabajo de cómo estructurar y controlar la instancia de segmento de
red durante su ciclo de vida. Un plan de segmentación permite la creación de instancias de
una Red 5G, que proporciona ciertas caracteŕısticas (por ejemplo, latencia ultrabaja, ultra
confiabilidad, servicios de valor agregado para empresas, etc.). Un plan de segmentación se
refiere a los recursos f́ısicos y lógicos necesarios.
13
-
Instancia de sub-red: se compone de un conjunto de funciones de red y los recursos
necesario para estas funciones (no es requerido para formar una red lógica completa) [12].
4.3. Protocolo OpenFlow
Es un protocolo de comunicaciones abierto en el cual el plano de datos y el plano de
control están separados. Fue diseñado particularmente para redes SDN, ya que permite mani-
pular las tablas de flujo de la capa de infraestructura a través de los controladores OpenFlow,
de modo que los dispositivos de red ejecutan las tareas del plano de datos, mientras que el
controlador se encarga de la inteligencia del plano de control dependiendo la aplicación de
negocio, cómo se muestra en la figura 4.5.
Figura 4.5: OpenFlow en la arquitectura SDN.
Fuente: Open Networking, Software-Defined Networking (SDN) Definition
14
-
Este estándar fue desarrollado hace varios años en la Universidad de Stanford después
de concluir que las redes se hab́ıan convertido en una infraestructura cŕıtica y la innovación
de la red en esa infraestructura se véıa cada vez más obstaculizada. Como solución se pro-
puso la idea de virtualización de la red, compuesta por una parte de producción y una parte
experimental. En ésta dirección se encamina el proyecto de OpenFlow [13], que aún está en
desarrollo.
El protocolo Openflow se fundamenta en tres pilares fundamentales;
1. Es programable para facilitar a los administradores la gestión de las redes
2. Presenta inteligencia centralizada que permite mejores rendimientos basados en
poĺıticas de gestión distribuidas y suministro simple
3. Se basa en abstracción que se evidencia en la separación del software y hardwa-
re que redunda en el desacoplo de plano de control y plano de datos, mencionado
anteriormente[14].
En un router o switch clásico la gestión del tráfico (plano de datos) y las decisiones de
enrutamiento de alto nivel (plano de control) se producen en el mismo dispositivo. Un Open
vSwitch o Switch OpenFlow separa estas dos funciones. Las tareas del plano de datos aún
reside en el switch, mientras que las decisiones de enrutamiento de alto nivel se mueven a un
controlador aislado, por lo general es un servidor estándar. El Open vSwitch y el controlador
se comunican a través del protocolo OpenFlow, que definen los mensajes, como paquetes
recibidos, enviados, modificar la tabla de flujo, y obtener estad́ısticas.
Dado que OpenFlow permite que la red sea programable basada en flujos, una arqui-
tectura SDN basada en este protocolo ofrece un control granular permitiendo que la red
responda a cambios en tiempo de real de las aplicaciones o usuarios.
El Open vSwitch presenta una abstracción de la tabla de flujo limpia; cada entrada de
esta tabla contiene un conjunto de campos de paquetes de acuerdo a la topoloǵıa, y una
acción acorde (como el puerto de salida de env́ıos, modificación de campo, o flujo de tráfico).
Cuando un switch OpenFlow recibe un paquete con caracteŕısticas que no ha visto nunca
antes, para el que no tiene entradas de flujo coincidente, lo encapsula y env́ıa al controlador.
Entonces, el controlador toma una decisión acerca del manejo de este paquete, es posible
que sea descartado ya que no existe una forma de transmitirlo o, por el contrario, añade una
entrada en la tabla de flujo de los switches que van a transportarlo, para que sean capaces
de dirigir adecuadamente el paquete y adicionalmente permitirá dirigir paquetes similares
15
-
en el futuro [15].
OpenFlow se añade como una caracteŕıstica de los switches Ethernet, router y puntos
de acceso inalámbricos comerciales; y proporciona un estándar para permitir a los investi-
gadores realizar experimentos, sin necesidad de vendedores que expongan el funcionamiento
interno de sus dispositivos de red. El protocolo actualmente está siendo implementado por
los principales proveedores de dispositivos de red, habilitándolo en los switches disponibles
en el mercado.
4.4. Tablas de flujo
La API de OpenFlow permite la inserción, modificación y eliminación de entradas de
flujo en el vSwitch. Estas entradas de flujo son similares a las listas de control de acceso
y consisten en una coincidencia y una acción correspondiente. Actualmente, la mayoŕıa de
los conmutadores y controladores implementan la versión 1.3 de la especificación OpenFlow.
En esta versión, los paquetes se emparejan según cualquier combinación de los siguientes
campos:
Puerto de ingreso
Dirección Ethernet origen/destino
Ethertype
VLAN ID
Prioridad de VLAN
Dirección IPv4 origen/destino
Protocolo IPv4
ToS en IPv4
Puerto TCP/UDP origen/destino
Estos parámetros admiten valores “comod́ın”para todos los campos, lo que significa que
cualquier valor de ese campo da como resultado una coincidencia. Si un paquete no con-
cuerda con ninguna de las entradas, el paquete se encapsula y se env́ıa al controlador. La
versión actual no tiene soporte para IPv6. Para cada coincidencia de flujo, puede tener o no
16
-
acciones asociadas a él. Si una coincidencia no tiene ninguna acción asociada, el paquete se
descarta. Puede producirse una coincidencia para varios paquetes si hay más de una acción
de reenv́ıo asociada con esa coincidencia. Es importante aclarar que en la lista anterior el
primer parámetro (Puerto de ingreso) hace referencia a la interfaz f́ısica por la cual el switch
recibió el paquete, mientras que el último ı́tem de los mencionados (Puerto TCP/UDP ori-
gen/destino), corresponde al puerto lógico que identifica la comunicación extremo-extremo
bien sea sobre el protocolo TCP o sobre UDP.
Una vez encuentre una coincidencia el Switch debe implementar acciones, algunas de
estas son obligatorias y son presentadas en la tabla 4.1, mientras que las presentadas en la
tabla 4.2 son acciones opcionales.
Tabla 4.1: Acciones requeridas para el protocolo OpenFlow.
Acciones requeridas DescripciónForward-Port Env́ıa el paquete por un puerto f́ısicoForward-All Env́ıa el paquete a todas la interfaces, excluye la interfaz de entradaForward-Controller Encapsula y env́ıa el paquete al controladorForward-Local Env́ıa el paquete a la pila de la red localFordward-Table Env́ıa el paquete de acuerdo a la acción de la tabla de flujoForward-In-Port Env́ıa el paquete por el puerto de entradaDrop Implementado como un flujo sin acciones
Fuente: ONF, OpenFlow Switch Specification
Tabla 4.2: Acciones opcionales para el protocolo OpenFlow.
Acciones opcionales DescripciónForward-Normal Procesa el paquete usando el camino tradicional de env́ıo del switchForward-Flood Inunda a lo largo del Spanning Tree, excluye la interfaz de entradaEnqueue Env́ıa a través de la cola asignada al puertoModify-VLAN ID Reemplaza o agrega el ID de la VLANModify-VLAN Priority Reemplaza el campo de prioridadStrip-VLAN Tag Muestra la etiqueta de la VLANModify-Ethernet Address Reemplaza la dirección Ethernet de origen/destinoModify-IPv4 address Reemplaza la dirección IPv4 de origen/destinoModify-ToS bits Reemplaza el campo de ToS de IPv4Modify-TDCP/UDP port Reemplaza el puerto TCP/UDP de origen/destino
Fuente: ONF, OpenFlow Switch Specification
En la figura 4.6 se muestra un diagrama de flujo detallado del proceso que ejecuta el
switch cada vez que recibe un paquete. En la figura se muestra una comparación con varias
17
-
tablas debido a que hay situaciones particulares en las cuales un mismo vSwitch tenga más
de una tabla de flujo.
Figura 4.6: Diagrama de flujo que detalla el flujo de paquetes a través de un Open vSwitch.
Fuente: ONF, OpenFlow Switch Specification
El protocolo OpenFlow se compone de tres tipos de mensaje:
Controlador a Switch (C): Este tipo de mensajes son iniciados por el controlador
y pueden o no requerir una respuesta desde el switch, utilizado para administrar o
inspeccionar directamente el estado del switch.
Aśıncrono (A): Este tipo de mensajes son iniciados por el switch y utilizados para
actualizar al controlador acerca de eventos y cambios en el estado del switch.
Simétrico (S):Estos mensajes son iniciados por el controlador o el switch, y enviados
sin solicitación, en cualquier dirección.
En la tabla 4.3 se hace una descripción de los mensajes que componen el protocolo OpenFlow
y la clasificación según el tipo.
18
-
Tabla 4.3: Tipos de mensaje del protocolo OpenFlow.
Mensaje Tipo DescripciónFeatures C Consulta las caracteŕısticas admitidas por el switch .Configuration C Consulta los parámetros de configuración.Modify-State C Agrega/Modifica/Elimina un flujo o propiedades de los puertos.Read.State C Recopila estad́ısticas.Send-Packet C Env́ıa de regreso paquetes al puerto del switch.
Barrier CEl switch env́ıa respuesta cuando ha finalizado todas lassolicitudes pendientes.
Packet-In ALos paquetes de datos son enviados del switch alcontrolador.
Flow-Removed A Flujo expirado.Port-Status A Transición encendido/apagado de un puerto.Error A Mensaje de error desde el switch hacia el controlador.Hello S Inicia la comunicación.
Echo SSolicitud/Respuesta de estado iniciada por el controlador o elswitch.
Vendor S Usado para funcionalidades futurasFuente: ONF, OpenFlow Switch Specification
Como se muestra en la figura 4.7.(a) los elementos que componen un flujo en OpenFlow
1.3, definen ciertos espacios que permiten buscar y ubicar coincidencias con el paquete (Match
Fields), donde se utilizan los campos del encabezado presentados en la figura 4.7.(b). Por
otra parte, la prioridad es una variable novedosa en OpenFlow 1.3, la cual permite asignar
privilegios a algunos flujos sobre otros, el otro parámetro relevante es el de instrucciones
en el cual se tomaran las acciones de acuerdo a las coincidencias que sean halladas para el
paquete.
(a) Componentes de un flujo en OpenFlow
(b) Encabezado del protocolo OpenFlow
Figura 4.7: Información para hacer coincidencias OpenFlow 1.3
Fuente: ONF, OpenFlow Switch Specification
19
-
4.5. Mininet
Mininet es un emulador que permite crear redes de máquinas virtuales, switches, contro-
ladores y enlaces, implementados en un dispositivo f́ısico que ejecuta el kernel estándar de
Linux. Tiene como cualidad adicional que sus switches soportan OpenFlow, caracteŕıstica
útil para simular enrutamiento personalizado altamente flexible y otros peculiaridades de las
redes definidas por software (SDN).
Mininet apoya la investigación, el desarrollo, el aprendizaje, la creación de prototipos,
pruebas, depuración, y cualesquiera otras tareas que podŕıan beneficiarse de tener una red
experimental completa en un ordenador portátil u otro PC [16], esta y otras caracteŕısticas
como las presentadas a continuación describen lo que es Mininet.
Proporciona un entorno de pruebas simple y económico para el desarrollo de aplicacio-
nes OpenFlow
Permite a múltiples desarrolladores trabajar de forma concurrente e independiente
sobre la misma topoloǵıa
Permite realizar pruebas en topoloǵıas complejas, sin la necesidad de cablear una red
f́ısica
Incluye una interfaz de ĺınea de comandos (CLI) que reconoce la topoloǵıa y al protocolo
OpenFlow, para la realización de pruebas y depuración del funcionamiento de toda la
red
Soporta topoloǵıas personalizadas, e incluye un conjunto básico de topoloǵıas listas
para usar sin necesidad de programación.
También proporciona una API de Python sencilla y extensible para la creación de redes
personalizadas y posible experimentación con estas (MiniEdit).
Mininet proporciona un método sencillo para determinar el comportamiento correcto
del sistema (y, en cierta medida compatible con el rendimiento en la implementación con
hardware real), del mismo modo para experimentar con topoloǵıas personalizadas.
20
-
Figura 4.8: Emulación de redes en Mininet
Fuente: ONF, Mininet (What is Mininet?).
Las redes en Mininet ejecutan un código real, incluyendo aplicaciones estándar de red
Unix/Linux, aśı como el kernel real de Linux y la pila de red (incluyendo cualquier exten-
sión de kernel que tenga disponible, siempre y cuando sean compatibles con el sistema, por
ejemplo Wireshark).
Debido a esto, el código desarrollado y probado en Mininet, para un controlador Open-
Flow, switch modificado, o dispositivo final, se puede trasladar a un sistema real con cambios
mı́nimos, para las pruebas, la evaluación de rendimiento y posterior implementación. Es im-
portante destacar que esto significa que un diseño que funciona en Mininet por lo general
puede pasar directamente a los switches reales [16].
El emulador Mininet también presenta ciertas limitaciones, dentro de las más destacadas
se encuentra que las redes implementadas no pueden superar el ancho de banda o capacidad
de procesamiento disponible en el servidor asignado. Otra limitación, aunque menor en la
practica es que Mininet no puede ejecutar aplicaciones que no sean compatibles con Linux
[16].
Este emulador ofrece tres caminos para ser instalado y ejecutado, el primero consiste en
instalar una imagen de una máquina virtual previamente configurada que se encuentra dis-
ponible para ser descargada de forma gratuita de la página oficial de Mininet (mininet.org),
21
-
su implementación es sencilla. Sin embargo, no es muy útil cuando se requiere conectar con
controladores remotos. Otra alternativa para la instalación de Mininet es hacerlo de forma
nativa sobre un sistema operativo Linux, sobre el cual se instalan todos los paquetes que
requiere el emulador. La tercera alternativa consiste en la instalación nativa de algunos de
los paquetes seleccionados.
Una vez instalado el emulador se puede abrir utilizando dos métodos, el primero median-
te la ĺınea de comandos (CLI) desde la cual se pueden ejecutar topoloǵıas predeterminadas
o desplegar topoloǵıas personalizadas descritas en el lenguaje de programación Python.
Desde la ĺınea de comandos se pueden crear topoloǵıas con un simple comando como el
que se muestra a continuación:
sudo mn − −switch ovs − −controller ref − −topo tree, depth = 2, fanout =3 −−test pingall
Este comando inicia con “sudo mn”, que indica se debe abrir la aplicación Mininet con
permisos de usuario privilegiado, el primer parámetro “−− switch ovs”, determina que losswitches serán Open vSwitches con todas las caracteŕısticas que estos dispositivos poseen,
el siguiente parámetro “− − controller ref”, determina que el controlador para esta redserá el OpenFlow de referencia que trae compilado por defecto el emulador, el parámetro
“− − topo tree” define que la topoloǵıa será tipo árbol, que determina su tamaño con lossub-parámetros “fanout = 3 ” y “depth = 2” se interpreta que tendrá 2 niveles de jerarqúıa
en la red, es decir, un switch central y switches conectados a este, que para el caso son 3,
además de 3 host conectados a cada uno de estos switches de jerarqúıa menor. Finalmente,
el parámetro “−− test pingall” inicia una prueba de conexión tipo ping desde cada uno delos host creados hacia los demás dispositivos finales.
La otra forma de crear topoloǵıas mediante la ĺınea de comandos es utilizando el compi-
lador de Python y un script que contenga la información de la red que se pretende simular,
con un comando cómo el siguiente:
sudo python ejemplo.py
Nota: En los anexos se encuentran diferentes códigos fuente que serviŕıan como ejemplo.
Otra alternativa para crear topoloǵıas es mediante la utilidad MiniEdit descrita en Pyt-
hon, que se encuentra en el directorio “˜/mininet/examples”. Esta es un interfaz gráfica
simple, como se muestra en la figura 4.9.
22
-
Figura 4.9: Interfaz Gráfica para crear topoloǵıas en Mininet.
Fuente: Propia.
En la figura se muestra una topoloǵıa que se compone de 4 switches conectados mediante
enlaces representados con ĺıneas continuas, y 9 hosts conectados a los vSwitches. Adicional-
mente, los switches se comunican con el controlador central, a través de enlaces representados
por medio de ĺıneas punteadas.
La topoloǵıa creada con los dos métodos descritos es la misma, no obstante, es evidente
que es mucho más intuitivo el proceso gráfico. Esta interfaz permite además, con una barra
de herramientas realmente sencilla crear múltiples topoloǵıas y configurar caracteŕısticas en
los hosts.
Como se mencionó anteriormente los host simulados se pueden concebir como máqui-
nas virtuales corriendo sobre el kernel de la maquina huésped. Esta cualidad permite que
los dispositivos se pueden administrar desde una interfaz Xterm y de esta forma ejecutar
comandos de la shell de Linux.
4.6. Controlador Floodlight
El controlador de código abierto para redes SDN Floodlight, está soportado por Java y
licenciado por Apache, además de un grupo significativo de colaboradores e ingenieros que
23
-
aportan activamente al Floodlight Project.
Floodlight trabaja de la mano con OpenFlow por lo tanto ofrece un punto de adminis-
tración central para las redes SDN, como se muestra en la figura 4.10, lo cual le permite
configurar remotamente switches con un set de instrucciones de enrutamiento, haciendo sen-
cilla la forma en la cual se modifica el comportamiento de la red. Como propiedad adicional
es compatible con una amplia gama de switches OpenFlow f́ısicos disponibles en el mercado,
lo cual simplifica enormemente la administración de la red.
Figura 4.10: Ubicación de Floodlight Controller en la arquitectura SDN.
Fuente: Sean Michael Kerner, Big Switch Shines Open Source Floodlight OpenFlow Controller on OpenStack.
Sin embargo, el controlador Floodlight no es únicamente un controlador de OpenFlow,
sino que alrededor de este se desarrollan un grupo de herramientas que facilitan el trabajo
de administrar y consultar la red [17], estas funcionalidades están distribuidas en piezas de
software independientes que se organizan conformando los módulos de Floodlight.
24
-
4.6.1. Módulos del controlador
Como se muestra en la figura 4.11 Floodlight adopta una arquitectura modular y por
ende son muchos los elementos que conforman el controlador en sus funcionalidades básicas
de red (REST API), la mayoŕıa de ellos desarrollados en el lenguaje de programación java.
Estos módulos requieren un “framework” capaz de orquestar las funciones de cada uno de
los procesos, este marco se denomina Java IFloodlightModule.
Figura 4.11: Diagrama de la arquitectura de Floodlight.
Fuente: Floodlight Controller Documentation, The Controller.
Los módulos del controlador implementan funciones de red que son de uso común para
la mayoŕıa de las aplicaciones, tales como:
El descubrimiento y la exposición de estados y eventos de red (topoloǵıa, dispositivos,
flujos)
25
-
La comunicación del controlador con los conmutadores de red (es decir, el protocolo
OpenFlow)
La administración de los módulos de Floodlight y recursos compartidos, como almace-
namiento, hilos y pruebas
Una interfaz de usuario web y un servidor de depuración (Jython)
Existe otro grupo de módulos y aplicaciones (Module Application y REST Aplication,
en la figura 4.11) que son descritos, en su mayoŕıa, en Python, los cuales son precisamente
los componentes que implementan soluciones para diferentes propósitos. Los módulos pueden
aprovechar la funcionalidad y las caracteŕısticas expuestas por otros módulos mediante el uso
del framework llamado IFloodlightServices. En seguida se presentan algunos de los módulos
de aplicación implementados en el controlador:
Fordwarding: aplicación de reenv́ıo de paquetes reactivos predeterminado de Flood-
light.
Static Flow Entry Pusher: una aplicación para instalar una entrada de flujo espećıfica
(coincidencia + acción) a un switch espećıfico. Habilitado por defecto.
Firewall: una aplicación para la gestión de reglas de ACL para permitir/denegar el
tráfico en función de una coincidencia espećıfica.
Port Down Reconciliation: una aplicación para conciliar flujos a través de una red
cuando un puerto o enlace se cae.
Learning Switch: un interruptor de aprendizaje L2 común. No habilitado por defecto.
Hub: una aplicación de concentrador que siempre inunda cualquier paquete entrante a
todos los demás puertos activos. No habilitado por defecto.
Virtual Network Filter: Una aplicación sencilla de aislamiento de la red basada en
MAC. No habilitado por defecto.
Load Balancer: un módulo simple de balanceador de carga para los flujos de Ping, TCP
y UDP. No habilitado por defecto.
Además de los ya mencionados, otros colaboradores del Floodlight Project han desarro-
llado propuestas de módulos que atienden necesidades particulares. Por ejemplo, existe un
modulo que permite implementar poĺıticas de calidad de servicio basado en encolamiento,
definiendo diferentes anchos de banda en cada uno de los puertos del Switch que lo soportan.
26
-
De acuerdo a las requerimientos que formule el administrador, el controlador asignará los
flujos a una u otra cola, lo cual permite diferenciar servicios. Este es uno de los puntos que
hicieron que Floodlight fuera escogido como el controlador con el que se trabajaŕıa en el
presente proyecto.
Asimismo la elección del controlador se basa en los resultados obtenidos y presentados en
un trabajo de grado previo, llamado “Análisis de las capacidades y prestaciones de calidad
de servicio en redes definidas por software”[18] (realizado en la Facultad de Ingenieŕıa de la
Universidad Distrital FJDC), donde Floodlight es comparado con diferentes controladores
SDN de código abierto y se concluye que; en un entorno de simulación es el controlador con
mejores prestaciones. En adición a esto la comunidad de desarrolladores que trabajan sobre
este controlador han proporcionado amplia documentación, lo que simplifica el trabajo en
múltiples aspectos.
4.7. Calidad de Servicio (QoS)
La calidad de servicio (QoS, por sus siglas en inglés), ha sido definida por la UIT3 como:
“La totalidad de las caracteŕısticas de un servicio de telecomunicaciones que determinan su
capacidad para satisfacer las necesidades expĺıcitas e impĺıcitas del usuario del servicio”[19],
donde las caracteŕısticas deben ser observables y/o mensurables. Por otra parte el IETF4
define la QoS en el RFC 2386 como: “Un conjunto de requisitos de servicio que debe cumplir
la red mientras se transporta un flujo”[20]. En resumen la calidad de servicio es un conjunto
de estrategias que implementa el administrador de red sobre los recursos del ambiente, pa-
ra garantizar que las expectativas de los usuarios de un determinado servicio se cumplan [21].
Una textbfclase de servicio representa un conjunto de tráfico que requiere caracteŕısticas
espećıficas de retardo, pérdida de paquetes y jitter en la red. Conceptualmente, una clase de
servicio se refiere a un grupo de aplicaciones con caracteŕısticas y requisitos de rendimiento
similares, por ejemplo, ”Datos de alto rendimiento”para aplicaciones como la web y el correo
electrónico, o una clase de servicio ”Telefońıa”para tráfico en tiempo real, como voz y otros
servicios de telefońıa. Dicha clase de servicio se puede definir de forma local en un dominio
de Servicios diferenciados (DS), o en múltiples dominios de DS, posiblemente extendiéndose
de extremo a extremo. Es necesario definir una estructura que sea capaz de cumplir con estos
requerimientos.
3Unión Internacional de Telecomunicaciones4Grupo de Trabajo de Ingenieŕıa de Internet, por sus siglas en inglés
27
-
4.7.1. Arquitectura básica
La arquitectura básica para garantizar calidad de servicio en un red establece tres ele-
mentos fundamentales:
Metodoloǵıa con la cual serán tratados los paquetes dentro de los dispositivos inter-
medios de la red (por ejemplo; encolamiento, programación y modelado de tráfico)
Técnicas para etiquetar los paquetes, de modo que todos los elementos de red
sean capaces de coordinar la comunicación de extremo a extremo.
Funciones de poĺıticas, administración y contabilidad de QoS para controlar y
administrar el tráfico de extremo a extremo a través de una red.
4.7.2. Niveles de servicio
Los niveles de servicio deben corresponder con las capacidades reales, es decir, la ca-
pacidad de la red para prestar el servicio necesario para un tráfico espećıfico de extremo a
extremo. Los servicios difieren en su nivel de “rigor en QoS”, que describe qué tan estricta
puede ser la limitación del servicio en caracteŕısticas como: ancho de banda, retardo, fluc-
tuación(jitter) y pérdidas[21].
A continuación, se presentan tres niveles básicos de calidad de servicio extremo a extremo,
que se disponen regularmente en una red heterogénea.
Servicio de mejor esfuerzo (Best Effort), en el cual todos los paquetes son tratados de
la misma forma, es decir, no hay calidad de servicio especificada.
Servicios diferenciados (DiffServ), o QoS suave, en el cual cierto tráfico se trata mejor
que el resto (manejo más rápido, más ancho de banda en promedio, menor pérdida
promedio). Esta es una preferencia estad́ıstica, no una garant́ıa dura y rápida.
Servicio garantizado, o QoS duro, reserva absoluta de recursos de red para tráfico
espećıfico.
4.7.3. Tipos de tráfico
El tráfico se puede describir en términos de las caracteŕısticas de diferentes objetos tales
como paquetes, ráfagas, flujos, sesiones y conexiones, dependiendo de la escala de tiempo de
las variaciones estad́ısticas relevantes[22]. En este contexto, es pertinente distinguir entre el
28
-
trafico elástico y el no elástico.
El tráfico elástico se puede ajustar a los cambios en el rendimiento de la red, sin dejar
de satisfacer las necesidades de las aplicaciones[23].
El tráfico no elástico no se adapta a las variaciones del rendimiento de la red, este tipo
de tráfico es el que es generado por las aplicaciones multimedia. La mayoŕıa del tráfico no
elástico exige un mı́nimo de rendimiento consistente, esto es dif́ıcil de cumplir en una red
congestionada[23].
4.7.4. Mecanismos para garantizar calidad de servicio
Son diversos los mecanismos existentes que se implementan para garantizar una adecuada
Calidad de Servicio[18](p. 18), los cuales se muestran a continuación:
Gestión de colas: por la naturaleza que tiene la transmisión de aplicaciones multimedia
a través de la red, propicia que la cantidad de tráfico no exceda la velocidad de la
conexión haciendo varias colas para los diferentes servicios.
Clasificación de paquetes: para manipular los tráficos y otorgarles QoS, se utilizan los
procedimientos básicos de clasificación y asignación de prioridad.
Medición y flujo de formación de tráfico: en muchas ocasiones es necesario limitar la
cantidad de tráfico de una aplicación a través de varias interfaces. Estas funcionali-
dades de control vienen determinadas por las herramientas de ĺımites de tasa y las
herramientas de formación.
Gestión de colas de altas velocidades: se basa en la manera que los protocolos operan,
con el fin de no llegar a la congestión de la red.
Metodoloǵıas de Estimación de Calidad de Servicio Percibida: es la calidad percibida
por el usuario independiente de la red transporte. Las medidas de calidad percibida
pueden realizarse usando métodos objetivos o subjetivos[18](p. 18).
4.7.5. Técnicas de encolamiento
En el contexto de las redes SDN, para el controlador Floodlight se plantea la posibilidad
de garantizar niveles de servicio usando una técnica basada en el encolamiento de paquetes
en los Open vSwitches por ese motivo se presentará a continuación una breve descripción de
la técnica de encolamiento que permite gestionar la información.
29
-
Encolamiento de prioridad (PQ)
Es una metodoloǵıa a través de la cual se ofrece un tratamiento preferencial a los pa-
quetes, que en el momento de ingresar a la interfaz, son identificados por prioridad. Cada
paquete se asigna a una de las colas disponibles, que son tratadas en estricto orden de prio-
ridad. Los paquetes se sirven de la cabecera de una cola, sólo, si todas las colas de prioridad
mayor están vaćıas. El encolamiento de prioridad se ajusta a condiciones donde existe tráfico
importante, pero puede causar la total falta de atención de colas de menor prioridad. Por
ejemplo, se pueden colocar prioridades a las aplicaciones de tiempo real, como voz y v́ıdeo
interactivo, y que se traten de forma prioritaria frente a otras aplicaciones que no operan en
tiempo real [18](p. 19).
Figura 4.12: Encolamiento de prioridad.
Ducuara, D y Porras, J.(2017). Análisis De Las Capacidades Y Prestaciones De Calidad De Servicio En Redes Definidas Por
Software [Figura 3].
4.8. Aplicación de la arquitectura SDN en la
segmentación de hardware (Slicing) en redes 5G
Una vez reconocidas las caracteŕısticas que definen la arquitectura de las redes definidas
por software (SDN) y el concepto de segmentación de hardware (Slicing) para redes 5G, es
posible describir los aspectos funcionales clave de la arquitectura SDN que se aplican para
la ejecución del concepto 5G[3].
La arquitectura SDN ofrece una infraestructura común para soportar de forma eficiente
múltiples instancias de clientes en la red (adaptadas y optimizadas para servicios con dife-
rentes y diversos requisitos). Sus conceptos claves (virtualización de recursos y recursividad)
30
-
Figura 4.13: Redes SDN al servicio de la segmentación de recursos de red.
Hakiriab,A ; Gokha, A; Berthouab, P; Schmidt, D y Gayraud, T. Software-Defined Networking: Challenges and research
opportunities for Future Internet[Figura 1].
soportan el alto grado de flexibilidad previsto para 5G Slicing. Las abstracciones comunes
permiten la presentación de todos los recursos relevantes (redes, procesamiento y almace-
namiento) incluidos en un segmento para cumplir un objetivo comercial, mientras que las
interfaces abiertas y programables permiten el control dinámico, la automatización de su
creación y operación, es decir, segmentación de hardware dinámico[3].
Aplicando la arquitectura SDN, un controlador en el contexto del cliente proporciona
el conjunto abstracto completo de recursos y la lógica de control de soporte para constituir
un segmento, incluida la colección completa de atributos de servicio de cliente relacionados.
Como tal, un segmento de 5G es comparable, si no el mismo que, un contexto de cliente SDN,
aislado por la virtualización del controlador y las funciones de poĺıtica de cliente y conti-
nuamente optimizado por la coordinación y las funciones de poĺıtica global del controlador[3].
En particular, la arquitectura SDN admite la posibilidad de que las caracteŕısticas de
31
-
los segmentos de red se predefinan en términos de los servicios y recursos abstractos necesa-
rios, con instancias de red creadas a petición en puntos finales y con recursos determinados
dinámicamente[3].
4.8.0.1. Métricas
Para determinar el rendimiento de una red de datos es necesario describir un grupo de
parámetros, que son los más usados para tal efecto, enseguida se introduce el concepto y se
entregan algunos detalles sobre el uso que se dará en el proyecto.
Retardo de transmisión o Transfer Delay hace referencia al tiempo que toma el paquete
en pasar por un componente de red (host, switch o segmento de red), es un parámetro
cŕıtico en las aplicaciones de 5G
Variación de retardo o Jitter es la variación en el tiempo de retardo en la llegada de
cada paquete
Paquetes perdidos o Loss Ratio es la tasa de perdida de paquetes, su valor se obtiene
de la relación entre el total de paquete perdidos y el total de paquetes transmitidos,
en un flujo de datos determinado.
Los valores que se asocien a cada uno de estos parámetros servirá para evaluar el rendi-
mientos de la red antes y después de aplicar poĺıticas de calidad de servicio y de esta forma
concluir acerca de las ventajas y desventajas de aplicar este tipo de reglas.
32
-
5 Estado del Arte
Las redes de computadores son complejas y dif́ıciles de administrar. Esas redes tienen
muchos tipos de equipos, desde routers y switches usados como dispositivos finales o como
firewalls, traductores de direcciones, balanceadores de carga en los servidores y detección
de intrusos en el sistema. Routers y switches manejan software complejo y t́ıpicamente es
cerrado y con licencia [24].
El camino que han debido llevar las redes definidas por software es cada vez buscar que
los procesos sean más programables habilitando la innovación en la administración y dismi-
nuye la barrera en el desarrollo de nuevos servicios. Como se muestra en [9] la historia se
divide en 3 etapas mostradas en la figura 1. Cada etapa tiene su aporte a la historia: 1) Redes
activas (desde mediados de los 90’s hasta el comienzo de 2000), alĺı se introdujo nuevas fun-
ciones programables para habilitar crecimiento en la innovación; 2) Separación del plano de
control y el plano de datos (desde 2001 hasta 2007), alĺı se desarrollaron interfaces abiertas
entre el plano de control y el plano de datos; y 3) El API de OpenFlow y sistema operativo
de red (desde 2007 hasta 2010), lo que representó el primer caso de adopción generalizada
de una interfaz abierta desarrollando formas de hacer la separación del plano de datos y el
plano de control escalable y práctico [24].
5.1. Redes Activas
Desde inicios de los 90’s se observó el crecimiento de Internet, con aplicaciones y atractivo
que superó ampliamente las primeras aplicaciones de transferencia de archivos y de correo
electrónico para cient́ıficos. Más diversas aplicaciones y un mayor uso por parte del público
en general, atrajo a los investigadores que estaban deseosos de probar e implementar nuevas
ideas para mejoras los servicios de red. Para ello, los investigadores han diseñado y probado
nuevos protocolos de red en entornos de laboratorio pequeños y el comportamiento simulado
en las redes más grandes. Entonces, la motivación y la financiación persistieron, alĺı tomaron
ideas del IETF (Grupo de trabajo de ingenieŕıa de Internet por sus siglas en inglés), para
estandarizar estos protocolos. El proceso de normatividad fue lento y finalmente muchos
33
-
Figura 5.1: Desarrollo de redes programables últimos 20 años
Feamster, N, Rexford, J y Zegura, E.(2014). The Road to SDN: An Intellectual History of Programmable Networks [Figura 1].
investigadores se frustraron [24]. La comunidad de redes activas persiguió dos modelos de
programación:
Modelo de cápsula: Donde el código para ejecutar en los nodos se realizó dentro de
paquetes de datos.
Modelo de programación de switches y routers: Donde el código para ejecutar en los
nodos se realizó fuera de los mecanismos de datos.
5.2. Separación del plano de control y el plano de datos
En la década de 2000, el aumento de los volúmenes de tráfico y un mayor énfasis en la fia-
bilidad de la red, la previsibilidad y el rendimiento llevado a los operadores de red en busca de
mejores enfoques para ciertas funciones de gestión de red, tales como el control sobre las ru-
tas utilizadas para entregar el tráfico (una práctica comúnmente conocida como la ingenieŕıa
de tráfico). Los medios para la realización de la ingenieŕıa de tráfico a través de protocolos de
enrutamiento convencionales eran primitivas en el mejor de los casos. Las frustraciones de los
operadores con estos planteamientos fueron reconocidas por una pequeña comunidad, bien
organizada de investigadores que trabajaban para cualquiera o interactuaban regularmente
34
-
con los operadores de red troncal. Estos investigadores exploraron los enfoques pragmáticos a
corto plazo aprovechando los estándares establecidos o inminente implementando protocolos
existentes [24]. Esas tendencias se catalizaron en dos innovaciones:
Una interface abierta entre el plano de control y el plano de datos
Una red de lógica centralizada
5.3. OpenFlow y Sistema operativo de red
A mediados de la década de 2000, los investigadores y los organismos de financiación
ganaron interés en la idea de la experimentación de red a escala, alentado por el éxito de las
infraestructuras experimentales, y la disponibilidad de fondos del gobierno independientes de
la instrumentación a gran escala, previamente reservada para otras disciplinas con el fin de
construir la costosa infraestructura, como colisionadores y telescopios. Una consecuencia de
este entusiasmo fue la creación del Entorno Mundial para Innovaciones de Redes (GENI) con
una Oficina de Proyectos GENI. Los cŕıticos de este enfoque en la infraestructura señalaron
que esta gran inversión en infraestructura no se corresponde a las ideas bien concebidas de
implementación. En medio de esto, un grupo de investigadores de Stanford creó el Programa
“Clean Slate” y se centró en la experimentación en una escala más local y manejables: redes
de campus [24].
5.4. Actualidad
En los últimos años en los desarrollos en redes definidas por software SDN han sido
de tipo académico principalmente, aunque empresas como Cisco y Dell ya ofrecen paquetes
que traen instalados controladores para redes, que le dan cierto grado de virtualización y
separación del plano de control en los switches ya implementados.
En la actualidad las universidades españolas de Cantabria, la universidad politécnica de
Valencia y universidad Autónoma de Madrid, han desarrollado trabajos de grado para el
fin de carrera en varios programas de ingenieŕıa. Por ejemplo la universidad de Cantabria
ubicada al norte de España se ha encargado de publicar trabajos como el ”Despliegue de
un maqueta de red basada en OpenFlow”[25], desarrollada por Carlos Arteche, en el cual se
realiza una simulación en el entorno Mininet y luego se lleva a equipos reales, otro trabajo
desarrollado en esta institución es ”Mecanismos de control de las comunicaciones en la in-
ternet del futuro a través de OpenFlow”[26], desarrollado por Sergio Rodŕıguez Santamaŕıa,
35
-
en la cual se usa OpenFlow para hacer una definición de lo que son las SDN y su poten-
cial impacto en las redes actuales, este par de trabajos, presentados fueron realizado con la
dirección de Ramón Agüero Calvo. En la universidad politécnica de Valencia se desarrollo
el proyecto Redes Definidas por Software (SDN): OpenFlow [27], por David Andrés Serrano
bajo la dirección de Juan Carlos Guerri, para optar por el grado en ingenieŕıa de tecnoloǵıas
y servicios de telecomunicación, en el trabajo de grado se realizan definiciones del paradigma
SDN y como se puede implementar usando OpenFlow realizando simulaciones en el software
Mininet, de un controlador POX, realizando funciones de un switch de capa 2 del modelo
OSI. Por otra parte en la universidad Autónoma de Madrid se desarrollo por parte de Maŕıa
Teresa Pegado el trabajo titulado ”Desarrollo de un sistema de monitorización para SDNs
(Software Defined Networks)”[28], bajo la tutoria de Francisco Javier Ramos, en el cual se
describe el desarrollo de un sistema de monitorización para SDN, que permita aplicar diver-
sas poĺıticas a las red, mediante reglas instalables en los switches a través de un controlador,
usando para ello el protocolo OpenFlow.
En latinoamérica, se ha desarrollado en la Universidad de Guadalajara un sistema de
optimización del tráfico interno de la Universidad, basada en IPv6 lo cual es presentado por
Jaime Olmos en la convención de LACNIC realizada en Bogotá en 2015[29], usando el proto-
colo OpenFlow y un interfaz desarrollada en Python, que permite a varias personas manejar
el sistema sin ningún tipo de inconveniente. En Colombia varias universidades han tenido
acercamiento, entre ellas está la Universidad Católica de Pereira en la cual no se realizó
ninguna experimentación sino una descripción del Estado del Arte de las redes definidas por
software[10], por Andrés Felipe Ruiz, con la dirección de Néstor Álzate. Por otro lado cómo
ya se mencionó anteriormente la Universidad Distrital viene trabajando en el desarrollo de
las bases teóricas de una ĺınea de investigación orientada hacia las redes SDN, ya que adi-
cional al trabajo mencionado y el presente se viene desarrollando paralelamente un proyecto
de implementación que recopile los resultados previos.
Un paso importante en el área también lo ha realizado la Pontificia Universidad Javeriana
en su sede Bogotá la cual ya ha adelantado varios trabajos de investigación e implementación,
dentro de los que se encuentran publicados está ”Diseño e implementación de una aplicación
de red bajo la arquitectura SDN”[30], la cual es un trabajo de nivel de maestŕıa. Con lo cual
se observa un futuro con investigación y desarrollo en un ambiente poco explorado por la
ingenieŕıa en el páıs.
36
-
6 Metodoloǵıa
En esta sección se describe la metodoloǵıa utilizada con la intención obtener resultados
cualitativos y cuantitativos acerca de la aplicación de la arquitectura SDN en redes 5G. Pre-
sentando la configuración de las herramientas necesarias para la realización de pruebas en
los escenarios planteados,
También se describe cada uno de los diferentes escenarios planteados, los cuales presentan
caracteŕısticas particulares por las que han sido seleccionados para ser parte del proyecto,
debido a que permiten analizar propiedades notables acerca de la aplicación de poĺıticas de
calidad de servicio en redes SDN. La creación de las topoloǵıas se realiza con ayuda de la
herramienta MiniEdit de Mininet, con la cual es sencillo bosquejar múltiples configuraciones
a partir de una interfaz gráfica. Posterior al proceso de diseño se obtiene un script en lenguaje
Python, que describe la creación y configuración de cada uno de los dispositivos de red, que
permite realizar las pruebas que se consideren convenientes con el simulador Mininet. En la
sección A de los anexos se encuentran dichos códigos fuente.
6.1. Máquina Virtual Floodlight
Para agilizar el proceso de instalación del simulador y del controlador, aśı cómo la asocia-
ción entre ellos, se descarga e instala una “imagen”pre-configurada de una maquina virtual
con la versión 14.04 de Ubuntu ofrecida en la pagina oficial de Floodlight, la cual contiene
todas las aplicaciones, complementos y demás herramientas necesarias para implementar to-
poloǵıas SDN sobre Mininet con Floodlight como controlador. Un pequeño tutorial sobre la
instalación de la máquina virtual es ofrecido en el siguiente enlace: Tutorial para instalación
de maquina virtual
6.1.1. Módulo de Calidad de Servicio
Como se ha mencionado anteriormente, el controlador Floodlight es un controlador de
código abierto que se soporta en el desarrollo de un grupo de ingenieros del consorcio Big
37
https://floodlight.atlassian.net/wiki/spaces/floodlightcontroller/pages/8650780/Floodlight+VMhttps://floodlight.atlassian.net/wiki/spaces/floodlightcontroller/pages/8650780/Floodlight+VM
-
Switch Network 1, integrado principalmente por investigadores norteamericanos, quienes han
documentado en la página oficial del controlador un modulo de Calidad de Servicio desa-
rrollado por Ryan Wallner del Marist Collegue de Nueva York [31], el cual se compone de
algunas rutinas configurables desarrolladas en Python. El módulo fue diseñado para trabajar
con OpenFlow 1.0, sin embargo, los creadores mencionan que han tenido pruebas exitosas
hasta la versión 1.3 del protocolo.
Esta pieza de software se puede descargar directamente del repositorio GitHub del crea-
dor, junto a la versión 0.90 de Floodlight. Finalizada la descarga se creará un directorio en
el “home”del usuario, con el nombre foodlight-qos-beta, como se muestra en la figura 6.1.
Figura 6.1: Directorio que se crea al descargar el controlador que contiene el modulo QoS.
Fuente propia.
Cabe recordar que se esta trabajando sobre una maquina virtual que ya teńıa instalado
un controlador Floodlight básico, por lo tanto a la hora de iniciar el controlador es impor-
tante verificar que corresponda al que ha sido descargado desde GitHub.
Dentro la ruta /home/floodlight/foodlight-qos-beta/apps/qos se encuentran los scripts
desarrollados por Wallner para el módulo de QoS.
Como se muestra en la figura 6.2, dentro de este directorio hay 8 archivos que conforman
el módulo, a continuación se realiza una breve descripción de la función que cumple cada
uno de ellos;
1Compañ́ıa de virtualización para SDN, que apoyó el desarrollo de OpenFlow
38
-
Figura 6.2: Directorio donde se encuentran los scripts que conforman el módulo de QoS.
Fuente propia.
circuitpusher.py: Es un código que se encarga de crear un circuito bidireccional,
mediante un flujo permanente instalado en todos los switches de la ruta entre dos
dispositivos, basado en la dirección IP. No fue desarrollado por Ryan Wallner
circuit.json: Es el archivo donde se almacena un resumen de los circuitos virtuales
establecidos, es creado y actualizado por el controlador Floodlight cuando se activa el
módulo QoS
mininet-add-queues.py: Es un código que, por defecto crea 3 colas en cada uno de
los puertos de cada Open vSwitch, es el elemento central sobre el cual se desarrolla
todo el módulo, son estas colas las que garantizan el ancho de banda asignado
mininet-add-queues.py.README: Describe el modo de uso del script mininet-
add-queues.py
qosmanager2.py: Este script es el encargado de organizar la información que confor-
ma la poĺıtica de la manera adecuada para que el controlador lo interprete, utiliza los
objetos tipo json para enviar de manera ordenada los elementos como direcciones IP,
prioridades, cola y puerto entre otros. Estos mismos campos serán usados para confor-
mar las tablas de flujo de los swtiches. Adicionalmente, permite activar o desactivar el
modulo QoS.
qosmanager2.pyc: Es una versión compilada del script qosmanager2.py, por este
motivo se ejecuta mas rápido.
qospath2.py: Es capaz de replicar la información de la poĺıticas en cada uno de
los switches que intervienen en un circuito lógico particular. Este archivo basa su
funcionamiento en el script qosmanager2.py.
39
-
qos-state.json: Es el archivo donde se almacena un resumen de las poĺıticas y servicios
de Calidad de Servicio que se han establecido, también es creado y actualizado por el
controlador Floodlight cuando se activan las funciones de QoS.
Los archivos mininet-add-queues.py, qosmanager2.py y qospath2.py, utilizan co-
mandos ovs-vsctl y ovs-ofctl, para configurar caracteŕısticas en los OVS y comunicarse con
el controlador. En los anexos se encuentran dichos scripts, que también pueden ser descar-
gados del siguiente enlace:Descarga del controlador Floodlight con Modulo de QoSl.
Ejecución del Módulo
En primer lugar es necesario iniciar el controlador, para ello con ayuda de la terminal nos
ubicamos en el directorio “/home/floodlight/floodlight-qos-beta” y desde alĺı se ejecutan los
dos comandos presentados enseguida, que se encargan de compilar e inicializar el controlador
respectivamente:
sudo ant
./floodlight.sh
A grandes rasgos se puede mencionar que ant es una aplicación que se encarga de com-
pilar y depurar software desarrollado en java. Por otro lado, el archivo floodlight.sh, es un
archivo que ejecuta comandos de la shell de Linux, las tareas espećıficas que realiza están
fuera del alcance de este proyecto.
El otro requisito antes de activar el módulo de calidad de servicio es asegurarnos que el
controlador reconozca la red sobre la cual se va a trabajar, para el caso particular el con-
trolador y red se ejecutan en el mismo dispositivo, lo cual simplifica el proceso. Se inicia la
simulación de la topoloǵıa en Mininet llevando a cabo alguna de las metodoloǵıas mostradas
en la presentación de la herramienta.
La ejecución del módulo se realiza mediante ĺınea de comandos, para ello nos ubicamos
en el directorio “/home/floodlight/foodlight-qos-beta/apps/qos”. Alĺı se encontrarán dispo-
nibles los 8 archivos mencionados.
Una vez cumplidas las condiciones lo primero que se debe hacer es definir las colas con
las cuales se trabajará, tal como se mencionó esta es la funcionalidad que ofrece el archi-
vo mininet-add-queues.py. Adicionalmente, el script crea una cola por defecto que es usada
40
https://github.com/wallnerryan/floodlight-qos-beta
-
cuando un paquete no presenta ninguna coincidencia dentro de los flujos definidos. Esta
utilidad se pone el marcha ejecutando el siguiente comando:
python ./mininet− add− queues.py
Nota: los valores de ancho de banda se pueden actualizar en cualquier momento (inclu-
so la cola por defecto), únicamente modificando los parámetros en el script y ejecutando de
nuevo el comando anterior.
Luego, se deben activar las caracteŕısticas de QoS en el controlador, para ello se utiliza
el script qosmanager2.py, con el parámetro “-e” (enable), ejecutando el comando:
./qosmanager2.py − e
Una vez activado el módulo de calidad de servicio, se pueden crear las poĺıticas para cada
uno de los enlaces extremo a extremo, para esto es necesario agregar algunos parámetros que
permitan diferenciar los flujos. Ejecutando el comando ./qospath2.py -h se obtiene una ayud