ContrerasPardoCarlosAlberto2014.pdf

IMPLEMENTACIÓN DE UN OPENFLOW CONTROLLER PARA EL MANEJO DE OPENFLOW
SWITCHES
CARLOS ALBERTO CONTRERAS PARDO
PONTIFICIA UNIVERSIDAD JAVERIANA
FACULTAD DE INGENIERÍA
DEPARTAMENTO DE INGNIERÍA ELECTRÓNICA
BOGOTÁ
2014

2
IMPLEMENTACIÓN DE UN OPENFLOW CONTROLLER PARA EL MANEJO DE OPENFLOW
SWITCHES
CARLOS ALBERTO CONTRERAS PARDO
TRABAJO DE GRADO
DIRECTOR: GUSTAVO ADOLFO RAMÍREZ ESPINOSA
PONTIFICIA UNIVERSIDAD JAVERIANA
FACULTAD DE INGENIERÍA
DEPARTAMENTO DE INGENIERÍA ELECTRÓNICA
BOGOTÁ
2014

3
A MIS PADRES QUE SIEMPRE ESTUVIERON
APOYÁNDOME EN TODO EL PROCESO,
A MI AMOR ETERNO QUE TAMBIÉN ME
ACOMPAÑO Y A DIOS POR DARME ESTA
GRAN OPORTUNIDAD.

4
AGRADECIMIENTOS
Gracias a la mi segundo hogar la Pontificia Universidad Javeriana por brindar todo el apoyo académico para
el desarrollo de una etapa tan importante, agradezco a cada uno de los profesores que guiaron mi camino
para llegar a la cima. De igual forma agradezco a mis faros de toda la vida, mis padres, que con esfuerzo y
valentía hicieron todo lo posible por hacer de este sueño una realidad.

5
CONTENIDO
1. INTRODUCCIÓN..............................................................................................................................10
2. MARCO TEÓRICO ..........................................................................................................................12
2.1 REDES SDN ...............................................................................................................................12
2.2 OPENFLOW ..............................................................................................................................14
2.3 TABLAS DE FLUJO (Flow-Table) VERSION 1.0.................................................................15
2.4. TABLAS DE FLUJO (Flow-Table) VERSION 1.3.................................................................17
2.5. CONTROLADORES SDN........................................................................................................21
2.5.1. POX .....................................................................................................................................21
2.5.2. BEACON.............................................................................................................................22
2.5.3. FLOODLIGHT...................................................................................................................22
2.5.4. SDN VAN CONTROLLER...............................................................................................22
2.5.5. COMUNICACIÓN DEL PROTOCOLO OPENFLOW VERSIÓN 1.0 Y 1.3 .............25
3. ESPECIFICACIONES ......................................................................................................................26
4. DESARROLLOS................................................................................................................................27
4.1. SIMULADORES........................................................................................................................28
4.1.1. MININET............................................................................................................................28
4.1.1. CBENCH BENCHMARK TOOL ....................................................................................39
4.2. TOPOLOGIA DE RED CREADA EN EL LABORATORIO...............................................40
4.2.1. TOPOLOGIA DE RED BUS.............................................................................................41
4.2.2. TOPOLOGÍA DE RED ANILLO.....................................................................................45
5. ANALISIS DE RESULTADOS ........................................................................................................48
5.1. TOPOLOGIA BUS ....................................................................................................................48
5.1.1. PING DE HOST 1 A HOST 2 (VIRTUAL) .....................................................................48
5.1.2. PING DE HOST 1 A HOST 3 (VIRTUAL) .....................................................................49
5.1.3. PING DE HOST 1 A HOST 2 (REAL).............................................................................49
5.1.4. PING DE HOST 1 A HOST 3 (REAL).............................................................................50
5.2. TOPOLOGÍA DE RED ANILLO.............................................................................................50
5.2.1. PING HOST 1 A HOST 2 (VIRTUAL)............................................................................50

6
5.2.4. PIN HOST 1 A HOST 2 (REAL) ......................................................................................52
5.2.5. PING HOST 2 A HOST 3 (REAL) ...................................................................................52
5.2.6. PING HOST 3 A HOST 1 (REAL) ...................................................................................53
5.3. FLUJOS OBTENIDOS CON MININET.................................................................................53
6. CONCLUSIONES..............................................................................................................................55
.........................................................................................................................¡Error! Marcador no definido.
7. BIBLIOGRAFÍA................................................................................................................................57
8. ANEXOS .............................................................................................................................................59

7
TABLA DE FIGURAS
Figura 1. Arquitectura de red SDN ..............................................................................................................13
Figura 2. Esquema de funcionamiento del protocolo OpenFlow para OpenFlow Switch ...........................14
Figura 3. Componentes de una tabla de flujo de un switch..........................................................................15
Figura 4. Campos de información encontrados en “Header Fields” ............................................................16
Figura 5. Conteos que realiza el campo “Counter” y el número de bits usado ............................................17
Figura 6. Paquetes de entrada comparados contra las tablas de flujo en el pipeline....................................18
Figura 7. Proceso del paquete por tabla de flujo..........................................................................................18
Figura 8. Componentes principales de un flujo de entrada in una tabla de flujo .........................................18
Figura 9. Cabeceras de paquetes OpenFlow ................................................................................................19
Figura 10. Proceso de comparación entre el flujo de entrada y las tablas de flujo.......................................19
Figura 11. Conteos realizados por el protocolo versión 1.3.........................................................................21
Figura 12. Control distribuido......................................................................................................................23
Figura 13. Control centralizado....................................................................................................................23
Figura 14. Topología de red implementada en la comprobación del controlador.......................................28
Figura 15. Topología dada por floodlight ...................................................................................................29
Figura 16. Ancho de banda entre los terminales ..........................................................................................30
Figura 17. Topología dada por Beacon ........................................................................................................30
Figura 18. Ancho de banda entre los terminales con controlador Beacon ...................................................31
Figura 19. Reconocimiento de switch por POX...........................................................................................31
Figura 20. Ancho de banda dado por POX ..................................................................................................32
Figura 21. Detección de switch por SDN VAN HP.....................................................................................32
Figura 22. Ancho de banda dado por SDN VAN HP...................................................................................33
Figura 23. Intercambio de mensajes entre el switch y el controlado............................................................33
Figura 24. Topología lineal en MIninet dada por floodlight........................................................................34
Figura 25. Dispositivos Vistos por beacon en topología bus .......................................................................35
Figura 26. Conexión switch virtuales en topología bus Mininet..................................................................35
Figura 27. Topología Anillo Mininet, floodlight .........................................................................................36
Figura 28. Switch vistos por Beacon en Topología anillo en Mininet.........................................................37
Figura 29. Switch en topología anillo identificados por el controlador .......................................................38
Figura 30. Topología en anillo dada por Mininet, controlador SDN VAN H..............................................38
Figura 31. Características del equipo donde se encuentran los controladores .............................................40
Figura 32. Topología tipo bus implementada en el laboratorio...................................................................41
Figura 33. Pantalla Principal de Floodlight..................................................................................................42
Figura 34. Topología de red dada por el controlador...................................................................................43
Figura 35. Reconocimiento de switch en controlador Beacon.....................................................................43
Figura 36. Reconocimiento de switches por controlador POX....................................................................44
Figura 37. Reconocimiento de los switches por el controlador SDN VAN HP...........................................44
Figura 38. Topología dada por el controlador SDN VAN ...........................................................................45
Figura 39. Topología de red Anillo usada en el laboratorio.........................................................................45
Figura 40. Topología de red anillo dada por controlador Floodlight ...........................................................46
Figura 41. Conexión entre sí de los switch ..................................................................................................46

8
Figura 42. Reconocimiento de los switch en la topología anillo por parte del controlador POX ................47
Figura 43. Topología en anillo dada por el controlador SDN VAN HP .........................................................47

9
TABLA DE GRÁFICAS
Gráfica 1. RTT Max H1- H2........................................................................................................................48
Gráfica 2. RTT Min H1 - H2........................................................................................................................48
Gráfica 3. RTT Min Topología H1 – H3 .....................................................................................................49
Gráfica 4. RTT Min Topología H1 – H3 .....................................................................................................49
Gráfica 5. RTT Max H1-H2, real.................................................................................................................49
Gráfica 6. RTT Min H1 - H2, real................................................................................................................49
Gráfica 7. RTT Max H1-H3, real.................................................................................................................50
Gráfica 8. RTT Min H1-H3, real..................................................................................................................50
Gráfica 9. Tiempo de RTT Max y Min........................................................................................................50
Gráfica 10. Tiempos RTT Max y Min .........................................................................................................51
Gráfica 11. Tiempos RTT Max y Min .........................................................................................................51
Gráfica 12. RTT Min Host 1 a Host 2, real..................................................................................................52
Gráfica 13. RTT Max Host 1 a Host , real. ..................................................................................................52
Gráfica 14. RTT Max Host 2 a Host 3, real .................................................................................................52
Gráfica 16. RTT Max Host 3 a Host 1, real. ................................................................................................53
Gráfica 18. Manejo de Flujos con 10 M de Host .........................................................................................53
Gráfica 19. Manejo de Flujos con 1 M de Host ...........................................................................................54
Gráfica 20. Manejo de Flujos con 100 K Host.............................................................................................54

10
1. INTRODUCCIÓN
Las topologías actuales de red están configuradas de tal forma que se minimiza el riesgo de indisponibilidad
y se asegura una conexión estable para el usuario [1], el entorno que posibilita dicho enlace presenta una
alta complejidad en sus arquitecturas debido a un incremento en el uso de internet por parte de dispositivos
tales como tabletas, Smartphones, TV Smart y gadgets [2]. Otro problema importante que se destaca, es la
alta demanda de servicios en la nube además el uso de servidores Big Data1
y la convergencia de servicios
(datos, voz, video, telefonía) [3] , acaparando así un alto flujo de datos, por consiguiente toda la red se ve
congestionada y saturada haciendo que estas topologías de red sean obsoletas. La gestión de estas topologías,
siendo la red altamente tecnológica, presenta una baja automatización de sus procesos como por ejemplo,
para la inserción de políticas de calidad de servicio es necesario la configuración manual por parte de un
operario incrementando así el riesgo de fallas por error humano.
Para atacar el problema de la configuración y administración surgen las redes SDN (Software Defined
Networking o red definida por software), las redes SDN presentan como fundamento principal la separación
de los planos de control y el plano de datos, esto con el fin de delegar el plano de control del dispositivo de
red a un software externo y únicamente quedándose con el plano de datos. Para entender esta separación de
las capas se describe brevemente cual es la función de cada una, el plano de control es el encargado de tomar
las decisiones sobre el camino que deben tomar los paquetes, mientras que el plano de datos es el encargado
de reenvío de los datos tan rápido como sea posible.
Un componente principal de las redes SDN es el controlador, el software al que se le otorgara la inteligencia
de la red, el controlador es el encargado de administrar la red de manera centralizada mediante el protocolo
de comunicación OpenFlow2
, este sistema además tiene la habilidad de moldear el tráfico a través de la red
sin la necesidad de tocar elementos individuales, es decir no requiera la conexión directa entre el controlador
y un switch. Al insertar el controlador en las redes SDN éste tiene la habilidad de manipular las reglas
dentro del switch cuando sea necesario, dando prioridad o no a los distintos paquetes, con esto posee un
gran control sobre la red establecida y por ende beneficios como gestión, total control y optimización con
la priorización y tratamiento de paquetes, en consecuencia se obtienen switch con mayor agilidad para el
envío de información ya que la inteligencia no estará soportada sobre él si no que será delegada al
controlador.
Este trabajo de grado tuvo como finalidad la evaluación e implementación de un controlador (OpenFlow
Controller) para la administración de las topologías de red SDN. En el mercado existen varios controladores
desarrollados para el manejo de este tipo de redes los cuales tienen característica de código abierto, lenguajes
de programación variados y capacidad de manejo de versión del protocolo OpenFlow 1.0 y 1.3, con base en
las características que se profundizarán a lo largo del trabajo de grado sobre los controladores, se determinó
cuáles son los controladores adecuados para el manejo de la topología de red implementada y posteriormente
se exponen los resultados del desempeño tanto en el entorno virtual como en el real.
En primera instancia se determinaron parámetros esenciales con el fin de establecer un punto de referencia
e iniciar con la proceso, se postuló la evaluación en tres aspectos importantes como son la calidad de la
documentación, el interfaz de usuario y los niveles de compatibilidad en cuanto a las versiones del protocolo
OpenFlow.
En la calidad de la documentación se enfocó en la información encontrada y disponible acerca de, los
requerimientos del sistema y sus limitaciones, la instalación del controlador, solución de posibles errores y
1
Big Data [25] : El concepto de Big Data aplica para toda aquella información que no puede ser procesada o analizada utilizando procesos o
herramientas tradicionales. Sin embargo, Big Data no se refiere a alguna cantidad en específico, ya que es usualmente utilizado cuando se habla en
términos de petabytes y exabytes de datos.
2
Protocolo OpenFlow: Es un protocolo de comunicación abierto que permite a un servidor de software determinar el camino de reenvío de paquetes
que deberá seguir a través de la red.

11
fallos y posteriormente su forma de uso. Para la apreciación de estos parámetros acerca del controlador se
observaron videos, tutoriales, blogs de internet referenciados al proceso, además se indagaron foros puesto
que al ser software OpenSource3
debían poseer este tipo de soluciones; este proceso se realizó con el fin de
tener un criterio autónomo y determinar con base en la experiencia cual controlador posee la suficiente
documentación para pensar en la inclusión de él en una topología de red SDN.
En cuanto al interfaz de usuario se evaluó en conjunto con los niveles de compatibilidad del controlador
para la versiones 1.0 y 1.3, el proceso que se desarrolló fue la implementación de topologías de red tanto
real como virtual utilizando las dos versiones disponibles para así poder determinar la adaptabilidad que
tiene el controlador y su correcto funcionamiento, de igual forma se observaron las características de
funcionalidad como lo es la visualización de la topología y las estadísticas en tiempo real del flujo a través
de los puertos del switch.
Para la documentación necesaria acerca del montaje y el uso del controlador, se destinó una parte del trabajo
de grado para enfatizar en este ítem, allí se exponen parámetros óptimos y suficientes para la
implementación del controlador y la forma en que debe usarse para la administración de la red, de igual
forma se documentó la configuración que debe realizarse a los switch HP para el protocolo OpenFlow y las
redes SDN.
Para concluir con la evaluación e implementación del controlador OpenFlow, se dispuso de dos topologías
de red reales, bus y anillo, donde se incluye el controlador para la administración, de esta manera se
determinó el comportamiento de los flujos a través de la red, por consiguiente se implementó un servicio de
red sobre el controlador.
3
Open Source: Open Source o Código Abierto es un término que se aplica al Software distribuido bajo una licencia que le permita al usuario el
acceso al código fuente del Software y además le facilite el estudio y la modificación con toda libertad sin restricciones en el uso, por otro lado
permite redistribuirlo siempre y cuando sea de acuerdo con los términos de la licencia bajo la cual el Software original fue adquirido.

12
2. MARCO TEÓRICO
Con base en las topologías actuales de redes de comunicación y la administración por parte de los
proveedores de servicio, se tiene al alcance una infinidad de aplicaciones y soluciones que se han vuelto
esenciales para la vida cotidiana, por ejemplo, encontramos servicios bancarios tales como transacciones,
retiros de dinero, transferencias, también encontramos servicios para aerolíneas, hospitales, información
gubernamental. Estas redes han llegado a tal punto de necesidad y dependencia que es indispensable el
correcto funcionamiento y la optimización de los procesos para obtener los mayores beneficios posibles,
pero cuando un sistema se torna tan esencial e indispensable comienzan a aparecer problemáticas de la
misma magnitud.
Algunos de los problemas que se observan son el cambio en el patrón del tráfico, es decir, las
comunicaciones actuales se basan en el modelo Cliente/Servidor, el cual consiste en una solicitud por parte
del cliente a un servidor capaz de procesar y entregar una respuesta a la solicitud [4]; con las nuevas
aplicaciones y servicios ofrecidos por múltiples plataformas este modelo ha venido decayendo, ahora las
aplicaciones y las solicitudes hechas por un cliente son procesadas por varias bases de datos y servidores,
esto hace que se desencadene un flujo de conexiones entre los servidores antes de entregar una respuesta
final.
Para atacar las problemáticas actuales se instauran estrategias de calidad tales como ACL, seguridad y QoS4
,
pero al aplicar estas políticas en redes con altísimas conexiones se torna un problema mayor, el sistema
tiende a volverse inmanejable, una alta densidad de terminales y todos con los mismo requerimientos
significa una alta demanda de recursos tecnológicos, incrementando así los costos de manejo de la red.
2.1 REDES SDN
Para ubicar el contexto de las redes actuales se explica cómo es el proceso de un paquete cuando llega a un
switch de red convencional, al ingresar el paquete las reglas de protocolo instauradas en el dispositivo le
indican a este a donde transferirlo, el dispositivo simplemente envía el paquete al mismo destino y por la
misma trayectoria, en una red definida por software un administrador (controlador) de red puede moldear
el tráfico desde una consola centralizada para así indicarle al switch que hacer con el nuevo paquete,
teniendo en cuenta parámetros como prioridad, origen, destino, simplemente con una actualización de la
tablas de flujo instauradas en los dispositivos se tiene el tratamiento correspondiente para el paquete.
Un problema concreto con el cual se lidio y se pensó en una nueva forma de redes fue el crecimiento del
ancho de banda, si antes una red tenía cuatro nodos, ahora existe la posibilidad de que llegue a tener 4000,
además si esta red requiere de 4000 sistemas de configuración el grado de complejidad y el posible error
por tratamiento humano incrementa de una manera exponencial, obligando así a los prestadores de servicios
a buscar estrategias para que la programación no se haga nodo a nodo, si no que por el contrario realizarlo
de manera centralizada.
4
Estas políticas de calidad son necesarias para tener redes de alto desempeño, se hace una breve descripción a continuación:
 ACL: Una Lista de Control de Acceso (ACL), es un concepto de seguridad informática usado para fomentar la separación de privilegios
dentro de la red, las ACL permiten controlar el flujo de tráfico en equipo de red tales como router y switch.
 Seguridad: Se necesita tener esta política en la red puesto que se dispone de servicios que exponen datos personales de usuarios como
transacciones bancarias de alto valor, se enfoca en la protección de la infraestructura y por ende su contenido
 QoS: Las políticas de Calidad de servicios (QoS) hace referencia al rendimiento de la red en aspectos como prestación del servicio de
comunicación, aprovechamiento eficiente del ancho de banda, rendimiento, retrasos en la trasmisión, latencia, Jitter.

13
En respuesta a las nuevas necesidades surge una tecnología que facilita el manejo y la administración sobre
las redes de telecomunicaciones, esta tecnología permitirá tener un control absoluto sobre los dispositivos
que la componen permitiendo así una visualización exacta sobre cada elemento y sus respectivos enlaces,
con base a estas propiedades se podrá manejar el tráfico a través de la red de una manera más eficiente
permitiendo dar prioridad a datos detallados y el camino que deben tomar por los dispositivos.
Figura 1. Arquitectura de red SDN [5]
En esta etapa del surgimiento de las redes SDN y la necesidad de estandarización, empresas pioneras como
Verizon, Deutsche Telekom, Google, Microsoft, Facebook y Yahoo [6] se asocian para crear Open
Networking Fundation (ONF), una organización instaurada con el fin de reglamentar y determinar los
parámetros bajos los cuales las redes SDN funcionan, este reglamentación abarca desde especificaciones
técnicas de los switch hasta el desarrollo de nuevas versiones del protocolo OpenFlow.
Con la centralización del plano de control se pretende obtener de las redes SDN lo siguiente:
 Visión total de la red: Con las redes SDN, se tiene la completa visión de la red, se puede localizar
la conexión de cada dispositivo (host, Switch, router), se conoce previamente la topología y de esta
manera se facilita su administración.
 Alta disponibilidad: Mediante una centralización del control tráfico se puede tener un manejo
optimizado del flujo a través de la red, puesto que es solo un ente que controla la comunicación será
este el que determine la mejora trayectoria para que la información llegue a su destino.
 Optimización hacia fallos: Como se tiene una visualización completa de la red, cuando algún
dispositivo o conexión presenta fallos, este inmediatamente es reconocido por el controlador, el
control aplica las medidas correspondientes a fallos reorganizando las tablas de flujos de los demás
dispositivos, de esta forma toda la red conoce la falla y alterna la vía de comunicación.
 Actualizaciones sin impacto: Cuando sea necesario la actualización del firmware de los
dispositivos de red, al tener la capa de control separada de la de datos, se puede realizar dicha gestión
sin alterar el flujo de los datos ni alguna limitación en la capacidad de la misma.

14
 Administración absoluta por parte propietario: Los propietarios de los sistemas SDN que
soporten OpenFlow, poseen la total administración del equipo sin alguna limitación, es decir, no
tienen alguna atadura con el fabricante, la administración de la red puede realizarse por cualquier
persona con conocimientos suficientes para ello.
2.2 OPENFLOW
Fue un proyecto de investigación en la Universidad de Stanford, Nick McKeown junto con un grupo de
ingenieros, desarrollaron un protocolo de comunicación al cual denominaron OpenFlow [7], este protocolo
les permitía tener acceso, mediante software, a los flujos de datos en los componentes de red (switch, router,
AP), los ingenieros encargados del protocolo pudieron tener acceso a las tablas de flujo y también a las
reglas encargadas de el reenvío de paquetes en los switch. Con base en esta información se logró analizar y
cambiar dicho direccionamiento dando prioridad a información que lo requiera, de esta manera se
optimizaría el tráfico y se evoluciona en tanto a las velocidades de procesamiento de paquetes y
encolamiento de los dispositivos de red.
La forma de uso del protocolo es muy sencilla, los switch poseen tablas de flujos que le indican al dispositivo
que acciones realizar cuando llega un paquete, se utilizan aplicaciones remotas para acceder a dichas tablas
y modificar las reglas de los componentes de red, en palabras sencillas un administrador de red puede
modificar, quitar, añadir y gestionar las reglas. En condiciones normales, sin el protocolo OpenFlow, cuando
llega un paquete al switch este evalúa el destino y lo reenvía según la información contenida en su tabla de
flujo, todo los paquetes son dirigidos hacia el mismo nodo, encaminados por la misma ruta y tratados de la
misma manera, este proceso hace que los operadores de red carezcan de control para agilizar el proceso.
Figura 2. Esquema de funcionamiento del protocolo OpenFlow para OpenFlow Switch [8]

15
Cuando se tiene instalado el protocolo OpenFlow se puede determinar prioridad y enrutamiento de los
paquetes en los switch, haciendo de esta una red más flexible y optimizada para ciertos propósitos, por
ejemplo, se puede determinar prioridad a un video o una comunicación en streaming de esta manera se evita
la interrupción del servicio. Por otro lado, y una de las ventajas del protocolo, es la determinación de normas
para gestionar el tráfico, por ejemplo, cuando en una red tiene algún indicio de un terminal sospechoso de
virus, puede establecerse una norma para el tráfico a partir del origen y destino del paquete y proceder a
bloquear todos los flujos en la red que se dirijan o salgan de él.
El protocolo OpenFlow tiene dos funciones principales, la primera consiste en poder definir el flujo de
paquetes, la segunda función facilita el camino que deben tomar los paquetes a través de la red, estas
configuraciones pueden hacerse gracias al protocolo, con la ventaja de hacer en tiempo real sin la necesidad
de interrupción en el servicio. Basándose en estas características, el protocolo plantea mejoramientos
notables en cuanto al ancho de banda usado, la latencia presente en el sistema y la disminución de saltos
para el consumo energético [7].
Esta tecnología consta de tres componentes principales:
 Switch de dos tipos, OpenFlow-only y OpenFlow Hibridos.
 Controlador OpenFlow.
 Protocolo de comunicación para redes SDN capaz de establecer conexión de manera segura a los
Switch, OpenFlow.
2.3 TABLAS DE FLUJO (Flow-Table) VERSION 1.0 [8]
Los Switch OpenFlow constan de tablas de flujo para el desempeño de sus funciones, las tablas de flujo
ejecutan las funciones de reenvió y redireccionamiento, además poseen un canal seguro para la
comunicación con el controlador, esta conexión se realiza ya que el controlador es el encargado de gestionar
el dispositivo de red y lo hace con el protocolo OpenFlow.
Las tablas de flujo contienen tres campos principales, el primer campo llamado “Header Fields” contiene
un conjunto de entradas que son cabeceras del paquete las cuales poseen información con direcciones IP de
origen y de destino, información sobre Vlan (ID y Priority), puerto de ingreso, protocolos de comunicación
(TCP/UDP), cada campo del “Header Fields” se explicará a continuación, un segundo campo “Counters”
contiene información de conteo, este conteo se realiza por tabla, por flujo, por puerto y por cola, el tercer
campo “Actions” es donde se encuentra la información de qué hacer con el paquete de entrada, es decir, que
acción de reenvío debe ejecutar y por cual puerto, con los campos anteriores se evalúa la información de
paquete y con base en ello el switch toma una acción.
Todos los paquetes son procesados por el switch y comparados contra la tabla de flujo presentes en ellos,
cuando un paquete ingresa se toma la acción definida por la tabla, las acciones pueden ser hacer el reenvío
del paquete o sacar el paquete por un puerto especifico, de la misma forma cuando ingresa un nuevo paquete
el controlador este es el encargado de actualizar las tablas de los switch para que conozcan e identifiquen el
nuevo paquete, de esta forma los dispositivos sabrán qué hacer con él.
Header Fields Counter Actions
Figura 3. Componentes de una tabla de flujo de un switch

16
 Header Fields
El protocolo OpenFlow toma los flujos de entrada (flows-entry) para detectar los paquetes, cada entrada
contiene información específica con valores detallados como se ilustran en la figura 4.
Ingress
Port
Ether
Source
Ether
Dst
Ether
type
VLAN
id
VLAN
priority
IP
source
IP
dst
IP
Procol
IP
ToS
bits
TCP/
UDP
Src
port
TCP/
UDP
Dst
Port
Figura 4. Campos de información encontrados en “Header Fields”
 Counters
Es el campo encargado de actualizar la información, el proceso lo hace por tabla, por flujo, por puerto,
además realiza un conteo detallado sobre paquetes recibidos y enviados. En la figura 5, se encuentra los
conteos que realiza el campo por cada aspecto mencionado.
Counter Bits
Per table
Active Entries 32
Packets Lookups 64
Packets Matches 64
Per Flow
Received Packets 64
Received Bytes 64
Duration (seconds) 32
Duration (nanoseconds) 32
Per Port
Received Packets 64
Transmitted Packets 64
Received Bytes 64
Transmitted Packets 64
Receive Drops 64
Transmit Packets 64
Receive Errors 64
Transmit Errors 64
Receive Frame Alignment Errors 64
Receive Overrum Errors 64
Receive CRC Errors 64
Collisions 64
Per Queue

17
Transmit Packets 64
Transmit Bytes 64
Transmit Overrun Errors 64
Figura 5. Conteos que realiza el campo “Counter” y el número de bits usado
 Actions
También conocido como “Instructions”, con los valores de este campo el Switch sabe qué hacer con el flujo
de entrada, entre las acciones se encuentra principalmente el reenvío pero esta acción posee varias
naturalidades que pueden ser:
1. All: Reenvío por todos los puertos.
2. Controller: Encapsula y reenvía el paquete de un flujo al controlador, se usa normalmente para el primer
paquete de un flujo nuevo, esto con el fin de que el controlador determine si se agrega o no el flujo a las
tablas de flujo.
3. Table: Realiza la operación según su tabla (para paquetes de salida únicamente).
4. In_port: Reenvia el paquete por el puerto de entrada.
2.4.TABLAS DE FLUJO (Flow-Table) VERSION 1.3
Para la descripción de las tablas de flujo en la versión 1.3 de OpenFlow, el proceso en el cual los flujos
entrantes hacen Matching5
con las tablas es diferentes en comparación con la versión 1.0, cuando un paquete
llega al switch es comparado con una tabla de flujo única y se ejecuta la acción correspondiente a la tabla,
mientras que en el protocolo en su versión 1.3 el paquete realiza el proceso de Matching por todas las tablas
esto es con el fin de incrementar la precesión en la acción a tomar, al pasar por las diferentes tablas de flujo
se le conoce como Pipeline Processing [9] [10].
Pipeline Processing es un proceso en el cual los flujo de entrada pasan por múltiples tablas de flujo
contenidas en los switch, de esta manera se precisa las acciones que deben tomar los paquetes en la red, en
la Figura 3. se describe el funcionamiento del Pipeling Processing cuando ingresa un paquete al switch y su
proceso a través de las tablas de flujo, mientras que en la Figura 6. se observa el proceso que sigue el paquete
en cada tabla de flujo comenzando desde la tabla 0.
5
Matching: En SDN es el proceso por el cual los flujos de entrada con comparados con las tablas de flujo de los switches.

18
Figura 6. Paquetes de entrada comparados contra las tablas de flujo en el pipeline
Figura 7. Proceso del paquete por tabla de flujo
En la figura 7. se aprecia el orden que tiene la tabla de flujo para procesar el paquete y se describe a
continuación:
1. El paquete es comparado con la primera tabla de flujo, el orden se define desde la tabla de flujo 0
hasta la N.
2. Se aplican las instrucciones para el paquete las cuales varían desde la salida por un puerto específico
hasta la sucesión del paquete a otra tabla.
3. Envío de los datos y la acción hacia la siguiente tabla.
Las tablas de flujo de la versión 1.3 del protocolo OpenFlow presenta ciertas adiciones en los flujos entrantes
en comparación con la versión 1.0, en esta versión se agregan los campos Priority, Timeouts y Cookie, en
la figura 8 se observan los componentes de los flujos entrantes y posteriormente se explicará el
funcionamiento de cada uno.
Match Fields Priority Counters Instructions Timeouts Cookie
Figura 8. Componentes principales de un flujo de entrada in una tabla de flujo

19
 Match Fieds: Son los encabezados del paquete, al igual que el protocolo OpenFlow en
la versión 1.0 presenta los mismos encabezados.
Ingress
Port
Ether
Source
Ether
Dst
Ether
type
VLAN
id
VLAN
priority
IP
source
IP
dst
IP
Procol
IP
ToS
bits
TCP/
UDP
Src
port
TCP/
UDP
Dst
Port
Figura 9. Cabeceras de paquetes OpenFlow
 Priority: Este campo se utiliza para indicarle al sistema, a que tabla de flujo debe
enviarse específicamente después de ingresar en la tabla 0. En la figura 10. se observa la
comparación del paquete con las tablas de flujo y que acciones ejecuta.
Figura 10. Proceso de comparación entre el flujo de entrada y las tablas de flujo
Cuando un flujo de entrada no realizar el proceso de comparación con una tabla del switch se le conoce
como Table-miss, este suceso se presenta principalmente cuando hay el ingreso de nuevos flujos, aquí el
switch envía la solicitud al controlador para saber qué hacer con el paquete, el controlador responde con
indicaciones para el nuevo flujo, el switch actualiza sus tablas de flujo y posteriormente ejecuta la acción
dada por el controlador.
 Counters: Este campo es destinado para la información estadística de los flujos de
entrada, en la figura 11 se muestra una lista de conteos que realiza el sistema

20
Counter Bits
Per Flow Table
Reference count (active entries) 32 Requiered
Packet Lookups 64 Optional
Packet Lookups 64 Optional
Per Flow Entry
Received Packets 64 Optional
Received Bytes 64 Optional
Duration (seconds) 32 Requiered
Duration (nanoseconds) 32 Optional
Per Flow Port
Received Packets 64 Requiered
Transmitted Packets 64 Requiered
Received Bytes 64 Optional
Transmitted Bytes 64 Optional
Receive Drops 64 Optional
Transmit Drops 64 Optional
Receive Errors 64 Optional
Transmit Errors 64 Optional
Receive Frame Alignment Errors 64 Optional
Receive Overrun Errors 64 Optional
Receive CRC Errors 64 Optional
Collisions 64 Optional
Per Queue
Transmit Packets 64 Requiered
Transmit Bytes 64 Optional
Transmit Overrun Errors 64 Optional
Per Group
Reference Count (flow entries) 32 Optional
Packet Count 64 Optional
Byte Count 64 Optional
Per Group Bucket
Packet Count 64 Optional
Byte Count 64 Optional
Per Group Bucket

21
Flow Count 32 Optional
Input Packet Count 64 Optional
Input Byte Count 64 Optional
Per Meter Band
In Band Packet Count 64 Optional
In Band Byte Count 64 Optional
Figura 11. Conteos realizados por el protocolo versión 1.3
 Instructions: Cada flujo de entrada contiene un conjunto de instrucciones las cuales son
ejecutadas cuando se compara el paquete con las tablas de flujo, mediante este campo del
protocolo se determina el proceso que debe realizarse al paquete bien sea modificación
del contenido de instructions o el procesamiento por el pipeline.
 Timeouts: Este campo es el encargado de determinar el tiempo máximo que tiene el
switch para descartar el flujo.
 Cookie: Este campo habilita al controlador para realizar una categorización del paquete
de entrada más eficiente en vez de realizar la clasificación siguiendo todas las tablas de
flujo del switch.
2.5.CONTROLADORES SDN
El controlador es el núcleo y alma fundamental de las redes, este es capaz de administrar y dirigir toda la
topología de red. Algunas de las funciones del controlador son la de centralizar toda la comunicaciones que
pasa a través de los dispositivos de red, también tiene una visualización total de la red, el controlador es
capaz de determinar cómo los flujos van a comportarse dentro de la red, en resumen los dispositivos que
componen la red SDN deben reportarse al controlador cada vez que estos lo ameriten, estos casos suelen ser
ingreso de nuevos flujos por la red, el dispositivo de red no tiene definido qué hacer con el paquete y por
ende pregunta al controlador que hacer con él, el control da las indicaciones a los dispositivos mediante la
actualización de las tablas de flujo que cada elemento posee y de esta forma realizar la acción
correspondiente.
En la actualidad existen varias soluciones de controladores, entre los cuales se encuentran POX, Beacon,
Floodlight, SDN VAN HP, estos controladores presentan varias características y diferencias, donde la más
notoria diferencia es el lenguaje de programación con el cual fueron desarrollados, a continuación se
presenta una breve descripción de los controladores y sus características.
2.5.1. POX
Es un controlado desarrollado para cubrir las necesidades de redes SDN usando lenguaje de programación
de Python, sirve para sistemas operativos como Windows, Mac OS y Linux. Entre las características más
relevantes del controlador se tiene:

22
 Lenguaje de OpenFlow basado en Python
 Detección de topologías de red y selección de rutas de acceso
 Interfaz gráfica para el usuario y componentes de visualización
 Desarrollado para el manejo del protocolo OpenFlow en versión 1.0
2.5.2. BEACON
Es un controlador con lenguaje de programación en Java, soporta operaciones basadas en eventos y threads,
características de desarrollo optimas, presenta interfaz de usuario y visualización completa de la red, por
otro lado al ser el código basado en Java tiene amplias características para ser modificado, esta disposición
de poder manipular el código es una de las principales características de los controladores puesto que son
todos OpenSource6
(código abierto), entre las características más relevantes se encuentran:
 Actualmente es capaz de manejar 100 switch virtuales y 20 switch reales.
 Por su lenguaje de programación de java puede ejecutarse en muchas plataformas, desde los
servidores Linux hasta teléfonos Android.
 Interfaz de usuario personalizado
 Fácil de descargar y correr, al ejecutar Java y Eclipse simplifican el desarrollo y la depuración de
sus aplicaciones.
 Rápido debido a su característica de multiproceso
2.5.3. FLOODLIGHT
Controlador capaz de manejar switch tanto reales como virtuales, basado en lenguaje de programación Java,
dispone de una serie de funcionalidades y capacidades para el manejo de redes SDN, el controlador está
previsto para el manejo de paquetes y la instalación de entradas en las tablas de flujo, desarrollado por David
Erickson. Este software presenta las siguientes características de manejo en su entorno:
 Interfaz UI amigable y fácil de observar parámetros detallados.
 Fácil instalación y uso del mismo
2.5.4. SDN VAN CONTROLLER
Controlador desarrollado por el propio fabricante de dispositivos de red HP, es capaz de manejar switch
tanto reales como virtuales, en su versión de prueba puede manejar hasta 50 nodos con una amplia gama de
posibilidades de control e interacción con las mismas, en las características del controlador se encuentra:
 Interfaces abiertas y programables
6
OpenSource: Es la expresión con la que se conoce al software distribuido y desarrollado libremente. Se focaliza más en los beneficios prácticos
(acceso al código fuente) que en cuestiones éticas o de libertad que tanto se destacan en el software libre

23
 Control flexible y centralizado
 Alta disponibilidad y escalabilidad
 Posee robustez en su seguridad
 Puede manejar el protocolo OpenFlow en sus versiones 1.0 y 1.3
En lo anterior se mostraron algunas características que poseen los controladores y también una breve
explicación de cómo funcionan dentro de las redes SDN.
Para el uso del controlador se presentan dos topologías de red, la primera topología se conoce como control
centralizado, Figura 13, el controlador es conectado a un switch determinado y desde allí tiene visualización
completa de la red, puede enviar instrucciones a cualquier componente y tiene comunicación sin ningún
inconveniente con cualquier elemento, dentro de las ventajas se destaca el uso de un solo software para la
administración de la red, simplicidad sin alterar desempeño. Otra localización que se le puede dar al
controlador es la conocida como controlador distribuido, Figura 12, en esta topología de red existen varios
controladores ubicados a lo largo de los dispositivos de la red, principalmente se usa este tipo de topologías
cuando se tiene redes demasiado extensas, es decir cuando un controlador aun con sus ventajas de red SDN
queda corto en la administración, cabe resaltar que es una red bastante extensa, oscilando entre las 70 y 140
switch.
Cuando se implementa alguna de las topologías para el controlador nombradas anteriormente, es necesario
introducir el tipo de enrutamiento que el controlador asignará, existen dos posibilidades entre las cuales se
encuentra el enrutamiento de flujo y el enrutamiento de agregación, a continuación se hace una breve
descripción de su funcionamiento.
Basado en el flujo
 Cada flujo individual es generado en el controlador
 Debe haber una coincidencia exacta en las entradas de flujo para el matching de los paquetes
 Las tablas de flujo contienen una entrada de flujo por tabla
 Ideal para un control detallado
Figura 13. Control centralizado Figura 12. Control distribuido

24
Agregación
 Una entrada abarca una gran cantidad de flujo, coincidencias menores en el matching para los flujo
de entrada.
 La tabla de flujo contiene una entrada una entrada por cada categoría de flujos.
 Ideal para la implementación en un entorno donde exista gran cantidad de flujos
Además el controlador presenta dos características en su comportamiento, las cuales pueden denominarse
controlador reactivo y controlador proactivo, la forma de uso de estas opciones dependerá principalmente
de las necesidades del cliente, para describir estos posibles distribuciones del controlador se explican a
continuación algunas de sus funcionalidades:
Control Reactivo
 Uso eficiente de la tabla de flujo, se adapta a las necesidades de la red, cuando no se use una tabla
de flujo por un tiempo determinado esta pasa a ser reiniciada y dispuesta para el manejo de nuevos
paquetes de entrada.
 Cada flujo incide en un tiempo determinado para su configuración, tiempo que tarda el controlador
en actualizar las tablas de flujo.
 Si llegase haber una desconexión por parte del controlador, el switch entra en una capacidad
limitada, quedándose con las actualización realizadas antes de la caída.
Control Proactivo
 Previa configuración de las tablas de flujo, al saber qué tipo de paquetes y como deben ser tratados
el controlador puede dar instrucciones previas para su manejo.
 No existe pérdida de tiempo en la configuración por parte del controlador, acción previamente
realizada.
 Cuando se presenta una desconexión del controlador el tráfico no se ve interrumpido, pero se resalta
que este debe conocerse previamente con exactitud.
Teniendo presente las características tanto de desarrollo y configuración de los controladores, y las
posibilidades de uso dentro de la red, se escoge un controlador que desempeñe la funcionalidad exigida,
además se tienen también en cuenta los siguientes parámetros para su escogencia:
1. Documentación suficiente para el desarrollo y utilización.
2. Los lenguajes de desarrollo de los controladores, este ítem hace referencia si el código con el cual
fue construido afecta o no el desempeño del mismo.
3. Facilidad de uso de la aplicación y características adicionales, para tener una total administración
de la red una amigable interfaz gráfica y un entorno visual bastante amplio son fundamentales para
la elección.
4. Adaptabilidad a los firmwares del equipo por parte del controlador. Este ítem hace referencia a las
capacidades de funcionamiento con los protocolos 1.0 y 1.3 que el protocolo OpenFlow.
5. Desempeño como controlador.

25
2.5.5. COMUNICACIÓN DEL PROTOCOLO OPENFLOW VERSIÓN 1.0 Y 1.3
El protocolo OpenFlow tiene tres tipos de mensajes denominados controller-to-switch, asynchronous, y
symmetric [8], cada uno posee subtipos de mensaje.
El controller-to-switch son mensajes iniciados por el controlador, este tipo de mensajes es para verificar el
estado del switch y para su configuración; el tipo de mensaje asynchronous, es un tipo de mensaje iniciado
por el switch, este es utilizado por el dispositivo para actualizar al control de nuevos eventos de red, cambios
de estado del Switch y notificación de errores, los eventos de red pueden ser conexión de nuevos terminales,
encuentro de nuevos flujos, y peticiones al controlador, por último se encuentra el tipo de mensaje
symmetric, este tipo de mensajes son iniciados tanto por el Switch como por él controlador, se utiliza para
la comunicación cuando un Switch se vincula a la red el controlador responde.
A continuación se mostrará los submensajes de cada tipo conocidos anteriormente:
1. Controller-to-Switch: Son mensajes iniciados por el controlador, este tipo de mensaje es utilizado
para verificar el estado del switch y también para configurarlo, puede o no tener una respuesta del
switch.
 Features: Se usa para el establecimiento de la conexión con el Switch mediante TLS7
,
con esta solicitud el controlador desea conocer las características del Switch, este
responde al controlado con una seria de capacidades específicas soportadas por este.
 Configuration: El controlador es capaz de establecer y preguntar los parámetros de
configuración de Switch, este a su vez solo responde dicha solicitud a controlador.
 Modify-State: Son mensajes enviados por el controlador para gestionar el Switch, el
propósito principal de este es agregar, quitar o modificar los flujos en la tabla de flujo del
Switch y establecer las propiedades del puerto.
 Read-State: Este mensaje es utilizado por el controlador para recolectar estadísticas del
Switch acerca de las tablas de flujo, puertos y flujo de entrada.
 Send-Packet: Es usado por el controlador para indicarle Switch que saque por un puerto
específico determinado paquete.
 Barrier: Este es un mensaje que tiene tanto petición como respuesta, es usado por el
controlador para asegurarse que las dependencias de un mensaje se han cumplido o para
recibir notificaciones de operaciones terminadas.
 Role-Request: Este mensaje es usado por el controlador para establecer el canal
OpenFlow o para preguntar al switch por él, usualmente se usa cuando al switch se le
conectan varios controladores.
2. Asynchronous: Es un tipo de mensaje utilizado por el switch para notificar al controlador de eventos
nuevos de red, cambios de estado y notificación de errores. Los eventos de red involucran los casos
de nuevas conexiones por parte de terminales y encuentro de nuevos flujos.
7
TLS: El protocolo TLS (Transport Layer Security) es una evolución de protocolo SSL (Secure Sockets Layer), es un protocolo mediante el cual
se establece una conexión segura por medio de un canal cifrado entre el cliente y servidor, en este caso se establece una conexión entre switch
(cliente) y Controlador (servidor) basándose en este protocolo, se encuentra en la referencia RFC 2246.

26
 Packet-in: Es un paquete enviado por el Switch hacia el controlador, lo hace cuando
entra un paquete nuevo que al ser comparado con la tabla de flujo no sabe qué hacer con
él, el controlador analiza el paquete y responde con un Packet-out.
 Flow-Removed: Se envía cuando se presenta una inactividad de un flujo, o cuando se
vencen los parámetros de TTL8
, este puede ser enviado por el controlador o por el Switch.
 Port-Status: El Switch es el encargado de enviar este mensaje al controlador y se utiliza
para cuando la configuración de un puerto cambia.
 Error: El Switch notifica al controlador cuando existen problemas con esto mensajes.
3. Symmetric: Este tipo de mensajes son iniciados por el switch y por el controlador, el mensaje es
utilizado para la comunicación cuando un switch se vincula a la red, se realiza un intercambio de
mensajes donde se determinan parámetros funcionales entre los dispositivos.
 Hello: Son mensajes intercambiados entre el controlador y el Switch, se utilizan para
establecer la conexión entre los dos.
 Echo: Es un mensaje que posee tanto petición como respuesta y se utiliza para verificar
parámetros de la red tales como latencia, ancho de banda y determinar el estado activo
del dispositivo.
 Vendor: Permite dar funcionalidades extra al Switch, este mensaje se usa principalmente
para futuras versiones de OpenFlow.
3. ESPECIFICACIONES
Las especificaciones alcanzadas por el trabajo se desglosan de la siguiente manera, en primera instancia se
evaluó el proceso correspondiente a la calidad de documentación la cual hace referencia a la adquisición e
instalación del controlador, forma de uso y limitaciones. En segunda instancia se procede a realizar
topologías de red utilizando el software Mininet, por otra parte se usa el software Cbench que permite
realizar una serie de evaluaciones de desempeño en cuanto a la capacidad de procesamiento del controlador
frente a las peticiones realizadas por un número determinado de switch.
Para concluir con las especificaciones realizadas se creó una red real SDN administrada por el controlador,
se desarrolló una topología en el laboratorio usando switch del fabricante HP con referencias 3500yl y 3800,
estos switches fueron especialmente creados para el manejo de redes SDN y el protocolo OpenFlow. El
objetivo de esta implementación era observar el funcionamiento del controlador y poder comprobar las
ventajas de esta nueva tecnología.
El proceso anteriormente mencionado se describe a profundidad en los siguientes numerales:
1. Para dar un veredicto sobre la calidad de documentación se procede a realizar una exhaustiva búsqueda
sobre cada aspecto mencionado anteriormente, se enfoca principalmente en la forma de uso y posibles
fallos encontrados a la hora de correr el controlador.
8
TTL: Time to live, es utilizado en el paquete IP de manera que los routers puedan analizarlo y actuar según su contenido. Si un router recibe un
paquete con un TTL igual a uno o cero, no lo envía a través de sus puertos, si no que notifica vía ICMP a la dirección IP origen que el destino se
encuentra “inaccesible o inalcanzable” y procede a descartar dicho paquete.

27
2. Mediante una correcta instalación de los controladores, se verificó la funcionalidad de los mismos y su
operación, esto incluye su despliegue en una topología de red real montada en el laboratorio y una
topología de red emulada. Se configuraron las topologías de red tales que fueran las mismas en el
entorno real como en el virtual con el fin de tener una comparación en cuanto al desempeño a priori9
(virtual), y un desempeño a posteriori10
(real).
3. En la UI (User Interface) de los controladores, se pudo determinar visualmente la topología de red en la
cual se encontraba, también se observó el flujo de paquetes en tiempo real haciendo referencia a su
puerto, su dirección IP, la prioridad y el número de paquetes tanto recibidos como enviados.
4. Con el analizador de protocolos Wireshark se pudo ver el intercambio de mensajes en los diferentes
escenarios que se plantearon y que se profundizarán más adelante, esto con fin de verificar el
cumplimiento de la especificaciones del protocolo OpenFlow 1.0 y 1.3 por parte de los controladores.
5. Con el equipo disponible en el laboratorio y en conjunto con HP (Hewlett Packard), se desplegó una
red que satisface la topología SDN, en el proceso de la configuración de los equipos se asimilaron las
líneas de condigo que debían realizarse para la instauración tanto de controlador como la adición de los
terminales al switch.
6. Por culminar en los aspectos alcanzados, se realizó un manual (Tutorial) para la creación de una red
SDN y la inclusión del controlador, en la guía se explica detalladamente las línea de código usadas para
la configuración de los switches y posibles inconvenientes encontrados, por otra parte se muestra como
debe ser la adición del controlador y algunos requerimientos y limitaciones.
4. DESARROLLOS
Para iniciar con el proceso se escogieron cuatro controladores de los cuales tres de ellos (POX, Beacon,
Floodlight) se eligieron con base a un artículo que realiza una evaluación similar, el artículo se llama
“Evaluation of OpenFlow Controllers” [11], el cuarto controlador se escoge ya que es un controlador
desarrollado por los mismo fabricantes de switch Hewlett Packard (HP VAN ).
Para la evaluación del controlador en las redes SDN, se tuvo la necesidad de implementar programas
específicos para este tipo de redes, estos programas se encargan de probar la eficiencia en cuanto al
procesamiento de packet_in y packet_out11
, el encargado de realizar este procedimiento se denomina Cbench
[12], más adelante se da una explicación a fondo sobre su forma de uso y operación. Por otro lado se tiene
un software especialmente desarrollado para probar variadas topologías de red SDN con diferentes
elementos, incluye la posibilidad de adicionar el controlador y ser este el encargado de la administración
virtual, este software se denomina Mininet [13], además se desarrolló un código de programación en
lenguaje Python (Ver anexo 1) para una topología en semejanza con la red real montada.
Para la ejecución de los controladores, después de haber sido instalados siguiendo las indicaciones del
Anexo 2, deben ejecutarse los siguientes comandos:
9
A priori: Término de la filosofía idealista que designa un saber obtenido antes e independientemente de la experiencia, inherente desde un principio
a la conciencia, a diferencia de a posteriori, o saber obtenido de la experiencia y como resultado de la misma.
10
A posteriori: Término que, a diferencia de a priori, designa el saber obtenido de la experiencia.
11
Packet_in/Packet_out: Son mensajes del protocolo OpenFlow que son usados para la notificaciones del switchal controlador la llegada de un
nuevo flujo (packet_in), el controlador se encarga de procesarlo e indicarle al switch que debe hacerse con este flujo (packet_out)

28
 Floodlight: Se abre un terminal (Crtl+Alt+t), allí se ejecuta el comando “$ cd flloodlight” y luego
“$ java –jar target/floodlight.jar”. De esta manera el controlador iniciara y estará escuchando las
peticiones por el puerto 6633.
 Beacon: En la ventana principal de eclipse se debe seguir esta ruta, Debug – Debug Preferences –
OSGI – Beacon y click en Debug.
 POX: Se abre un terminal (Crtl+Alt+t), allí se ejecuta el comando “$ cd pox” y luego “$./pox.py
samples.pretty_log forwarding.l2_learning”.
 SDN VAN HP: Este controlador basta con ingresar en el navegador la siguiente dirección
https://controller_ip_address:8443/sdn/ui/, y se reemplaza la dirección IP por la del equipo donde
se corra.
4.1. SIMULADORES
4.1.1. MININET
.
Este software permite la emulación de una topología de red (host, switch, controlador OpenFlow) mediante
la ejecución de líneas de comando en un OS12
Linux, la gran ventaja que posee el simulador es que brinda
la conexión de cada elemento de red e incorpora el controlador para la administración de la misma, en una
primera impresión el simulador de red Mininet permite la conexión virtual del controlador.
El uso de Mininet en esta etapa de evaluación fue una de las más importantes para el proyecto, lo que se
obtuvo con él programa fue la comprobación de que el controlador funcionó y que la instalación fue correcta,
para ello se generó la topología de la Figura 14, y se vinculó el controlador obteniendo así la visualización
por parte de la UI de la red y el reconocimiento del switch.
4.1.1.1. RECONOCIMIENTO DE TOPOLOGIA DE MININET POR LOS
CONTROLADORES
12
OS: Operating System o Sistema Operativo
Controlador
Switch
Host 1
Host 2
Figura 14. Topología de red implementada en la comprobación del controlador

29
Para la ejecución de Mininet y la inclusión del controlador tuvo que escribirse la siguiente línea de código
en un terminal:
 $ sudo mn –controller=remote,ip=”ip_del_host_del_controlador”
4.1.1.1.1. RECONOCIMIENTO DE TOPOLOGIA POR CONTROLADOR
FLOODLIGHT E IPERF
Figura 15. Topología dada por floodlight

30
Figura 16. Ancho de banda entre los terminales
4.1.1.1.2. RECONOCIMIENTO DE TOPOLOGIA POR CONTROLADOR BEACON E
IPERF
Figura 17. Topología dada por Beacon

31
Figura 18. Ancho de banda entre los terminales con controlador Beacon
4.1.1.1.3. RECONOCIMIENTO DE TOPOLOGIA POR CONTROLADOR POX E IPERF
Figura 19. Reconocimiento de switch por POX

32
Figura 20. Ancho de banda dado por POX
4.1.1.1.4. RECONOCIMIENTO DE TOPOLOGIA POR CONTROLADOR SDN VAN HP
E IPERF
Figura 21. Detección de switch por SDN VAN HP

33
Figura 22. Ancho de banda dado por SDN VAN HP
4.1.1.1.5. INTERCAMBIO DE MENSAJES ENTRE EL SWITCH Y EL
CONTROLADOR
Figura 23. Intercambio de mensajes entre el switch y el controlado

34
Con base a las posibilidades que ofrece Mininet y especialmente en la manipulación de terminales, se
procedió a emitir comandos tales como ping, pingall, iperf entre los terminales de la red para observar la
comunicación entre ellos y en conjunto con WireShark verificar los mensajes del protocolo OpenFlow.
 Ping: Se pretende emitir un ping desde un origen hacia un destino con el fin de comprobar la
conexión correcta de la red y el alcance, esta prueba permite identificar, mediante el uso de
WireShark, que el controlador y lo terminales que intervienen en la ejecución de la acción realizan
su proceso de comunicación correcto y que el protocolo OpenFlow realiza el intercambio de tramas
correspondientes.
 Ping all: Esta prueba permite realizar ping desde un terminal hacia todos los de la red, de esta forma
se identifica a conexión total en la red y su visualización de todos los terminales.
 Iperf13
: Permite ejecutar un servidor iperf en un host y un cliente iperf en otro host, esto con el fin
de caracterizar el ancho de banda entre los dos.
4.1.1.2. TOPOLOGIA BUS, 3 SWITCHES Y 3 HOST
Para lograr esta topología de red en Mininet debe escribirse el siguiente comando:
 $ sudo mn –topo linear,3 –controller=remote,ip=”Ip_del_host_del_controlador”
4.1.1.2.1. TOPOLOGIA BUS, CONTROLADOR FLOODLIGHT (VIRTUAL)
Figura 24. Topología lineal en MIninet dada por floodlight
13
Iperf: Es una herramienta de análisis de uso común que puede crear flujos de datos TCP y UDP y medir el rendimiento de la red. permite al
usuario ajustar los distintos parámetros que pueden usarse para probar una red, o alternativamente para optimizar o ajustar la red. Iperf tiene una
funcionalidad de cliente y servidor, y puede medir el rendimiento entre los dos extremos, ya sea unidireccionalmente o bidireccionalmente.

35
4.1.1.2.2. TOPOLOGIA BUS, CONTROLADOR BEACON (VIRTUAL)
Figura 25. Dispositivos Vistos por beacon en topología bus
4.1.1.2.3. TOPOLOGIA BUS, CONTROLADOR POX (VIRTUAL)
Figura 26. Conexión switch virtuales en topología bus Mininet

36
4.1.1.3. TOPOLOGIA EN ANILLO, 3 SWITCH Y 3 HOST
Como esta topología de red es personalizada, debe ejecutarse de la siguiente forma, teniendo en cuenta que
Mininet guardas las topologías personalizadas en una carpeta llamada custom.
$ sudo mn –custom /home/carlos/mininet/custom/mytopo1.py –topo mytopo –
controller=remote,ip=”Ip_del_host_del_controlador”.
4.1.1.3.1. TOPOLOGIA EN ANILLO CONTROLADOR FLOODLIGHT
Figura 27. Topología Anillo Mininet, floodlight

37
4.1.1.3.2. TOPOLOGIA EN ANILLO CONTROLADOR BEACON
Figura 28. Switch vistos por Beacon en Topología anillo en Mininet

38
4.1.1.3.3. TOPOLOGIA EN ANILLO CONTROLADOR POX
Figura 29. Switch en topología anillo identificados por el controlador
4.1.1.3.4. TOPOLOGIA EN ANILLO CONTROLADOR SDN VAN HP
Figura 30. Topología en anillo dada por Mininet, controlador SDN VAN H

39
4.1.1. CBENCH BENCHMARK TOOL
Para la evaluación del controlador en cuanto a su aspecto de procesamiento de peticiones nuevas por parte
de los switch, se usó un Benchmark tool llamado Cbench, este software permite emular un número
determinado de host (terminales) conectados a un número N switch y evaluar los parámetros de troughput
del controlador.
El funcionamiento de Cbench es el siguiente, el simulador crea N switch y conecta un número determinado
de host, luego crea N conexiones hacia el controlador, de esta manera se genera una topología como la vista
en la figura 25.
Para evaluar el Troughput se determinará la cantidad de transacciones por segundo que el controlador pueda
manejar, el sistema puede medir este parámetro de dos maneras diferentes, la primera en bits por segundo
(bit/s o bps) y la segunda en paquetes por segundo.
Para la ejecución de Cbench, una vez descargado (Ver Anexo 3), se escribe en una terminal el siguiente
código:
- $ cd openflow
- $ cd oflops
- $ cd cbench
- $ ./cbench -c localhost -p 6633 -m 10000 -l 10 -s 16 -M 1000 –t
Donde –s representa el número de switch a emular, y –M representa la cantidad de Host por switch.
En la evaluación que se realizó a los controladores se usó el siguiente comando, donde se varió el número
de Host por switch desde 100 k hasta 10 M, en la sección de análisis de resultados se expone lo obtenido.
 ./cbench -c localhost -p 6633 -m 10000 -l 10 -s 16 –M 10000000 –t
Figura 25. Topología generada por Cbench. El número de switch a emular será un parámetro dado por el usuario, de igual forma
la cantidad de host conectados a los switch. [18]

40
4.2.TOPOLOGIA DE RED CREADA EN EL LABORATORIO
La máquina donde se encuentran los controladores POX, Beacon y Floodlight tiene las características que
se observan en la Figura 31.
Figura 31. Características del equipo donde se encuentran los controladores

41
4.2.1. TOPOLOGIA DE RED BUS
La figura 32 representa una de las topologías construidas en el laboratorio, usando el equipo disponible que
consta de dos switches HP E3800 y un HP 3500yl, y se incluyen los controladores para la administración
de la red. A continuación se muestra como fue el intercambio de mensajes entre los switches y el
controlador:
La configuración que tuvo que hacerse a los switch se encuentra en el Anexo 4 y se realizó con ayuda del
manual dado por el fabricante HP “HP OpenFlow Switches”.
Para tener en contraste los resultados obtenidos en la simulación con lo obtenido en la red real, se realizó la
prueba de conectividad entre el Host 1, a los Host 2 y Host 3, en la sección de análisis de resultados se
expone cuáles fueron los datos obtenidos en cuanto el tiempo mínimo, máximo y promedio que tardaba en
ir y volver a su destino, y el número de paquetes perdidos en el proceso, esta prueba se realizó ya que los
switch están en constante comunicación con el controlador y enviaran la solicitud de qué hacer con el flujo
de entrada nuevo, así se pondrá a prueba la velocidad de respuesta del controlador, como se puede observar
el controlador solo necesita estar en conexión directa con un switch para tener administración y total visión
de la red.
Controlador
Switch 1
Host 1 Host 2 Host 3
Switch 2 Switch 3
Figura 32. Topología tipo bus implementada en el laboratorio

42
4.2.1.1. RECONOCIMIENTO DE LA TOPOLOGÍA POR PARTE DEL CONTROLADOR
FLOODLIGHT
Figura 33. Pantalla Principal de Floodlight
En la figura 33 se observa como el controlador floodlight en su UI reconoce los switch y los host.

43
Figura 34. Topología de red dada por el controlador
BEACON
Figura 35. Reconocimiento de switch en controlador Beacon

44
POX
Figura 36. Reconocimiento de switches por controlador POX
SDN VAN HP
Figura 37. Reconocimiento de los switches por el controlador SDN VAN HP

45
Figura 38. Topología dada por el controlador SDN VAN
4.2.2. TOPOLOGÍA DE RED ANILLO
La figura 39 representa una segunda topología de red implementa en el laboratorio, de igual forma se realizó
prueba de conectividad entre los terminales con el comando ping de la siguiente manera, de Host 1 a Host
2, de Host 2 a Host 3, y de Host 3 a Host 1, esta prueba tuvo la característica de que se realizó de manera
simultánea con el fin de observar el desempeño del controlador cuando los switch mandan solicitudes al
tiempo.
Controlador
Switch 1
Switch 2
Switch 3
Host 2
Host 1 Host 3
Figura 39. Topología de red Anillo usada en el laboratorio

46
FLOODLIGHT
Figura 40. Topología de red anillo dada por controlador Floodlight
BEACON
Figura 41. Conexión entre sí de los switch

47
POX
Figura 42. Reconocimiento de los switch en la topología anillo por parte del controlador POX
SDN VAN HP
Figura 43. Topología en anillo dada por el controlador SDN VAN HP

48
5. ANÁLISIS DE RESULTADOS
En el análisis de resultados se realizaron gráficas para comparar los controladores en los diferentes
escenarios propuestos, estos análisis incluyen los resultados del comando ping tanto en red virtual como en
la red real. También se expone el resultado del test hecho con Cbench donde se evaluó la cantidad de flujos
por segundo que puede manejar el controlador al conectar 16 switches en serie y a cada switch, un número
N de host.
5.1.TOPOLOGIA BUS
El primer escenario que se logró fue en la topología de bus en Mininet realizar un comando ping del Host 1
al Host 2 y al Host 3, en este escenario se probaron los 4 controladores obteniendo lo siguiente:
5.1.1. PING DE HOST 1 A HOST 2 (VIRTUAL)
0,040
0,023 0,021
0,024
0,000
0,010
0,020
0,030
0,040
0,050
FLOODLIGHT BEACON HP POX
Min RTT (ms)
Min RTT (ms)
6,611
0,899 0,845
32,006
0,000
5,000
10,000
15,000
20,000
25,000
30,000
35,000
Max RTT (ms)
Max RTT (ms)
Gráfica 2. RTT Min H1 - H2 Gráfica 1. RTT Max H1- H2

49
5.1.2. PING DE HOST 1 A HOST 3 (VIRTUAL)
5.1.3. PING DE HOST 1 A HOST 2 (REAL)
11,885
2,214 2,01
32,537
0,000
5,000
10,000
15,000
20,000
25,000
30,000
35,000
Max RTT (ms)
0,034
0,025
0,02
0,04
0,000
0,005
0,010
0,015
0,020
0,025
0,030
0,035
0,040
0,045
Min RTT (ms)
5,007
0,219 0,222 0,226
0
1
2
3
4
5
6
Min RTT (ms)
14,252 11,275
608,839
229,828
0
100
200
300
400
500
600
700
Max RTT (ms)
Gráfica 4. RTT Min Topología H1 – H3 Gráfica 3. RTT Min Topología H1 – H3
Gráfica 6. RTT Min H1 - H2, real. Gráfica 5. RTT Max H1-H2, real

50
5.1.4. PING DE HOST 1 A HOST 3 (REAL)
5.2.TOPOLOGÍA DE RED ANILLO
El segundo escenario implementado consta de una topología de red Anillo, aquí tanto en red simulada como
en la real se realizó un ping distribuido de la siguiente forma, Host 1 a Host 2, Host 2 a Host 3, Host 3 a
Host 1, y posteriormente se obtuvieron los siguientes resultados:
5.2.1. PING HOST 1 A HOST 2 (VIRTUAL)
Gráfica 9. Tiempo de RTT Max y Min
0,0054 0,004 0,0023 0,007
75,864 78,447
56,897
98,456
0
20
40
60
80
100
120
ms
Tiempos de RTT Max y Min
Min RTT (ms) Max RTT (ms)
8,039
4,677
0,902
6,717
0
1
2
3
4
5
6
7
8
9
Min RTT (ms)
62,527 43,045
871,844
272,291
0
100
200
300
400
500
600
700
800
900
1000
Max RTT (ms)
Gráfica 8. RTT Min H1-H3, real. Gráfica 7. RTT Max H1-H3, real.

51
Gráfica 10. Tiempos RTT Max y Min
Gráfica 11. Tiempos RTT Max y Min
0,003 0,002 0,0014 0,035
73,467
82,882
67,785
90,405
0
10
20
30
40
50
60
70
80
90
100
ms Tiempos RTT Max y Min
0,0045 0,002 0,004 0,008
99,39 98,112
65,093 64,976
0
20
40
60
80
100
120
ms
Tiempos RTT Max y Min

52
5.2.4. PIN HOST 1 A HOST 2 (REAL)
5.2.5. PING HOST 2 A HOST 3 (REAL)
5,02
0,209 0,203
5,119
0
1
2
3
4
5
6
Min RTT (ms)
12,539 8,89
634,574
55,544
0
100
200
300
400
500
600
700
Max RTT (ms)
6,173
4,006
0,71
6,754
0
1
2
3
4
5
6
7
8
Min RTT (ms)
8,519
90,625
837,607
635,855
0
100
200
300
400
500
600
700
800
900
Max RTT (ms)
Gráfica 12. RTT Min Host 1 a Host 2, real. Gráfica 13. RTT Max Host 1 a Host , real.
Gráfica 15. RTT Min Host 2 a Host 3, real. Gráfica 14. RTT Max Host 2 a Host 3, real

53
5.2.6. PING HOST 3 A HOST 1 (REAL)
5.3.FLUJOS OBTENIDOS CON MININET
6
4
0
6
0
1
2
3
4
5
6
7
Min RTT (ms)
34 12 5
611
0
100
200
300
400
500
600
700
Max RTT (ms)
1540,68
879067,89
1101,45 7423,59
22410,41
786530,56
25849,25
7496
0
100000
200000
300000
400000
500000
600000
700000
800000
900000
1000000
Flows/s
Cantidad de flujos con 10 M hosts
Min (Flows/s) Max (Flow/s)
Gráfica 17. RTT Min Host 3 a Host 1, real. Gráfica 16. RTT Max Host 3 a Host 1, real.
Gráfica 18. Manejo de Flujos con 10 M de Host

54
Gráfica 19. Manejo de Flujos con 1 M de Host
Gráfica 20. Manejo de Flujos con 100 K Host
Los resultados para el controlador Beacon son contundentes, es el que mayor puede manejar flujos,
superando por bastante a los demás controladores, puede deberse a las características del lenguaje de
programación JAVA.
1155,95
671003,32
1203,5 7226,03
24923,08
930368,55
8381,47 7440,62
0
100000
200000
300000
400000
500000
600000
700000
800000
900000
1000000
Flujos/s
Cantidad de Flujos con 1 M de Host
986,65
1064277,85
1145,97 7226,03
22426,07
1074019,49
9504,19 7440,62
0
200000
400000
600000
800000
1000000
1200000
Flows/s
Manejo de Flujos con 100 K Host

55
6. CONCLUSIONES
 Al concluir con el trabajo de grado se tienen dos ideas concretas. La primera hace referencia a los
beneficios de las nuevas tecnologías de redes SDN, donde se resaltan capacidad de administración
y manejo, se comprendió todo el ecosistema que estas redes plantean y se encontró que se dispone
de fabricantes enfocados a impulsar estos entornos de las telecomunicaciones. Por otra parte y
basándose en el objetivo principal se implementaron de manera correcta los cuatro controladores
estudiados, los cuales permiten explotar las cualidades que poseen, así de esta manera se pudo
evidenciar la característica más relevante de SDN el desprendimiento del control por parte del
switch y la delegación de este trabajo a un software externo denominado controlador.
 Los controladores evaluados poseen un gran respaldo en cuanto a documentación se refiere, puede
decirse que la información encontrada en las páginas web de los desarrolladores están muy
completas y que satisfacen los parámetros planteados con anterioridad. La información disponible
para la instalación fue suficiente y exacta para llevar a cabo este proceso, tenían claridad en las
líneas de comando que debían usarse, los prerrequisitos para el correcto funcionamiento y
desempeño. Por otra parte se encontraron problemáticas a la hora de la instalación de los
complementos, en algunos casos la instalación de Java y sus extensiones eran nombradas por el
desarrollador del controlador como requisito pero no describía la forma de instalarse, aunque no fue
problema buscar como debe ser la instalación se debería tener un pequeño tutorial sobre los
complementos externos al controlador, de esta forma se da una mayor certeza de que los que se está
ejecutando va a funcionar sin ningún inconveniente.
 En cuanto a la forma de uso, el mejor camino que se tomó fué comenzar con la exploración de los
componentes que cada controlador ofrecía, de esta manera se pudo tener un acercamiento a las
interfaces de usuario y sus propiedades, no obstante para poder explotar a fondo las posibilidades
que ofrecen los controladores se observaron videos elaborados por los mismos desarrolladores,
ratificando así el empeño por generar software OpenSource. Para concluir con la primer parte del
de evaluación referente a la calidad de la documentación, puede decirse que todos los controladores
usados poseen la suficiente información para su instalación y su posterior forma de uso, aunque las
formas de ejecutar los controladores sean diferentes, no son relevantes para su exclusión, todo lo
contrario ofrecen un variado portafolio de cualidades y beneficios que sin duda el usuario final es
el encargado de definir que controlador usar.
 En cuanto a los controlares se refiere, la evaluación del desempeño sobre el manejo de flujos arrojo
un dato de suma importancia, en este caso y según las gráficas elaboradas sobre el número de flujos
por segundo el controlador BEACON, es el que mayor número puede manejar, puede deberse a el
lenguaje con el cual fue desarrollado, ya que JAVA funciona con Threads, permitiendo así más
manejo y procesamiento de paquetes. Aunque este resultado es muy importante para el desempeño
del controlador, este software no presenta un topología de red en su UI, si no que por el contrario
arroja es un resumen de los puertos de conexión, la comodidad de un entorno visual hace del
controlador un software más ameno y práctico para su uso, para un administrador de red SDN una
ayuda visual es un gran complemento para el manejo de la arquitectura puesto que podrá definir
rutas y detectar errores rápidamente.

56
 El manejo por parte del controlador de las versiones existentes del protocolo OpenFlow, hacen de
este un ítem importante a la hora de elección, si la versión 1.3 de OpenFlow da mayor exactitud en
el tratamiento de los paquetes, porque el único controlador capaz de soportar esta versión es SDN
HP VAN, se infiere que al ser un controlador desarrollado por un fabricante pionero en este tipo de
redes ofrece a sus usuarios mayor y mejores posibilidades que cualquier otro, el enfoque que le da
HP a la redes SDN es muy relevante puesto que ellos apuestan por esta tecnología como futuro
reemplazo de las actuales.
 Analizando las gráficas sobre el resultado en la simulación con el obtenido en la topología de red
real montada, se pudo tener un punto de comparación, el simulador de red Mininet me permitió
generar redes que se asemejaran mucho a la realidad, en un primer acercamiento se puede observar
el potencial de las redes SDN inclusive si es en un entorno virtualizado.
 En el aspecto personal espero tener la posibilidad de enfocarme muchas más en esta tecnología,
puesto que con el desarrollo del trabajo de grado se pudo tener una claridad sobre los aspectos
relevantes de la red, así también que pretende atacar estas redes y su beneficio en la actualidad,
como Ingeniero próximo a titulación puedo asegurar que el mundo encaminado a las redes SDN
presentará unas ventajas inmensas en el entorno de las telecomunicaciones.

57
7. BIBLIOGRAFÍA
[1] M. Polanco, «Redes complejas hechas facilmente, ¿Será posible?,» Magazcitum, 23 08 2013.
[2] ITU, International Telecommunication Union, «Mobile-Broadband uptake continues to grow at
double-digit rates,» ICT Data and Statistics Division, Telecommunication Develop Bureau, Genova,
Suiza, 2014.
[3] A. T. Aldana y A. Vallejo C, «Telecomunicaciones, convergencia y regulación,» Revista de economía
institucional , vol. 12, nº 23, pp. 165-197, 2010.
[4] L. Marquez, Modelo Cliente-Servidor, 2010.
[5] Hewlett Packard, «Software-defined Networking,» [En línea]. Available:
http://h17007.www1.hp.com/co/es/networking/solutions/technology/sdn/index.aspx#tab=TAB2.
[Último acceso: 13 Abril 2014].
[6] «Investigación de redes deifninas por software,» Philosophie Naturalis Principia Technologica, vol.
I, pp. 1 - 106.
[7] S. Rodriguez Santamaria , «Mecanismo de control de las comunicaciones en la internet del futuro a
través de OpenFlow,» Universidad de Cantábria, España, Septiembre de 2012.
[8] OPEN NETWORKING FOUNDATION, «OpenFlow Switch Specification. Version 1.0.0 (Wire Protocol
0x01),» Diciembre 31 de 2009.
[9] Open Networking Foundation, OpenFlow Switch Specifation, 2013.
[10] B. Salisbury, «SDN Central,» 1 Julio 2012. [En línea]. Available:
http://www.sdncentral.com/technology/sdn-openflow-tcam-need-to-know/2012/07/. [Último
acceso: 23 04 2014].
[11] G. R. d. T. Muntaner, «Evaluation of OpenFlow Controllers,» Octubre 15 de 2012.
[12] Big Switch Networks, «Project Flooodlight,» 2014. [En línea]. Available:
http://www.openflowhub.org/display/floodlightcontroller/Cbench+(New). [Último acceso: 25 2
2014].
[13] Mininet Team, «Mininet, An Instant Virtual Network on your Laptop,» [En línea]. Available:
http://mininet.org/download/. [Último acceso: 27 04 2014].
[14] Network Working Group, Especificación Protocolo Internet, Version 6 (IPv6), 1998.
[15] Hewlett Packard, HP, HP VAN SDN Controller Adminstration Guide, 2013.
[16] Hewlett Packard, HP, HP VAN SDN Controller REST API, 2013.

58
[17] W. E. S. Yu, CS 154: Introduction to Mininet, 2013.
[18] R. Sherwood, «Cbench: Controller BenchMarker,» [En línea]. Available:
http://archive.openflow.org/wk/index.php/Oflops. [Último acceso: 27 04 2014].
[19] J. Ogden , Cbench: A Software Toolkit for Testing, Benchmarking, and Qualifying HPTC Linux
Clusters.
[20] M. Jarschel , F. Lehrieder , Z. Magyari y R. Pries, «A Flexible OpenFlow-Controller Benchmark,» IEEE.
European Workshop on Software Defined Networking, pp. 48 - 53 , 2012.
[21] N. Figuerola, «SDN - Redes Definidas por Software».
[22] Hewlett Packard, HP, SDN Controller Programming Guide, 2013.
[23] Alice, America Latina Interconectada con Europa, OpenFLow 1.3, Cuenca, 2012.
[24] Alice, America Latina Interconectada con Europa, LAs versiones del Protocolo OpenFlow, Cuenca,
2012.
[25] «IBM DevelopedWorks,» 12 06 2012. [En línea]. Available:
http://www.ibm.com/developerworks/ssa/local/im/que-es-big-data/. [Último acceso: 20 05 2014].
[26] «Wikipedia, La enciclopedia Libre,» 30 04 2014. [En línea]. Available:
http://es.wikipedia.org/wiki/Openflow. [Último acceso: 8 05 2014].
[27] «ONF, Open Networking Foundation,» [En línea]. Available:
https://www.opennetworking.org/about/onf-overview. [Último acceso: 16 3 2014].
[28] Y. Panadero, Redes Programables: Como añadir Inteligencia a la red según cisco, 2013.
[29] V. Yasici, O. Sunay y A. Ozer Ercan , Controlling a Software-Defined Network Via Distribuited
Controllers, Estanbul, Turquia, 2102.
[30] GOOGLE. Inc, «OpenFlow@Google,» 2012.
[31] C. Spera , «Software Defined Network: el futuro de las arquitecturas de red,» Logicalis, pp. 42 - 45,
2013.
[32] A. Lara, A. Kolasani y B. Ramamurthy, «Network Innovation using OpenFlow: A survey,» IEEE
COMUNICATIONS SURVEYS & TUTORIALS, pp. 1 -20.
[33] D. F. Blandón Gómez, OpenFlow...El protocolo del futuro, 2013.

59
8. ANEXOS
ANEXO 1
CODIGO DESARROLLADO EN PYTHON PARA TOPOLOGIA PERSONALIZADA EN
MININET
"""Custom topology example
Two directly connected switches plus a host for each switch:
host --- switch --- switch --- host
Adding the 'topos' dict with a key/value pair to generate our newly
defined
topology enables one to pass in '--topo=mytopo' from the command line.
from mininet.topo import Topo
class MyTopo( Topo ):
"Simple topology example."
def __init__( self ):
"Create custom topo."
# Initialize topology
Topo.__init__( self )
# Add hosts and switches
leftHost = self.addHost( 'h1' )
middleHost = self.addHost( 'h3' )
rightHost = self.addHost( 'h5' )
leftSwitch = self.addSwitch( 's1' )
middleSwitch = self.addSwitch( 's2' )
rightSwitch = self.addSwitch( 's3')
# Add links
self.addLink( leftHost, leftSwitch )
self.addLink( leftSwitch, middleSwitch )
self.addLink( middleHost, middleSwitch )
self.addLink( middleSwitch, rightSwitch )
self.addLink( rightHost, rightSwitch )

60
self.addLink( rightSwitch, leftSwitch )
topos = { 'mytopo': ( lambda: MyTopo() ) }
ANEXO 2
INSTALACION DE LOS DIFERENTES CONTROLADORES USADOS
Floodlight
$ sudo apt-get install build-essential default-jdk ant python-dev eclipse
$ git clone git://github.com/floodlight/floodlight.git
$ cd floodlight
$ ant
Ejecucion de Floodlight
$ java -jar target/floodlight.jar
POX
$ sudo apt-get install git
$ git cloone git://github.com/noxrepo/pox
$ https://github.com/noxrepo/pox/dwnloads
Ejecución de POX
$ cd pox
$ ./pox.py samples.pretty_log forwarding.l2_learning
Beacon
Descargar Eclipse for RCP and RAP Developers v3.7.0, disponible en eclipse.org
$mkdir git
$cd git
$git clone git://gitosis.stanford.edu/openflowj.git
$git clone git://gitosis.stanford.edu/beacon.git
Acceder al entorno eclipse mediante la aplicación descargada RCP and RAP
Dar el nombre del wrkspace como /WorkspaceBeacon click en aceptar
File – Import – General – Existing Projects into Workspace – Next
Agregar las localizaciones /home/nombre_del_equipo/git/openflow
/home/nombre_del_equipo/git/beacon
Abrir el proyecto y dar click en Beacon Main Target – main.target
En la parte inferior derech deberá decir “Resolving Target Definition”, esperar a que el sistema termine co
el proceso.
Luego click en “Set as target Platform”
Para terminar
Click en Window – Preferences – Java – Code style – Formatter
Hacer click en el botón Import y ubicar la dirección /git/beacon/Beacon_style_settings.xml y acpetar

61
Ejecucion de Beacon
Run – Debug Configurations – OSGI y seleccionar Beacon y finalmente click en Debug.
Controlador HP
Se remite a la guía de instalación del fabricante
 http://h20565.www2.hp.com/portal/site/hpsc/template.BINARYPORTLET/public/kb/docDisplay/
resource.process/?spf_p.tpst=kbDocDisplay_ws_BI&spf_p.rid_kbDocDisplay=docDisplayResUR
L&javax.portlet.begCacheTok=com.vignette.cachetoken&spf_p.rst_kbDocDisplay=wsrp-
resourceState%3DdocId%253Demr_na-c03998700-
3%257CdocLocale%253D&javax.portlet.endCacheTok=com.vignette.cachetoken
NOTA: Usar una arquitectura de 64 Bits, e instalar el controlador SDN VAN HP solo, sin ningún otro
controlador
NOTA 2: Los tres primeros controladores si pueden instalarse en un mismo equipo, no se deben ejecutar
controladores al tiempo.

62
ANEXO 3
Instalacion de Cbench benchamark tool
$ sudo apt-get install autoconf automake libtool libsnmp-dev libpcap-dev
$ git clone git://gitosis.stanford.edu/oflops.git
$ cd oflops; git submodule init && git submodule update
$ git clone git://gitosis.stanford.edu/openflow.git
$ cd openflow; git checkout -b release/1.0.0 remotes/origin/release/1.0.0
$ wget http://hyperrealm.com/libconfig/libconfig-1.4.9.tar.gz
$ tar -xvzf libconfig-1.4.9.tar.gz
$ cd libconfig-1.4.9
$ ./configure
$ sudo make && sudo make install
$ cd ../../netfpga-packet-generator-c-library/
$ sudo ./autogen.sh && sudo ./configure && sudo make
$ cd ..
$ sh ./boot.sh ; ./configure --with-openflow-src-dir=<absolute path to openflow branch>; make
$ sudo make install
$ cd cbench
Ejecucion de Cbench
./cbench -c localhost -p 6633 -m 10000 -l 10 -s 16 -M 1000 –t
-s : Representa el número de switch a emular
-M: Numero de MACs por switch

63
ANEXO 4
MANUAL CONFIGURACIONES SWITCH HP
Los siguientes comandos deberán hacer exactamente igual para los switch que se deseen usar, así se
garantiza el correcto funcionamiento del controlador SDN y la conexión entre los switch.
CONFIGURACION VLAN DEL CONTROLADOR
HP-Stack-3800# configure
HP-Stack-3800(config)# vlan 10
HP-Stack-3800(vlan-10)# name “Nombre_al_controlador”
HP-Stack-3800(vlan-10)# ip address 20.0.1.1/24 (ip exlcusiva del controlador)
HP-Stack-3800(vlan-10)# untagged 1/1 (Para los switch 3800 debe escribirse con “1/n”, mientras que en el
switch 3500 solo debe ponerse el n, n hace referencia al número el puerto).
HP-Stack-3800(vlan-10)# openflow controller-id 1 ip 20.0.1.30 controller-interface vlan 10 (ip para todos
igual)
CONFIGURACIÓN VLAN DE LOS USUARIOS
HP-Stack-3800(vlan-10)# name “Nombre_de_la_Vlan”
HP-Stack-3800(vlan-10)# untagged 1/2-1/12
HP-Stack-3800(vlan-11)# openflow instance “Nombre de la instancia OpenFlow”” member vlan 20
HP-Stack-3800(config)# openflow instance “Nombre de ka instancia OpenFlow” controller-id 1
MODOS TRUNK
HP-Stack-3800(config)# trunk 1/12 trk12 ( Puerto de libre elección, por aquí se comunicara el controlador
con los otros switch)
HP-Stack-3800(config)# trunk 1/11 trk111 (Para los switch 3800 debe escribirse con “1/n”, mientras que
en el switch 3500 solo debe ponerse el n, n hace referencia al número el puerto).
HP-Stack-3800(vlan-10)# tagged trk12
HP-Stack-3800(vlan-10)# tagged trk11

ContrerasPardoCarlosAlberto2014.pdf

Recomendados

Recomendados

Más contenido relacionado

Similar a ContrerasPardoCarlosAlberto2014.pdf

Similar a ContrerasPardoCarlosAlberto2014.pdf (20)

Más de Fernando Velez Varela

Más de Fernando Velez Varela (20)

Último

Último (20)

ContrerasPardoCarlosAlberto2014.pdf