Software Defined Networking (SDN)

(1)

1

SOFTWARE DEFINED NETWORKING (SDN)

Proyecto de grado presentado por

RAFAEL EDUARDO CARRILLO VILLAMIZAR

[email protected]

Asesor

YEZID DONOSO, Ph.D

Profesor Asociado Departamento de Ingeniería de Sistemas y Computación

UNIVERSIDAD DE LOS ANDES

(2)

2

Tabla de Contenidos

RESUMEN ... 3

1. INTRODUCCIÓN ... 3

2. DESCRIPCIÓN GENERAL... 6

2.1. Objetivos ... 6

2.1.1. Objetivo General ... 6

2.1.2. Objetivos Específicos ... 6

3. INVESTIGACIÓN ... 6

3.1. Software Defined Networking (SDN) ... 6

3.1.1. Descripción ... 6

3.1.2. Inicio ... 7

3.1.3. Beneficios ... 7

3.1.4. Principal Promotor ... 8

3.2. Network Function Virtualization (NFV) ... 8

3.2.1. Descripción ... 8

3.2.2. Inicio ... 9

3.2.3. Beneficios ... 9

3.2.4. Principal Promotor ... 10

3.3. SDN vs NFV ... 10

4. IMPLEMENTACIÓN ... 11

4.1. Herramientas ... 11

4.1.1. Herramientas Generales ... 11

4.1.2. Herramientas Generales ... 12

4.2. Despliegue de la topología ... 13

4.2.1. Aspectos Generales ... 13

4.2.2. Controladores ... 16

5. RESULTADOS ... 22

5.1. Conclusiones ... 22

5.2. Trabajos Futuros ... 23

(3)

3

RESUMEN

Hoy día se utilizan arquitecturas de red tradicionales que no se ajustan correctamente a los requerimientos actuales de diversas empresas, operadores de la industria y usuarios finales. Gran parte del problema está en que dichas arquitecturas fueron propuestas hace más de 20 años donde la computación cliente-servidor era dominante, sin embargo estas no se adaptan correctamente a la computación y almacenamiento dinámico que es requerido en la actualidad para soportar los servicios como virtualización, cloud computing, computación móvil, big data, entre otros. Adicionalmente el hecho que la mayoría de las implementaciones están sujetas a plataformas cerradas y que las funcionalidades soportadas dependan directamente del proveedor/vendedor, ha tornado extremadamente difícil la innovación y adaptación de tales dispositivos para enfrentar los requerimientos de negocio mencionados previamente.

1. INTRODUCCIO N

MOTIVACIÓN

Las distintas tendencias tecnológicas que han surgido en los últimos años son las responsables en la generación de nuevos paradigmas al momento de diseñar y construir arquitecturas de redes. Es fundamental resaltar que la mayoría de estas arquitecturas actuales son jerárquicas con una estructura de árbol, las cuales se adaptan perfectamente en modelos de computación cliente-servidor. Sin embargo, al mismo tiempo estas arquitecturas son estáticas frente a los nuevos desafíos en donde una computación y un almacenamiento dinámico son necesarios.

Algunas de las principales tendencias tecnológicas que han influenciado en este proceso de generación de nuevos paradigmas y en un sentido similar, han generado nuevas necesidades y requerimientos de negocio en la industria son presentadas a continuación:

 Virtualización: El hecho principal que una máquina/servidor tenga la capacidad de simular más máquinas/servidores y simular funciones de diferentes dispositivos (Ej: routers, switches), han convertido a la virtualización una tendencia en la computación. Cabe aclarar que las ventajas en la virtualización no es solo ahorrar espacio físico, sino por el contrario aprovechar los recursos computacionales que poseen las máquinas/servidores y su superioridad para simular cualquier dispositivo, ofreciendo beneficios económicos no sólo en infraestructura, sino también en la administración.

(4)

4

 Cloud Computing: Ante el auge de los servicios de computación en la nube (ya sean nubes privadas, públicas y mixtas) y la gran adopción por parte de la industria y de los usuarios finales,

cloud computing es una tendencia fundamental que ha estado (y seguirá) creciendo en el tiempo. Algunos de los elementos diferenciadores frente a los modelos On Premise son:

o Ahorros en tiempos de ejecución debido a que la mayoría de proyectos consisten en una personalización de una solución en lugar de instalación de un software empresarial donde existen altas probabilidades de fallos y errores en la implementación de los proyectos. o Está basado principalmente en un modelo de subscripción, ofreciendo una flexibilidad al

momento de consumir un servicio al poder tanto crecer cómo decrecer de acuerdo a las necesidades del negocio y de pagar por los recursos que realmente se estén usando (Pay as You Need), dejando atrás la complejidad en la adquisición de licencias, la instalación y el mantenimiento de infraestructura.

o Gran efectividad de estas soluciones en diferentes frentes debido a que empresas de gran tamaño cómo Oracle, Amazon o Microsoft han invertido grandes sumas de dinero para ofrecer niveles de servicios o SLAs (Service Level Agreements) que son complejos de sostener con infraestructura propia. Esto principalmente influye en empresas con poco capital de inversión cómo las startups.

Son estas algunas de las principales razones por la cloud computing es una tendencia, ofreciendo una gran cantidad de ventajas tanto en modelos B2B (orientado a empresas) como en B2C (orientado a clientes). Sin embargo desde el punto de vista de las empresas que ofrecen estos servicios, este modelo exige un nivel alto de flexibilidad y escalabilidad frente a los recursos de computación, almacenamiento y redes.

 Big Data: La gran cantidad de información generada a partir de la interacción de las personas en los diferentes medios digitales, conocido como la web 2.0, les da a las organizaciones la opción de analizar data que generalmente es no estructurada (ej: blogs, comentarios, imágenes, videos) presente en fuentes tanto internas como externas, buscando enriquecer sus sistemas empresariales. Un claro ejemplo se puede observar en torno a lo que se conoce como Experiencia del Cliente (CX), en la cual las redes sociales son consideradas como un canal fundamental para las organizaciones debido a que muchas conversaciones de sus clientes, usuarios o ciudadanos están ocurriendo allí. Por ende, poder interactuar con ellos, llevarles una trazabilidad multi-canal a mis usuarios y ofrecerles una experiencia única es fundamental hoy en día en las organizaciones principalmente en una época (customer centric) donde los usuarios tienen cada vez más poder y voz.

 Computación Móvil (BYOD): Adicionalmente a los diversos medios digitales que han surgido, la tecnología ha influido enormemente al cambio en el comportamiento de los usuarios a través de múltiples dispositivos cómo los smartphones, tablets, smartwatches, portátiles, entre otros. Esta tendencia ha influenciado a los usuarios a estar siempre conectados desde cualquier dispositivo tanto empresarial como personal (Bring Your Own Device, BYOD), obligando a los encargados de TI (Tecnología de información) a tomar acciones para ajustar las redes a los patrones de tráfico variables sin perder de vista los requerimientos de seguridad existentes en las organizaciones.

(5)

5

Son estos los principales motivos y las nuevas necesidades a las que se enfrentan las organizaciones, por lo que se empezaron a generar nuevos paradigmas en torno a esta situación. Es acá donde han sido creadas algunas arquitecturas emergentes cómo Software-Defined Networking (SDN) o Network Function Virtualization (NFV), y la iniciativa y el interés de investigar acerca de este tipo de soluciones, en el cual se concentrará este proyecto.

Imagen 1. Motivación de Software-Defined Networking [1]

Estructura del documento

El documento presente se dividió en 3 secciones principales con el objetivo de llevar un hilo conductor del proyecto y lograr su completo entendimiento. La primera sección está conformada por los primeros dos capítulos, los cuales dan una introducción y descripción del problema que abarcará el proyecto, junto a los objetivos propuestos. La segunda sección está conformada por los capítulos 3 &4, donde se realiza una investigación de aquellas arquitecturas emergentes propuestas cuya función es combatir el nuevo paradigma presentado y se realiza de igual modo, la implementación de estas arquitecturas con su descripción detallada. Finalmente la última sección está compuesta por el capítulo 5, el cual detalla las conclusiones del proyecto y resalta el trabajo futuro.

(6)

6

2. DESCRIPCIO N GENERAL

2.1. Objetivos

2.1.1. Objetivo General

Ante las nuevas arquitecturas emergentes cuyo propósito ha sido atacar la problemática presentada anteriormente, el objetivo será investigar dos de aquellas arquitecturas emergentes (SDN & NFV) e implementar una topología de red basada en Software-Defined Networking (SDN).

2.1.2. Objetivos Específicos

1. Realizar una investigación sobre las arquitecturas emergentes de SDN & NFV

2. Implementación de un proyecto de SDN con el despliegue de una topología previamente definida

3. Implementación de diferentes controladores (“cerebros”) de SDN en los distintos niveles de acceso presentados a continuación:

a. Al mismo nivel de la herramienta Mininet b. Al mismo nivel de la máquina virtual

c. A nivel del host (fuera de la máquina virtual)

3. INVESTIGACIO N

3.1. Software Defined Networking (SDN)

3.1.1. Descripción

Arquitectura emergente la cual desacopla el control de la red del ruteo (forwarding) realizado por los diferentes dispositivos que componen una red (switches & routers), permitiendo que la infraestructura sea abstraída de las aplicaciones y los servicios de la red. Es decir, a través de un controlador se centralizará la inteligencia de la red, y por ende, la misma red estará representada por un único switch lógico ante las diferentes aplicaciones y dispositivos que quieran accederla como se puede apreciar en la Imagen 2.

(7)

7

Imagen 2. Arquitectura basada en Software Defined Networking [3]

3.1.2. Inicio

En base a la información de SDN Central [2] & Open Networking Foundation [3], SDN nació en las redes de los campus (~ 2008) donde los investigadores buscaban centralizar el control para evitar tener que entrar el software de cada dispositivo de la red al momento de querer realizar cambios. Se argumenta que nació allí ya que ellos fueron los encargados de impulsar diferentes aspectos fundamentales en una arquitectura SDN como el desacoplamiento de la inteligencia (control) de la red de las funciones de forwarding (tarea de cada dispositivo) y posterior centralización del control. Sin embargo, los data centers y las nubes (privadas, públicas o hibridas) son los casos de uso en la industria donde más tuvo y siguen teniendo éxito por la flexibilidad, agilidad y demás beneficios que ofrece SDN (presentados a continuación).

3.1.3. Beneficios

A continuación se presentan algunos beneficios asociados a este nuevo paradigma de diseñar y crear arquitectura de redes:

 Administración centralizada: Toda la inteligencia de la red queda centralizada como una única entidad lógica frente a todas las aplicaciones, motores de políticas y demás dispositivos, permitiendo una configuración y orquestación dinámica frente a cualquier nuevo requerimiento. Adicionalmente SDN interactúa y relaciona el hardware con el software, facilitando la administración de cualquier dispositivo físico o virtual en la red.

 Agilidad: Permite de forma dinámica ajustar el tráfico de la red y crear nuevas políticas de acuerdo a las nuevas necesidades en cualquier momento y desde cualquier lugar.

(8)

8

 Flexibilidad: La red puede crecer o disminuir de forma sencilla debido a que un “cerebro” los controla y orquestra dichos dispositivos, evitando entrar físicamente a cada dispositivo a cambiar el control de comunicación. Adicionalmente cómo es una capa de software que desacopla la inteligencia de la red de los dispositivos físicos, SDN no es dependiente de las funcionalidades que preste el hardware (vendedor/proveedor).

 Habilita la innovación: Las organizaciones pueden desplegar rápidamente nuevas aplicaciones y servicios para ajustarse a nuevos requerimientos de negocio.

 Costos: Este nuevo paradigma impacta en la reducción de costos tanto en el capital (CapEX) cómo en la operación (OpEX). El motivo principal de la reducción en el CapEX se ve asociado a la eliminar los costos adicionales de sobre-aprovisionamiento donde no se explotan los recursos al máximo y evitar la compra de recursos de circuito integrados para aplicaciones específicas (ASIC, sigla en inglés) gracias a OpenFlow, protocolo del cual se hablará más adelante. Adicionalmente reduce adicionalmente la complejidad en la gestión de las redes tanto en tiempo como en la disminución de errores humanos al tener una visión global de la red, afectando directamente en el OpEX.

3.1.4. Principal Promotor

La principal entidad promotora de SDN es la Open Networking Foundation, comunidad encargada de facilitar la adopción de esta arquitectura en base a estándares de desarrollo abiertos orientados a la industria, como el OpenFlow Standard [4], protocolo del cual se discutirá más adelante.

3.2. Network Function Virtualization (NFV)

3.2.1. Descripción

Arquitectura de red la cual desacopla los servicios de red de hardware propietario y de propósito específico. Es decir, su objetivo principal es poder prestar cualquier servicio de la red cómo la traducción de las direcciones de red (NAT, sigla en inglés), firewall, balanceo de carga, caching, sistema de nombres de dominio (DNS, sigla en inglés), entre otros, de una forma virtual a través de software. Cómo se mencionó previamente, dado a los grandes avances que se han presentado tecnológicamente y al uso de la virtualización, en pocas palabras cualquier función o servicio que sea generado por un dispositivo puede ser replicado en software y de esta forma desacoplar estos servicios del hardware, ilustrándose estos cambios de arquitectura en la Imagen 3 y trayendo consigo un conjunto de beneficios los cuales se ilustrarán más adelante.

(9)

9

Imagen 3. Network Function Virtualization. Fuente: Steve Noble

3.2.2. Inicio

A diferencia de SDN, el concepto de NFV nació por parte de los proveedores de servicio del sector de Telecomunicaciones, los cuales ante la necesidad de acelerar los despliegues de servicios y al contar con restricciones a nivel de dispositivos físicos (hardware), decidieron usar tecnologías de virtualización estándares para ejecutar dichos servicios previamente mencionados.

3.2.3. Beneficios

A continuación se presentan algunos beneficios asociados a la arquitectura NFV:

 Acelerar el tiempo de salida al mercado (Time-to-Market): Reduce el tiempo de despliegue de los nuevos servicios y el riesgo asociado que conlleva esta acción.

 Flexibilidad & Agilidad: Similar a SDN, esta arquitectura ofrece dichos beneficios para adaptarse de forma rápida a los cambios en el negocio o nuevos requerimientos por ofrecerse virtualmente.

 Costos: Similar a SDN, reduce el CapEX en este caso al evitar comprar hardware de propósito específico (Ej: servidor encargado de realizar el NAT) y evitar el sobre-aprovisionamiento. Por otro lado, reduce el OpEX en la gestión de los servicios (disminución de complejidad) y al evitar el mantenimiento de los dispositivos.

(10)

10

3.2.4. Principal Promotor

Diversos proveedores (Telcos) [5] tomaron la iniciativa de crear un comité con el apoyo de la ETSI (European Telecommunications Standards Institute) conocido como ETSI Industry Specification Group for NFV, los cuales se centraran en crear estándares para esta arquitectura definiendo los requerimientos sobre la virtualización de las funciones ya mencionadas.

3.3. SDN vs NFV

Es claro reconocer que las dos arquitecturas emergentes no son comparables directamente ya que están enfocadas en “atacar” diferentes problemáticas. Sin embargo, en la Tabla 1 se puede resumir las principales características de cada una [2].

Categoría SDN NFV

Principales necesidades a

cubrir

Desacoplamiento del control de la red de la función de forwarding

Centralización del control

 Virtualizar servicios y funciones que normalmente realiza hardware de propósito específico

Inicios Campus [Alrededor del 2008] Proveedores de servicio del sector de telecomunicaciones (Telcos) [2012] Casos de uso Data centers y nubes (privadas,

publicas e hibridas).

Proveedores de servicio del sector de telecomunicaciones (Telcos)

Infraestructura necesaria

Servidores & switches Servidores & switches

Funcionalidad inicial

Orquestación de la red

Orquestación del cloud

 Virtualizar funciones cómo routers, firewalls, gateways, CDN, caching, etc. Protocolos

usados

OpenFlow, creado en Standford y desarrollado por la ONF.

No está definido Principal

Promotor

Open Networking Foundation (ONF).

Principales miembros [6]:

 Deutsche Telekom

 Facebook

 Goldman Sachs

 Google

 Microsoft

 NTT Communications

 Verizon

 Yahoo!

ETSI Industry Specification Group for NFV. Principales miembros [5]:

AT&T

BT

China Mobile

CenturyLink

Deutsche Telekom

Orange

Telefonica

Verizon Tabla 1. Resumen de SDN vs NFV

(11)

11

4. IMPLEMENTACIO N

4.1. Herramientas

4.1.1. Herramientas Generales

A continuación se presenta el listado con una corta descripción de aquellas herramientas utilizadas en el proyecto, asociadas específicamente a SDN o NFV.

4.1.1.1. OpenFlow

(

www.openflow.

org

)

Interfaz abierta que permite controlar las tablas encargadas del

forwarding en switches, routers y access points. Se utilizó cómo protocolo de comunicación entre el controlador de SDN y los dispositivos de la red.

4.1.1.2. Mininet

4.1.1.5. OpenDayLight

(

http://www.opendaylight.org/

)

Controlador de SDN Open-Source creado para la industria con el apoyo de Linux Fundation. Incluye también Network Function Virtualization (NFV). Se utilizó como controlador de Mininet con el objetivo de ejecutar un controlador a un nivel de acceso remoto (fuera de la máquina virtual).

(12)

https://www.python.org

)

Lenguaje de programación orientado a objetos desarrollado por

Oracle Corporation en el caso de Java. Python es un lenguaje de programación de propósito general desarrollado por Python Software Foundation. Se utilizaron principalmente para compilar y ejecutar

(13)

13

4.2. Despliegue de la topología

4.2.1. Aspectos Generales

En esta sección se discutirán aspectos generales en el despliegue de la topología. Primero, fue necesario iniciar la máquina virtual la cual contiene Mininet (http://mininet.org/download/) y empezar a instalar diferentes herramientas tales como Java, Firefox y los controladores que tenían pensado ir dentro de la máquina virtual. En la Imagen 4 se puede apreciar la configuración de red de la máquina virtual.

Imagen 4. Configuración de la red

Luego, cuando está configurado, a través de Mininet se ejecuta la topología necesaria con el siguiente comando: $ sudo mn y adicionalmente se adicionan los parámetros que definen dicha topología. Cómo parámetros principales está definir la estructura de la topología (- -topo), el tipo del switch en el cual se desea que este sea uno virtual (- -switch) y el controlador en el caso que se desee usar otro adicional al POX que viene preinstalado (- -controller). Mininet cuenta con una estructura de directorios con archivos que son de Python (extensión .py), los cuales son fundamentales al momento de querer reescribir la topología (crear una personalizada) o escribir un controlador que aprenda de forma proactiva sobre los elementos que conforman la red.

(14)

14

La topología sobre la cual se trabajó se puede observar en detalle en la Imagen 5 y la Imagen 6. En la primera de estas se puede observar desde Mininet la estructura de la red, donde existe un controlador (c0) del cual se entrará en detalle más adelante, 1 switch principal (s1) el cual servirá como router y 2 switches (s2 & s3) debajo de este (s1), los cuales poseen las conexiones con los hosts. En esta topología se crearon 4 hosts, los cuales están separados en parejas por switch, implicando que el switch (s2), estará conectado con 2 hosts (h1 & h2) y el switch (s3) estará conectado con los otros 2 hosts (h3 & h4). Esta misma topología se puede observar en la segunda imagen (Imagen 6), la cual es una representación gráfica de lo mencionado previamente.

Imagen 5. Topología desplegada en Mininet

(15)

15

La información acerca de los controladores se hablará en la siguiente sección. Sin embargo, un aspecto fundamental general es el protocolo OpenFlow del cual se habló anteriormente, y más en concreto, el análisis sobre los paquetes que usan este protocolo con una herramienta como

Wireshark. A continuación la Imagen 7 representa justamente una captura realizada en esta herramienta luego de realizar un ping desde el primer host (h1) hasta el tercer host (h3), los cuales según nuestra topología se encuentran bajo switches distintos.

Imagen 7. Wireshark

Los aspectos fundamentales a describir de esta imagen son los siguientes:

 En el filtro de Wireshark se encuentran 2 caracteres, ‘of’, los cuales realiza un filtro rápido para visualizar aquellos paquetes que usen el protocolo OpenFlow.

 En el primer conjunto de paquetes registrados, se puede observar que el destino es broadcast, y esto ocurre ya que las tablas de forwarding inicialmente están vacías, por lo que es necesario lanzar un mensaje en broadcast para preguntarles a todos. En este conjunto el protocolo usado es OFP + ARP y está basado en una comunicación a través de las direcciones MAC.

(16)

16

 En el segundo conjunto de paquetes registrados, se puede observar que el host 3 responde al mensaje de broadcast diciendo la IP del host a través del protocolo OFP + ARP.

 En el tercer conjunto de paquetes registrados, se pueden observar que el protocolo es OFP, cuya descripción establece que se realiza un Flow Mod. Este Flow mod se puede ver en detalle al final de la imagen, donde es parte del protocolo de OpenFlow para que el controlador comience a almacenar dichas tablas y a aprender sobre la red de la cual está a cargo (Flow Mod=Flow Modification). Allí en este protocolo se pueden definir diferentes parámetros entre los cuales está por ejemplo los timeouts para eliminar la información de las tablas, una índice de prioridad sobre el flujo de comunicación entre distintos puntos, un comando que en este ejemplo es “New Flow” ya que hasta ahora se está aprendiendo sobre la red, entre otros parámetros.

 Finalmente el ultimo conjunto de paquetes registrados, identificados con el protocolo OFP + ICMP, corresponden ya al ping realizado desde primer host (h1) hasta el tercer host (3), ya a través de las direcciones IPs.

4.2.2. Controladores

4.2.2.1. POX

Este es el primer controlador usado ya que viene preinstalado con Mininet y está basado en Python. La razón por la cual se usó era para realizar las pruebas iniciales (disminuir curva de aprendizaje) y ejecutar un controlador que esté en el mismo nivel de la solución (Mininet).

Respecto a este controlador es necesario programarlo para el auto-aprendizaje, ya que por defecto la única forma de añadir los flujos es a través del comando $ dpctl, en donde con un comando cómo $ dpctl add-flow tcp:127.0.0.1:6634 in_port=1,actions=output:2, se define el flujo entre los distintos puertos especificados. Es decir, que es responsabilidad de el usuario agregar los flujos ya sea programándolos o de forma manual cómo se presentó anteriormente, porque de lo contrario va a ocurrir la situación de la Imagen 8 en donde todos los paquetes se van a perder inicialmente ya que nadie se comunica con nadie.

(17)

17

4.2.2.2. FloodLight

Este es el segundo controlador usado el cual se instaló en la maquina virtual y es basado en Java. La razón por la cual se usó principalmente fue para ejecutar un controlador que esté dentro de la máquina virtual no a nivel de la solución (Mininet) y poder probar diferentes aspectos de la programación debido a que su lenguaje es Java.

FloodLight funciona similar al siguiente controlador (OpenDayLight) desde el punto de vista SDN, y lo interesante en este aspecto es que estos controladores aprenden automáticamente, por lo cual en una fase inicial tienen que hacer el broadcast para que se conozcan los diferentes elementos de la red, sin embargo esto cambia después de la primera comunicación disminuyendo considerablemente el tiempo de respuesta de los mensajes. Esto último mencionado se puede apreciar en las siguientes 3 imágenes, las cuales se encuentran divididas por fases. La primera fase (Imagen 9) consiste en la primera vez que se van a comunicar, por lo cual el primer ping tiene una duración de 6.02 ms (etapa de conocimiento y aprendizaje) mientras que los siguientes tienen un duración menor a 0.2ms. La segunda fase consiste en realizar un ping después de haber transcurrido un tiempo, esto con motivo de que caduque el flujo en la tabla por el cual sea necesario volver a realizar un broadcast, sin embargo aunque el primer flujo es alto en comparación a los siguientes pings, se puede observar que la duración del primer ping es mucho menor respecto al ping inicial de la primera fase. Finalmente la tercera fase consistió en realizar un ping enseguida de la segunda fase, por lo cual se puede observar que los tiempos son muy bajos.

Imagen 9. h1 ping h2 (1era fase)

(18)

18

Imagen 11. h1 ping h2 (3ra fase)

Otra de las ventajas de Floodlight es su GUI web donde en tiempo real se puede monitorear la topología de la red que administra el controlador. En la Imagen 12 se puede observar la misma información respecto a la topología, donde existen actualmente 3 switches y 4 distintos hosts, lo cual a través de la Imagen 13 lo representa gráficamente.

(19)

19

Imagen 13. Representación Gráfica de la Topología en Floodlight

4.2.2.3. OpenDayLight

Este es el último controlado usado en el proyecto, el cual corre sobre el S.O local de la máquina, es decir afuera de la máquina virtual. La razón por la cual se utilizó OpenDayLight

fueron principalmente 2 motivos: el primero debido a la gran acogida por parte de la industria de este controlador, y la segunda ya que posee tanto SDN como NFV.

Luego de ejecutar este controlador y ejecutar la topología en Mininet definiendo como parámetro que el controlador estará remoto en una dirección IP asignada, se prosiguió a realizar las pruebas entre los diferentes hosts. Allí, al igual que Floodlight, existe un periodo de adaptación en donde las tablas de forwarding se comienzan a llenar. Sin embargo, este controlador es mucho más robusto ofreciendo una gran oferta de distintas opciones al momento de crear un flujo cómo se puede apreciar en la Imagen 14, o hasta especificar que los nodos en mi red se comporten de forma reactiva o proactiva (Imagen 15). Finalmente en la Imagen 16 & la Imagen 17, se puede apreciar gráficamente la configuración de la topología junto a las características de los dispositivos (nodos) y de los flujos construidos, permitiendo desde la misma interfaz una fácil modificación de estas (cabe resaltar que en las últimas versiones de OpenDayLight, no se visualizan los hosts en el dashboard).

(20)

20

Imagen 14. Opciones de configuración de OpenDayLight

(21)

21

Imagen 16. Topología prevista en OpenDayLight

(22)

22

4.2.2.4. Resumen

Categoría POX FloodLight OpenDayLight

Lenguaje Python Java Java

Comunidad Nicira Networks Big Switch Networks The Linux Foundation

Nivel de

Ejecución Local (dentro de Mininet)

Remota (dentro de la misma máquina virtual)

Remota (fuera de la máquina virtual)

Ventajas

Controlador liviano que viene preinstalado en la MV de Mininet.

Versión licenciada de Apache y es el core de los productos de Big Switch Networks.

Existen 3 versiones del controlador con distintas características.

 Soporta NFV

Interfaz que permite la edición de topologías desde el portal web

Desventajas

Es una versión muy básica a partir de NOX.

Flujos es necesario agregarlos de forma manual

No soporta NFV

Desde la interfaz web no se puede editar las topologías

Al estar pre-construido en 3 versiones cuenta a veces con herramientas innecesarias y un ambiente no liviano. Link http://www.noxrepo.org/

pox/about-pox/

http://www.projectfloodlight .org/floodlight/

https://www.opendaylight .org

Tabla 2. Comparación de los distintos controladores

5. RESULTADOS

5.1. Conclusiones

En el proyecto se presentó una aproximación a aquellas arquitecturas de redes emergentes que han estado tomado fuerza con el tiempo para contrarrestar las antiguas arquitecturas de red que se acoplaban a modelos clientes-servidor, las cuales permiten agilidad en el despliegue de infraestructura para ofrecer nuevos servicios emergentes y un mejor diseño ante nuevos paradigmas como la computación en la nube, virtualización, computación móvil, entre otros. En resumen, en este proyecto se logró lo siguiente:

1. Estudio de la problemática a tratar y un análisis de las alternativas más conocidas y soportadas por la industria y la academia que son las arquitecturas SDN & NFV

2. Ejecución de una arquitectura SDN con la topología propuesta compuesta de un controlador, un router, dos switches y cuatro hosts apoyado en Mininet, software para realizar virtualización de redes (switches & hosts).

(23)

23

3. Investigación de los distintos controladores existentes en el mercado compatibles con el protocolo OpenFlow.

4. Ejecución de 3 distintos controladores con diferentes niveles de acceso respecto a Mininet

cómo lo son POX, FloodLight & OpenDayLight.

Finalmente cabe resaltar la gran acogida que han tenidos estos nuevos paradigmas en la industria y en la academia, y el respaldo que han tenido de distintas asociaciones donde los principales promotores son empresas de gran tamaño como Google, Microsoft, AT&T y Verizon.

5.2. Trabajos Futuros

Ante la necesidad de querer solucionar una problemática extensa y compleja, el proyecto se centró en investigar principalmente dos arquitecturas emergentes cómo lo fueron SDN & NFV. Al investigar acerca de ellas y observar que no son directamente comparables ya que tienen objetivos distintos, se enfocó el proyecto en SDN y en desplegar dicha arquitectura a través de diferentes cerebros o controladores cómo fue presentado. Sin embargo, cabe resaltar la importancia de la NFV cómo arquitectura para la virtualización de distintos servicios prestados por la red cómo DNS, caching, firewall, NAT, entre otros, por lo cual se recomendaría explorar a profundidad en trabajos futuros.

6. REFERENCIAS

[1] Ochs, G. (2013). Software Defined Network (SDN). Universidad de Stuttgart – Curso de SmartCloud realizado por IBM . [En línea] [Citado el 14 de mayo de 2014]

http://www.iaas.uni-stuttgart.de/lehre/vorlesung/2013_ws/vorlesungen/smcc/materialien/SoftwareDefinedNetwork_20131024_v04.pdf [2] Pate, P. (2013) NFV and SDN: What’s the Difference? [En línea] [Citado el 14 de mayo de 2014]

http://www.sdncentral.com/technology/nfv-and-sdn-whats-the-difference/2013/03/

[3] ONF White Paper (2013). Software-Defined Networking: The New Norm for Networks [En línea] [Citado el 14 de mayo de 2014]

https://www.opennetworking.org/images/stories/downloads/sdn-resources/white-papers/wp-sdn-newnorm.pdf

[4] Open Networking Foundation. OpenFlow Standard. [En línea] [Citado el 14 de mayo de 2014]

https://www.opennetworking.org/sdn-resources/onf-specifications/openflow

[5] ISG NFV. List of Members. [En línea] [Citado el 14 de mayo de 2014] http://portal.etsi.org/NFV/NFV_List_members.asp

[6] NEC Corporation of America. Ten things to Look for in an SDN Controller. [En línea] [Citado el 20 de mayo de 2014]https://www.necam.com/Docs/?id=23865bd4-f10a-49f7-b6be-a17c61ad6fff