UNIVERSIDAD CENTRAL DEL ECUADOR FACULTAD DE … · Las redes de computadoras son de suma...

UNIVERSIDAD CENTRAL DEL ECUADOR

FACULTAD DE INGENIERÍA CIENCIAS FÍSICAS Y MATEMÁTICA

CARRERA DE INGENIERÍA INFORMÁTICA

DISEÑO Y SIMULACIÓN DE UNA RED DEFINIDA POR SOFTWARE (SDN)

TRABAJO DE GRADUACIÓN PREVIO A LA OBTENCIÓN DEL TÍTULO DE

INGENIERA INFORMÁTICA

AUTOR: NATALY ESTEFANÍA ESPAÑA TARAPUEZ

TUTOR: MGS. MAURO LEONARDO ROSAS LARA

QUITO – 19 DE MAYO

2016

ii

DEDICATORIA

A Dios por estar presente en mi vida,

A mis padres por ser mi apoyo y mi todo en cada etapa,

A mis hermanos que siempre fueron incondicionales,

y principalmente a mi hija Emily,

eres mi razón de ser.

iii

AGRADECIMIENTO

A mis ingenieros,

A mis amigos que nunca me dejaron sola

en los momentos más difíciles.

A mi tutor Ing. Mauro Rosas

por ser un guía y amigo

durante todo este proceso.

iv

AUTORIZACIÓN DE LA AUTORÍA INTELECTUAL

Yo, Nataly Estefanía España Tarapuéz, en calidad de autora del Trabajo de

Investigación: “Diseño y simulación de una red definida por software (SDN)”, autorizo

a la UNIVERSIDAD CENTRAL DEL ECUADOR, hacer uso de todos los contenidos

que me pertenecen o parte de los que contiene esta obra, con fines estrictamente

académicos o de investigación.

Los derechos que como autora me corresponden, con excepción de la presente

autorización, seguirán vigentes a mi favor, de conformidad con lo establecido en los

artículos 5, 6, 8, 19 y demás pertinentes de la Ley de Propiedad Intelectual y su

Reglamento.

Asimismo, autorizo a la Universidad Central del Ecuador para que realice la

digitalización y publicación de este trabajo de investigación en el repositorio virtual, de

conformidad a lo dispuesto en el Art. 144 de la Ley Orgánica de Educación Superior.

Quito, 19 de Mayo de 2016

Nataly Estefanía España Tarapuéz

CI: 1722417100

Telf: 0999985768

Email: [email protected]

v

CERTIFICACIÓN DEL TUTOR

Yo, Mauro Leonardo Rosas Lara en calidad de tutor del trabajo de titulación Diseño y

Simulación de una Red Definida por Software (SDN), elaborado por la estudiante

Nataly Estefanía España Tarapuéz de la Carrera de Ingeniería Informática, Facultad de

Ingeniería, Ciencias Físicas y Matemática de la Universidad Central del Ecuador,

considero que el mismo reúne los requisitos y méritos necesarios en el campo

metodológico y en el campo epistemológico, para ser sometido a la evaluación por parte

del jurado examinador que se designe, por lo que APRUEBO, a fin de que el trabajo

investigativo sea habilitado para continuar con el proceso de titulación determinado por

la Universidad Central del Ecuador.

En la ciudad de Quito, a los 19 días de mes mayo de 2016.

MGS. MAURO LEONARDO ROSAS LARA

CC: 171164296-5

viii

CONTENIDO

pág.

RESUMEN .................................................................................................................... xiv

ABSTRACT ................................................................................................................... xv

INTRODUCCIÓN ............................................................................................................ 1

1. ANTECEDENTES.................................................................................................... 2

1.1 Antecedentes del problema ...................................................................................... 2

1.2 Planteamiento, descripción y definición del problema.......................................... 2

1.3 Hipótesis .................................................................................................................... 3

1.4 Objetivos .................................................................................................................... 4

1.4.1 Objetivo general ................................................................................................ 4

1.4.2 Objetivos específicos ......................................................................................... 4

1.5 Alcance del proyecto ................................................................................................. 4

1.6 Delimitación del Proyecto ........................................................................................ 5

2. MARCO TEÓRICO ................................................................................................. 6

2.1 Definición y características generales de las SDN (Software Defined Networks)6

2.2 Arquitectura SDN ..................................................................................................... 6

2.3 Comparativa de la arquitectura de red tradicional vs arquitectura SDN .......... 7

2.4 Diferencias entre la red tradicional y SDN .......................................................... 10

2.5 Protocolo OpenFlow ............................................................................................... 11

2.6 Mensajes OpenFlow ............................................................................................... 12

2.6.1 Switch-controlador .......................................................................................... 12

2.6.2 Asíncrono ........................................................................................................ 13

2.6.3 Simétrico .......................................................................................................... 13

2.7 Herramienta de simulación Mininet ..................................................................... 14

2.8 Creación de topologías en Mininet ........................................................................ 14

2.8.1 Single (única) .................................................................................................. 14

ix

2.8.2 Linear (lineal) ................................................................................................. 15

2.8.3 Tree (árbol) ...................................................................................................... 16

2.8.4 Custom (personalizado) .................................................................................. 16

2.9 Controladores SDN................................................................................................. 17

2.9.1 OpenIRIS (Java) ............................................................................................. 17

2.9.2 Floodlight (Java) ............................................................................................. 18

2.9.3 POX (Phyton) .................................................................................................. 19

3. METODOLOGÍA EXPERIMENTAL ................................................................. 20

4. SIMULACIÓN DE LA RED DEFINIDA POR SOFTWARE ........................... 21

4.1 Entorno de simulación en software ....................................................................... 21

4.1.1 Selección y preparación del Software de simulación Mininet ...................... 21

4.1.2 Selección y preparación del controlador OpenIRIS ...................................... 25

4.2 Escenarios de simulación ....................................................................................... 27

4.3 Topología empleada en la simulación ................................................................... 29

4.4 Ejecución de los Controladores SDN .................................................................... 32

5. EVALUACIÓN DE LAS SDN............................................................................... 37

5.1 Tabulación de resultados en la simulación de la SDN ......................................... 37

5.2 Evaluación de Resultados en la simulación de la red definida por software

(SDN)........................................................................................................................ 39

6. DISCUSIÓN ............................................................................................................ 40

7. CONCLUSIONES .................................................................................................. 41

8. RECOMENDACIONES ........................................................................................ 42

BIBLIOGRAFÍA .......................................................................................................... 43

ANEXOS ....................................................................................................................... 47

ANEXO A ........................................................................................................................ 1

Instalación de los controladores .................................................................................... 1

ANEXO B ........................................................................................................................ 5

Conexión SSH hacia Mininet y los controladores ....................................................... 5

ANEXO C ........................................................................................................................ 7

Propiedades y ejecución de los controladores .............................................................. 7

ANEXO D ...................................................................................................................... 10

x

Código y ejecución de las topologías ........................................................................... 10

ANEXO E ...................................................................................................................... 14

Resultados de la ejecución de los controladores ........................................................ 14

xi

LISTA DE FIGURAS

pág.

Figura 1. Arquitectura SDN (Principia technologica, 2014) ...................................... 6

Figura 2. Comparativa de la arquitectura de una red tradicional y una SDN

(Seetharaman, 2011) ................................................................................................. 9

Figura 3. Red tradicional vs SDN (Savu & Stancu, 2014) ........................................ 10

Figura 4. Arquitectura de red de OpenFlow .............................................................. 11

Figura 5. Topología single ............................................................................................ 15

Figura 6. Topología linear............................................................................................ 15

Figura 7. Topología tree ............................................................................................... 16

Figura 8. Interfaz web del controlador OpenIRIS .................................................... 18

Figura 9. Interfaz web del controlador FloodLight................................................... 18

Figura 10. Configuración de Interfaz de un solo anfitrión ....................................... 23

Figura 11. Direcciones IP para las interfaces agregadas. ......................................... 24

Figura 12. Red básica Mininet .................................................................................... 24

Figura 13. Descarga del controlador OpenIRIS ........................................................ 26

Figura 14. Descomprimir OpenIRIS .......................................................................... 26

Figura 15. Carpeta IRIS del controlador instalada .................................................. 27

Figura 16. Escenario de simulación ............................................................................ 28

Figura 17. Conexión SSH hacia Mininet .................................................................... 29

Figura 18. Conexión SSH hacia el controlador .......................................................... 29

Figura 19. Topología personalizada usada en la simulación .................................... 30

Figura 20. Archivos de la topología para cada escenario ......................................... 30

Figura 21. Ejecución topología personalizada 1 ........................................................ 32

Figura 22. Archivo de propiedades del controlador OpenIRIS ............................... 32

Figura 23. Edición y configuración de las propiedades del controlador ................. 33

Figura 24. Ejecución del controlador OpenIRIS ....................................................... 33

Figura 25. Ejecución de los tres controladores al mismo tiempo ............................. 34

xii

Figura 26. Error de paquetes duplicados ................................................................... 34

Figura 27. Interfaz web de OpenIRIS en el Escenario 1 ........................................... 35

Figura 28. Topología empleada representada en la interfaz web ............................ 35

xiii

LISTA DE TABLAS

pág.

Tabla 1. Diferencias entre red tradicional y SDN ..................................................... 10

Tabla 2. Características de las versiones OpenFlow ................................................. 12

Tabla 3. Cuadro comparativo software de simulación de red .................................. 22

Tabla 4. Cuadro comparativo Controladores SDN ................................................... 26

Tabla 5. Direccionamiento IP para cada escenario y puertos para cada controlador

.................................................................................................................................. 28

Tabla 6. Puertos para la interfaz web de los controladores ..................................... 36

Tabla 7. Comparación de tiempos de respuesta máximos (Rendimiento 1) ........... 37

Tabla 8. Comparación de tiempos de respuesta (Latencia 1) ................................... 37

Tabla 9. Comparación de tiempos de respuesta máximos (Rendimiento 2) ........... 38

Tabla 10. Comparación de tiempos de respuesta (Latencia 2) ................................. 38

Tabla 11. Comparación de tiempos de respuesta máximos (Rendimiento 3) ......... 38

Tabla 12. Comparación de respuesta (latencia) en Escenario 3 ............................... 39

Tabla 13. Mejores tiempos promedios de Latencia ................................................... 39

Tabla 14. Máximos tiempos de respuesta de los controladores ................................ 39

xiv

RESUMEN

DISEÑO Y SIMULACIÓN DE REDES DEFINIDAS POR SOFTWARE (SDN),

MODALIDAD PROYECTO DE INVESTIGACIÓN

Autora: Nataly Estefanía España Tarapuéz

Tutor: Mauro Leonardo Rosas Lara

El presente proyecto tiene como propuesta investigar la arquitectura de Redes Definidas

por Software (SDN), los controladores y diseñar redes definidas por software usando

aplicaciones de controladores OpenFlow que se acoplen a cualquier red y permitan una

mayor flexibilidad. Se describen conceptos básicos, la arquitectura SDN, el protocolo

OpenFlow, configuración de la aplicación y análisis de los resultados obtenidos. Se

comparan diferentes controladores a nivel de rendimiento y latencia, así como el

lenguaje de programación que cada uno de ellos posee, la comparación se realiza a

través del envío de paquetes entre controlador y dispositivos de la red, analizando el

estado y funcionamiento de las aplicaciones realizadas. En este proyecto se diseña una

aplicación basada en el controlador OpenIRIS que usa el lenguaje de programación

Java, optimizando los recursos en la implementación de la red mediante la simulación

de ésta en Mininet.

PALABRAS CLAVES: / CONTROLADOR SDN/ MININET/ REDES DEFINIDAS

POR SOFTWARE/ OPENFLOW/ LATENCIA/ RENDIMIENTO DE LA RED/

xv

ABSTRACT

DESIGN AND SIMULATION SOFTWARE-DEFINED NETWORKING (SDN),

METHOD RESEARCH PROJECT

Author: Nataly Estefanía España Tarapuéz

Tutor: Mauro Leonardo Rosas Lara

This present project has as purpose to investigate the architecture of software-defined

networking (SDN), controllers and to design software-defined networking, using

applications OpenFlow controllers that fit any network and allow greater flexibility.

Basic concepts, SDN architecture, the OpenFlow protocol, application configuration

and analysis of the results obtained are described. Different controllers are compared at

the level of throughput and latency, as well as the programming language that each uses,

the comparison is done by sending packets between controller and network devices,

analyzing the status and operation of applications made. This projects is designed an

application based on OpenIRIS controller using the Java programming language,

ensuring resource optimization in the implementation of the network by simulating this

in Mininet.

KEYWORDS: / SDN CONTROLLER/ MININET/ SOFTWARE-DEFINED

NETWORKING/ OPENFLOW/ LATENCY/ NETWORK THROUGHPUT/

1

INTRODUCCIÓN

En los tiempos actuales la nueva tecnología se ha convertido en uno de los productos

fundamentales de consumo en la vida laboral, estudiantil, social, etc.

Las redes de computadoras son de suma importancia ya que son un conjunto de equipos

de comunicación conectados por medio de cables, señales, ondas o cualquier otro

método de transporte de datos, que comparten información, recursos, servicios, etc. que

permiten la comunicación de todas las personas desde distintos lugares.

El desarrollo de los dispositivos móviles, la virtualización de las redes, la aparición de la

nube y todos los servicios que ésta ofrece, son algunas de los avances que ha tenido la

tecnología impulsando al mejoramiento de las redes tradicionales (AZODOLMOLKY,

2013).

En el presente proyecto se busca investigar y evidenciar como las redes definidas por

software (SDN) aportan en la mejora del flujo de datos. Se compara un controlador

respecto de otros controladores en base a módulos similares programados por defecto,

los cuales permiten el flujo de paquetes en la red.

2

1. ANTECEDENTES

1.1 Antecedentes del problema

El modelo de red tradicional, sobre el cual se han desarrollado todos los servicios que

ésta ofrece y, además donde se basan los nuevos servicios digitales actualmente,

considera a la red como un conjunto de elementos independientes, relacionados entre sí

y que transfieren datos entre ellos (Principia technologica, 2014). El problema surge al

tratar de hablar de red como un todo, hay que entender que son elementos individuales,

con conexiones y diferentes características.

La arquitectura de red definida por software (SDN) ofrece la posibilidad de interactuar

directamente con la red como si fuera un todo, haciéndola más flexible ya que el flujo

de datos se ajusta dinámicamente a los cambios de la red, programable porque se

permite establecer reglas de flujo mediante la programación, administrable ya que se

tiene el control de la red centralizado y rentable puesto a que no se necesita estar atado a

un software propietario. (OPEN NETWORKING FOUNDATION, s.f.).

Desde hace algún tiempo se ha venido trabajando en el desarrollo de redes basadas en

software (SDN), algunos ejemplos que se pueden mencionar son: la Escuela Politécnica

Nacional (MORILLO, 2014), Universidad Politécnica de Catalunya-Barcelona

(GÓMEZ, 2015), Escuela Politécnica del Ejército (ALBAN & BRITO, 2015), y muchos

otros que han impulsado la tendencia hacia las SDN.

1.2 Planteamiento, descripción y definición del problema

Una red definida por software (SDN) es una tecnología que aborda la creación de redes

donde el control se desprende del hardware. La administración se enfoca en una

aplicación de software llamada controlador, donde se ejecutan una serie de reglas

programadas (Principia technologica, 2014).

3

La necesidad de permitir la transmisión de información de una forma ágil y contar con

elementos cuya infraestructura sea lo suficientemente idónea para la administración de

los datos de una forma eficiente sugiere la importancia de una solución SDN.

La importancia de este proyecto consiste en evaluar la flexibilidad de la red con un

sistema de control, donde se podrá cambiar el comportamiento de la red de manera

dinámica y automatizada, obteniendo una red adaptable. Además de aprovechar la

utilización de software libre. Este proyecto tendrá un alcance correlacional ya que se

compara los controladores OpenIRIS, POX y Floodlight en base al rendimiento y

latencia de los mismos.

En este proyecto se evalúa el rendimiento dependiendo del mínimo tiempo de respuesta

en la conexión del switch con el controlador, y la latencia dependiendo del menor

tiempo promedio que se puede evidenciar en las pruebas de conectividad realizadas

posteriormente (Capitulo 4).

1.3 Hipótesis

Es factible diseñar y simular una Red Definida por Software con un controlador SDN

que permita que los switches y los hosts realicen los procesos generados por dicho

controlador.

Para la formulación de la hipótesis se ha tomado las siguientes variables:

Variable independiente: Controlador SDN

Variables dependientes: Diseño y simulación de la Red.

4

1.4 Objetivos

1.4.1 Objetivo general

Diseñar y simular redes definidas por software (SDN) con un controlador SDN,

solución basada en hardware y software.

1.4.2 Objetivos específicos

Simular y programar los elementos de la Red mediante el entorno de simulación

Mininet.

Seleccionar el controlador dependiendo de la operatividad, funcionalidad y

facilidad de uso del mismo.

Controlar y gestionar de forma centralizada los dispositivos que comprenden

una topología de red en el diseño de la SDN.

Realizar la evaluación de la funcionalidad y flexibilidad de la SDN.

1.5 Alcance del proyecto

En el presente proyecto se realizará:

Investigación y descripción de la arquitectura de las SDN, protocolo

OpenFlow, software Mininet (Herramienta de simulación) y controlador SDN.

La instalación del programa Mininet, simulación del controlador SDN y análisis

de su funcionamiento.

La simulación de una topología de red y la evaluación de los controladores a

comparar dependiendo de las reglas preestablecidas en los módulos por defecto

de cada controlador.

Análisis de resultados en la simulación de la red.

5

1.6 Delimitación del Proyecto

Una de las principales limitaciones planteada en el proyecto es que se realiza la

simulación de una SDN en una máquina virtual porque se tienen tiempos que no son

reales y no se puede evidenciar datos que se obtendrían en una máquina física.

En el presente proyecto se realizó la comparación de los controladores OpenIRIS,

FloodLight y POX en base al rendimiento de cada controlador tomando en cuenta los

tiempos de respuesta cuando se establece la conexión entre los switches y el

controlador, adicional a esto se evaluó la latencia de la red con cada uno de los

controladores comparando el comportamiento de la misma con los tiempos de respuesta

mínimos en cada uno de los casos. La limitante en este proyecto es que se evaluó

solamente estos dos parámetros por lo que se puede realizar un análisis diferente

estableciendo nuevas medidas como es la seguridad, el rendimiento en cuanto a la red,

la creación de nuevos módulos para evaluar la dificultad de programación en cada

controlador, etc.

6

2. MARCO TEÓRICO

2.1 Definición y características generales de las SDN (Software Defined Networks)

Las Redes Definidas por Software o SDN comprenden una tecnología en la cual el

plano de datos se separa del plano de control y se emplean controladores basados en

software, los cuales son los responsables de gestionar el flujo de datos entre el

controlador y los conmutadores (switch). Los switch delegan su inteligencia al

controlador y pasan a ser simples unidades de conmutación de tráfico. El controlador

será quien estará abierto a la implementación de las nuevas funcionalidades o procesos.

En las SDN la manera estándar de emplearlas es con un solo controlador que administra

la actuación de los switch en una red. Así se percibe que toda la red es una sola unidad,

ya que el controlador precisa la conducta de la red como un todo (LÓPEZ, 2012).

2.2 Arquitectura SDN

La arquitectura SDN está compuesta por tres capas: Infraestructura, Control y

Aplicaciones, como se muestra en la Figura 1, las cuales interactúan mediante las

interfaces abiertas: Southbound “Hacia el sur” y Northbound “Hacia el norte”.

Figura 1. Arquitectura SDN (Principia technologica, 2014)

7

La capa de infraestructura hace relación a los dispositivos de red como por ejemplo

routers y switches, estos a su vez pueden ser físicos (hardware) y/o virtuales (software).

El Controlador es el software instalado en un servidor que admite controlar de una

forma lógica y centralizada a la red. Las aplicaciones en las SDN como por ejemplo:

Aplicaciones de voz, video, servicios de red. OpenFlow es el protocolo empleado para

comunicación entre el controlador (plano de control) y el switch (plano de datos).

Southbound o Interfaz hacia el sur: permite la comunicación entre el controlador SDN

y los dispositivos de Red en la capa de Infraestructura. El protocolo OpenFLow es el

elemento principal en esta interfaz para implementar las soluciones SDN.

Northbound o Interfaz hacia el norte: permite la comunicación del controlador hacia

las aplicaciones. La interfaz Northbound permite incluir funciones básicas de red, como

ruteo, manejo de tráfico y seguridad para la administración de servicios de red en la

nube.

La inteligencia de la red, en SDN, se encuentra (lógicamente) centralizada en

controladores basados en software, que mantienen una visión global de la misma.

2.3 Comparativa de la arquitectura de red tradicional vs arquitectura SDN

En la comparativa entre la arquitectura de red tradicional y la arquitectura SDN se

observan las posibles causantes que sugieren un cambio de tecnología en las redes, así

como la tendencia a las SDN.

En la arquitectura de red tradicional una aplicación corre en un servidor e intercambiaba

tráfico fundamentalmente con sus clientes. Pero hoy, las aplicaciones están distribuidas

a lo largo de múltiples máquinas virtuales, que intercambian tráfico unas con otras y que

pueden ser movidas de servidor físico para optimizar los servicios y balancear la carga

de los servidores. Mientras que cada aplicación sigue teniendo sus requerimientos de

red (Redclara).

8

Las redes tradicionales están descentralizadas en el control. La complejidad de las redes

de hoy en día hace que sea muy difícil aplicar un conjunto coherente de acceso,

seguridad, calidad de servicio y otras políticas a los usuarios cada vez más móviles, lo

que deja a la empresa vulnerable a violaciones de seguridad, incumplimiento de las

normas y otras consecuencias negativas.

En respuesta, la industria ha creado el Software Defined Networking (SDN), la

arquitectura y el desarrollo de normas asociadas (Principia technologica, 2014).

Las SDN permiten a los operadores de red configurar, administrar, proteger y optimizar

los recursos de manera flexible.

Los diseños y equipos utilizados tradicionalmente en las redes de telecomunicaciones,

aunque funcionan correctamente, no están alineados con los objetivos de negocio ni con

la lógica de las aplicaciones, sino que forman una estructura cerrada y estática que no se

puede adaptar en tiempo real a la demanda de las aplicaciones (GARCÍA CENTENO,

RODRÍGUEZ VERGEL, ANÍAS CALDERÓN, & CASMARTIÑO BONDARENKO,

2012) como se muestra en la Figura 2.

9

Figura 2. Comparativa de la arquitectura de una red tradicional y una SDN

(SEETHARAMAN, 2011)

10

2.4 Diferencias entre la red tradicional y SDN

De lo dicho anteriormente, en la Figura 3 se hace evidente de manera gráfica que el

control centralizado programable es el aspecto más importante de las SDN.

Posteriormente se puede identificar en la Tabla 1 las diferencias entre la red tradicional

y la SDN.

Figura 3. Red tradicional vs SDN (SAVU & STANCU, 2014)

Tabla 1. Diferencias entre red tradicional y SDN

RED TRADICIONAL SDN

Relativamente estática y difícil de aplicar

políticas Dinámica

No son flexibles Flexible

Incapaz de ser escalable Escalabilidad

Las tablas de flujo están cerradas en los

dispositivos Tablas de enrutamiento abiertas

Nuevas aplicaciones en mayor tiempo Nuevas aplicaciones en menor tiempo

Configuración descentralizada

(en cada dispositivo)

Configuración centralizada mediante

programación en el software controlador

Interfaces propietarias APIs bien definidas y abiertas

Automatización posible pero tediosa

Control central

Una interfaz (API) para todos los

dispositivos (Savu & Stancu, 2014)

Envió de paquetes basados en coincidencias

de la tabla

Formato y acciones de las tablas

claramente especificadas

Corta la investigación y desarrollo Facilidad de innovación

Altos costos operativos y financieros Reducción de costos operativos y

financieros

11

2.5 Protocolo OpenFlow

El protocolo OpenFlow es un protocolo estándar abierto definido por la Open

Networking Foundation (ONF) desde 2011, ofrece una comunicación entre las capas de

control e infraestructura comprendidas en la arquitectura de SDN.

OpenFlow está relacionado con la conexión remota entre el controlador SDN y los

switches como se muestra en la Figura 4, usando dispositivos como Ethernet, routers y

puntos de acceso inalámbrico donde se puede tener acceso a las tablas de flujo y a las

reglas, que muestran el direccionamiento del tráfico de paquetes.

Figura 4. Arquitectura de red de OpenFlow

Al centralizar el control de los dispositivos de capas de infraestructuras, OpenFlow

simplifica la administración de las redes y la capacidad de programación que promete

SDN (AZODOLMOLKY, 2013).

El protocolo OpenFlow se implementa en los dispositivos comprendidos en la

infraestructura de red y en el controlador SDN. Usa el concepto de flujos para

identificar el tráfico de red basado en reglas predefinidas que pueden ser programadas

estática o dinámicamente en el controlador, permitiendo a la red responder en tiempo

real a nivel de aplicación, usuario y sesión. OpenFlow presenta varias versiones con sus

respectivas características, las cuales se han resumido en la Tabla 2.

12

Tabla 2. Características de las versiones OpenFlow

2.6 Mensajes OpenFlow

Los mensajes OpenFlow son los que permiten transmitir acciones e información desde

el controlador hacia el o los dispositivos de red. Se dividen en: mensajes del controlador

al conmutador (switch), mensajes asincrónicos y mensajes simétricos

(AZODOLMOLKY, 2013).

2.6.1 Switch-controlador

Son iniciados por el controlador y se utilizan para administrar o gestionar el estado del

switch, puede o no requerir una respuesta del switch. Hay diferentes tipos de estos

mensajes:

Features (request/reply): Una vez establecida la sesión TLS (Seguridad en la

Capa de Transporte), el controlador envía un mensaje features request al switch. El

switch debe enviar un mensaje features reply en el cual especifica sus

características y capacidades.

* Diciembre, 2009* Febrero 28, 2011 * Diciembre, 2011 * Abril 25, 2013 * Agosto, 2013

* L1-L4 campo

coincidente* Múltiples tablas

* Extensión de

soporte Match* Múltiples tablas

* Propiedades de

puerto óptico

* Acciones: envia al

puerto, reescribe los

encabezados de

L2-L4, set/strip

etiqueta VLAN

* Multinivel y

etiquetado de MPLS

y VLAN

* Soporte básico

IPV6

* Expande el soporte

IPV6

* IANA puerto TCP

6653

* Máscaras de

subred* Puertos virtuales

* Paquetes de

mensajes

* Encriptación de

información

* Eventos de

monitoreo y estado

del controlador

* Tráfico en el puerto

de salida* Grupo de puertos

* Conexión a más de

1 controlador

* Estadísticas de los

flujos

* Módulo de fallo

difícil de implementar

* Módulo de fallo de

conexión incluido* Tunnel-ID meta data

Openflow 1.0 Openflow 1.1 Openflow 1.2 Openflow 1.3 Openflow 1.4

13

Configuration: El controlador es capaz de establecer una consulta de

configuración de parámetros en el switch. El switch responde a la consulta y envía

la información necesaria para el controlador.

Modify-State: su propósito es añadir, modificar o eliminar entradas en las tablas de

flujo y establecer las propiedades del switch.

Read-State: interroga al switch sobre estadísticas del tráfico (contadores de las

tablas de flujo).

Send-Packet: usado por el controlador para enviar paquetes a un puerto específico

del switch.

Barrier (request/reply): utilizado para asegurar que se cumplan las dependencias

de los mensajes o recibir notificaciones de operaciones completadas.

2.6.2 Asíncrono

Son iniciados por el switch cuando reciben un paquete y ha ocurrido un cambio en su

estado.

Packet-in: Se envía al controlador cuando un paquete no tiene una entrada de

flujo o si el paquete coincide con una entrada cuya acción sea la de enviarlo al

controlador.

Flow-Removed: se envía al controlador para informar que una entrada es

añadida a la tabla de flujos del switch.

Port-status: informa al controlador de un cambio en el estado de un puerto

determinado.

Error: informa al controlador de un error que ha ocurrido en un switch.

2.6.3 Simétrico

Se generan sin necesidad de una solicitud en cualquier dirección y se utilizan, por

ejemplo, para poner a prueba la dinámica de una conexión del switch de control.

14

Hello: son intercambiados entre el switch y el controlador al iniciarse la

conexión.

Echo (request/reply): es enviado por el switch o el controlador y se usa para

comprobar la comunicación entre ellos, además de ser usado para medir la

latencia o el ancho de banda o para verificar que un dispositivo esté activo.

Vendor: proveen una manera estándar para que los switches OpenFlow

ofrezcan funcionalidades adicionales. Está pensado para futuras revisiones de

OpenFlow.

2.7 Herramienta de simulación Mininet

Dentro de las diferentes herramientas de simulación como: Kiva, Packet Tracer, NS2,

OMNet++ y muchos otros compatibles con el estándar OpenFlow se encuentra Mininet.

Esta plataforma es escalable para la emulación de redes definidas por software mediante

el uso de virtualización permitiendo la creación e interacción de diferentes topologías de

red. Ejecuta un conjunto de hosts, switches, routers, links y controladores sobre un

simple kernel Linux (NADEAU & GRAY, 2013). Dado que es un proyecto Open

Source, está en constante evolución, permitiendo además que cualquier usuario pueda

modificar el código con total libertad.

MiniNet crea una red virtual realista, corriendo kernel real, el switch y el código de

aplicación, en una sola máquina (máquina virtual, nube o nativo), en segundos, con un

solo comando: $ sudo mn (MiniNet, 2014)

2.8 Creación de topologías en Mininet

2.8.1 Single (única)

Esta topología se crea mediante el siguiente comando:

$ sudo mn --topo single, n

15

En el cual, n es el número de hosts conectados a un único switch, como se visualiza en

la Figura 5.

Figura 5. Topología single

2.8.2 Linear (lineal)


$ sudo mn --topo linear, n

En el cual, n es el número de switches, y cada switch tiene un único host conectado a él.

En la Figura 6 se muestra esta topología.

Figura 6. Topología linear

16

2.8.3 Tree (árbol)


$ sudo mn --topo tree, depht=n, fanout =m

Implementa una topología de árbol, con profundidad de n niveles y m host conectados a

cada switch. En la Figura 7 se muestra de manera gráfica un ejemplo de esta topología.

Figura 7. Topología tree

2.8.4 Custom (personalizado)

Se pueden implementar topologías tan complejas como se desee, para esto se crea

topologías customizadas a través de un script en lenguaje phyton.

Para el presente proyecto se realizará una topología personalizada (custom) que se ha

detallado en el siguiente capítulo, puesto que se quiere dar un ejemplo de cómo se

realiza dicha topología, además de tener una topología que se adapte a nuestros intereses

y proponer modelos de red propios.

17

2.9 Controladores SDN

El controlador equivale al sistema operativo de la red que controla todas las

comunicaciones entre las aplicaciones y los dispositivos. El controlador SDN se encarga

de traducir las necesidades o requisitos de la capa de aplicación a los elementos de red,

y de proporcionar información relevante a las aplicaciones SDN, pudiendo incluir

estadísticas y eventos (SPERA, 2013).

Entre los controladores de código abierto tenemos: Beacon, POX, Floodlight, OpenIRIS

y muchos más, siendo la única diferencia entre ellos el lenguaje de programación

empleado para definir las reglas y políticas y la plataforma en la que trabajen, pues la

funcionalidad es la misma ya que todos pueden transmitir y recibir paquetes OpenFlow

para comunicarse con los dispositivos SDN. Se puede decir que los controladores son el

auténtico cerebro de las redes SDN y que los elementos o equipos de la capa física tan

solo aceptan órdenes de estos.

2.9.1 OpenIRIS (Java)

OpenIRIS es la versión libre de controlador OpenFlow IRIS, que presenta una interfaz

que es totalmente compatible con Floodlight. Además, proporciona alta escalabilidad a

nivel de operador y disponibilidad de un control centralizado.

Tiene las siguientes características principales:

1. Soporta varias versiones de OpenFlow (v1.0-v1.3)

2. Mejor rendimiento: maneja 2.5 veces más el flujo de datos.

3. Mejor modelo de programación: fácil de programar, más fácil de añadir API

REST para sus módulos y fácil de portar módulos existentes en Floodlight.

4. Soporta abstracción de red recursiva basado en OpenFlow.

18

Finalmente OpenIRIS ofrece un interfaz web donde se pueden visualizar los

componentes de la red, las conexiones y el resto de parámetros que la definen como se

muestra en la Figura 8.

Figura 8. Interfaz web del controlador OpenIRIS

2.9.2 Floodlight (Java)

Controlador SDN basado en OpenFlow, diseñado para trabajar con una gran cantidad de

switches, routers, máquinas virtuales y puntos de acceso. Utiliza el lenguaje de

programación Java para definir las reglas de control y tiene un sistema de módulos que

lo hace extensible, fácil de configurar y de alto rendimiento. Presenta una interfaz web

donde se puede visualizar la topología empleada y cada uno de sus elementos (switch,

hosts, conexiones) como se muestra en la Figura 9.

Figura 9. Interfaz web del controlador FloodLight

19

2.9.3 POX (Phyton)

Es un controlador que proporciona una plataforma para la creación de aplicaciones para

OpenFlow el cual ofrece una API escrita en C++ y Python. POX permite un rápido

desarrollo y creación de prototipos de software de control de red.

POX es el controlador más antiguo, por así decirlo, por lo que no presenta una interfaz

web.

20

3. METODOLOGÍA EXPERIMENTAL

La metodología a seguir es la cualitativa ya que se adopta el método de investigación.

Se pretende hacer una investigación descriptiva para explicar detalladamente el

concepto SDN, como está actualmente el protocolo OpenFlow, ya que ambos pueden

ser utilizados en cualquier tipo de conexión. Contando además con la utilización de

aplicaciones existentes y la distribución de canales de datos según la necesidad

planteada, tomando en cuenta la viabilidad desde el punto de vista tecnológico,

características y requerimientos para su implementación. Además de evaluar el

controlador OpenIRIS centrándonos en dos requerimientos principales: rendimiento y

latencia.

Por lo mencionado anteriormente se desea obtener una visión más clara de este

concepto ayudándonos de una revisión bibliográfica, mediante libros, investigaciones

anteriores, artículos, donde se deposita toda la información necesaria para el desarrollo

del proyecto.

En este proyecto se llevaron a cabo los siguientes procesos:

Recolección de la información basándose en documentación bibliográfica,

libros y documentación electrónica.

Presentamos la arquitectura SDN y el protocolo OpenFlow, se discuten

alternativas actuales basadas en protocolos y servicios, para identificar su

funcionamiento y tomar decisiones para su mejora.

Se describe el controlador escogido: características y funcionamiento.

Finalmente se realiza la simulación de la SDN y se valida el funcionamiento de

la misma y de sus componentes.

http://www.monografias.com/trabajos11/metods/metods.shtml

21

4. SIMULACIÓN DE LA RED DEFINIDA POR SOFTWARE

4.1 Entorno de simulación en software

Con el fin de simular las redes definidas por software se necesita de dos elementos

básicos, un simulador de redes y un controlador SDN. En este proyecto se ha decidido

utilizar el software de simulación Mininet y el controlador SDN OpenIRIS, los cuales

han sido escogidos por características como tipo de licencia, plataformas que soporta,

lenguaje de programación, uso investigativo, entre otras como se puede observar en las

Tablas 3 y 4.

Este proyecto ha sido desarrollado en un computador con sistema operativo OS X,

usando una máquina virtual que contiene Linux, y que a su vez tiene instalado Mininet,

la misma que se ha cargado usando VirtualBox.

4.1.1 Selección y preparación del Software de simulación Mininet

En la Tabla 3 se han detallado algunas de las características de los simuladores de red

como son tipo de licencia, plataformas que soporta, programación, uso investigativo,

instalación, etc., por lo cual se decidió escoger Mininet, ya que tiene un uso

investigativo alto y su instalación es fácil, pues existe la máquina virtual que puede ser

descargada fácilmente y de forma gratuita de la página oficial.

22

Tabla 3. Cuadro comparativo software de simulación de red

KIVA PACKET

TRACER NS2 OMNet++ MININET NCTUns

INTERFAZ GRÁFICA si si si (baja) si si si

INSTALACIÓN compleja media compleja compleja fácil compleja

TIPO DE LICENCIA Libre

* Libre

(miembros

CISCO)

* Comercial

Libre

* Libre

(propósitos

académicos)

* Comercial

Libre Libre

PLATAFORMAS * Windows

* Linux

* Windows

(98, ME,

2000 o XP)

* Mac

(versión 3.2

de Packet

Tracer no

soporta

Macintosh).

* Mac

* Unix

(Free BSD,

Linux,

SunOS,

Solaris)

* Windows

(desde W95

necesita MS

Visual C++

5.0 (ó >).

* Windows

* Unix y

Linux (algunas

versiones)

* Mac

* Windows

* Mac

* Linux

* Linux

(Red Hat,

Fedora core

3.0)

PROTOCOLOS Y

TECNOLOGÍAS

Bajo: IP,

tcp/IP

Alto: solo

Ethernet Alto Alto Alto

Alto: solo

Linux

LENGUAJE Java Desconocido C++ y OTcl NED (se basa

en C++) Phyton Desconocido

COMPATIBILIDAD no si no si si no existe

información

PROGRAMACIÓN alta media alta alta media alta

USO

INVESTIGATIVO medio

alto (pagando

licencia) alto alto alto alto

CARACTERÍSTICAS

GENERALES

Estudio de las

redes IP y

especialmente

el

seguimiento y

análisis del

funcionamien

to, el envío y

la recepción

de los

datagramas a

través de

TCP/IP

Entrenamient

o para

obtener la

certificación

de CCNA,

CCNP y

CCIE. Solo

simula con

equipos de

CISCO

Módulos

que cubren

un extenso

grupo de

aplicaciones

, protocolos

de ruteo,

transporte,

diferentes

tipos de

enlaces,

entre otros.

Simulación

de eventos

discretos,

modular y

orientado a

objetos.

Crea redes

virtuales a

gran escala

de forma

rapida y

eficiente.

(práctica

para el

estudio de

SNDs,

debido a

que permite

implementa

r nodos

con

protocolo

OpenFlow)

Simulador y

emulador de

redes y

sistemas de

telecomunic

aciones

avanzado

23

En primer lugar, se ha descargado la máquina virtual de Mininet de la página oficial

https://github.com/mininet/mininet/wiki/Mininet-VM-Images, la misma que se iniciará

utilizando el motor de máquinas virtuales VirtualBox y se procederá a realizar las

configuraciones correspondientes.

Se ha añadido en VirtualBox una interfaz de red del tipo “solo-anfitrión” como se puede

ver en la Figura 10, que nos sirve para establecer la conexión remota por ssh hacia la

máquina virtual.

Figura 10. Configuración de Interfaz de un solo anfitrión

Una interfaz de red viene ya añadida que se conectará a la red NAT y que sirve

netamente para la conexión a Internet. Una vez hechas las configuraciones de las

interfaces y que la máquina arranque se solicitará hacer login, tanto el nombre de

usuario como la contraseña son “mininet”.

Usuario: mininet

Contraseña: mininet

https://github.com/mininet/mininet/wiki/Mininet-VM-Images

24

Siempre que la máquina inicie se debe comprobar si las interfaces de red están

configuradas de manera correcta y que dispongan de una dirección IP como se muestra

en la Figura 11.

Figura 11. Direcciones IP para las interfaces agregadas.

En este momento la máquina es totalmente funcional, esto se comprueba creando una

red básica como se puede ver en la Figura 12 con el comando: $ sudo mn

Figura 12. Red básica Mininet

25

Cabe recalcar que si no se especifica el controlador, Mininet utiliza el controlador que

tiene incorporado por defecto. El parámetro que permite seleccionar un controlador

distinto es –controller, usando la siguiente sintaxis:

$ sudo mn --controller remote

La sintaxis general del parámetro --controller es:

--controller remote, ip=[controller IP], port=[controller port]

Algunos de los comandos que podemos ejecutar desde la consola de Mininet son:

mininet> net // muestra información sobre la red

mininet> h1 ping –c1 h2 // manda un ping desde el Host 1 (h1) al Host 2 (h2)

mininet> h1 ifconfig // muestra información sobre los interfaces de h1

mininet> exit // cierra la consola

Para que se pueda ejecutar comandos con permisos de root se debe teclear dichos

comandos anteponiendo sudo. Una vez que se cierre Mininet se recomienda limpiar la

topología de la red previa, ejecutando:

$ sudo mn –c

4.1.2 Selección y preparación del controlador OpenIRIS

Por los resultados obtenidos en la Tabla 4, se ha decidido utilizar el Controlador

OpenIRIS. Se han explorado otras opciones de controladores más usados como

Floodlight o Beacon, y pese a que OpenIRIS se encuentra en fase de pruebas, se ha

apostado por él, especialmente porque soporta todas las versiones OpenFlow y no ha

sido desarrollado por ninguna otra institución como se indicó en la Introducción.

26

Tabla 4. Cuadro comparativo Controladores SDN

(IMPORTANCIA - 1: baja, 2: media, 3: alta)

En la Figura 13, se muestra el comando para descargar OpenIRIS o también se lo puede

realizar ingresando a la página web oficial (https://github.com/openiris/IRIS).

Figura 13. Descarga del controlador OpenIRIS

Luego se descomprime el proyecto .zip, como se visualiza en la Figura 14 con el

comando $ unzip v2.2.1.zip

Figura 14. Descomprimir OpenIRIS

OpenIRIS CALF. FLOODLIGHT CALF. BEACON CALF. NOX CALF. POX CALF.

PROGRAMACIÓN Java 3 Java 3 Java 3 Phyton 2 Phyton 2

SOPORTE

PROTOCOLO OF

OpenFlow

V1.O –V1.33 OF V1.0 1 OF V1.0 1 OF V1.0 1 OF V1.0 1

HERRAMIENTAS

DE SIMULACIÓN

* MININET

* OVS2

* MININET

* OVS2

* MININET

* OVS2

* MININET

* OVS2

* MININET

* OVS2

PLATAFORMAS

(S.O.)

* Windows

* Linux

* OS X

2

* Windows

* Linux

* OS X

2

* Windows

* Linux

* OS X

* Android

para móviles

3 Linux 1

* Windows

* Linux

* OS X

2

TIPO DE

SOFTWARE

Código

Abierto3 Código Abierto 3

Código

Abierto3

Código

Abierto3

Código

Abierto3

ESTUDIADO EN Ninguna 3

* Politécnica

Nacional

* Universidad de

Ambato

2Universidad

de Ambato1

Politécnica

Nacional1 ESPE 1

FUNCIONALIDAD

DE LA REDNivel alto 3 Nivel medio 2 Nivel bajo 1 Nivel bajo 1 Nivel bajo 1

TIEMPO DE

LANZAMIENTO2 años 2 2 años 2 4 años 3 6 años 3 1 año 1

DOCUMENTACIÓN Media 2 Alta 3 Alta 3 Alta 3 Media 2

TOTALES 23 20 20 17 15

https://github.com/openiris/IRIS)

27

Una vez que se ha descomprimido el proyecto se crea la carpeta IRIS-2.2.1, con el

comando ls se visualiza dicha carpeta como se muestra en la Figura 15.

Figura 15. Carpeta IRIS del controlador instalada

De igual manera, para los controladores POX y Floodlight que se han utilizado para

comparar con el controlador OpenIRIS, se ha realizado el procedimiento de descarga e

instalación, mismo que se lo puede encontrar en el Anexo A.

4.2 Escenarios de simulación

El escenario de simulación a emplearse se muestra en la Figura 16. Existirán 3 posibles

escenarios:

Escenario 1: el controlador y Mininet se encuentran en la misma máquina

dentro de la misma red.

Escenario 2: el controlador se encuentra en un servidor y Mininet en una

máquina diferente dentro de la misma red.

Escenario 3: el controlador se encuentra en un servidor y Mininet en una

máquina diferente en diferentes redes.

28

Figura 16. Escenario de simulación

Para recrear los escenarios mencionados se necesita establecer el direccionamiento IP y

un número de puerto para cada controlador como se muestra en la Tabla 5.

Tabla 5. Direccionamiento IP para cada escenario y puertos para cada controlador

Cabe mencionar que para conectarse remotamente a la máquina de Mininet siempre se

utilizará la IP: 192.168.56.101 y el puerto 22 por defecto.

Es necesaria una conexión desde la PC hacia la máquina virtual y hacia los

controladores, por lo que se ha utilizado el protocolo SSH para establecer dos o más

sesiones remotas. La primera sesión se utilizará para conectar con la máquina virtual y

estrictamente levantar el entorno de simulación Mininet y las demás para conectarnos

con uno o varios de los controladores.

IP PUERTO

POX

PUERTO

FLOODLIGHT

PUERTO

IRIS

Escenario 1 192.168.56.101

6633 6653 6643 Escenario 2 192.168.88.100

Escenario 3 190.155.208.131

29

Para el Escenario 2 se ha realizado las conexiones como se muestra en las Figuras 17 y

18.

Figura 17. Conexión SSH hacia Mininet

Figura 18. Conexión SSH hacia el controlador

Las mismas conexiones se han realizado para el Escenario 3 pero con la IP asignada en

la Tabla 5 para conectarse a los controladores. Sin embargo para el Escenario 1 se ha

utilizado la misma sesión de la Figura 17 para conectarse tanto a Mininet como a los

controladores (ver Anexo B).

4.3 Topología empleada en la simulación

30

Se ha utilizado una topología personalizada (custom), ya que se requiere incluir

parámetros de red en el código evitando repetir el proceso cada vez que se necesite crear

la topología. Adicionalmente, se ha incorporado en la programación el llamado de los

tres controladores. En la Figura 19 se muestra la topología a usar.

Figura 19. Topología personalizada usada en la simulación

Para ejecutar una topología personalizada se utiliza el siguiente comando:

$ sudo python [nombre_de_la_topología].py

Se ha generado para cada escenario un archivo diferente de la topología como se

muestra en la Figura 20.

Figura 20. Archivos de la topología para cada escenario

31

A continuación se presenta el código del archivo topocustom1.py generado para el

Escenario 1.

ESCENARIO 1 (topocustom1.py): from mininet.net import Mininet

from mininet.cli import CLI

from mininet.node import RemoteController

from mininet.util import dumpNodeConnections

from mininet.log import setLogLevel

net = Mininet(controller=None)

#AGREGAR CONTROLADORES net.addController('c0', controller=RemoteController, ip='127.0.0.1', port=6633)

#Controlador POX net.addController('c1', controller=RemoteController, ip='127.0.0.1', port=6643)

#Controlador IRIS net.addController('c2', controller=RemoteController, ip='127.0.0.1', port=6653)

#Controlador Floodlight

#AGREGAR SWITCHS s1 = net.addSwitch('s1')

s2 = net.addSwitch('s2')


#AGREGAR HOSTS h1 = net.addHost('h1')

h2 = net.addHost('h2')



#AGREGAR ENLACES net.addLink(s1, s2)

net.addLink(s1, s3)

net.addLink(h1, s2)

net.addLink(h2, s2)

net.addLink(h3, s3)

net.addLink(h4, s3)

setLogLevel( 'info' ) #INFORMACION DE LA TOPOLOGIA

net.start() #INICIO

dumpNodeConnections(net.hosts) #CONEXIONES DE LOS HOSTS

CLI(net) #INGRESO A LA LINEA DE COMANDOS MININET

net.stop() #FIN

32

La topología para el Escenario 1 (topocustom1) se ejecuta como se muestra en la Figura

21.

Figura 21. Ejecución topología personalizada 1

De igual manera, se ha generado el mismo código para los otros escenarios (Ver anexo

D), pero diferenciando el direccionamiento IP mostrado en la Tabla 5.

4.4 Ejecución de los Controladores SDN

En el presente proyecto se ha realizado dos formas de ejecución: la primera

considerando a un solo controlador y la segunda ejecutando los tres controladores al

mismo tiempo dentro de la red. Para ejecutar el controlador OpenIRIS, se sugiere

configurar el archivo de propiedades “torpedo.properties” mostrado en la Figura 22.

Figura 22. Archivo de propiedades del controlador OpenIRIS

33

Se ha editado el archivo de propiedades con el comando nano, asignando diferentes

puertos de los que están por defecto, como se muestra en la Figura 23, para evitar que

otro servicio esté ocupando el mismo puerto.

Figura 23. Edición y configuración de las propiedades del controlador

Finalmente, la Figura 24 muestra cómo se ejecuta el controlador.

Figura 24. Ejecución del controlador OpenIRIS

Similar configuración se ha realizado en los archivos de propiedades los controladores

POX y Floodlight para poder ser ejecutados (ver anexo C).

34

Una vez finalizada la ejecución considerando a un solo controlador en la red, se ha

procedido a ejecutar los tres controladores (POX, Floodlight y OpenIRIS) al mismo

tiempo, como se puede ver en la Figura 25.

Figura 25. Ejecución de los tres controladores al mismo tiempo

Como se puede observar en la Figura 26, se presentan inconsistencias en la red porque

los tres controladores se encuentran ejecutando módulos con reglas similares, es decir,

que al comunicarse los switches con los controladores, éstos necesitan saber las

acciones que deben tomar y como los tres controladores se encuentran levantados

responden con la misma regla de flujo provocando que el mismo paquete se direccione

al mismo destino, generando los paquetes duplicados.

Figura 26. Error de paquetes duplicados

35

Para visualizar la red de una manera más amigable y gráfica se puede levantar la

interfaz web de los controladores, donde se presentan los dispositivos (switches, hosts)

con sus respectivas conexiones como se puede ver en la Figura 27. También se puede

ver cómo queda la topología empleada en la Figura 28.

Figura 27. Interfaz web de OpenIRIS en el Escenario 1

Figura 28. Topología empleada representada en la interfaz web

36

Dependiendo del escenario donde se esté trabajando se asigna la IP correspondiente

especificada en la Tabla 5 y un puerto para levantar la interfaz web de cada controlador,

en este proyecto se ha asignado los siguientes puertos presentados en la Tabla 6.

CONTROLADOR PUERTO INTERFAZ WEB

OPENIRIS 8084

FLOODLIGHT 8085

POX No tiene interfaz web

Tabla 6. Puertos para la interfaz web de los controladores

37

5. EVALUACIÓN DE LAS SDN

5.1 Tabulación de resultados en la simulación de la SDN

Para realizar el análisis de la SDN y de cada controlador en cada escenario se han

tomado los tiempos máximos de respuesta para evaluar el rendimiento (Tablas 7, 9 y

11) y los tiempos promedios de respuesta para evaluar la latencia (Tablas 8, 10, 12)

marcando de fondo verde a los mejores tiempos, de las diferentes corridas de cada uno

de los controladores (ver anexo E).

Escenario 1:

Tabla 7. Comparación de tiempos de respuesta máximos (Rendimiento 1)

Tabla 8. Comparación de tiempos de respuesta (Latencia 1)

CONTROLADOR HOST

ORIGEN

HOST

DESTINO

PRIMERA

CONEXIÓN

(ms)

CONEXIÓN

ESTABLECIDA

(ms)

FLOODLIGHT H1 H4 61.80 8.66

H1 H2 9.79 2.81

OPENIRIS H1 H4 71.10 0.05

H1 H2 24.50 2.23

POX H1 H4 40.20 43.90

H1 H2 7.35 5.73

CONTROLADOR HOST

ORIGEN

HOST

DESTINO

PRIMERA CONEXIÓN

(ms)

CONEXIÓN

ESTABLECIDA

(ms)

MIN AVG MAX MIN AVG MAX

FLOODLIGHT H1 H4 0.000 6.268 61.839 0.049 1.129 8.661

H1 H2 0.044 1.064 9.797 0.000 0.408 2.810

OPENIRIS H1 H4 0.069 7.235 71.180 0.053 0.091 0.189

H1 H2 0.053 3.178 24.571 0.053 0.368 2.239

POX H1 H4 0.039 4.441 40.213 0.058 4.740 43.960

H1 H2 0.054 1.043 7.354 0.000 0.824 5.733

38

Escenario 2:

CONTROLADOR HOST

ORIGEN

HOST

DESTINO

PRIMERA

CONEXIÓN

(ms)

CONEXIÓN

ESTABLECIDA

(ms)


H1 H2 13.90 6.72

OPENIRIS H1 H4 77.40 9.87

H1 H2 24.00 5.44

POX H1 H4 85.90 35.30

H1 H2 71.30 42.10


CONTROLADOR HOST

ORIGEN

HOST

DESTINO

PRIMERA CONEXIÓN

(ms)

CONEXIÓN

ESTABLECIDA

(ms)


FLOODLIGHT H1 H4 0.049 7.486 73.705 0.064 1.851 16.975

H1 H2 0.038 1.468 13.903 0.056 0.757 6.723

OPENIRIS H1 H4 0.059 7.847 77.422 0.055 1.139 9.871

H1 H2 0.053 2.497 24.051 0.045 0.629 5.444

POX H1 H4 0.071 8.845 85.945 0.040 3.689 35.343

H1 H2 0.048 7.304 71.389 0.050 4.353 42.173

Tabla 10. Comparación de tiempos de respuesta (Latencia 2)

Escenario 3:


CONTROLADOR HOST

ORIGEN

HOST

DESTINO

PRIMERA

CONEXIÓN

(ms)

CONEXIÓN

ESTABLECIDA

(ms)


H1 H2 127.00 88.33

OPENIRIS H1 H4 258.00 124.00

H1 H2 166.00 52.20

POX H1 H4 1948.00 860.00

H1 H2 166.00 75.10

39

CONTROLADOR HOST

ORIGEN

HOST

DESTINO

PRIMERA CONEXIÓN

(ms)

CONEXIÓN

ESTABLECIDA

(ms)


FLOODLIGHT H1 H4 0.055 30.652 305.569 0.060 20.938 208.251

H1 H2 0.050 12.822 127.270 0.048 8.944 88.380

OPENIRIS H1 H4 0.045 25.930 258.333 0.064 12.625 124.997

H1 H2 0.042 16.682 166.173 0.055 5.304 52.215

POX H1 H4 0.065 291.989 1.948.109 0.061 86.216 860.043

H1 H2 0.061 16.802 166.089 0.054 7.711 75.190

Tabla 12. Comparación de respuesta (latencia) en Escenario 3

5.2 Evaluación de Resultados en la simulación de la red definida por software

(SDN)

Tomando en cuenta las tablas anteriores (7-12), se puede ver en la Tabla 13 los mejores

tiempos promedios (mínimos) de cada controlador y en la Tabla 14 los mínimos

tiempos de los máximos tiempos de respuesta de cada controlador en cada escenario,

evidenciando que el controlador OpenIRIS tiene la mejor latencia y rendimiento.

Tabla 13. Mejores tiempos promedios de Latencia

ESCENARIOS

PRIMERA

CONEXIÓN

(ms)

CONTROLADOR

CONEXIÓN

ESTABLECIDA

(ms)

CONTROLADOR

1 7.35 POX 0.053 OPENIRIS

2 13.9 FLOODLIGHT 5.44 OPENIRIS

3 127 FLOODLIGHT 52.2 OPENIRIS

Tabla 14. Máximos tiempos de respuesta de los controladores

ESCENARIOS

PRIMERA

CONEXIÓN

(ms)

CONTROLADOR

CONEXIÓN

ESTABLECIDA

(ms)

CONTROLADOR

1 1.043 POX 0.091 OPENIRIS



40

6. DISCUSIÓN

Para verificar que la simulación de red es factible, se planteó tres escenarios diferentes

donde se observa el comportamiento de la red en función de los tráficos existentes,

como se puede evidenciar en las tablas obtenidas (7-12), cuando se realiza las pruebas

de conectividad de h1 a h2 se obtienen menores tiempos de respuesta ya que solo se

establece la comunicación de un switch con el controlador, por ende el flujo de paquetes

pasa a través de ese único switch (switch 2). En cambio, cuando se realiza las pruebas

de conectividad de h1 a h4 los tiempos de respuesta en la primera conexión son más

altos debido a que esta vez interactúan los tres switches con el controlador, es decir, el

flujo de paquetes pasa por cada switch y éste se tiene que comunicar a su vez con el

controlador hasta aprender la ruta y llegar al host destino. Una vez establecida la

conexión, los dispositivos ya se conocen entre sí, por lo que ya no se necesita de una

comunicación constante del controlador con los switch puesto que ya se almacenaron

las reglas del flujo relacionadas a dichos dispositivos. El rendimiento de cada

controlador se ha evaluado en función de los tiempos máximos de respuesta con el fin

de evaluar el comportamiento de cada controlador en cada uno de los escenarios

establecidos. En las tablas 13 y 14 se puede observar que para la primera conexión se ha

obtenido menores tiempos de respuesta para los controladores POX y Floodlight,

mientras que cuando la conexión está establecida los tiempos de respuesta son mejores

para OpenIRIS, por lo tanto se evidencia que OpenIRIS tiene mejor rendimiento y

latencia cuando la conexión ya está establecida. Se trabajó con diferentes escenarios

para poder validar el controlador, dentro de la virtualización y también cuando se

encuentra en un servidor o computador físico, los resultados obtenidos en las tablas 8

son tiempos bajos puesto que se trabaja en una red totalmente virtual, en cambio las

tablas 10 y 12 nos dan a conocer tiempos de respuesta que se pueden dar dentro de una

topología de red real. Con esta validación se comprobó que no necesariamente el

controlador debe estar dentro de una misma red, podemos tener un controlador incluso

fuera de la misma (escenario 3), por lo tanto es factible crear una SDN puesto que no

importa el ambiente sea virtual o físico siempre se lleva a cabo los procesos.

41

7. CONCLUSIONES

Es importante conocer las características de los diferentes tipos de controladores y

las funciones que éstos ofrecen para seleccionar adecuadamente el que se va

emplear en una implementación de red.

Con esta nueva estructura de redes se destaca netamente que no nos encontramos

atados a un solo lenguaje de programación para generar o establecer reglas, ya que

independientemente del lenguaje que usen los controladores se puede migrar los

módulos ya establecidos.

Los diferentes actores implementan SDN de múltiples maneras, primando el uso de

sus propios equipos, de la misma forma se ha propuesto una topología personalizada

como se puede ver en la Figura 19 incorporando en la programación el llamado de

los tres controladores. para poder realizar las pruebas necesarias y que se ajusten a

nuestros requerimientos.

Al realizar pruebas de conectividad, se puede concluir que cuando el controlador se

encuentra dentro de un escenario virtualizado (escenario 1) se tienen tiempos de

respuesta irreales ya que son demasiado bajos, a diferencia de tener un controlador

físico como en los escenarios 2 y 3 donde se puede evidenciar tiempos que se

ajustan a la realidad.

En los resultados obtenidos en las tablas 13 y 14 se concluye que el controlador

OpenIRIS es mejor en rendimiento y latencia respecto a los otros controladores, una

vez que la conexión este ya establecida, pues presenta los menores tiempos de

respuesta respecto a los tiempos máximos de los demás controladores.

Cuando se hace la ejecución de los 3 controladores al mismo tiempo, se puede

establecer la conexión con los tres, pero si se ejecuta un módulo en común entre los

controladores se evidencia errores de comunicación, en este proyecto se obtiene un

error de paquetes duplicados como se puede ver en la Figura 26 ya que al responder

los tres controladores a la misma petición envían el mismo paquete al mismo destino

generando que éste se duplique.

42

8. RECOMENDACIONES

Como el SDN\Openflow es un campo relativamente nuevo, para entender de mejor

manera se recomienda hacer pruebas cambiando de controladores y experimentando

diferentes flujos de paquetes, inclusive programando reglas para determinar su

comportamiento.

Este proyecto no cuenta con un sistema de backup, sería importante implementar un

proceso de respaldo, ya que, si ocurre un error es necesario volver a configurar todo

nuevamente.

Se recomienda realizar un monitoreo de la red, esto se lo puede hacer mediante la

conexión a una base de datos en la cual se almacenen los logs transaccionales que nos

permitirán saber el estado de cada equipo de la red.

Otra recomendación es que se debería ejecutar los controladores con diferentes módulos

para que no existan errores, por ejemplo, la duplicación de paquetes que se puede

apreciar en el anexo E.

43

BIBLIOGRAFÍA

1. ALBAN, P., & BRITO, D. (2015). Repositorio Digital ESPE. Obtenido de

http://repositorio.espe.edu.ec/xmlui/bitstream/handle/21000/9848/T-ESPE-

048694.pdf?sequence=1

2. AZODOLMOLKY, S. (2013). Software Defined Networking with OpenFlow.

Birmingham: PACKT.

3. DOXYGEN. (3 de Febrero de 2015). Mininet Python API Reference Manual.

Obtenido de http://mininet.org/api/annotated.html

4. GARCÍA CENTENO, A., RODRÍGUEZ VERGEL, C., ANÍAS CALDERÓN,

C., & CASMARTIÑO BONDARENKO, C. (Septiembre de 2012).

Controladores SDN, elementos para su selección y evaluación. Obtenido de

Revista Telemática:

http://revistatelematica.cujae.edu.cu/index.php/tele/article/viewFile/164/153

5. GitHUb. (07 de Junio de 2015). OpenIRIS v2.2.1. Obtenido de IRIS: The

Recursive SDN Openflow Controller by ETRI:

https://github.com/openiris/IRIS/releases

6. GÓMEZ, H. (Enero de 2015). Depósito institucional de la UPC. Obtenido de

http://upcommons.upc.edu/bitstream/handle/2099.1/25422/Dynamical_QoS_ove

r_SDN.pdf

7. LÓPEZ, D. R. (9 de Noviembre de 2012). SDN (Software Defined Networking):

cambiando de paradigma en la red. Obtenido de http://blogthinkbig.com/sdn-

software-defined-networking-cambiando-de-paradigma-en-la-red/

44

8. MALDONADO, D. A. (Mayo de 2014). Diseño e implementación de una

aplicación de red bajo la arquitectura SDN. Obtenido de PONTIFICIA

UNIVERSIDAD JAVERIANA:

http://repository.javeriana.edu.co/bitstream/10554/12745/1/MaldonadoHidalgoD

iegoArmando2014.pdf

9. MiniNet. (2014). MiniNet. Obtenido de http://mininet.org/

10. MORILLO, D. (Mayo de 2014). Repositorio Digital EPN. Obtenido de

http://bibdigital.epn.edu.ec/bitstream/15000/7360/1/CD-5509.pdf

11. NADEAU, T. D., & GRAY, K. (2013). Software Defined Networks SDN. United

States of America: Published by O´Reilly.

12. OPEN NETWORKING FOUNDATION. (s.f.). Software-Defined Networking

(SDN) Definition. Obtenido de https://www.opennetworking.org/

13. Principia technologica. (marzo de 2014). Investigación de redes definidas por

software. Obtenido de

https://principiatechnologica.files.wordpress.com/2014/03/sdn-principia-

technologica-2.pdf

14. Principia technologica. (Marzo de 2014). Investigación de redes definidas por

software. Obtenido de

https://principiatechnologica.files.wordpress.com/2014/03/sdn-principia-

technologica-3.pdf

15. RAJESH, K. S. (2013). A definitive guide to Software Defined Networking.

Smashwords Edition.

45

16. Redclara. (s.f.). Indico. Obtenido de

http://eventos.redclara.net/indico/getFile.py/access?contribId=0&resId=0&mater

ialId=slides&confId=197

17. RONCERO HERVÁS, Ó. (s.f.). Software Defined Networking. Obtenido de

Portal del coneixement obert de la UPC:

http://upcommons.upc.edu/bitstream/handle/2099.1/21633/Memoria.pdf?sequen

ce=4

18. RUIZ, A. F. (28 de Noviembre de 2014). ESTADO DEL ARTE - REDES

DEFINIDAS POR SOFTWARE (SDN). Obtenido de

http://ribuc.ucp.edu.co:8080/jspui/bitstream/handle/10785/2788/CDMIST97.pdf

?sequence=2

19. SAVU, D., & STANCU, S. (14 de Febrero de 2014). Software Defined

Networking technology details and openlab research overview. Obtenido de

http://openlab.web.cern.ch/sites/openlab.web.cern.ch/files/presentations/0%5B1

%5D.pdf

20. SEETHARAMAN, S. (Noviembre de 2011). OpenFlow/ Software Defined

Networking. Obtenido de http://es.slideshare.net/openflow/openflow-tutorial

21. SONBA, A., & ABDALKREIM, H. (Diciembre de 2014). Performance

Comparison Of the state of the art Openflow Controllers. Obtenido de

http://www.diva-portal.org/smash/get/diva2:783679/FULLTEXT02

22. SPERA, C. (2013). Software Defined Network: el futuro de las arquitecturas de

red. Obtenido de http://www.la.logicalis.com/globalassets/latin-

america/logicalisnow/revista-20/lnow20-nota-42-45.pdf

46

23. VÁSQUEZ, J. M. (10 de Julio de 2011). Diseño y Desarrollo de una Aplicación

Para el Estudio Comparativo de Topologías de Red. Obtenido de e-Archivo

Universidad Carlos III de Madrid: http://e-

archivo.uc3m.es/bitstream/handle/10016/12615/PFC-Jose-Miguel-Vazquez-

Viejo.pdf?sequence=1

24. VELASCO, R. (20 de Marzo de 2014). Lista de simuladores de redes para

virtualizar nuestra propia red. Obtenido de REDES ZONE:

http://www.redeszone.net/2014/03/20/lista-de-simuladores-de-redes-para-

virtualizar-nuestra-propia-red/

47

ANEXOS

1

ANEXO A

Instalación de los controladores

POX:

Para descargar el controlador POX se puede ingresar a la página web oficial (Figura

A1): https://github.com/noxrepo/pox/tree/eel o con el comando:

$ wget https://github.com/noxrepo/pox/archive/eel.zip

Figura A1. Descarga del controlador POX

Luego se descomprime el archivo eel.zip descargado con el comando:

$ unzip eel.zip

Figura A2. Descomprimir controlador

https://github.com/noxrepo/pox/tree/eel

2

Al ser descomprimido se crea la carpeta pox-eel en la cual se encuentra el archivo para

ser ejecutado el controlador. Ingresar a la carpeta con el comando: $ cd pox-eel/

Figura A3. Carpeta pox-eel del controlador instalada

FLOODLIGHT:

Descargar el proyecto del controlador Floodlight de la página web oficial

http://www.projectfloodlight.org/download/ o con el comando:

$ wget https://github.com/floodlight/floodlight/archive/v1.2.zip

Figura A4. Descarga controlador Floodlight.

http://www.projectfloodlight.org/download/

3

Descomprimir el proyecto con el comando:

$ unzip v1.2.zip

Figura A5. Descomprimir controlador

Una vez que se ha descomprimido el proyecto se genera una carpeta floodlight-1.2. Al

ingresar a ésta carpeta se encuentra el archivo para ejecutar el controlador.

Figura A6. Carpeta floodlight-1.2 del controlador instalada

4

Para compilar el proyecto java de Floodligth se debe usar el programa ant, se lo

descarga previamente y basta con ingresar a la carpeta del proyecto y ejecutar el

comando:

$ ant

Figura A6. Compilar controlador Floodlight

Al completar el proceso de compilación se crea la carpeta target.

Figura A7. Carpeta target instalada

5

ANEXO B

Conexión SSH hacia Mininet y los controladores

Para el Escenario 1: se abre dos terminales con la misma sesión como se muestra en la

figura B1, la una se conecta al controlador y la otra se conecta a Mininet.

Figura B1. Conexión SSH hacia Mininet y controlador (dos veces la misma)

Para el Escenario 3: se asigna la IP correspondiente definida en la Tabla 5.

Figura B2. Conexión SSH hacia Mininet

6

Figura B3. Conexión SSH hacia el controlador

7

ANEXO C

Propiedades y ejecución de los controladores

Floodlight:

Editar el archivo de propiedades “learning.properties” del controlador Floodlight y

asignar puertos diferentes a los que están por defecto.

Figura C1. Edición y configuración de las propiedades del controlador

8

Al finalizar los cambios, ya se puede ejecutar el controlador como se muestra en la

siguiente Figura.

Figura C2. Ejecución del controlador Floodlight

POX:

Editar el archivo de propiedades “learning.py” del controlador POX o se sugiere crear

un archivo nuevo pero con las mismas propiedades de éste y asignar puertos diferentes a

los que están por defecto. En este caso se creó el archivo of_01.py

Figura C3. Edición y configuración de las propiedades del controlador

9

Al finalizar los cambios, ya se puede ejecutar el controlador como se muestra en la

siguiente Figura.

Figura C4. Ejecución del controlador POX

10

ANEXO D

Código y ejecución de las topologías

TOPOLOGÍA 2 - ESCENARIO 2 (topocustom2.py):

Código fuente cambiando el direccionamiento IP según la Tabla 5.

from mininet.net import Mininet


















net.addLink(s1, s3)

net.addLink(h1, s2)

net.addLink(h2, s2)

net.addLink(h3, s3)

net.addLink(h4, s3)


net.start() #INICIO

dumpNodeConnections(net.hosts) #CONEXIONES


net.stop() #FIN

11

Cambio de direccionamiento IP y ejecución de la topología para el Escenario 2.

Figura D1. Código fuente con la dirección IP asignada al escenario 2

Figura D2. Ejecución topología personalizada 2

12

TOPOLOGÍA 3 - ESCENARIO 3 (topocustom3.py):

Código fuente cambiando el direccionamiento IP según la Tabla 5.

from mininet.net import Mininet


















net.addLink(s1, s3)

#net.addLink(s2, s3) net.addLink(h1, s2)

net.addLink(h2, s2)

net.addLink(h3, s3)

net.addLink(h4, s3)


net.start() #INICIO

dumpNodeConnections(net.hosts) #CONEXIONES


net.stop() #FIN

13

Cambio de direccionamiento IP y ejecución de la topología para el Escenario 3.

Figura D3. Código fuente con la dirección IP asignada al escenario 3

Figura D4. Ejecución topología personalizada 3

14

ANEXO E

Resultados de la ejecución de los controladores

ESCENARIO 1:

Resultados de la ejecución del controlador Floodlight.

Figura E1. Tiempos de respuesta a la primera conexión

Figura E2. Tiempos de respuesta conexión establecida

15

Resultados de la ejecución del controlador OpenIRIS.



16

Resultados de la ejecución del controlador POX.



17

ESCENARIO 2:




18




19




20

ESCENARIO 3:




21




22




UNIVERSIDAD CENTRAL DEL ECUADOR FACULTAD DE … · Las redes de computadoras son de suma...

Documents

Transcript of UNIVERSIDAD CENTRAL DEL ECUADOR FACULTAD DE … · Las redes de computadoras son de suma...