Analisi y Evaluaciones de Las Redes Definidas Por Software

Universidad de ExtremaduraCentro Universitario de Mérida

Grado en Ingeniería en Telemática

Trabajo Fin de Grado

ANÁLISIS Y EVALUACIÓN DE LAS REDESDEFINIDAS POR SOFTWARE

Autor/a: Pablo Murillo Nogales

Mérida, Julio de 2015

Universidad de ExtremaduraCentro Universitario de Mérida

Grado en Ingeniería en Telemática

Trabajo Fin de Grado

ANÁLISIS Y EVALUACIÓN DE LAS REDESDEFINIDAS POR SOFTWARE

Autor/a: Pablo Murillo NogalesFdo:

Director/a: Javier Domingo Carmona MurilloFdo:

ResumenSoftware-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 propuestopor 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 losplanos abre la puerta a la virtualización de redes, proporcionando a los usuarios unaabstracción lógica de los recursos de red subyacentes.

La iniciativa Open Networking Foundation (ONF), está desarrollando estándaresabiertos que permitan alcanzar los retos planteados por SDN. El resultado es lograruna arquitectura que permita a los administradores de red tener un control total enel 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ándarSDN 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 enOpenDaylight. Además procederemos a desplegar una red de ejemplo mediante laherramienta Mininet que permite simular un entorno SDN. Después se ha realizadoun 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 elrendimiento 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 redaumenta.

5

6

AbstractLately, the emerging paradigm of Software-Defined Networking has grown in pre-

sence and claims to simplify future networking. The decoupling of network controland forwarding plane proposed by this architecture allows the control of the entirenetwork behavior by means of a logically centralized software program (controller).Such separation of planes opens the way to Network Virtualization, which providesusers a logical abstraction of underlying network resources.

Open Networking Foundation (ONF) is a user-driven organization dedicated tothe promotion and adoption of Software-Defined Networking (SDN) through openstandards development. Thus, network administrators, will be able to program andcontrol the forwarding plane of such networks in a new way.

In this work we analyze the SDN and the OpenFlow protocol and we see someof the different alternative controllers, and finally, we focus on OpenDaylight. Furt-hermore we proceed to create a sample network using Mininet to simulate a SDNenvironment. Finally a case study is performed to check more specifically how toprogram 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 theenergy consumption, although the network load is increased.

7

Índice general

1. Introducción 51.1. Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.3. Planificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.4. Estructura del documento . . . . . . . . . . . . . . . . . . . . . . . . 7

2. Software Defined Networking 92.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2. Concepto de SDN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.3. SDN y virtualización . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.4. Beneficios del SDN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.5. Usos de SDN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3. OpenFlow 133.1. Protocolo OpenFlow . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.2. Funcionamiento de OpenFlow . . . . . . . . . . . . . . . . . . . . . . 15

3.2.1. Flujos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.2.2. Tablas de flujos . . . . . . . . . . . . . . . . . . . . . . . . . . 163.2.3. Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.2.4. Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.2.5. Mensajes del protocolo OpenFlow . . . . . . . . . . . . . . . . 173.2.6. Matching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.3. Probando OpenFlow . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.3.1. Explicación teórica. . . . . . . . . . . . . . . . . . . . . . . . . 20

4. Software utilizado 294.1. Controladores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.1.1. OpenDaylight . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.1.2. Ryu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.1.3. Floodlight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.1.4. NOX/POX . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.2. Mininet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.2.1. Ventajas e inconvenientes de Mininet . . . . . . . . . . . . . . 35

i

Índice general

4.2.2. vSwitch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.3. Wireshark . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.4. Iperf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.5. Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.5.1. Maven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.6. Uso del software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.6.1. Mininet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.6.2. Wireshark . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.6.3. OpenDaylight . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5. Caso práctico: Mejora de la eficiencia energética en una red SDN 495.1. Explicación teórica . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.1.1. Desarrollo del código: Java . . . . . . . . . . . . . . . . . . . . 505.1.2. Desarrollo del código: Maven . . . . . . . . . . . . . . . . . . . 615.1.3. Desarrollo del código: Python . . . . . . . . . . . . . . . . . . 62

5.2. Funcionamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625.2.1. Configuración módulo flowApp . . . . . . . . . . . . . . . . . 625.2.2. Iniciando OpenDaylight . . . . . . . . . . . . . . . . . . . . . 665.2.3. Iniciando Mininet . . . . . . . . . . . . . . . . . . . . . . . . . 66

5.3. Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

6. Conclusiones y trabajo futuro 736.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 736.2. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

7. Agradecimientos 75

Bibliografía 77

ii

Índice de figuras

3.1. Esquema Openflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.2. Proceso de matching . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.3. Topología . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.4. PACKET_IN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.5. PACKET_OUT a . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.6. FLOW_MOD a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.7. PACKET_OUT b . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.8. FLOW_MOD b . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.9. Ultimos paquetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.10. Wireshark Packet-in y Flow-mod . . . . . . . . . . . . . . . . . . . . 28

4.1. OpenDaylight Helium . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.2. Floodligh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.3. Mininet VM ifconfig . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.4. mininet> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.5. Topología simple Mininet . . . . . . . . . . . . . . . . . . . . . . . . . 424.6. Topología con MiniEdit . . . . . . . . . . . . . . . . . . . . . . . . . 444.7. Controlador remoto MiniEdit . . . . . . . . . . . . . . . . . . . . . . 454.8. Activar CLI MiniEdit . . . . . . . . . . . . . . . . . . . . . . . . . . 454.9. Ventana de Wireshark . . . . . . . . . . . . . . . . . . . . . . . . . . 464.10. Controlador OpenDaylight iniciándose . . . . . . . . . . . . . . . . . 48

5.1. Topología en malla . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505.2. Topología en anillo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515.3. Topología en árbol . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525.4. dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615.5. Compilar con Maven . . . . . . . . . . . . . . . . . . . . . . . . . . . 635.6. Código python iperfUDP . . . . . . . . . . . . . . . . . . . . . . . . . 645.7. OpenDaylight configuración y monitor . . . . . . . . . . . . . . . . . 675.8. Topología en malla . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705.9. Topología en anillo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715.10. Topología árbol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

1

Índice de figuras

2

Índice de tablas

1.1. Metodología del trabajo . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.1. Principales componentes de una entrada en una tabla de flujo . . . . 163.2. Lista requerida de contadores para usar en mensajes de estadísticas . 183.3. Campos de los paquetes usados para matching . . . . . . . . . . . . . 19

4.1. Bundles importantes de OpenDaylight . . . . . . . . . . . . . . . . . 314.2. AD-SAL vs MD-SAL . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3

Índice de tablas

4

1 Introducción

1.1. AntecedentesLa 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, unared multisalto, semejante a las a las actuales WSN (Wireless Sensor Networks) cuyainnovación fue que en el campo de datos de cada paquete se incluían comandos quelos nodos iban ejecutando a medida que los iban recibiendo. De esta manera, la redpodía irse modificando de forma dinámica y en tiempo real. Fue un intento de definiruna red auto-organizable destinada a permitir la experimentación y la innovacióncon diferentes protocolos. No hubo desarrollo posterior, pero su idea fue el embriónde las posteriores Active Networks [3].

Las Active Networks presentaban una arquitectura consistente en llevar embebidoen 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 procesaranlos 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 unatendencia 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 elmismo: 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 loselementos de conmutación, como sí hace la filosofía SDN.

En 2007, un grupo de trabajo de la Universidad de Standford formado por losprofesores Nick McKeown, Scott Shenker y el estudiante de doctorado Martín Ca-sado desarrollaron OpenFlow y fundaron Nicira, una compañía de virtualización deredes. 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

5

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 gamade productos y compró Nicira por 1260 millones de dólares. Martín Casado pasó aser el "arquitect networking" en jefe de VMware [4].

1.2. ObjetivosLos 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 componentesbá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 paradigmaSDN frente a la gestión tradicional de la red.Además se ha desarrollado una aplicación con la que intentar mejorar la eficienciaenergética de las redes usando tecnologías SDN.

1.3. PlanificaciónMetodologí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.

6

1.4 Estructura del documento

Febrero Marzo Abril Mayo JunioTarea 1 XTarea 2 XTarea 3 XTarea 4 X XTarea 5 X X

Tabla 1.1: Metodología del trabajo

1.4. Estructura del documentoEste 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 laaplicación propuesta y del análisis de sus mediciones. El trabajo se ha estructuradoen cinco capítulos principales de la siguiente manera:

El Capítulo 2 presenta las Redes Definidas por Software. Se tratan de explicarcomo concepto y sus relaciones con la virtualización. Además se aportan una seriede beneficios de este tipo de redes. Por ultimo se explican algunos usos que puedentener las SDN.

En el Capítulo 3 se realiza un análisis del protocolo OpenFlow. Se explica elfuncionamiento de las distintas partes que lo componen y finalmente, se simula uncaso 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 controladorOpenDaylight que es el que se usará posteriormente para realización de la aplicaciónprá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 estasaplicaciones.

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 dichaaplicación.

Finalmente en el Capítulo 6 se harán las conclusiones pertinentes y una serie deposibles trabajos futuros a desarrollar relacionados con las SDN.

7

1 Introducción

8

2 Software Defined Networking

2.1. IntroducciónEl SDN (Software Defined Networking) es una técnica emergente que concentra

las funciones de control de la red en elementos software. Explicaremos el conceptode SDN, su relación con las técnicas de virtualización y sus beneficios, explorandotambién el concepto de Network Functions Virtualization (NFV) [5].

2.2. Concepto de SDNSDN 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 yque consiste, simplemente, en transportar datos a su destino. Para ello, estosequipos envían los paquetes de datos a dónde indiquen unas rutas previamentecalculadas.

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 transporteson ejecutadas de forma distribuida en todos los routers/swItches de la red. SDN esun 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 (enlugar de hacerlo en hardware). Además, centraliza en un elemento, el controladoresa función de control.

Resumimos pues los tres elementos que caracterizan al Software Defined Networ-king (SDN):

9


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 conllevaque la red se pueda programar mediante aplicaciones, lo que proporciona una enormeflexibilidad 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ónLa 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 mundodel networking sino que, de hecho, surgió más bien en el mundo de las Tecnologíasde la información, de los grandes servidores de aplicaciones y los data centers. Lavirtualización abstrae las máquinas reales, el hardware real, en lo que se denominala máquina virtual, esto es, una máquina ficticia implementada en software pero ala 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áquinaadaptada a sus necesidades pero del alguna forma independiente del hardware realque la soporta. Para crear y gestionar esas máquinas virtuales se emplea un softwareque 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 sentidode que las funciones de control centralizadas se suelen implementar como switchesvirtuales (es decir, la simulación de un switch en software) ejecutándose en máquinasvirtuales 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ónde funciones de red (Network Functions Virtualization, NFV). Lo que significa esteconcepto es la centralización de funciones de red en servidores de propósito generalvirtualizados. Así, por ejemplo, se pueden centralizar funciones en el campo de laseguridad AAA (Authentication, Authorization and Accounting).

2.4. Beneficios del SDN¿Qué aporta el SDN? Podríamos resumir los beneficios en los siguientes puntos:

10

2.5 Usos de SDN

Elimina la lentitud en innovación propia del hardware permitiendo que ésta seproduzca 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 mayorutilización de la capacidad de red.

2.5. Usos de SDNLas 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 controlpersonalizado y una oportunidad para de eliminar middleboxes y con ello simplificarel 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 entornosempresariales. Las redes SDN pueden ser usadas para manejar las políticas dered mediante programación. Las SDN pueden manejar funciones de middleboxcomo 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 eficienciaenergética a través de métodos para usar solo una parte de la red, intentandoque esto no repercuta en la eficiencia de la red. Más adelante nosotros tambiénabordaremos este problema [7].

Redes ópticas: Manejar el trafico de datos mediante flujos, permite a las SDNy a OpenFlow en particular, soportar e integrar múltiples tipos de tecnologíasde red. De acuerdo a el Optical Transport Working Group (OTWG) creadoen 2013 por la Open Network Foundation (ONF), los beneficios de aplicar

11


SDN y el estándar OpenFlow en particular a las redes de transporte ópticasincluyen: mejora el control de red del transporte óptico y la flexibilidad en laadministración, permitiendo la implementación de administración de tercerosy control de sistemas, e implementando nuevos servicios de virtualización.

Infraestructuras basadas en redes de acceso inalámbricas: Recientemente seestá viendo un creciente interés académico y de la industria en para aplicarSDN a las redes móviles. La principal motivación detrás de esto es que SDNpuede ayudar a los operadores móviles a simplificar la administración de susredes y permitir nuevos servicios que soporten el crecimiento exponencial deltráfico previsto para las redes 5G [8].

Hogares y PYMES: Varios proyectos se han centrado en ver cómo las redesSDN 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 volviendocada vez más complejos debido a la creciente disponibilidad de dispositivos dered 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 futurasimplantaciones, nuevas tecnologías para los entornos de red, entre ellas está la quetratamos en este documento, las redes SDN. Se pretende en un futuro, poder usaresta tecnología para controlar sus capas de transporte [9].

12

3 OpenFlowLo 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 ycon una densidad de puertos muy alta. Por otra parte, los fabricantes no tienen queexponer los procesos internos de sus switches. La propuesta de OpenFlow es muyclara, permitir que los investigadores puedan evaluar sus ideas en un entorno detrabajo real y ser un componente muy útil en los bancos de pruebas a gran escala.

3.1. Protocolo OpenFlowLa 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 paraimplementar firewalls, NAT, QoS y recolectar estadísticas. Es posible experimentarcon nuevos protocolos, nuevos modelos de seguridad, esquemas de direccionamiento,incluso alternativas para IP lo que supone una mayor innovación. El plano de datosno se vería afectado ya que está aislado y se procesaría de la misma manera que seha estado realizando hasta hoy día. El cambio reside en el plano de control que seimplementaría mediante OpenFlow.

Los switch OpenFlow puede soportar diversas acciones, aunque es necesario teneruna serie de características comunes a todos ellos. Un switch OpenFlow consiste enal menos tres partes (ver figura 3.1 [5]):

Tabla de flujos: con una acción asociada a cada entrada de la tabla, indicandoal 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 yel controlador usando el protocolo OpenFlow.

Controlador: Un controlador añade y elimina entradas en la tabla de flujos.

13

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 alos controladores, típicamente un servidor o una estación de trabajo. Una aplicaciónde gestión se ejecutará en las interfaces del controlador que une todos los switchesen la red, facilitando la configuración de caminos de reenvío que utilizarán todo elancho de banda disponible. La especificación define el protocolo entre el controladory los switches y un conjunto de operaciones que se pueden realizar entre ellos Lasinstrucciones de reenvío se basan en el flujo, que consiste en que todos los paquetescomparten 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 lospaquetes cuando llegan, el puerto Ethernet de origen, la etiqueta VLAN, el destinoEthernet o el puerto IP y otro numero de características de los paquetes. Un nuevoflujo se debe crear cuando un paquete que llega no encuentra ninguna coincidenciacon ninguna entrada de la tabla. El switch debería tener configurado un descartadode 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

14

3.2 Funcionamiento de OpenFlow

para ese paquete y crea una o más entradas para la tabla. Éste envía la entradao entradas al switch para que sean añadidas a las tablas de flujo. Finalmente, elpaquete se envía de vuelta al switch para ser procesado con las nuevas entradascreadas.

SDN no es OpenFlow

A menudo se apunta a Openflow como sinónimo de SDN, pero en realidad, essimplemente un elemento que forma parte de la arquitectura SDN. Openflow esun estándar abierto para un protocolo de comunicaciones que permite al plano decontrol interactuar con el plano de datos (Openflow, sin embargo, no es el únicoprotocolo disponible o en desarrollo para SDN, aunque sí está convirtiéndose en elmodelo estándar de implementación de una SDN.

3.2. Funcionamiento de OpenFlow

3.2.1. FlujosUn 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 configuradoun 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 entoncesdefine 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 deflujo. Finalmente, el paquete se envía de vuelta al switch para ser procesado con lasnuevas 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 losswitches sucede a la velocidad de la línea.

2. Encapsulación y reenvío este flujo de paquetes al controlador. Elpaquete 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, paraque 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 paraque sean procesados.

15

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, paraparar 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 flujosUna tabla de flujo contiene una serie de entradas de flujoCada entrada de la tabla de flujo (tabla ) contiene:

match fields: Coincidencia. Este campo consiste en el puerto y la cabecerade 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 elmismo 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 yhard_time_out. El primero hacer referencia al tiempo que un flujo estará sinusar. 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. InstructionsCada tabla de flujo contiene un set de instrucciones que se ejecutan cuando el

paquete encuentra una coincidencia con la entrada. Estas instrucciones dan lugar acambios 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 quese marcan como requeridas y son: Instrucción de escritura (Write-Actions “action”):

16


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 dela 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 porcada 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. Lasacciones pueden especificar que el paquete que se va a reenviar a través de un puertoespecífico, modificar el TTL, VLAN, etiqueta MPLS o la QoS.

Además, una instrucción puede especificar un identificador de grupo. Se puedendefinir en el switch mediante entradas en la tabla de grupo Las instrucciones de laprimera tabla deberán realizar una acción en el paquete o añadir acciones que serealizarán después. Las instrucciones asimismo, deberán permitir que el procesadode paquetes continúe comparándolos con las entradas de otras tablas de flujos.

3.2.4. CountersLos contadores están mantenidos por tabla, por flujos, por puertos y por cola. Los

contadores pueden estar implementados por software y mantenidos por contadorespor hardware que tienen rangos más limitados.

La tabla 3.2 contiene el conjunto de contadores requeridos [10]. Duration hacereferencia a el tiempo que un flujo ha estado instalado en un switch. Los camposReceive Errors incluyen todos los errores específicos, incluyendo frame, overrun yerrores de CRC además de algunos otros.

3.2.5. Mensajes del protocolo OpenFlowEl 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 unnuevo flujo se ha creado.

Mensajes asíncronos se envían al switch para:

17

3 OpenFlow

Counter BitsPer Table

Active Entries 32Packet Lookups 64Packet Matches 64

Per FlowReceives Packets 64Received Bytes 64Duration (seconds) 32Duration (nanoseconds) 32

Per PortReceived Packets 64Transmitted Packets 64Received Bytes 64Transmitted Bytes 64Receive Drops 64Transmit Drops 64Receive Errors 64Transmit Errors 64Receive Frame Alignmet Errors 64Receive Overrun Errors 64Receive CRC Errors 64Collisions 64

Per QueueTransmit Packets 64Transmit Bytes 64Transmit Overrun Errors 64

Tabla 3.2: Lista requerida de contadores para usar en mensajes de estadísticas

18


Ingress Port Ether Src Ether Dst Ether type VLAN id VLAN PriorityIP 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ámetroTTL o el timer de inactividad han vencido.

Informar al controlador de un cambio en el estado de un puerto o de un errorque ha ocurrido en un switch. Ejemplos de estas circunstancias son cuandolos links se caen o cuando un paquete llega con una instrucción de reenvío noespecificada.

Mensajes simétricos pueden ser enviados por el switch o el controlador y se usanpara:

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 dela tecnología OpenFlow.

3.2.6. MatchingCuando 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 tablade flujo. Las tablas de flujos se numeran empezando por el cero, y basado en estaprimera 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 delpaquete. Los campos que se utilizan para buscar coincidencias dependen del tipo delpaquete y típicamente incluyen varios campos de cabecera, las coincidencias tambiénse 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 unswitch. Un paquete coincide con una entrada de la tabla de flujos si los valores delos campos del paquete que se usan para la búsqueda están definidos en la misma.

19

3 OpenFlow

Si tiene un valor ANY (omitido), coincidirá con todos los valores posibles en lacabecera. Si el switch trabaja con mascaras arbitrarias para campos específicos sepodrá afinar mucho más las coincidencias. El paquete solo coincidirá también tienela prioridad más alta Los contadores asociados a la tabla seleccionada deben seractualizados y el set de instrucciones incluido en el flujo seleccionado, será aplicado.

Si hay múltiples coincidencias y todas tienen configuradas la misma prioridad, laentrada de flujo seleccionada esta explícitamente indefinida. Está especificación notiene en cuenta si el switch recibe un paquete corrupto o con un formato que no esel 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

20

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 S1realiza el proceso de matching (figura 3.2), en esencia lo que hace es buscar si hayalguna 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, estetodavía no tiene instalado ningún flujo por lo que opta por enviar un PACKET_INal controlador, el cual contiene entre otros campos el buffer_id, que está generadode 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 escuando entra en escena la labor del programador que tiene que encargarse de decidirque hacer con el PACKET_IN. Por ejemplo se podrían uno de estos dos casos o losdos a la vez:

1. Simplemente decirle a S1 que envíe el paquete que recibió el controlador porel puerto 4 de S1. Para esto el controlador envía un PACKET_OUT (ver

21

3 OpenFlow

Figura 3.4: PACKET_IN

22


Figura 3.5: PACKET_OUT a

figura 3.5) el cual contiene el paquete original, el mismo buffer_id que conteníael PACKET_IN y una acción que indica que el paquete se envíe por el puerto4.

2. Enviarle a S1 un paquete FLOW_MOD (ver figura3.6) indicándole queinstale un flujo (flow) el cual diga que todos los paquetes en cuya cabecerafigure el puerto TCP 80 y que lleguen por el puerto eth1, que corresponde conH1 (estas dos opciones formarían el campo MATCH, en este caso lo formaríanlos campos Ingress Port y TCP dst Port. Tabla 3.3) sean enviados por porel 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 queno encuentra ninguna referencia en su tabla de flujos. Así que podremos realizar las

23

3 OpenFlow

Figura 3.6: FLOW_MOD a

24


Figura 3.7: PACKET_OUT b

dos mismas acciones descritas anteriormente pero en sentido inverso. Figuras 3.7 y3.8.

Finalmente los mensajes restantes, encontrarán una entrada de flujo de acuerdo asus cabeceras, por lo que los paquetes serán redirigidos directamente sin necesidadde 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 mensajeFLOW_MOD. Esto ocurre en los dos sentidos por los que viaja el paquete.

25

3 OpenFlow

Figura 3.8: FLOW_MOD b

26


Figura 3.9: Ultimos paquetes

27

3 OpenFlow

Figura 3.10: Wireshark Packet-in y Flow-mod

28

4 Software utilizado

4.1. ControladoresComo hemos visto anteriormente un controlador básicamente añade y elimina

entradas en la tabla de flujos. Existen numerosos controladores disponibles paraOpenFlow 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 dedocumentación, ejemplos e información disponible, que hará más sencilla la tareade desarrollar un programa para el controlador.

4.1.1. OpenDaylightOpenDaylight [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. OpenDaylightsoporta el framework OSGi y REST bidireccional.

El framework OSGi se utiliza para las aplicaciones que se ejecutan en el mismoespacio de direcciones que el controlador mientras que REST API se utiliza paraaplicaciones 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 aplicacionesutilizan el controlador para reunir la inteligencia de red, ejecutar algoritmos pararealizar 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 tareascomo ver que los dispositivos se encuentran dentro de la red y sus capacidades, larecopilación de estadísticas, etc. Además otros servicios y extensiones pueden serañ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

29


Figura 4.1: OpenDaylight Helium

dinámicamente conectados a la Service Abstraction Layer (SAL). La SAL contieneservicios de dispositivos para los módulos de niveles más altos. La SAL determinacómo cumplir con el servicio solicitado, independientemente del protocolo utilizadoentre el controlador y los dispositivos de red.

El controlador ofrece una serie de core bundles, cada uno de ellos exporta serviciosimportantes a través de Java Interfaces. En la tabla 4.1 se ofrece una lista de algunosbundles importantes que ofrece a la hora de desarrollar servicios de red. Cada una deestas interfaces ofrece una serie de métodos [13] que dan facilidad a para el desarrollode los servicios de red en Java, más adelante se explicará algunos de estos métodosmá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 deFunción de Red (Topology Manager, Statistics Manager, Switch Manager... ). LasAPI SAL son los contratos a los que los plugins de protocolo y los módulos de NFS

30

4.1 Controladores

Bundle Interface exportadora Descripciónarphandler IHostFinder Componente responsable del

aprendizaje de laslocalizaciones 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 detodos 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 quecolecta todas las estadísticas

de la red SDNsal IReadService Interface que provee la vista

hardware de los flujos, colas,puertos de los nodos de red.

sal ITopolgyService Métodos de topologíaproporcionados por SALhacia 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 paralas aplicaciones.

Tabla 4.1: Bundles importantes de OpenDaylight

31


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 usarAD-SAL ya que se ha encontrado un mayor número de documentación y ejemplosvarios, en contraposición con MD-SAL que siendo más reciente es más complicadoencontrar ejemplos concretos.

4.1.2. RyuRyu 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 crearaplicaciones de control y gestión de la red. Ryu soporta varios protocolos para lagestión de dispositivos de red, como OpenFlow, Netconf, OF-config, etc. En cuantoa 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 distintasmarcas.

Todo el código esta disponible libremente a través de la licencia Apache 2.0. Ryuestá totalmente escrito en Python. Ryu significa «flow» en japonés. Ryu posee grancantidad de documentación, ordenada, y fácil de comenzar a utilizar. Para másinformación[17, 18].

4.1.3. FloodlightEl 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, switchesvirtuales 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ásinformación[19]

4.1.4. NOX/POXNOX 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 hechomientras 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 fueinicialmente desarrollada por Nicira Networks codo con codo con OpenFlow (NOXfue el primer controlador SDN). Nicira donó NOX a la comunidad de desarrolladores

32

4.1 Controladores

AD-SAL MD-SAL

API-Driven SAL Model-Driven SALThe SAL APIs, request routing between

consumers and providers, and data adaptationsare all statically defined at compile/build time.

The SAL APIs, request routing betweenconsumers and providers are defined from

models, and data adaptations are provided by‘internal’ adaptation plugins.

The AD-SAL typically has both NB and SBAPIs even for functions/services that aremapped 1:1 between SB Plugins and NB

Plugins.

The MD-SAL allows both the NB plugins andSB plugins to use the same API generated froma 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 toaccess data and functions defined in models .

he AD-SAL provides request routing (selects anSB plugin based on service type) and optionallyprovides service adaptation, if an NB (Service,

abstract) API is different from itscorresponding SB (protocol) API.

The MD-SAL provides request routing and theinfrastructure 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: theSAL knows which node instance is served by

which plugin, and when an NB Plugin requestsan operation on a given node, the request isrouted to the appropriate plugin which thenroutes the request to the appropriate node.

Request Routing in the MD-SAL is done onboth protocol type and node instances, sincenode instance data is exported from the plugin

into the SAL.

AD-SAL is stateless MD-SAL can store data for models defined byplugins: provider and consumer plugins canexchange data through the MD-SAL storage

Limited to flow-capable device and servicemodels only

Model agnostic. It can support any deviceand/or service models and is not limited toflow-capable device and service models only

AD-SAL services usually provide bothasynchronous and synchronous versions of the

same API method.

In MD-SAL, Service model APIs only provideasynchronous APIs, but they return a

‘java.concurrent.Future’ object, which allows acaller to block until the call is processed and aresult object is available. Same API can beused for both synchronous and asynchronous

approach. Thus MD-SAL encouragesasynchronous approach to application design

but does not preclude synchronous applications.Tabla 4.2: AD-SAL vs MD-SAL

33


Figura 4.2: Floodligh

34

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 controladorOpenFlow. POX además va más allá de eso.

Para más información acerca de NOX y POX [20].

4.2. MininetMininet [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ónligera para hacer que un solo sistema parezca una red completa. Los programas quese 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 porlo que parece un verdadero interruptor de Ethernet, un enrutador o middlebox, conuna determinada cantidad de colas. Cuando dos programas, como un iperf clientey el servidor, se comunican a través mininet, el rendimiento medido debe coincidircon el de dos máquinas nativas más lentas. En resumen, los dispositivos virtuales demininet, conmutadores, enlaces y los controladores se crean utilizando software enlugar de hardware, en su mayor parte el comportamiento es similar a los elementosde hardware.

4.2.1. Ventajas e inconvenientes de MininetMininet 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 sepueda ejecutar en Linux.

35


Compartir resultados: al ser un sistema cerrado es fácil compartir el códigoy ejecutarlo en distintas máquinas.

Se pueden ejecutar experimentos simples escritos en Python, por ejemploun servidor web simple usando un pequeño comando.

Inconvenientes

Todos los hosts mininet comparten el mismo sistema de archivos y elespacio PID.

Actualmente mininet no hace NAT fuera de su sistema. Los host no puedenhablar directamente a Internet a menos que proporcione un medio para que lohagan (se pueden configurar los hosts mininet para que tengan conectividadexterna 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 100Mb/s en lugar de 10 Gb/s, debido al hecho de que los paquetes son transmitidospor 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 deconmutación dedicado [6].

4.2.2. vSwitchOpen 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 haceideal para la construcción de esquemas de redes virtuales para nubes. OpenVSwitches el esquema por defecto de gestión de redes de Mininet y se incluye preinstaladoen la máquina virtual de Mininet.

4.3. WiresharkWireshark [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. Cuentacon 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 interfazgráfica y muchas opciones de organización y filtrado de información. Así, permite ver

36

4.4 Iperf

todo el tráfico que pasa a través de una red (usualmente una red Ethernet, aunquees 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 salvadoen disco. Se puede analizar la información capturada, a través de los detalles ysumarios por cada paquete. Wireshark incluye un completo lenguaje para filtrar loque queremos ver y la habilidad de mostrar el flujo reconstruido de una sesión deTCP.

4.4. IperfIperf [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 elrendimiento de la red. Iperf fue desarrollado por el Distributed Applications SupportTeam (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 parahacer pruebas en una red, o para optimizar y ajustar la red. Iperf puede funcionarcomo 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ódigoabierto y puede ejecutarse en varias plataformas incluyendo Linux, Unix y Windows.

UDP: Cuando se utiliza el protocolo UDP, Iperf permite al usuario especificarel tamaño de los datagramas y proporciona resultados del rendimiento y delos 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 megabytesy 1000*1000 para megabits.

4.5. EclipseEclipse [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 queel 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

37


de Java llamado Java Development Toolkit (JDT) y el compilador (ECJ) que seentrega como parte de Eclipse (y que son usados también para desarrollar el mismoEclipse).

Eclipse fue desarrollado originalmente por IBM como el sucesor de su familia deherramientas para VisualAge. Eclipse es ahora desarrollado por la Fundación Eclipse,una organización independiente sin ánimo de lucro que fomenta una comunidad decó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 64bits ya que contiene la herramienta Maven preinstalada.

4.5.1. MavenMaven [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), perotiene un modelo de configuración de construcción más simple, basado en un formatoXML. Estuvo integrado inicialmente dentro del proyecto Jakarta pero ahora ya esun 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, yel orden de construcción de los elementos. Viene con objetivos predefinidos pararealizar ciertas tareas claramente definidas, como la compilación del código y suempaquetado.

4.6. Uso del software

4.6.1. MininetComo 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 marchade Mininet más sencilla es usar la máquina virtual que se proporciona en su páginaweb, esta contiene el Mininet propiamente dicho, todos los binarios OpenFlow y másherramientas preinstaladas (p.e. Wireshark) y modificaciones de la configuración delkernel que dan soporte a redes Mininet más complejas. Se puede descargar la versión

1Descarga Eclipse IDE for Java Developers http://www.eclipse.org/downloads/packages/eclipse-ide-java-developers/marsr

38

http://www.eclipse.org/downloads/packages/eclipse-ide-java-developers/marsr

http://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 podertener acceso desde cualquier punto de mi red.

Ya que la VM no incluye interfaz gráfica la forma más cómoda de manejar Mininetes 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 Windowspodemos 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 nombrede 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 VM https://github.com/mininet/mininet/wiki/Mininet-VM-Images

39

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


$ 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 poderusar 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 pordefecto.

CLI

Una vez dentro de la máquina remota usaremos el siguiente comando para iniciarMininet (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 yh2 (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 deswitches Open vSwitch, además indicamos que se conecte a un controlador remotoy 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 podemoscomprobar la conectividad de la red con el comando pingall que mandará un pingdesde todos los host de la red a todos los host restantes, o bien podemos usar elcomando dump para visualizar los dispositivos que esta nuestra red. Además poniendoel nombre del dispositivo seguido de un espacio y un comando de unix, podremosejecutar 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 XQuartz http://xquartz.macosforge.org/landing/4Descargar Xming http://sourceforge.net/projects/xming/

40

http://xquartz.macosforge.org/landing/

http://sourceforge.net/projects/xming/


Figura 4.4: mininet>

41


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íaen á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 nospermite hacer eso mismo de forma gráfica. Este mismo ha sido usado para crearlas topologías que usaremos más adelante. Para ejecutarlo basta con lanzarlo comocualquier script python, en concreto en nuestra máquina virtual de Mininet se haríacon el siguiente comando:

$ sudo ~/mininet/examples/miniedit.py

42


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 podremosmodificar todas sus características. Algo importante que debemos hacer es decirleque el controlador es remoto, para ello, simplemente haremos click derecho en elicono 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 dondese iniciará OpenDaylight (Figura 4.7). También indicarle a MiniEdit que cuandolancemos el script python de Mininet nos cargue el CLI para que podamos trabajardesde su consola, para hacer esto debemos ir a Edit, Preferences y seguidamentemarcar la casilla Start CLI (Figura 4.8). Para más información acerca de como usarMiniEdit [31].

Una vez tengamos nuestra topología creada la guardaremos y la exportaremosa Level 2 Script que nos creará un script python de mininet, el cual simplementelanzaremos y tendremos nuestro mininet listo. Para ello primero habrá dar permisosde 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. WiresharkPara 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 demininet. Este incluye un plugin para OpenFlow que permite visualizar los paquetesde forma mucho más ordenada, además también permite el filtrado de estos. Parafiltrar los paquetes OpenFlow usaremos el código «of». Más adelante veremos comose inicia la conexión en el protocolo OpenFlow visualizando los paquetes medianteeste 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&

43


Figura 4.6: Topología con MiniEdit

44


Figura 4.7: Controlador remoto MiniEdit

Figura 4.8: Activar CLI MiniEdit

45


Figura 4.9: Ventana de Wireshark

46


4.6.3. OpenDaylightComo 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 sencillade usar, ya que desde el principio está todo montado y no es necesario instalar máscosas. En concreto usaremos una versión modificada de SDN Hub [32], ya que esmás liviana que la versión original ya que solo incluye los módulos necesarios parala ejecución de nuestro programa. Esta versión se incluye en los archivos externosentregados junto a la documentación. Para lanzar el controlador nos iremos a lacarpeta 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.

47


Figura 4.10: Controlador OpenDaylight iniciándose

48

5 Caso práctico: Mejora de laeficiencia energética en una redSDN

5.1. Explicación teóricaSe ha desarrollado un módulo para OpendayLight llamado flowApp que intenta

mejorar la eficiencia energética de redes de switches utilizando para ello tecnologíaSDN. En concreto usaremos Opendaylight y Mininet (que incluye switches Open-Flow). Se usarán tres topologías distintas para comprobar el grado de mejora encada 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 loscódigos fuentes del módulo OpenDaylight programado en Java y de las topologíasde Mininet escritas en Python.

El gasto energético de una interfaz de red es proporcional al throughtput de esainterfaz. Al aumentar el throughtput también aumentará el gasto energético de laforma que se indica en la tabla, de forma que prácticamente una interfaz de redcon un throughput de 1000Mpbs (que diremos que está en nivel 2) tiene solamenteel 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 delas conexiones estén en nivel 2 lo que hará que haya mayor numero de interfaces enStandBy (que son las que menos gasto energético tienen) . El módulo se encarga decalcular 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 ellosse encuentran tres importantes que nos permitirán cambiar los costes (usados por elalgoritmo shortest path de Dijkstra) dados a cada nivel energético (StandBy, Nivel1o Nivel2). Así el módulo se encargará de calcular las rutas más óptimas energética-mente hablando. Variando estos valores conseguiremos modificar el comportamientodel 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

49

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 medioa las interfaces Nivel1 y un valor bajo a las interfaces Nivel2, así intentaríamos usarlo 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 conseguireficiencia energética y, simplemente, consiguiendo forwarding entre host usando elcontrolador.

5.1.1. Desarrollo del código: JavaAlgoritmo 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 dadoun vértice origen al resto de los vértices en un grafo con pesos en cada arista. Sunombre 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 caminosmá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

50

5.1 Explicación teórica

Figura 5.2: Topología en anillo

51


Figura 5.3: Topología en árbol

52


Algoritmo 5.1 Algoritmo de DijkstraRequire: Directed network G = (V,E,w), with non-negative edge weights andsource s ∈ V .

Ensure: Array µ(· ) of length n, where µ(u) is the maximum reliability for eachu ∈ V , and array pred(· ) of length n, where pred(u) is the parent of vertex u inthe shortest path tree rooted at s.S = ∅;S ′ = Vfor every u ∈ V do

µ(P ) = 0;end forµ(s) = 1; pred(s) = 0;while |S| < n do

let u ∈ S ′ be the vertex for which µ(u) = minu∈S′{d(u)};S = S ∪ {u};S ′ = S ′ − {u};for ∀(u,w) ∈ E do

if µ(w) < µ(u)·wt(u,w) thenµ(w) = µ(u)·wt(u,w)

end ifend for

end while

que componen el grafo, el algoritmo se detiene. El algoritmo es una especializaciónde la búsqueda de costo uniforme, y como tal, no funciona en grafos con aristas decoste 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 delcamino 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 tomaeste 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.

53


API AD-SAL

Se ha usado el java-doc de AD-SAL OpenDaylight [13] para tener una referenciade los distintos métodos que se pueden usar a través de las Interfaces descritas enla tabla 4.1. Las dos interfaces más importantes para la realización de este proyectohan sido el Topology Manager y el Statistics Manager.

Topology Manager: Nos da información acerca de la topología de la red. Sumétodo más importante es getEdges el cual nos devuelve un Map con todoslos edges de la red. A partir del objeto edge podemos sacar el nodeConnectorde cada extremo y de este último el node. Hay que tener en cuenta que eltopologyManager entrega dos edges para cada enlace, uno en cada sentido.Por eso a la hora de crear el grafo de la red usaremos un grafo dirigido paraque a la hora de calcular los caminos nos entreguen los edges en la direccióncorrecta.

Statistics Manager: Entrega información de los contadores del protocolo Open-Flow de los switchs. Nos interesa para conocer los campos Transmitted Bytesy Received Bytes de los puertos (ver apartado3.2.4) con el fin de calcular suthroughput.

Código

A continuación pasaremos a explicar las partes más relevantes del programa[14, 34]. Para más información consultar el código fuente el cual está totalmentecomentado.

PacketHandler.receiveDataPacket. Esta función es llamada cuando el contro-lador recibe un PACKET_IN desde cualquiera de los switches, como vemosen la figura 5.2 se comprueba que sea de tipo Ethernet para a continuaciónextraer las direcciones MAC origen y destino que contiene el paquete. Segui-damente se comprueba que se trate de un paquete IPv4 e igual que en el pasoanterior, extraemos las direcciones IP origen y destino. Finalmente llamamosal método installPathFlows que se encargará de calcular las rutas e instalarlasen los nodos correspondientes.

PacketHandler.installPathFlows. El trabajo de esta función es la de calcularlas rutas e instalarlas en toda la red (figuras 5.3 y 5.4). Primero se busca elnodo al que está conectado un host con la dirección dstAddr. Una vez encon-trado, inicializamos el objeto path de tipo Path, una clase la cual contiene losmétodos de cálculo de caminos usando el algoritmo Shortest Path de Dijkstra

54


Función 5.2 receiveDataPacket

55


basándonos en Framework para grafos JUNG 1. Para hacer esto nos basamosen la interfaz topologyManager con el fin de sacar una lista de edges los cualesusaríamos para crear un grafo. Además tenemos un Map llamado edgeCost elcual contiene los costes actuales asociados a cada enlace (edge o arista). Unavez hecho esto, primeramente miraríamos si existe conexión entre los dos no-dos y seguidamente calcularíamos el camino mediante el método getPath. Elcamino lo formarían una lista de edges los cuales instalaríamos para instalarun flujo en el nodo situado en el primer extremo del enlace (tail). En esteflujo indicaríamos que todos los paquetes con dirección IP fuente srcAddr ydirección IP destino dstAddr se mandaran por la interfaz correspondiente aledge usado. Este paso lo realizaríamos tantas veces como edges tenga la listaedgePath.

PacketHandler.programFlow. Dicha función (5.5) se encarga de crear los flujose instalarlos en los nodos correspondientes. Primero se crea un objeto Matchel cual contendrá los datos con los cuales se decidirá si un paquete hará uso delflujo o no según los datos de su cabecera. En nuestro caso simplemente selec-cionaríamos los paquetes IPv4 con dirección IP fuente srcAddr y dirección IPdestino dstAddr. El siguiente paso es crear la lista de acciones que realizaránlos paquetes coincidentes con el match, le vamos a indicar solo una, que el pa-quete se envie por el puerto outConnector. Por último creamos el flujo usandolos objetos match y actions, le asignamos los time_outs correspondientes yfinalmente programamos el flujo en el nodo.

PacketHandler.iniEdgeBps. Dicha función (5.6) asigna el nivel que tendrá cadaenlace dependiendo de su throughput actual. Además devuelve la carga totalde la red.

Paths.buildGraph. Esta función (5.7) genera el grafo del cual calcularemos loscaminos. Simplemente hay que añadir todas las aristas y sus dos vértices eindicar el tipo de arista (en nuestro caso será dirijida, ya que como hemoscomentado antes topologyManager entrega un edge por cada sentido de unenlace).

1Java Universal Network/Graph Framework http://jung.sourceforge.net/doc/api/index.html

56

http://jung.sourceforge.net/doc/api/index.html


Función 5.3 PacketHandler.installPathFlows Parte 1

57


Función 5.4 PacketHandler.installPathFlows Parte 2

58


Función 5.5 PacketHandler.programFlow

59


Función 5.6 PackeHandler.iniEdgeBps

Función 5.7 Paths.buildGraph

60


Figura 5.4: dependencies

5.1.2. Desarrollo del código: MavenComo hemos dicho anteriormente Maven automatiza el proceso de añadir las de-

pendencias necesarias para nuestro proyecto a la hora de compilar. Para hacer estousa el fichero pom.xml (se encuentra dentro del proyecto de flowApp) el cual contie-ne el nombre de las dependencias necesarias y repositorios donde conseguirlas. Paraañadir más dependencias simplemente hay que buscar el nombre de la dependen-cia deseada2 y añadirla en el apartado depdendencies (figura 5.4) dentro del ficheropom.xml [35].

Una vez tenemos nuestro fichero pom.xml configurado para compilar nuestro pro-yecto lo haremos pinchando con el botón derecho en nuestro proyecto de eclipse, nosvamos a Run as y finalmente pinchamos en Maven install como se muestra en la

2Dependencias Opendaylighthttps://nexus.opendaylight.org/content/repositories/opendaylight.snapshot/org/opendaylight/controller/

61

https://nexus.opendaylight.org/content/repositories/opendaylight.snapshot/org/opendaylight/controller/


figura 5.5.

5.1.3. Desarrollo del código: PythonLos scripts python programados simplemente se encargan de generar tráfico para

comprobar el rendimiento de la red. Se encargan de lanzar comandos en cada host deforma automática. Concrétamente se lanzan comandos ping e iperf cada 10 segun-dos. Inicialmente solo se usaron comandos iperf para generar tráfico UDP ya queesta herramienta solo permitía modular el ancho de banda de este tipo de tráfico.El problema vino con que el controlador OpenDaylight no procesaba los paquetesUDP con la rapidez necesaría, y mientras se estaban instalando las rutas a lo largode la red, seguian llegando paquetes al controlador ya que no se encontraban flujosasociados por que no había dado tiempo a instalarlos. Para poder solucionarlo esoptó por mandar primero un paquete ICMP mediante la aplicación ping para que alcontrolador le diera tiempo de calcular las rutas e instalarlas. Una vez hecho esto seharía el iperf UDP y ya se encontrarían los flujos instalados por lo que no llegaríannunca al controlador.

Como vemos en la figura 5.6 primero ejecutamos iperf en modo servidor en todoslos hosts y seguidamente comienzan a mandarse en bucle los ping y las peticionesiperf (con ancho de banda de 50Mbps y durante 50 segundos).

5.2. Funcionamiento

5.2.1. Configuración módulo flowAppPara cambiar la configuración del módulo solamente debemos cambiar los valores

del fichero flowapp.conf. Estos valores son los siguientes:

«@IDLETIMEOUT valor » Tiempo en segundos para el idle_time_out de los flujosque se instalarán. Por defecto 15.

«@HARDTIMEOUT valor » Tiempo en segundos para el hard_time_out de los flujosque se instalarán. Por defecto 7200 (dos horas)

«@REFRESHTIME valor » Tiempo en segundos para el refresco del calculo de niveles.Por defecto 10.

«@LEVEL1 valor » Troughtput en bytes por segundo mediante el cual se asigna-rán los niveles. Así pues los enlaces con un throughtput de 0 estarán enStandBy, los enlaces de 0 al valor estarán en Nivel1 y los enlaces cuyo

62

5.2 Funcionamiento

Figura 5.5: Compilar con Maven

63


Figura 5.6: Código python iperfUDP

64

5.2 Funcionamiento

throughtput sea mayor al valor estarán en Nivel2. Por defecto 12500000(12.5MB/s = 100Mbps).

«@ESTANDBY valor » Energía en mW que consume una interfaz en StandBy. Pordefecto 49.

«@ELEVEL1 valor » Energía en mW que consume una interfaz en Nivel1. Por defecto315.

«@ELEVEL2 valor » Energía en mW que consume una interfaz en Nivel2. Por defecto619.

«@STANDBYCOST valor » Coste asignado a un enlace en StandBy. Por defecto 50.

«@LEVEL1COST valor » Coste asignado a un enlace en Nivel1. Por defecto 15.

«@LEVEL2COST valor » Coste asignado a un enlace en Nivel2. Por defecto 1.

«@MONPATH ruta » Ruta en la cual se guardarán los ficheros de monitorización. Pordefecto «./»

«@MONITOR true/false » True si queremos mostrar los datos de monitorización enconsola, false si no. Por defecto a true.

También podemos añadir comentarios de la forma #+comentario. Si repetimos másde un comando, será siempre el último el que tendrá valor.

Ejemplo de un fichero flowapp.conf creado:

#Fichero de configuracion@IDLETIMEOUT 15@HARDTIMEOUT 7200@REFRESHTIME 10@LEVEL1 12500000@ESTANDBY 49@ELEVEL1 315@ELEVEL2 619@STANDBYCOST 50@LEVEL1COST 1@LEVEL2COST 1@MONPATH /Users/pablomuri/Develop/@MONITOR true

65


5.2.2. Iniciando OpenDaylight

Partiendo de la base en que ya tenemos nuestro módulo compilado listo para usar-se en la carpeta plugins dentro de opendaylight y configurado, la máquina virtualiniciada y los scripts de Python (para este paso se puede usar algún cliente SFTPcomo winSCP3 en Windows, Fugu4 para Mac o Filezilla para Linux5 bien usar elcomando scp6 desde la terminal.) en ella. Iniciamos OpenDaylight como dijimos enel apartado 4.6.3. Abrimos una terminal, nos vamos a la carpeta opendaylight yejecutamos el siguiente comando:

$ ./run.sh

Si está todo va bien en unos segundos nos debería aparecer la configuración car-gada y comenzar a monitorizar a los 10 segundos, siempre que tengamos activado elmodo monitor (ver figura 5.7).

5.2.3. Iniciando Mininet

Una vez tenemos OpenDaylight corriendo toca iniciar Mininet, para ello primerodebemos conectarnos por ssh como muestra el apartado 4.6.1. Ahora tenemos queiniciar nuestra topología, en nuestro caso usaremos las tres topologías descritas enel apartado 5.1. Cada topología se inicia con un fichero .py diferente. Por ejemploprobaremos el script malla6.py el cual contiene una topología en malla, la forma delanzarlo es como se haría con cualquier ejecutable de unix, una cosa que hay quetener en cuenta es que mininet debe tener permisos de administrador, por lo tantoel comando quedaría así:

$ sudo ./malla6.py

Esperaremos unos instantes y deberíamos tener acceso al CLI si el script de Mini-net está bien configurado. Además en la consola de OpenDaylight veríamos que losswitchs han sido reconocidos por el controlador y el monitor de comienza a mostrarinformación del nivel de las interfaces. Esperaremos unos segundos hasta que en elnúmero total de interfaces aparezcan todas (tiene que se el doble del número deenlaces entre nodos). Para la topología en malla utilizada deberían ser 17.

3Descargar winSCP http://winscp.net/eng/docs/lang:es4Descargar Fugu http://sourceforge.net/projects/fugussh/5Descargar Filezilla https://filezilla-project.org/download.php?show_all=16Cómo usar el comando scp http://www.tecmint.com/scp-commands-examples/

66

http://winscp.net/eng/docs/lang:es

http://sourceforge.net/projects/fugussh/

https://filezilla-project.org/download.php?show_all=1

http://www.tecmint.com/scp-commands-examples/

5.2 Funcionamiento

Figura 5.7: OpenDaylight configuración y monitor

67


Una vez cargada nuestra red, es el momento de realizar las pruebas. Para ello usa-remos una función en python que cargaremos desde un script externo. Para haceresto primero necesitamos cargar el script (archivo malla6_iperf.py).

mininet> py execfile('malla6_iperf.py')

Seguidamente llamaremos a la función iperfUDP(h1,h2,h3,h4,h5,h6) la cual se en-cuentra dentro del script que acabamos de cargar. Esta función se encarga de generaren bucle tráfico entre los host cada 10 segundos (este tiempo se puede cambiar mo-dificando la variable t del script python):

mininet> py iperfUDP(h1,h2,h3,h4,h5,h6)

Como esta, se han preparado otras dos pruebas. Cada una tiene un script parainiciar la topología y otro script que contiene la función iperfUDP asociada a cadatopología.

La topología en anillo se encuentra en el script anillo16.py, por lo tanto paracargarla lo hacemos del mismo modo que la primera:

$ sudo ./anillo16.py

En la consola de mininet usaremos los siguientes comandos para lanzar la prueba:

mininet> py execfile('anillo16_iperf.py')

mininet> py iperfUDP(h1,h2,h3,h4,h5,h6,h7,h8,h9,h10,h11,h12)

Finalmente la topología en árbol se encuentra en el fichero tree4.py. Lo ejecuta-remos igual que las veces anteriores.

$ sudo ./tree4.py

mininet> py execfile('tree4_iperf.py')

mininet> py iperfUDP(h1,h2,h3,h4,h5,h6,h7,h8,h9)

68

5.3 Resultados

5.3. ResultadosSe han realizado las tres pruebas comentadas anteriormente usando dos ficheros

de configuración diferentes. En uno de ellos todos los niveles tenían coste 1, es decir,la mejora energética está desactivada. En el otro fichero el coste para los enlaces denivel 2 es de 1, para los enlaces de nivel 1 es de 5 y para los enlaces en stand byes de 50. Se ha llegado a la conclusión de que estos valores son los más adecuadosrealizando diversas pruebas, al final se observó que había que usar un valor alto parael coste de los enlaces en stand by, ya que la intención es evitarlos lo máximo posible.Para el consumo energético de cada nivel se han usado los valores por defecto: 49mW para las interfaces en StandBy, 315 mW para las interfaces en nivel 1 y 619 mWpara las interfaces en nivel 2 [36].

El programa guarda en varios ficheros algunos datos para la monitorización delsistema, en nuestro caso cada 10 minutos. A partir de esos datos se han creado lasgráficas 5.8, 5.9 y 5.10 usando la carga total de la red (en Bytes por segundo) y laenergía total de la red (en mW).

Se puede observar fácilmente en las gráficas que prácticamente solo hay mejoraen la topología de malla, ya que esta es la que permite más diferentes entre hostsy por ello hay más dispersión entre caminos cuando no se usa la mejora energética.En cambio cuando se usa la mejora, los caminos se van centrando mucho más. Sinembargo en las otras dos topologías no hay apenas mejora, ya que estas no permitentantos caminos diferentes como para notar un cambio usando la eficiencia energética.

Vemos como la energía total de la red y el número total de interfaces en StandByestán muy relacionadas entre sí, ya que son las interfaces en este nivel las que menosconsumo energético tienen. Los picos iniciales son debidos a que la red todavía se estácargando. Justo después vemos como se estabiliza en valores bajos y seguidamen-te vuelve a subir, es por que en este momento las pruebas de carga han sido lanzadas.

Sin embargo es en las gráficas del throughput de la red donde se encuentra el pro-blema. Al intentar usar siempre los enlaces en los que ya hay una carga, los caminosacaban siendo más largos en número de saltos, así pues, la carga total aumenta.

Por esto es trabajo del administrador de red configurar el coste de los niveles deenlace en el archivo de configuración, con el fin de conseguir el balance de eficienciaenergética y de carga deseados.

69


(a) Energía total de la red

(b) Carga total de la red

Figura 5.8: Topología en malla

70

5.3 Resultados



Figura 5.9: Topología en anillo

71




Figura 5.10: Topología árbol

72

6 Conclusiones y trabajo futuro

6.1. ConclusionesTendencias como la movilidad del usuario, la virtualización de servidores, o la ne-

cesidad para responder a las cambiantes condiciones de negocios, significan nuevasdemandas sobre las redes. Las redes definidas un software forman un nuevo paradig-ma que habilita la programación de la red y que dentro de muy poco encontraremosen muchas de las redes más importantes del planeta [9].

En este trabajo se han definido qué son las redes SDN, qué papel juegan en la vir-tualización de sistemas, y cuales son sus beneficios. También se han dado ejemplosde uso de este tipo de redes. Se ha explicado qué es y cómo funciona el protoco-lo OpenFlow, siendo actualmente el protocolo más importante que hace uso de lasredes SDN. También hemos definido las partes más importantes de este protocolopara posteriormente poder desarrollarlas en un trabajo práctico.

Hemos visto también que es un controlador y como trabaja junto a OpenFlow.Además se han mostrado algunos ejemplos de controladores para finalmente cen-trarnos en OpenDaylight, un controlador que funciona bajo la máquina virtual deJava y que permite desarrollar módulos que pueden funcionar en conjunto.

Para poder ejecutar una red, se ha usado el software Mininet, una herramientamuy potente que proporciona un escenario ideal para la implantación de un númeroinfinito de distintas topologías de red que facilitan las pruebas en un entorno deinvestigación.

Mediante estas tecnologías se ha desarrollado una aplicación para OpenDaylightque busca mejorar la eficiencia energética de las redes usando tecnología SDN debidoal creciente tamaño que están teniendo las redes de última generación.

Gracias a esto se ha conseguido comprender como usar las herramientas que nosofrece el protocolo OpenFlow para en un futuro poder desarrollar otras aplicacionesSDN para otros campos en continuo crecimiento, como son las redes móviles, o lasredes ópticas.

73

6 Conclusiones y trabajo futuro

6.2. Trabajo futuroHay varios aspectos que pueden ser mejorados en un futuro. Podrían probarse las

posibilidades de otros controladores en la parte de programación y más actualizados,por ejemplo OpenDaylight con MD-SAL.

Actualmente, la aplicación desarrollada funciona bajo IPv4 ya que la API usadaestaba pensada para ser usada bajo OpenFlow 1.0 que en teoría no permite usarIPv6. Esto podría resolverse usando algún controlador más actualizado que entre-gue APIs más adecuadas para el trabajo con IPv6 y alguna versión más modernade OpenFlow, como OpenFlow 1.3 u OpenFlow 1.4.

Gracias al uso de SDN sería posible seguir aumentando la eficiencia energética.La idea sería seguir mejorando los algoritmos para la eficiencia energética ahora queya están asentadas las bases para el desarrollo bajo SDN.

En el presente ya se haya entre nosotros la cuarta generación de telefonía: 4G. Asíque justo ahora es cuando se está investigando la siguiente generación conocida por5G. Se podrían aplicar los conocimientos desarrollados en este trabajo para desa-rrollar protocolos bajo la tecnología SDN con el fin de gestionar la movilidad en lasredes 5G, ya que SDN estará intrínsicamente ligada a la siguiente generación.

En este trabajo hemos desplegado las redes virtualmente usando la herramientaMininet. Sería interesante ver como se comportaría la solución desarrollada en unentorno real usando dispositivos físicos.

74

7 AgradecimientosAgradecer a mi familia la ayuda aportada durante todos estos años, tanto moral-

mente como económicamente.

A Yai, que ha aguantado estos últimos meses de agobios y no ha podido apoyarmemás.

A todos mis compañeros del grado, los cuales al final han acabado siendo amigos.

Al director de mi proyecto, Javier. Muchas gracias por haber creído en mis posi-bilidades y ofrecerme un proyecto el cual no podría haber disfrutado más. Graciaspor tu ayuda durante todos estos meses.

75

7 Agradecimientos

76

Bibliografía[1] Dan Pitt. A revolution (revelation?) in networking. Open Networ-

king Foundation, 2012. URL: http://opennetsummit.org/archives/apr12/pitt-mon-ons.pdf.

[2] Jens Zander and Robert Forchheimer. Softnet-an approach to high level packetcommunication, 1983.

[3] David L. Tennenhouse and David J. Wetherall. Toward an active networkarchitecture, 1996. URL: http://dx.doi.org/10.1117/12.235899, doi:10.1117/12.235899.

[4] Craig Matsumoto. Vmware and nicira: 1 year and dollar 1.26blater, 2013. URL: https://www.sdxcentral.com/articles/featured/vmwarenicira-1-year-and-1-26b-later/2013/07/.

[5] Bruno Nunes, Manoel Mendonca, Xuan-Nam Nguyen, Katia Obraczka, ThierryTurletti, et al. A survey of software-defined networking: Past, present, andfuture of programmable networks. Communications Surveys & Tutorials, IEEE,16(3):1617–1634, 2014.

[6] Washington A. Velásquez Vargas. Emulación de una red definida por softwareutilizando mininet. 2014.

[7] Raj Jain and Sudipta Paul. Network virtualization and software defined net-working for cloud computing: a survey. Communications Magazine, IEEE,51(11):24–31, 2013.

[8] Woon Hau Chin, Zhong Fan, and R. Haines. Emerging technologies and re-search challenges for 5g wireless networks. Wireless Communications, IEEE,21(2):106–112, April 2014. doi:10.1109/MWC.2014.6812298.

[9] H Wessing DTU, K Bozorgebrahimi, A Tzanakaki, and B Belter. Deliverabled12. 3 (dj1. 1.1) future network architectures. 2015.

[10] Open Networking Fundation. Openflow switch specification 1.3, 2012.

77

http://opennetsummit.org/archives/apr12/pitt-mon-ons.pdf

http://opennetsummit.org/archives/apr12/pitt-mon-ons.pdf

http://dx.doi.org/10.1117/12.235899

http://dx.doi.org/10.1117/12.235899

http://dx.doi.org/10.1117/12.235899

https://www.sdxcentral.com/articles/featured/vmwarenicira-1-year-and-1-26b-later/2013/07/

https://www.sdxcentral.com/articles/featured/vmwarenicira-1-year-and-1-26b-later/2013/07/

http://dx.doi.org/10.1109/MWC.2014.6812298

Bibliografía

[11] David Mahler. Introduction to openflow. Última visita 2015. URL: https://www.youtube.com/watch?v=l25Ukkmk6Sk.

[12] Opendaylight [URL: http://www.opendaylight.org, última visita 2015].

[13] Cisco. Opendaylight api. URL: https://developer.cisco.com/media/XNCJavaDocs/overview-summary.html [última visita 2015].

[14] Srini Seetharaman. Opendaylight helium application developers’ tutorial. URL:http://sdnhub.org/tutorials/opendaylight-helium/ [última visita 2015].

[15] Inc The OpenDaylight Project. Controller projects’ modules/bundles and inter-faces. URL: https://wiki.opendaylight.org/view/Controller_Projects%27_Modules/Bundles_and_Interfaces [última visita 2015].

[16] Kanika. Difference Between AD-SAL and MD-SAL. URL: http://sdntutorials.com/difference-between-ad-sal-and-md-sal/.

[17] Openflow ryu tutorial. URL: https://github.com/osrg/ryu/wiki/OpenFlow_Tutorial.

[18] R. team. RYU SDN Framework - English Edition:. Release 1.0. RYU projectteam, 2014. URL: http://books.google.es/books?id=JC3rAgAAQBAJ.

[19] Floodlight Web. URL: http://www.projectfloodlight.org/ [última visita2015].

[20] Nox/pox [URL: http://www.noxrepo.org/, última visita 2015].

[21] Mininet [URL: http://mininet.org/, última visita 2015].

[22] Wireshark Wikipedia. URL: https://es.wikipedia.org/wiki/Wireshark[última visita 2015].

[23] Wireshark web. URL: https://www.wireshark.org/ [última visita 2015].

[24] Iperf Wikipedia. URL: https://es.wikipedia.org/wiki/Iperf [última visita2015].

[25] Iperf [URL: https://iperf.fr/, última visita 2015].

[26] Eclipse Web. URL: https://eclipse.org/ [última visita 2015].

[27] Eclipse Wikipedia. URL: https://es.wikipedia.org/wiki/Eclipse_(software) [última visita 2015].

78

https://www.youtube.com/watch?v=l25Ukkmk6Sk

https://www.youtube.com/watch?v=l25Ukkmk6Sk

http://www.opendaylight.org

https://developer.cisco.com/media/XNCJavaDocs/overview-summary.html

https://developer.cisco.com/media/XNCJavaDocs/overview-summary.html

http://sdnhub.org/tutorials/opendaylight-helium/

https://wiki.opendaylight.org/view/Controller_Projects%27_Modules/Bundles_and_Interfaces

https://wiki.opendaylight.org/view/Controller_Projects%27_Modules/Bundles_and_Interfaces

http://sdntutorials.com/difference-between-ad-sal-and-md-sal/

http://sdntutorials.com/difference-between-ad-sal-and-md-sal/

https://github.com/osrg/ryu/wiki/OpenFlow_Tutorial

https://github.com/osrg/ryu/wiki/OpenFlow_Tutorial

http://books.google.es/books?id=JC3rAgAAQBAJ

http://www.projectfloodlight.org/

http://www.noxrepo.org/

http://mininet.org/

https://es.wikipedia.org/wiki/Wireshark

https://www.wireshark.org/

https://es.wikipedia.org/wiki/Iperf

https://iperf.fr/

https://eclipse.org/

https://es.wikipedia.org/wiki/Eclipse_(software)

https://es.wikipedia.org/wiki/Eclipse_(software)

Bibliografía

[28] Maven Web. URL: https://maven.apache.org/ [última visita 2015].

[29] Maven Wikipedia. URL: https://es.wikipedia.org/wiki/Maven [última vi-sita 2015].

[30] Mininet Team. Mininet walkthrough. URL: http://mininet.org/walkthrough/ [última visita 2015].

[31] Brian Linkletter. How to use miniedit, mininet’s graphi-cal user interface. URL: http://www.brianlinkletter.com/how-to-use-miniedit-mininets-graphical-user-interface/ [últimavisita 2015].

[32] Srini Seetharaman, Anirudh Ramachandran, and Sriram Natarajan. Sdn hub.URL: http://sdnhub.org/ [última visita 2015].

[33] S Skiena. Dijkstra’s algorithm. Implementing Discrete Mathematics: Combi-natorics and Graph Theory with Mathematica, Reading, MA: Addison-Wesley,pages 225–227, 1990.

[34] Frank Durr. Reactive flow programming with opendaylight, 2014.

[35] Frank Durr. Developing osgi components for opendaylight.

[36] Jordan R. Energy efficient ethernet: Technology, application and why youshould care. Technical report, Intel Corporation, 2011.

79

https://maven.apache.org/

https://es.wikipedia.org/wiki/Maven

http://mininet.org/walkthrough/

http://mininet.org/walkthrough/

http://www.brianlinkletter.com/how-to-use-miniedit-mininets-graphical-user-interface/

http://www.brianlinkletter.com/how-to-use-miniedit-mininets-graphical-user-interface/

http://sdnhub.org/

Documents

Analisi y Evaluaciones de Las Redes Definidas Por Software