rafael eduardo carrillo villamizar
TRANSCRIPT
1
SOFTWARE DEFINED NETWORKING (SDN)
Proyecto de grado presentado por
RAFAEL EDUARDO CARRILLO VILLAMIZAR
Asesor
YEZID DONOSO, Ph.D
Profesor Asociado Departamento de Ingeniería de Sistemas y Computación
UNIVERSIDAD DE LOS ANDES
Mayo de 2014, Bogotá D.C., Colombia
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
6. REFERENCIAS ....................................................................................................................................... 23
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
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
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
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
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
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
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
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
Goldman Sachs
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
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 (www.mininet.org)
Herramienta Open-Source que permite crear una red virtual de SDN con hosts, controladores y switches (basado en Open vSwitch). Hace uso de OpenFlow cómo protocolo de comunicación y de POX como controlador. Se utilizó justamente para crear la topología de la red virtual.
4.1.1.3. POX (http://www.noxrepo.org/)
Controlador de SDN Open-Source implementado en Python. Es el controlador que Mininet tiene instalado por defecto. Se utilizó para ejecutar un controlador al mismo nivel de acceso de Mininet.
4.1.1.4. FloodLight (www.projectfloodlight.org)
Controlador de SDN Open-Source implementado en Java. Se utilizó como controlador de Mininet con el objetivo de ejecutar un controlador a un nivel de acceso remoto pero dentro de la misma máquina virtual.
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
4.1.2. Herramientas Generales
A continuación se presenta el listado con una corta descripción de aquellas herramientas utilizadas en el proyecto, pero que no están asociadas específicamente a SDN o NFV.
4.1.2.1. Wireshark (http://www.wireshark.org/)
Herramienta Open-Source cuya función principal es analizar paquetes transmitidos en una red. Se utilizó para monitorear una interfaz de red donde se estaban transmitiendo los paquetes con el protocolo de OpenFlow.
4.1.2.2. VirtualBox (https://www.virtualbox.org/)
Herramienta de virtualización de sistemas operativos de Oracle Corporation. Se utilizó para ejecutar el sistema operativo Ubuntu en la máquina virtual.
4.1.2.3. Ubuntu (http://www.ubuntu.com/)
Sistema operativo de Linux basado en Debian y S.O por defecto en la máquina virtual de Mininet.
4.1.2.4. PuTTY (http://www.putty.org/)
Herramienta Open-Source usada como emulador de terminales (consolas). Se utilizó para iniciar distintas sesiones de forma simultánea y ejecutar distintos procesos paralelamente.
4.1.2.5. Xming (http://www.straightrunning.com/XmingNotes/)
Implementación del Sistema de ventanas X (X Window System) para sistemas
operativos de Microsoft Windows. Se utilizó para habilitar las interfaces gráficas
de Firefox y Wireshark.
4.1.2.6. Firefox (http://www.mozilla.org/en-US/firefox)
Navegador Web Open-Source desarrollado para Windows, OS X, Linux y Android.
Se utilizó para desplegar la GUI de FloodLight y ver en el navegador web la
topología desplegada.
4.1.2.7. Java (http://www.java.com/en) & Python (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
FloodLight & POX respectivamente.
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
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
Imagen 6. Representación gráfica de la topología
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
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.
Imagen 8. Pingall 100% dropped
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)
Imagen 10. h1 ping h2 (2nda fase)
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.
Imagen 12. Dashboard de Floodlight
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
Imagen 14. Opciones de configuración de OpenDayLight
Imagen 15. Información del nodo
21
Imagen 16. Topología prevista en OpenDayLight
Imagen 17. Configuración de flujos en OpenDayLight
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
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
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