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