Analisi y Evaluaciones de Las Redes Definidas Por Software

Universidad de Extremadura
Centro Universitario de Mrida

Grado en Ingeniera en Telemtica
Trabajo Fin de Grado

ANLISIS Y EVALUACIN DE LAS REDES
DEFINIDAS POR SOFTWARE
Autor/a: Pablo Murillo Nogales
Mrida, Julio de 2015
Universidad de Extremadura
Centro Universitario de Mrida
Grado en Ingeniera en Telemtica
Trabajo Fin de Grado

ANLISIS Y EVALUACIN DE LAS REDES
DEFINIDAS POR SOFTWARE
Autor/a: Pablo Murillo Nogales

Fdo:
Director/a: Javier Domingo Carmona Murillo

Fdo:
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
2. Software Defined Networking

2.1. Introduccin . . . . . . . .
2.2. Concepto de SDN . . . . .
2.3. SDN y virtualizacin . . .
2.4. Beneficios del SDN . . . .
2.5. Usos de SDN . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
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
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5. Caso prctico: Mejora de la eficiencia energtica

5.1. Explicacin terica . . . . . . . . . . . . . . .
5.1.1. Desarrollo del cdigo: Java . . . . . . .
5.1.2. Desarrollo del cdigo: Maven . . . . . .
5.1.3. Desarrollo del cdigo: Python . . . . .
5.2. Funcionamiento . . . . . . . . . . . . . . . . .
5.2.1. Configuracin mdulo flowApp . . . .
5.2.2. Iniciando OpenDaylight . . . . . . . .
5.2.3. Iniciando Mininet . . . . . . . . . . . .
5.3. Resultados . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
en una red SDN

. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
36
36
37
37
38
38
38
43
47
.
.
.
.
.
.
.
.
.
49
49
50
61
62
62
62
66
66
69
6. Conclusiones y trabajo futuro

73
6.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.2. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
7. Agradecimientos
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
4.1. OpenDaylight Helium . . . . . . . . . .

4.2. Floodligh . . . . . . . . . . . . . . . .
4.3. Mininet VM ifconfig . . . . . . . . . .
4.4. mininet> . . . . . . . . . . . . . . . .
4.5. Topologa simple Mininet . . . . . . . .
4.6. Topologa con MiniEdit . . . . . . . .
4.7. Controlador remoto MiniEdit . . . . .
4.8. Activar CLI MiniEdit . . . . . . . . .
4.9. Ventana de Wireshark . . . . . . . . .
4.10. Controlador OpenDaylight inicindose
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
30
34
39
41
42
44
45
45
46
48
5.1. Topologa en malla . . . . . . . . . . .

5.2. Topologa en anillo . . . . . . . . . . .
5.3. Topologa en rbol . . . . . . . . . . .
5.4. dependencies . . . . . . . . . . . . . . .
5.5. Compilar con Maven . . . . . . . . . .
5.6. Cdigo python iperfUDP . . . . . . . .
5.7. OpenDaylight configuracin y monitor
5.8. Topologa en malla . . . . . . . . . . .
5.9. Topologa en anillo . . . . . . . . . . .
5.10. Topologa rbol . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
50
51
52
61
63
64
67
70
71
72
ndice de figuras
ndice de tablas
1.1. Metodologa del trabajo . . . . . . . . . . . . . . . . . . . . . . . . .
3.1. Principales componentes de una entrada en una tabla de flujo . . . . 16

3.2. Lista requerida de contadores para usar en mensajes de estadsticas . 18
3.3. Campos de los paquetes usados para matching . . . . . . . . . . . . . 19
4.1. Bundles importantes de OpenDaylight . . . . . . . . . . . . . . . . . 31
4.2. AD-SAL vs MD-SAL . . . . . . . . . . . . . . . . . . . . . . . . . . 33
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
Metodologa de trabajo (ver tabla 1.1):

1. Anlisis y estudio de los antecedentes de SDN y OpenFlow.
2. Anlisis de los elementos que componen la red SDN y Openflow.
3. Virtualizacin de agentes de red. Mininet.
4. Despliegue y anlisis de las plataformas OpenDayLight.
5. Desarrollo de aplicacin bajo OpenDaylight y estudio de su comportamiento.
1.4 Estructura del documento
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
Estructura del documento
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
2 Software Defined Networking

2.1.
Introduccin
El SDN (Software Defined Networking) es una tcnica emergente que concentra

las funciones de control de la red en elementos software. Explicaremos el concepto
de SDN, su relacin con las tcnicas de virtualizacin y sus beneficios, explorando
tambin el concepto de Network Functions Virtualization (NFV) [5].
2.2.
Concepto de SDN
SDN es el acrnimo de Software Defined Networking, es decir, la implementacin

en software de algunas funciones de red. Para entender lo que SDN aporta, conviene primero repasar cules son las funciones de un router o un switch en una red,
tpicamente una red IP. Este tipo de equipos soportan dos funciones fundamentales:
Una funcin de transporte: que se podra entender como su funcin primaria y
que consiste, simplemente, en transportar datos a su destino. Para ello, estos
equipos envan los paquetes de datos a dnde indiquen unas rutas previamente
calculadas.
Una funcin de control: que permite gestionar la funcin de transporte mediante otras dos subfunciones principales:
Intercambiar informacin sobre conectividad con otros routers/switches.
Calcular rutas con base en la informacin obtenida.
En el networking tradicional tanto las funciones de control como las de transporte
son ejecutadas de forma distribuida en todos los routers/swItches de la red. SDN es
un enfoque de networking que, por un lado, separa claramente las funciones transporte y de control y, por otro implementa la funcin de control con software (en
lugar de hacerlo en hardware). Adems, centraliza en un elemento, el controlador
esa funcin de control.
Resumimos pues los tres elementos que caracterizan al Software Defined Networking (SDN):

Separacin clara entre las funciones de transporte y de control.
Centralizacin de la funcin de control.
Implementacin de la funcin de control en software.
El hecho de centralizar la funcin de control y de implementarla en software conlleva
que la red se pueda programar mediante aplicaciones, lo que proporciona una enorme
flexibilidad y facilidad de despliegue de funciones de red.
Adems, el controlador puede exponer interfaces de aplicacin que facilitan la
manipulacin y gestin de la red [6].
2.3.
SDN y virtualizacin
La virtualizacin es una tcnica que pretende simular hardware y elementos de

red mediante software. No es un concepto que provenga especficamente del mundo
del networking sino que, de hecho, surgi ms bien en el mundo de las Tecnologas
de la informacin, de los grandes servidores de aplicaciones y los data centers. La
virtualizacin abstrae las mquinas reales, el hardware real, en lo que se denomina
la mquina virtual, esto es, una mquina ficticia implementada en software pero a
la que se asigna memoria, espacio en disco, etc, como si de una mquina real se tratase. De esta forma las aplicaciones ven, por decirlo de alguna manera, una mquina
adaptada a sus necesidades pero del alguna forma independiente del hardware real
que la soporta. Para crear y gestionar esas mquinas virtuales se emplea un software
que se denomina hypervisor.
Aunque, ya en el campo del networking SDN y virtualizacin son conceptos diferentes, lo cierto es que en realidad aparecen muy unidos. Y lo hacen en el sentido
de que las funciones de control centralizadas se suelen implementar como switches
virtuales (es decir, la simulacin de un switch en software) ejecutndose en mquinas
virtuales alojadas sobre unos servidores fsicos y gestionadas mediante un hypervisor.
Un concepto relacionado con la virtualizacin y el SDN es el de virtualizacin
de funciones de red (Network Functions Virtualization, NFV). Lo que significa este
concepto es la centralizacin de funciones de red en servidores de propsito general
virtualizados. As, por ejemplo, se pueden centralizar funciones en el campo de la
seguridad AAA (Authentication, Authorization and Accounting).
2.4.
Beneficios del SDN
Qu aporta el SDN? Podramos resumir los beneficios en los siguientes puntos:
10
2.5 Usos de SDN

Elimina la lentitud en innovacin propia del hardware permitiendo que sta se
produzca a la velocidad del software, especialmente en el plano de control.
Optimiza el coste de hardware de networking.
Implementacin de la funcin de control en software.
Simplifica el equipamiento de red
Posibilita el uso de algoritmos ms complejos y exigentes computacionalmente.
Reduce la barrera de entrada para innovadores e investigadores.
Reduce drsticamente los ciclos de vida de lanzamiento de servicios.
Promueve la innovacin en algoritmos de enrutamiento as como una mayor
utilizacin de la capacidad de red.
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].
Redes empresariales: Una gestin adecuada es de vital importancia en entornos

empresariales. Las redes SDN pueden ser usadas para manejar las polticas de
red mediante programacin. Las SDN pueden manejar funciones de middlebox
como firewalls, NATs, balanceadores de carga o medidas de control de acceso.
Data Centers: Un gran problema de los data centers, es el gran consumo energtico que producen. Las redes SDN pueden permitir mejorar la eficiencia
energtica a travs de mtodos para usar solo una parte de la red, intentando
que esto no repercuta en la eficiencia de la red. Ms adelante nosotros tambin
abordaremos este problema [7].
Redes pticas: Manejar el trafico de datos mediante flujos, permite a las SDN
y a OpenFlow en particular, soportar e integrar mltiples tipos de tecnologas
de red. De acuerdo a el Optical Transport Working Group (OTWG) creado
en 2013 por la Open Network Foundation (ONF), los beneficios de aplicar
11

SDN y el estndar OpenFlow en particular a las redes de transporte pticas
incluyen: mejora el control de red del transporte ptico y la flexibilidad en la
administracin, permitiendo la implementacin de administracin de terceros
y control de sistemas, e implementando nuevos servicios de virtualizacin.
Infraestructuras basadas en redes de acceso inalmbricas: Recientemente se
est viendo un creciente inters acadmico y de la industria en para aplicar
SDN a las redes mviles. La principal motivacin detrs de esto es que SDN
puede ayudar a los operadores mviles a simplificar la administracin de sus
redes y permitir nuevos servicios que soporten el crecimiento exponencial del
trfico previsto para las redes 5G [8].
Hogares y PYMES: Varios proyectos se han centrado en ver cmo las redes
SDN podran ser utilizadas en redes ms pequeas, tales como las que se encuentran en hogares o pequeas empresas. Estos escenarios se estn volviendo
cada vez ms complejos debido a la creciente disponibilidad de dispositivos de
red de bajo coste y la necesidad de dispositivos ms complicados de administrar y de mayor seguridad.
GANT, la red cientfica europea, recientemente ha publicado entre sus futuras

implantaciones, nuevas tecnologas para los entornos de red, entre ellas est la que
tratamos en este documento, las redes SDN. Se pretende en un futuro, poder usar
esta tecnologa para controlar sus capas de transporte [9].
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
La mayora de los switches Ethernet contienen tablas de flujos (Flow-Tables), la

idea de OpenFlow es la posibilidad de modificar estas tablas de forma dinmica para
implementar firewalls, NAT, QoS y recolectar estadsticas. Es posible experimentar
con nuevos protocolos, nuevos modelos de seguridad, esquemas de direccionamiento,
incluso alternativas para IP lo que supone una mayor innovacin. El plano de datos
no se vera afectado ya que est aislado y se procesara de la misma manera que se
ha estado realizando hasta hoy da. El cambio reside en el plano de control que se
implementara mediante OpenFlow.
Los switch OpenFlow puede soportar diversas acciones, aunque es necesario tener
una serie de caractersticas comunes a todos ellos. Un switch OpenFlow consiste en
al menos tres partes (ver figura 3.1 [5]):
Tabla de flujos: con una accin asociada a cada entrada de la tabla, indicando
al switch como debe procesar ese flujo.
Canal seguro que conecte el switch a un proceso de control remoto (controlador), permitiendo comandos y paquetes se puedan enviar entre el switch y
el controlador usando el protocolo OpenFlow.
Controlador: Un controlador aade y elimina entradas en la tabla de flujos.
13
3 OpenFlow
Figura 3.1: Esquema Openflow

Los switches tradicionales usan STP, SPB o TRILL para determinar cmo se reenvan los paquetes. OpenFlow traslada esta decisin de reenvo de los switches a
los controladores, tpicamente un servidor o una estacin de trabajo. Una aplicacin
de gestin se ejecutar en las interfaces del controlador que une todos los switches
en la red, facilitando la configuracin de caminos de reenvo que utilizarn todo el
ancho de banda disponible. La especificacin define el protocolo entre el controlador
y los switches y un conjunto de operaciones que se pueden realizar entre ellos Las
instrucciones de reenvo se basan en el flujo, que consiste en que todos los paquetes
comparten una serie de caractersticas comunes.
Existen infinidad de parmetros que pueden especificarse para definir un flujo.
Entre los posibles criterios podemos incluir los puertos por donde se reciben los
paquetes cuando llegan, el puerto Ethernet de origen, la etiqueta VLAN, el destino
Ethernet o el puerto IP y otro numero de caractersticas de los paquetes. 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
14
3.2 Funcionamiento de OpenFlow

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.
SDN no es OpenFlow
A menudo se apunta a Openflow como sinnimo de SDN, pero en realidad, es
simplemente un elemento que forma parte de la arquitectura SDN. Openflow es
un estndar abierto para un protocolo de comunicaciones que permite al plano de
control interactuar con el plano de datos (Openflow, sin embargo, no es el nico
protocolo disponible o en desarrollo para SDN, aunque s est convirtindose en el
modelo estndar de implementacin de una SDN.
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
Tabla 3.1: Principales componentes de una entrada en una tabla de flujo
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
Una tabla de flujo contiene una serie de entradas de flujo

Cada entrada de la tabla de flujo (tabla ) contiene:
match fields: Coincidencia. Este campo consiste en el puerto y la cabecera
de paquete y opcionalmente metadatos especificados en una tabla anterior.
priority: Prioridad del flujo. En el caso de que haya ms de un flujo con el
mismo match tendr prioridad el flujo con el nmero de prioridad ms alto.
counters: Contadores que se actualizan cuando los paquetes coinciden (matched).
instructions: Instrucciones que indican la accin que har el paquete a procesar.
timeouts: tiempos antes de que un flujo expire. Son dos: idle_time_out y
hard_time_out. El primero hacer referencia al tiempo que un flujo estar sin
usar. El segundo indica el tiempo real desde que se instal el flujo.
cookie: Valor que elige el controlador para filtrar las estadsticas, las modificaciones y el borrado de los flujos. No se usa: cuando se procesan los paquetes.
Una entrada de la tabla de flujo es identificada por su "match fields" y prioridad.
3.2.3.
Instructions
Cada tabla de flujo contiene un set de instrucciones que se ejecutan cuando el

paquete encuentra una coincidencia con la entrada. Estas instrucciones dan lugar a
cambios en el paquete, en el conjunto de acciones y en el procesamiento.
Un switch no tiene por qu soportar todos los tipos de instrucciones, solo las que
se marcan como requeridas y son: Instruccin de escritura (Write-Actions action):
16

Si la accin del tipo dado existe, se sobrescribe, si no, se aade. Ir a la tabla (GotoTable next-table-id): Indica la siguiente tabla en el procesado. El identificador de
la siguiente tabla debe ser mayor que el de la actual. Las entradas del flujo de la
ltima tabla no pueden incluir esta instruccin. Solo se permite una instruccin por
cada tipo. Los switches OpenFlow con una tabla no lo necesitarn.
Las instrucciones de la tabla de flujos modifican la accin asociada a cada paquete. Los paquetes empiezan a procesarse con un conjunto de acciones vaco. Las
acciones pueden especificar que el paquete que se va a reenviar a travs de un puerto
especfico, modificar el TTL, VLAN, etiqueta MPLS o la QoS.
Adems, una instruccin puede especificar un identificador de grupo. Se pueden
definir en el switch mediante entradas en la tabla de grupo Las instrucciones de la
primera tabla debern realizar una accin en el paquete o aadir acciones que se
realizarn despus. Las instrucciones asimismo, debern permitir que el procesado
de paquetes contine comparndolos con las entradas de otras tablas de flujos.
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.
Mensajes del protocolo OpenFlow
El protocolo consiste en 3 tipos de mensajes: controlador a switch, asncrono y

asimtrico. Controlador a switch se envan para:
Especificar, modificar o borrar definiciones de flujos.
Solicitar informacin acerca de las capacidades del switch.
Obtener informacin como los contadores del switch.
Enviar paquetes de vuelta al switch para su procesamiento despus de que un
nuevo flujo se ha creado.
Mensajes asncronos se envan al switch para:
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

Ingress Port Ether Src Ether Dst Ether type VLAN id VLAN Priority
IP src IP dst IP proto IP Tos TCP/UDP src port TCP/UDP dst port
Tabla 3.3: Campos de los paquetes usados para matching
Enviar al controlador el paquete que no coincide con los flujos existentes.

Informar al controlador que el flujo ha sido eliminado porque su parmetro
TTL o el timer de inactividad han vencido.
Informar al controlador de un cambio en el estado de un puerto o de un error
que ha ocurrido en un switch. Ejemplos de estas circunstancias son cuando
los links se caen o cuando un paquete llega con una instruccin de reenvo no
especificada.
Mensajes simtricos pueden ser enviados por el switch o el controlador y se usan
para:
Los mensajes de hello que se intercambian el controlador y el switch al comienzo.
Mensajes de echo usados para determinar la latencia de la conexin controladorswitch y para verificar que esta conexin sigue operativa.
Mensajes experimentales para proveer un camino para futuras extensiones de
la tecnologa OpenFlow.
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.
Figura 3.2: Proceso de matching
3.3.
Probando OpenFlow
3.3.1.
Explicacin terica.
Veamos como se comportara un switch OpenFlow (S1 ), en el supuesto de que el

host H1 realizara una peticin a un servidor HTTP alojado en el host H4 [11]. Ver
20
3.3 Probando OpenFlow
Figura 3.3: Topologa

figura 3.3.
H1 enva un paquete SYN para intentar iniciar la conexin. Cuando llega a S1
realiza el proceso de matching (figura 3.2), en esencia lo que hace es buscar si hay
alguna entrada de flujo de la tabla de flujo cuyo campo match coincida con la cabecera del paquete SYN. En este caso, al ser el primer paquete que recibe S1, este
todava no tiene instalado ningn flujo por lo que opta por enviar un PACKET_IN
al controlador, el cual contiene entre otros campos el buffer_id, que est generado
de forma secuencial, adems de el paquete SYN original. Figura 3.4.
Ahora el controlador se encarga de procesar el PACKET_IN. En esta parte es
cuando entra en escena la labor del programador que tiene que encargarse de decidir
que hacer con el PACKET_IN. Por ejemplo se podran uno de estos dos casos o los
dos a la vez:
1. Simplemente decirle a S1 que enve el paquete que recibi el controlador por
el puerto 4 de S1. Para esto el controlador enva un PACKET_OUT (ver
21
3 OpenFlow
Figura 3.4: PACKET_IN
22
Figura 3.5: PACKET_OUT a

figura 3.5) el cual contiene el paquete original, el mismo buffer_id que contena
el PACKET_IN y una accin que indica que el paquete se enve por el puerto
4.
2. Enviarle a S1 un paquete FLOW_MOD (ver figura3.6) indicndole que
instale un flujo (flow) el cual diga que todos los paquetes en cuya cabecera
figure el puerto TCP 80 y que lleguen por el puerto eth1, que corresponde con
H1 (estas dos opciones formaran el campo MATCH, en este caso lo formaran
los campos Ingress Port y TCP dst Port. Tabla 3.3) sean enviados por por
el puerto eth4, que corresponde con H4 (esto formara el campo ACTION ).
Adems se aaden otros datos ms indicados en la figura 3.6.
Posteriormente el paquete SYN llegar a su destinatario.
Una vez el paquete SYN ha llegado H4 enva de vuelta el paquete SYN/ACK.
Una vez ms el controlador tendr que decidir que hacer con este paquete, ya que
no encuentra ninguna referencia en su tabla de flujos. As que podremos realizar las
23
3 OpenFlow
Figura 3.6: FLOW_MOD a
24
Figura 3.7: PACKET_OUT b

dos mismas acciones descritas anteriormente pero en sentido inverso. Figuras 3.7 y
3.8.
Finalmente los mensajes restantes, encontrarn una entrada de flujo de acuerdo a
sus cabeceras, por lo que los paquetes sern redirigidos directamente sin necesidad
de que S1 tenga que comunicarse con el controlador. Ver figura 3.9.
En la figura 3.10 podemos observar como efectivamente primero llega un PACKET_IN al controlador y este se encarga de instalar un flujo mediante un mensaje
FLOW_MOD. Esto ocurre en los dos sentidos por los que viaja el paquete.
25
3 OpenFlow
Figura 3.8: FLOW_MOD b
26
Figura 3.9: Ultimos paquetes
27
3 OpenFlow
Figura 3.10: Wireshark Packet-in y Flow-mod
28
4 Software utilizado
4.1.
Controladores
Como hemos visto anteriormente un controlador bsicamente aade y elimina

entradas en la tabla de flujos. Existen numerosos controladores disponibles para
OpenFlow pero nos centraremos solo en algunos de ellos. Se ha llegado a la conclusin de que finalmente se usar OpenDaylight, debido a la mayor cantidad de
documentacin, ejemplos e informacin disponible, que har ms sencilla la tarea
de desarrollar un programa para el controlador.
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
Figura 4.1: OpenDaylight Helium

dinmicamente conectados a la Service Abstraction Layer (SAL). La SAL contiene
servicios de dispositivos para los mdulos de niveles ms altos. La SAL determina
cmo cumplir con el servicio solicitado, independientemente del protocolo utilizado
entre el controlador y los dispositivos de red.
El controlador ofrece una serie de core bundles, cada uno de ellos exporta servicios
importantes a travs de Java Interfaces. En la tabla 4.1 se ofrece una lista de algunos
bundles importantes que ofrece a la hora de desarrollar servicios de red. Cada una de
estas interfaces ofrece una serie de mtodos [13] que dan facilidad a para el desarrollo
de los servicios de red en Java, ms adelante se explicar algunos de estos mtodos
ms importantes. Para ms informacin [14, 15].
AD-SAL vs MD-SAL
La SAL no es ms que cruce que conecta el plugin del protocolo y los Mdulos de
Funcin de Red (Topology Manager, Statistics Manager, Switch Manager... ). Las
API SAL son los contratos a los que los plugins de protocolo y los mdulos de NFS
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
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
Ryu es un componentes bsico de las redes definidas por software. Provee de

componentes software, las API que facilitan a los desarrolladores la tarea de crear
aplicaciones de control y gestin de la red. Ryu soporta varios protocolos para la
gestin de dispositivos de red, como OpenFlow, Netconf, OF-config, etc. En cuanto
a OpenFlow, Ryu soporta totalmente las versiones 1.0, 1.2, 1.3, 1.4 y las Nicira Extensions. Adems Ryu posee certificaciones para trabajar en dispositivos de distintas
marcas.
Todo el cdigo esta disponible libremente a travs de la licencia Apache 2.0. Ryu
est totalmente escrito en Python. Ryu significa flow en japons. Ryu posee gran
cantidad de documentacin, ordenada, y fcil de comenzar a utilizar. Para ms
informacin[17, 18].
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.
The AD-SAL typically has both NB and SB

APIs even for functions/services that are
mapped 1:1 between SB Plugins and NB
Plugins.
In AD-SAL there is a dedicated REST API
for each northbound/southbound plugin.
he AD-SAL provides request routing (selects an
SB plugin based on service type) and optionally
provides service adaptation, if an NB (Service,
abstract) API is different from its
corresponding SB (protocol) API.
Request routing is based on plugin type: the
SAL knows which node instance is served by
which plugin, and when an NB Plugin requests
an operation on a given node, the request is
routed to the appropriate plugin which then
routes the request to the appropriate node.
AD-SAL is stateless
Limited to flow-capable device and service

models only
AD-SAL services usually provide both
asynchronous and synchronous versions of the
same API method.
Request Routing in the MD-SAL is done on

both protocol type and node instances, since
node instance data is exported from the plugin
into the SAL.
MD-SAL can store data for models defined by

plugins: provider and consumer plugins can
exchange data through the MD-SAL storage
Model agnostic. It can support any device
and/or service models and is not limited to
flow-capable device and service models only
In MD-SAL, Service model APIs only provide
asynchronous APIs, but they return a
java.concurrent.Future object, which allows a
caller to block until the call is processed and a
result object is available. Same API can be
used for both synchronous and asynchronous
approach. Thus MD-SAL encourages
asynchronous approach to application design
but does not preclude synchronous applications.
Tabla 4.2: AD-SAL vs MD-SAL
33
Figura 4.2: Floodligh
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.
Ventajas e inconvenientes de Mininet
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
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
Wireshark [22, 23], antes conocido como Ethereal, es un analizador de protocolos

utilizado para realizar anlisis y solucionar problemas en redes de comunicaciones,
para desarrollo de software y protocolos, y como una herramienta didctica. Cuenta
con todas las caractersticas estndar de un analizador de protocolos de forma nicamente hueca.
La funcionalidad que provee es similar a la de tcpdump, pero aade una interfaz
grfica y muchas opciones de organizacin y filtrado de informacin. As, permite ver
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.
UDP: Cuando se utiliza el protocolo UDP, Iperf permite al usuario especificar

el tamao de los datagramas y proporciona resultados del rendimiento y de
los paquetes perdidos.
TCP: Cuando se utiliza TCP, Iperf mide el rendimiento de la carga til. Un detalle a tener en cuenta es que Iperf usa 1024*1024 para medidas en megabytes
y 1000*1000 para megabits.
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
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
Maven [28, 29] es una herramienta de software para la gestin y construccin de

proyectos Java creada por Jason van Zyl, de Sonatype, en 2002. Es similar en funcionalidad a Apache Ant (y en menor medida a PEAR de PHP y CPAN de Perl), pero
tiene un modelo de configuracin de construccin ms simple, basado en un formato
XML. Estuvo integrado inicialmente dentro del proyecto Jakarta pero ahora ya es
un proyecto de nivel superior de la Apache Software Foundation.
Maven utiliza un Project Object Model (POM) para describir el proyecto de software a construir, sus dependencias de otros mdulos y componentes externos, y
el orden de construccin de los elementos. Viene con objetivos predefinidos para
realizar ciertas tareas claramente definidas, como la compilacin del cdigo y su
empaquetado.
4.6.
Uso del software
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
Descarga Eclipse IDE for Java Developers http://www.eclipse.org/downloads/packages/eclipseide-java-developers/marsr
38
4.6 Uso del software
Figura 4.3: Mininet VM ifconfig

ms reciente desde el siguiente enlace 2 .
En nuestro caso usaremos la versin Mininet 2.2.1 on Ubuntu 14.04 64 bits. Para la ejecucin de la mquina virtual se usara el software de virtualizacin VMware.
En mi caso he configurado la VM una interfaz de red en modo bridge para poder
tener acceso desde cualquier punto de mi red.
Ya que la VM no incluye interfaz grfica la forma ms cmoda de manejar Mininet
es a travs de SSH. En nuestro caso accederemos desde OS X 10.10 as que no habr
que instalar nada adicional ya que viene con un cliente ssh instalado, desde Windows
podemos usar cualquier cliente SSH disponible (p.e. Putty). Antes de todo habr
que mirar con el comando ifconfig la direccin IP de la VM Mininet, el nombre
de usuario y la contrasea son mininet (Figura 4.3).
Para acceder a la mquina virtual abrimos una terminal y usamos el siguiente
comando e introducimos la contrasea mininet:
2
Descargar Mininet VM https://github.com/mininet/mininet/wiki/Mininet-VM-Images
39
$ 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
Descargar XQuartz http://xquartz.macosforge.org/landing/

Descargar Xming http://sourceforge.net/projects/xming/
40
Figura 4.4: mininet>
41
Figura 4.5: Topologa simple Mininet

Topologas
Mininet permite ejecutar algunas topologas predefinidas usando algunos parmetros en el CLI. Por ejemplo el siguiente comando nos permitir cargar una topologa
en rbol de dos niveles:
$ sudo mn --topo=tree,2
Ms interesante aun es la posibilidad de crear topologas personalizadas. La forma ms sencilla es usar MiniEdit, que es un programa escrito en python que nos
permite hacer eso mismo de forma grfica. Este mismo ha sido usado para crear
las topologas que usaremos ms adelante. Para ejecutarlo basta con lanzarlo como
cualquier script python, en concreto en nuestra mquina virtual de Mininet se hara
con el siguiente comando:
$ sudo ~/mininet/examples/miniedit.py
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
Figura 4.6: Topologa con MiniEdit
44
Figura 4.7: Controlador remoto MiniEdit
Figura 4.8: Activar CLI MiniEdit
45
Figura 4.9: Ventana de Wireshark
46
4.6.3.
OpenDaylight
Como hemos dicho anteriormente, OpenDaylight [12] es un controlador OpenFlow

escrito en Java. En nuestro caso hemos usado la versin base que es la ms sencilla
de usar, ya que desde el principio est todo montado y no es necesario instalar ms
cosas. En concreto usaremos una versin modificada de SDN Hub [32], ya que es
ms liviana que la versin original ya que solo incluye los mdulos necesarios para
la ejecucin de nuestro programa. Esta versin se incluye en los archivos externos
entregados junto a la documentacin. Para lanzar el controlador nos iremos a la
carpeta de OpenDaylight y ejecutaremos el comando (Figura 4.10):
$ ./run.sh
Es posible que previamente haya que dar permisos de ejecucin, si esto ocurre,
usaremos el siguiente comando para solucionar esto:
$ sudo chmod +x run.sh
Ms adelante veremos ms a fondo como usar el controlador OpenDaylight comunicndolo con la mquina de Mininet para nuestro caso concreto.
47
Figura 4.10: Controlador OpenDaylight inicindose
48
5 Caso prctico: Mejora de la

eficiencia energtica en una red
SDN
5.1.
Explicacin terica
Se ha desarrollado un mdulo para OpendayLight llamado flowApp que intenta

mejorar la eficiencia energtica de redes de switches utilizando para ello tecnologa
SDN. En concreto usaremos Opendaylight y Mininet (que incluye switches OpenFlow). Se usarn tres topologas distintas para comprobar el grado de mejora en
cada una de ellas. Estas son, topologa en malla (figura 5.1), topologa en anillo (figura 5.2) y topologa en rbol (figura 5.3). A continuacin pasaremos a explicar los
cdigos fuentes del mdulo OpenDaylight programado en Java y de las topologas
de Mininet escritas en Python.
El gasto energtico de una interfaz de red es proporcional al throughtput de esa
interfaz. Al aumentar el throughtput tambin aumentar el gasto energtico de la
forma que se indica en la tabla, de forma que prcticamente una interfaz de red
con un throughput de 1000Mpbs (que diremos que est en nivel 2) tiene solamente
el doble del gasto energtico de una interfaz con un throughtput de 100Mbps (diremos que est en nivel 1), de modo que lo que se pretende es que la mayora de
las conexiones estn en nivel 2 lo que har que haya mayor numero de interfaces en
StandBy (que son las que menos gasto energtico tienen) . El mdulo se encarga de
calcular las rutas energticamente ptimas entre dos hosts y de instalarlas en la red,
permitiendo la comunicacin en cualquier topologa de red SDN.
El mdulo flowApp permite la configuracin de distintos parmetros. Entre ellos
se encuentran tres importantes que nos permitirn cambiar los costes (usados por el
algoritmo shortest path de Dijkstra) dados a cada nivel energtico (StandBy, Nivel1
o Nivel2). As el mdulo se encargar de calcular las rutas ms ptimas energticamente hablando. Variando estos valores conseguiremos modificar el comportamiento
del ahorro energtico, consiguiendo ms ahorro energtico (se usaran menos enlaces) repercutiendo en el aumento del throughtput total de la red, para conseguir
49
5 Caso prctico: Mejora de la eficiencia energtica en una red SDN
Figura 5.1: Topologa en malla

esto deberamos asignarle un valor alto a las interfaces en StandBy, un valor medio
a las interfaces Nivel1 y un valor bajo a las interfaces Nivel2, as intentaramos usar
lo menos posible las interfaces en StandBy. Si asignramos el mismo coste a todos los niveles permitiramos que la red se comporte de forma normal sin conseguir
eficiencia energtica y, simplemente, consiguiendo forwarding entre host usando el
controlador.
5.1.1.
Desarrollo del cdigo: Java
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
5.1 Explicacin terica
Figura 5.2: Topologa en anillo
51
Figura 5.3: Topologa en rbol
52

Algoritmo 5.1 Algoritmo de Dijkstra
Require: Directed network G = (V, E, w), with non-negative edge weights and
source s V .
Ensure: Array ( ) of length n, where (u) is the maximum reliability for each
u V , and array pred( ) of length n, where pred(u) is the parent of vertex u in
the shortest path tree rooted at s.
S = ; S 0 = V
for every u V do
(P ) = 0;
end for
(s) = 1; pred(s) = 0;
while |S| < n do
let u S 0 be the vertex for which (u) = minuS 0 {d(u)};
S = S {u}; S 0 = S 0 {u};
for (u, w) E do
if (w) < (u) wt(u, w) then
(w) = (u) wt(u, w)
end if
end for
end while
que componen el grafo, el algoritmo se detiene. El algoritmo es una especializacin
de la bsqueda de costo uniforme, y como tal, no funciona en grafos con aristas de
coste negativo (al elegir siempre el nodo con distancia menor, pueden quedar excluidos de la bsqueda nodos que en prximas iteraciones bajaran el costo general del
camino al pasar por una arista con costo negativo) [33].
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

API AD-SAL
Se ha usado el java-doc de AD-SAL OpenDaylight [13] para tener una referencia
de los distintos mtodos que se pueden usar a travs de las Interfaces descritas en
la tabla 4.1. Las dos interfaces ms importantes para la realizacin de este proyecto
han sido el Topology Manager y el Statistics Manager.
Topology Manager: Nos da informacin acerca de la topologa de la red. Su
mtodo ms importante es getEdges el cual nos devuelve un Map con todos
los edges de la red. A partir del objeto edge podemos sacar el nodeConnector
de cada extremo y de este ltimo el node. Hay que tener en cuenta que el
topologyManager entrega dos edges para cada enlace, uno en cada sentido.
Por eso a la hora de crear el grafo de la red usaremos un grafo dirigido para
que a la hora de calcular los caminos nos entreguen los edges en la direccin
correcta.
Statistics Manager: Entrega informacin de los contadores del protocolo OpenFlow de los switchs. Nos interesa para conocer los campos Transmitted Bytes
y Received Bytes de los puertos (ver apartado3.2.4) con el fin de calcular su
throughput.
Cdigo
A continuacin pasaremos a explicar las partes ms relevantes del programa
[14, 34]. Para ms informacin consultar el cdigo fuente el cual est totalmente
comentado.
PacketHandler.receiveDataPacket. Esta funcin es llamada cuando el controlador recibe un PACKET_IN desde cualquiera de los switches, como vemos
en la figura 5.2 se comprueba que sea de tipo Ethernet para a continuacin
extraer las direcciones MAC origen y destino que contiene el paquete. Seguidamente se comprueba que se trate de un paquete IPv4 e igual que en el paso
anterior, extraemos las direcciones IP origen y destino. Finalmente llamamos
al mtodo installPathFlows que se encargar de calcular las rutas e instalarlas
en los nodos correspondientes.
PacketHandler.installPathFlows. El trabajo de esta funcin es la de calcular

las rutas e instalarlas en toda la red (figuras 5.3 y 5.4). Primero se busca el
nodo al que est conectado un host con la direccin dstAddr. Una vez encontrado, inicializamos el objeto path de tipo Path, una clase la cual contiene los
mtodos de clculo de caminos usando el algoritmo Shortest Path de Dijkstra
54
Funcin 5.2 receiveDataPacket
55

basndonos en Framework para grafos JUNG 1 . Para hacer esto nos basamos
en la interfaz topologyManager con el fin de sacar una lista de edges los cuales
usaramos para crear un grafo. Adems tenemos un Map llamado edgeCost el
cual contiene los costes actuales asociados a cada enlace (edge o arista). Una
vez hecho esto, primeramente miraramos si existe conexin entre los dos nodos y seguidamente calcularamos el camino mediante el mtodo getPath. El
camino lo formaran una lista de edges los cuales instalaramos para instalar
un flujo en el nodo situado en el primer extremo del enlace (tail). En este
flujo indicaramos que todos los paquetes con direccin IP fuente srcAddr y
direccin IP destino dstAddr se mandaran por la interfaz correspondiente al
edge usado. Este paso lo realizaramos tantas veces como edges tenga la lista
edgePath.
PacketHandler.programFlow. Dicha funcin (5.5) se encarga de crear los flujos

e instalarlos en los nodos correspondientes. Primero se crea un objeto Match
el cual contendr los datos con los cuales se decidir si un paquete har uso del
flujo o no segn los datos de su cabecera. En nuestro caso simplemente seleccionaramos los paquetes IPv4 con direccin IP fuente srcAddr y direccin IP
destino dstAddr. El siguiente paso es crear la lista de acciones que realizarn
los paquetes coincidentes con el match, le vamos a indicar solo una, que el paquete se envie por el puerto outConnector. Por ltimo creamos el flujo usando
los objetos match y actions, le asignamos los time_outs correspondientes y
finalmente programamos el flujo en el nodo.
PacketHandler.iniEdgeBps. Dicha funcin (5.6) asigna el nivel que tendr cada

enlace dependiendo de su throughput actual. Adems devuelve la carga total
de la red.
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).
Java Universal Network/Graph Framework http://jung.sourceforge.net/doc/api/index.html
56
Funcin 5.3 PacketHandler.installPathFlows Parte 1
57
Funcin 5.4 PacketHandler.installPathFlows Parte 2
58
Funcin 5.5 PacketHandler.programFlow
59

Funcin 5.6 PackeHandler.iniEdgeBps
Funcin 5.7 Paths.buildGraph
60
Figura 5.4: dependencies
5.1.2.
Desarrollo del cdigo: Maven
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

figura 5.5.
5.1.3.
Desarrollo del cdigo: Python
Los scripts python programados simplemente se encargan de generar trfico para

comprobar el rendimiento de la red. Se encargan de lanzar comandos en cada host de
forma automtica. Concrtamente se lanzan comandos ping e iperf cada 10 segundos. Inicialmente solo se usaron comandos iperf para generar trfico UDP ya que
esta herramienta solo permita modular el ancho de banda de este tipo de trfico.
El problema vino con que el controlador OpenDaylight no procesaba los paquetes
UDP con la rapidez necesara, y mientras se estaban instalando las rutas a lo largo
de la red, seguian llegando paquetes al controlador ya que no se encontraban flujos
asociados por que no haba dado tiempo a instalarlos. Para poder solucionarlo es
opt por mandar primero un paquete ICMP mediante la aplicacin ping para que al
controlador le diera tiempo de calcular las rutas e instalarlas. Una vez hecho esto se
hara el iperf UDP y ya se encontraran los flujos instalados por lo que no llegaran
nunca al controlador.
Como vemos en la figura 5.6 primero ejecutamos iperf en modo servidor en todos
los hosts y seguidamente comienzan a mandarse en bucle los ping y las peticiones
iperf (con ancho de banda de 50Mbps y durante 50 segundos).
5.2.
Funcionamiento
5.2.1.
Configuracin mdulo flowApp
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
Figura 5.5: Compilar con Maven
63
Figura 5.6: Cdigo python iperfUDP
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
Descargar winSCP http://winscp.net/eng/docs/lang:es

Descargar Fugu http://sourceforge.net/projects/fugussh/
5
Descargar Filezilla https://filezilla-project.org/download.php?show_all=1
6
Cmo usar el comando scp http://www.tecmint.com/scp-commands-examples/
4
66
5.2 Funcionamiento
Figura 5.7: OpenDaylight configuracin y monitor
67

Una vez cargada nuestra red, es el momento de realizar las pruebas. Para ello usaremos una funcin en python que cargaremos desde un script externo. Para hacer
esto primero necesitamos cargar el script (archivo malla6_iperf.py).
mininet> py execfile('malla6_iperf.py')
Seguidamente llamaremos a la funcin iperfUDP(h1,h2,h3,h4,h5,h6) la cual se encuentra dentro del script que acabamos de cargar. Esta funcin se encarga de generar
en bucle trfico entre los host cada 10 segundos (este tiempo se puede cambiar modificando la variable t del script python):
mininet> py iperfUDP(h1,h2,h3,h4,h5,h6)
Como esta, se han preparado otras dos pruebas. Cada una tiene un script para
iniciar la topologa y otro script que contiene la funcin iperfUDP asociada a cada
topologa.
La topologa en anillo se encuentra en el script anillo16.py, por lo tanto para
cargarla lo hacemos del mismo modo que la primera:
$ sudo ./anillo16.py
En la consola de mininet usaremos los siguientes comandos para lanzar la prueba:
mininet> py execfile('anillo16_iperf.py')
mininet> py iperfUDP(h1,h2,h3,h4,h5,h6,h7,h8,h9,h10,h11,h12)
Finalmente la topologa en rbol se encuentra en el fichero tree4.py. Lo ejecutaremos igual que las veces anteriores.
$ sudo ./tree4.py
mininet> py execfile('tree4_iperf.py')
mininet> py iperfUDP(h1,h2,h3,h4,h5,h6,h7,h8,h9)
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
(a) Energa total de la red
(b) Carga total de la red
Figura 5.8: Topologa en malla
70
5.3 Resultados
Figura 5.9: Topologa en anillo
71
Figura 5.10: Topologa rbol
72
6 Conclusiones y trabajo futuro

6.1.
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 Conclusiones y trabajo futuro
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
[23] Wireshark web. URL: https://www.wireshark.org/ [ltima visita 2015].

[24] Iperf Wikipedia. URL: https://es.wikipedia.org/wiki/Iperf [ltima visita
2015].
[25] Iperf [URL: https://iperf.fr/, ltima visita 2015].
[26] Eclipse Web. URL: https://eclipse.org/ [ltima visita 2015].
[27] Eclipse Wikipedia.
URL: https://es.wikipedia.org/wiki/Eclipse_
(software) [ltima visita 2015].
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/
[31] Brian Linkletter.

How to use miniedit, mininets graphical user interface.
URL: http://www.brianlinkletter.com/
how-to-use-miniedit-mininets-graphical-user-interface/
[ltima
visita 2015].
[32] Srini Seetharaman, Anirudh Ramachandran, and Sriram Natarajan. Sdn hub.
URL: http://sdnhub.org/ [ltima visita 2015].
[33] S Skiena. Dijkstras algorithm. Implementing Discrete Mathematics: Combinatorics and Graph Theory with Mathematica, Reading, MA: Addison-Wesley,
pages 225227, 1990.
[34] Frank Durr. Reactive flow programming with opendaylight, 2014.
[35] Frank Durr. Developing osgi components for opendaylight.
[36] Jordan R. Energy efficient ethernet: Technology, application and why you
should care. Technical report, Intel Corporation, 2011.
79

Analisi y Evaluaciones de Las Redes Definidas Por Software

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Analisi y Evaluaciones de Las Redes Definidas Por Software

Enviado por

Direitos autorais:

Formatos disponíveis

Universidad de Extremadura

Centro Universitario de Mrida

Trabajo Fin de Grado

Autor/a: Pablo Murillo Nogales

Mrida, Julio de 2015

Trabajo Fin de Grado

Autor/a: Pablo Murillo Nogales

Director/a: Javier Domingo Carmona Murillo

2. Software Defined Networking

5. Caso prctico: Mejora de la eficiencia energtica

en una red SDN

6. Conclusiones y trabajo futuro

4.1. OpenDaylight Helium . . . . . . . . . .

5.1. Topologa en malla . . . . . . . . . . .

3.1. Principales componentes de una entrada en una tabla de flujo . . . . 16

Metodologa de trabajo (ver tabla 1.1):

1.4 Estructura del documento

Estructura del documento

2 Software Defined Networking

El SDN (Software Defined Networking) es una tcnica emergente que concentra

SDN es el acrnimo de Software Defined Networking, es decir, la implementacin

2 Software Defined Networking

La virtualizacin es una tcnica que pretende simular hardware y elementos de

Beneficios del SDN

Qu aporta el SDN? Podramos resumir los beneficios en los siguientes puntos:

2.5 Usos de SDN

Redes empresariales: Una gestin adecuada es de vital importancia en entornos

2 Software Defined Networking

GANT, la red cientfica europea, recientemente ha publicado entre sus futuras

La mayora de los switches Ethernet contienen tablas de flujos (Flow-Tables), la

Figura 3.1: Esquema Openflow

3.2 Funcionamiento de OpenFlow

Tabla 3.1: Principales componentes de una entrada en una tabla de flujo

Una tabla de flujo contiene una serie de entradas de flujo

Cada tabla de flujo contiene un set de instrucciones que se ejecutan cuando el

3.2 Funcionamiento de OpenFlow

Mensajes del protocolo OpenFlow

El protocolo consiste en 3 tipos de mensajes: controlador a switch, asncrono y

3.2 Funcionamiento de OpenFlow

Enviar al controlador el paquete que no coincide con los flujos existentes.

Figura 3.2: Proceso de matching

Veamos como se comportara un switch OpenFlow (S1 ), en el supuesto de que el

3.3 Probando OpenFlow

Figura 3.3: Topologa

Figura 3.4: PACKET_IN

3.3 Probando OpenFlow

Figura 3.5: PACKET_OUT a

Figura 3.6: FLOW_MOD a

3.3 Probando OpenFlow

Figura 3.7: PACKET_OUT b

Figura 3.8: FLOW_MOD b

3.3 Probando OpenFlow

Figura 3.9: Ultimos paquetes

Figura 3.10: Wireshark Packet-in y Flow-mod

Como hemos visto anteriormente un controlador bsicamente aade y elimina

Figura 4.1: OpenDaylight Helium

Ryu es un componentes bsico de las redes definidas por software. Provee de

The AD-SAL typically has both NB and SB

Limited to flow-capable device and service

Request Routing in the MD-SAL is done on

MD-SAL can store data for models defined by

Tabla 4.2: AD-SAL vs MD-SAL

Figura 4.2: Floodligh

Ventajas e inconvenientes de Mininet