Redes Definidas por Software

1. Universidad Nacional Autónoma de Nicaragua
Unan-León
Facultad de Ciencias yTecnología
Tesis para optar alTitulo de
Ingeniero enTelemática
Elaborado por:
 Br. Alexander Ernesto Aragón García
 Br. Mauricio Antonio Castro Bustillo
 Br. Edward Ricardo Garth Pérez
Tutor: Msc. Aldo Rene Martínez Delgadillo

2. Redes Definidas por Software (SDN): Un nuevo paradigma
frente a las Redes Convencionales.
Tema

3. Antecedentes.
Planteamiento del Problema.
Objetivos.
Diseño Metodológico.
Marco Teórico.
Desarrollo
Demostración
Conclusión.
Recomendación.
Contenido

4. Introducción
Las redes de computadoras son de suma importancia en nuestra vida laboral,
estudiantil, social, etc. Ya que son un conjunto de equipos de comunicación
conectados por medio de cables, señales, ondas o cualquier otro método de
transporte de datos, que comparten información, recursos, servicios, etc. Uno de los
inconvenientes de las redes actuales es que no poseen flexibilidad concerniente a la
programabilidad de sus elementos, para que la calidad de servicio sea de la
organización en particular.
Las redes son complejas y difíciles de gestionar, debido que ellas envuelven muchos
tipos de equipos, desde routers y switches hasta middleboxes como firewalls, NAT,
balanceadores de carga y sistemas de detección de Intrusos. Los routers y switches
ejecutan complejos software de control distribuidos que típicamente son de carácter
propietario y cerrado. El software implementa protocolos de red que han llevado años
de estandarización y pruebas de interoperabilidad, los administradores de la red
típicamente configuran dispositivos de red individuales usando interfaces de
configuración que varían entre vendedores e incluso entre diferentes productos del
mismo vendedor.

5. Introducción (cont.)
Las SDN tratan de simplificar el desarrollo de nuevas aplicaciones separando el
plano de datos del plano de control. El plano de control es también llamado
controlador, el cual tiene una vista global de la red y controla el flujo que
atraviesa esta misma. La inteligencia es ahora transferida al controlador, el
switch solo realiza acciones que el controlador solicita, esto hace que los
switches sean únicos y baratos, pero en las redes tradicionales cada dispositivo
tiene un vendedor especifico de sistema operativo que controla el plano de
datos.
El plano de control SDN ejerce un control directo sobre el plano de datos de la
red (por ejemplo, routers, switches y otros middleboxes) mediante una API bien
definida llamada Openflow que permite controlar remotamente las tablas de
reenvió en una red de switches, routers y Access Points.

6. Antecedentes
La idea de programar redes no es nueva, hay varias contribuciones anteriores a
SDN. Una de ellas es SOFTNET, que por los años 80, era una red multisalto,
semejante a las a las actuales WSN (Wireless Sensor Networks) cuya innovación
fue que en el campo de datos de cada paquete se incluían comandos que los
nodos iban ejecutando a medida que los iban recibiendo.
Las Active Networks presentaban una arquitectura consistente en llevar embebido
en los paquetes pequeños, programas que podían ser ejecutados por los nodos
que éstos atraviesan. Esto hacía posible que los switches y routers de la red
procesaran los paquetes de datos, haciéndoles partícipes de los mensajes y no
solo meros espectadores que se limitaban a enviar mensajes de un puerto a otro,
de una forma “pasiva”. De ahí el nombre de Active Networks.

7. Planteamiento del Problema
En la actualidad con el auge de la tecnología, la modernización de los equipos que
brindan el manejo y control de los sistemas de interconexión de las redes se ha
planteado la necesidad de estudiar y profundizar sobre mecanismos que ayuden
al mejoramiento y agilización de las redes para brindar una eficiencia en el control
de los datos que viajan a través de la misma.
Las Redes Tradicionales:
No son flexibles. Se comportan en base a las reglas (protocolos) que incorporen
los fabricantes de dispositivos. Lógicamente, cuanto más configurables sean
éstos, más costosos serán.

8. Planteamiento del Problema (cont.)
Están basadas en multitud de reglas predefinidas. Los protocolos
actuales están basados en más de 5000 RFCs, y cualquier modificación que
se sugiera ha de pasar un tedioso proceso de estudio y aprobación por parte
de los organismos competentes (IETF principalmente).
Limitan la investigación y el desarrollo. Evidentemente, los fabricantes y
administradores de redes, son reticentes a experimentar y desarrollar nuevos
paradigmas en redes que ya funcionan de una forma “satisfactoria”. Es el
célebre “si funciona no lo toques”.
Es muy complicado introducir nuevas propuestas. Este punto enlaza
directamente con el anterior. Cualquier innovación, aunque ya esté aprobada
en su RFC, es muy complicado.

9. Justificación
La creación de este trabajo con el fin de optar al título de Ingeniero en Telemática
tiene como fin mejorar la calidad y el proceso de enseñanza que tiene el
departamento de computación de la UNAN-León.
Será un inicio en el proceso de documentación que les permita asignar prácticas
guiadas a los estudiantes con el fin de integrarse al mundo actual sobre el manejo
de las redes definidas por software.
Comprender los temas más recientes sobre el uso y monitorización de las redes
de manera que con los temas y las prácticas de laboratorios a resolver sirvan
para el día a día que deban enfrentar en el ámbito laboral una vez sean
egresados y profesionalizados de la carrera de Ingeniería en Telemática.

10. Justificación (cont.)
Guiado: se espera describir paso a paso cada una de las formas en que se debe estudiar
el protocolo de manera que sirva de guía básica para el uso del mismo.
Sencillo: las guías aplicativas serán elaboradas de manera sencilla para su fácil
comprensión, de manera que sea una forma de aprendizaje fácilmente entendible por los
estudiantes.
Secuencial: se establecerá una forma secuencial de cada uno de los métodos de
desarrollo para la elaboración de las mismas de manera que se pueda obtener buenos
resultados en la finalización de los mismos.
Esto permitirá constar con un material de apoyo sencillo pero eficiente tanto para el
personal docente, como recursos en formación (estudiantes) sobre el manejo del protocolo
Openflow basados en redes SDN. De manera que sea un buen inicio de la sistematización
y manejo de los recursos de la red.

11. Objetivos
Objetivo General:
 Diseñar prototipos de redes definidas por software SDN utilizando el protocolo
OpenFlow mediante el uso de diversos controladores OpenSource
 Proporcionar aspectos introductorios a SDN y al protocolo OpenFlow,
resaltando las características generales, arquitectura, ventajas y desventajas.
 Implementar los elementos básicos de una red mediante la simulación en el
programa Mininet, seleccionando diferentes controladores dependiendo de la
operatividad, funcionalidad y facilidad de uso de los mismos.
 Gestionar de forma centralizada los dispositivos que comprenden la topología
planteada en el diseño de la red definida por software, con el propósito de resaltar
las bondades de este nuevo paradigma.
Objetivos Específicos:

12.  Control central de la red (data desde 1980 en AT&T )
 Redes Activas (1990)
 Virtualizacion de la Red (1990)

13.  Control central de la red (data desde 1980 en AT&T )
 In-Band signaling
• Voz y datos eran enviados sobre el mismo canal
• Ciertas frequencias podian resetear lineas telefonicas (2600 Hz)
 NCP
• Vista extensa desde el NCP
• Evolución independiente de la infraestructura, datos y servicios.
Beneficios de un control central
• Vistas puntuales de redes extensas
• Independencia de la evolución de infraestructura, datos y servicios

14.  Redes Activas (1990)
Redes donde los switches realizaban cálculos personalizados sobre los paquetes.
Ejemplos: Middleboxes, proxies, aplicaciones de servicio, etc.
Motivación
 Acelerar la innovación
 Nodos activos
Proyectos
 ANTS (MIT)
 SwitchWare (Penn)
 Smart Packets (BBN)
 Open Signaling (Columbia)
 Tempest (Cambridge): Switchlets by IETF
Porqué estos proyectos no tuvieron éxito?
Legado de las redes activas para SDN
 Funciones programables
 Demultiplexación de programas en la cabecera de los paquetes (PLANETLAB, FLOWVISOR, GENI, etc)
Desarrollo Teórico

15.  Virtualización de la red
Es la representación de una o más topologías lógicas de red encima de la misma infraestructura física subyacente.
Beneficios de la Virtualización
• Compartir
• Personalizar
Tres ejemplos de redes virtuales
• Tempest: Switchlets (1998)
• VINI: A Virtual Network Infrastructure (2006)
• Cabo: Separates infrastructure, services (2007)
Legado para SDN?
• Separar los servicios de la infraestructura
• Múltiples controladores desde un único switch
• Topología de redes Lógicas
Desarrollo Teórico

16. Control de redes de conmutación de paquetes
Como controlar una red de conmutación de paquetes?
• Separar el canal de control: FORCES (2003)
• protocolos In-band: Routing Control Platform (2004)
• Hardware abierto: Ethane (2007)
• OpenFlow (2008)
El Hardware abierto permite desacoplar el control y adoptar OpenFlow
Desarrollo Teórico

17. En 2007, un grupo de trabajo de la Universidad de Standford formado por los profesores Nick McKeown, Scott Shenker y el estudiante de
doctorado Martín Casado desarrollaron OpenFlow y fundaron Nicira, una compañía de virtualización de redes. Es a partir de este momento
donde se sitúa el nacimiento de SDN.
¿Qué es OpenFlow?
Openflow es un protocolo de comunicaciones diseñado para dirigir el manejo y enrutamiento del tráfico en una red conmutada, hasta la fecha
los switches decidían hacia donde llevar el tráfico de manera individual y en base al firmware de cada uno de ellos, eran dependiente del
fabricante y dispositivo, con OpenFlow esa decisión dejará de ser tomada de manera individual por cada switch y pasará a estar controlada
por una fuerte de inteligencia externa.
El protocolo OpenFlow define el protocolo de comunicación entre el switch OpenFlow y el controlador. El switch establece la comunicación
con el controlador en una dirección IP, usando un determinado puerto, habitualmente el 6634.
Desarrollo Teórico

18. Ventajas de separar el Plano de Control del Plano de Datos
• Centralización del control
• Control basado en flujos
• Un controlador caro con muchos switches baratos
• La lógica de Control se mueve a un controlador
• Fácil gestión de muchos dispositivos
• Planos de Red
• Switches OpenFlow, incluyendo el switch virtual Open vSwitch by Nicira
• Versiones OpenFlow
Planos de Red
 Plano de Datos: Todas las actividades que involucren o resulten del envío de
paquetes por el usuario final
 Plano de Control: Todas las actividades que son necesarias para llevar a cabo las
acciones del plano de datos pero que no involucran a los paquetes del usuario final.
.
Desarrollo Teórico

19. Componentes de un Switch OpenFlow
• Tabla de flujos
• Canal seguro
• Controlador
Tipos de Switches
• Switches OpenFlow dedicados:
soporta OpenFlow, contiene múltiples tablas de flujos, y cada flujo contiene múltiples entradas de flujo.
• Switches OpenFlow híbridos
soportan tanto la operación OpenFlow como el Switching Ethernet convencional.
Desarrollo Teórico

20. En 2011, Scott Shenker y Nick McKeown fundaron la Open Networking Foundation (ONF), organización que buscaba fomentar el uso de
OpenFlow, la creación de estándares y la implantación de SDN más allá de las universidades.
Debido a la trascendencia que se adivinaba en el cambio a SDN, seis compañías que poseían algunas de las redes más importantes del
mundo anunciaron en 2011 la formación de la ONF. Se trata de una organización dedicada a la promoción y a la mejora y adopción del
networking a través de SDN.

21. Versiones del protocolos OpenFlow
Versiones OpenFlow Especificaciones
OpenFlow Versión 1.0 Match campos de cabeceras con las entradas de la tabla de flujo, actualiza
los contadores y realiza las acciones apropiadas.
OpenFlow Versión 1.1 Acciones sobre un match, solo Ethernet/IP, no soporta MPLS, ni un multicast
con eficiencia.
OpenFlow Versión 1.2 Soporte para IPv6, matches extensibles.
OpenFlow Versión 1.3 Extensión de cabeceras IPv6, soporta MPLS, encapsulación MAC-en-MAC,
túneles VxLAN, conexiones paralelas al controlador, etc.
OpenFlow Versión 1.4 Puertos ópticos, notificar si la tabla esta sin espacio, ejecución automática de
un lote de instrucciones, etc.
OpenFlow Versión 1.5 status connection controller, tables egress

22. Mininet
 Un entorno de red virtul que puede corer en una sola PC
 Ejecuta un kernel real, switch y código de aplicaciones en una sola máquina
 Command-line, UI, Python interfaces
Porqué usar Mininet?
Rápido
Posibilidad de crear topologías personalizadas
Ejecutar programas reales
Switches OpenFlow programables
Fácil de usar
Open source
Topologias por defecto
• Minimal
• Linear
• Single
• Tree
• Custom
Mininet es un emulador de red que ejecuta una colección
de dispositivos finales, switches, routers y enlaces en un
solo core de Linux

23. Controlador
Que es un controlador?
Controladores SDN
Existen muchas consideraciones cuando determinamos que controlador usar; una es la opción de un lenguaje de programación que puede
algunas veces, pero no siempre, afectar el rendimiento del controlador mismo, también cuánto tiempo toma determinar cómo usar el
controlador.
Pyretic
RYU

24. OpenDaylight
OpenDayLight Es un proyecto de Código Abierto
(Open Source) el cuál tiene como objetivo
acelerar y acrecentar la difusión de la innovación
en el diseño e implementación de un estándar
abierto y transparente de Redes Definidas por
Software (RDS), es decir, Software-Defined
Networking (SDN).
Consorcio OpenDayligth

25. SDN
Que és SDN?
Las redes definidas por software (SDN) son una manera de abordar la creación de redes en la cual el control se desprende del hardware y
se le da a una aplicación de software llamada controlador.
Arquitectura de Red Convencional Arquitectura de Red SDN

26. SDN
Ventajas
 Directamente programable
 Ágil: Abstrayendo el control del de reenvío
 Control centralizado
 Configurado programáticamente
Los operadores de red pueden implementar características que quieran en el software que controlan, en vez de tener que esperar que los
fabricantes los ponga en marcha en sus propios productos.
Reduce el gasto de operación, lo que conlleva menos errores y menor inactividad (frente a fallos) ya que permite la configuración
automatizada de la red y reduce la configuración manual.
Arquitectura de Red Convencional Arquitectura de Red SDN

27. Desarrollo Practico
Practica 0: Familiarizarse con el entorno de desarrollo Mininet.
Practica 1: Diseño de la topología de red y modificación manual en la tabla de entrada de
flujo del switch.
Practica 2: Implementación de un hub simple y un switch inteligente utilizado el controlador
POX
Practica 3: Modificación del switch inteligente para que funcione con reglas de firewall.
Practica 4: Explicación y funcionamiento del controlador SDN Ryu.
Practica 5: Utilización de contenedores con “Docker”.
Practica 6: Uso del lenguaje de procesamiento de paquetes P4.
Practica 7: Ejemplo practico del uso del controlador SDN Kinetic.
Practica 8: Definición y uso del Lenguaje SDN Pyretic.
Practica 9: Definición y uso del controlador comercial FloodLight.
Practica 10: Simulación de un ataque DoS en redes SDN usando el controlador FloodLight y
la herramienta de gestión sFlow-RT.
Practica 11: Experimentación de Bufferbloat en un router casero.

28. Desarrollo Practico

29. Conclusiones
 SDN no está sujeta a las RFCs y firmware propietario de los fabricantes de
equipos y esto es beneficioso en términos de optimización de la red.
 En este trabajo monográfico hemos comentado el caso de varios
controladores open-source, desarrollados expresamente para la comunidad
científica como: POX, Ryu, FloodLight, Pyretic, OpenDaylight entre otros.
 Este modelo no va a sustituir a las redes tradicionales, más bien convivirá con
ellas en un futuro no muy lejano. A medida que los trabajos de
estandarización avancen y se profundice en las investigaciones sobre temas
pendientes (seguridad, resiliencia, rendimiento del controlador, etc.)
 Desarrollo de herramientas de estudio de SDN como Mininet, desarrollado
por la universidad de Stanford, el cual proporciona una potente herramienta
de simulación de redes SDN.

30. Recomendaciones
1. Actualizar este documento con las tendencias de Redes Definidas por
Software que van apareciendo en el mercado.
2. Realizar un estudio más a fondo sobre el proyecto OpenDaylight el cual
pretende convertirse en una plataforma abierta que utilicen todas las
empresas, evitando que lo sistemas propietarios limiten el crecimiento del
mercado y al mismo tiempo se reduzcan los costes de desarrollo.
3. Hacer pruebas con equipos reales de hardware que soporten SDN, para
desarrollar pequeñas prácticas de laboratorio.
4. Fomentar la investigación de las nuevas tecnologías de Redes emergentes
relacionadas a SDN, proponiendo utilizar este documento como base para
impartir una electiva con tendencia a obtener nuevos conocimientos acerca
de este nuevo paradigma.