Beruflich Dokumente
Kultur Dokumente
Universidad de Extremadura
Centro Universitario de Mrida
Grado en Ingeniera en Telemtica
Resumen
Software-Defined Networking (o Redes Definidas por Software) es un nuevo paradigma que tiene como objetivo simplificar la creacin y gestin de redes de ordenadores. El desacoplamiento entre el control de la red y el plano de reenvo propuesto
por esta arquitectura permite el control de todo el comportamiento de la red mediante un elemento lgico centralizado, llamado controlador. Esta separacin de los
planos abre la puerta a la virtualizacin de redes, proporcionando a los usuarios una
abstraccin lgica de los recursos de red subyacentes.
La iniciativa Open Networking Foundation (ONF), est desarrollando estndares
abiertos que permitan alcanzar los retos planteados por SDN. El resultado es lograr
una arquitectura que permita a los administradores de red tener un control total en
el funcionamiento de la red a travs del despliegue de software que controle y automatice el comportamiento de la misma. La ONF ya ofrece el estndar OpenFlow,
que permite la programacin remota del plano de control. Este es el primer estndar
SDN y un elemento vital de una arquitectura de red definida por software.
En este trabajo analizaremos las SDN y el protocolo OpenFlow y veremos algunas de las diferentes alternativas de controladores para terminar centrndonos en
OpenDaylight. Adems procederemos a desplegar una red de ejemplo mediante la
herramienta Mininet que permite simular un entorno SDN. Despus se ha realizado
un caso prctico para comprobar de forma ms concreta como programar un controlador y en definitiva poder manejar toda la red.
Finalmente se han realizado algunas pruebas con el fin de analizar y mejorar el
rendimiento energtico de una red SDN. Como resultado se obtiene que efectivamente el consumo energtico mejora, aunque en contra, la carga total de la red
aumenta.
Abstract
Lately, the emerging paradigm of Software-Defined Networking has grown in presence and claims to simplify future networking. The decoupling of network control
and forwarding plane proposed by this architecture allows the control of the entire
network behavior by means of a logically centralized software program (controller).
Such separation of planes opens the way to Network Virtualization, which provides
users a logical abstraction of underlying network resources.
Open Networking Foundation (ONF) is a user-driven organization dedicated to
the promotion and adoption of Software-Defined Networking (SDN) through open
standards development. Thus, network administrators, will be able to program and
control the forwarding plane of such networks in a new way.
In this work we analyze the SDN and the OpenFlow protocol and we see some
of the different alternative controllers, and finally, we focus on OpenDaylight. Furthermore we proceed to create a sample network using Mininet to simulate a SDN
environment. Finally a case study is performed to check more specifically how to
program a controller and ultimately to manage the entire network.
Finally, some tests be performed in order to analyze and improve the energy performance of a SDN network. Obtained results show that our proposal improves the
energy consumption, although the network load is increased.
ndice general
1. Introduccin
1.1. Antecedentes
1.2. Objetivos . .
1.3. Planificacin .
1.4. Estructura del
. . . . . . .
. . . . . . .
. . . . . . .
documento
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3. OpenFlow
3.1. Protocolo OpenFlow . . . . . . . . . . .
3.2. Funcionamiento de OpenFlow . . . . . .
3.2.1. Flujos . . . . . . . . . . . . . . .
3.2.2. Tablas de flujos . . . . . . . . . .
3.2.3. Instructions . . . . . . . . . . . .
3.2.4. Counters . . . . . . . . . . . . . .
3.2.5. Mensajes del protocolo OpenFlow
3.2.6. Matching . . . . . . . . . . . . .
3.3. Probando OpenFlow . . . . . . . . . . .
3.3.1. Explicacin terica. . . . . . . . .
4. Software utilizado
4.1. Controladores . . . . . . . . . . . .
4.1.1. OpenDaylight . . . . . . . .
4.1.2. Ryu . . . . . . . . . . . . .
4.1.3. Floodlight . . . . . . . . . .
4.1.4. NOX/POX . . . . . . . . .
4.2. Mininet . . . . . . . . . . . . . . .
4.2.1. Ventajas e inconvenientes de
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
5
6
6
7
.
.
.
.
.
9
9
9
10
10
11
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
13
13
15
15
16
16
17
17
19
20
20
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
Mininet
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
29
29
29
32
32
32
35
35
.
.
.
.
.
.
.
.
.
.
ndice general
4.2.2. vSwitch . . .
4.3. Wireshark . . . . . .
4.4. Iperf . . . . . . . . .
4.5. Eclipse . . . . . . . .
4.5.1. Maven . . . .
4.6. Uso del software . . .
4.6.1. Mininet . . .
4.6.2. Wireshark . .
4.6.3. OpenDaylight
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
36
36
37
37
38
38
38
43
47
.
.
.
.
.
.
.
.
.
49
49
50
61
62
62
62
66
66
69
75
Bibliografa
77
ii
ndice de figuras
3.1. Esquema Openflow . . . . . . . .
3.2. Proceso de matching . . . . . . .
3.3. Topologa . . . . . . . . . . . . .
3.4. PACKET_IN . . . . . . . . . . .
3.5. PACKET_OUT a . . . . . . . .
3.6. FLOW_MOD a . . . . . . . . . .
3.7. PACKET_OUT b . . . . . . . . .
3.8. FLOW_MOD b . . . . . . . . . .
3.9. Ultimos paquetes . . . . . . . . .
3.10. Wireshark Packet-in y Flow-mod
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
14
20
21
22
23
24
25
26
27
28
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
30
34
39
41
42
44
45
45
46
48
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
50
51
52
61
63
64
67
70
71
72
ndice de figuras
ndice de tablas
1.1. Metodologa del trabajo . . . . . . . . . . . . . . . . . . . . . . . . .
ndice de tablas
1 Introduccin
1.1.
Antecedentes
La idea de programar redes no es nueva, segn [1] hay varias contribuciones anteriores a SDN. Una de ellas es SOFTNET [2], all por principios de los 80, una
red multisalto, semejante a las a las actuales WSN (Wireless Sensor Networks) cuya
innovacin fue que en el campo de datos de cada paquete se incluan comandos que
los nodos iban ejecutando a medida que los iban recibiendo. De esta manera, la red
poda irse modificando de forma dinmica y en tiempo real. Fue un intento de definir
una red auto-organizable destinada a permitir la experimentacin y la innovacin
con diferentes protocolos. No hubo desarrollo posterior, pero su idea fue el embrin
de las posteriores Active Networks [3].
Las Active Networks presentaban una arquitectura consistente en llevar embebido
en los paquetes pequeos programas que podan ser ejecutados por los nodos que
stos atraviesan. Esto haca posible que los switches y routers de la red procesaran
los paquetes de datos, hacindoles partcipes de los mensajes y no solo meros espectadores que se limitaban a enviar mensajes de un puerto a otro, de una forma
pasiva. De ah el nombre de Active Networks. El rea de Active Networks fue una
tendencia en investigacin hace tiempo, aunque ltimamente ha decado.
Tanto SOFTNET como Active Networks concibieron una red innovadora, dinmica y partcipe de los datos que transportaban. El mecanismo era bsicamente el
mismo: aadir lneas de cdigo a los paquetes de datos para que los nodos intermedios las ejecutarn. No incorporaban un elemento software como control de los
elementos de conmutacin, como s hace la filosofa SDN.
En 2007, un grupo de trabajo de la Universidad de Standford formado por los
profesores Nick McKeown, Scott Shenker y el estudiante de doctorado Martn Casado desarrollaron OpenFlow y fundaron Nicira, una compaa de virtualizacin de
redes. Es a partir de este momento donde se sita el nacimiento de SDN.
En 2011, Scott Shenker y Nick McKeown fundaron la Open Networking Foundation (ONF), organizacin que buscaba fomentar el uso de OpenFlow, la creacin de
1 Introduccin
estndares y la implantacin de SDN ms all de las universidades.
En julio de 2012 VmWare, una de las compaas lderes en virtualizacin de servidores, dio un paso hacia la incorporacin de la virtualizacin de redes en su gama
de productos y compr Nicira por 1260 millones de dlares. Martn Casado pas a
ser el "arquitect networking" en jefe de VMware [4].
1.2.
Objetivos
Los objetivos del trabajo eran el diseo, desarrollo y prueba de escenarios basados
en mquinas virtuales que permitieran evaluar las nuevas arquitecturas de red basadas en software (Software Defined Networks o SDN). Se estudiaron los componentes
bsicos utilizados en SDN:
Protocolo OpenFlow.
Emuladores de red con soporte OpenFlow como Mininet.
Entornos como OpenDayLight.
Partiendo de estos componentes, se crearon escenarios que combinaban estas plataformas con el objetivo de detectar los beneficios que puede aportar el paradigma
SDN frente a la gestin tradicional de la red.
Adems se ha desarrollado una aplicacin con la que intentar mejorar la eficiencia
energtica de las redes usando tecnologas SDN.
1.3.
Planificacin
Tarea
Tarea
Tarea
Tarea
Tarea
1.4.
Febrero
X
X
Marzo
Abril
Mayo
1
2
3
X
4
X
X
5
X
Tabla 1.1: Metodologa del trabajo
Junio
Este trabajo aborda los temas antes mencionados a partir de una definicin ms
amplia de las tecnologas y su introduccin, seguido de la descripcin del diseo de la
aplicacin propuesta y del anlisis de sus mediciones. El trabajo se ha estructurado
en cinco captulos principales de la siguiente manera:
El Captulo 2 presenta las Redes Definidas por Software. Se tratan de explicar
como concepto y sus relaciones con la virtualizacin. Adems se aportan una serie
de beneficios de este tipo de redes. Por ultimo se explican algunos usos que pueden
tener las SDN.
En el Captulo 3 se realiza un anlisis del protocolo OpenFlow. Se explica el
funcionamiento de las distintas partes que lo componen y finalmente, se simula un
caso prctico para asentar la concepcin de como funciona el protocolo.
El Captulo 4 describe el software utilizado. Primeramente se exponen algunos controladores compatibles con OpenFlow y se hace un inciso en el controlador
OpenDaylight que es el que se usar posteriormente para realizacin de la aplicacin
prctica. Tambin se prestar atencin al software emulador de redes SDN Mininet.
Por ultimo se harn algunos ejemplos sencillos que muestran como ejecutar estas
aplicaciones.
En el Captulo 5 se mostrar como se ha desarrolado la aplicacin descrita anteriormente adems de su funcionamiento y las pruebas realizadas para probar dicha
aplicacin.
Finalmente en el Captulo 6 se harn las conclusiones pertinentes y una serie de
posibles trabajos futuros a desarrollar relacionados con las SDN.
1 Introduccin
Introduccin
2.2.
Concepto de SDN
2.3.
SDN y virtualizacin
2.4.
10
2.5.
Usos de SDN
Las redes SDN tienen aplicaciones en una gran variedad de entornos de red. Separando los planos de control y de datos, las redes programables permiten un control
personalizado y una oportunidad para de eliminar middleboxes y con ello simplificar
el desarrollo y la implementacin de nuevos servicios y protocolos. A continuacin,
se examinarn diferentes entornos para los que han sido propuestas o aplicadas soluciones SDN [5].
11
12
3 OpenFlow
Lo que propone OpenFlow [10] es una manera para que los investigadores puedan
experimentar con protocolos en la redes que se usan a diario. Permite a los investigadores experimentar con switches de manera uniforme a la velocidad de la lnea y
con una densidad de puertos muy alta. Por otra parte, los fabricantes no tienen que
exponer los procesos internos de sus switches. La propuesta de OpenFlow es muy
clara, permitir que los investigadores puedan evaluar sus ideas en un entorno de
trabajo real y ser un componente muy til en los bancos de pruebas a gran escala.
3.1.
Protocolo OpenFlow
13
3 OpenFlow
14
3.2.
Funcionamiento de OpenFlow
3.2.1.
Flujos
Un nuevo flujo se debe crear cuando un paquete que llega no encuentra ninguna
coincidencia con ninguna entrada de la tabla. El switch debera tener configurado
un descartado de paquetes para el flujo que no haya sido definido, pero en la mayora de los casos, el paquete ser enviado al controlador. El controlador entonces
define un nuevo flujo para ese paquete y crea una o ms entradas para la tabla.
ste enva la entrada o entradas al switch para que sean aadidas a las tablas de
flujo. Finalmente, el paquete se enva de vuelta al switch para ser procesado con las
nuevas entradas creadas.
Cada flujo de entrada tiene asociada una accin simple. Las tres bsicas son:
1. Reenvo de flujo de paquetes a un puerto o puertos dados. Esto permite que los paquetes ser encaminados a travs de la red. En la mayora de los
switches sucede a la velocidad de la lnea.
2. Encapsulacin y reenvo este flujo de paquetes al controlador. El
paquete ser enviado al Canal Seguro, donde se encapsula y se enva al controlador. Tpicamente se usa para el primer paquete en un nuevo flujo, para
que el controlador pueda decidir si el flujo debe ser aadido a la tabla de flujos.
Tambin se puede usar para reenviar todos los paquetes al controlador para
que sean procesados.
15
3 OpenFlow
Match Fields
Priority
Counters
Instructios
Timeouts
Cookie
3. Descartar este flujo de paquetes. Puede ser usado por seguridad, para
parar ataques de denegacin de servicio o reducir el falso trfico de descubrimiento broadcast desde los hosts finales.
3.2.2.
Tablas de flujos
3.2.3.
Instructions
16
3.2.4.
Counters
Los contadores estn mantenidos por tabla, por flujos, por puertos y por cola. Los
contadores pueden estar implementados por software y mantenidos por contadores
por hardware que tienen rangos ms limitados.
La tabla 3.2 contiene el conjunto de contadores requeridos [10]. Duration hace
referencia a el tiempo que un flujo ha estado instalado en un switch. Los campos
Receive Errors incluyen todos los errores especficos, incluyendo frame, overrun y
errores de CRC adems de algunos otros.
3.2.5.
17
3 OpenFlow
Counter
Per Table
Active Entries
Packet Lookups
Packet Matches
Per Flow
Receives Packets
Received Bytes
Duration (seconds)
Duration (nanoseconds)
Per Port
Received Packets
Transmitted Packets
Received Bytes
Transmitted Bytes
Receive Drops
Transmit Drops
Receive Errors
Transmit Errors
Receive Frame Alignmet Errors
Receive Overrun Errors
Receive CRC Errors
Collisions
Per Queue
Transmit Packets
Transmit Bytes
Transmit Overrun Errors
Tabla 3.2: Lista requerida de contadores para usar en
18
Bits
32
64
64
64
64
32
32
64
64
64
64
64
64
64
64
64
64
64
64
64
64
64
mensajes de estadsticas
3.2.6.
Matching
Cuando se recibe un paquete el Switch OpenFlow realiza las acciones que se ven
en la figura 3.2 [10]. El switch comienza haciendo una bsqueda en la primera tabla
de flujo. Las tablas de flujos se numeran empezando por el cero, y basado en esta
primera bsqueda realizara bsquedas en otras tablas de flujo.
A los campos de la tabla 3.3 que coinciden con alguna entrada se les extrae del
paquete. Los campos que se utilizan para buscar coincidencias dependen del tipo del
paquete y tpicamente incluyen varios campos de cabecera, las coincidencias tambin
se pueden hacer en base al puerto de entrada o por campos de metadatos.
Los metadatos se usarn para poder mandar informacin entre las tablas en un
switch. Un paquete coincide con una entrada de la tabla de flujos si los valores de
los campos del paquete que se usan para la bsqueda estn definidos en la misma.
19
3 OpenFlow
Si tiene un valor ANY (omitido), coincidir con todos los valores posibles en la
cabecera. Si el switch trabaja con mascaras arbitrarias para campos especficos se
podr afinar mucho ms las coincidencias. El paquete solo coincidir tambin tiene
la prioridad ms alta Los contadores asociados a la tabla seleccionada deben ser
actualizados y el set de instrucciones incluido en el flujo seleccionado, ser aplicado.
Si hay mltiples coincidencias y todas tienen configuradas la misma prioridad, la
entrada de flujo seleccionada esta explcitamente indefinida. Est especificacin no
tiene en cuenta si el switch recibe un paquete corrupto o con un formato que no es
el adecuado.
3.3.
Probando OpenFlow
3.3.1.
Explicacin terica.
20
21
3 OpenFlow
22
23
3 OpenFlow
24
25
3 OpenFlow
26
27
3 OpenFlow
28
4 Software utilizado
4.1.
Controladores
4.1.1.
OpenDaylight
OpenDaylight [12] es un proyecto open-source. Se trata de un controlador implementado en software contenido dentro de su propia mquina virtual de Java (JVM).
Como tal, puede ser desplegado en cualquier plataforma que soporte Java. El controlador contiene APIs abiertas que son utilizadas por las aplicaciones. OpenDaylight
soporta el framework OSGi y REST bidireccional.
El framework OSGi se utiliza para las aplicaciones que se ejecutan en el mismo
espacio de direcciones que el controlador mientras que REST API se utiliza para
aplicaciones que no se ejecutan en el mismo espacio de direcciones que el controlador.
La lgica de negocio y los algoritmos residen en las aplicaciones. Estas aplicaciones
utilizan el controlador para reunir la inteligencia de red, ejecutar algoritmos para
realizar anlisis y, seguidamente, usar el controlador para crear nuevas reglas a travs de la red.
El propio controlador contiene una coleccin de mdulos enlazables dinmicamente para realizar tareas de red. Hay una serie de servicios de red base para tareas
como ver que los dispositivos se encuentran dentro de la red y sus capacidades, la
recopilacin de estadsticas, etc. Adems otros servicios y extensiones pueden ser
aadidos al controlador para aumentar la funcionalidad SDN.
La interfaz de bajo nivel es capaz de soportar mltiples protocolos (plugins separados) como OpenFlow 1.0, OpenFlow 1.3, BGP-LS, etc. Estos mdulos estn
29
4 Software utilizado
30
4.1 Controladores
Bundle
arphandler
Interface exportadora
IHostFinder
Descripcin
Componente responsable del
aprendizaje de las
localizaciones del los hosts
usando ARP.
hosttracker
IfIptoHost
Localiza los hosts relativos a
la red SDN.
switchmanager
ISwitchManager
Componente que maneja el
inventario de informacin de
todos los nodos (switches)
conocidos por el controlador.
topologymanager
ITopolgyManager
Maneja el grafo de la red
completa.
statisticsmanager
IStatisticsManager
Componente a cargo de usar
el ReadService del SAL que
colecta todas las estadsticas
de la red SDN
sal
IReadService
Interface que provee la vista
hardware de los flujos, colas,
puertos de los nodos de red.
sal
ITopolgyService
Mtodos de topologa
proporcionados por SAL
hacia las aplicaciones.
sal
IFlowProgrammerService
Interface para instalar,
modificar o eliminar flujos en
los nodos de red.
sal
IDataPacketService
Servicios de paquetes de
datos de SAL provistos para
las aplicaciones.
Tabla 4.1: Bundles importantes de OpenDaylight
31
4 Software utilizado
se adhieren con el fin de ser capaz de hablar el uno al otro.
En la tabla 4.2 se comparan AD-SAL y MD-SAL [16]. Se ha optado por usar
AD-SAL ya que se ha encontrado un mayor nmero de documentacin y ejemplos
varios, en contraposicin con MD-SAL que siendo ms reciente es ms complicado
encontrar ejemplos concretos.
4.1.2.
Ryu
4.1.3.
Floodlight
El controlador SDN Floodlight es un controlador de clase empresarial, est disponible con licencia Apache para casi cualquier propsito. Es apoyado por una gran comunidad de desarrolladores que incluyen ingenieros de Big Switch Networks. Floodlight est diseado para trabajar con un gran numero de switches, routers, switches
virtuales y puntos de acceso compatibles con el protocolo OpenFlow. Es un sistema multiplataforma ya que funciona sobre la mquina virtual de Java. Para ms
informacin[19]
4.1.4.
NOX/POX
NOX es una pieza del ecosistema de las Redes Definidas por Software (SDN). Especficamente es una plataforma para crear aplicaciones de control de red. De hecho
mientras que ahora llamamos SDN a un nmero creciente de proyectos acadmicos,
la primera tecnologa en ser realmente conocida por SDN fue Openflow y NOX fue
inicialmente desarrollada por Nicira Networks codo con codo con OpenFlow (NOX
fue el primer controlador SDN). Nicira don NOX a la comunidad de desarrolladores
32
4.1 Controladores
AD-SAL
MD-SAL
API-Driven SAL
The SAL APIs, request routing between
consumers and providers, and data adaptations
are all statically defined at compile/build time.
Model-Driven SAL
The SAL APIs, request routing between
consumers and providers are defined from
models, and data adaptations are provided by
internal adaptation plugins.
The MD-SAL allows both the NB plugins and
SB plugins to use the same API generated from
a model. One plugin becomes an API (service)
provider; the other becomes an API (service)
Consumer.
MD-SAL provides a common REST API to
access data and functions defined in models .
The MD-SAL provides request routing and the
infrastructure to support service adaptation,
but it does not provide service adaptation
itself; service adaptation is provided by plugins.
33
4 Software utilizado
34
4.2 Mininet
en el ao 2008, y desde entonces ha sido la base para muchos proyectos en el inicio de las SDN. NOX provee a un desarrollador de una API C++ para OpenFlow 1.0.
POX es el hermano pequeo de NOX. En esencia, es una plataforma para el rpido desarrollo y prototipado para el control de la red por software utilizando Python.
Es uno de un nmero creciente de frameworks para SDN (incluyendo NOX, Floodlight, Opendaylight...) con el fin de prestar ayuda para programar un controlador
OpenFlow. POX adems va ms all de eso.
Para ms informacin acerca de NOX y POX [20].
4.2.
Mininet
Mininet [21] es un emulador de red que ejecuta una coleccin de dispositivos finales, switches, routers y enlaces en un solo core de Linux. Se utiliza la virtualizacin
ligera para hacer que un solo sistema parezca una red completa. Los programas que
se ejecutan pueden enviar paquetes a travs de lo que parece ser una interfaz de Ethernet real, con una velocidad de enlace y con retardo. Los paquetes se procesan por
lo que parece un verdadero interruptor de Ethernet, un enrutador o middlebox, con
una determinada cantidad de colas. Cuando dos programas, como un iperf cliente
y el servidor, se comunican a travs mininet, el rendimiento medido debe coincidir
con el de dos mquinas nativas ms lentas. En resumen, los dispositivos virtuales de
mininet, conmutadores, enlaces y los controladores se crean utilizando software en
lugar de hardware, en su mayor parte el comportamiento es similar a los elementos
de hardware.
4.2.1.
Mininet presenta una serie de ventajas e inconvenientes al simular una red, las
cuales se presentan a continuacin.
Ventajas
Rpido: la puesta en marcha de una red simple tarda slo unos segundos.
Esto significa que el bucle de gestin edit-debug puede ser muy rpido.
Se pueden crear topologas personalizadas: un solo switch, grandes topologas tipo Internet...
Puede correr programas reales: puede correr cualquier programa que se
pueda ejecutar en Linux.
35
4 Software utilizado
Compartir resultados: al ser un sistema cerrado es fcil compartir el cdigo
y ejecutarlo en distintas mquinas.
Se pueden ejecutar experimentos simples escritos en Python, por ejemplo
un servidor web simple usando un pequeo comando.
Inconvenientes
Todos los hosts mininet comparten el mismo sistema de archivos y el
espacio PID.
Actualmente mininet no hace NAT fuera de su sistema. Los host no pueden
hablar directamente a Internet a menos que proporcione un medio para que lo
hagan (se pueden configurar los hosts mininet para que tengan conectividad
externa o para aadirles una interfaz fsica).
Lo ms importante que se tiene que tener en cuenta para los experimentos de red,
es que probablemente habr que utilizar enlaces ms lentos, por ejemplo 10 o 100
Mb/s en lugar de 10 Gb/s, debido al hecho de que los paquetes son transmitidos
por un conjunto de conmutadores de software, los recursos de la CPU que comparten la memoria, y por lo general tienen un menor rendimiento que el hardware de
conmutacin dedicado [6].
4.2.2.
vSwitch
Open vSwitch es un sistema de switch virtual, diseado especficamente para habilitar automatizacin y despliegue de interfaces de red de manera programada, adems soporta su distribucin alrededor de mltiples servidores fsicos, lo que lo hace
ideal para la construccin de esquemas de redes virtuales para nubes. OpenVSwitch
es el esquema por defecto de gestin de redes de Mininet y se incluye preinstalado
en la mquina virtual de Mininet.
4.3.
Wireshark
36
4.4 Iperf
todo el trfico que pasa a travs de una red (usualmente una red Ethernet, aunque
es compatible con algunas otras) estableciendo la configuracin en modo promiscuo.
Tambin incluye una versin basada en texto llamada tshark.
Permite examinar datos de una red viva o de un archivo de captura salvado
en disco. Se puede analizar la informacin capturada, a travs de los detalles y
sumarios por cada paquete. Wireshark incluye un completo lenguaje para filtrar lo
que queremos ver y la habilidad de mostrar el flujo reconstruido de una sesin de
TCP.
4.4.
Iperf
Iperf [24, 25] es una herramienta que se utiliza para hacer pruebas en redes informticas. El funcionamiento habitual es crear flujos de datos TCP y UDP y medir el
rendimiento de la red. Iperf fue desarrollado por el Distributed Applications Support
Team (DAST) en el National Laboratory for Applied Network Research (NLANR)
y est escrito en C++.
Iperf permite al usuario ajustar varios parmetros que pueden ser usados para
hacer pruebas en una red, o para optimizar y ajustar la red. Iperf puede funcionar
como cliente o como servidor y puede medir el rendimiento entre los dos extremos de la comunicacin, unidireccional o bidireccionalmente. Es software de cdigo
abierto y puede ejecutarse en varias plataformas incluyendo Linux, Unix y Windows.
4.5.
Eclipse
Eclipse [26, 27] es un programa informtico compuesto por un conjunto de herramientas de programacin de cdigo abierto multiplataforma para desarrollar lo que
el proyecto llama "Aplicaciones de Cliente Enriquecido", opuesto a las aplicaciones
"Cliente-liviano" basadas en navegadores. Esta plataforma, tpicamente ha sido usada para desarrollar entornos de desarrollo integrados (del ingls IDE), como el IDE
37
4 Software utilizado
de Java llamado Java Development Toolkit (JDT) y el compilador (ECJ) que se
entrega como parte de Eclipse (y que son usados tambin para desarrollar el mismo
Eclipse).
Eclipse fue desarrollado originalmente por IBM como el sucesor de su familia de
herramientas para VisualAge. Eclipse es ahora desarrollado por la Fundacin Eclipse,
una organizacin independiente sin nimo de lucro que fomenta una comunidad de
cdigo abierto y un conjunto de productos complementarios, capacidades y servicios.
Se ha usado la versin Eclipse IDE for Java Developers 1 para MAC OS X de 64
bits ya que contiene la herramienta Maven preinstalada.
4.5.1.
Maven
4.6.
4.6.1.
Mininet
Como hemos comentado anteriormente, Mininet [21] es un software que nos permite emular una red que usa el protocolo OpenFlow. La forma de puesta en marcha
de Mininet ms sencilla es usar la mquina virtual que se proporciona en su pgina
web, esta contiene el Mininet propiamente dicho, todos los binarios OpenFlow y ms
herramientas preinstaladas (p.e. Wireshark) y modificaciones de la configuracin del
kernel que dan soporte a redes Mininet ms complejas. Se puede descargar la versin
1
38
39
4 Software utilizado
$ ssh -Y mininet@ip_mininet
La opcin -Y permite ejecutar interfaz grfica usando el servidor X11 de la mquina remota que nos servir para poder abrir ventanas adicionales o para poder
usar Wireshark y MiniEdit. Para poder usarlo necesitamos tener instalado el software XQuartz 3 para OS X o bien Xming4 para Windows, en Linux X11 viene por
defecto.
CLI
Una vez dentro de la mquina remota usaremos el siguiente comando para iniciar
Mininet (Figura 4.4).
$ sudo mn
Con ello ya estaremos ejecutando mininet. Mininet por defecto carga una topologa simple con un controlador c0 conectado a un switch s1 y a este dos hosts, h1 y
h2 (ver Figura 4.5).
Es posible aadir ms opciones al comando que nos permitirn personalizar nuestra red. Por ejemplo el siguiente comando cargara una red en rbol de dos niveles de
switches Open vSwitch, adems indicamos que se conecte a un controlador remoto
y su direccin ip.
$ sudo mn --switch=ovsk --topo=tree,2 --controller=remote,ip=192.168.1.3
Ahora dentro del CLI podemos realizar varias acciones. Por ejemplo podemos
comprobar la conectividad de la red con el comando pingall que mandar un ping
desde todos los host de la red a todos los host restantes, o bien podemos usar el
comando dump para visualizar los dispositivos que esta nuestra red. Adems poniendo
el nombre del dispositivo seguido de un espacio y un comando de unix, podremos
ejecutar comandos en los dispositivos directamente desde la consola de Mininet (ej.
h1 ping h2). Para salir usaremos el comando exit. Para ms informacin [30]).
3
4
40
41
4 Software utilizado
42
Nos abrir una ventana como esta (Figura 4.6) que nos permitir aadir los switches OpenFlow, los hosts, el controlador as como sus enlaces. Tambin podremos
modificar todas sus caractersticas. Algo importante que debemos hacer es decirle
que el controlador es remoto, para ello, simplemente haremos click derecho en el
icono del controlador, pinchamos en Properties y en Controller Type elegimos Remote Controller. Adems debemos cambiar la direccin IP por la del host donde
se iniciar OpenDaylight (Figura 4.7). Tambin indicarle a MiniEdit que cuando
lancemos el script python de Mininet nos cargue el CLI para que podamos trabajar
desde su consola, para hacer esto debemos ir a Edit, Preferences y seguidamente
marcar la casilla Start CLI (Figura 4.8). Para ms informacin acerca de como usar
MiniEdit [31].
Una vez tengamos nuestra topologa creada la guardaremos y la exportaremos
a Level 2 Script que nos crear un script python de mininet, el cual simplemente
lanzaremos y tendremos nuestro mininet listo. Para ello primero habr dar permisos
de ejecucin al archivo que exportamos y seguidamente podremos ejecutar el script:
$ sudo chmod +x nombre_script.py
$ sudo ./nombre_script.py
4.6.2.
Wireshark
Para este trabajo, usaremos el software Wireshark [23] que nos permitir visualizar los paquetes de nuestra red. Wireshark est incluido en la mquina virtual de
mininet. Este incluye un plugin para OpenFlow que permite visualizar los paquetes
de forma mucho ms ordenada, adems tambin permite el filtrado de estos. Para
filtrar los paquetes OpenFlow usaremos el cdigo of. Ms adelante veremos como
se inicia la conexin en el protocolo OpenFlow visualizando los paquetes mediante
este plugin.
Iniciar Wireshark
Para ejecutar Wireshark (Figura 4.9) basta con lanzarlo usando el siguiente comando en la mquina de Mininet:
$ sudo wireshark&
43
4 Software utilizado
44
45
4 Software utilizado
46
4.6.3.
OpenDaylight
47
4 Software utilizado
48
Explicacin terica
49
5.1.1.
Algoritmo de Dijkstra
El algoritmo de Dijkstra (ver algortmo 5.1), tambin llamado algoritmo de caminos mnimos, es un algoritmo para la determinacin del camino ms corto dado
un vrtice origen al resto de los vrtices en un grafo con pesos en cada arista. Su
nombre se refiere a Edsger Dijkstra, quien lo describi por primera vez en 1959.
La idea subyacente en este algoritmo consiste en ir explorando todos los caminos
ms cortos que parten del vrtice origen y que llevan a todos los dems vrtices;
cuando se obtiene el camino ms corto desde el vrtice origen, al resto de vrtices
50
51
52
Consideraciones previas.
Durante la explicacin del cdigo hay que tener en cuenta que:
Los enlaces es llaman edges indistintamente, ya que es el nombre que toma
este objeto en OpenDaylight.
De la misma forma, un nodo (node) es lo mismo que un switch.
Un nodeConnector a su vez es un puerto de un switch.
53
54
55
Paths.buildGraph. Esta funcin (5.7) genera el grafo del cual calcularemos los
caminos. Simplemente hay que aadir todas las aristas y sus dos vrtices e
indicar el tipo de arista (en nuestro caso ser dirijida, ya que como hemos
comentado antes topologyManager entrega un edge por cada sentido de un
enlace).
56
57
58
59
60
5.1.2.
Como hemos dicho anteriormente Maven automatiza el proceso de aadir las dependencias necesarias para nuestro proyecto a la hora de compilar. Para hacer esto
usa el fichero pom.xml (se encuentra dentro del proyecto de flowApp) el cual contiene el nombre de las dependencias necesarias y repositorios donde conseguirlas. Para
aadir ms dependencias simplemente hay que buscar el nombre de la dependencia deseada2 y aadirla en el apartado depdendencies (figura 5.4) dentro del fichero
pom.xml [35].
Una vez tenemos nuestro fichero pom.xml configurado para compilar nuestro proyecto lo haremos pinchando con el botn derecho en nuestro proyecto de eclipse, nos
vamos a Run as y finalmente pinchamos en Maven install como se muestra en la
2
Dependencias Opendaylight
https://nexus.opendaylight.org/content/repositories/opendaylight.snapshot/org/opendaylight/controller/
61
5.1.3.
5.2.
Funcionamiento
5.2.1.
Para cambiar la configuracin del mdulo solamente debemos cambiar los valores
del fichero flowapp.conf. Estos valores son los siguientes:
@IDLETIMEOUT valor Tiempo en segundos para el idle_time_out de los flujos
que se instalarn. Por defecto 15.
@HARDTIMEOUT valor Tiempo en segundos para el hard_time_out de los flujos
que se instalarn. Por defecto 7200 (dos horas)
@REFRESHTIME valor Tiempo en segundos para el refresco del calculo de niveles.
Por defecto 10.
@LEVEL1 valor Troughtput en bytes por segundo mediante el cual se asignarn los niveles. As pues los enlaces con un throughtput de 0 estarn en
StandBy, los enlaces de 0 al valor estarn en Nivel1 y los enlaces cuyo
62
5.2 Funcionamiento
63
64
5.2 Funcionamiento
throughtput sea mayor al valor estarn en Nivel2. Por defecto 12500000
(12.5MB/s = 100Mbps).
@ESTANDBY valor Energa en mW que consume una interfaz en StandBy. Por
defecto 49.
@ELEVEL1 valor Energa en mW que consume una interfaz en Nivel1. Por defecto
315.
@ELEVEL2 valor Energa en mW que consume una interfaz en Nivel2. Por defecto
619.
@STANDBYCOST valor Coste asignado a un enlace en StandBy. Por defecto 50.
@LEVEL1COST valor Coste asignado a un enlace en Nivel1. Por defecto 15.
@LEVEL2COST valor Coste asignado a un enlace en Nivel2. Por defecto 1.
@MONPATH ruta Ruta en la cual se guardarn los ficheros de monitorizacin. Por
defecto ./
@MONITOR true/false True si queremos mostrar los datos de monitorizacin en
consola, false si no. Por defecto a true.
Tambin podemos aadir comentarios de la forma #+comentario. Si repetimos ms
de un comando, ser siempre el ltimo el que tendr valor.
Ejemplo de un fichero flowapp.conf creado:
#Fichero de configuracion
@IDLETIMEOUT 15
@HARDTIMEOUT 7200
@REFRESHTIME 10
@LEVEL1 12500000
@ESTANDBY 49
@ELEVEL1 315
@ELEVEL2 619
@STANDBYCOST 50
@LEVEL1COST 1
@LEVEL2COST 1
@MONPATH /Users/pablomuri/Develop/
@MONITOR true
65
5.2.2.
Iniciando OpenDaylight
Partiendo de la base en que ya tenemos nuestro mdulo compilado listo para usarse en la carpeta plugins dentro de opendaylight y configurado, la mquina virtual
iniciada y los scripts de Python (para este paso se puede usar algn cliente SFTP
como winSCP3 en Windows, Fugu4 para Mac o Filezilla para Linux5 bien usar el
comando scp6 desde la terminal.) en ella. Iniciamos OpenDaylight como dijimos en
el apartado 4.6.3. Abrimos una terminal, nos vamos a la carpeta opendaylight y
ejecutamos el siguiente comando:
$ ./run.sh
Si est todo va bien en unos segundos nos debera aparecer la configuracin cargada y comenzar a monitorizar a los 10 segundos, siempre que tengamos activado el
modo monitor (ver figura 5.7).
5.2.3.
Iniciando Mininet
Una vez tenemos OpenDaylight corriendo toca iniciar Mininet, para ello primero
debemos conectarnos por ssh como muestra el apartado 4.6.1. Ahora tenemos que
iniciar nuestra topologa, en nuestro caso usaremos las tres topologas descritas en
el apartado 5.1. Cada topologa se inicia con un fichero .py diferente. Por ejemplo
probaremos el script malla6.py el cual contiene una topologa en malla, la forma de
lanzarlo es como se hara con cualquier ejecutable de unix, una cosa que hay que
tener en cuenta es que mininet debe tener permisos de administrador, por lo tanto
el comando quedara as:
$ sudo ./malla6.py
Esperaremos unos instantes y deberamos tener acceso al CLI si el script de Mininet est bien configurado. Adems en la consola de OpenDaylight veramos que los
switchs han sido reconocidos por el controlador y el monitor de comienza a mostrar
informacin del nivel de las interfaces. Esperaremos unos segundos hasta que en el
nmero total de interfaces aparezcan todas (tiene que se el doble del nmero de
enlaces entre nodos). Para la topologa en malla utilizada deberan ser 17.
3
66
5.2 Funcionamiento
67
68
5.3 Resultados
5.3.
Resultados
Se han realizado las tres pruebas comentadas anteriormente usando dos ficheros
de configuracin diferentes. En uno de ellos todos los niveles tenan coste 1, es decir,
la mejora energtica est desactivada. En el otro fichero el coste para los enlaces de
nivel 2 es de 1, para los enlaces de nivel 1 es de 5 y para los enlaces en stand by
es de 50. Se ha llegado a la conclusin de que estos valores son los ms adecuados
realizando diversas pruebas, al final se observ que haba que usar un valor alto para
el coste de los enlaces en stand by, ya que la intencin es evitarlos lo mximo posible.
Para el consumo energtico de cada nivel se han usado los valores por defecto: 49
mW para las interfaces en StandBy, 315 mW para las interfaces en nivel 1 y 619 mW
para las interfaces en nivel 2 [36].
El programa guarda en varios ficheros algunos datos para la monitorizacin del
sistema, en nuestro caso cada 10 minutos. A partir de esos datos se han creado las
grficas 5.8, 5.9 y 5.10 usando la carga total de la red (en Bytes por segundo) y la
energa total de la red (en mW).
Se puede observar fcilmente en las grficas que prcticamente solo hay mejora
en la topologa de malla, ya que esta es la que permite ms diferentes entre hosts
y por ello hay ms dispersin entre caminos cuando no se usa la mejora energtica.
En cambio cuando se usa la mejora, los caminos se van centrando mucho ms. Sin
embargo en las otras dos topologas no hay apenas mejora, ya que estas no permiten
tantos caminos diferentes como para notar un cambio usando la eficiencia energtica.
Vemos como la energa total de la red y el nmero total de interfaces en StandBy
estn muy relacionadas entre s, ya que son las interfaces en este nivel las que menos
consumo energtico tienen. Los picos iniciales son debidos a que la red todava se est
cargando. Justo despus vemos como se estabiliza en valores bajos y seguidamente vuelve a subir, es por que en este momento las pruebas de carga han sido lanzadas.
Sin embargo es en las grficas del throughput de la red donde se encuentra el problema. Al intentar usar siempre los enlaces en los que ya hay una carga, los caminos
acaban siendo ms largos en nmero de saltos, as pues, la carga total aumenta.
Por esto es trabajo del administrador de red configurar el coste de los niveles de
enlace en el archivo de configuracin, con el fin de conseguir el balance de eficiencia
energtica y de carga deseados.
69
70
5.3 Resultados
71
72
Conclusiones
Tendencias como la movilidad del usuario, la virtualizacin de servidores, o la necesidad para responder a las cambiantes condiciones de negocios, significan nuevas
demandas sobre las redes. Las redes definidas un software forman un nuevo paradigma que habilita la programacin de la red y que dentro de muy poco encontraremos
en muchas de las redes ms importantes del planeta [9].
En este trabajo se han definido qu son las redes SDN, qu papel juegan en la virtualizacin de sistemas, y cuales son sus beneficios. Tambin se han dado ejemplos
de uso de este tipo de redes. Se ha explicado qu es y cmo funciona el protocolo OpenFlow, siendo actualmente el protocolo ms importante que hace uso de las
redes SDN. Tambin hemos definido las partes ms importantes de este protocolo
para posteriormente poder desarrollarlas en un trabajo prctico.
Hemos visto tambin que es un controlador y como trabaja junto a OpenFlow.
Adems se han mostrado algunos ejemplos de controladores para finalmente centrarnos en OpenDaylight, un controlador que funciona bajo la mquina virtual de
Java y que permite desarrollar mdulos que pueden funcionar en conjunto.
Para poder ejecutar una red, se ha usado el software Mininet, una herramienta
muy potente que proporciona un escenario ideal para la implantacin de un nmero
infinito de distintas topologas de red que facilitan las pruebas en un entorno de
investigacin.
Mediante estas tecnologas se ha desarrollado una aplicacin para OpenDaylight
que busca mejorar la eficiencia energtica de las redes usando tecnologa SDN debido
al creciente tamao que estn teniendo las redes de ltima generacin.
Gracias a esto se ha conseguido comprender como usar las herramientas que nos
ofrece el protocolo OpenFlow para en un futuro poder desarrollar otras aplicaciones
SDN para otros campos en continuo crecimiento, como son las redes mviles, o las
redes pticas.
73
6.2.
Trabajo futuro
Hay varios aspectos que pueden ser mejorados en un futuro. Podran probarse las
posibilidades de otros controladores en la parte de programacin y ms actualizados,
por ejemplo OpenDaylight con MD-SAL.
Actualmente, la aplicacin desarrollada funciona bajo IPv4 ya que la API usada
estaba pensada para ser usada bajo OpenFlow 1.0 que en teora no permite usar
IPv6. Esto podra resolverse usando algn controlador ms actualizado que entregue APIs ms adecuadas para el trabajo con IPv6 y alguna versin ms moderna
de OpenFlow, como OpenFlow 1.3 u OpenFlow 1.4.
Gracias al uso de SDN sera posible seguir aumentando la eficiencia energtica.
La idea sera seguir mejorando los algoritmos para la eficiencia energtica ahora que
ya estn asentadas las bases para el desarrollo bajo SDN.
En el presente ya se haya entre nosotros la cuarta generacin de telefona: 4G. As
que justo ahora es cuando se est investigando la siguiente generacin conocida por
5G. Se podran aplicar los conocimientos desarrollados en este trabajo para desarrollar protocolos bajo la tecnologa SDN con el fin de gestionar la movilidad en las
redes 5G, ya que SDN estar intrnsicamente ligada a la siguiente generacin.
En este trabajo hemos desplegado las redes virtualmente usando la herramienta
Mininet. Sera interesante ver como se comportara la solucin desarrollada en un
entorno real usando dispositivos fsicos.
74
7 Agradecimientos
Agradecer a mi familia la ayuda aportada durante todos estos aos, tanto moralmente como econmicamente.
A Yai, que ha aguantado estos ltimos meses de agobios y no ha podido apoyarme
ms.
A todos mis compaeros del grado, los cuales al final han acabado siendo amigos.
Al director de mi proyecto, Javier. Muchas gracias por haber credo en mis posibilidades y ofrecerme un proyecto el cual no podra haber disfrutado ms. Gracias
por tu ayuda durante todos estos meses.
75
7 Agradecimientos
76
Bibliografa
[1] Dan Pitt.
A revolution (revelation?) in networking.
Open Networking Foundation, 2012. URL: http://opennetsummit.org/archives/apr12/
pitt-mon-ons.pdf.
[2] Jens Zander and Robert Forchheimer. Softnet-an approach to high level packet
communication, 1983.
[3] David L. Tennenhouse and David J. Wetherall. Toward an active network
architecture, 1996. URL: http://dx.doi.org/10.1117/12.235899, doi:10.
1117/12.235899.
[4] Craig Matsumoto.
Vmware and nicira: 1 year and dollar 1.26b
later, 2013.
URL: https://www.sdxcentral.com/articles/featured/
vmwarenicira-1-year-and-1-26b-later/2013/07/.
[5] Bruno Nunes, Manoel Mendonca, Xuan-Nam Nguyen, Katia Obraczka, Thierry
Turletti, et al. A survey of software-defined networking: Past, present, and
future of programmable networks. Communications Surveys & Tutorials, IEEE,
16(3):16171634, 2014.
[6] Washington A. Velsquez Vargas. Emulacin de una red definida por software
utilizando mininet. 2014.
[7] Raj Jain and Sudipta Paul. Network virtualization and software defined networking for cloud computing: a survey. Communications Magazine, IEEE,
51(11):2431, 2013.
[8] Woon Hau Chin, Zhong Fan, and R. Haines. Emerging technologies and research challenges for 5g wireless networks. Wireless Communications, IEEE,
21(2):106112, April 2014. doi:10.1109/MWC.2014.6812298.
[9] H Wessing DTU, K Bozorgebrahimi, A Tzanakaki, and B Belter. Deliverable
d12. 3 (dj1. 1.1) future network architectures. 2015.
[10] Open Networking Fundation. Openflow switch specification 1.3, 2012.
77
Bibliografa
[11] David Mahler. Introduction to openflow. ltima visita 2015. URL: https:
//www.youtube.com/watch?v=l25Ukkmk6Sk.
[12] Opendaylight [URL: http://www.opendaylight.org, ltima visita 2015].
[13] Cisco. Opendaylight api. URL: https://developer.cisco.com/media/
XNCJavaDocs/overview-summary.html [ltima visita 2015].
[14] Srini Seetharaman. Opendaylight helium application developers tutorial. URL:
http://sdnhub.org/tutorials/opendaylight-helium/ [ltima visita 2015].
[15] Inc The OpenDaylight Project. Controller projects modules/bundles and interfaces. URL: https://wiki.opendaylight.org/view/Controller_Projects%
27_Modules/Bundles_and_Interfaces [ltima visita 2015].
[16] Kanika.
Difference Between AD-SAL and MD-SAL.
URL: http://
sdntutorials.com/difference-between-ad-sal-and-md-sal/.
[17] Openflow ryu tutorial.
OpenFlow_Tutorial.
URL: https://github.com/osrg/ryu/wiki/
[18] R. team. RYU SDN Framework - English Edition:. Release 1.0. RYU project
team, 2014. URL: http://books.google.es/books?id=JC3rAgAAQBAJ.
[19] Floodlight Web. URL: http://www.projectfloodlight.org/ [ltima visita
2015].
[20] Nox/pox [URL: http://www.noxrepo.org/, ltima visita 2015].
[21] Mininet [URL: http://mininet.org/, ltima visita 2015].
[22] Wireshark Wikipedia.
[ltima visita 2015].
URL: https://es.wikipedia.org/wiki/Wireshark
78
Bibliografa
[28] Maven Web. URL: https://maven.apache.org/ [ltima visita 2015].
[29] Maven Wikipedia. URL: https://es.wikipedia.org/wiki/Maven [ltima visita 2015].
[30] Mininet Team.
Mininet walkthrough.
walkthrough/ [ltima visita 2015].
URL: http://mininet.org/
79