Red SDN

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
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.
ii
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.
iii
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: natalyeet@hotmail.com
iv
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
v
vi
vii
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
viii
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
ix
Código y ejecución de las topologías ........................................................................... 10
ANEXO E ...................................................................................................................... 14
Resultados de la ejecución de los controladores ........................................................ 14
x
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
xi
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
xii
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
xiii
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/
xiv
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/
xv
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.
1
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).
2
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.
3
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.
4
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.
5
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)
6
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).
7
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.
8
Figura 2. Comparativa de la arquitectura de una red tradicional y una SDN
(SEETHARAMAN, 2011)
9
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)
RED TRADICIONAL SDN

Relativamente estática y difícil de aplicar
Dinámica
políticas
No son flexibles Flexible
Incapaz de ser escalable Escalabilidad
Las tablas de flujo están cerradas en los
Tablas de enrutamiento abiertas
dispositivos
Nuevas aplicaciones en mayor tiempo Nuevas aplicaciones en menor tiempo
Configuración descentralizada Configuración centralizada mediante
(en cada dispositivo) programación en el software controlador
Interfaces propietarias APIs bien definidas y abiertas
 Control central
Automatización posible pero tediosa  Una interfaz (API) para todos los
dispositivos (Savu & Stancu, 2014)
Envió de paquetes basados en coincidencias Formato y acciones de las tablas
de la tabla claramente especificadas
Corta la investigación y desarrollo Facilidad de innovación
Reducción de costos operativos y
Altos costos operativos y financieros
financieros
Tabla 1. Diferencias entre red tradicional y SDN
10
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.
11
Openflow 1.0 Openflow 1.1 Openflow 1.2 Openflow 1.3 Openflow 1.4
* Diciembre, 2009
* Febrero 28, 2011 * Diciembre, 2011 * Abril 25, 2013 * Agosto, 2013
* L1-L4 campo * Extensión de * Propiedades de

* Múltiples tablas * Múltiples tablas
coincidente soporte Match puerto óptico
* Acciones: envia al
puerto, reescribe los * Multinivel y
* Soporte básico * Expande el soporte * IANA puerto TCP
encabezados de etiquetado de MPLS
IPV6 IPV6 6653
L2-L4, set/strip y VLAN
etiqueta VLAN
* Eventos de
* Máscaras de * Paquetes de * Encriptación de
* Puertos virtuales monitoreo y estado
subred mensajes información
del controlador
* Tráfico en el puerto * Conexión a más de * Estadísticas de los
* Grupo de puertos
de salida 1 controlador flujos
* Módulo de fallo * Módulo de fallo de
* Tunnel-ID meta data
difícil de implementar conexión incluido
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.
12
 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.
13
 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

14
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
15
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.
16
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.
17
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
18
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.
19
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.
20
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.
21
PACKET
KIVA NS2 OMNet++ MININET NCTUns
TRACER
INTERFAZ GRÁFICA si si si (baja) si si si
INSTALACIÓN compleja media compleja compleja fácil compleja

* Libre * Libre
(miembros (propósitos
TIPO DE LICENCIA Libre Libre Libre Libre
CISCO) académicos)
* Comercial * Comercial
* Mac
* Windows * Unix
(98, ME, (Free BSD,
* Windows
2000 o XP) Linux,
* Unix y * Linux
* Mac SunOS, * Windows
* Windows Linux (Red Hat,
PLATAFORMAS (versión 3.2 Solaris) * Mac
* Linux (algunas Fedora core
de Packet * Windows * Linux
versiones) 3.0)
Tracer no (desde W95
* Mac
soporta necesita MS
Macintosh). Visual C++
5.0 (ó >).
PROTOCOLOS Y Bajo: IP, Alto: solo Alto: solo

Alto Alto Alto
TECNOLOGÍAS tcp/IP Ethernet Linux
NED (se basa

LENGUAJE Java Desconocido C++ y OTcl Phyton Desconocido
en C++)
no existe
COMPATIBILIDAD no si no si si
información
PROGRAMACIÓN alta media alta alta media alta
USO alto (pagando

medio alto alto alto alto
INVESTIGATIVO licencia)
Crea redes
virtuales a
Estudio de las gran escala
Módulos
redes IP y de forma
Entrenamient que cubren
especialmente rapida y
o para un extenso
el eficiente. Simulador y
obtener la grupo de Simulación
seguimiento y (práctica emulador de
certificación aplicaciones de eventos
análisis del para el redes y
CARACTERÍSTICAS de CCNA, , protocolos discretos,
funcionamien estudio de sistemas de
GENERALES CCNP y de ruteo, modular y
to, el envío y SNDs, telecomunic
CCIE. Solo transporte, orientado a
la recepción debido a aciones
simula con diferentes objetos.
de los que permite avanzado
equipos de tipos de
datagramas a implementa
CISCO enlaces,
través de r nodos
entre otros.
TCP/IP con
protocolo
OpenFlow)
Tabla 3. Cuadro comparativo software de simulación de red
22
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
23
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
24
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.
25
OpenIRIS CALF. FLOODLIGHT CALF. BEACON CALF. NOX CALF. POX CALF.
PROGRAMACIÓN Java 3 Java 3 Java 3 Phyton 2 Phyton 2

SOPORTE OpenFlow
3 OF V1.0 1 OF V1.0 1 OF V1.0 1 OF V1.0 1
PROTOCOLO OF V1.O –V1.3
HERRAMIENTAS * MININET * MININET * MININET * MININET * MININET
2 2 2 2 2
DE SIMULACIÓN * OVS * OVS * OVS * OVS * OVS
* Windows
* Windows * Windows * Linux * Windows
PLATAFORMAS
* Linux 2 * Linux 2 * OS X 3 Linux 1 * Linux 2
(S.O.)
* OS X * OS X * Android * OS X
para móviles
TIPO DE Código Código Código Código
3 Código Abierto 3 3 3 3
SOFTWARE Abierto Abierto Abierto Abierto
* Politécnica
Nacional Universidad Politécnica
ESTUDIADO EN Ninguna 3 2 1 1 ESPE 1
* Universidad de de Ambato Nacional
Ambato
FUNCIONALIDAD
Nivel alto 3 Nivel medio 2 Nivel bajo 1 Nivel bajo 1 Nivel bajo 1
DE LA RED
TIEMPO DE
2 años 2 2 años 2 4 años 3 6 años 3 1 año 1
LANZAMIENTO
DOCUMENTACIÓN Media 2 Alta 3 Alta 3 Alta 3 Media 2
TOTALES 23 20 20 17 15
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

26
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.
27
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.
PUERTO PUERTO PUERTO

IP
POX FLOODLIGHT IRIS
Escenario 1 192.168.56.101
Escenario 2 192.168.88.100 6633 6653 6643
Escenario 3 190.155.208.131
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.
28
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
29
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
30
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
#Controlador IRIS
#Controlador Floodlight
#AGREGAR SWITCHS
s1 = net.addSwitch('s1')
#AGREGAR HOSTS
h1 = net.addHost('h1')
#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
31
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
32
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).
33
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
34
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
35
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
36
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:
PRIMERA CONEXIÓN
HOST HOST
CONTROLADOR CONEXIÓN ESTABLECIDA
ORIGEN DESTINO
(ms) (ms)
H1 H4 61.80 8.66
FLOODLIGHT
H1 H2 9.79 2.81
H1 H4 71.10 0.05
OPENIRIS
H1 H2 24.50 2.23
H1 H4 40.20 43.90
POX
H1 H2 7.35 5.73
Tabla 7. Comparación de tiempos de respuesta máximos (Rendimiento 1)
CONEXIÓN
PRIMERA CONEXIÓN
HOST HOST ESTABLECIDA
CONTROLADOR (ms)
ORIGEN DESTINO (ms)
MIN AVG MAX MIN AVG MAX
H1 H4 0.000 6.268 61.839 0.049 1.129 8.661
FLOODLIGHT
H1 H2 0.044 1.064 9.797 0.000 0.408 2.810
H1 H4 0.069 7.235 71.180 0.053 0.091 0.189
OPENIRIS
H1 H2 0.053 3.178 24.571 0.053 0.368 2.239
H1 H4 0.039 4.441 40.213 0.058 4.740 43.960
POX
H1 H2 0.054 1.043 7.354 0.000 0.824 5.733
Tabla 8. Comparación de tiempos de respuesta (Latencia 1)
37
Escenario 2:
PRIMERA CONEXIÓN
HOST HOST
ORIGEN DESTINO
(ms) (ms)
H1 H4 73.70 16.90
FLOODLIGHT
H1 H2 13.90 6.72
H1 H4 77.40 9.87
OPENIRIS
H1 H2 24.00 5.44
H1 H4 85.90 35.30
POX
H1 H2 71.30 42.10
CONEXIÓN
PRIMERA CONEXIÓN
CONTROLADOR (ms)
ORIGEN DESTINO (ms)
H1 H4 0.049 7.486 73.705 0.064 1.851 16.975
FLOODLIGHT
H1 H2 0.038 1.468 13.903 0.056 0.757 6.723
H1 H4 0.059 7.847 77.422 0.055 1.139 9.871
OPENIRIS
H1 H2 0.053 2.497 24.051 0.045 0.629 5.444
H1 H4 0.071 8.845 85.945 0.040 3.689 35.343
POX
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:
PRIMERA CONEXIÓN
HOST HOST
ORIGEN DESTINO
(ms) (ms)
H1 H4 305.00 208.00
FLOODLIGHT
H1 H2 127.00 88.33
H1 H4 258.00 124.00
OPENIRIS
H1 H2 166.00 52.20
H1 H4 1948.00 860.00
POX
H1 H2 166.00 75.10
38
CONEXIÓN
PRIMERA CONEXIÓN
CONTROLADOR (ms)
ORIGEN DESTINO (ms)
H1 H4 0.055 30.652 305.569 0.060 20.938 208.251
FLOODLIGHT
H1 H2 0.050 12.822 127.270 0.048 8.944 88.380
H1 H4 0.045 25.930 258.333 0.064 12.625 124.997
OPENIRIS
H1 H2 0.042 16.682 166.173 0.055 5.304 52.215
H1 H4 0.065 291.989 1.948.109 0.061 86.216 860.043
POX
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.
PRIMERA CONEXIÓN
ESCENARIOS CONEXIÓN CONTROLADOR ESTABLECIDA CONTROLADOR
(ms) (ms)
1 1.043 POX 0.091 OPENIRIS
2 1.468 FLOODLIGHT 0.629 OPENIRIS
Tabla 13. Mejores tiempos promedios de Latencia
PRIMERA CONEXIÓN
ESCENARIOS CONEXIÓN CONTROLADOR ESTABLECIDA CONTROLADOR
(ms) (ms)
1 7.35 POX 0.053 OPENIRIS
3 127 FLOODLIGHT 52.2 OPENIRIS
Tabla 14. Máximos tiempos de respuesta de los controladores
39
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.
40
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.
41
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.
42
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/
43
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.
44
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
45
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/
46
ANEXOS
47
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
1
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.
2
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
3
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
4
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

5
Figura B3. Conexión SSH hacia el controlador
6
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
7
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

8
Al finalizar los cambios, ya se puede ejecutar el controlador como se muestra en la
siguiente Figura.
Figura C4. Ejecución del controlador POX
9
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.

#Controlador POX
#Controlador IRIS
#AGREGAR SWITCHS
#AGREGAR HOSTS
#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)

net.start() #INICIO
dumpNodeConnections(net.hosts) #CONEXIONES
net.stop() #FIN
10
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
11
TOPOLOGÍA 3 - ESCENARIO 3 (topocustom3.py):
Código fuente cambiando el direccionamiento IP según la Tabla 5.

#Controlador POX
#Controlador IRIS
#AGREGAR SWITCHS
#AGREGAR HOSTS
#AGREGAR ENLACES
net.addLink(s1, s2)
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
12
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
13
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
14
Resultados de la ejecución del controlador OpenIRIS.
15
Resultados de la ejecución del controlador POX.
16
ESCENARIO 2:
17
18
19
ESCENARIO 3:
20
21
22

Red SDN

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Red SDN

Enviado por

Direitos autorais:

Formatos disponíveis

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

AUTOR: NATALY ESTEFANÍA ESPAÑA TARAPUEZ

TUTOR: MGS. MAURO LEONARDO ROSAS LARA

A Dios por estar presente en mi vida,

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

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

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

Quito, 19 de Mayo de 2016

Nataly Estefanía España Tarapuéz

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

MGS. MAURO LEONARDO ROSAS LARA

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

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

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

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

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

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

PALABRAS CLAVES: / CONTROLADOR SDN/ MININET/ REDES DEFINIDAS

DESIGN AND SIMULATION SOFTWARE-DEFINED NETWORKING (SDN),

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

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

KEYWORDS: / SDN CONTROLLER/ MININET/ SOFTWARE-DEFINED

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

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

1.1 Antecedentes del problema

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

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

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

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

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

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

 Variable independiente: Controlador SDN

1.4.1 Objetivo general

1.4.2 Objetivos específicos

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

1.5 Alcance del proyecto

En el presente proyecto se realizará:

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

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

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

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

2.2 Arquitectura SDN

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

Figura 1. Arquitectura SDN (Principia technologica, 2014)

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

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

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

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

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

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

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

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

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

RED TRADICIONAL SDN

Tabla 1. Diferencias entre red tradicional y SDN

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

Figura 4. Arquitectura de red de OpenFlow

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