Universidad de Extremadura
Centro Universitario de Mérida Grado en Ingeniería en Telemática
Trabajo Fin de Grado
ANÁLISIS Y EVALUACIÓN DE LAS REDES DEFINIDAS POR SOFTWARE
Autor/a: Pablo Murillo Nogales
Mérida, Julio de 2015
Universidad de Extremadura
Centro Universitario de Mérida Grado en Ingeniería en Telemática
Trabajo Fin de Grado
ANÁLISIS Y EVALUACIÓN DE LAS REDES DEFINIDAS POR SOFTWARE
Autor/a: Pablo Murillo Nogales Fdo:
Director/a: Javier Domingo Carmona Murillo
Fdo:
Resumen
Software-Defined Networking (o Redes Definidas por Software) es un nuevo para- digma que tiene como objetivo simplificar la creación y gestión de redes de ordena- dores. El desacoplamiento entre el control de la red y el plano de reenvío propuesto por esta arquitectura permite el control de todo el comportamiento de la red me- diante un elemento lógico centralizado, llamado controlador. Esta separación de los planos abre la puerta a la virtualización de redes, proporcionando a los usuarios una abstracción lógica de los recursos de red subyacentes.
La iniciativa Open Networking Foundation (ONF), está desarrollando estándares abiertos que permitan alcanzar los retos planteados por SDN. El resultado es lograr una arquitectura que permita a los administradores de red tener un control total en el funcionamiento de la red a través del despliegue de software que controle y auto- matice el comportamiento de la misma. La ONF ya ofrece el estándar OpenFlow, que permite la programación remota del plano de control. Este es el primer estándar SDN y un elemento vital de una arquitectura de red definida por software.
En este trabajo analizaremos las SDN y el protocolo OpenFlow y veremos algu- nas de las diferentes alternativas de controladores para terminar centrándonos en OpenDaylight. Además procederemos a desplegar una red de ejemplo mediante la herramienta Mininet que permite simular un entorno SDN. Después se ha realizado un caso práctico para comprobar de forma más concreta como programar un con- trolador y en definitiva poder manejar toda la red.
Finalmente se han realizado algunas pruebas con el fin de analizar y mejorar el rendimiento energético de una red SDN. Como resultado se obtiene que efectiva- mente el consumo energético mejora, aunque en contra, la carga total de la red aumenta.
Abstract
Lately, the emerging paradigm of Software-Defined Networking has grown in pre- sence and claims to simplify future networking. The decoupling of network control and forwarding plane proposed by this architecture allows the control of the entire network behavior by means of a logically centralized software program (controller).
Such separation of planes opens the way to Network Virtualization, which provides users a logical abstraction of underlying network resources.
Open Networking Foundation (ONF) is a user-driven organization dedicated to the promotion and adoption of Software-Defined Networking (SDN) through open standards development. Thus, network administrators, will be able to program and control the forwarding plane of such networks in a new way.
In this work we analyze the SDN and the OpenFlow protocol and we see some of the different alternative controllers, and finally, we focus on OpenDaylight. Furt- hermore we proceed to create a sample network using Mininet to simulate a SDN environment. Finally a case study is performed to check more specifically how to program a controller and ultimately to manage the entire network.
Finally, some tests be performed in order to analyze and improve the energy per- formance of a SDN network. Obtained results show that our proposal improves the energy consumption, although the network load is increased.
Índice general
1. Introducción 5
1.1. Antecedentes . . . 5
1.2. Objetivos . . . 6
1.3. Planificación . . . 6
1.4. Estructura del documento . . . 7
2. Software Defined Networking 9 2.1. Introducción . . . 9
2.2. Concepto de SDN . . . 9
2.3. SDN y virtualización . . . 10
2.4. Beneficios del SDN . . . 10
2.5. Usos de SDN . . . 11
3. OpenFlow 13 3.1. Protocolo OpenFlow . . . 13
3.2. Funcionamiento de OpenFlow . . . 15
3.2.1. Flujos . . . 15
3.2.2. Tablas de flujos . . . 16
3.2.3. Instructions . . . 16
3.2.4. Counters . . . 17
3.2.5. Mensajes del protocolo OpenFlow . . . 17
3.2.6. Matching . . . 19
3.3. Probando OpenFlow . . . 20
3.3.1. Explicación teórica. . . 20
4. Software utilizado 29 4.1. Controladores . . . 29
4.1.1. OpenDaylight . . . 29
4.1.2. Ryu . . . 32
4.1.3. Floodlight . . . 32
4.1.4. NOX/POX . . . 32
4.2. Mininet . . . 35
4.2.1. Ventajas e inconvenientes de Mininet . . . 35
Índice general
4.2.2. vSwitch . . . 36
4.3. Wireshark . . . 36
4.4. Iperf . . . 37
4.5. Eclipse . . . 37
4.5.1. Maven . . . 38
4.6. Uso del software . . . 38
4.6.1. Mininet . . . 38
4.6.2. Wireshark . . . 43
4.6.3. OpenDaylight . . . 47
5. Caso práctico: Mejora de la eficiencia energética en una red SDN 49 5.1. Explicación teórica . . . 49
5.1.1. Desarrollo del código: Java . . . 50
5.1.2. Desarrollo del código: Maven . . . 61
5.1.3. Desarrollo del código: Python . . . 62
5.2. Funcionamiento . . . 62
5.2.1. Configuración módulo flowApp . . . 62
5.2.2. Iniciando OpenDaylight . . . 66
5.2.3. Iniciando Mininet . . . 66
5.3. Resultados . . . 69
6. Conclusiones y trabajo futuro 73 6.1. Conclusiones . . . 73
6.2. Trabajo futuro . . . 74
7. Agradecimientos 75
Bibliografía 77
Índice de figuras
3.1. Esquema Openflow . . . 14
3.2. Proceso de matching . . . 20
3.3. Topología . . . 21
3.4. PACKET_IN . . . 22
3.5. PACKET_OUT a . . . 23
3.6. FLOW_MOD a . . . 24
3.7. PACKET_OUT b . . . 25
3.8. FLOW_MOD b . . . 26
3.9. Ultimos paquetes . . . 27
3.10. Wireshark Packet-in y Flow-mod . . . 28
4.1. OpenDaylight Helium . . . 30
4.2. Floodligh . . . 34
4.3. Mininet VM ifconfig . . . 39
4.4. mininet> . . . 41
4.5. Topología simple Mininet . . . 42
4.6. Topología con MiniEdit . . . 44
4.7. Controlador remoto MiniEdit . . . 45
4.8. Activar CLI MiniEdit . . . 45
4.9. Ventana de Wireshark . . . 46
4.10. Controlador OpenDaylight iniciándose . . . 48
5.1. Topología en malla . . . 50
5.2. Topología en anillo . . . 51
5.3. Topología en árbol . . . 52
5.4. dependencies . . . 61
5.5. Compilar con Maven . . . 63
5.6. Código python iperfUDP . . . 64
5.7. OpenDaylight configuración y monitor . . . 67
5.8. Topología en malla . . . 70
5.9. Topología en anillo . . . 71
5.10. Topología árbol . . . 72
Índice de figuras
Índice de tablas
1.1. Metodología del trabajo . . . 7 3.1. Principales componentes de una entrada en una tabla de flujo . . . . 16 3.2. Lista requerida de contadores para usar en mensajes de estadísticas . 18 3.3. Campos de los paquetes usados para matching . . . 19 4.1. Bundles importantes de OpenDaylight . . . 31 4.2. AD-SAL vs MD-SAL . . . 33
Índice de tablas
1 Introducción
1.1. Antecedentes
La idea de programar redes no es nueva, según [1] hay varias contribuciones an- teriores a SDN. Una de ellas es SOFTNET [2], allá por principios de los 80, una red multisalto, semejante a las a las actuales WSN (Wireless Sensor Networks) cuya innovación fue que en el campo de datos de cada paquete se incluían comandos que los nodos iban ejecutando a medida que los iban recibiendo. De esta manera, la red podía irse modificando de forma dinámica y en tiempo real. Fue un intento de definir una red auto-organizable destinada a permitir la experimentación y la innovación con diferentes protocolos. No hubo desarrollo posterior, pero su idea fue el embrión de las posteriores Active Networks [3].
Las Active Networks presentaban una arquitectura consistente en llevar embebido en los paquetes pequeños programas que podían ser ejecutados por los nodos que éstos atraviesan. Esto hacía posible que los switches y routers de la red procesaran los paquetes de datos, haciéndoles partícipes de los mensajes y no solo meros es- pectadores que se limitaban a enviar mensajes de un puerto a otro, de una forma
“pasiva”. De ahí el nombre de Active Networks. El área de Active Networks fue una tendencia en investigación hace tiempo, aunque últimamente ha decaído.
Tanto SOFTNET como Active Networks concibieron una red innovadora, diná- mica y partícipe de los datos que transportaban. El mecanismo era básicamente el mismo: añadir líneas de código a los paquetes de datos para que los nodos inter- medios las ejecutarán. No incorporaban un elemento software como control de los elementos de conmutación, como sí hace la filosofía SDN.
En 2007, un grupo de trabajo de la Universidad de Standford formado por los profesores Nick McKeown, Scott Shenker y el estudiante de doctorado Martín Ca- sado desarrollaron OpenFlow y fundaron Nicira, una compañía de virtualización de redes. Es a partir de este momento donde se sitúa el nacimiento de SDN.
En 2011, Scott Shenker y Nick McKeown fundaron la Open Networking Founda- tion (ONF), organización que buscaba fomentar el uso de OpenFlow, la creación de
1 Introducción
estándares y la implantación de SDN más allá de las universidades.
En julio de 2012 VmWare, una de las compañías líderes en virtualización de ser- vidores, dio un paso hacia la incorporación de la virtualización de redes en su gama de productos y compró Nicira por 1260 millones de dólares. Martín Casado pasó a ser el "arquitect networking" en jefe de VMware [4].
1.2. Objetivos
Los objetivos del trabajo eran el diseño, desarrollo y prueba de escenarios basados en máquinas virtuales que permitieran evaluar las nuevas arquitecturas de red basa- das en software (Software Defined Networks o SDN). Se estudiaron los componentes básicos utilizados en SDN:
Protocolo OpenFlow.
Emuladores de red con soporte OpenFlow como Mininet.
Entornos como OpenDayLight.
Partiendo de estos componentes, se crearon escenarios que combinaban estas pla- taformas con el objetivo de detectar los beneficios que puede aportar el paradigma SDN frente a la gestión tradicional de la red.
Además se ha desarrollado una aplicación con la que intentar mejorar la eficiencia energética de las redes usando tecnologías SDN.
1.3. Planificación
Metodología de trabajo (ver tabla 1.1):
1. Análisis y estudio de los antecedentes de SDN y OpenFlow.
2. Análisis de los elementos que componen la red SDN y Openflow.
3. Virtualización de agentes de red. Mininet.
4. Despliegue y análisis de las plataformas OpenDayLight.
5. Desarrollo de aplicación bajo OpenDaylight y estudio de su comportamiento.
1.4 Estructura del documento Febrero Marzo Abril Mayo Junio
Tarea 1 X
Tarea 2 X
Tarea 3 X
Tarea 4 X X
Tarea 5 X X
Tabla 1.1: Metodología del trabajo
1.4. Estructura del documento
Este trabajo aborda los temas antes mencionados a partir de una definición más amplia de las tecnologías y su introducción, seguido de la descripción del diseño de la aplicación propuesta y del análisis de sus mediciones. El trabajo se ha estructurado en cinco capítulos principales de la siguiente manera:
El Capítulo 2 presenta las Redes Definidas por Software. Se tratan de explicar como concepto y sus relaciones con la virtualización. Además se aportan una serie de beneficios de este tipo de redes. Por ultimo se explican algunos usos que pueden tener las SDN.
En el Capítulo 3 se realiza un análisis del protocolo OpenFlow. Se explica el funcionamiento de las distintas partes que lo componen y finalmente, se simula un caso práctico para asentar la concepción de como funciona el protocolo.
El Capítulo 4 describe el software utilizado. Primeramente se exponen algu- nos controladores compatibles con OpenFlow y se hace un inciso en el controlador OpenDaylight que es el que se usará posteriormente para realización de la aplicación práctica. También se prestará atención al software emulador de redes SDN Mininet.
Por ultimo se harán algunos ejemplos sencillos que muestran como ejecutar estas aplicaciones.
En el Capítulo 5 se mostrará como se ha desarrolado la aplicación descrita ante- riormente además de su funcionamiento y las pruebas realizadas para probar dicha aplicación.
Finalmente en el Capítulo 6 se harán las conclusiones pertinentes y una serie de posibles trabajos futuros a desarrollar relacionados con las SDN.
1 Introducción
2 Software Defined Networking
2.1. Introducción
El SDN (Software Defined Networking) es una técnica emergente que concentra las funciones de control de la red en elementos software. Explicaremos el concepto de SDN, su relación con las técnicas de virtualización y sus beneficios, explorando también el concepto de Network Functions Virtualization (NFV) [5].
2.2. Concepto de SDN
SDN es el acrónimo de Software Defined Networking, es decir, la implementación en software de algunas funciones de red. Para entender lo que SDN aporta, convie- ne primero repasar cuáles son las funciones de un router o un switch en una red, típicamente una red IP. Este tipo de equipos soportan dos funciones fundamentales:
Una función de transporte: que se podría entender como su función primaria y que consiste, simplemente, en transportar datos a su destino. Para ello, estos equipos envían los paquetes de datos a dónde indiquen unas rutas previamente calculadas.
Una función de control: que permite gestionar la función de transporte me- diante otras dos subfunciones principales:
• Intercambiar información sobre conectividad con otros routers/switches.
• Calcular rutas con base en la información obtenida.
En el networking tradicional tanto las funciones de control como las de transporte son ejecutadas de forma distribuida en todos los routers/swItches de la red. SDN es un enfoque de networking que, por un lado, separa claramente las funciones trans- porte y de control y, por otro implementa la función de control con software (en lugar de hacerlo en hardware). Además, centraliza en un elemento, el controlador esa función de control.
Resumimos pues los tres elementos que caracterizan al Software Defined Networ- king (SDN):
2 Software Defined Networking
Separación clara entre las funciones de transporte y de control.
Centralización de la función de control.
Implementación de la función de control en software.
El hecho de centralizar la función de control y de implementarla en software conlleva que la red se pueda programar mediante aplicaciones, lo que proporciona una enorme flexibilidad y facilidad de despliegue de funciones de red.
Además, el controlador puede exponer interfaces de aplicación que facilitan la manipulación y gestión de la red [6].
2.3. SDN y virtualización
La virtualización es una técnica que pretende simular hardware y elementos de red mediante software. No es un concepto que provenga específicamente del mundo del networking sino que, de hecho, surgió más bien en el mundo de las Tecnologías de la información, de los grandes servidores de aplicaciones y los data centers. La virtualización abstrae las máquinas reales, el hardware real, en lo que se denomina la máquina virtual, esto es, una máquina ficticia implementada en software pero a la que se asigna memoria, espacio en disco, etc, como si de una máquina real se tra- tase. De esta forma las aplicaciones ven, por decirlo de alguna manera, una máquina adaptada a sus necesidades pero del alguna forma independiente del hardware real que la soporta. Para crear y gestionar esas máquinas virtuales se emplea un software que se denomina hypervisor.
Aunque, ya en el campo del networking SDN y virtualización son conceptos dife- rentes, lo cierto es que en realidad aparecen muy unidos. Y lo hacen en el sentido de que las funciones de control centralizadas se suelen implementar como switches virtuales (es decir, la simulación de un switch en software) ejecutándose en máquinas virtuales alojadas sobre unos servidores físicos y gestionadas mediante un hypervisor.
Un concepto relacionado con la virtualización y el SDN es el de virtualización de funciones de red (Network Functions Virtualization, NFV). Lo que significa este concepto es la centralización de funciones de red en servidores de propósito general virtualizados. Así, por ejemplo, se pueden centralizar funciones en el campo de la seguridad AAA (Authentication, Authorization and Accounting).
2.4. Beneficios del SDN
¿Qué aporta el SDN? Podríamos resumir los beneficios en los siguientes puntos:
2.5 Usos de SDN Elimina la lentitud en innovación propia del hardware permitiendo que ésta se produzca a la velocidad del software, especialmente en el plano de control.
Optimiza el coste de hardware de networking.
Implementación de la función de control en software.
Simplifica el equipamiento de red
Posibilita el uso de algoritmos más complejos y exigentes computacionalmente.
Reduce la barrera de entrada para innovadores e investigadores.
Reduce drásticamente los ciclos de vida de lanzamiento de servicios.
Promueve la innovación en algoritmos de enrutamiento así como una mayor utilización de la capacidad de red.
2.5. Usos de SDN
Las redes SDN tienen aplicaciones en una gran variedad de entornos de red. Sepa- rando los planos de control y de datos, las redes programables permiten un control personalizado y una oportunidad para de eliminar middleboxes y con ello simplificar el desarrollo y la implementación de nuevos servicios y protocolos. A continuación, se examinarán diferentes entornos para los que han sido propuestas o aplicadas so- luciones SDN [5].
Redes empresariales: Una gestión adecuada es de vital importancia en entornos empresariales. Las redes SDN pueden ser usadas para manejar las políticas de red mediante programación. Las SDN pueden manejar funciones de middlebox como firewalls, NATs, balanceadores de carga o medidas de control de acceso.
Data Centers: Un gran problema de los data centers, es el gran consumo ener- gético que producen. Las redes SDN pueden permitir mejorar la eficiencia energética a través de métodos para usar solo una parte de la red, intentando que esto no repercuta en la eficiencia de la red. Más adelante nosotros también abordaremos este problema [7].
Redes ópticas: Manejar el trafico de datos mediante flujos, permite a las SDN y a OpenFlow en particular, soportar e integrar múltiples tipos de tecnologías de red. De acuerdo a el Optical Transport Working Group (OTWG) creado en 2013 por la Open Network Foundation (ONF), los beneficios de aplicar
2 Software Defined Networking
SDN y el estándar OpenFlow en particular a las redes de transporte ópticas incluyen: mejora el control de red del transporte óptico y la flexibilidad en la administración, permitiendo la implementación de administración de terceros y control de sistemas, e implementando nuevos servicios de virtualización.
Infraestructuras basadas en redes de acceso inalámbricas: Recientemente se está viendo un creciente interés académico y de la industria en para aplicar SDN a las redes móviles. La principal motivación detrás de esto es que SDN puede ayudar a los operadores móviles a simplificar la administración de sus redes y permitir nuevos servicios que soporten el crecimiento exponencial del tráfico previsto para las redes 5G [8].
Hogares y PYMES: Varios proyectos se han centrado en ver cómo las redes SDN podrían ser utilizadas en redes más pequeñas, tales como las que se en- cuentran en hogares o pequeñas empresas. Estos escenarios se están volviendo cada vez más complejos debido a la creciente disponibilidad de dispositivos de red de bajo coste y la necesidad de dispositivos más complicados de adminis- trar y de mayor seguridad.
GÈANT, la red científica europea, recientemente ha publicado entre sus futuras implantaciones, nuevas tecnologías para los entornos de red, entre ellas está la que tratamos en este documento, las redes SDN. Se pretende en un futuro, poder usar esta tecnología para controlar sus capas de transporte [9].
3 OpenFlow
Lo que propone OpenFlow [10] es una manera para que los investigadores puedan experimentar con protocolos en la redes que se usan a diario. Permite a los investi- gadores experimentar con switches de manera uniforme a la velocidad de la línea y con una densidad de puertos muy alta. Por otra parte, los fabricantes no tienen que exponer los procesos internos de sus switches. La propuesta de OpenFlow es muy clara, permitir que los investigadores puedan evaluar sus ideas en un entorno de trabajo real y ser un componente muy útil en los bancos de pruebas a gran escala.
3.1. Protocolo OpenFlow
La mayoría de los switches Ethernet contienen tablas de flujos (Flow-Tables), la idea de OpenFlow es la posibilidad de modificar estas tablas de forma dinámica para implementar firewalls, NAT, QoS y recolectar estadísticas. Es posible experimentar con nuevos protocolos, nuevos modelos de seguridad, esquemas de direccionamiento, incluso alternativas para IP lo que supone una mayor innovación. El plano de datos no se vería afectado ya que está aislado y se procesaría de la misma manera que se ha estado realizando hasta hoy día. El cambio reside en el plano de control que se implementaría mediante OpenFlow.
Los switch OpenFlow puede soportar diversas acciones, aunque es necesario tener una serie de características comunes a todos ellos. Un switch OpenFlow consiste en al menos tres partes (ver figura 3.1 [5]):
Tabla de flujos: con una acción asociada a cada entrada de la tabla, indicando al switch como debe procesar ese flujo.
Canal seguro que conecte el switch a un proceso de control remoto (contro- lador), permitiendo comandos y paquetes se puedan enviar entre el switch y el controlador usando el protocolo OpenFlow.
Controlador: Un controlador añade y elimina entradas en la tabla de flujos.
3 OpenFlow
Figura 3.1: Esquema Openflow
Los switches tradicionales usan STP, SPB o TRILL para determinar cómo se re- envían los paquetes. OpenFlow traslada esta decisión de reenvío de los switches a los controladores, típicamente un servidor o una estación de trabajo. Una aplicación de gestión se ejecutará en las interfaces del controlador que une todos los switches en la red, facilitando la configuración de caminos de reenvío que utilizarán todo el ancho de banda disponible. La especificación define el protocolo entre el controlador y los switches y un conjunto de operaciones que se pueden realizar entre ellos Las instrucciones de reenvío se basan en el flujo, que consiste en que todos los paquetes comparten una serie de características comunes.
Existen infinidad de parámetros que pueden especificarse para definir un flujo.
Entre los posibles criterios podemos incluir los puertos por donde se reciben los paquetes cuando llegan, el puerto Ethernet de origen, la etiqueta VLAN, el destino Ethernet o el puerto IP y otro numero de características de los paquetes. Un nuevo flujo se debe crear cuando un paquete que llega no encuentra ninguna coincidencia con ninguna entrada de la tabla. El switch debería tener configurado un descartado de paquetes para el flujo que no haya sido definido, pero en la mayoría de los casos, el paquete será enviado al controlador. El controlador entonces define un nuevo flujo
3.2 Funcionamiento de OpenFlow para ese paquete y crea una o más entradas para la tabla. Éste envía la entrada o entradas al switch para que sean añadidas a las tablas de flujo. Finalmente, el paquete se envía de vuelta al switch para ser procesado con las nuevas entradas creadas.
SDN no es OpenFlow
A menudo se apunta a Openflow como sinónimo de SDN, pero en realidad, es simplemente un elemento que forma parte de la arquitectura SDN. Openflow es un estándar abierto para un protocolo de comunicaciones que permite al plano de control interactuar con el plano de datos (Openflow, sin embargo, no es el único protocolo disponible o en desarrollo para SDN, aunque sí está convirtiéndose en el modelo estándar de implementación de una SDN.
3.2. Funcionamiento de OpenFlow
3.2.1. Flujos
Un nuevo flujo se debe crear cuando un paquete que llega no encuentra ninguna coincidencia con ninguna entrada de la tabla. El switch debería tener configurado un descartado de paquetes para el flujo que no haya sido definido, pero en la ma- yoría de los casos, el paquete será enviado al controlador. El controlador entonces define un nuevo flujo para ese paquete y crea una o más entradas para la tabla.
Éste envía la entrada o entradas al switch para que sean añadidas a las tablas de flujo. Finalmente, el paquete se envía de vuelta al switch para ser procesado con las nuevas entradas creadas.
Cada flujo de entrada tiene asociada una acción simple. Las tres básicas son:
1. Reenvío de flujo de paquetes a un puerto o puertos dados. Esto per- mite que los paquetes ser encaminados a través de la red. En la mayoría de los switches sucede a la velocidad de la línea.
2. Encapsulación y reenvío este flujo de paquetes al controlador. El paquete será enviado al Canal Seguro, donde se encapsula y se envía al con- trolador. Típicamente se usa para el primer paquete en un nuevo flujo, para que el controlador pueda decidir si el flujo debe ser añadido a la tabla de flujos.
También se puede usar para reenviar todos los paquetes al controlador para que sean procesados.
3 OpenFlow
Match Fields Priority Counters Instructios Timeouts Cookie Tabla 3.1: Principales componentes de una entrada en una tabla de flujo
3. Descartar este flujo de paquetes. Puede ser usado por seguridad, para parar ataques de denegación de servicio o reducir el falso tráfico de descubri- miento broadcast desde los hosts finales.
3.2.2. Tablas de flujos
Una tabla de flujo contiene una serie de entradas de flujo Cada entrada de la tabla de flujo (tabla ) contiene:
match fields: Coincidencia. Este campo consiste en el puerto y la cabecera de paquete y opcionalmente metadatos especificados en una tabla anterior.
priority: Prioridad del flujo. En el caso de que haya más de un flujo con el mismo match tendrá prioridad el flujo con el número de prioridad más alto.
counters: Contadores que se actualizan cuando los paquetes coinciden (mat- ched).
instructions: Instrucciones que indican la acción que hará el paquete a pro- cesar.
timeouts: tiempos antes de que un flujo expire. Son dos: idle_time_out y hard_time_out. El primero hacer referencia al tiempo que un flujo estará sin usar. El segundo indica el tiempo real desde que se instaló el flujo.
cookie: Valor que elige el controlador para filtrar las estadísticas, las modifi- caciones y el borrado de los flujos. No se usa: cuando se procesan los paquetes.
Una entrada de la tabla de flujo es identificada por su "match fields" y prioridad.
3.2.3. Instructions
Cada tabla de flujo contiene un set de instrucciones que se ejecutan cuando el paquete encuentra una coincidencia con la entrada. Estas instrucciones dan lugar a cambios en el paquete, en el conjunto de acciones y en el procesamiento.
Un switch no tiene por qué soportar todos los tipos de instrucciones, solo las que se marcan como requeridas y son: Instrucción de escritura (Write-Actions “action”):
3.2 Funcionamiento de OpenFlow Si la acción del tipo dado existe, se sobrescribe, si no, se añade. Ir a la tabla (Goto- Table “next-table-id”): Indica la siguiente tabla en el procesado. El identificador de la siguiente tabla debe ser mayor que el de la actual. Las entradas del flujo de la última tabla no pueden incluir esta instrucción. Solo se permite una instrucción por cada tipo. Los switches OpenFlow con una tabla no lo necesitarán.
Las instrucciones de la tabla de flujos modifican la acción asociada a cada pa- quete. Los paquetes empiezan a procesarse con un conjunto de acciones vacío. Las acciones pueden especificar que el paquete que se va a reenviar a través de un puerto específico, modificar el TTL, VLAN, etiqueta MPLS o la QoS.
Además, una instrucción puede especificar un identificador de grupo. Se pueden definir en el switch mediante entradas en la tabla de grupo Las instrucciones de la primera tabla deberán realizar una acción en el paquete o añadir acciones que se realizarán después. Las instrucciones asimismo, deberán permitir que el procesado de paquetes continúe comparándolos con las entradas de otras tablas de flujos.
3.2.4. Counters
Los contadores están mantenidos por tabla, por flujos, por puertos y por cola. Los contadores pueden estar implementados por software y mantenidos por contadores por hardware que tienen rangos más limitados.
La tabla 3.2 contiene el conjunto de contadores requeridos [10]. Duration hace referencia a el tiempo que un flujo ha estado instalado en un switch. Los campos Receive Errors incluyen todos los errores específicos, incluyendo frame, overrun y errores de CRC además de algunos otros.
3.2.5. Mensajes del protocolo OpenFlow
El protocolo consiste en 3 tipos de mensajes: controlador a switch, asíncrono y asimétrico. Controlador a switch se envían para:
Especificar, modificar o borrar definiciones de flujos.
Solicitar información acerca de las capacidades del switch.
Obtener información como los contadores del switch.
Enviar paquetes de vuelta al switch para su procesamiento después de que un nuevo flujo se ha creado.
Mensajes asíncronos se envían al switch para:
3 OpenFlow
Counter Bits
Per Table
Active Entries 32
Packet Lookups 64
Packet Matches 64
Per Flow
Receives Packets 64
Received Bytes 64
Duration (seconds) 32
Duration (nanoseconds) 32 Per Port
Received Packets 64
Transmitted Packets 64
Received Bytes 64
Transmitted Bytes 64
Receive Drops 64
Transmit Drops 64
Receive Errors 64
Transmit Errors 64
Receive Frame Alignmet Errors 64 Receive Overrun Errors 64
Receive CRC Errors 64
Collisions 64
Per Queue
Transmit Packets 64
Transmit Bytes 64
Transmit Overrun Errors 64
Tabla 3.2: Lista requerida de contadores para usar en mensajes de estadísticas
3.2 Funcionamiento de OpenFlow Ingress Port Ether Src Ether Dst Ether type VLAN id VLAN Priority IP src IP dst IP proto IP Tos TCP/UDP src port TCP/UDP dst port
Tabla 3.3: Campos de los paquetes usados para matching
Enviar al controlador el paquete que no coincide con los flujos existentes.
Informar al controlador que el flujo ha sido eliminado porque su parámetro TTL o el timer de inactividad han vencido.
Informar al controlador de un cambio en el estado de un puerto o de un error que ha ocurrido en un switch. Ejemplos de estas circunstancias son cuando los links se caen o cuando un paquete llega con una instrucción de reenvío no especificada.
Mensajes simétricos pueden ser enviados por el switch o el controlador y se usan para:
Los mensajes de hello que se intercambian el controlador y el switch al co- mienzo.
Mensajes de echo usados para determinar la latencia de la conexión controlador- switch y para verificar que esta conexión sigue operativa.
Mensajes experimentales para proveer un camino para futuras extensiones de la tecnología OpenFlow.
3.2.6. Matching
Cuando se recibe un paquete el Switch OpenFlow realiza las acciones que se ven en la figura 3.2 [10]. El switch comienza haciendo una búsqueda en la primera tabla de flujo. Las tablas de flujos se numeran empezando por el cero, y basado en esta primera búsqueda realizara búsquedas en otras tablas de flujo.
A los campos de la tabla 3.3 que coinciden con alguna entrada se les extrae del paquete. Los campos que se utilizan para buscar coincidencias dependen del tipo del paquete y típicamente incluyen varios campos de cabecera, las coincidencias también se pueden hacer en base al puerto de entrada o por campos de metadatos.
Los metadatos se usarán para poder mandar información entre las tablas en un switch. Un paquete coincide con una entrada de la tabla de flujos si los valores de los campos del paquete que se usan para la búsqueda están definidos en la misma.
3 OpenFlow
Si tiene un valor ANY (omitido), coincidirá con todos los valores posibles en la cabecera. Si el switch trabaja con mascaras arbitrarias para campos específicos se podrá afinar mucho más las coincidencias. El paquete solo coincidirá también tiene la prioridad más alta Los contadores asociados a la tabla seleccionada deben ser actualizados y el set de instrucciones incluido en el flujo seleccionado, será aplicado.
Si hay múltiples coincidencias y todas tienen configuradas la misma prioridad, la entrada de flujo seleccionada esta explícitamente indefinida. Está especificación no tiene en cuenta si el switch recibe un paquete corrupto o con un formato que no es el adecuado.
Figura 3.2: Proceso de matching
3.3. Probando OpenFlow
3.3.1. Explicación teórica.
Veamos como se comportaría un switch OpenFlow (S1 ), en el supuesto de que el host H1 realizara una petición a un servidor HTTP alojado en el host H4 [11]. Ver
3.3 Probando OpenFlow
Figura 3.3: Topología
figura 3.3.
H1 envía un paquete SYN para intentar iniciar la conexión. Cuando llega a S1 realiza el proceso de matching (figura 3.2), en esencia lo que hace es buscar si hay alguna entrada de flujo de la tabla de flujo cuyo campo match coincida con la ca- becera del paquete SYN. En este caso, al ser el primer paquete que recibe S1, este todavía no tiene instalado ningún flujo por lo que opta por enviar un PACKET_IN al controlador, el cual contiene entre otros campos el buffer_id, que está generado de forma secuencial, además de el paquete SYN original. Figura 3.4.
Ahora el controlador se encarga de procesar el PACKET_IN. En esta parte es cuando entra en escena la labor del programador que tiene que encargarse de decidir que hacer con el PACKET_IN. Por ejemplo se podrían uno de estos dos casos o los dos a la vez:
1. Simplemente decirle a S1 que envíe el paquete que recibió el controlador por el puerto 4 de S1. Para esto el controlador envía un PACKET_OUT (ver
3 OpenFlow
Figura 3.4: PACKET_IN
3.3 Probando OpenFlow
Figura 3.5: PACKET_OUT a
figura 3.5) el cual contiene el paquete original, el mismo buffer_id que contenía el PACKET_IN y una acción que indica que el paquete se envíe por el puerto 4.
2. Enviarle a S1 un paquete FLOW_MOD (ver figura3.6) indicándole que instale un flujo (flow) el cual diga que todos los paquetes en cuya cabecera figure el puerto TCP 80 y que lleguen por el puerto eth1, que corresponde con H1 (estas dos opciones formarían el campo MATCH, en este caso lo formarían los campos Ingress Port y TCP dst Port. Tabla 3.3) sean enviados por por el puerto eth4, que corresponde con H4 (esto formaría el campo ACTION ).
Además se añaden otros datos más indicados en la figura 3.6.
Posteriormente el paquete SYN llegará a su destinatario.
Una vez el paquete SYN ha llegado H4 envía de vuelta el paquete SYN/ACK.
Una vez más el controlador tendrá que decidir que hacer con este paquete, ya que no encuentra ninguna referencia en su tabla de flujos. Así que podremos realizar las
3 OpenFlow
Figura 3.6: FLOW_MOD a
3.3 Probando OpenFlow
Figura 3.7: PACKET_OUT b
dos mismas acciones descritas anteriormente pero en sentido inverso. Figuras 3.7 y 3.8.
Finalmente los mensajes restantes, encontrarán una entrada de flujo de acuerdo a sus cabeceras, por lo que los paquetes serán redirigidos directamente sin necesidad de que S1 tenga que comunicarse con el controlador. Ver figura 3.9.
En la figura 3.10 podemos observar como efectivamente primero llega un PAC- KET_IN al controlador y este se encarga de instalar un flujo mediante un mensaje FLOW_MOD. Esto ocurre en los dos sentidos por los que viaja el paquete.
3 OpenFlow
Figura 3.8: FLOW_MOD b
3.3 Probando OpenFlow
Figura 3.9: Ultimos paquetes
3 OpenFlow
Figura 3.10: Wireshark Packet-in y Flow-mod
4 Software utilizado
4.1. Controladores
Como hemos visto anteriormente un controlador básicamente añade y elimina entradas en la tabla de flujos. Existen numerosos controladores disponibles para OpenFlow pero nos centraremos solo en algunos de ellos. Se ha llegado a la con- clusión de que finalmente se usará OpenDaylight, debido a la mayor cantidad de documentación, ejemplos e información disponible, que hará más sencilla la tarea de desarrollar un programa para el controlador.
4.1.1. OpenDaylight
OpenDaylight [12] es un proyecto open-source. Se trata de un controlador imple- mentado en software contenido dentro de su propia máquina virtual de Java (JVM).
Como tal, puede ser desplegado en cualquier plataforma que soporte Java. El contro- lador contiene APIs abiertas que son utilizadas por las aplicaciones. OpenDaylight soporta el framework OSGi y REST bidireccional.
El framework OSGi se utiliza para las aplicaciones que se ejecutan en el mismo espacio de direcciones que el controlador mientras que REST API se utiliza para aplicaciones que no se ejecutan en el mismo espacio de direcciones que el controlador.
La lógica de negocio y los algoritmos residen en las aplicaciones. Estas aplicaciones utilizan el controlador para reunir la inteligencia de red, ejecutar algoritmos para realizar análisis y, seguidamente, usar el controlador para crear nuevas reglas a tra- vés de la red.
El propio controlador contiene una colección de módulos enlazables dinámicamen- te para realizar tareas de red. Hay una serie de servicios de red base para tareas como ver que los dispositivos se encuentran dentro de la red y sus capacidades, la recopilación de estadísticas, etc. Además otros servicios y extensiones pueden ser añadidos al controlador para aumentar la funcionalidad SDN.
La interfaz de bajo nivel es capaz de soportar múltiples protocolos (plugins se- parados) como OpenFlow 1.0, OpenFlow 1.3, BGP-LS, etc. Estos módulos están
4 Software utilizado
Figura 4.1: OpenDaylight Helium
dinámicamente conectados a la Service Abstraction Layer (SAL). La SAL contiene servicios de dispositivos para los módulos de niveles más altos. La SAL determina cómo cumplir con el servicio solicitado, independientemente del protocolo utilizado entre el controlador y los dispositivos de red.
El controlador ofrece una serie de core bundles, cada uno de ellos exporta servicios importantes a través de Java Interfaces. En la tabla 4.1 se ofrece una lista de algunos bundles importantes que ofrece a la hora de desarrollar servicios de red. Cada una de estas interfaces ofrece una serie de métodos [13] que dan facilidad a para el desarrollo de los servicios de red en Java, más adelante se explicará algunos de estos métodos más importantes. Para más información [14, 15].
AD-SAL vs MD-SAL
La SAL no es más que cruce que conecta el plugin del protocolo y los Módulos de Función de Red (Topology Manager, Statistics Manager, Switch Manager... ). Las API SAL son los contratos a los que los plugins de protocolo y los módulos de NFS
4.1 Controladores
Bundle Interface exportadora Descripción
arphandler IHostFinder Componente responsable del aprendizaje de las localizaciones del los hosts
usando ARP.
hosttracker IfIptoHost Localiza los hosts relativos a la red SDN.
switchmanager ISwitchManager Componente que maneja el inventario de información de
todos los nodos (switches) conocidos por el controlador.
topologymanager ITopolgyManager Maneja el grafo de la red completa.
statisticsmanager IStatisticsManager Componente a cargo de usar el ReadService del SAL que colecta todas las estadísticas
de la red SDN
sal IReadService Interface que provee la vista
hardware de los flujos, colas, puertos de los nodos de red.
sal ITopolgyService Métodos de topología
proporcionados por SAL hacia las aplicaciones.
sal IFlowProgrammerService Interface para instalar, modificar o eliminar flujos en
los nodos de red.
sal IDataPacketService Servicios de paquetes de datos de SAL provistos para
las aplicaciones.
Tabla 4.1: Bundles importantes de OpenDaylight
4 Software utilizado
se adhieren con el fin de ser capaz de hablar el uno al otro.
En la tabla 4.2 se comparan AD-SAL y MD-SAL [16]. Se ha optado por usar AD-SAL ya que se ha encontrado un mayor número de documentación y ejemplos varios, en contraposición con MD-SAL que siendo más reciente es más complicado encontrar ejemplos concretos.
4.1.2. Ryu
Ryu es un componentes básico de las redes definidas por software. Provee de componentes software, las API que facilitan a los desarrolladores la tarea de crear aplicaciones de control y gestión de la red. Ryu soporta varios protocolos para la gestión de dispositivos de red, como OpenFlow, Netconf, OF-config, etc. En cuanto a OpenFlow, Ryu soporta totalmente las versiones 1.0, 1.2, 1.3, 1.4 y las Nicira Ex- tensions. Además Ryu posee certificaciones para trabajar en dispositivos de distintas marcas.
Todo el código esta disponible libremente a través de la licencia Apache 2.0. Ryu está totalmente escrito en Python. Ryu significa «flow» en japonés. Ryu posee gran cantidad de documentación, ordenada, y fácil de comenzar a utilizar. Para más información[17, 18].
4.1.3. Floodlight
El controlador SDN Floodlight es un controlador de clase empresarial, está dispo- nible con licencia Apache para casi cualquier propósito. Es apoyado por una gran co- munidad de desarrolladores que incluyen ingenieros de Big Switch Networks. Flood- light está diseñado para trabajar con un gran numero de switches, routers, switches virtuales y puntos de acceso compatibles con el protocolo OpenFlow. Es un siste- ma multiplataforma ya que funciona sobre la máquina virtual de Java. Para más información[19]
4.1.4. NOX/POX
NOX es una pieza del ecosistema de las Redes Definidas por Software (SDN). Es- pecíficamente es una plataforma para crear aplicaciones de control de red. De hecho mientras que ahora llamamos SDN a un número creciente de proyectos académicos, la primera tecnología en ser realmente conocida por SDN fue Openflow y NOX fue inicialmente desarrollada por Nicira Networks codo con codo con OpenFlow (NOX fue el primer controlador SDN). Nicira donó NOX a la comunidad de desarrolladores
4.1 Controladores
AD-SAL MD-SAL
API-Driven SAL Model-Driven SAL
The SAL APIs, request routing between consumers and providers, and data adaptations are all statically defined at compile/build time.
The SAL APIs, request routing between consumers and providers are defined from models, and data adaptations are provided by
‘internal’ adaptation plugins.
The AD-SAL typically has both NB and SB APIs even for functions/services that are mapped 1:1 between SB Plugins and NB
Plugins.
The MD-SAL allows both the NB plugins and SB plugins to use the same API generated from
a model. One plugin becomes an API (service) provider; the other becomes an API (service)
Consumer.
In AD-SAL there is a “dedicated” REST API for each northbound/southbound plugin.
MD-SAL provides a “common” REST API to access data and functions defined in models . he AD-SAL provides request routing (selects an
SB plugin based on service type) and optionally provides service adaptation, if an NB (Service,
abstract) API is different from its corresponding SB (protocol) API.
The MD-SAL provides request routing and the infrastructure to support service adaptation,
but it does not provide service adaptation itself; service adaptation is provided by plugins.
Request routing is based on plugin type: the SAL knows which node instance is served by which plugin, and when an NB Plugin requests
an operation on a given node, the request is routed to the appropriate plugin which then routes the request to the appropriate node.
Request Routing in the MD-SAL is done on both protocol type and node instances, since node instance data is exported from the plugin
into the SAL.
AD-SAL is stateless MD-SAL can store data for models defined by plugins: provider and consumer plugins can exchange data through the MD-SAL storage Limited to flow-capable device and service
models only
Model agnostic. It can support any device and/or service models and is not limited to flow-capable device and service models only AD-SAL services usually provide both
asynchronous and synchronous versions of the same API method.
In MD-SAL, Service model APIs only provide asynchronous APIs, but they return a
‘java.concurrent.Future’ object, which allows a caller to block until the call is processed and a result object is available. Same API can be used for both synchronous and asynchronous
approach. Thus MD-SAL encourages asynchronous approach to application design but does not preclude synchronous applications.
Tabla 4.2: AD-SAL vs MD-SAL
4 Software utilizado
Figura 4.2: Floodligh
4.2 Mininet en el año 2008, y desde entonces ha sido la base para muchos proyectos en el ini- cio de las SDN. NOX provee a un desarrollador de una API C++ para OpenFlow 1.0.
POX es el hermano pequeño de NOX. En esencia, es una plataforma para el rápi- do desarrollo y prototipado para el control de la red por software utilizando Python.
Es uno de un número creciente de frameworks para SDN (incluyendo NOX, Flood- light, Opendaylight...) con el fin de prestar ayuda para programar un controlador OpenFlow. POX además va más allá de eso.
Para más información acerca de NOX y POX [20].
4.2. Mininet
Mininet [21] es un emulador de red que ejecuta una colección de dispositivos fina- les, switches, routers y enlaces en un solo core de Linux. Se utiliza la virtualización ligera para hacer que un solo sistema parezca una red completa. Los programas que se ejecutan pueden enviar paquetes a través de lo que parece ser una interfaz de Et- hernet real, con una velocidad de enlace y con retardo. Los paquetes se procesan por lo que parece un verdadero interruptor de Ethernet, un enrutador o middlebox, con una determinada cantidad de colas. Cuando dos programas, como un iperf cliente y el servidor, se comunican a través mininet, el rendimiento medido debe coincidir con el de dos máquinas nativas más lentas. En resumen, los dispositivos virtuales de mininet, conmutadores, enlaces y los controladores se crean utilizando software en lugar de hardware, en su mayor parte el comportamiento es similar a los elementos de hardware.
4.2.1. Ventajas e inconvenientes de Mininet
Mininet presenta una serie de ventajas e inconvenientes al simular una red, las cuales se presentan a continuación.
Ventajas
Rápido: la puesta en marcha de una red simple tarda sólo unos segundos.
Esto significa que el bucle de gestión edit-debug puede ser muy rápido.
Se pueden crear topologías personalizadas: un solo switch, grandes topo- logías tipo Internet...
Puede correr programas reales: puede correr cualquier programa que se pueda ejecutar en Linux.
4 Software utilizado
Compartir resultados: al ser un sistema cerrado es fácil compartir el código y ejecutarlo en distintas máquinas.
Se pueden ejecutar experimentos simples escritos en Python, por ejemplo un servidor web simple usando un pequeño comando.
Inconvenientes
Todos los hosts mininet comparten el mismo sistema de archivos y el espacio PID.
Actualmente mininet no hace NAT fuera de su sistema. Los host no pueden hablar directamente a Internet a menos que proporcione un medio para que lo hagan (se pueden configurar los hosts mininet para que tengan conectividad externa o para añadirles una interfaz física).
Lo más importante que se tiene que tener en cuenta para los experimentos de red, es que probablemente habrá que utilizar enlaces más lentos, por ejemplo 10 o 100 Mb/s en lugar de 10 Gb/s, debido al hecho de que los paquetes son transmitidos por un conjunto de conmutadores de software, los recursos de la CPU que compar- ten la memoria, y por lo general tienen un menor rendimiento que el hardware de conmutación dedicado [6].
4.2.2. vSwitch
Open vSwitch es un sistema de switch virtual, diseñado específicamente para ha- bilitar automatización y despliegue de interfaces de red de manera programada, ade- más soporta su distribución alrededor de múltiples servidores físicos, lo que lo hace ideal para la construcción de esquemas de redes virtuales para nubes. OpenVSwitch es el esquema por defecto de gestión de redes de Mininet y se incluye preinstalado en la máquina virtual de Mininet.
4.3. Wireshark
Wireshark [22, 23], antes conocido como Ethereal, es un analizador de protocolos utilizado para realizar análisis y solucionar problemas en redes de comunicaciones, para desarrollo de software y protocolos, y como una herramienta didáctica. Cuenta con todas las características estándar de un analizador de protocolos de forma úni- camente hueca.
La funcionalidad que provee es similar a la de tcpdump, pero añade una interfaz gráfica y muchas opciones de organización y filtrado de información. Así, permite ver
4.4 Iperf todo el tráfico que pasa a través de una red (usualmente una red Ethernet, aunque es compatible con algunas otras) estableciendo la configuración en modo promiscuo.
También incluye una versión basada en texto llamada tshark.
Permite examinar datos de una red viva o de un archivo de captura salvado en disco. Se puede analizar la información capturada, a través de los detalles y sumarios por cada paquete. Wireshark incluye un completo lenguaje para filtrar lo que queremos ver y la habilidad de mostrar el flujo reconstruido de una sesión de TCP.
4.4. Iperf
Iperf [24, 25] es una herramienta que se utiliza para hacer pruebas en redes infor- máticas. El funcionamiento habitual es crear flujos de datos TCP y UDP y medir el rendimiento de la red. Iperf fue desarrollado por el Distributed Applications Support Team (DAST) en el National Laboratory for Applied Network Research (NLANR) y está escrito en C++.
Iperf permite al usuario ajustar varios parámetros que pueden ser usados para hacer pruebas en una red, o para optimizar y ajustar la red. Iperf puede funcionar como cliente o como servidor y puede medir el rendimiento entre los dos extre- mos de la comunicación, unidireccional o bidireccionalmente. Es software de código abierto y puede ejecutarse en varias plataformas incluyendo Linux, Unix y Windows.
UDP: Cuando se utiliza el protocolo UDP, Iperf permite al usuario especificar el tamaño de los datagramas y proporciona resultados del rendimiento y de los paquetes perdidos.
TCP: Cuando se utiliza TCP, Iperf mide el rendimiento de la carga útil. Un de- talle a tener en cuenta es que Iperf usa 1024*1024 para medidas en megabytes y 1000*1000 para megabits.
4.5. Eclipse
Eclipse [26, 27] es un programa informático compuesto por un conjunto de herra- mientas de programación de código abierto multiplataforma para desarrollar lo que el proyecto llama "Aplicaciones de Cliente Enriquecido", opuesto a las aplicaciones
"Cliente-liviano" basadas en navegadores. Esta plataforma, típicamente ha sido usa- da para desarrollar entornos de desarrollo integrados (del inglés IDE), como el IDE
4 Software utilizado
de Java llamado Java Development Toolkit (JDT) y el compilador (ECJ) que se entrega como parte de Eclipse (y que son usados también para desarrollar el mismo Eclipse).
Eclipse fue desarrollado originalmente por IBM como el sucesor de su familia de herramientas para VisualAge. Eclipse es ahora desarrollado por la Fundación Eclipse, una organización independiente sin ánimo de lucro que fomenta una comunidad de código abierto y un conjunto de productos complementarios, capacidades y servicios.
Se ha usado la versión Eclipse IDE for Java Developers1 para MAC OS X de 64 bits ya que contiene la herramienta Maven preinstalada.
4.5.1. Maven
Maven [28, 29] es una herramienta de software para la gestión y construcción de proyectos Java creada por Jason van Zyl, de Sonatype, en 2002. Es similar en funcio- nalidad a Apache Ant (y en menor medida a PEAR de PHP y CPAN de Perl), pero tiene un modelo de configuración de construcción más simple, basado en un formato XML. Estuvo integrado inicialmente dentro del proyecto Jakarta pero ahora ya es un proyecto de nivel superior de la Apache Software Foundation.
Maven utiliza un Project Object Model (POM) para describir el proyecto de soft- ware a construir, sus dependencias de otros módulos y componentes externos, y el orden de construcción de los elementos. Viene con objetivos predefinidos para realizar ciertas tareas claramente definidas, como la compilación del código y su empaquetado.
4.6. Uso del software
4.6.1. Mininet
Como hemos comentado anteriormente, Mininet [21] es un software que nos per- mite emular una red que usa el protocolo OpenFlow. La forma de puesta en marcha de Mininet más sencilla es usar la máquina virtual que se proporciona en su página web, esta contiene el Mininet propiamente dicho, todos los binarios OpenFlow y más herramientas preinstaladas (p.e. Wireshark) y modificaciones de la configuración del kernel que dan soporte a redes Mininet más complejas. Se puede descargar la versión
1Descarga Eclipse IDE for Java Developershttp://www.eclipse.org/downloads/packages/eclipse- ide-java-developers/marsr
4.6 Uso del software
Figura 4.3: Mininet VM ifconfig
más reciente desde el siguiente enlace 2.
En nuestro caso usaremos la versión «Mininet 2.2.1 on Ubuntu 14.04 64 bits». Pa- ra la ejecución de la máquina virtual se usara el software de virtualización VMware.
En mi caso he configurado la VM una interfaz de red en modo bridge para poder tener acceso desde cualquier punto de mi red.
Ya que la VM no incluye interfaz gráfica la forma más cómoda de manejar Mininet es a través de SSH. En nuestro caso accederemos desde OS X 10.10 así que no habrá que instalar nada adicional ya que viene con un cliente ssh instalado, desde Windows podemos usar cualquier cliente SSH disponible (p.e. Putty). Antes de todo habrá que mirar con el comando ifconfig la dirección IP de la VM Mininet, el nombre de usuario y la contraseña son mininet (Figura 4.3).
Para acceder a la máquina virtual abrimos una terminal y usamos el siguiente comando e introducimos la contraseña «mininet»:
2Descargar Mininet VMhttps://github.com/mininet/mininet/wiki/Mininet-VM-Images
4 Software utilizado
$ ssh -Y mininet@«ip_mininet»
La opción -Y permite ejecutar interfaz gráfica usando el servidor X11 de la má- quina remota que nos servirá para poder abrir ventanas adicionales o para poder usar Wireshark y MiniEdit. Para poder usarlo necesitamos tener instalado el soft- ware XQuartz 3 para OS X o bien Xming4 para Windows, en Linux X11 viene por defecto.
CLI
Una vez dentro de la máquina remota usaremos el siguiente comando para iniciar Mininet (Figura 4.4).
$ sudo mn
Con ello ya estaremos ejecutando mininet. Mininet por defecto carga una topolo- gía simple con un controlador c0 conectado a un switch s1 y a este dos hosts, h1 y h2 (ver Figura 4.5).
Es posible añadir más opciones al comando que nos permitirán personalizar nues- tra red. Por ejemplo el siguiente comando cargaría una red en árbol de dos niveles de switches Open vSwitch, además indicamos que se conecte a un controlador remoto y su dirección ip.
$ sudo mn --switch=ovsk --topo=tree,2 --controller=remote,ip=192.168.1.3
Ahora dentro del CLI podemos realizar varias acciones. Por ejemplo podemos comprobar la conectividad de la red con el comando pingall que mandará un ping desde todos los host de la red a todos los host restantes, o bien podemos usar el comandodump para visualizar los dispositivos que esta nuestra red. Además poniendo el nombre del dispositivo seguido de un espacio y un comando de unix, podremos ejecutar comandos en los dispositivos directamente desde la consola de Mininet (ej.
h1 ping h2). Para salir usaremos el comando exit. Para más información [30]).
3Descargar XQuartzhttp://xquartz.macosforge.org/landing/
4Descargar Xming http://sourceforge.net/projects/xming/
4.6 Uso del software
Figura 4.4: mininet>
4 Software utilizado
Figura 4.5: Topología simple Mininet
Topologías
Mininet permite ejecutar algunas topologías predefinidas usando algunos paráme- tros en el CLI. Por ejemplo el siguiente comando nos permitirá cargar una topología en árbol de dos niveles:
$ sudo mn --topo=tree,2
Más interesante aun es la posibilidad de crear topologías personalizadas. La for- ma más sencilla es usar MiniEdit, que es un programa escrito en python que nos permite hacer eso mismo de forma gráfica. Este mismo ha sido usado para crear las topologías que usaremos más adelante. Para ejecutarlo basta con lanzarlo como cualquier script python, en concreto en nuestra máquina virtual de Mininet se haría con el siguiente comando:
$ sudo ~/mininet/examples/miniedit.py
4.6 Uso del software
Nos abrirá una ventana como esta (Figura 4.6) que nos permitirá añadir los swit- ches OpenFlow, los hosts, el controlador así como sus enlaces. También podremos modificar todas sus características. Algo importante que debemos hacer es decirle que el controlador es remoto, para ello, simplemente haremos click derecho en el icono del controlador, pinchamos en Properties y en Controller Type elegimos Re- mote Controller. Además debemos cambiar la dirección IP por la del host donde se iniciará OpenDaylight (Figura 4.7). También indicarle a MiniEdit que cuando lancemos el script python de Mininet nos cargue el CLI para que podamos trabajar desde su consola, para hacer esto debemos ir a Edit, Preferences y seguidamente marcar la casilla Start CLI (Figura 4.8). Para más información acerca de como usar MiniEdit [31].
Una vez tengamos nuestra topología creada la guardaremos y la exportaremos a Level 2 Script que nos creará un script python de mininet, el cual simplemente lanzaremos y tendremos nuestro mininet listo. Para ello primero habrá dar permisos de ejecución al archivo que exportamos y seguidamente podremos ejecutar el script:
$ sudo chmod +x nombre_script.py
$ sudo ./nombre_script.py
4.6.2. Wireshark
Para este trabajo, usaremos el software Wireshark [23] que nos permitirá visua- lizar los paquetes de nuestra red. Wireshark está incluido en la máquina virtual de mininet. Este incluye un plugin para OpenFlow que permite visualizar los paquetes de forma mucho más ordenada, además también permite el filtrado de estos. Para filtrar los paquetes OpenFlow usaremos el código «of». Más adelante veremos como se inicia la conexión en el protocolo OpenFlow visualizando los paquetes mediante este plugin.
Iniciar Wireshark
Para ejecutar Wireshark (Figura 4.9) basta con lanzarlo usando el siguiente co- mando en la máquina de Mininet:
$ sudo wireshark&
4 Software utilizado
Figura 4.6: Topología con MiniEdit
4.6 Uso del software
Figura 4.7: Controlador remoto MiniEdit
Figura 4.8: Activar CLI MiniEdit
4 Software utilizado
Figura 4.9: Ventana de Wireshark
4.6 Uso del software
4.6.3. OpenDaylight
Como hemos dicho anteriormente, OpenDaylight [12] es un controlador OpenFlow escrito en Java. En nuestro caso hemos usado la versión base que es la más sencilla de usar, ya que desde el principio está todo montado y no es necesario instalar más cosas. En concreto usaremos una versión modificada de SDN Hub [32], ya que es más liviana que la versión original ya que solo incluye los módulos necesarios para la ejecución de nuestro programa. Esta versión se incluye en los archivos externos entregados junto a la documentación. Para lanzar el controlador nos iremos a la carpeta de OpenDaylight y ejecutaremos el comando (Figura 4.10):
$ ./run.sh
Es posible que previamente haya que dar permisos de ejecución, si esto ocurre, usaremos el siguiente comando para solucionar esto:
$ sudo chmod +x run.sh
Más adelante veremos más a fondo como usar el controlador OpenDaylight comu- nicándolo con la máquina de Mininet para nuestro caso concreto.
4 Software utilizado
Figura 4.10: Controlador OpenDaylight iniciándose
5 Caso práctico: Mejora de la
eficiencia energética en una red SDN
5.1. Explicación teórica
Se ha desarrollado un módulo para OpendayLight llamado flowApp que intenta mejorar la eficiencia energética de redes de switches utilizando para ello tecnología SDN. En concreto usaremos Opendaylight y Mininet (que incluye switches Open- Flow). Se usarán tres topologías distintas para comprobar el grado de mejora en cada una de ellas. Estas son, topología en malla (figura 5.1), topología en anillo (fi- gura 5.2) y topología en árbol (figura 5.3). A continuación pasaremos a explicar los códigos fuentes del módulo OpenDaylight programado en Java y de las topologías de Mininet escritas en Python.
El gasto energético de una interfaz de red es proporcional al throughtput de esa interfaz. Al aumentar el throughtput también aumentará el gasto energético de la forma que se indica en la tabla, de forma que prácticamente una interfaz de red con un throughput de 1000Mpbs (que diremos que está en nivel 2) tiene solamente el doble del gasto energético de una interfaz con un throughtput de 100Mbps (di- remos que está en nivel 1), de modo que lo que se pretende es que la mayoría de las conexiones estén en nivel 2 lo que hará que haya mayor numero de interfaces en StandBy (que son las que menos gasto energético tienen) . El módulo se encarga de calcular las rutas energéticamente óptimas entre dos hosts y de instalarlas en la red, permitiendo la comunicación en cualquier topología de red SDN.
El módulo flowApp permite la configuración de distintos parámetros. Entre ellos se encuentran tres importantes que nos permitirán cambiar los costes (usados por el algoritmo shortest path de Dijkstra) dados a cada nivel energético (StandBy, Nivel1 o Nivel2). Así el módulo se encargará de calcular las rutas más óptimas energética- mente hablando. Variando estos valores conseguiremos modificar el comportamiento del ahorro energético, consiguiendo más ahorro energético (se usarían menos enla- ces) repercutiendo en el aumento del throughtput total de la red, para conseguir
5 Caso práctico: Mejora de la eficiencia energética en una red SDN
Figura 5.1: Topología en malla
esto deberíamos asignarle un valor alto a las interfaces en StandBy, un valor medio a las interfaces Nivel1 y un valor bajo a las interfaces Nivel2, así intentaríamos usar lo menos posible las interfaces en StandBy. Si asignáramos el mismo coste a to- dos los niveles permitiríamos que la red se comporte de forma normal sin conseguir eficiencia energética y, simplemente, consiguiendo forwarding entre host usando el controlador.
5.1.1. Desarrollo del código: Java
Algoritmo de Dijkstra
El algoritmo de Dijkstra (ver algorítmo 5.1), también llamado algoritmo de ca- minos mínimos, es un algoritmo para la determinación del camino más corto dado un vértice origen al resto de los vértices en un grafo con pesos en cada arista. Su nombre se refiere a Edsger Dijkstra, quien lo describió por primera vez en 1959.
La idea subyacente en este algoritmo consiste en ir explorando todos los caminos más cortos que parten del vértice origen y que llevan a todos los demás vértices;
cuando se obtiene el camino más corto desde el vértice origen, al resto de vértices
5.1 Explicación teórica
Figura 5.2: Topología en anillo
5 Caso práctico: Mejora de la eficiencia energética en una red SDN
Figura 5.3: Topología en árbol
5.1 Explicación teórica Algoritmo 5.1 Algoritmo de Dijkstra
Require: Directed network G = (V, E, w), with non-negative edge weights and source s ∈ V .
Ensure: Array µ(· ) of length n, where µ(u) is the maximum reliability for each u ∈ V , and array pred(· ) of length n, where pred(u) is the parent of vertex u in the shortest path tree rooted at s.
S = ∅; S0 = V for every u ∈ V do
µ(P ) = 0;
end for
µ(s) = 1; pred(s) = 0;
while |S| < n do
let u ∈ S0 be the vertex for which µ(u) = minu∈S0{d(u)};
S = S ∪ {u}; S0 = S0− {u};
for ∀(u, w) ∈ E do
if µ(w) < µ(u)· wt(u, w) then µ(w) = µ(u)· wt(u, w) end if
end for end while
que componen el grafo, el algoritmo se detiene. El algoritmo es una especialización de la búsqueda de costo uniforme, y como tal, no funciona en grafos con aristas de coste negativo (al elegir siempre el nodo con distancia menor, pueden quedar exclui- dos de la búsqueda nodos que en próximas iteraciones bajarían el costo general del camino al pasar por una arista con costo negativo) [33].
Consideraciones previas.
Durante la explicación del código hay que tener en cuenta que:
Los enlaces es llaman edges indistintamente, ya que es el nombre que toma este objeto en OpenDaylight.
De la misma forma, un nodo (node) es lo mismo que un switch.
Un nodeConnector a su vez es un puerto de un switch.
