EMULACIÓN DEL PROCESO DE CONMUTACIÓN/APILAMIENTO DE ETIQUETAS EN REDES MPLS, MEDIANTE UNA HERRAMIENTA DE

SIMULACIÓN PARA REDES DEFINIDAS POR SOFTWARE.

YURY LORENA MONTOYA ÁLZATE & JHON MAURICIO AVENDAÑO OCAMPO

UNIVERSIDAD CATÓLICA DE PEREIRA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA

INGENIERIA DE SISTEMAS Y TELECOMUNICACIONES PEREIRA

2016

2

EMULACIÓN DEL PROCESO DE CONMUTACIÓN/APILAMIENTO DE ETIQUETAS EN REDES MPLS, MEDIANTE UNA HERRAMIENTA DE

SIMULACIÓN PARA REDES DEFINIDAS POR SOFTWARE.

YURY LORENA MONTOYA ÁLZATE & JHON MAURICIO AVENDAÑO OCAMPO

TRABAJO DE GRADO

DIRECTORA PROYECTO LINE YASMÍN BECERRA

INGENIERA ELECTRONICA

UNIVERSIDAD CATÓLICA DE PEREIRA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA

INGENIERIA DE SISTEMAS Y TELECOMUNICACIONES PEREIRA

2016

3

TABLA DE CONTENIDO

Pág.

TABLA DE CONTENIDO __________________________________________________________________________ 3

LISTA DE TABLAS ________________________________________________________________________________ 6

LISTA DE FIGURAS _______________________________________________________________________________ 7

LISTA DE ANEXOS ________________________________________________________________________________ 9

LISTA DE ACRONIMOS _________________________________________________________________________ 10

RESUMEN ________________________________________________________________________________________ 11

ABSTRACT _______________________________________________________________________________________ 12

INTRODUCCIÓN ________________________________________________________________________________ 13

1 OBJETIVOS _________________________________________________________________________________ 15

1.1 OBJETIVO GENERAL ___________________________________________________________________ 15

1.2 OBJETIVOS ESPECÍFICOS ______________________________________________________________ 15

2 MARCO TEORICO _________________________________________________________________________ 16

2.1 IMPORTANCIA DE UN NUEVO PARADIGMA DE RED ______________________________ 16

2.2 REDES DEFINIDAS POR SOFTWARE SDN ___________________________________________ 17 2.2.1 Beneficios de SDN ______________________________________________________________________________ 19

2.3 CONTROLADORES PARA SDN ________________________________________________________ 20

2.4 CARACTERÍSTICAS DE ALGUNOS CONTROLADORES _____________________________ 21 2.4.1 Controlador Beacon ____________________________________________________________________________ 22 2.4.2 Controlador Floodlight _________________________________________________________________________ 23 2.4.3 Controlador NOX _______________________________________________________________________________ 26 2.4.4 Controlador POX________________________________________________________________________________ 26 2.4.5 Controlador TREMA ____________________________________________________________________________ 27 2.4.6 Controlador RYU _______________________________________________________________________________ 27 2.4.7 Controlador Opendaylight _____________________________________________________________________ 28

2.5 ELEMENTOS A TENER EN CUENTA PARA LA SELECCIÓN DE CONTROLADORES SDN 29

2.6 INTRODUCCIÓN A MPLS REAL _______________________________________________________ 31 2.6.1 Descripción cabecera MPLS ___________________________________________________________________ 32 2.6.2 Arquitectura MPLS _____________________________________________________________________________ 33

2.6.2.1 Router conmutador de etiquetas (LRS: Label Switch Router) ________________________ 33 2.6.2.2 Router de frontera de etiquetas (LER: Label Egde Router) ___________________________ 34 2.6.2.3 Clase equivalente de envió (FEC: Forwarding Equivalence Class) ___________________ 34 2.6.2.4 NHLFE (Next Hop Label Forwarding Entry) ___________________________________________ 34

4

2.6.3 Protocolos utilizados en MPLS ________________________________________________________________ 35 2.6.3.1 Protocolo LDP ____________________________________________________________________________ 35 2.6.3.2 RSVP-TE __________________________________________________________________________________ 35

2.6.4 Componente de envío de etiquetas ___________________________________________________________ 36 2.6.5 Etiquetas ________________________________________________________________________________________ 39 2.6.6 Apilado de etiquetas ___________________________________________________________________________ 40

2.7 Aplicaciones de MPLS _________________________________________________________________ 43 2.7.1 Ingeniería de tráfico en MPLS _________________________________________________________________ 44 2.7.2 Implementación de QoS en MPLS _____________________________________________________________ 45

3 EMULACIÓN DE MPLS MEDIANTE UN EMULADOR DE REDES DEFINIDAS POR SOFTWARE ______________________________________________________________________________________ 47

3.1 HERRAMIENTAS DE SIMULACIÓN Y EMULACIÓN DE REDES DEFINIDAS POR SOFTWARE _______________________________________________________________________________________ 47

3.1.1 Simulación ______________________________________________________________________________________ 47 3.1.2 Emulación _______________________________________________________________________________________ 48 3.1.3 NCTUns (EstiNet)_______________________________________________________________________________ 49 3.1.4 DieCast __________________________________________________________________________________________ 50 3.1.5 ModelNet ________________________________________________________________________________________ 50 3.1.6 Mininet __________________________________________________________________________________________ 50

3.2 HERRAMIENTA DE EMULACIÓN SELECCIONADA PARA EL DESARROLLO DEL PROYECTO _______________________________________________________________________________________ 51

3.3 CONTROLADOR SELECCIONADO PARA EL DESARROLLO DEL PROYECTO ____ 52 3.3.1 Floodlight _______________________________________________________________________________________ 53

3.4 VENTAJAS DEL PROCESO DE CONMUTACIÓN Y APILAMIENTO DE ETIQUETAS DE MPLS __________________________________________________________________________________________ 55

3.5 ANTECEDENTES DE EMULACIÓN Y/O SIMULACIÓN DE MPLS CON REDES DEFINIDAS POR SOFTWARE __________________________________________________________________ 56

3.6 DESARROLLO DE LA EMULACION DE MPLS MEDIANTE UN EMULADOR DE REDES DEFINIDAS POR SOFTWARE __________________________________________________________ 59

3.6.1 Arquitectura de la topología de prueba 1 sin MPLS _________________________________________ 59 3.6.2 Topología de la emulación prueba 1 diseñada en Python ___________________________________ 60 3.6.3 Pruebas de conectividad con los host y Switch ______________________________________________ 62

3.7 FUNCIONAMIENTO DE MPLS EN TOPOLOGÍA DE PRUEBA 1 _____________________ 65 3.7.1 Importancia del controlador Floodlight para la topología de prueba 1 ____________________ 66

3.7.1.1 Activación del controlador Floodlight en Mininet _____________________________________ 67 3.7.2 Importancia de OpenFlow 1.3 para la topología de prueba 1 _______________________________ 69 3.7.3 Topología de prueba 1 con MPLS diseñada en Python ______________________________________ 70 3.7.4 Asignación manual de flujo y etiquetado MPLS ______________________________________________ 73

3.7.4.1 Captura de tráfico en Wireshark topología de prueba 1 ______________________________ 78 3.7.4.2 Verificación del flujo de datos con Floodlight __________________________________________ 79 3.7.4.3 Verificación de MPLS en Floodlight web _______________________________________________ 81

3.8 ARQUITECTURA DE LA TOPOLOGIA DE PRUEBA 2 SIN MPLS ___________________ 83 3.8.1 Topología de la emulación prueba 2 diseñada en Python ___________________________________ 83

5

3.8.2 Pruebas de conectividad topología de red 2 _________________________________________________ 86

3.9 ARQUITECTURA DE LA TOPOLOGIA DE PRUEBA 2 CON MPLS __________________ 87 3.9.1 Topología de red prueba 2 diseñada en Python ______________________________________________ 88 3.9.2 Funcionamiento de MPLS en topología de prueba 2 _________________________________________ 92

3.9.2.1 Asignación manual de flujo y etiquetado MPLS en la topología de prueba 2 ________ 93 3.9.2.2 Captura de tráfico en Wireshark topología de prueba 2 ______________________________ 98 3.9.2.3 Verificación del flujo de datos con Floodlight ________________________________________ 100 3.9.2.4 Verificación de MPLS en Floodlight web _____________________________________________ 102

3.10 ANALISIS DE RESULTADOS __________________________________________________________ 104

4 CONCLUSIONES __________________________________________________________________________ 107

ANEXOS _________________________________________________________________________________________ 109

BIBLIOGRAFIA _________________________________________________________________________________ 112

6

LISTA DE TABLAS

Tabla 1. Características de algunos Controladores ___________________________________________________________ 21 Tabla 2. Asignación de etiquetas en los switches. _____________________________________________________________ 77 Tabla 3. Asignación de etiquetas en los switches en la topología de prueba 2. ______________________________ 97

7

LISTA DE FIGURAS

FIGURA 1. SDN Red Definida por Software: ____________________________________________________________________ 18 FIGURA 2. The Beacon OpenFlow Controller, __________________________________________________________________ 23 FIGURA 3. Project Floodlight Controller, _______________________________________________________________________ 25 FIGURA 4. Capa 2.5 Modelo OSI, exposición arquitectura MPLS, _____________________________________________ 31 FIGURA 5. Estudio y diseño de redes virtuales privadas (VPN) basadas en tecnología MPLS, ______________ 32 FIGURA 6. MPLS Multi Protocol Label Switching, _____________________________________________________________ 33 FIGURA 7. MPLS: Next Steps, The Morgan Kaufmann Series in Networking, ________________________________ 37 FIGURA 8. MPLS Multi Protocol Label Switching, _____________________________________________________________ 39 FIGURA 9. Análisis de la red de la cnt ep para la implementación de servicios integrados mediante tecnología MPLS, ________________________________________________________________________________________________ 41 FIGURA 10. MPLS: Next Steps, The Morgan Kaufmann Series in Networking, _______________________________ 42 FIGURA 11. MPLS: Next Steps, The Morgan Kaufmann Series in Networking, 2008, Proceso de apilamiento de etiquetas en redes MPLS, ____________________________________________________________________________________ 43 FIGURA 12. Mininet Testing Platform Controller, _____________________________________________________________ 52 FIGURA 13. Pipeline del thread IOFMessageListener de Beacon, _____________________________________________ 53 FIGURA 14. API de Floodlight, The controller, _________________________________________________________________ 54 FIGURA 15. Topología de red prueba 1, ________________________________________________________________________ 59 FIGURA 16-A, Código Python Topología de red prueba 1._____________________________________________________ 60 FIGURA 17-B, Código Python Topología de red prueba 1._____________________________________________________ 61 FIGURA 18. Llamado en Mininet del código Python. __________________________________________________________ 62 FIGURA 19. Verificación de conectividad de red _______________________________________________________________ 63 FIGURA 20. Verificación de conectividad entre h1 y h4. _______________________________________________________ 63 FIGURA 21. Verificación de los nodos de la red. _______________________________________________________________ 64 FIGURA 22. Enlaces que tiene la red topología de red 1. ______________________________________________________ 64 FIGURA 23. Verificar la información de los nodos de la red 1. ________________________________________________ 65 FIGURA 24. Topología de prueba 1 configurada con Floodlight y OpenFlow 1.3. ____________________________ 66 FIGURA 25. Floodlight en modo escucha puerto 6653. ________________________________________________________ 67 FIGURA 26. Mensajes generados por Floodlight. ______________________________________________________________ 68 FIGURA 27. Captura con Wireshark del protocolo OpenFlow 1.3. ____________________________________________ 70 FIGURA 28. Código Python de la topología de red prueba 1 para utilizar MPLS. ____________________________ 71 FIGURA 29. Llamado en Mininet del código Python de la topología de prueba 1 MPLS. ____________________ 72 FIGURA 30. Asignación manual de Flujo MPLS en los Switches. ______________________________________________ 73 FIGURA 31. Resultados de ovs-vsctl show. _____________________________________________________________________ 75 FIGURA 32. Envío de paquetes por la red MPLS h1 – h3. ______________________________________________________ 76 FIGURA 33. Envío de paquetes por la red MPLS h2 – h4. ______________________________________________________ 77 FIGURA 34. Captura de tráfico con protocolo MPLS y Wireshark host 1 – host 3. ___________________________ 78 FIGURA 35. Captura de trafico Wireshark entre host 3 – host 1. _____________________________________________ 79 FIGURA 36. Topología actual de red vista desde Floodlight Web. ____________________________________________ 80 FIGURA 37. Floodlight web versión de OpenFlow 1.3 utilizada en Switch 1. _________________________________ 80 FIGURA 38. Página principal de Floodlight. ___________________________________________________________________ 81 FIGURA 39. Verificación de Floodlight web en la asignación de etiqueta MPLS Switch 1. ___________________ 82 FIGURA 40. Verificación de Floodlight web en la asignación de etiqueta MPLS Switch 2. ___________________ 82 FIGURA 41. Topología de red prueba 2. ________________________________________________________________________ 83 FIGURA 42-A. Topología en Python prueba 2 sin MPLS. ______________________________________________________ 84 FIGURA 43-B. Topología en Python prueba 2 sin MPLS. ______________________________________________________ 84 FIGURA 44-C. Topología en Python prueba 2 sin MPLS. _______________________________________________________ 85

8

FIGURA 45. Llamado en Mininet del código Python topología de prueba 2. _________________________________ 85 FIGURA 46. Verificación de conectividad de red con el comando pingall. ____________________________________ 86 FIGURA 47. Verificación de conectividad entre h1 y h27. _____________________________________________________ 87 FIGURA 48. Topología de red prueba 2 con MPLS. ____________________________________________________________ 88 FIGURA 49-A. Topología en Python prueba 2 con MPLS. ______________________________________________________ 89 FIGURA 50-B, Topología en Python prueba 2 con MPLS. ______________________________________________________ 89 FIGURA 51-C. Topología en Python prueba 2 con MPLS. ______________________________________________________ 90 FIGURA 52. Llamado de la topología personalizada de prueba 2 y pingall de conectividad. ________________ 91 FIGURA 53. Activación controlador Floodlight en Mininet. ___________________________________________________ 92 FIGURA 54-A. Mensajes generados por Floodlight. ____________________________________________________________ 92 FIGURA 55-B. Mensajes generados por Floodlight. ____________________________________________________________ 93 FIGURA 56-A. Asignación manual de Flujo MPLS en los switches. ____________________________________________ 94 FIGURA 57-B. Asignación manual de Flujo MPLS en los switches de red 2. __________________________________ 95 FIGURA 58. Envío de paquetes por la red MPLS h1 – h24 cambio de MPLS. _________________________________ 96 FIGURA 59. Envío de paquetes por la red MPLS h4 – h27 cambio de etiquetas MPLS. ______________________ 97 FIGURA 60. Captura de trafico Wireshark entre host 27 – host 4, primer salto en Switch 30. ______________ 98 FIGURA 61. Captura de trafico Wireshark entre host 27 – host 4, segundo salto en Switch 20. _____________ 99 FIGURA 62. Captura de trafico Wireshark entre host 4 – host 27, Respuesta host 4 en Switch 10. _________ 99 FIGURA 63. Captura de trafico Wireshark entre host 4 – host 27 respuesta host 4 en Switch 20. ________ 100 FIGURA 64. Topología de prueba 2 vista desde Floodlight Web. ____________________________________________ 101 FIGURA 65. Floodlight web versión de OpenFlow 1.3 utilizada en Switch 30.______________________________ 101 FIGURA 66. Página principal de Floodlight topología de prueba 2. ________________________________________ 102 FIGURA 67. Flujo del Switch 10 etiquetado MPLS. ___________________________________________________________ 103 FIGURA 68. Flujo del Switch 30 etiquetado MPLS respuesta del host 27 al host 4. ________________________ 103

9

LISTA DE ANEXOS

A. Instalación MiniNet con OpenFlow 1.3 _________________________________________________________________ 109 B. Instalación de Floodlight 1.0 ____________________________________________________________________________ 111

10

LISTA DE ACRONIMOS

SDN: (Software Defined Network o red definida por software)

MPLS: (Multiprotocol Label Switching) LSR: (Label Switching Router) LER: (Label Edge Router) LSP: (Label Switched Path) o Intercambio de rutas por etiqueta LDP: (Label Distribution Protocol) FEC: (Forwarding Equivalence Class) FEC: (Forwarding Equivalence Class) RSVP: (Resource Reservation Protocol) API: (Interfaz de programación de aplicación) LLDP: (Protocolo de descubrimiento de capa de enlace)

11

RESUMEN

Las Redes Definidas por Software (SDN) son catalogadas hoy en día como el nuevo paradigma de red que trae consigo como objetivo el facilitar la creación y gestión de redes de datos. El desacople entre el Plano de control y el plano de datos planteado por esta arquitectura permite el control de todo el comportamiento y seguimiento de la red a través de un módulo lógico centralizado, llamado controlador. El estándar MPLS fue desarrollado para suplir la problemática que afrontan los carriers, ya que este protocolo provee ventajas en el enrutamiento de paquetes por ser un protocolo que trabaja en capa 2.5 y permite que el enrutamiento de paquetes se realice mediante el intercambio de etiquetas lo que confiere velocidad en la conmutación de paquetes a diferencia de las redes convencionales. El estándar MPLS soporta tanto la creación y administración de rutas estáticas como dinámicas. Incluye los mecanismos del plano de control dinámico en el conjunto de protocolos MPLS. Actualmente es muy utilizado debido a sus ventajas tanto en la conmutación de paquetes como para el soporte de ingeniería de tráfico ya que minimiza el consumo del ancho de banda y a su vez minimiza los costos en el tráfico, MPLS también incrementa la fiabilidad en la red ya que facilita una calidad de servicio (QoS) avanzada. En este documento se presenta el procedimiento para emular MPLS en una red definida por software mediante la herramienta Mininet. En primera instancia se describe el funcionamiento de cada una de las tecnologías presentes y herramientas necesarias para realizar dicha emulación tales como MPLS, SDNs, herramientas de simulación y emulación de SDNs, controladores etc. Finalmente se describe el proceso de emulación MPLS-SDN mediante dos topologías sencillas, usando el protocolo OpenFlow 1.3 y el controlador Floodlight, indicando la forma como se configura el etiquetamiento en MPLS y como se activa el controlador y los diferentes protocolos. La información suministrada tanto teoría como los resultados del proceso es un aporte valioso para futuras investigaciones. Descriptores Controladores, Floodlight, Mininet, MPLS, ONF, OpenFlow, Redes SDN.

12

ABSTRACT

The networks defined by Software (SDN) are today listed as the new paradigm of network that brings as a aims to facilitate the creation and management of data networks. The disconnect between the control plane and data plane raised by this architecture allows control of all the behavior and monitoring of the network through a centralized logical module, called controller. The MPLS standard was developed to compensate for the problems faced by carriers, since this Protocol provides advantages in the routing of packets to be a protocol that works on layer 2.5 and enables packet routing is performed through the exchange of labels giving speed in switching of packets as opposed to conventional networks. The MPLS standard supports both the creation and administration of static routes as dynamic. Includes mechanisms for dynamic control plane the MPLS protocol suite. Currently it is widely used because of its advantages both in packet switching and traffic engineering support since it minimizes bandwidth consumption and in turn minimizes the traffic cost, MPLS also increases reliability on the network since it facilitates an advanced quality of service (QoS). This document presents the procedure to emulate MPLS network software using the Mininet tool defined. In the first instance describes the behavior of each of these technologies and tools needed to perform this emulation such as MPLS, SDNs, simulation tools and emulation of SDNs, controller etc. Finally describes the process of emulation MPLS-SDN through two simple topologies, using OpenFlow 1.3 Protocol and controller Floodlight, indicating the form set up in MPLS labeling and turn on the controller and the different protocols. The information provided both theory as the results of the process is a valuable input for future research. Descriptores Controllers, Floodlight, Mininet, MPLS, ONF, OpenFlow, Network SDN.

13

INTRODUCCIÓN

Durante muchos años se viene generando un crecimiento fuerte y sostenido de las redes de telecomunicaciones, resultado de una demanda cada vez mayor por parte de los usuarios. Este crecimiento, desordenado por basarse en principios y modelos no escalables, demostró que las infraestructuras y arquitecturas tradicionales presentan serias limitaciones de adaptación, flexibilidad y crecimiento, generando un “cuello de botella” en el despliegue y evolución de los negocios. Es necesario realizar un cambio de enfoque sobre las arquitecturas de redes, para poder incrementar la productividad, y lograr que acompañen la capacidad de innovación de las organizaciones. El problema radica en el esquema de control tradicional, el cual se basa en un enfoque no centralizado. La administración de los diferentes equipos por separado, teniendo únicamente un plano de control distribuido, no provee la flexibilidad, escalabilidad, y dinámica que las redes actuales requieren. Estas topologías tradicionales han llegado a ser extremadamente complejas y difíciles de abarcar. Se continúan diseñando distintos protocolos y procesos acorde al enfoque distribuido del esquema de control tradicional, que lleva a que en vez de poder usar simples abstracciones para explicar y modificar el funcionamiento de una red, se deba enfocar el estudio y análisis en el aprendizaje de diversos protocolos, por lo general aplicaciones prácticas y guías de diseño, y no principios abstractos y fundamentales. Esto implica que cada vez que se quiere desplegar una nueva funcionalidad, se debe lidiar con estandarizaciones de métodos de aplicación distribuidos. Se plantea un nuevo paradigma, basado en principios abstractos y fundamentales. El estudio y análisis de los métodos de aplicación de los diversos protocolos se realiza una única vez, creando abstracciones y utilizándolas para explicar y modificar el funcionamiento de una red. De esta forma, la red se pone al servicio de los operadores y programadores, y las diferentes funcionalidades se programan, configuran y operan a un nivel de control centralizado, sin tener que lidiar con la distribución de la inteligencia. Se proponen nuevas arquitecturas de red que sean flexibles, escalables, programables y capaces de soportar múltiples servicios; que logren optimizar la forma en la que operamos, comprendemos, diseñamos e interactuamos con las redes. Junto a ello, se busca acompañar el creciente despliegue de servicios de tipo “cloud computing” y la virtualización de las funciones de red. Es entonces SDN un enfoque de arquitectura de red que brinda la habilidad de programar directamente operaciones de red, usando lenguajes y sistemas

14

operativos estándar. SDN permite realizar una transición, desde modelos de redes tradicionales (estáticas, inflexibles, con poca agilidad y que no acompañan a las nuevas iniciativas de los negocios) hacia redes programables, que brindan flexibilidad, agilidad, optimización y virtualización. La funcionalidad SDN les permite a los operadores de red utilizar conceptos de programación para implementar técnicas de administración y orquestación automáticas, aplicar diversas configuraciones en múltiples equipos, y desacoplar las aplicaciones que realizan estas operaciones de los sistemas operativos de los dispositivos de red. SDN permite a las aplicaciones interactuar dinámicamente con los diferentes procesos de la red, usando estadísticas y diferentes parámetros recibidos de la misma, junto con requerimientos específicos, para desplegar de forma dinámica nuevos esquemas y configuraciones. El esfuerzo para optimizar las redes y servicios, ha obligado a las empresas a añadir mecanismos capaces de transformar las redes de acceso en arquitecturas de red orientadas a servicios. Como resultado, nace la tecnología Multiprotocol Label Switching (MPLS), tecnología que consigue de modo eficaz unificar los diferentes tipos de tráfico de una red utilizando para ello la conmutación de etiquetas. Este mecanismo optimiza el tradicional proceso de encaminamiento de paquetes por IP. La pretensión de este proyecto apunta a validar el proceso de etiquetado en una red SDN. En primera instancia se describe el funcionamiento de cada una de las tecnologías presentes y herramientas necesarias para realizar dicha emulación tales como MPLS, SDNs, herramientas de simulación y emulación de SDNs, controladores etc. Finalmente se describe el proceso de emulación MPLS-SDN mediante dos topologías sencillas, en las cuales se activa el protocolo OpenFlow 1.3 y el controlador Floodlight, indicando la forma como se configura el etiquetamiento en MPLS y como se activa el controlador y los diferentes protocolos. El documento se encuentra estructurado de la siguiente manera: en el capítulo 1 se dan los objetivos del proyecto, en el capítulo 2 encontramos el marco teórico, en el capítulo 3 vemos la emulación de MPLS mediante un emulador de redes definidas por software, por último en el capítulo 4 nos encontramos con las conclusiones del proyecto.

15

1 OBJETIVOS

1.1 OBJETIVO GENERAL Realizar la emulación del protocolo MPLS y su proceso de conmutación/apilamiento de etiquetas en una red definida por software, con el fin de evaluar las ventajas del proceso, en cuanto al funcionamiento SDN-MPLS y el beneficio que confiere en el enrutamiento de paquetes. 1.2 OBJETIVOS ESPECÍFICOS

Explorar e indagar sobre las diferentes herramientas de simulación y emulación para redes definidas por software, seleccionar la apropiada para el desarrollo de este proyecto y estudiar su funcionamiento.

Determinar teóricamente las ventajas del proceso de conmutación y apilamiento de etiquetas en redes MPLS mediante una exploración del estado del arte de dicho proceso y estudio del funcionamiento del protocolo MPLS.

Seleccionar una arquitectura de red MPLS sencilla, de tal manera que se pueda emular la red sin el proceso de conmutación/apilamiento y con el proceso de conmutación/apilamiento con el fin de comparar los resultados.

Diseñar, configurar y ejecutar la emulación de la red MPLS con y sin el proceso de conmutación/apilamiento de etiquetas.

Generar conclusiones con respecto a las ventajas de usar el proceso de conmutación/apilamiento de etiquetas.

Documentar todo el proceso y desarrollo del trabajo de grado.

16

2 MARCO TEORICO

Las arquitecturas de red existentes no han sido diseñadas para satisfacer las necesidades de los usuarios, las empresas y los operadores de hoy en día. Los diseñadores de redes se encuentran restringidos por las limitaciones de las redes actuales, como las que se describen a continuación: (Open Networking Foundation,

2012)

Políticas inconsistentes: Implementar una política para toda la red supone tener que configurar miles de dispositivos y mecanismos.

Incapacidad para escalar: Al igual que la demanda en los centros de datos crece rápidamente, también debe crecer la red. Sin embargo, se vuelve mucho más compleja con la incorporación de n dispositivos que deben ser configurados y gestionados.

Dependencia de proveedores: Los operadores tratan de desplegar nuevos servicios de respuesta rápida a las necesidades cambiantes del negocio. Sin embargo, su capacidad de respuesta se ve obstaculizada por los ciclos de los vendedores de productos. La falta de interfaces estándar y libres limita la capacidad de los operadores para adaptar la red a sus entornos individuales. En respuesta a esto, la industria ha creado el Software-Defined Networking (SDN), la arquitectura y el desarrollo de normas asociadas.

2.1 IMPORTANCIA DE UN NUEVO PARADIGMA DE RED El estándar MPLS fue desarrollado para suplir la problemática que afrontan los carriers, ya que el tráfico en sus redes de transporte se ha desplazado rápidamente del tráfico TDM de conmutación de circuitos a paquetes de datos IP. Ahora, ellos tienen que soportar la conmutación de paquetes sin dejar de llevar tráfico legado con la alta fiabilidad de sus redes actuales. El estándar MPLS soporta tanto la creación y administración de rutas estáticas como dinámicas. Incluye los mecanismos del plano de control dinámico en el conjunto de protocolos MPLS. Un plano de control dinámico ofrece ventajas mediante la creación y modificación de rutas sin la necesidad de intervención del administrador.

17

Al usar SDN en un entorno MPLS se puede reducir la complejidad en el plano de control dinámico y permitir la creación de servicios flexibles. Un cambio a SDN eliminaría la necesidad de implementaciones de protocolos residentes en los switches. Un controlador OpenFlow, por ejemplo, podría emitir directrices para establecer las rutas de red. Las aplicaciones que sirven de interfaz al controlador implementarían las funciones que actualmente presta el código de protocolo residente en el router. Los routers ya no requieren tanta memoria o capacidad de cálculo, reduciendo así las necesidades de energía y actualizaciones frecuentes. (Jacobs, 2014) 2.2 REDES DEFINIDAS POR SOFTWARE SDN

El término SDN (Software Defined Network o red definida por software) se ha venido acuñando en los últimos dos años para hacer referencia a una arquitectura de red que permite separar el plano de control del plano de datos, para conseguir redes más programables, automatizables y flexibles.

El concepto en sí, sin embargo, no es tan reciente. La idea de una red que pueda programarse, y no simplemente configurarse, ha sido ya aplicada por numerosos fabricantes, pero con una gran limitación: hasta ahora, todas las iniciativas habían sido muy propietarias.

Aproximadamente en 2010, no obstante, se produjo “una respuesta masiva por parte de la industria para crear interfaces totalmente abiertas, entre ellas OpenFlow, que definan una manera única, abierta y común para todos los fabricantes a la hora de extender sus equipos y exponerlos a piezas de software que permitan programarlos”, explicó Xavi Homs, director de preventa de HP Networking.

Desde entonces, el término SDN ha llegado con la promesa de una revolución de la arquitectura de red en los centros de datos.

De SDN se ha hablado mucho, pero no existe una única definición. Es, ante todo, un concepto, que cobra sentido especialmente comparándolo con las redes tradicionales. En las redes actuales, la manera como se procesan los paquetes depende de una programación, mientras que en una SDN está condicionada por una interfaz de programación con un software que gobierna su comportamiento. La manera de procesar los paquetes no depende de una programación estática en unos ficheros de configuración en cada uno de los nodos, sino de los mensajes

18

que envía un software a cada elemento de la red de manera dinámica. (Dynamics,

2013)

La Figura 1 representa una vista lógica de la arquitectura SDN. La inteligencia de red es centralizada en el controlador SDN basado en software, que mantienen una visión global de la red. Como resultado, en la red aparecen las aplicaciones de negocio y servicios de red. Con SDN, las empresas y operadores diseñan el control independiente del proveedor sobre toda la red desde un único punto lógico, lo que simplifica en gran medida el diseño y funcionamiento de la red. SDN también simplifica en un alto porcentaje los dispositivos de la red, puesto que ya no necesitan entender y procesar miles de normas de protocolo, sino simplemente aceptar instrucciones de los controladores SDN. (Hervas, 2914)

FIGURA 1. SDN Red Definida por Software:

The New Norm for Networks, 2012, Software-Defined Network Architecture, pág. 7

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

sdn-newnorm.pdf

19

2.2.1 Beneficios de SDN Una vez que el control del software es separado del hardware y transformado en un entorno más abierto, los usuarios pueden obtener diversos beneficios incluyendo los siguientes: (Santamaría, 2012)

Visión unificada de la estructura de red: Con el SDN se tiene una visión unificada de la red, simplificando la configuración, gestión y aprovisionamiento.

Alta utilización: Una Ingeniería de tráfico centralizada proporciona una visión global, tanto en la oferta como en la demanda de recursos en la red. Gestionar a través de esta visión global el camino extremo a extremo que permita conseguir una alta utilización de los enlaces.

Manejo más rápido de fallos: Los fallos, ya sean en un enlace o nodo, se gestionan más rápido. Además, los sistemas convergen más rápidamente hacia el objetivo óptimo y el comportamiento es predecible.

Entorno de prueba de alta fidelidad: La red dorsal (backbone) es emulada completamente mediante software, esto no sólo ayuda en la comprobación y verificación, sino también en la gestión de posibles escenarios que se puedan dar.

Elasticidad en el cómputo: Calcular la capacidad de los dispositivos de red ya no es un factor limitador, al igual que el control y la gestión, reside en los servidores y controladores externos.

Actualizaciones sin impacto: El desacoplamiento del plano de control respecto al plano de datos, permite llevar a cabo actualizaciones de software sin pérdida de paquetes o degradación de la capacidad.

Otros beneficios que aparecen son:

Personalización de la red y sus servicios.

Operaciones mejoradas.

Incremento del rendimiento.

20

2.3 CONTROLADORES PARA SDN Un controlador SDN ofrece una interfaz de programación para los conmutadores OpenFlow de tal forma que, las aplicaciones de gestión, a través de la misma, pueden realizar tareas de gestión y ofrecer nuevas funcionalidades. Un controlador SDN puede ser descrito de forma general como un sistema de software, o colección de sistemas, que ofrecen: (revistatelematica, 2014)

Gestión del estado de la red, que implica una base de datos. Estas bases de datos sirven como un repositorio para la información de los elementos de red gestionados, incluyendo el estado de la red, alguna información de configuración temporal e información sobre la topología de la red.

Un modelo de datos de alto nivel que captura las relaciones entre los recursos gestionados, las políticas y otros servicios prestados por el controlador. En muchos casos estos modelos de datos se construyen utilizando el lenguaje de modelado Yang.

Un mecanismo de descubrimiento de dispositivos, topología y servicio; un sistema de cálculo de ruta y, potencialmente, otros servicios de información centrados en la red o en los recursos.

Una sesión de control segura sobre el Protocolo de Control de Trasmisión (Transmission Control Protocol: TCP por sus siglas en inglés) entre el controlador y los agentes asociados en los elementos de la red, por ejemplo con el uso del protocolo TLS (Seguridad en la Capa de Transporte o Transport Layer Security, por sus siglas en inglés).

Un protocolo basado en estándares (OpenFlow) para obtener el estado de la red impulsado por las aplicaciones de los elementos de red.

Un conjunto de APIs, a menudo RESTful (Transferencia de estado representacional o Representational State Transfer, por sus siglas en inglés) que exponen los servicios del controlador a las aplicaciones de gestión. Esto facilita la mayor parte de la interacción del controlador con estas aplicaciones. Esta interfaz se representa a partir del modelo de datos que describe los servicios y funciones del controlador. En algunos casos, el controlador y su API son parte de un entorno de desarrollo que genera el código de la API a partir del modelo de datos.

21

Algunos controladores ofrecen entornos de desarrollo robustos que permiten la expansión de las capacidades básicas del núcleo y la posterior publicación de las APIs para los nuevos módulos, incluyendo los que soportan la expansión dinámica de las capacidades del controlador

Por tanto, en las SDN, es el controlador central el que dicta el comportamiento general de la red a partir de los requerimientos de las aplicaciones. Ejemplos de algunos controladores de código abierto existentes son: Beacon, Floodlight, NOX, POX, Ryu, Trema y OpenDayLight (ODL). En la tabla 1 se muestran algunas características de estos controladores

Tabla 1. Características de algunos Controladores

Tomado de: (Alejandro Garcia Centeno, 2014) 2.4 CARACTERÍSTICAS DE ALGUNOS CONTROLADORES Aquí observaremos una brevemente descripción de los controladores más utilizados con la plataforma OpenFlow, esto nos ayudaran a seleccionar el mejor controlado para el proyecto planteado, a continuación se presentan las características de los controladores presentados en la tabla 1.

Beacon Floodlight NOX POX Trema Ryu ODL

Soporte OpenFlow

OF v1.0 OF v1.0, 1.3,

1.4, 1.5 OF v1.0

OF v1.0, 1.3, 1.4,

1.5 OF v1.3

OF v1.0, v1.2, v1.3, v1.4, 1.5 y

extensiones Nicira OF v1.0

Virtualización MiniNet y

Open vSwitch

MiniNet y Open

vSwitch

MiniNet y Open

vSwitch

MiniNet y Open

vSwitch

MiniNet y Open

vSwitch

Construcción de una herramienta

virtual de simulación

MiniNet y Open

vSwitch

lenguaje de Desarrollo

Java Java C++ Python Rudy/C Python Java

Provee REST API

NO SI NO NO Si

(Básica) Si (Básica) SI

Interfaz Grafica Web Web Python+,

QT4 Python+,

QT4 , WEB NO WEB WEB

Soporte de plataformas

Linux, Mac OS, Windows y Android para

móviles

Linux, Mac OS,

Windows Linux

Linux, Mac OS,

Windows Linux Linux

Linux, Mac OS,

Windows

Soporte de OpenStack

NO SI NO NO SI SI SI

Multiprocesos SI SI SI NO SI NO SI

Tiempo en el mercado

5 años 4 años 8 años 3 años 4 años 4 años 3 años

Documentación Buena Buena Media Pobre Pobre Media Media

22

2.4.1 Controlador Beacon Es un controlador OpenFlow de código abierto basado en Java creado en 2010. Se exploró nuevas áreas del espacio de diseño del controlador OpenFlow, con un enfoque en ser amistoso con el desarrollador, de alto rendimiento, y tener la capacidad para iniciar y detener existentes y nuevas aplicaciones en tiempo de ejecución. Beacon mostró sorprendentemente alto rendimiento, y fue capaz de escalar linealmente con núcleos de procesamiento, manejo de 12,8 millones de paquetes en mensajes por segundo con 12 núcleos, mientras que se construye utilizando Java. Beacon aprovecha múltiple librerías de las bibliotecas en la plataforma en un intento de maximizar la reutilización de código y para aliviar la carga de desarrollo tanto del controlador en sí mismo, y las aplicaciones de usarlo. La biblioteca más importante es la Spring, como se muestra en la Figura 2, proporciona un marco para el control de los dispositivos de red utilizando el protocolo OpenFlow, y un conjunto de aplicaciones integradas que proporcionan funcionalidad de plano de control comúnmente necesario. (Erickson, The Beacon

OpenFlow Controller, 2015)

Administrador De Dispositivos (Device Manager): Visualizar las señales de dispositivos en la red, tales como: direcciones (Ethernet e IP), últimos vistos en la red, el interruptor y el puerto. El administrador de dispositivos proporciona una interfaz (IDevice-Manager) para buscar los dispositivos conocidos, y la posibilidad de registrarse para recibir eventos como adición de nuevos dispositivos y actualización y eliminación de existentes.

Topología (Topology): Descubre enlaces entre switches OpenFlow conectados. Su interfaz (ITopology) permite la recuperación de una lista de dichos enlaces, y el registro de eventos para ser notificado cuando se agregan o enlaces que se habían quitado.

Routing (Routing): Provee una capa más corta en el trayecto de enrutamiento entre dos dispositivos en la red. Esta aplicación exporta la interfaz de motor de enrutamiento, permitiendo implementaciones del motor de enrutamiento intercambiables. La aplicación utiliza la ruta más corta como método de cálculo. El enrutamiento depende tanto de Topología y el Administrador de dispositivos.

Web. Proporciona una interfaz de usuario Web de Beacon. La aplicación web proporciona la interfaz IWebManageable, permitiendo a los ejecutores de la interfaz poder añadir sus propios elementos de la IU.

23

Ap

licacio

nes

To

po

log

ía

Ad

min

istr

ad

or

de

dis

positiv

os

Enru

tam

iento

FIGURA 2. The Beacon OpenFlow Controller,

2015, Descripción general de Beacon, pág. 1,

http://yuba.stanford.edu/~derickso/docs/hotsdn15 -erickson.pdf

2.4.2 Controlador Floodlight El controlador Floodlight es un controlador OpenFlow de clase empresarial, con licencia de Apache, basada en Java. Es apoyado por una comunidad de desarrolladores que incluyen una serie de ingenieros de redes de conmutación grandes, como se muestra en la Figura 3 este trabaja entre el plano de datos y el plano de control. (sponsored community project, 2015) OpenFlow es un estándar abierto gestionada por la Fundación Open Networking (ONF). Se especifica un protocolo a través del interruptor de un controlador remoto puede modificar el comportamiento de los dispositivos de red a través de un "conjunto de instrucciones de reenvío" bien definido. Floodlight está diseñado para trabajar con el creciente número de switches, routers, switches virtuales, y los puntos de acceso compatibles con el estándar OpenFlow, a partir de Floodlight v1.0, Floodlight tiene soporte completo para todas las características OpenFlow 1.3. También es compatible con versiones anteriores de OpenFlow 1.0 (con soporte experimental para OpenFlow 1.1 y 1.2). Expone todas las versiones OpenFlow a través de una API común generado por el proyecto Loxigen llamado OpenFlowJ-Loxi. (sponsored community project, 2015)

24

Ventajas, ¿porque trabajar con este controlador?

OpenFlow - funciona con interruptores físico y virtualización que hablan con el protocolo OpenFlow.

Licencia Apache - permite utilizar Floodlight para casi cualquier propósito de arquitectura.

Comunidad Abierta - Floodlight es desarrollado por una comunidad abierta de desarrolladores. Todas las contribuciones de código de participantes activos son compartidas abiertamente sobre el estado del proyecto, plan de trabajo, bugs, etc.

Fácil de usar- Floodlight es de código simple de construir y correr.

Ofrece un sistema de módulo de carga que hace que sea fácil de extender y mejorar

Probado y compatible - Floodlight es el núcleo de un controlador de producto comercial de grandes Redes y está probado y mejorado de forma activa por una comunidad de desarrolladores profesionales.

Fácil de configurar con dependencias mínimas.

Soporta una amplia gama de switches OpenFlow virtualización y físico.

Diseñado para ser de alto rendimiento - es el núcleo de un producto comercial de grandes Redes.

Soporte para la plataforma OpenStack nube.

25

Aplicación de Nivel

Mas Aplicaciones Floodlight

API Dirección Norte

Nivel de plano de control

Controlador OpenFlow

Interfaz de plano de datos Indigo

Nivel de plano de Datos

FIGURA 3. Project Floodlight Controller,

2015, Descripción general de Floodlight, pág. 1, http://www.projectfloodlight.org/floodlight/

26

2.4.3 Controlador NOX Es una pieza del ecosistema de las redes definidas por software. En concreto, se trata de una plataforma para la creación de aplicaciones de control de red. De hecho, mientras que lo que ahora llamamos SDN creció de una serie de proyectos académicos (quizás principalmente SANE and Ethane), la primera tecnología SDN para obtener el reconocimiento el verdadero nombre era OpenFlow y NOX fue desarrollado inicialmente en Nicira Redes de lado a lado con OpenFlow - NOX fue el primer controlador OpenFlow. Nicira donó NOX a la comunidad de investigadores en 2008, y desde entonces, ha sido la base de muchos y diversos proyectos de investigación en la exploración temprana del espacio SDN. (NOX, 2014) Ventajas que NOX proporciona:

Proporciona un API 1.0 C ++ OpenFlow

Proporciona rápido, asíncrono IO

Está dirigido a las distribuciones recientes de Linux

Incluye componentes de ejemplo para:

o Descubrimiento de topología

o Interruptor de aprendizaje

o Interruptor de toda la red 2.4.4 Controlador POX Es ideal para comenzar en SDN usando Python en Windows, Mac OS o Linux, desde el mismo instante que se instala este controlando con OpenFlow en sólo unos segundos después puede utilizar la potencia de este controlador. Está dirigido principalmente a la investigación y la educación, y es usado para el trabajo en curso sobre la definición de las abstracciones y técnicas clave para el diseño del controlador. (POX, 2014)

27

POX es el hermano menor de NOX. En su esencia, es una plataforma para el rápido desarrollo y creación de prototipos de software de control de red utilizando Python. Es decir, en un nivel muy básico, que es uno de un número creciente de framework, para ayudar a escribir un controlador OpenFlow. POX también va más allá de esto. Además de ser un framework para interactuar con switches OpenFlow, se está usando como base para algunos trabajos en curso para ayudar a construir la disciplina emergente de Software Defined Networking. Se está usando para explorar y distribuir prototipos, SDN depuración, virtualización de redes, diseño del controlador, y modelos de programación. Soporta los mismos GUI y herramientas de visualización como NOX. (POX, 2014) 2.4.5 Controlador TREMA Es un framework para programar un controlador SDN, a gusto del programador, en los lenguajes Ruby y C. Este entorno de programación genera un fichero de configuración que después puede ser ejecutado por Trema para comportarse como un controlador SDN. (Community Trema, 2015) 2.4.6 Controlador RYU Es un componente para las redes definidas por software un framework. Ryu ofrece componentes de software con API bien definidas que hacen que sea fácil para los desarrolladores crear nuevas aplicaciones de gestión y control de la red. Ryu es compatible con varios protocolos para la gestión de dispositivos de red, tales como OpenFlow, Netconf, DE-config, etc. Ryu es totalmente compatible con v1.0, 1.2, 1.3, 1.4 y Nicira Extensiones. Todo el código está disponible gratuitamente bajo la licencia Apache 2.0. (Ryu SDN Framework Community, 2014) Ryu tiene una impresionante colección de librerías, que van desde el apoyo a múltiples protocolos southbound y las operaciones de procesamiento de paquetes diferentes de red. Con respecto a los protocolos southbound, Ryu soporta DE-CONFIG (Gestión OpenFlow y Configuration Protocol), OVSDB (Protocolo de gestión de base de datos Openvswitch), NETCONF, X FLOW (NetFlow y sFlow) y otros protocolos de terceros. NetFlow es apoyado por Cisco y otros, y es específico para una IP. Los protocolos de muestreo de paquetes de soporte y agregación NetFlow y sFlow, que se utilizan principalmente para la medición del tráfico de red. (Ryu SDN Framework Community, 2014)

28

Las bibliotecas de terceros son vinculantes abrir vSwitch Python, la biblioteca de configuración de Oslo y una biblioteca de Python para el cliente NETCONF. La biblioteca de paquetes Ryu ayudan a analizar y construir varios paquetes de protocolo, como VLAN, MPLS, GRE, etc. (Ryu SDN Framework Community, 2014)

2.4.7 Controlador Opendaylight Es una plataforma abierta para la programación de redes para permitir la SDN y NFV para redes en cualquier tamaño y escala. El segundo lanzamiento de la comunidad " Helium" viene con una nueva interfaz de usuario y un proceso de instalación mucho más simple y personalizable gracias a la utilización del contenedor Apache Karaf. (OpenDaylight, a Linux Foundation Collaborative Project,

2015) OpenDaylight es la combinación de componentes de software que incluye un controlador totalmente conectable, las interfaces, protocolos de plug-ins y aplicaciones. Con esta plataforma común Tanto los clientes como los proveedores pueden innovar y colaborar con el fin de comercializar soluciones basadas en NFV y SDN. (OpenDaylight, a Linux Foundation Collaborative Project, 2015) En el comunicado de helio, la plataforma ha evolucionado OpenDaylight en otras áreas clave, como la alta disponibilidad, clustering y seguridad, así como el fortalecimiento y la adición de nuevos protocolos como OpenFlow tipo de tabla Patrones, PacketCable MultiMedia, y el framework de políticas de aplicaciones y herramientas para el servicio de función de encadenamiento. (OpenDaylight, a

Linux Foundation Collaborative Project, 2015) OpenDaylight puede ser el componente central dentro de cualquier arquitectura SDN. Basándose en una fuente abierta SDN y el controlador NFV Permite a los usuarios reducir la complejidad operativa, extender la vida de la infraestructura de hardware existente y permitir nuevos servicios y capacidades sólo disponibles con NEE. Ya sea que la organización es un proveedor de TI de la empresa, un proveedor de servicios de red o un proveedor de servicios en la nube, puede comenzar a tomar ventaja de SDN y NFV utilizando un controlador de código abierto impulsado por la comunidad disponibles en la actualidad. (OpenDaylight, a

Linux Foundation Collaborative Project, 2015)

29

2.5 ELEMENTOS A TENER EN CUENTA PARA LA SELECCIÓN DE CONTROLADORES SDN

Saber elegir o seleccionar un controlador es vital en el diseño de una red SDN, ya que no todos cumplen con los mismos objetivos o están limitados a tareas muy específicas. A continuación se presentan las características más relevantes al momento de tomar la decisión de cual controlador seleccionar, Los puntos a tener presentes al evaluar un controlador SDN se describen de la siguiente manera: (revistatelematica, 2014)

Soporte OpenFlow: Al elegir un controlador los administradores de red necesitan conocer las características de las versiones de OpenFlow que el controlador soporta, así como las posibilidades que ofrece el proveedor para migrar a las nuevas versiones del protocolo, tales como la v1.3 y la v1.4.

Virtualización de red: Debido a los beneficios que ofrece la virtualización de red, un controlador SDN debe soportarla. Esta característica permite a los administradores crear dinámicamente las redes virtuales basadas en políticas, disociadas de las redes físicas, para satisfacer una amplia gama de requisitos.

Funcionalidad de la red: Para lograr mayor flexibilidad en términos de cómo los flujos son enrutados, es importante que el controlador SDN pueda tomar decisiones de enrutamiento basado en múltiples campos de la cabecera de OpenFlow.

Escalabilidad: Una consideración fundamental con respecto a la escalabilidad de una red SDN es el número de conmutadores o switches que un controlador SDN puede soportar.

Rendimiento: Una de las principales funciones de un controlador SDN es establecer flujos. Por ello, dos de los indicadores claves de rendimiento asociados con un controlador SDN son el tiempo de conformación de flujo y el número de flujos por segundo que puede establecer el controlador.

Programación de red: Una de las características fundamentales de las SDN es la existencia de interfaces para la programación del controlador, lo que posibilita que este ofrezca varias funcionalidades.

30

Confiabilidad: Una de las técnicas que un controlador SDN puede utilizar para aumentar la fiabilidad de la red, es la capacidad de descubrir múltiples caminos desde el origen hasta el destino lo cual puede realizar si continuamente controla la topología de la red. Si el controlador SDN establece varias rutas entre el origen y el destino, la disponibilidad de la solución no se ve afectada por la interrupción de un solo enlace.

Seguridad de la red: Con el fin de proporcionar seguridad a la red, un controlador SDN debe ser capaz de soportar la autenticación y autorización. Debido a que un controlador SDN es candidato para un ataque malicioso, necesita poseer la capacidad de limitar las comunicaciones de control.

Monitorización centralizada y visualización: Un controlador SDN tiene que ser capaz de utilizar los datos ofrecidos por el protocolo OpenFlow para identificar los problemas en la red y, automáticamente, cambiar la ruta que toma un flujo determinado.

Fabricantes de controladores SDN: Debido a la volatilidad del mercado SDN en general, y del mercado del controlador SDN, en particular, las organizaciones que deben evaluar controladores SDN para sus redes deben centrarse no sólo en los atributos técnicos del controlador, sino también en las características del vendedor o proveedor.

Soporte de plataformas: Los controladores SDN corren sobre sistemas operativos siendo importante que el que se esté evaluando sea multiplataforma. En muchas entidades es de gran interés que el controlador corra sobre plataformas de código abierto.

Procesamiento: Al evaluar un controlador se debe conocer si el mismo soporta procesos múltiples o no, pues esto puede repercutir en la escalabilidad de los núcleos de la CPU.

31

2.6 INTRODUCCIÓN A MPLS REAL MPLS quiere decir Conmutación de Etiquetas Multiprotocolo (Multiprotocol Label Switching), es una tecnología relativamente nueva que se desarrolló para solucionar la mayoría de los problemas que existen en la técnica actual de reenvío de paquetes, asignando etiquetas a los paquetes en función de su prioridad de despacho; permite construir redes virtuales privada (VPNs), flexibles y ampliables, que respaldan la prestación de servicios en diferentes niveles. (SALVIAT, 2005) Opera entre la capa de enlace de datos y la capa de red del modelo OSI tal como se observa en la Figura 4, fue diseñado para unificar el servicio de transporte de datos para las redes basadas en circuitos y las basadas en paquetes, puede ser utilizado para transportar diferentes tipos de tráfico incluyendo tráfico de voz y de paquetes IP. (Peralta, 2015)

FIGURA 4. Capa 2.5 Modelo OSI, exposición arquitectura MPLS,

2015, Clase de teoría de las telecomunicaciones, Ingeniera Line Yasmín Becerra,

Universidad Católica de Pereira

Según el énfasis que se tenga a la hora de explicar sus características y utilidad, MPLS se puede presentar como un sustituto de la conocida arquitectura IP sobre ATM, también como un protocolo para hacer túneles (sustituyendo a las técnicas habituales de “tunneling”), o bien, como una técnica para acelerar el encaminamiento de paquetes. (Peralta, 2015)

32

No obstante, se debe considerar MPLS como el avance más reciente en la evolución de las tecnologías de Routing y Forwarding en las redes IP, lo que implica una evolución en la manera de construir y gestionar las redes que se requieren para esta época. (SALVIAT, 2005) 2.6.1 Descripción cabecera MPLS En la Figura 5 se representa el esquema de los campos de la cabecera genérica MPLS y su relación con las cabeceras de los otros niveles.

Como se observa en la figura, los 32 bits de la cabecera MPLS se reparten en: 20 bits para la etiqueta MPLS, 3 bits para identificar la clase de servicio en el campo experimental llamado CoS, 1 bit de Stack para poder apilar etiquetas de forma jerárquica (S) y 8 bits para indicar el TTL (time to live) que sustenta la funcionalidad estándar TTL de las redes IP. De esta manera, las cabeceras MPLS permiten cualquier combinación de tecnologías de transporte, con la flexibilidad que esto supone para un proveedor IP a la hora de extender su red. (Castaneda, 2012)

FIGURA 5. Estudio y diseño de redes virtuales privadas (VPN) basadas en tecnología MPLS,

2004, Estructura de la cabecera genérica MPLS, pág. 54,

http://bibdigital.epn.edu.ec/bitstream/15000/5035/1/T2218.pdf

33

2.6.2 Arquitectura MPLS En la arquitectura de la red MPLS se encuentran elementos muy importantes y que cumplen con un papel valioso para el funcionamiento de la red. Se muestran estos elementos a continuación Figura 6:

FIGURA 6. MPLS Multi Protocol Label Switching,

2010, Componentes de una red MPLS,

https://sites.google.com/site/3cuelectronica/home/ethernet/mpls

2.6.2.1 Router conmutador de etiquetas (LRS: Label Switch Router) El LSR es un router conmutador de etiquetas que basa su funcionamiento de envío en el chequeo de la etiqueta o pila de etiquetas que ha sido añadida a un paquete IP en la frontera de ingreso al dominio MPLS. No realiza funciones de chequeo de capa de red ya que para el envío basta con analizar la etiqueta contenida en el paquete IP etiquetado, la cual le indica su siguiente salto. El LSR remueve la etiqueta y asigna otra para indicar el siguiente salto dentro de la red MPLS. (Canalis M. S., 2003)

34

2.6.2.2 Router de frontera de etiquetas (LER: Label Egde Router) El LER es un router el cual se encuentra en la frontera de una red MPLS. Se encarga de realizar y brindar funcionalidades de aplicaciones del cliente cuando esté conectado a la red de un proveedor MPLS. Este elemento se encuentra presente tanto en el ingreso como en el egreso de la red, cumpliendo las funciones principales de la misma. Estos enrutadores cumplen funciones ya sea para un Dominio MPLS como para un Dominio no MPLS. (Canalis M. S., 2003) Cuando un paquete ingresa etiquetado a un LER de salida en la red MPLS, este dispositivo de red le realiza el chequeo correspondiente y al consultar con su tabla de etiquetas el LER de salida decide si el siguiente salto lo saca o no del dominio MPLS. Si el siguiente salto lo saca de la nube, el LER de salida removerá la etiqueta del paquete y lo enviara a su destino por enrutamiento convencional. Si el siguiente salto es una nube MPLS (puede ser él mismo LER, u otro dominio MPLS) el LER de salida mediante su tabla de etiquetas tomará la decisión correspondiente. (Canalis M. S., 2003)

2.6.2.3 Clase equivalente de envió (FEC: Forwarding Equivalence Class) La Clase Equivalente de Envío (FEC) hace referencia a un subconjunto de paquetes IP que son tratados de la misma forma por un router (sobre la misma ruta y con el mismo tratamiento de envío) Se puede decir que en el enrutamiento convencional, cada paquete está asociado a un nuevo FEC en cada salto. En MPLS la operación de asignar una FEC a un paquete solo se realiza una vez que el mismo ingrese a la red. (Canalis M. S., 2003)

2.6.2.4 NHLFE (Next Hop Label Forwarding Entry) Es una entrada a una tabla de envío en la que se indica la etiqueta del siguiente hop. Por lo tanto, cuando un paquete entra a una red MPLS, se le asigna un determinado FEC. (Canalis M. S., 2003)

35

2.6.3 Protocolos utilizados en MPLS En esta sección se dará una descripción de los protocolos más utilizados en MPLS, como hemos visto estos permiten la distribución de etiquetas entre los routers de conmutación de etiquetas (LSR), permitiendo así la creación de LSP, dos de los protocolos más difundidos son: 2.6.3.1 Protocolo LDP El LDP es un protocolo creado específicamente para la distribución de información concerniente a uniones FEC/etiqueta, dentro de una red MPLS. Es usado para mapear FECs a etiquetas, lo cual consecuentemente creará LSPs. Las sesiones LDP son creadas entre pares LDP de una red MPLS (pares no necesariamente adyacentes). Los pares intercambian los siguientes tipos de mensajes LSP: (Cisco

Systems, Inc., 2007)

Mensajes de descubrimiento (discovery messages): anuncian y mantienen la presencia de un LSR dentro de la red MPLS.

Mensajes de sesión (session messages): establecen, mantienen y terminan sesiones entre pares LDP.

Mensajes de advertencia (advertisement messages): crean, cambian y borran mapeos de etiquetas a FECs.

Mensajes de notificación (notification messages): proveen de información de aviso y de información de error en la señal.

2.6.3.2 RSVP-TE El protocolo RSVP-TE es una extensión del protocolo RSVP original, que fue diseñado para ejecutar la distribución de etiquetas sobre MPLS. RSVP-TE soporta además la creación de rutas explícitas con o sin reserva de recursos. Una de las características adicionales más importantes de este protocolo es que permite el re-enrutamiento de los túneles LSP, con el fin de dar una solución ante caídas de red, congestión y cuellos de botella. (Dibildox, 2006)

36

Originalmente el IETF propuso a RSVP-TE como el protocolo de señalización principal, ya que este era utilizado por la mayoría de las compañías de Internet en MPLS y porque la tendencia es utilizar un protocolo de señalización RSVP. De aquí en adelante la IETF recomendó profundizar más en el protocolo RSVP y dejar a un lado CR-LDP. (Dibildox, 2006) 2.6.4 Componente de envío de etiquetas El algoritmo de reenvío utilizado por el componente de envío de conmutación de etiquetas se basa en el intercambio de etiqueta. El algoritmo funciona de la siguiente manera. Cuando un LSR recibe un paquete, el router extrae la etiqueta del paquete y lo utiliza como un índice en su tabla de reenvío. Una vez que se encuentra la entrada indexada por la etiqueta (la entrada tiene su componente de etiqueta de entrada igual a la etiqueta extraída del paquete), para cada subentrada de la entrada se encuentra el router sustituye a la etiqueta en el paquete con la etiqueta de salida de la subentrada y envía el paquete a través de la interfaz de salida especificado por esta subentrada al siguiente salto especificado por esta subentrada. (Farrel, MPLS: Next Steps, The Morgan Kaufmann Series in Networking,

2008) Si la entrada especifica una cola de salida en particular, el router coloca el paquete en la cola especificada. Supone que un LSR mantiene una única tabla de reenvío. Sin embargo, un LSR también puede mantener una tabla de reenvío distinto para cada una de sus interfaces. En este caso, la única modificación al algoritmo es que después de que el LSR recibe un paquete, el LSR utiliza la interfaz en la que se recibió el paquete para seleccionar una tabla de reenvío particular que se utilizará para manejar el paquete. (Farrel, MPLS: Next Steps, The Morgan Kaufmann

Series in Networking, 2008) El camino que sigue un paquete de datos a través de la red se define por la transición en los valores de la etiqueta. Puesto que el mapeo en cada nodo es constante, la ruta se determina únicamente por el valor de la etiqueta en el nodo primero. Dicha ruta se denomina Switched Path Label (LSP). (Farrel, MPLS: Next

Steps, The Morgan Kaufmann Series in Networking, 2008) Cada nodo en una red MPLS mantiene una tabla de consulta que permite determinar el siguiente salto en el LSP. La tabla se conoce como la Base de información Etiqueta de Reenvió (LFIB) y mapas (interfaz entrante, etiqueta entrante) a (interfaz saliente, etiqueta saliente). (Farrel, MPLS: Next Steps, The

Morgan Kaufmann Series in Networking, 2008)

37

Esta es toda la información necesaria para enviar paquetes etiquetados. Una vez que el LFIB ha sido ocupado no hay libertad de elección de los valores de la etiqueta. El proceso de ocupar la LFIB se controla a través de la configuración o por medio de los protocolos de distribución de etiquetas. En general, la elección de los valores de etiqueta para poner en el LFIB se rige únicamente por la consideración de que las etiquetas que ya están en uso, y las capacidades del hardware / software que será cambiando paquetes basada en los valores de la etiqueta. (Farrel, MPLS: Next Steps, The Morgan Kaufmann Series in Networking, 2008)

FIGURA 7. MPLS: Next Steps, The Morgan Kaufmann Series in Networking,

2008, Cambio de etiquetas en redes MPLS, pág. 15, http://www.amazon.com/MPLS-Volume-

Morgan-Kaufmann-Networking/dp/0123744008

La Figura 7, ilustra dos LSP que transportan datos desde el Host A al Host B y Host C. La red MPLS se compone de cuatro routers Label Switching (LSRs) para reenviar los paquetes. Host A envía paquetes IP normales a LSR V utilizando su ruta por defecto. LSR V es un ingreso LSR y clasifica los paquetes basados en el destino final, los asigna a un LSP y los etiqueta. Esos paquetes dirigidos a Host B se asignan a la LSP superior y están etiquetados con el valor 15; aquellos para Host C se asignan a la LSP inferior y están etiquetados con el valor 10. Una vez etiquetados, los paquetes se envían por la interfaz apropiada hacia LSR W. (Farrel,

MPLS: Next Steps, 2008) En LSR W se examina cada paquete etiquetado para determinar la interfaz de entrada y la etiqueta entrante. Estos se verifican en el LFIB para determinar la etiqueta de salida y la interfaz de salida. Los valores de la etiqueta se intercambian (entrante-reemplazado-saliente) y los paquetes se envían hacia las interfaces designadas. En la Figura 7, los paquetes etiquetados 15 se envían por la interfaz

38

de salida para LSR X que lleva el nuevo valor 19; mientras el paquete 10 que estaba etiquetado se envían por la interfaz de salida para LSR y llevar la nueva etiqueta 62. (Farrel, MPLS: Next Steps, 2008) LSR X e LSR Y son LSRs salida. También realizan una consulta en sus LFIBs, pero las entradas indican que deberían eliminar la cabecera shim y reenviar el paquete de forma normal. Este reenvío puede ser a través de la tabla de enrutamiento IP normal, pero puede ser optimizado por el LFIB que indica la interfaz de salida de modo que no se requiere el enrutamiento look-up. Así, en el ejemplo, si LSR V asocia todos los paquetes para Host B con el LSP superior y los etiqueta con el valor de 15, se remitirán con éxito a través de la red y se entregan al Host B. (Farrel, MPLS: Next Steps, 2008) La simplicidad del algoritmo de reenvío utilizado por el componente de envío de etiquetas de conmutación facilita las implementaciones de bajo costo de este algoritmo en hardware, que, a su vez, permite aumentar el rendimiento de reenvío más rápido sin necesidad de hardware más caro. (Farrel, MPLS: Next Steps, 2008) En lo que respecta a la decisión de reenvío, diferentes paquetes clasificados dentro de un mismo FEC son considerados idénticos. Todos los paquetes pertenecientes a un mismo FEC seguirán el mismo camino. (Farrel, MPLS: Next

Steps, 2008) En el envío IP, un router considerará a dos paquetes dentro del mismo FEC si hay algún prefijo de dirección X en la tabla de routing del router el cuál sea de mayor concordancia para la dirección de destino de los paquetes. A medida que el paquete sigue circulando por la red, cada router realiza la misma operación de asignación en un FEC. (Farrel, MPLS: Next Steps, 2008) En MPLS, esta asignación se efectúa solamente cuando el paquete entra en la red, como se observa en la Figura 8 Tras esto, el FEC al que el paquete ha sido asignado se codifica en un valor llamado Etiqueta. Cuando un paquete va a ser enviado al siguiente nodo, se le añade la etiqueta. (Farrel, MPLS: Next Steps, 2008) En el resto de los nodos del camino, no se necesitará realizar análisis de la cabecera del paquete. La etiqueta que acompaña al paquete servirá para encontrar el siguiente salto y una nueva etiqueta, procediendo a repetir el proceso de envío. (Farrel, MPLS: Next Steps, 2008)

39

FIGURA 8. MPLS Multi Protocol Label Switching,

2003, Esquema funcional de MPLS, pág. 103,

http://exa.unne.edu.ar/informatica/SO/libmpls.PDF

2.6.5 Etiquetas La etiqueta es un identificador corto de longitud fija de 32 bits, empleado para asociar un determinado FEC; usualmente tiene significado local.

Cuando se habla de etiquetas MPLS se refiere a una percepción simplificada del encabezado de un paquete IP, aun cuando una etiqueta contiene toda la información asociada al direccionamiento de un paquete hasta su destino final en la red MPLS. A diferencia de un encabezado IP, las etiquetas no contienen una dirección IP, sino más bien un valor numérico acordado entre dos nodos consecutivos para proporcionar una conexión a través de un LSP. (Castaneda, 2012)

40

2.6.6 Apilado de etiquetas Una de las características más potentes de MPLS es la capacidad de apilar etiquetas. Es útil tener un modelo más general en el que un paquete etiquetado transporte cierto número de etiquetas, organizadas en una estructura de pila. A esta estructura se le denomina “pila de etiquetas”, siendo esta una característica fundamental de MPLS. Permitiendo a MPLS sea utilizado simultáneamente para enrutar a un nivel fino y a un nivel mayor. Cada nivel en una pila de etiquetas pertenece a algún nivel jerárquico. Esto facilita el modo de operación de túnel en MPLS. (Castaneda, 2012)

Un paquete etiquetado puede llevar muchas etiquetas, las mismas que pueden anidarse formando una pila con funcionamiento LIFO (Last-In, First-Out), ultimo en entrar primero en salir. Esto permite ir agregando o segregando flujos. (Castaneda,

2012) El procesamiento está siempre basado en la etiqueta superior, sin tener en cuenta que cierto número de etiquetas pueda haber estado sobre ella en la pila, anteriormente, o que otras tantas estén bajo ella actualmente. Un paquete sin etiquetar se puede ver como un paquete con la pila de etiquetas vacía. Si la profundidad de la pila de etiquetas es de profundidad m, a la etiqueta del fondo se la nombra como 1 y a la de la cima como m. (nivel 1, nivel m) como se observa en la Figura 9. Cabe destacar que cualquier LSR puede añadir una etiqueta a la pila (operación push) o puede remover la misma (operación pop). (Castaneda, 2012) El apilamiento de etiquetas hace posible la agregación de LSPs en un solo LSP gracias a la creación de un túnel para una porción de la ruta a través de una red. Al inicio de un túnel el LSR asigna la misma etiqueta a los paquetes de un número de LSPs, colocando la etiqueta sobre la pila de cada paquete. Al final del túnel, otro LSR es el encargado de extraer la etiqueta de la cima de la pila. MPLS se destaca debido a que soporta una pila ilimitada, logrando de esta manera una considerable flexibilidad en la transmisión de la información. (Castaneda, 2012)

41

FIGURA 9. Análisis de la red de la cnt ep para la implementación de servicios integrados

mediante tecnología MPLS,

2008, Apilamiento de etiquetas, pág. 44,

http://dspace.unach.edu.ec/bitstream/123456789/340/1/FI -IET-40A019.pdf

En la Figura 10 se ilustra cómo se utilizan pilas de etiqueta en la red. LSR P toma el tráfico de Host A dirigido al Host D e impone una etiqueta (5). Del mismo modo, el tráfico C de Host a Host E se maneja a LSR R donde se impone una etiqueta (8). En el W de LSR, tanto LSP se someten a label swapping (5-3 y 8-7) y se transmite por un túnel en un nuevo LSP donde una etiqueta adicional (9) es empujada en la pila. La expedición a lo largo de la ruta de acceso W-X-Y-Z como se describe antes, la etiqueta superior en la pila se intercambia y se reenvía el paquete. Tenga en cuenta que las etiquetas más abajo de la pila no son examinados o procesado. En el LSR Z, la etiqueta que define el túnel se extraen de la pila, y el tráfico se reenvía utilizando la siguiente etiqueta en la pila. (Farrel,

MPLS: Next Steps, 2008)

42

FIGURA 10. MPLS: Next Steps, The Morgan Kaufmann Series in Networking,

2008, Apilamiento de etiquetas en redes MPLS, pág. 21, http://www.amazon.com/MPLS-

Volume-Morgan-Kaufmann-Networking/dp/0123744008

Las medidas necesarias para hacer un túnel pueden ser codificadas en la LFIB utilizando una columna adicional. La LFIB en la Figura 11, muestra cómo el proceso en la salida del túnel (LSR Z) es un poco torpe. En primer lugar, se hace una búsqueda en la LFIB para el permiso recibido (6), y luego se realizará una segunda búsqueda para procesar las etiquetas de los LSPs tunelizados (3 y 7) para determinar cómo reenviar los paquetes. La segunda búsqueda puede ser difícil de realizar en las implementaciones de hardware y no es realmente necesario si el nodo anterior realiza el penúltimo salto.

43

Interfaz de entrada

Etiqueta entrada Acción

Interfaz de salida

Etiquetas

de salida

FIGURA 11. MPLS: Next Steps, The Morgan Kaufmann Series in Networking, 2008, Proceso

de apilamiento de etiquetas en redes MPLS,

cuadro de interfaces de la red , pág. 21, http://www.amazon.com/MPLS-Volume-Morgan-

Kaufmann-Networking/dp/0123744008

2.7 Aplicaciones de MPLS Entre las aplicaciones más importantes que maneja MPLS tenemos las siguientes:

Ingeniería de trafico MPLS TE

Implementación de QoS en MPLS

Redes Privadas Virtuales (VPN)

44

2.7.1 Ingeniería de tráfico en MPLS Ingeniería de tráfico es el proceso de mapear la demanda de tráfico sobre la topología de la red. Es la habilidad de controlar el flujo de tráfico sobre la red. Se establece que la ingeniería de trafico concierne a la optimización de la performance de una red e involucra diversas áreas: mediciones de tráfico, modelado de tráfico y redes, control del tráfico en Internet, evaluación de performance. (Farrel, MPLS: Next Steps, 2008) Se establece que los principales objetivos de TE son:

Mover el tráfico del camino establecido por el IGP(Protocolo de pasarela interno) a un camino menos congestionado

Utilizar el exceso de ancho de banda sobre los enlaces sub-utilizados

Maximizar la utilización de los enlaces y nodos de la red.

Aumentar la confiabilidad del servicio

Alcanzar requerimientos impuestos Los requerimientos pueden ser:

Orientados al tráfico: pérdidas de paquetes, retardos, etc.

Orientados a los recursos: básicamente utilización de capacidad de la red. Las acciones de control tomadas al realizar TE pueden involucrar:

Modificación de los parámetros de gestión de tráfico

Modificación de los parámetros asociados al ruteo

Modificación de los parámetros y atributos asociados con los recursos

45

En general se busca también minimizar la intervención manual para tomar acciones de control. La ingeniería de tráfico debe resolver tres problemas básicos:

Cómo mapear paquetes en FEC

Cómo mapear FEC en troncales tráfico.

Cómo mapear troncales en la red física 2.7.2 Implementación de QoS en MPLS Es la habilidad para diferenciar diversas clases de servicio y asignarles prioridades sobre cada enrutador en la red. El primer paso para la implementación de QoS es identificar las distintas clases de tráfico que la red va a soportar. El tráfico puede ser clasificado basado en el tipo como voz, aplicaciones, datos, etc., y sobre las propiedades de patrones de tráfico, luego de que el tráfico ha sido clasificado el próximo paso es identificar que operaciones de QoS serán llevadas a cabo para cada uno de esos tipos sobre el enrutador local. (Lobo, 2005) La calidad de servicio garantiza el valor de uno o varios de los parámetros que definen la calidad de servicio que ofrece la red. El contrato que especifica los parámetros de calidad de servicio acordados entre el proveedor y el usuario se denomina SLA. (Lobo, 2005) Donde MPLS tiene el campo EXP para poder propagar la clase de servicio en la correspondiente LSP. Los parámetros típicos que se deben cumplir en una red que tenga calidad de servicio son los siguientes:

1. Disponibilidad: tiempo mínimo que el operador asegura que la red esté en funcionamiento.

2. Ancho de Banda: indica el ancho de banda mínimo que el operador garantiza al usuario dentro de su red.

3. Pérdida de paquetes: Máximo de paquetes perdidos (siempre y cuando el

usuario no exceda el caudal garantizado).

4. Round Trip Delay: el retardo de ida y vuelta medio de los paquetes.

46

5. Jitter: la fluctuación que se puede producir en el retardo de ida y vuelta medio.

MPLS y las redes de nueva generación permiten asignar QoS a un cliente o a un tipo de tráfico una FEC a la que se asocie un LSP que discurra por enlaces con bajo nivel de carga. (Lobo, 2005) MPLS QoS fue diseñado para soportar a IP QoS por lo que no difieren en mucho de los beneficios que provee el simple IP QoS, pues no modifica fundamentalmente el modelo de calidad de servicio de IP. Pero hace importante el uso de MPLS QoS, dado que a diferencia de IP, no es un protocolo que corre entre los terminales (end to end). (Lobo, 2005) Las redes de nueva generación se convertirán en futuro próximo a MPLS lo que motiva para soportar QoS, integrando de esta manera los servicios. Tomando en cuenta que la calidad de servicio tiene importancia entre equipos, lo cual se adapta mejor a MPLS que a IP. (Lobo, 2005)

47

3 EMULACIÓN DE MPLS MEDIANTE UN EMULADOR DE REDES

DEFINIDAS POR SOFTWARE

En la siguiente sección se tiene como objetivo realizar la emulación de MPLS en dos topologías sencillas SDN seleccionadas como prueba, que permita evidenciar el funcionamiento de la red con el protocolo MPLS, para ello se dará una conceptualización sobre simulación, emulación y se describirán diferentes herramientas existentes para emular redes definidas por software. 3.1 HERRAMIENTAS DE SIMULACIÓN Y EMULACIÓN DE REDES

DEFINIDAS POR SOFTWARE 3.1.1 Simulación La simulación es el desarrollo de un modelo lógico matemático de un sistema el cual permite la imitación del proceso en un intervalo de tiempo de un modelo físico (real), ya sea realizado manualmente o computacionalmente, donde se involucra la historia artificial de un sistema y la observación de dicha historia mediante la experimentación con las cuales se pueden inferir las características operacionales de tal sistema. (Azarang M., 2006) En la simulación existen dos parámetros fundamentales que son:

Desarrollo del modelo: hace referencia al modelo matemático lógico y sus ecuaciones que serán una representación del sistema y la preparación de un software.

Experimentación: En la experimentación se tomaran en cuenta las variables de entrada del sistema para analizar el comportamiento de dicho sistema.

En el ámbito de la educación la simulación es una herramienta muy usada en cuanto a la realización de laboratorios o prácticas se refiere, puesto que con la simulación se podrá recrear el funcionamiento de muchos elementos usados en el proceso de aprendizaje de una ciencia y a su vez proporciona a la entidad educativa un ahorro económico al no tener que adquirir equipos reales los cuales pueden ser muy costosos. (Azarang M., 2006)

48

Ventajas

o Una vez construido, el modelo puede ser modificado de manera rápida con el fin de analizar diferentes políticas o escenarios.

o Generalmente es más barato mejorar el sistema vía simulación, que hacerlo directamente en el sistema real.

o Es mucho más sencillo comprender y visualizar los métodos de simulación que los métodos puramente analíticos.

o Los métodos analíticos se desarrollan casi siempre, para sistemas relativamente sencillos donde suele hacerse un gran número de suposiciones o simplificaciones, mientras que con los modelos de simulación es posible analizar sistemas de mayor complejidad o con mayor detalle.

o En algunos casos, la simulación es el único medio para lograr una solución.

Desventajas

o Los modelos de simulación en una computadora son costosos y requieren mucho tiempo para desarrollarse y validarse.

o Se requiere gran cantidad de corridas computacionales para encontrar "soluciones óptimas", lo cual repercute en altos costos.

o Es difícil aceptar los modelos de simulación. o Los modelos de simulación no dan soluciones óptimas. o La solución de un modelo de simulación puede dar al analista un

falso sentido de seguridad. 3.1.2 Emulación Un emulador es un software que permite ejecutar programas en un entorno diferente al propio es decir consiste en tomar algo ya creado y adaptarlo para que funcione o imite las funciones de otro sistema, un emulador tiene como fin el de imitar lo más preciso al sistema real en muchas ocasiones superando el desempeño del modelo original. (Beuran, 2012) Emulación, como tal, no es un nuevo concepto en ciencias de la computación, y ni siquiera en un sentido más amplio, ya que este enfoque ya está bien establecido en varios dominios, como se señala en (Beuran, 2012).

49

A pesar de que la idea de la emulación de la red apareció hace casi 30 años, y que la emulación de red, como tal, ha existido durante más de 10 años, todavía no existe un acuerdo total sobre lo que la emulación de la red como debe ser definida, y con frecuencia hay confusión con la técnica relacionada de simulación de la red. (Beuran, 2012) La mayoría de los investigadores parecen estar de acuerdo que la emulación implica elementos reales utilizados junto con los componentes simulados. Sin embargo, se requieren propiedades adicionales en algunas labores. Por ejemplo, (Guruprasad, 2002) presenta "que se ejecuta en tiempo real" como una propiedad

definitoria de emuladores. (S. Guruprasad, 2005) Sin embargo, el trabajo más reciente de Gokturk reconoce que el tiempo es más que otra parte de la realidad que se puede simular en un experimento de emulación. (A stance on emulation and testbeds, 2007) 3.1.3 NCTUns (EstiNet) El NCTUns es una herramienta de alta fidelidad y simulador de red extensible y emulador, capaz de simular diferentes protocolos utilizados en ambas redes IP cableadas e inalámbricas. Su tecnología central se basa en la metodología de volver a entrar en el kernel inventado por el Prof. SY Wang, cuando él estaba persiguiendo su PhD. grado en la Universidad de Harvard. Debido a esta nueva metodología, NCTUns proporciona muchas ventajas únicas que no se puede conseguir fácilmente por simuladores de redes tradicionales. La herramienta de simulación NCTUns se comercializa en la actualidad con el nombre EstiNet 7.0. Esta versión implementa todas las mejores aplicaciones de NCTUns 6.0. Esta herramienta es open-source y se plantea como uno de los mejores simuladores en las comunidades Networking en cuanto a su alta fiabilidad. Wang, Wang, Li, y Lau (2011) describen el alto potencial que se encuentra en la herramienta, ya que utilizan la implementación de VANET y describen como la herramienta permite, por medio de una interfaz gráfica, hacer un esquema de simulación muy fácilmente. Por otro lado, Khan, Zaman, y Reddy (2008) indican que el software de simulación NCTUns provee una interfaz de usuario integrada y profesional; por todo ello, la herramienta es catalogada con un alto nivel de interfaz gráfica. (NCTUns, 2013)

50

3.1.4 DieCast Es emulador trabaja muy cercano al comportamiento de la red real y utiliza pocos recursos físicos. Permite trabajar amplias redes que incluyen miles de dispositivos, ejecuta protocolos heterogéneos y configuraciones de software que se distribuye a través de cientos de redes físicas. Diecast no se centra en la ampliación de los recursos de hardware, como memoria principal y el disco, emula SDN y fue desarrollado para el área académica. (Deepak Kumar, 2014) 3.1.5 ModelNet Es un emulador escalable que proporciona la emulación de redes a gran escala. El punto principal que hace a ModelNet diferente de otro emulador, es que se centra en la emulación de topología de redes de gran tamaño. En ModelNet no es necesario contar con recursos de maquina altos para emular la red. El ModelNet incluye cinco fases: Create, Distill, Assign, Bind and run. La emulación en ModelNet se basa en tiempo real, por lo tanto, cada paquete que se envía a través de la red emulada lleva un intervalo de tiempo igual, con el mismo retardo y la misma tasa de pérdida de paquetes como si se tratara de una red real, fue desarrollado para el área académica. (Deepak Kumar, 2014) 3.1.6 Mininet Mininet es un emulador de red que crea una red de hosts virtuales, switches, Routers, y enlaces. Un anfitrión Mininet ejecuta software de red estándar de Linux, y sus switches soportan OpenFlow para el enrutamiento altamente flexible y redes definidas por software. Un anfitrión Mininet se comporta como una máquina real; se puede iniciar ssh en ella y ejecutar programas arbitrarios (incluyendo cualquier cosa que se instala en el sistema Linux subyacente.) (Mininet Team, 2015) Los programas que se ejecuta pueden enviar paquetes a través de la interfaz Ethernet, con una velocidad de enlace dada. Los paquetes se procesan por lo que parece ser un interruptor Ethernet, Routers, o middlebox, con una cantidad dada de cola. Cuando dos programas, como un cliente iperf y el servidor, se comunican a través de Mininet, el rendimiento medido debe coincidir con el de dos (más lento) máquinas nativas.

51

En resumen, hosts virtuales, conmutadores, enlaces, y los controladores de Mininet son la reales, que sólo se crean utilizando software en lugar de hardware y en su mayor parte su comportamiento es similar a los elementos de hardware discretos. Por lo general, es posible crear una red Mininet que se asemeja a una red de hardware, o una red de hardware que se asemeja a una red Mininet, y ejecutar el mismo código binario y aplicaciones en cualquier plataforma. 3.2 HERRAMIENTA DE EMULACIÓN SELECCIONADA PARA EL

DESARROLLO DEL PROYECTO Mininet fue la herramienta elegida para el desarrollo de nuestro trabajo puesto que se ajustó a la necesidad de un emulador que soportara redes SDN, además cuenta con una amplia flexibilidad, Mininet es un emulador para la extensión de redes en los limitados recursos de un solo ordenador o de una máquina virtual. Una de las características relevantes en la elección de MiniNet para este proyecto es que este emulador permite correr el código sin modificar de manera interactiva en el hardware virtual de un ordenador, proporcionando comodidad, veracidad, facilidad de uso, rendimiento y precisión escalabilidad. Mininet no tiene la necesidad de modelar hosts, conmutadores, enlaces y Controladores SDN / OpenFlow. Permite la creación de topologías de gran tamaño hasta la escala de miles de nodos y realizar pruebas en ellos con mucha facilidad. Tiene herramientas muy simples de línea de comandos y API. MiniNet permite al usuario crear fácilmente, personalizar, compartir y probar redes SDN. Figura 12. MiniNet está disponible gratuitamente y es un software de código abierto que emula dispositivos OpenFlow y controladores SDN lo que es una ventaja en el desarrollo de un trabajo académico. MiniNet puede emular redes SDN, puede ejecutar un controlador para experimentos. Permite emulando verdadero mundo de escenarios de red de controladores, SDN está incluido con MiniNet en VM. Los controladores predeterminados son buenos, pero para la implementación de los conceptos de anticipo, POX se utiliza de controlador.

52

FIGURA 12. Mininet Testing Platform Controller,

2014, Emulating Real Networks in Mininet, pág. 1,

http://www.sbsstc.ac.in/icccs2014/Papers/Paper29.pdf

3.3 CONTROLADOR SELECCIONADO PARA EL DESARROLLO DEL

PROYECTO Saber elegir o seleccionar un controlador es muy importante en el diseño de una red SDN tal como se explicó en el numeral 2.5, ya que no todos cumplen con los mismos objetivos o están limitados a tareas muy específicas. Validando las características más relevantes de los controladores existentes actualmente, nos llevó a elegir el mejor controlador para el desarrollo de este proyecto, el controlador seleccionado en este caso fue Floodlight el cual es un controlador OpenFlow de clase empresarial con una comunidad de desarrolladores a nivel mundial y con muy buen soporte para diseño de redes SDN.

53

3.3.1 Floodlight Floodlight es un controlador OpenFlow desarrollado en Java. Aparece como evolución del controlador Beacon (Erickson, The Beacon OpenFlow Controller, 2011), por lo que igualmente comparten similar estructura. Java brinda soporte multiplataforma y sencillez de programación. El usuario puede hacer uso de herramientas típicas de Java, como son threads, temporizadores, sockets, etc. Floodlight incluye la librería OpenFlowJ para trabajar con mensajes OpenFlow. Esta librería es una implementación Java orientada a objetos de la especificación de la versión 1.3 de OpenFlow. Los listeners se utilizan para notificar cuando los conmutadores son añadidos o eliminados (IOFSwitchListener), y para recibir distintos tipos de mensajes específicos OpenFlow (IOFMessageListener). Además, Floodlight contiene aplicaciones básicas de referencia las cuales constituyen el core. Esta API adicional es la que se muestra en la Figura 13. (Izard,

2015).

FIGURA 13. Pipeline del thread IOFMessageListener de Beacon,

Emulating Controlador Openflow Beacon, pág. 3,

http://yuba.stanford.edu/~derickso/docs/hotsdn15 -erickson.pdf

Las aplicaciones básicas disponibles son:

Device Manager: muestra los dispositivos que aparecen en la red, incluyendo sus direcciones (Ethernet e IP), fecha de último uso, el conmutador y el puerto que han sido vistos por última vez. El Device Manager provee una interfaz (IDeviceManager) para buscar dispositivos conocidos y la habilidad de registrarlos para recibir eventos cuando nuevos dispositivos sean incluidos, actualizados o eliminados. (Izard, 2015).

Topology: descubre los enlaces entre los conmutadores OpenFlow. Su interfaz (ITopology) permite la recuperación de una lista de los enlaces y el registro de eventos para ser notificados cuando los enlaces son incluidos o eliminados. (Izard, 2015).

54

Routing: provee enrutamiento de la capa L2 con el camino más corto entre dos dispositivos de la red. Esta aplicación exporta la interfaz IRoutingEngine, permitiendo implementaciones con diferentes lógicas de encaminamiento. La implementación incluida usa todos los métodos de computación de camino más corto entre dos pares. Esta aplicación depende tanto de la Topology como del Device Manager. (Izard, 2015).

Web: provee una Web User Interface (UI) para Floodlight. La aplicación web provee la interfaz IWebManageable, permitiendo a los desarrolladores añadir sus propios elementos UI. (Izard, 2015).

Por otro lado, Floodlight contiene funciones adicionales como se muestra en la Figura 14. Se presenta un Java API para el desarrollo de aplicaciones que residen dentro del controlador y requieren alta eficiencia de procesamiento (por ejemplo, procesamiento de paquetes tipo PACKET_IN). Adicionalmente, el REST API (por las siglas de Representational State Transfer) está disponible para configuración remota (puerto 8080 por defecto) de los diferentes servicios del controlador. De esta manera, los usuarios pueden crear aplicaciones que invoquen servicios del controlador mediante peticiones web (HTTP REST). (Izard, 2015).

FIGURA 14. API de Floodlight, The cont roller,

2015, https://floodlight.atlassian.net/wiki/display/floodlightcontroller/The+Controller

55

3.4 VENTAJAS DEL PROCESO DE CONMUTACIÓN Y APILAMIENTO DE ETIQUETAS DE MPLS

Dentro de las características más importantes que tiene MPLS es el apilamiento de etiquetas que maneja, un paquete etiquetado puede contener varias etiquetas organizadas en modo: Ultimo en Entrar Primero en Salir (LIFO). El procesado de etiquetas en MPLS siempre se basa en la etiqueta superior, por lo que en cualquier LSR se puede añadir (push) o remover (pop) una etiqueta. La ventaja principal del apilamiento de etiquetas es que permite añadir rutas parciales dentro de la red a un LSP existente, creando así túneles. (E. Rosen, 2001). Al principio de cada túnel los LSR asignan la misma etiqueta a los paquetes que van entrando mediante la operación push. Al final de cada túnel pasa lo inverso, el LSR de salida remueve la etiqueta superior (añadida a la entrada del túnel) para mostrar la etiqueta original con el fin de que siga su trayectoria original. Esta operación se puede realizar indefinidamente formando así una red de túneles dentro de cada LSP original. (E. Rosen, 2001). MPLS permite aumentar la velocidad de envió ya que cuando los paquetes se envían a los Routers no tienen que leer la cabecera de los paquetes completa para leer la dirección destino de los paquetes, sino que leen la cabecera MPLS y la etiqueta para enviar al siguiente salto y el enrutamiento no está basado en la dirección destino sino en el intercambio de etiquetas, esto hace que la velocidad de envió incremente. (BELLESSA, 2015). El apilamiento de etiquetas permite crear túneles y por tanto reducir la utilización de etiquetas, ya que uno de los problemas de MPLS es que al tener el campo de etiqueta de 20 bits solo puede enviar 2 a la 20 posibles comunicaciones, esto lo limita para redes grandes, además las etiquetas deben ser únicas para las comunicaciones cuando se asignan, no pueden haber dos comunicaciones diferentes con la misma etiqueta, por eso es necesario utilizar menos etiquetas, esto se resuelve con los túneles. (BELLESSA, 2015).

56

3.5 ANTECEDENTES DE EMULACIÓN Y/O SIMULACIÓN DE MPLS CON REDES DEFINIDAS POR SOFTWARE

En el proyecto de implementación de MPLS con etiquetas con redes definidas por software. (BELLESSA, 2015) Nos habla que el esquema de conmutación basada en etiquetas, tales como MPLS, ha sido conocido por ser un mecanismo eficaz para superar muchos desafíos en redes definidas por software, mientras que un desarrollo mucho más reciente, se considera que tienen el potencial de revolucionar la creación de redes. Sin embargo, algunos investigadores de redes, incluso dentro de la comunidad SDN, creen que las redes SDN para poder prosperar, debe adoptar un modelo más estructurado con un borde inteligente y una etiqueta rápida simple de conmutación central. Este es un caso de uso excelente para MPLS en OpenFlow. Nos explica (BELLESSA, 2015) Pero, aunque ha habido otras implementaciones de MPLS en OpenFlow, abandonan el OpenFlow al requerir hardware sofisticado. Este sistema discute nuestra implementación híbrida OpenFlow de MPLS que sólo requiere de hardware de los productos básicos en la red central. Logramos esto compilando las etiquetas MPLS que habrían sido encontradas a lo largo de un camino a través de la red en una sola etiqueta, que se almacena en el campo de dirección MAC de destino de los paquetes. (BELLESSA, 2015). En esta tesis, (BELLESSA, 2015) nos presenta una implementación híbrida de OpenFlow con MPLS, construida con una técnica sencilla de mapeo de etiquetas en capa 2. Debido a que las etiquetas no requieren ninguna modificación en la estructura de paquetes, se puede implementar utilizando sólo los interruptores de la red central. La conclusión de esta tesis, fue que se llevó a cabo la implementación de la funcionalidad MPLS en un controlador de red OpenFlow, capaz de correr en un hardware simple sin tanto recurso. (BELLESSA, 2015) Esto lo logramos mediante la asignación de las etiquetas MPLS que se impulsaron en paquetes a una sola etiqueta estática que se almacena en el destino campo de dirección MAC del paquete y permanece inalterado, ya que el paquete viaja entre los bordes de la red. Los resultados del proyecto de implementación de MPLS, mostrado en (BELLESSA, 2015) señala que evaluaciones son muy prometedores, demostrando que somos capaces de avanzar de manera eficiente en él envió de grandes cantidades de tráfico a través de la red principal con un único hardware simple, en términos de funcionalidad disponible. (BELLESSA, 2015).

57

Según (Ali Reza Sharafat, 2011) nos muestra la Ingeniería de Tráfico (MPLS-TE) y Redes Privadas Virtuales basada en (MPLS VPN) utilizando OpenFlow y NOX. La manifestación es el resultado de un experimento de ingeniería que responde a las siguientes preguntas: ¿Es difícil de implementar un plano de control complejo en la parte superior de un controlador de red tales como NOX? ¿El punto de vista global en NOX hace la aplicación más fácil que el método tradicional de su aplicación en cada Switch, incrustado en el plano de datos? Implementaron cada característica importante de MPLS-TE y MPLSVPN en tan sólo 2.000 líneas de código, en comparación con líneas mucho más grandes de código en el enfoque más tradicional, como Quagga-MPLS. Debido a que NOX mantiene un mapa coherente de topología actualizada, las características del plano de control MPLS son bastante simples de implementar. Y su simplicidad hace que sea fácil de extender: Hemos añadido fácilmente varias características nuevas (Ali Reza Sharafat, 2011); algo que un operador de red que podía hacer para personalizar su red para satisfacer las necesidades de sus clientes. La demo consta de dos partes: los servicios MPLS-TE y después MPLS VPN impulsado por una GUI. James Kempf (James Kempf, 2011) nos habla que la conmutación de etiquetas por multiprotocolo (MPLS) es un protocolo ampliamente utilizado en redes de operadores comerciales para reenviar paquetes acompañado por etiquetas de enlace específico en la cabecera del paquete de salida enlaces en lugar mediante el cotejo prefijo más largo del estándar IP. Sin embargo, en las redes existentes, MPLS es implementado por completo en IP Routers, ya que los protocolos del plano de control MPLS como LDP utilizan el enrutamiento IP para configurar la etiqueta en el cambió de caminos, a pesar de que el plano de datos MPLS no requiere enrutamiento IP. OpenFlow 1.0 es una interfaz para el control de una ruta o una caja de conmutación insertando especificaciones de flujo en tabla de flujo de la caja. Mientras OpenFlow 1.0 no soporta MPLS1, basado en etiqueta MPLS el reenvío parece conceptualmente un buen partido con OpenFlow basado en el flujo del paradigma de enrutamiento. A esta nota se describe el diseño y la implementación de una extensión experimental de OpenFlow 1.0 para apoyar MPLS. La extensión permite que un interruptor de OpenFlow sin capacidad de enrutamiento IP sirva para reenviar MPLS en el plano de datos. (James Kempf,

2011). (James Kempf, 2011) También describe la aplicación de una fuente abierta de prototipo Etiqueta MPLS conmutada de router, basado en la plataforma de

58

hardware NetFPGA, utilizando OpenFlow MPLS. El prototipo es capaz del reenvío de paquetes del plano de datos a velocidad de expedición de línea sin reenvío IP, aunque el reenvío IP aún se utiliza en el plano control. Ofrecemos algunas medidas de rendimiento que comparen el prototipo con los Routers de software. Las mediciones indican que el prototipo es un instrumento adecuado para lograr la velocidad de expedición de línea en bancos de pruebas y otras redes experimentales donde la flexibilidad es un atributo clave, como un sustituto para los Routers de software. El Departamento de Ciencias de la Computación e Ingeniería, del Instituto Indio de Tecnología, dice que: Los proveedores de servicios están experimentando un desafío que es causado por el crecimiento explosivo de la demanda de conexiones de alta velocidad a través de redes metropolitanas, regionales y centrales. (Vishal Negi, 2012) Los operadores están bajo presión para aumentar la capacidad de sus redes para cumplir con estos requisitos cada vez mayores. Para mejorar la agilidad del servicio y eficiencia de la red y reducir los costos a lo largo de toda su infraestructura, los proveedores están evaluando maneras de utilizar el transporte de paquetes en todas partes. Carrier Ethernet es un nuevo mecanismo que se propone consolidar la red de transporte óptico de paquetes. Multiprotocol Label Switching-Transporte el Perfil (MPLS-TP) - una variante del Carrier Ethernet ofrece una adición potencialmente importante dentro del conjunto de herramientas de transporte de paquetes. Operaciones, administración y mantenimiento (OAM) la funcionalidad es indispensable para esta nueva norma. Esto ayuda a la creación de servicios y el aseguramiento proporcionando así una extensión de las capacidades de transporte de paquetes dentro de las arquitecturas emergentes de infraestructura de múltiples capas. (Vishal Negi, 2012). En 2014 IEEE Conferencia Internacional sobre Ingeniería de Nube, nos muestra que las Redes definidas por software se ha convertido en una solución prometedora para apoyar las funciones de las red dinámicas y aplicaciones inteligentes a través del desacoplamiento del plano de control de la transmisión de plano de datos. OpenFlow es la primera interfaz de gestión abierta estandarizada de la arquitectura SDN. Pero no es realista simplemente intercambiando las redes convencionales de nueva infraestructura. ¿Cómo integrar OpenFlow con las redes existentes? sigue siendo un serio desafío. Xiaogang Tu y su equipo nos proponen un mecanismo de túnel de empalme para red heterogénea con MPLS y Routers OpenFlow. Sugirieron dos mecanismos fundamentales: primero, resumen de los dispositivos de red subyacentes en nodos uniformados con el fin de proteger los detalles de varios equipos; segundo, despojar la manipulación de la tabla de flujo y la tabla de etiqueta del controlador y realizar en un módulo independiente. Este nuevo paradigma se ha desarrollado en el sistema Linux y pruebas se han llevado a cabo en las redes de experimentación. (Xiaogang Tu, 2014).

59

3.6 DESARROLLO DE LA EMULACION DE MPLS MEDIANTE UN EMULADOR DE REDES DEFINIDAS POR SOFTWARE

La siguiente sección tiene como objetivo realizar la emulación de MPLS en dos topologías de prueba distintas topologías SDN seleccionadas como prueba, que permita evidenciar el funcionamiento de la red con el protocolo MPLS y sin el protocolo MPLS, para ello se utilizara la herramienta Mininet la cual es un emulador de redes SDN, sumado al controlador Floodlight y el protocolo OpenFlow 1.3 ambos por tener soporte para el protocolo MPLS como se observó en capítulos anteriores. Se proporciona una explicación de cada una de las instrucciones que permiten la programación de una topología de red en Python (lenguaje en el que trabaja Mininet), así como la secuencia requerida para habilitar los protocolos y funcionalidades requeridas para cada una de las pruebas. 3.6.1 Arquitectura de la topología de prueba 1 sin MPLS En la Figura 15, se muestra el diseño de la topología de red a emular para esta primera prueba, se puede ver claramente una estructura con dos (2) switches y cuatro (4) host interconectados, a su vez los switches están conectados a un controlador nativo de Mininet (Erickson, The Beacon OpenFlow Controller, 2011), al llegar un paquete a los switches estos los trasmiten a los dispositivos finales, esta topología inicial se diseña para conocer el funcionamiento de la red y su estructura básica.

FIGURA 15. Topología de red prueba 1 .

Imagen diseñada en miniedit de Mininet y Paint, “Elaboración propia”

60

3.6.2 Topología de la emulación prueba 1 diseñada en Python El código para esta topología de red esta implementado en Python, en este caso se utilizara un editor de Python el cual ya viene incluido con el sistema operativo Ubuntu 14.04 el cual se utiliza en este proyecto, gedit es el editor de texto libre oficial del escritorio GNOME. Este editor se caracteriza principalmente por su facilidad de uso, además permite trabajar programación en Python esto es algo muy importante ya que las SDN se desarrollan en este código, en Mininet se puede exportar un API de Python para crear redes personalizadas con pocas líneas de código, en la Figura 16A y 17B, podemos observar el código utilizado para esta topología, primero se diseñó una topología sin la utilización del protocolo MPLS para realizar una prueba de conectividad inicial.

FIGURA 16-A, Código Python Topología de red prueba 1.

“Elaboración propia”

61

FIGURA 17-B, Código Python Topología de red prueba 1.

“Elaboración propia”

En el código presentado se muestra lo siguiente: se tienen cuatro (4) host y dos 2 switches. Los host están repartidos por cada Switch en la red, el Switch 1 (s1) tiene conectado los host (h1, h2) y el Switch 2 (s2) tiene conectado los host (h3, h4). Lo primero en el código es importar las librerías de Mininet para usar el API, seguidamente definimos una topología, es decir, instanciamos un objeto “Mininet” como se muestra en el código. Luego creamos los nodos, todos los host y los switches, después agregamos las relaciones entre ellos y finalmente inicializamos todos los dispositivos. Al terminar de programar toda la topología de red esta debe ser guardada en la carpeta custom de Mininet, donde se llamará posteriormente a la topología para trabajar con ella. (Mininet Team, 2015). Al ejecutar el archivo prueba1.py en Mininet, se crea en la máquina virtual las interfaces virtuales y al mismo tiempo se compila el código de la emulación que hemos desarrollado, en la Figura 18 se muestra como se realiza el llamado de la topología con el comando de Mininet, se puede apreciar cómo se añaden y activan todos los dispositivos incluyendo el controlador por defecto de Mininet. (Mininet-

GitHub, 2015).

62

FIGURA 18. Llamado en Mininet del código Python.

Captura de pantalla terminal Mininet

“Elaboración propia”

De esta manera podemos interactuar con la red, utilizando los comandos que Mininet posee para observar el comportamiento de la red. 3.6.3 Pruebas de conectividad con los host y Switch Mininet posee un variedad de comandos los cuales permiten interactuar fácilmente con la topología de red y verificar su comportamiento ya que MiniNet incluye una interfaz de línea de comandos (CLI) que puede ser llamada en una red, y ofrece una variedad de comandos útiles, así como la capacidad de mostrar ventanas xterm y ejecutar comandos en nodos individuales en la red. (Mininet-Wiki, 2015).

63

FIGURA 19. Verificación de conectividad de red

Captura de pantalla terminal Mininet , “Elaboración propia”

En la Figura 19, vemos la utilización de la línea de comandos (CLI), en este caso utilizando el comando pingall para verificar la conectividad de la red. Como se observa hubo respuesta entre todos los dispositivos sin pérdida de paquetes, 12 paquetes enviados por la red 12 paquetes recibidos.

FIGURA 20. Verificación de conectividad entre h1 y h4.

Captura de pantalla terminal Mininet , “Elaboración propia”

En la Figura 20, se observa la utilización de otro comando de Mininet, en este caso utilizamos ping –c este permite hacer ping entre los dispositivos de la red, la manera de uso en este ejemplo seria: h1 ping-c 5 h4. El host 1 está haciendo ping al host 4, le está enviando cinco (5) mensajes, la cantidad de mensajes puede ser

64

configurada indicando el número de mensajes después del comando ping –c igual que la prueba anterior este tiene respuesta sin pérdida de paquetes.

FIGURA 21. Verificación de los nodos de la red.

Captura de pantalla terminal Mininet , “Elaboración propia”

Otros comando muy utilizados en Mininet son los siguientes: Para verificar los nodos de la red podemos utilizar el comando nodes tal como se muestra en la Figura 21, nos indica cuales nodos están activos en la topología actual, si lo que necesitamos es ver los enlaces que tiene la red, utilizamos el comando net tal como se muestra en la Figura 22, podemos observar cómo están conectados los host a los switches y los puestos de enlace.

FIGURA 22. Enlaces que tiene la red topología de red 1 .

Captura de pantalla terminal Mininet , “Elaboración propia”

Por último, veremos otro comando muy útil en Mininet, este es dump este comando permite ver la información de todos los nodos como se aprecia en la Figura 23.

65

FIGURA 23. Verificar la información de los nodos de la red 1.

Captura de pantalla terminal Mininet , “Elaboración propia”

3.7 FUNCIONAMIENTO DE MPLS EN TOPOLOGÍA DE PRUEBA 1 Para ver el funcionamiento de la arquitectura MPLS, inicialmente se seleccionó una topología de red sencilla en la cual se pueda ver el etiquetado MPLS en cada Switch, el acceso a esta red es a través de los switches que cumplen la función de un router programándolos manualmente para que puedan realizar el etiquetado de paquetes que pasan por estos, cada vez que un paquete ingresa a un Switch añade la etiqueta MPLS y en la salida del paquete en los extremos se quita esta y envía el paquete a su destino. Cuando un paquete llega a un Switch de borde que no tiene definida una regla de flujo el Switch solicita instrucciones del controlador. El controlador determinara entonces el camino para este paquete y de todos los paquetes que lleguen de cuál será su ruta, pero en la arquitectura de red utilizada, estos flujos de datos son programados manualmente desde un terminal xterm llamado por el comando de Mininet para tener un control sobre el enrutamiento. La topología vista en el punto 3.6.1, se creó inicialmente para verificar su funcionamiento sin etiquetado MPLS, en esta sección veremos esta misma topología activando el controlador y protocolos necesarios para el uso de MPLS en la red, en la Figura 24, podemos observar la topología a utilizar en esta prueba, tenemos un controlador que funciona con Floodlight y este a su vez conectado a dos switches que utilizan OpenFlow 1.3 y en los extremos tenemos dos host por cada Switch.

66

FIGURA 24. Topología de prueba 1 configurada con Floodlight y OpenFlow 1.3.

Imagen diseñada en miniedit de Mininet y Paint, “Elaboración propia”

3.7.1 Importancia del controlador Floodlight para la topología de prueba 1 Floodlight es un controlador de redes SDN que constantemente se actualiza para dar mayor soporte a estas redes y es apoyado por la comunidad de desarrolladores más grande del mundo para los controladores SDN. Fue diseñado en 2012 para ser de fácil configuración y sin altos requisitos del sistema. Por soportar una amplia gama de switches virtuales basados en hipervisor como Open vSwitch (OVS) y ofsoftswitch, lo hace ideal para trabajar con nuestro proyecto, además Floodlight actualmente está en su versión 1.1 y tiene soporte completo para el protocolo OpenFlow 1.0 y 1.3 el cual es utilizado en las pruebas ya que MPLS funciona sobre el protocolo OpenFlow 1.3. (Izard, 2015).

67

3.7.1.1 Activación del controlador Floodlight en Mininet Cuando se utiliza el controlador Floodlight debemos activarlo antes de realizar el llamado a la topología, ya que esto lleva a que el controlador se posicione en un estado de escucha a la espera de paquetes a través del puerto 6653 como se observa en la Figura 25, así como también activa el protocolo OpenFlow 1.3 y establece el envío de los paquetes LLDP (Protocolo de descubrimiento de capa de enlace) periódicos para descubrir los dispositivos que eventualmente se conecten, además se puede ver la conexión del controlador con OVS, como se muestra en la Figura 26, desde un terminal de Ubuntu 14.04 con el comando $ cd floodlight (se ingresa a la carpeta de Floodlight) y para su activación utilizamos el comando $ java -jar target/floodlight.jar. Por defecto, Floodlight tiene activado los módulos LearningSwitch y Forwading que le permiten al Switch reenviar los paquetes entre origen y destino. (Izard, 2015).

FIGURA 25. Floodlight en modo escucha puerto 6653.

Captura de pantalla terminal Mininet , “Elaboración propia”

68

FIGURA 26. Mensajes generados por Floodlight.

Captura de pantalla terminal Mininet , “Elaboración propia”

69

3.7.2 Importancia de OpenFlow 1.3 para la topología de prueba 1 OpenFlow es el protocolo encargado de la comunicación entre el plano de control y de datos, maneja el concepto de flujos que proporciona el camino a los paquetes a través de los switches de la red; este camino está determinado por el conjunto estandarizado de instrucciones o reglas en el software del controlador SDN. En caso de no existir una regla para enrutar un paquete de datos, el dispositivo de red consulta al controlador para obtener una que se aplique a dicho tráfico, dando como resultado una modificación de las tablas de control de los dispositivos de red. El controlador maneja el protocolo OpenFlow y es mediante éste con el cual se comunica con los otros equipos. El protocolo OpenFlow indica al tráfico como fluir por la red; Las reglas son definidas para cada flujo, con lo que se mantiene un control más exhaustivo de la red. (CPqD, 2015). Los siguientes componentes están disponibles en OpenFlow 1.3:

Ofdatapath: implementación de Switch

Ofprotocol: canal seguro para conectar el Switch al controlador

Oflib: una biblioteca para la conversión a formato 1.3

Dpctl: una herramienta para configurar el Switch de la consola

Soporte: MPLS Labels Para la captura de tráfico se utiliza la herramienta Wireshark la cual se llama mediante el comando $ sudo wireshark en Mininet el cual se activa, en la Figura 27 se observa la captura de tráfico donde OpenFlow 1.3 se encuentra activo; y que desde el controlador funciona sin problema.

70

FIGURA 27. Captura con Wireshark del protocolo OpenFlow 1.3.

“Elaboración propia”

3.7.3 Topología de prueba 1 con MPLS diseñada en Python En el punto 3.6.2, se observó cómo crear una topología de red en Python, en este punto utilizaremos el mismo código de la topología de red prueba 1, realizando una adición de los protocolos a utilizar y realizando el llamado al controlador, tal como se observa en la Figura 28, como se explicó anteriormente esta topología fue programada en Python, lo cual nos permite modificar fácilmente el código para la siguiente prueba.

71

FIGURA 28. Código Python de la topología de red prueba 1 para utilizar MPLS.

“Elaboración propia”

En el código que se muestra vemos lo siguiente: se tienen cuatro (4) host y dos 2 switches. Los host están repartidos por cada Switch en la red, el Switch 1 (s1) tiene conectado los host (h1, h2) y el Switch 2 (s2) tiene conectado los host (h3, h4). Lo primero en el código es importar las librerías de Mininet para usar el API, seguidamente definimos una topología, es decir, instanciamos un objeto “Mininet” como se muestra en el código. Luego creamos los nodos, todos los host, al crear los switches se añade el protocolo a utilizar en este caso OpenFlow 1.3 y al crear el controlador se le añade la IP donde estará activo para este ejemplo la IP 127.0.0.1 y la puerta de enlace, después agregamos las relaciones entre ellos y

72

finalmente inicializamos todos los dispositivos. Al terminar de programar toda la topología de red esta debe ser guardada en la carpeta custom de Mininet, donde se llamará posteriormente a la topología para trabajar con ella. (Mininet-Wiki, 2015). Al ejecutar el archivo topoprueba1.py en Mininet, se crea en la máquina virtual las interfaces virtuales y al mismo tiempo se compila el código de la emulación que hemos desarrollado, en la Figura 29 se muestra como se realiza el llamado de la topología con el comando de Mininet, aquí se debe también llamar al controlador remoto previamente activado y añadir el puerto de escucha, el Switch a utilizar y los protocolos que se emplearan, en este caso se llama a OpenFlow 1.3 y MPLS con esto nos aseguramos que se activen para realizar la prueba, se puede apreciar cómo se añaden y activan todos los dispositivos. (Mininet-GitHub, 2015).

FIGURA 29. Llamado en Mininet del código Python de la topología de prueba 1 MPLS.

Captura de pantalla terminal Mininet , “Elaboración propia”

73

3.7.4 Asignación manual de flujo y etiquetado MPLS En el escenario presentado de la topología de prueba 1, se realiza manualmente la asignación del flujo de datos, para ello se llama un xterm desde Mininet con el comando $ xterm s1 para añadir desde el Switch 1 el comportamiento del flujo y etiquetado MPLS tal como se muestra en la Figura 30.

FIGURA 30. Asignación manual de Flujo MPLS en los Switches.

Captura de pantalla xterm, “Elaboración propia”

El comando # ovs-vsctl set bridge s1 protocols=[“OpenFlow13”], nos permite verificar que el protocolo OpenFlow 1.3 este activo y funcione en el Switch, además permite que el bridge esté funcionando correctamente con el protocolo.

74

El comando # set-fail-mode bridge standalone permite que si el controlador falla, el flujo de información continúe en cuyo caso OVS se encargará de enviar los paquetes.

El comando # ovs-vsctl set bridge s1 datapath_type=netdev crear un puente entre los switches, como se puede observar en la Figura 30. (Pica8 Inc.,

2015) ovs-ofctl: es una herramienta de línea de comandos para la supervisión y administración de switches OpenFlow. También puede mostrar el estado actual de un interruptor de OpenFlow, incluyendo características, configuración y entradas de la tabla. Se puede trabajar con cualquier interruptor de OpenFlow, no sólo Open vSwitch. Add-flow: es un comando que permite añadir flujo dentro de un switch Para realizar el etiquetado MPLS del flujo que pasa por los switches utilizaremos los siguientes comandos:

ovs-ofctl add-flow <bridge>,in_port=<port>,actions=push_mpls: <ethertype>,set_field:<value>-\>mpls_label,output:<port>

Con la siguiente línea de código añadimos la etiqueta MPLS al flujo en el Switch 1 puerto entrante 1 al puerto de salida 3: ovs-ofctl –O OpenFlow13 add-flow s1 in_port=1,ip,actions=push_mpls:0x8847,

set_field:11-\>mpls_label,output:3 Para quitar la etiqueta MPLS del flujo que pasa por los switches al host destino utilizaremos los siguientes comandos:

ovs-ofctl add-flow <bridge> in_port=<port>, dl_type=<ethertype>,mpls_label=

<label>actions=pop_mpls:<ethertype>,output:<port> Con la siguiente línea de código quitamos la etiqueta MPLS al flujo en el Switch 2 puerto entrante 3 al puerto de salida 1: ovs-ofctl –O OpenFlow13 add-flow s2 in_port=3,dl_type=0x8847,mpls_label=11,

actions=pop_mpls=0x0800,output:1

75

Para verificar las interfaces si se asoció al bridge virtual (s1) se comprueba la creación del bridge s1 con sus respectivos puertos donde deben estar incluidas las interfaces respectivas, como se muestra en la Figura 31, para ello se emplea el comando # ovs-vsctl show se observa a Open vSwitch con la ruta hacia el controlador IP 127.0.0.1 puerto 6653. (Pica8 Inc., 2015).

FIGURA 31. Resultados de ovs-vsctl show.

Captura de pantalla xterm, “Elaboración propia”

76

En la Figura 32, se puede apreciar el etiquetado MPLS que se le da a cada paquete que pasa por el Switch 1, para este caso el host 1 envía un paquete, al llegar al Switch 1 este le asigna la etiqueta 11 y lo envía al siguiente salto el cual es el Switch 2, cuando este llega el Switch 2 quita la etiqueta y envía el paquete sin MPLS al host 3 destino. Para este ejemplo se realizó un ping de host 1 a host 3, la repuesta al ping de host 3 fue el siguiente: host 3 envía un paquete, cuando llega al Switch 2 este le asigna la etiqueta 33 y lo envía al siguiente salto el cual es el Switch 1 este quita la etiqueta y envía el paquete sin MPLS al host 1.

FIGURA 32. Envío de paquetes por la red MPLS h1 – h3.

Imagen diseñada en miniedit de Mininet y Paint , “Elaboración propia”

En la siguiente Figura 33, podemos observar como es el paso de un paquete y su etiquetado en la misma topología de prueba 1, para este caso el host 2 envía un paquete, al llegar al Switch 1 este le asigna la etiqueta 22 y lo envía al siguiente salto el cual es el Switch 2, cuando este llega el Switch 2 quita la etiqueta y envía el paquete sin MPLS al host 4 destino; cuando este da respuesta el host 4 envía un paquete, cuando llega al Switch 2 este le asigna la etiqueta 44 y lo envía al siguiente salto el cual es el Switch 1 este quita la etiqueta y envía el paquete sin MPLS al host 2.

77

FIGURA 33. Envío de paquetes por la red MPLS h2 – h4.

Imagen diseñada en miniedit de Mininet y Paint , “Elaboración propia”

En la siguiente tabla 2, se puede observar la asignación de etiquetas en los switches y la llegada a cada interfaz, también la acción que el Switch realiza al paquete. Tabla 2. Asignación de etiquetas en los switches.

La tabla presentada permite ver de una forma más ordenas el flujo que pasa por la red, programado en el numeral 3.7.4. Elaboración propia

78

3.7.4.1 Captura de tráfico en Wireshark topología de prueba 1

Como se vio en el numeral 3.7.2 se utiliza la herramienta Wireshark para ver el tráfico de la red, para este ejemplo lo activaremos para verificar el comportamiento de MPLS en la topología de prueba 1. En la figura 34 y 35, se observa como es el etiquetado MPLS de un paquete al pasar por un Switch, como se explicó anteriormente se envía un ping entre host 1 host 3.

FIGURA 34. Captura de tráfico con protocolo MPLS y Wireshark host 1 – host 3.

“Elaboración propia”

79

FIGURA 35. Captura de trafico Wireshark entre host 3 – host 1.

“Elaboración propia”

3.7.4.2 Verificación del flujo de datos con Floodlight Floodlight tiene una interfaz web sencilla incorporada. La cual permite ver qué nodos están conectados al Switch y que reglas se encuentran activas en los mismos. Para acceder a esto abrimos el navegador web e ingresamos la URL de Floodlight http://localhost:8080/ui/index.html, La interfaz gráfica de usuario tiene una herramienta en la cual se muestra la topología actual como se observa en la Figura 36, en la parte superior se puede ver que mostrará los switches y los hosts, además se puede percibir el tráfico que se envía a través de la red, en la Figura 37 se puede ver que la versión OpenFlow que se está utilizando es la 1.3 en este caso del Switch 1. Floodlight nos permite tener una mejor idea sobre cómo se transmite el tráfico en la realidad, en la Figura 38 se puede observar la ventana principal de Floodlight web.

80

FIGURA 36. Topología actual de red vista desde Floodlight Web.

Captura de pantalla del navegador web, “Elaboración propia”

FIGURA 37. Floodlight web versión de OpenFlow 1.3 utilizada en Switch 1.

Captura de pantalla del navegador web , “Elaboración propia”

81

FIGURA 38. Página principal de Floodlight.

Captura de pantalla del navegador web , “Elaboración propia”

3.7.4.3 Verificación de MPLS en Floodlight web Como se observó en el numeral 3.7.4.1 con respecto a la captura de tráfico a través de Wireshark, Floodlight también permite ver ese flujo de paquetes y el etiquetado MPLS, en la Figura 39 se aprecia que en este caso en el Switch 1 se puede ver la acción que se le aplicó al paquete al pasar por la puerta 1, donde al llegar con el protocolo IP al Switch 1 este le agrega la etiqueta 11 para enviarlo por la puerta de salida 3. Aquí se puedes observar todo el flujo de la red que pasa por el Switch 1 de extremo a extremo. También en la Figura 40, se observa el etiquetado MPLS del paquete enviado del host 3 al host 1, donde se le asigna la etiqueta 33.

82

FIGURA 39. Verificación de Floodlight web en la asignación de etiqueta MPLS Switch 1.

Captura de pantalla del navegador web , “Elaboración propia”

FIGURA 40. Verificación de Floodlight web en la asignación de etiqueta MPLS Switch 2.

Captura de pantalla del navegador web , “Elaboración propia”

83

3.8 ARQUITECTURA DE LA TOPOLOGIA DE PRUEBA 2 SIN MPLS

En la Figura 41, se muestra el diseño de la topología de red a emular para esta segunda prueba, se puede ver claramente una estructura con tres (3) switches y doce (12) host interconectados, a su vez los switches están conectados a un controlador nativo de Mininet (Erickson, The Beacon OpenFlow Controller, 2011), al llegar un paquete a los switches estos los trasmiten a los dispositivos finales, esta topología se diseña para conocer el funcionamiento de la red y su estructura básica.

FIGURA 41. Topología de red prueba 2.

Imagen disenada en miniedit de Mininet y Paint, “Elaboración propia”

3.8.1 Topología de la emulación prueba 2 diseñada en Python El código para esta topología de red esta implementado en Python, como se evidencio en el numeral 3.6.2, en la Figura 42-A, 43-B y 44-C, podemos observar el código utilizado para esta topología, primero se diseñó una topología sin la utilización del protocolo MPLS para realizar una prueba de conectividad inicial.

84

FIGURA 42-A. Topología en Python prueba 2 sin MPLS.

“Elaboración propia”

FIGURA 43-B. Topología en Python prueba 2 sin MPLS.

“Elaboración propia”

85

FIGURA 44-C. Topología en Python prueba 2 sin MPLS.

“Elaboración propia”

En el código presentado se muestra lo siguiente: se tienen doce (12) host y tres 3 switches. Los host están repartidos por cada Switch en la red, el Switch 10 (s10) tiene conectado los host (h1, h2, h3, h4), el Switch 20 (s20) tiene conectado los host (h12, h13, h14, h15) y el Switch 30 (s30) tiene conectado los host (h24, h25, h26, h27). Lo primero en el código es importar las librerías de Mininet para usar el API, seguidamente definimos una topología, es decir, instanciamos un objeto “Mininet” como se muestra en el código. Luego creamos los nodos, todos los host y los switches, después agregamos las relaciones entre ellos y finalmente inicializamos todos los dispositivos. Al terminar de programar toda la topología de red esta debe ser guardada en la carpeta custom de Mininet, donde se llamará posteriormente a la topología para trabajar con ella. (Mininet-Wiki, 2015) Al ejecutar el archivo topoh12h3s.py en Mininet, se crea en la máquina virtual las interfaces virtuales y al mismo tiempo se compila el código de la emulación que hemos desarrollado, en la Figura 45 se muestra como se realiza el llamado de la topología con el comando de Mininet, se puede apreciar cómo se añaden y activan todos los dispositivos. (Mininet-GitHub, 2015).

FIGURA 45. Llamado en Mininet del código Python topología de prueba 2.

Captura de pantalla terminal Mininet , “Elaboración propia”

86

De esta manera podemos interactuar con la topología de red 2, utilizando los comandos que Mininet posee para observar el comportamiento de la red. 3.8.2 Pruebas de conectividad topología de red 2 Tal como se vio en el numeral 3.6.3 Mininet posee una variedad de comandos los cuales permiten interactuar fácilmente con la topología de red y verificar su comportamiento. (Mininet-Wiki, 2015).

FIGURA 46. Verificación de conectividad de red con el comando pingall.

Captura de pantalla terminal Mininet , “Elaboración propia”

En la Figura 46, vemos la utilización de la línea de comandos (CLI), en este caso utilizando el comando pingall para verificar la conectividad de la red. Como se observa hubo respuesta entre todos los dispositivos sin pérdida de paquetes, 132 paquetes enviados por la red 132 paquetes recibidos.

87

FIGURA 47. Verificación de conectividad ent re h1 y h27.

Captura de pantalla terminal Mininet , “Elaboración propia”

En la Figura 47, se observa el ping utilizado: h1 ping-c 5 h27. El host 1 está haciendo ping al host 27, le está enviando cinco (5) mensajes, la cantidad de mensajes puede ser configurada indicando el número de mensajes después del comando ping –c igual que la prueba anterior este tiene respuesta sin pérdida de paquetes. 3.9 ARQUITECTURA DE LA TOPOLOGIA DE PRUEBA 2 CON MPLS Para la segunda prueba del funcionamiento de la arquitectura MPLS, se seleccionó una topología con 3 switches y 12 host, para realizar el etiquetado MPLS en cada Switch y validar su funcionamiento en la red SDN, como fue mencionado anteriormente el acceso a esta red es a través de los switches que cumplen la función de un router programándolos manualmente para que puedan realizar el etiquetado MPLS. Cuando un paquete llega a un Switch de borde que no tiene definida una regla de flujo el Switch solicita instrucciones del controlador. El controlador determinara entonces el camino para este paquete y de todos los paquetes que lleguen cuál será su ruta, pero en la arquitectura de red utilizada, estos flujos de datos son programados manualmente desde un terminal externo para tener un control sobre el enrutamiento.

88

En la Figura 48 podemos observar la topología a utilizar en esta prueba 2, tenemos un controlador que funciona con Floodlight y este a su vez conectado a dos switches que utilizan OpenFlow 1.3, y en los extremos tenemos doce host.

FIGURA 48. Topología de red prueba 2 con MPLS.

Imagen diseñada en miniedit de Mininet y Paint , “Elaboración propia”

3.9.1 Topología de red prueba 2 diseñada en Python Como ya se ha mencionado anteriormente Mininet puede exportar un API de Python para crear redes personalizadas pero en este caso se utilizará el editor de Python Gedit, en la Figura 49-A, 50-B, 51-C, podemos observar el código utilizado para esta.

89

FIGURA 49-A. Topología en Python prueba 2 con MPLS.

“Elaboración propia”

FIGURA 50-B, Topología en Python prueba 2 con MPLS.

“Elaboración propia”

90

FIGURA 51-C. Topología en Python prueba 2 con MPL S.

“Elaboración propia”

En el código presentado se muestra lo siguiente: se tienen doce (12) host y tres 3 switches. Los host están repartidos por cada Switch en la red, el Switch 10 (s10) tiene conectado los host (h1, h2, h3, h4), el Switch 20 (s20) tiene conectado los host (h12, h13, h14, h15) y el Switch 30 (s30) tiene conectado los host (h24, h25, h26, h27). Lo primero en el código es importar las librerías de Mininet para usar el API, seguidamente definimos una topología, es decir, instanciamos un objeto “Mininet” como se muestra en el código. Luego creamos los nodos, todos los host y los switches se añade el protocolo a utilizar en este caso OpenFlow 1.3 y al crear el controlador se le añade la IP donde estará activo para este ejemplo la IP 127.0.0.1 y la puerta de enlace, después agregamos las relaciones entre ellos y finalmente inicializamos todos los dispositivos. Al terminar de programar toda la topología de red esta debe ser guardada en la carpeta custom de Mininet, donde se llamará posteriormente a la topología para trabajar con ella. (Mininet-Wiki, 2015) Al ejecutar el archivo topoh12h3s.py en Mininet, se crea en la máquina virtual las interfaces virtuales y al mismo tiempo se compila el código de la emulación que hemos desarrollado, en la Figura 52 se muestra como se realiza el llamado de la topología con el comando de Mininet, aquí se debe también llamar al controlador remoto previamente activado y añadir el puerto de escucha, el Switch a utilizar y los protocolos que se emplearan, en este caso se llama a OpenFlow 1.3 y MPLS con esto nos aseguramos que se activen para realizar la prueba, se puede apreciar cómo se añaden y activan todos los dispositivos. (Mininet-GitHub, 2015).

91

FIGURA 52. Llamado de la topología personalizada de prueba 2 y pingall de conectividad.

Captura de pantalla terminal Mininet , “Elaboración propia”

En la Figura 52 podemos observar cómo se llama la topología personalizada en Mininet tal como se vio en el numeral 3.7.1.1, inicialmente debe realizarse un llamado al controlador remoto el cual vamos a utilizar, en un terminal con el comando $ cd floodlight (se ingresa a la carpeta de Floodlight) y para su activación utilizamos el comando $ java -jar target/floodlight.jar, esto lleva a que el controlador se posicione en un estado de escucha a través de los puerto 6653, que para este caso está en la IP : 127.0.0.1 y el puerto 6653 que utiliza Floodlight, importante realizar también el llamado a los protocolos OpenFlow13 y MPLS para que estos estén funcionando con nuestra topología tal y como se muestra en la figura, aquí también realizamos un pingall para verificar la conectividad entre los dispositivos se verifica que no hay perdida de paquetes.

92

3.9.2 Funcionamiento de MPLS en topología de prueba 2 Como se mencionó en el numeral anterior en primer lugar activamos el controlador Floodlight desde un terminal de Ubuntu 14.04 como se muestra en la Figura 53.

FIGURA 53. Activación controlador Floodlight en Mininet.

Captura de pantalla terminal Mininet , “Elaboración propia”

Como se observa en la Figura 54-A y 55-B, se activa el protocolo OpenFlow 1.3 y establece el envío de los paquetes LLDP (Protocolo de descubrimiento de capa de enlace) periódicos para descubrir los dispositivos que eventualmente se conecten, además se puede ver la conexión del controlador con OVS.

FIGURA 54-A. Mensajes generados por Floodlight.

Captura de pantalla terminal Mininet , “Elaboración propia”

93

FIGURA 55-B. Mensajes generados por Floodlight.

Captura de pantalla terminal Mininet , “Elaboración propia”

3.9.2.1 Asignación manual de flujo y etiquetado MPLS en la topología de prueba 2 En el escenario presentado de la topología de prueba 2 se realiza manualmente la asignación de flujo, para ello se llama un xterm desde Mininet con el comando $ xterm s10 para añadir desde el Switch 10 el comportamiento del flujo y etiquetado MPLS tal como se muestra en la Figura 56-A, 57-B.

94

FIGURA 56-A. Asignación manual de Flujo MPLS en los switches.

Captura de pantalla xterm, “Elaboración propia”

95

FIGURA 57-B. Asignación manual de Flujo MPLS en los switches de red 2.

Captura de pantalla xterm, “Elaboración propia”

Tal como se vio en el numeral 3.7.4, en cada Switch verificamos que el protocolo OpenFlow13 este activo para ello utilizamos el comando # ovs-vsctl set bridge s10 protocols=[“OpenFlow13”] esto permite que el bridge esté funcionando correctamente con el protocolo, después de esto utilizamos el comando # set-fail-mode bridge standalone este permite que si el controlador falla el flujo de información continúe; con el comando # ovs-vstl set bridge s10 datapath_type=netdev crear un puente entre los switches, como se puede observar en la Figura 56-A. Podemos verificar la configura de los switches desde un xterm de Ubuntu 14.04 con el comando # sudo ovs-vsctl show, cada Switch está conectado al controlador Floodlight que se encuentra en la IP 127.0.0.1 puerto 6653 y las conexiones de los switches con los host los cuales fueron añadidos manualmente. En la Figura 58, se puede apreciar el etiquetado MPLS que se le da a cada paquete que pasa por el Switch 10 luego por el Switch 20, para este caso el host 1 envía un paquete, al llegar al Switch 10 este le asigna la etiqueta 101 y lo envía al siguiente salto el cual es el Switch 20, este le quita la etiqueta 101 y le asigna una nueva etiqueta en este caso la 20, este es enviado por la red al siguiente salto que

96

101

20

20

301

201

201

es el Switch 30 al llegar el paquete este le quita la etiqueta 20 y envía el paquete sin MPLS al host 24 destino. Para este ejemplo se realizó un ping de host 1 a host 24, la repuesta al ping de host 24 fue el siguiente: host 24 envía un paquete, cuando llega al Switch 30 este le asigna la etiqueta 301 y lo envía al siguiente salto el cual es el Switch 20, este le quita la etiqueta 301 y le asigna una nueva que es la 201, por ultimo este paquete llega al Switch 10 donde se le retira la etiqueta y se envía el paquete sin MPLS al host 1.

FIGURA 58. Envío de paquetes por la red MPLS h1 – h24 cambio de MPLS.

Imagen diseñada en miniedit de Mininet y Paint , “Elaboración propia”

En la siguiente Figura 59, podemos observar como es el paso de un paquete y su etiquetado en la misma topología de prueba 2, para este caso el host 4 envía un paquete, al llegar al Switch 10 este le asigna la etiqueta 404 y lo envía al siguiente salto el cual es el Switch 20, cuando este llega el Switch 20 quita la etiqueta y le asigna una nueva en este caso 206, y se envía por la red MPLS al Switch 30, al llegar este quita la etiqueta y envía el paquete sin MPLS al host 27 destino; cuando este da respuesta el host 4 envía un paquete, cuando llega al Switch 30 este le asigna la etiqueta 403 y lo envía al siguiente salto el cual es el Switch 20, este toma el paquete y le asigna una nueva etiqueta 205 quitando la anterior, luego envía este al último Switch el cual quita la etiqueta y envía el paquete sin MPLS al host 4.

97

404

206

206

403

205

205

FIGURA 59. Envío de paquetes por la red MPLS h4 – h27 cambio de etiquetas MPLS.

Imagen diseñada en miniedit de Mininet y Paint , “Elaboración propia”

En la siguiente tabla 3, se puede observar la asignación de etiquetas en los switches y la llegada a cada interfaz, también la acción que el Switch realiza al paquete. Tabla 3. Asignación de etiquetas en los switches en la topología de prueba 2.

La tabla presentada permite ver de una forma más ordenas el flujo que pasa por la red, programado en el numeral 3.9.2.1, Elaboración propia

98

3.9.2.2 Captura de tráfico en Wireshark topología de prueba 2 Utilizamos la herramienta Wireshark para ver el tráfico de la red, para este ejemplo lo activaremos para verificar el comportamiento de MPLS en la topología de prueba 2, desde un terminal en Ubuntu 14.04 escribimos el comando sudo Wireshark. En las Figuras 60, 61, 62 y 63, se observa como es el etiquetado MPLS de un paquete al pasar por un Switch, como se explicó anteriormente se envía un ping entre host 4 al host 27. FIGURA 60. Captura de trafico Wireshark entre host 27 – host 4, primer salto en Switch 30.

“Elaboración propia”

99

FIGURA 61. Captura de trafico Wireshark entre host 27 – host 4, segundo salto en Switch

20.

“Elaboración propia”

FIGURA 62. Captura de trafico Wireshark entre host 4 – host 27, Respuesta host 4 en Switch

10.

“Elaboración propia”

100

FIGURA 63. Captura de trafico Wireshark entre host 4 – host 27 respuesta host 4 en Switch

20.

“Elaboración propia”

3.9.2.3 Verificación del flujo de datos con Floodlight Floodlight tiene una interfaz web sencilla incorporada. La cual permite ver qué nodos están conectados al Switch y que reglas se encuentran activas en los mismos. Para acceder a esto abrimos el navegador web e ingresamos la URL de Floodlight http://localhost:8080/ui/index.html, La interfaz gráfica de usuario tiene una herramienta en la cual se muestra la topología actual como se observa en la Figura 64, en la parte superior se puede ver que mostrará los switches y los hosts, además se puede percibir el tráfico que se envía a través de la red, en la Figura 65 se puede ver que la versión OpenFlow que se está utilizando es la 1.3 en este caso del Switch 30. Floodlight nos permite tener una mejor idea sobre cómo se transmite el tráfico en la realidad, en la Figura 66 se puede observar la ventana principal de Floodlight web, se puede apreciar todos los módulos que carga Floodlight para trabajar con la red.

101

FIGURA 64. Topología de prueba 2 vista desde Floodlight Web.

Captura de pantalla del navegador web, “Elaboración propia”

FIGURA 65. Floodlight web versión de OpenFlow 1.3 utilizada en Switch 30.

Captura de pantalla del navegador web , “Elaboración propia”

102

FIGURA 66. Página principal de Floodlight topología de prueba 2.

Captura de pantalla del navegador web , “Elaboración propia”

3.9.2.4 Verificación de MPLS en Floodlight web Tal como se captura de tráfico a través de Wireshark, Floodlight también permite ver ese flujo de paquetes y el etiquetado MPLS, en la Figura 67 se aprecia que en este caso en el Switch 10 se puede ver la acción que se le aplico al paquete al pasar por la puerta 1, donde al llegar con el protocolo IP al Switch 10 este le agrega la etiqueta 101 para enviarlo por la puerta de salida 5. Aquí se puedes observar todo el flujo de la red que pasa por el Switch 10 de extremo a extremo. También en la Figura 68, se observa el etiquetado MPLS del paquete enviado del host 27 al host 4, donde se le asigna la etiqueta 403.

103

FIGURA 67. Flujo del Switch 10 etiquetado MPLS.

Captura de pantalla del navegador web , “Elaboración propia”

FIGURA 68. Flujo del Switch 30 etiquetado MPLS respuesta del host 27 al host 4.

Captura de pantalla del navegador web , “Elaboración propia”

104

3.10 ANALISIS DE RESULTADOS La implementación de SDN en un ambiente MPLS puede simplificar considerablemente la complejidad en el plano de control y permitir la incursión de servicios flexibles. Normalmente en las operaciones del plano de control los protocolos como LMP, LDP RSVP-TE, OSPF-TE, RSVP-TE, LMP, MP-BGP y I-BGP, tienen como función la creación de LSP, para la reserva del ancho de banda con ingeniería de tráfico, deben por obligación hacer la búsqueda de disponibilidad de rutas, así como un monitoreo constante de rutas para la distribución de etiquetas a los Routers y la comunicación de los sistemas autónomos. Regularmente la ficha técnica de los Routers deben ser robusto respecto a memoria y carga de CPU, con el fin de que no queden cortos en el cargue de los diferentes protocolos. Los procesos de actualización a nivel de software pueden ser críticos ya que deben de hacerse cada que se presenten mejoramientos de fallas en los diferentes módulos del Router. En la evolución a Redes SDN desaparece el requerimiento de agregación de los protocolos existentes en los Routers. Esta tarea la asume el controlador que específicamente refiriéndonos a nuestro Proyecto es Floodlight, el cual establece las rutas de la red, es decir la interfaz del controlador asume las funciones antes sujetas a los protocolos que albergaban al Router (la implementación de servicio que requiera la red se llevara estableciendo código para el software de aplicación de la interfaz con el protocolo OpenFlow). Es así como el Router reduce su requerimiento técnico de capacidad de cálculo, memoria, CPU y procesos de actualización. En la evaluación del proceso de etiquetado MPLS pudimos observar cómo controlar el flujo de datos y programar la red desde un controlador para SDN, para ello se realizó una configuración manual de etiquetas en los switches, por tanto no se puedo utilizar los protocolos de distribución de etiquetas ni establecimiento de LSPs, el controlador Floodlight utilizado en este proyecto soporta el protocolo LDP, pero no hay suficiente documentación al respecto de su uso además para su utilización se debe desarrollar una API para utilizar desde el controlador lo cual no estaba como alcance del proyecto. El uso de etiquetado hace que se pueda controlar la ruta de envió más fácil que el modo convencional IP, en el enrutamiento IP convencional se hace el enrutamiento distribuido, en cada router se toma la decisión de la conmutación de los paquetes mediante la inspección de la cabecera del paquete y obteniendo la

105

dirección destino. En MPLS ya no es necesario inspeccionar toda la cabecera IP en cada router para obtener la dirección destino y enviar los paquetes esto solo se haría una vez en el router de borde y luego ya se conmutaría los paquetes mediante intercambio de etiquetas. En SDN la determinación de las rutas y control de enrutamiento se hace en forma centralizada desde el controlador y este le indica a los switches o enrutadores como se debe hacer esa conmutación. La pretensión que se tenía en este proyecto era poder evaluar este comportamiento centralizado de MPLS en SDN y compararlo con el enrutamiento convencional, pero fue complicado debido a que aunque el controlador Floodlight soporta protocolos de distribución de etiquetas, no se encontró la forma de hacerlo interactuar automáticamente con MPLS para poder hacer dichas pruebas y no se encontró información al respecto por tanto estas pruebas se dejaron para trabajos futuros que dan continuidad a este estudio. Se pudo hacer una configuración de etiquetas manuales que permitieron apreciar la conmutación de paquetes mediante etiquetas, donde se aprecia un comportamiento en el enrutamiento similar en el trayecto de los paquetes aparentemente, pero internamente el proceso se está haciendo centralizado al usar SDNs. Las ventajas de MPLS en las redes convencionales sugieren un aumento en la velocidad de enrutamiento, se necesitaría en trabajos futuros poder realizar unas pruebas en las que se pueda comprobar los tiempos de enrutamiento de paquetes comparando redes convencionales con SDNs pero teniendo las mismas condiciones de enrutamiento dinámico, usando protocolos de enrutamiento y de distribución de etiquetas. Entre las ventajas teóricas que se encontraron de las posibles ventajas que trae la combinación SDN-MPLS están:

La simplificación del plano de control IP / MPLS que a su vez reduce la carga del protocolo en la CPU del router (una preocupación real en las redes de transporte en los que no todo el hardware se actualiza al mismo tiempo).

Dentro de los beneficios de SDN con MPLS es el de optimizar la función o servicio de red (en oposición a las optimizaciones locales posibles hoy en día) ya que todo está centralizado desde un controlador, ya que al poder programar el flujo de datos y los protocolos a utilizar hace menos dispendioso el trabajo actual de los administradores de red quienes realizan estas labores en cada nodo de la red.

106

En cuanto a las ventaja que tienen los túneles MPLS en redes convencionales, nos encontramos con la reducción de usos de etiquetas y se podría suponer que en las redes MPLS igualmente se tendría la misma ventaja teniendo en cuenta que se usaría también los mismos requisitos establecidos en el estándar MPLS para el uso de etiquetas, en cuanto a lograr verificar las ventajas de los túneles MPLS no se pudo comprobar por las mismas razones expuestas anteriormente con respecto al uso de los protocolos de distribución de etiquetas lo que sugiere el desarrollo de una API, lo que también queda para futuros trabajos.

107

4 CONCLUSIONES

En la ejecución de las pruebas del Proyecto nos encontramos con algunas dificultades importantes por mencionar, para iniciar la herramienta MiniNet es muy sensible a la sintaxis a través del lenguaje de programación Python, debido a esto tuvimos que invertir mucho tiempo en la validación de las instrucciones escritas llevándonos a retrasos en la obtención de resultados.

Cabe destacar que existen pocos emuladores que soporten la tecnología SDN en el mercado, la mayoría son desarrollos académicos como lo son Modelnet, DieCast y Mininet, excepto EstiNet que es de uso comercial. Además, existen sitios de pruebas en línea que han ido incorporando soporte de la tecnología SDN como Emulab. Para este proyecto se eligió el emulador Mininet.

Mininet también presenta desventajas a la hora de trabajar. La capacidad de Mininet de emular redes a gran escala es limitada por los recursos disponibles en la máquina en donde corre. En este sentido, los tiempos dependen de la capacidad de procesamiento del computador, y estos aumentan exponencialmente al aumentar el número de nodos, mientras que el uso de memoria aumenta de forma lineal. Esto limita claramente la escalabilidad que se puede alcanzar con Mininet.

En la ejecución de las pruebas del Proyecto nos encontramos con algunas dificultades importantes por mencionar, para iniciar, la herramienta MiniNet es muy sensible a la sintaxis a través del lenguaje de programación Python, debido a esto tuvimos que invertir mucho tiempo en la validación de las instrucciones escritas llevándonos a retrasos en la obtención de resultados.

Dentro de los beneficios de SDN con MPLS teóricamente encontramos que es el de optimizar la función o servicio de red, ya que todo está centralizado desde un controlador, ya que al poder programar el flujo de datos y los protocolos a utilizar hace menos dispendioso el trabajo actual de los administradores de red quienes realizan estas labores en cada nodo de la red. Mediante una exploración del estado del arte de MPLS se pudo determinar teóricamente las ventajas del proceso de conmutación y apilamiento de etiquetas en redes MPLS.

Por otro lado la documentación respecto a Redes SDN en combinación con

MPLS en las diferentes líneas de información (Sitios Web, Páginas, Libros, Tesis, Trabajo de grado, artículos y juicio de expertos) es hallada de

108

manera muy general respecto a nuestra meta en este proyecto, si es posible apreciar su innovación, arquitectura, funcionamiento, ventajas, proyecciones, de manera individual pero la combinación de ambos conceptos SDN y MPLS es muy limitada lo que nos llevó a trabajar en el principio prueba y error para ir obteniendo resultados.

Este proyecto generó una metodología para configurar y activar MPLS en una red definida por software utilizando el protocolo OpenFlow 1.3 y el controlador Floodlight. Se dieron aportes valiosos para la instalación y utilización del emulador Mininet, el controlador Floodlight, el protocolo OpenFlow 1.3, que puede ser muy útil y servir como apoyo para futuras investigaciones en el tema.

109

ANEXOS

A. Instalación MiniNet con OpenFlow 1.3 Opción uno (1) de instalación MiniNet VM Instalación de máquina virtual es la manera más sencilla de la instalación de MiniNet. En la práctica, la diferencia de velocidad es mínima y la instalación es mucho más simple, puesto que no es necesario volver a compilar el kernell del sistema operativo o remplazar para añadir soporte de red para espacio de nombres. Para realizar una instalación personalizada, se explicara en la siguiente sección o se puede consultar MininetVMCreationNotes ó los archivos README / INSTALL de las fuentes MiniNet. Pasos para una instalación VM:

1. Descargar la imagen de la máquina virtual desde MiniNet, disponible en: https://github.com/mininet/mininet/wiki/Mininet-VM-Images . El archivo tiene un tamaño de 1GB, comprimido.

2. Descargar e instalar el VirtualBox (libre, GPL) para Windows o Linux. Disponible en: https://www.virtualbox.org/wiki/Downloads

3. Se recomienda suscribirse a la lista de correo-MiniNet

https://mailman.stanford.edu/mailman/listinfo/mininet-discuss . Esta fuente ofrece ayuda a investigadores.

4. Ejecutar a través de los MininetVMSetupNotes para iniciar sesión en la

máquina virtual e instalar el código MiniNet en el.

5. Siga el MininetWalkthrough para familiarizarse con los comandos de MiniNet y el uso típico.

110

Opción dos (2) de instalación MiniNet Nativo Esta opción funciona muy bien para VM local EC2 a distancia, y la instalación nativa. Se asume que el punto de partida es desde un nuevo Ubuntu (o, de forma experimental, Fedora). Se recomienda utilizar la versión más reciente de Ubuntu liberada, porque esto apoya a las nuevas versiones de Abrir vSwitch, Fedora también es compatible con las versiones más recientes de MiniNet. Para instalar de forma nativa desde la fuente, en primer lugar se necesita obtener el código fuente:

1. Abrir un nuevo terminal en Ubuntu y luego digitar git clone git://github.com/mininet/mininet

2. Cuando se halla descargado el paquete de instalación procedemos a ejecutar el siguiente comando ./mininet/util/install.sh –a

-a: instala todo lo que se incluye en el MiniNet VM, incluyendo dependencias como Open vSwitch así las adiciones como el Wireshark, OpenFlow y POX.

3. Después de que la instalación se haya completado, probar la funcionalidad básica de MiniNet con el siguiente comando sudo mn --test pingall

111

B. Instalación de Floodlight 1.0 Floodlight está basado en java y corre bajos las herramientas JDK, se debe instalar JDK 1.7 y Ant. Opcionalmente, se puede optar por instalar el eclipse, pero no es obligatorio. Pasos para la instalación:

1. Desde un terminal de Ubuntu 14.04, escribimos los siguiente: sudo apt-get install build-essential default-jdk ant python-dev eclipse

2. Desde el terminal abierto vamos a realizar la descarga, escribimos lo

siguiente: $ git clone git://github.com/floodlight/floodlight.git

3. Una vez terminada la descarga ingrasamos a la carpeta de Floodlight con el siguiente comando: $ cd floodlight

4. Entando dentro de la carpeta escribimos lo siguiente: $ ant

5. Luego escribimos lo siguiente: $ sudo mkdir /var/lib/floodlight

6. Por ultimo escribimos el siguiente comando: $ sudo chmod 777

/var/lib/floodlight En este momento ya tenemos instalado Floodlight para trabajar con el. Floodlight también tiene una máquina virtual pre-configurada con MiniNet, Openvswitch y Floodlight v1.1. la cual se puede usar sin ningún problema se puede descargar de la siguiente página web: https://floodlight.atlassian.net/wiki/display/floodlightcontroller/Floodlight+VM

112

BIBLIOGRAFÍA

A stance on emulation and testbeds, a. a. (2007). folk.uio.no/erek/publications. Retrieved 16 de Septiembre de 2015 from erek/publications: folk.uio.no/erek/publications/07ecms-gokturk-1.02.ps.gz

Alejandro Garcia Centeno, C. M. (Diciembre de 2014). revistatelematica. Retrieved 16 de Noviembre de 2015 from revistatelematica.cujae.edu.cu: http://revistatelematica.cujae.edu.cu/index.php/tele/article/viewFile/164/153 Ali Reza Sharafat, S. D. (2011). MPLS-TE and MPLS VPNs with OpenFlow. Retrieved 18 de Septiembre de 2015 from klamath.stanford.edu: http://klamath.stanford.edu/~nickm/papers/mpls-sigcomm11.pdf Awduche, D. (Diciembre de 2001). Applicability Statement for Extensions to RSVP for LSP-Tunnels . Retrieved 01 de Junio de 2015 from tools.ietf.org: https://tools.ietf.org/html/rfc3210 Azarang M., G. E. (2006). Simulación y análisis de modelos estocásticos. Retrieved 16 de Septiembre de 2015 from Universidad de Mérida: http://www.unamerida.com/archivospdf/337%20Lectura6.3.1.pdf BELLESSA, J. (30 de Abril de 2015). IMPLEMENTING MPLS WITH LABEL SWITCHING IN SOFTWARE-DEFINED NETWORKS. Retrieved 02 de DIciembre de 2015 from assured-cloud-computing.: http://assured-cloud-computing.illinois.edu/files/2015/02/Bellessa_John.pdf

Beuran, R. (2012). Network Emulation 101. In R. Beuran, Introduction to Network Emulation (p. 426). Singapore: Pan Stanford Publishing.

Braden, R. (Septiembre de 1997). Resource ReSerVation Protocol (RSVP). Retrieved 01 de Junio de 2015 from tools.ietf.org: https://tools.ietf.org/html/rfc2205

Canalis, M. S. (2003). Una Arquitectura de Backbone para la Internet del Siglo XXI. Retrieved 05 de Junio de 2015 from exa.unne.edu.ar: http://exa.unne.edu.ar/informatica/SO/libmpls.PDF Canalis, M. S. (2003). Una Arquitectura de Backbone para la Internet del Siglo XXI. Retrieved 16 de Noviembre de 2015 from exa.unne.edu.ar: http://exa.unne.edu.ar/depar/areas/informatica/SistemasOperativos/libmpls.PDF

113

Castaneda, F. G. (Octubre de 2012). ANALISIS DE LA RED DE LA CNT EP PARA LA IMPLEMENTACION DE SERVICIOS INTEGRADOS MEDIANTE TECNOLOGIA MPLS. Retrieved 05 de Junio de 2015 from dspace.unach.edu.ec: http://dspace.unach.edu.ec/bitstream/123456789/340/1/FI-IET-40A019.pdf Chodorek, R. (07 de Febrero de 2015). RSVP Extensions for Dynamic Reservation. Retrieved 01 de Junio de 2015 from datatracker.ietf.org: http://datatracker.ietf.org/doc/draft-chodorek-tsvwg-rsvp-dynamic-resv/?include_text=1 Christian Esteve Rothenberg, M. R. (Junio de 2011). OpenFlow e redes definidas por software: um novo paradigma de controle e inovacao em redes de pacotes. Retrieved 30 de Abril de 2015 from cpqd.com.br: http://www.cpqd.com.br/cadernosdetecnologia/Vol7_N1_jul2010_jun2011/pdf/artigo6.pdf

Cisco Systems, Inc. (Octubre de 2007). LDP Specification. Retrieved 22 de Novuembre de 2015 from tools.ietf.org: https://tools.ietf.org/html/rfc5036

Community Trema. (22 de Mayo de 2015). Full-Stack OpenFlow Framework in Ruby. Retrieved 22 de Mayo de 2015 from github.com: https://github.com/trema/trema

Cornell University. (2015). www.cs.cornell.edu. Retrieved 16 de Septiembre de 2015 from cornell.edu: http://www.cs.cornell.edu/skeshav/real/overview.html

Deepak Kumar, M. S. (2014). Software Defined Networking: A Concept and Related Issues. Retrieved 28 de Noviembre de 2015 from ijana.in: http://www.ijana.in/papers/V6I2-5.pdf Dibildox, L. M. (16 de Mayo de 2006). Protocolo MPLS. Retrieved 22 de Noviembre de 2015 from catarina.udlap.mx: http://catarina.udlap.mx/u_dl_a/tales/documentos/lis/morales_d_l/capitulo2.pdf Dynamics, C. V.-D. (25 de Marzo de 2013). SDN, LA EVOLUCIÓN QUE NECESITABA LA RED. Retrieved 18 de Enero de 2016 from datacenterdynamics.es: http://www.datacenterdynamics.es/focus/archive/2013/03/sdn-la-evolución-que-necesitaba-la-red

E. Rosen, C. S. (Enero de 2001). RFC 3031 MPLS Architecture . Retrieved 18 de Septiembre de 2015 from tools.ietf.org: http://tools.ietf.org/html/rfc3031#section-

114

3.27

Erickson, D. (14 de Mayo de 2015). The Beacon OpenFlow Controller. Retrieved 14 de Mayo de 2015 from yuba.stanford.edu: http://yuba.stanford.edu/~derickso/docs/hotsdn15-erickson.pdf Farrel, B. S. (2008). MPLS: Next Steps, The Morgan Kaufmann Series in Networking (Vol. 1). Burlington, USA: Morgan Kaufmann is an imprint of Elsevier. Farrel, B. S. (2008). MPLS: Next Steps. AMSTERDAM: Morgan Kaufmann Publishers is an imprint of Elsevier.

FELDMAN, A. D. (Enero de 2001). LDP Specification. Retrieved 30 de Mayo de 2015 from Network Working Group: https://www.rfc-editor.org/rfc/rfc3036.txt

gns3. (2007). gns3. Retrieved 16 de Septiembre de 2015 from gns3: http://www.gns3.com/

Guruprasad, S. (2002). An Integrated Experimental Environment for Distributed Systems and Networks. Retrieved 16 de Noviembre de 2015 from cs.cornell.edu: http://www.cs.cornell.edu/People/egs/cornellonly/syslunch/fall02/emulabtr02.pdf Hervás, O. R. (2914). Software Defined Networking. From upcommons.upc.edu: http://upcommons.upc.edu/bitstream/handle/2099.1/21633/Memoria.pdf Jacobs, D. B. (Octubre de 2014). Control de redes: planos dinámicos más simples con MPLS-TP y SDN. Retrieved 22 de Enero de 2016 from searchdatacenter: http://searchdatacenter.techtarget.com/es/cronica/Control-de-redes-planos-dinamicos-mas-simples-con-MPLS-TP-y-SDN James Kempf, S. W. (2011). OpenFlow MPLS and the Open Source Label Switched Router. Retrieved 18 de Septiembre de 2015 from yuba.stanford.edu: http://yuba.stanford.edu/~peyman/docs/ofmpls.pdf Jim Metzler, N. W. (15 de Noviembre de 2012). Explicación técnica: Software Defined Networking (SDN). Retrieved 05 de Abril de 2015 from http://cioperu.pe: http://cioperu.pe/articulo/11606/explicacion-tecnica-software-defined-networking-sdn/ Karamjeet Kaur, J. S. (2014). Mininet as Software Defined Networking Testing Platform. Retrieved 22 de Abril de 2015 from sbsstc.ac.in: http://www.sbsstc.ac.in/icccs2014/Papers/Paper29.pdf

115

Lobo, L. (2005). MPLS Configuration on Cisco IOS Software. (I. Cisco Systems, Ed.) Indianapolis, Indiana, USA: Cisco Press. Millan, R. (2015). MPLS (MultiProtocol Label Switching). Retrieved 30 de Mayo de 2015 from ramonmillan: http://www.ramonmillan.com/tutoriales/mpls.php Mininet Team. (2015). mininet overview. Retrieved 16 de Septiembre de 2015 from mininet.org: http://mininet.org/overview/ Mininet Team. (2015). Mininet Overview. Retrieved 22 de Abril de 2015 from mininet.org: http://mininet.org/overview/ Mininet-GitHub. (2015). GitHub. Retrieved 22 de Enero de 2016 from github.com: https://github.com/mininet/mininet/tree/master/examples Mininet-Wiki. (17 de Diciembre de 2015). Github. Retrieved 22 de Enero de 2016 from Introduction to Mininet: https://github.com/mininet/mininet/wiki/Introduction-to-Mininet#creating NCTUns. (Febrero de 2013). NCTUns 6.0 Network Simulator and Emulator . Retrieved 16 de Septiembre de 2015 from nctu.edu.tw: http://nsl.cs.nctu.edu.tw/NSL/nctuns.html NOX. (24 de Mayo de 2014). About NOX. Retrieved 22 de Mayo de 2015 from noxrepo.org: http://www.noxrepo.org/nox/about-nox/

nsnam. (2011). nsnam.org. Retrieved 16 de Septiembre de 2015 from NS-3: https://www.nsnam.org/overview/what-is-ns-3/

Open Networking Foundation. (13 de Abril de 2012). Software-Defined Networking: The New Norm for Networks. Retrieved 5 de Abril de 2015 from opennetworking.org:https://www.opennetworking.org/images/stories/downloads/sdn-resources/white-papers/wp-sdn-newnorm.pdf OpenDaylight, a Linux Foundation Collaborative Project. (2015). OPENDAYLIGHT “HELIUM” -- THE RISE OF OPEN SDN. Retrieved 22 de Mayo de 2015 from opendaylight.org: http://www.opendaylight.org/software Peralta, R. M. (14 de Mayo de 2015). Emulación de SNDs usando Mininet. Retrieved 14 de Mayo de 2015 from profesores.elo.utfsm.cl: http://www.profesores.elo.utfsm.cl/~agv/elo323/2s14/projects/reports/RodrigoManriquez/RodrigoManriquez.pdf

116

POX. (17 de Diciembre de 2014). About POX. Retrieved 22 de Mayo de 2015 from noxrepo.org: http://www.noxrepo.org/pox/about-pox/

revistatelematica. (Septiembre de 2014). Controladores SDN, elementos para su selección y evalución. Retrieved 14 de Mayo de 2015 from revistatelematica.cujae.edu.cu: http://revistatelematica.cujae.edu.cu/index.php/tele/article/viewFile/164/153 Riverbed Technology. (2015). riverbed. Retrieved 16 de Septiembre de 2015 from OPNET: http://www.riverbed.com/products/steelcentral/opnet.html?redirect=opnet ROMERO, G. (16 de Agosto de 2012). ENRUTAMIENTO OPTIMO EN REDES IP CASO INTRADOMINIO. Retrieved 05 de Junio de 2015 from riuc.bc.uc.edu.ve: http://www.riuc.bc.uc.edu.ve/bitstream/123456789/686/1/gromero.pdf Ryu SDN Framework Community. (22 de Mayo de 2014). COMPONENT-BASED SOFTWARE DEFINED NETWORKING FRAMEWORK Build SDN Agilely. Retrieved 22 de Mayo de 2015 from osrg.github.io: http://osrg.github.io/ryu/ S. Guruprasad, R. R. (2005). Integrated network experimentation using simulation and emulation. Conf. on Testbeds and Research Infrastructures for Development of Networks and Communities. TRIDENT- COM’05. SALVIAT, L. M. (Octubre de 2005). REDES MPLS: FUNDAMENTOS, APLICACION Y GESTION DE RECURSOS. Retrieved 16 de Noviembre de 2015 from cybertesis.uach.cl: http://cybertesis.uach.cl/tesis/uach/2005/bmfcic828r/sources/bmfcic828r.pdf Santamaría, S. R. (26 de Febrero de 2012). Proyecto fin de carrera, universidad de Cantabria: mecanismos de control de las comunicaciones en la internet del futuro a través de OpenFlow. Retrieved 05 de Abril de 2015 from repositorio.unican.es: http://repositorio.unican.es/xmlui/bitstream/handle/10902/1165/Sergio%20Rodriguez%20Santamaria.pdf.txt?sequence=8 sponsored community project. (2015). Floodlight Is an Open SDN Controller. Retrieved 22 de Mayo de 2015 from projectfloodlight.org: http://www.projectfloodlight.org/floodlight/ The Network Simulator ns-2. (Septiembre de 1997). www.isi.edu. Retrieved 16 de Septiembre de 2015 from isi.edu: http://www.isi.edu/nsnam/ns/

117

Vargas, W. A. (14 de Mayo de 2015). Emulación de una red definida por software utilizando MiniNet. Retrieved 14 de Mayo de 2015 from academia.edu: http://www.academia.edu/5730624/Emulación_de_una_red_definida_por_software_utilizando_MiniNet Vishal Negi, U. K. (Enero de 2012). Building an MPLS-TP Simulator. Retrieved 18 de Septiembre de 2015 from researchgate.net: https://www.researchgate.net/profile/Tulika_Pandey/publication/261427536_Building_an_MPLS-TP_simulator/links/5510f20b0cf2a8dd79bf47b7.pdf Xiaogang Tu, X. L. (2014). Splicing MPLS and OpenFlow Tunnels Based on SDN Paradigm. Retrieved 18 de Septiembre de 2015 from infona.pl: https://www.infona.pl/resource/bwmeta1.element.ieee-art-000006903516