Redes Virtuales Distribuidas Basadas en Openflow, Hacia La Internet Del Futuro - Virtual Distributed Network Based On Openflow, Towards The Future Internet

UNIVERSIDAD DE MURCIA
FACULTAD DE INFORMÁTICA
Máster en Nuevas
Tecnologías en Informática
Memoria del Trabajo Fin de Máster
Itinerario de Redes y Telemática:
Virtual Distributed Networks Based on OpenFlow,

Toward the Future Internet
Redes Virtuales Distribuidas Basadas en OpenFlow,

Hacia la Internet del Futuro
Autor:
José Bastida García
Jbg3@um.es
Tutores:
D. Antonio Fernando Skarmeta Gómez
D. Pedro Martínez-Juliá
Murcia, 13 de Septiembre de 2013

2 José Bastida García
Máster en Nuevas Tecnologías en Informática

Redes Virtuales Distribuidas Basadas en OpenFlow, Hacia la Internet del Futuro 3
“Piensa de OpenFlow como el conjunto de instrucciones x86. ¿Es el conjunto x86 la mejor
repuesta? No, es lo suficientemente bueno para que lo usemos, ¿entonces porque cambiarlo?
Esto es un símil a lo que ocurre con OpenFlow. Es el conjunto de instrucciones que se ha
desarrollado para utilizar, nosotros no vamos a quedarnos atascados en conseguir que sea
el estrictamente mejor. “– Scott Shenker UC Berkely
* * * *
“Think of OpenFlow as the x86 instruction set. Is the x86 instruction set the right answer? No,
its good enough for what we use it for, then why bother changing. Thats what OpenFlow is. It’s
the instruction set that we happen to use, but we shouldn’t get hung up on getting it exactly
right.” – Scott Shenker UC Berkely

ÍNDICE GENERAL
RESUMEN ..................................................................................................................................... 8
ABSTRACT .................................................................................................................................... 9
PRÓLOGO ................................................................................................................................... 10
1. INTRODUCCIÓN .......................................................................................................... 11
1.1. VIRTUALIZACIÓN ............................................................................................................... 13

1.2. LA RED............................................................................................................................. 15
1.2.1. Cuestiones al modelo ............................................................................................. 16
1.2.2. Evolución del modelo ............................................................................................. 18
1.2.3. Extender la red en la capa de virtualización: redes definidas por software ......... 21
2. ANÁLISIS DE OBJETIVOS Y METODOLOGÍA ................................................................... 25
2.1. DESAFÍOS ......................................................................................................................... 25

2.1.1. Entornos múltiple arrendatario escalables .......................................................... 25
2.1.2. Requisitos de movilidad de las máquinas virtuales ............................................... 25
2.1.3. Extensión de las redes virtuales ............................................................................. 26
2.1.4. Tamaño de las tablas de encaminamiento............................................................ 26
2.1.5. Desacoplamiento de la configuración lógica y física ............................................. 26
2.1.6. Comunicaciones entre máquinas virtualizadas y no virtualizadas ....................... 27
2.1.7. Transición a IPv6 .................................................................................................... 27
2.2. VIRTUALIZACIÓN DE LA RED, PROPUESTA OVERLAY .................................................................. 29
2.3. ANÁLISIS Y CONTRIBUCIÓN .................................................................................................. 31
2.3.1. Redes Definidas por Software: SDN y OpenFlow ................................................... 32
SOFTWARE-DEFINED NETWORK ............................................................................................................................... 32
OPENFLOW ......................................................................................................................................................... 33
ENCAMINAMIENTO VIRTUALIZADO ASISTENCIA HARDWARE ............................................................................................. 36
ENCAMINAMIENTO VIRTUALIZADO ASISTENCIA SOFTWARE .............................................................................................. 41
2.3.2. Método de contribución al proyecto ..................................................................... 46
3. DISEÑO Y RESOLUCIÓN CASO PRÁCTICO: OPENFLOW NETWORK .................................. 47
3.1. MININET, SOFTWARE DE EXPERIMENTACIÓN LOCAL PARA SDN ................................................. 50

3.1.1. Definir topología de red, mininet 2.0 .................................................................... 50
3.2. OFELIA, INFRAESTRUCTURA EXPERIMENTACIÓN BASADA EN OPENFLOW.................................... 64
3.2.1. Definir red de experimentación con Ofelia Control Framework ........................... 68
3.3. ANÁLISIS DE LA EXPERIMENTACIÓN CON SDN Y OPENFLOW ..................................................... 73
4. CONCLUSIONES Y VÍAS FUTURAS: ................................................................................ 79
5. REFERENCIAS .............................................................................................................. 82

APÉNDICE: ......................................................................................................................... 88
A.1. ENCAMINAMIENTO VIRTUALIZADO ASISTENCIA DE LA RED ........................................................ 88

 VPN (Virtual Private Network) ...................................................................................... 88
 OpenVPN (Virtual Private Network) ............................................................................. 88
 GRE Encapsulation Tunneling ....................................................................................... 89
 STT (Stateless Transport Tunnel) .................................................................................. 89
 MPLS (Multi Proposal VPN)........................................................................................... 90
 GMPLS (Multi Proposal VPN) ........................................................................................ 91
A.2. SOFTWARE-BASED VIRTUAL SWITCHES .................................................................................. 93
 VDE, Virtual Distributed Ethernet ................................................................................. 93
 Cisco Nexus V1000 ........................................................................................................ 94
 Microsoft Hyper-V extendible switch ............................................................................ 94
 Open vSwitch ................................................................................................................ 95
 OpenFlow Switch .......................................................................................................... 96
A.3. OPENFLOW CONTROLLERS...................................................................................................... 96
 OpenFlow Reference controller..................................................................................... 96
 NOX/POX ....................................................................................................................... 96
 SNAC ............................................................................................................................. 97
 RYU................................................................................................................................ 98
 FloodLight ..................................................................................................................... 99
A.4. SOFTWARE ÚTIL EN LOS LABORATORIOS ............................................................................. 100

ÍNDICE DE ILUSTRACIONES:
ILUSTRACIÓN 1: .......................................................................................................................................... 13
ILUSTRACIÓN 2: .......................................................................................................................................... 16
ILUSTRACIÓN 3: .......................................................................................................................................... 19
ILUSTRACIÓN 4:. ......................................................................................................................................... 20
ILUSTRACIÓN 5: .......................................................................................................................................... 23
ILUSTRACIÓN 6: .......................................................................................................................................... 28
ILUSTRACIÓN 7: .......................................................................................................................................... 30
ILUSTRACIÓN 8: .......................................................................................................................................... 32
ILUSTRACIÓN 9: .......................................................................................................................................... 33
ILUSTRACIÓN 10: ........................................................................................................................................ 34
ILUSTRACIÓN 11: ........................................................................................................................................ 35
ILUSTRACIÓN 12: ........................................................................................................................................ 37
ILUSTRACIÓN 13: ........................................................................................................................................ 39
ILUSTRACIÓN 14: ........................................................................................................................................ 39
ILUSTRACIÓN 15:. ....................................................................................................................................... 40
ILUSTRACIÓN 16: ........................................................................................................................................ 42
ILUSTRACIÓN 17: ........................................................................................................................................ 44
ILUSTRACIÓN 18: ........................................................................................................................................ 47
ILUSTRACIÓN 19: ........................................................................................................................................ 48
ILUSTRACIÓN 20: ........................................................................................................................................ 49
ILUSTRACIÓN 21: ........................................................................................................................................ 50
ILUSTRACIÓN 22: ........................................................................................................................................ 51
ILUSTRACIÓN 23: ........................................................................................................................................ 52
ILUSTRACIÓN 24: ........................................................................................................................................ 52
ILUSTRACIÓN 25: ........................................................................................................................................ 54
ILUSTRACIÓN 26: ........................................................................................................................................ 55
ILUSTRACIÓN 27: ...................................................................................................................................... 56
ILUSTRACIÓN 28: ........................................................................................................................................ 58
ILUSTRACIÓN 29: ........................................................................................................................................ 58
ILUSTRACIÓN 30: ........................................................................................................................................ 60
ILUSTRACIÓN 31: ........................................................................................................................................ 61
ILUSTRACIÓN 32: ........................................................................................................................................ 61
ILUSTRACIÓN 33: ........................................................................................................................................ 63
ILUSTRACIÓN 34: ........................................................................................................................................ 63
ILUSTRACIÓN 35 : ....................................................................................................................................... 64
ILUSTRACIÓN 36: ........................................................................................................................................ 65
ILUSTRACIÓN 37: ........................................................................................................................................ 66
ILUSTRACIÓN 38: ........................................................................................................................................ 67
ILUSTRACIÓN 39: ........................................................................................................................................ 68
ILUSTRACIÓN 40: ........................................................................................................................................ 70
ILUSTRACIÓN 41: ........................................................................................................................................ 71
ILUSTRACIÓN 42: ........................................................................................................................................ 71

ILUSTRACIÓN 43: ........................................................................................................................................ 72

ILUSTRACIÓN 44: ........................................................................................................................................ 73
ILUSTRACIÓN 45: ........................................................................................................................................ 73
ILUSTRACIÓN 46: ...................................................................................................................................... 76
ILUSTRACIÓN 47: ........................................................................................................................................ 78
ILUSTRACIÓN 48: ........................................................................................................................................ 78
ILUSTRACIÓN 49: ........................................................................................................................................ 81
ILUSTRACIÓN 50: ........................................................................................................................................ 89
ILUSTRACIÓN 51: ........................................................................................................................................ 92
ILUSTRACIÓN 52: ........................................................................................................................................ 93
ILUSTRACIÓN 53: ........................................................................................................................................ 95
ILUSTRACIÓN 54: ........................................................................................................................................ 97
ILUSTRACIÓN 55: ........................................................................................................................................ 98
ILUSTRACIÓN 56: ...................................................................................................................................... 100
ILUSTRACIÓN 57: ...................................................................................................................................... 102
ILUSTRACIÓN 58: ...................................................................................................................................... 102
ILUSTRACIÓN 59: ...................................................................................................................................... 103

RESUMEN
La expansión de los dispositivos móviles y el contenido digital, la virtualización de
servidores y la llegada de los servicios en “la nube”, son algunas de las tendencias que
impulsan la industria del networking a reexaminar las arquitecturas de red tradicionales.
Redes convencionales jerárquicas, con capas de switches Ethernet dispuestos en una
estructura arbórea.
Sometidos a la continua mejora de la virtualización de sistemas y los hábitos de consumo
del modelo actual de Internet [5][6][10], surgieron diversos proyectos cuyo objetivo era
abstraerse de los niveles de red y formar una capa virtual distribuida por encima de las
heterogeneidades de la red física ( concepto Overlay Networks).
En el desarrollo del proyecto que aquí presentamos, analizaremos algunos de las
herramientas que surgieron de este concepto, capaces de abstraer y manejar los servicios
de nivel de enlace sobre el sistema operativo. Este avance complementa a la virtualización
de sistemas añadiendo la flexibilidad y escalabilidad de añadir recursos virtuales desde una
perspectiva uniforme, sencilla y estandarizada.
El trabajo está orientado al estudio y análisis técnico de las herramientas de virtualización
del nivel de enlace distribuidas, con el propósito de plantear una evolución del modelo
convencional de la red de una forma no disruptiva. Nos introduciremos en la virtualización
distribuida del nivel de enlace a la red, teniendo en cuenta los nuevos desafíos: el modelo
multi-arrendamiento de los recursos, servicios extremo a extremo, el agotamiento de
direcciones y la coexistencia IPv4 e IPv6. Estos son los frentes para experimentar hacia el
Internet del futuro.
OpenFlow es la propuesta tangible al nuevo paradigma de la red definida por software.
Complementando al estudio teórico veremos con escenarios prácticos la evaluación de las
herramientas. Conclusiones de los ejemplos son válidas para experimentación con nuevos
protocolos, transición e interconexión con redes convencionales, implantación de
mecanismos extremo a extremo, la extensión de la red sobre nuevos medios, etc... Tales que
comencemos a considerar estas herramientas o complementos a estas para nuevos desafíos
sirviendo de nexo a un modelo de futuro.
* * * *

ABSTRACT
The explosion of mobile devices and content, server virtualization, and advent of cloud
services are among the trends driving the networking industry to reexamine traditional
network architectures. Many conventional networks are hierarchical, built with tiers of
Ethernet switches arranged in a tree structure.
Subjected to continuous improvement of system virtualization and consumption habits of
the current Internet model, emerged several projects aimed to get an abstraction of link
layer to create a virtual layer distributed over the heterogeneities of the physical network
(Overlay networks layers).
In developing the project shown here review some of the tools that emerged from this
concept, able to abstract and manage the link layer services on operating system
application. This progress complements the system virtualization adding flexibility and
scalability to add virtual resources where we connect.
This job is oriented to study with a technical analysis the virtualization distributed link level
tools, in order to raise an evolution of the conventional model of the network in a non-
disruptive. We introduce virtualization distributed link level to the system, taking into
account new challenges: multi-tenancy model of resources, end to end services and address
exhaustion IPv4 and IPv6 coexistence. These are the mainly fronts to tackle experience the
future internet (FI).
Based on actual proposal OpenFlow as implementation as the paradigm of software defined
network, we will complement the theoretical study with practical scenarios to evaluate
tools. The conclusions of the examples are valid to experiment with new protocols,
transition and interconnection with conventional networks, implementation of end-to-end
mechanisms for the extension of the network on new media, and so on. Those who begin to
consider these tools or additions to these serving as a link to a future model.
* * * *

PRÓLOGO
Este trabajo de investigación tecnológica está estructurado en cuatro bloques. En el primer
capítulo, se presenta el estado del arte y contextualiza la situación en el ámbito de la
virtualización, enfocada a solventar los problemas del modelo de red tradicional. El
segundo capítulo, concreta el ámbito para el cual competen las necesidades y desarrolla un
análisis- teórico de las herramientas para alcanzar esas propuestas, mitigar y/o paliar los
desafíos planteados. Profundizamos en cómo utilizar estas herramientas software y que
nos brinda el hardware para hacer frente a los desafíos que se plantean con escenarios
prácticos en el capítulo tercero, correspondiente al bloque empírico-analítico; con
herramientas concretas que giran en torno a OpenFlow y sus posibilidades. En este último
desarrollo pretendemos recrear escenarios de experimentación con dos herramientas:
MININET para un laboratorio local y OFELIA como ejemplo de despliegue físico.
Finalizando con el cuarto capítulo de conclusiones y vías de investigación futuras que abre
esta línea de trabajo y nuevas que se proponen.
El alcance de este proyecto es realizar un estudio profundo de las tecnologías de
virtualización en el nivel de enlace para escenarios distribuidos, del funcionamiento de
estas y de sus componentes o módulos, que nos permitirán abordar los desafíos expuestos.
Entre las novedades que este trabajo recoge destaca, la investigación y el seguimiento de
cómo han evolucionado los diferentes proyectos y asociaciones en torno a estos. Con la
intención de que sirva como trabajo de referencia para futuras investigaciones así como
reflexión para la planificación del internet del futuro.
Trabajos de investigación se han complementado y extrapolado del ámbito de la
investigación a entornos reales en muy poco tiempo dadas las grandes expectativas que
despierta la red definida por software (Software-Defined Networks) sufragados y
potenciados por las grandes compañías del sector y universidades. Al mismo tiempo que
esto potencia el rápido avance también puede llevar a una fragmentación por intereses
propios de un modelo que se planteó inicialmente abierto. Aquí pretendemos establecer un
rigor y a la vez concretar el nexo entre los modelos disruptivos que investigan el futuro
Internet y los desafíos actuales que se pretenden mitigar, teniendo en cuenta que el futuro
surge de como abordemos estos en el presente.
Estos modelos plantean un nivel de abstracción sobre la tecnología subyacente con capas
que ofrecen servicios extremo a extremo, la virtualización de los recursos no solo nos puede
proveer de laboratorios gigantes como GENI u OFELIA (con el cual trabajaremos en el
apartado práctico) sino que pueden causar el efecto “ARPANET contemporáneo” en la forma
de concebir la red.

1. INTRODUCCIÓN
El significado de la palabra “virtual” tiene entre sus acepciones la que se refiere a algo que
físicamente no existe pero lo aparenta, es decir, parece real. En la ciencia de la computación
entendemos por virtualización cuando una herramienta software no está ejecutándose
directamente sobre el hardware sino sobre una abstracción del mismo, que veremos como
una máquina virtual.
Los méritos hardware de la computación actual con altas prestaciones para virtualización
y la adecuación de los recursos en busca de la máxima eficiencia de los mismos se implantan
o explotan hoy día. Concretamente la virtualización frente a la emulación consigue un
rendimiento más próximo al que ofrecería el sistema operativo directamente sobre el
hardware del equipo anfitrión, permitiendo albergar según la capacidad de esta máquina
más VMs (Virtual Machines), dando más rendimiento a nuestro hardware y haciéndolo más
flexible.
La virtualización ofrece a cada programa que se ejecuta sobre la máquina virtual la ilusión
de que tiene su propio hardware para ejecutarse (procesador, memoria, unidades de
almacenamiento, etc.). Para esto, la VM es dependiente de esta tecnología de virtualización.
Cada máquina virtual reside finalmente en lo que se conoce como un Hypervisor o Virtual
Machine Monitor (VMM), que abstrae los recursos físicos de forma lógica para presentarlos
a las distintas máquinas virtuales (también llamados huéspedes) de los cuales tiene que
gestionar la coexistencia y seguridad en el mismo entorno hardware. [2][42]
Las técnicas de virtualización de CPU (central processor unit) han evolucionado
rápidamente en la última década pero no tanto la virtualización de dispositivos para redes
que ha quedado en la zaga. La premisa de conseguir la virtualización completa, donde la VM
se comporta idealmente como si todos los componentes funcionaran sobre el propio
hardware que se le presta, permanece en el trasfondo de los avances que se realizan en éste
área. En busca de que la interacción con el resto de dispositivos sea lo más “real” posible
evitando así emulaciones e indirecciones. Hay importantes avances en el sector de los
microprocesadores con soporte de instrucciones específico para mejorar el rendimiento
con dispositivos de entrada – salida virtualizados. [40][41].
Complementando a las herramientas software de virtualización de sistemas surgen nuevos
proyectos, algunos en acuerdo con fabricantes de electrónica de red otros fruto de
proyectos universitarios, con el objetivo de virtualizar los recursos de electrónica de red
principalmente de nivel 2-3. Este punto de vista añade nuevas posibilidades principalmente
de flexibilidad a los entornos con máquinas virtualizadas.
Actualmente en los centros de datos se ofrecen servicios que tienen que ser ampliables bajo
demanda, de manera que se optimice desde el consumo energético del centro hasta los
propios recursos de los equipos anfitrión según el desempeño. Es probable que un centro
necesite coordinarse o recurrir a otra sede para cubrir con este propósito en ciertas

ocasiones como por ejemplo desplegar nuevas VMs ante un incremento estacionario en la
demanda de sus servicios, ofrecer mejor disponibilidad de sus servicios en un nuevo
mercado lejos del habitual o recurrir a una rápida recuperación ante desastres por medio
de servicios de respaldo. Estos recursos que no tienen por qué estar físicamente conectados
en el mismo CPD (centro de procesamiento de datos) pueden estar ubicados
estratégicamente o por otras circunstancias por acuerdos establecidos en otro lugar,
obligando en estos casos a establecer relaciones inter-dominio seguras y aislados a la vez
de otros procesos distribuidos que concurren por el mismo hardware.
La interconexión virtual brinda la posibilidad de obtener una vista de los recursos en una
capa de red elevada sobre la red física existente. Esto es lo que nos ofrecen las herramientas
de virtualización de nivel de enlace distribuidas. Esto complementa a los sistemas de
virtualización, permitiendo conectar VMs físicamente distantes. Este concepto de plano
virtual que se abstrae de los mecanismos de interconexión subyacentes, a través del cual
estemos conectados es a lo que nos referiremos con extender la red que veremos
detenidamente cuando hablemos de Overlay Networks.
Nos referiremos generalmente al término en inglés switch en lugar de conmutador de red a
lo largo del documento, por ser un concepto genérico muy acuñado en la técnica que
estudiamos.
La virtualización a nivel de enlace surge para “virtualmente” conectar cada VM a un puerto
de ese switch virtual que podremos implementar en software o hardware como
estudiaremos.
En el desarrollo del proyecto analizaremos algunos de las herramientas que surgieron de
este concepto, capaces de abstraer y manejar los servicios de nivel de enlace sobre el
sistema operativo. Este avance complementa a la virtualización de sistemas añadiendo la
flexibilidad y escalabilidad de añadir recursos virtuales donde conectarnos.
El trabajo está orientado al estudio y análisis técnico de las herramientas de virtualización
a nivel de enlace distribuidas con el propósito de construir Virtual Distributed Networks
towards Future Internet. Añadiendo con la realización de escenarios prácticos conclusiones,
teniendo en cuenta escenarios que cumplan con los requisitos del Futuro Internet, tales que,
sirvan para considerar o adoptar un tipo de herramienta o complementos a estas según el
tipo de red subyacente y el esquema final.
Veamos los precedentes de las tecnologías a las que nos referiremos en el estudio y
contrastaremos los propósitos de uso actuales con los principales para los que fueron
diseñados para considerar las tendencias de estas.
Así centrar el objetivo de este proyecto en el que las tecnologías de virtualización y la red
convergen con perspectivas a corto y largo plazo para un modelo de Internet de futuro y la
investigación con nuevos escenarios.

1.1. VIRTUALIZACIÓN
A mediados de los años 60, IBM desarrolló el sistema operativo CP-67 que ya introdujo el
concepto de máquina virtual, era el primer intento de IBM, que fue el precursor de la
tecnología del VM/370, producto que maduraba esta tecnología ya por los años 70. El
objetivo era claro, dividir lógicamente los recursos de los sistemas mainframe para
ofrecerlos con la misma interfaz que el hardware real, esta interfaz se ejecutaba sobre el
software de control Control Program, encargado de comunicarse con la máquina real de
forma segura y manteniendo aislado el espacio del usuario, evitando que pudiera causar
daños a otros.
Los sistemas mainframe tenían importante capacidad de computación y empezaron a

pensar que el host tuviera unas particiones. A mediados de los 70 denominaban a estas
arquitecturas de 3ª generación donde continuó extendiéndose el término de VM [43]. El
sistema operativo que hasta entonces IBM llamaba “Supervisor” como otros sistemas
llamaban “monitor”, evolucionó al termino Hypervisor, pues era capaz de gestionar varios
sistemas operativos. Dando la posibilidad de que estas máquinas grandes y caras fueran
utilizadas al mismo tiempo por muchos usuarios, dando a cada uno de ellos su propio
sistema operativo llamado entonces CMS (Conversational Monitor System) con la capacidad
de aumentar en gran medida la utilización del hardware mediante la ejecución de muchas
aplicaciones a la vez.
El problema de la implementación de un sistema de tiempo compartido que permiten que
varios usuarios tener acceso al mismo equipo al mismo tiempo no era fácil de resolver. La
mayoría de los ingenieros estaban tomando los sistemas tradicionales de explotación de
lotes y hacer más interactiva para permitir que varios usuarios entran en el sistema, pero el
propio sistema operativo se convirtió en extremadamente complejo [21]. El equipo de IBM
de ingeniería en Cambridge, Massachusetts, se le ocurrió un nuevo enfoque que le dio a cada
usuario una máquina virtual (VM), con un sistema operativo que no tiene por qué ser
complejo, ya que sólo tiene que dar soporte a un usuario.
Ilustración 1: Ejemplo consola de login de CMS.
En sus primeros años la virtualización daba varias copias del sistema anfitrión con recursos
limitados, asegurando la compatibilidad del software de forma aislada y con un rendimiento

comparable con el original. Pero años después con la introducción de los sistemas
operativos multiusuario, la madurez de la arquitectura x86 y el modelo cliente servidor que
tuvieron mucha aceptación en los años 80, junto a la proliferación de los equipos personales
relegaron el concepto de virtualización. Este concepto surgió de nuevo con la tecnología
Java, que abordaba el acoplamiento para los desarrolladores de software a una arquitectura
concreta con el concepto de Java de multiplataforma. Actualmente muy extendido el código
Java se compila para un intérprete Java llamado Java Virtual Machine (JVM) que traducirá
en tiempo de ejecución las solicitudes a la arquitectura concreta del host. Esto permite
portar el software a cualquier plataforma que tenga la JVM. Este concepto tiene una filosofía
compartida ya que hay una capa intermedia entre el sistema operativo y el hardware para
las aplicaciones que se desarrollan con esta tecnología, pero no al mismo ámbito de la
virtualización de los recursos hardware del concepto de máquina virtual de los 70.
Pero de nuevo en los años 90 nos encontramos que estaba llegando al momento en que la
unidad de proceso central empezaba a desaprovechar recursos. Llegando a una situación
similar al de los años 60 con la excepción de que el hardware se había abaratado, pero las
posibilidades de virtualizar sistemas obsoletos, entornos de desarrollo para pruebas de
otros entornos ganaba interés. Aquí es donde la virtualización se retoma de nuevo.
VMware se hizo popular con la virtualización de servidores x86 en 1999 [42]. Desarrollando
una técnica que interfiere, adapta y convierte en instrucciones seguras aquellas que puedan
comprometer el espacio de usuario para la VM, dejando el resto de instrucciones trabajar
de forma original en binario sobre el hardware.
La virtualización ofrece grandes mejoras y ventajas respecto a un sistema de hardware
nativo que destacamos:
 Ahorro: Mejora substancialmente el aprovechamiento de los recursos de hardware,
lo que se traduce en un gran ahorro en cuanto a coste del hardware y también un
ahorro en cuanto a energía consumida y espacio.
 GreenIT: Al reducir el número de máquinas, reducimos la cantidad de energía
utilizada, no sólo en alimentar el servidor sino que también se reduce el consumo de
refrigeración tanto eléctrico como las emisiones de aire caliente.
 Flexibilidad: En una misma máquina podemos tener funcionando juntos un sistema
operativo Windows y un sistema basado en GNU Linux.
 Escalabilidad y tiempo de funcionamiento: La virtualización ofrece un sistema
totalmente homogéneo a las máquinas virtuales.
Dependiendo del hardware y del sistema operativo podemos distinguir hasta cuatro tipos
de virtualización diferentes:
 Emulación o simulación: el sistema operativo padre simula un hardware completo,
esta simulación hace que el rendimiento de la máquina virtual sea bastante menor.
 Virtualización a nivel de Sistema Operativo: Algunas comunidades no lo incluyen
dentro de la definición de virtualización como tal, porque se basa en crear celdas de

usuarios independientes, sin acceso entre ellas pero que comparten el mismo
sistema operativo y aplicaciones.
 Paravirtualización: la máquina virtual no simula un hardware, sino que ofrece una
interfaz al sistema que sólo puede usarse mediante la modificación del kernel del
sistema operativo de la máquina virtual. . La paravirtualización se utiliza
únicamente con sistemas operativos basados en GNU/Linux y BSD, ya que estos
permiten la modificación del kernel, en el caso de Windows y MAC OSX no es posible
ya que al ser propietario no es posible estas modificaciones.
 Virtualización nativa o completa: la máquina virtual simula un hardware
subyacente completo para permitir instalar un sistema operativo sin modificar en
la máquina virtual. La Máquina Virtual desconoce la existencia del entorno
virtualizado y como no requiere ser modificado es posible instalar cualquier sistema
operativo compatible con el hardware.
Las mejoras en el hardware con propósito específico (virtualización asistida por hardware)
han permitido que una máquina virtual se ejecute en un anfitrión sin incurrir en
penalizaciones de emulación y sin hacer modificaciones en el sistema operativo huésped.
El panorama de las herramientas de virtualización ahora es muy amplio y con diferentes
posibilidades tales como virtualización completa de sistemas operativos o virtualizaciones
parciales para procesos concretos. [2][7][25]
1.2. LA RED
Entre los significados de la palabra red reseñamos el de conjunto de elementos organizados
para determinado fin. Sin embargo, a aquellos que estén familiarizados con las nuevas
tecnologías (no necesariamente en el ámbito de la ciencia) hablar de la red, seguramente
estarían refiriéndose a Internet.
En nuestro propósito vamos a concretar la definición general refiriéndonos a la
interconexión de redes o al término suficientemente acuñado networking para definir red
como un conjunto de dispositivos (interconectados) que pueden comunicarse los unos con
los otros mediante el uso de algún protocolo.
Mucho han cambiado las expectativas de uso de Internet desde su desarrollo en la década
de los 70. El protocolo IP (Internet Protocol) recogido el RFC 791, es el que
organiza/estructura a los elementos que conforman la Red. Se diseñó utilizando
direcciones de 32 bits, que permiten identificar hasta unos 4 mil millones de terminales
diferentes. Terminales que antes no se pensaron fueran a cambiar en la infraestructura de
forma continua. Señalamos esto porque, aproximadamente un 71% de la población mundial
tiene teléfono móvil (cinco mil millones de personas), vemos una rápida evolución si lo
comparamos con años anteriores destacando que a finales de 2008 esta cifra rondaba el
cincuenta por ciento y que actualmente el número de estos usuarios con conexión a Internet
móvil es de aproximadamente de 2 mil millones y crece diariamente [105]. Este
crecimiento ha repercutido en las necesidades de ancho de banda (que ha sido el

exponencial), ligado al aumento del número de usuarios y el incremento del número de

aplicaciones de Internet. En nuestros días, el tráfico de datos supera al tradicional tráfico de
voz, lo cual ha suscitado un interés sin precedentes en IP; que ha sido ampliado para
soportar todo tipo de servicios que hoy día mantiene. De este modo, es entendible que la
convergencia de la capa IP y la capa óptica, inicialmente diseñada para el transporte de
servicios telefónicos de conmutación de circuitos, sea el tema central de la siguiente fase de
expansión de Internet.
Ilustración 2: “Networking of information”. [44]
Internet es un tejido artificial de contenidos como hoy día lo conocemos y se ha convertido

en uno de esos cambios que repercuten socioculturalmente en la evolución humana; un
cambio en las formas de organización, culturización y comunicación de los individuos que
ocurren cada cientos e incluso miles de años.
Realizamos una investigación evolutiva con el objetivo entender el comportamiento del
Internet actual, identificar los problemas existentes o emergentes, y resolverlos de acuerdo
con dos grandes limitaciones: la compatibilidad retrasada ‒inter-operar sin problemas con
la arquitectura heredada de Internet‒, y la implementación incremental ‒ se debe utilizar
un nuevo protocolo o tecnología como principio, incluso si no está implementado a nivel
mundial ‒ [4]. La investigación de borrón y cuenta nueva tiene como objetivo diseñar una
nueva arquitectura para el “Internet del futuro”, que sea significativamente mejor ‒en
términos de rendimiento, seguridad, resistencia y otras propiedades‒ que la que utiliza el
Internet actual y sin verse limitada por su misma arquitectura. [5][6].
Aunque el enfoque principal de este proyecto está enfocado a virtualizar la capa con los
recursos de red, es necesario hacer un análisis a lo que afecta por tratarse de un modelo
fuertemente acoplado a IP.
1.2.1. CUESTIONES AL MODELO
Comenzando por los contras actuales, a continuación se enumeran los puntos más
relevantes que nos conducen a cambiar el planteamiento del actual modelo masivamente
implantado:

 Direccionamiento
Comenzando con la primera generación de IP asignadas en clases, de tipo A, B, C y el

mal uso del direccionamiento en Internet por las operadoras a posteriori ha provocado
disrupción y desaprovechamiento de las direcciones en toda la red. Los problemas han
ido incrementándose con el escalamiento tan drástico de la red y el direccionamiento
no conforme con la topología tendiendo incluso al abandono del modelo CIDR
(Enrutamiento entre dominios sin Clase) que conseguía un alto nivel de agregación de
direcciones ligadas a una ubicación de red. Esto ha generado un incremento
exponencial en las tablas de encaminamiento e inversiones en hardware más
potente para el mantenimiento de las mismas.
La introducción de NAT obliga a renunciar al paradigma extremo a extremo de las

aplicaciones de Internet, que pasan a tener un dispositivo intermediador entre los
extremos. Desde dentro de una red privada, es decir desde detrás de un NAT, sólo se
puede acceder como cliente a algunos servicios de la Internet pública, como Web o
correo electrónico.
Además de NATs, se han introducido otros elementos intermedios, como por ejemplo,
los firewalls, proxys y cachés transparentes, que introducen aún más problemas para el
diseño y correcto funcionamiento de muchas aplicaciones.
 Privacidad
Internet está compuesto por dos espacios de nombres, direcciones IP y nombres FQDNs
(Fully Qualified Domain Names) que utilizan los DNS (Domain Name Server) para
resolver la dirección IP asociada. Las direcciones IP son usadas tanto para referenciar
las interfaces de red como los nombres de las localizaciones de los servicios o equipos.
Además, las distintas interfaces de los dispositivos disponen de distintas direcciones
IPs, y estas IPs pueden variar cada vez que el terminal se conecta a la red. Los espacios
de nombres actuales acarrean tres problemas principalmente:
o La reasignación dinámica de direcciones no puede ser gestionada

directamente
o El anonimato no se puede ofrecer de forma consistente y confiable
o No se provee de autenticación para sistemas y datagramas
 Multihoming
El aumento de niveles de multihoming en Internet actualmente produce un

incremento en tamaño de las tablas de enrutamiento que tienen que mantener los
proveedores de servicios para anunciar donde se dirigirse para resolver aquellos
prefijos que no están contenidos dentro de su red y así sucesivamente. El crecimiento
de las tablas de enrutamiento de Internet y la rotación que estas excede la regla de la

Ley de Moore. Incrementando el costo de routers para mantener la capacidad al día y la

desaceleración de la convergencia de Internet. Por otra parte, las direcciones de internet
deben ser gestionadas y reasignadas a medida que cambia la topología de la red a lo
largo del tiempo.
 Host Movility
Hay una amplia variedad de soluciones a este problema en la literatura, pero la

mayoría de ellos confían en la reasignación de direcciones basadas en la topología y el
mantenimiento de un servicio similar a DNS para resolver la correspondencia entre la
identidad de un host y como localizarlo.
 Control de Acceso
En general para los ISP se incrementa la necesidad de configurar reglas incluidos

controles y políticas de acceso. Hoy día estas reglas se manejan en base a la tabla de
direcciones. Dados los cambios que se producen en la estructura de red, estas reglas
necesitan ser actualizadas también si se producen cambios.
 Privacidad
Actualmente una dirección de red es utilizada tanto por los equipos de

encaminamiento en la red como para identificar en un mensaje la dirección del nodo
origen hacia qué dirección destino se envía un mensaje.
El actual uso de una dirección IP para identificar origen y destino además de para
encaminarlo (localizador) presenta hoy día problemas de privacidad ya que la
información de emisor y receptor viaja en el mensaje que puede ser trazado e incluso
interceptado, esto puede tener consecuencias con respecto a la integridad de los datos
o a la seguridad que esta información puede revelar a atacantes.
1.2.2. EVOLUCIÓN DEL MODELO
La masiva implantación de este modelo, desde el punto de vista de la ciencia lastra la mejora
de una arquitectura de Internet que desde las perspectivas de consumo actual necesita un
rediseño, las necesidades son distintas a las de su origen. Visto desde otro ángulo con la
explotación masiva de la infraestructura actual resurge la necesidad de plantear soluciones
acorde al uso que hacemos de la red hoy y que haremos en el futuro. Finalmente acaban
adoptándose “parches” que requieren modificaciones y compatibilidad hacia atrás para una
evolución del modelo, ahora móvil y que demanda flexibilidad, como reflejan las cifras
anteriores de usuarios conectados a servicios a la red.
La convergencia a que todo sea accesible desde Internet esta acoplada a la dirección IP que
tienen asignada los terminales que participan en la red. En escenarios que requieren
cambios (posición, medio de trasmisión, domino, etc.), supone que, reiteradamente estemos

limitados a mantener la persistencia de las conexiones extremo a extremo ante cambios en

el nivel de red. Visto desde el uso actual de la Red como proveedores y consumidores de
servicios (fundamentalmente información) desde cualquier lugar, surge la necesidad de
añadir mecanismos que reduzcan la complejidad y aumentar la flexibilidad para que
servidores y clientes continuamente moviéndose puedan conectarse a estas capas
(enfoquémoslo como virtuales) de servicios cuyos nodos quedan distribuidos
geográficamente. Estas ventajas a nivel de enlace se pueden escalar de forma dinámica
desde el software que maneja la topología de la red.
Debemos enmarcar aquello que demanda un nuevo diseño como objetivo y analizar la
evolución del modelo actual que analizaremos en el siguiente apartado. Esta problemática
del modelo actual genera controversia y diferentes puntos de vista (algunos más disruptivos
que otros):
 Empezar desde cero; Clean Slate
Aceptar la necesidad de un cambio profundo desde cero, nuevos paradigmas,

dispositivos que se plantean que estén instaurados en el futuro. Enfocado al actual uso
actual de Internet, con las consecuencias de interrupción de servicio, migración y
económicas.
 Abstracción sobre la actual topología; Concepto Overlay Network
Una red a nivel superior overlay que resuelva los problemas subyacentes y prorrogar
la adaptación de forma progresiva hacia niveles inferiores, dependiendo del éxito.
Hoy en día conocemos algunos modelos de redes con un fin concreto (centradas en la
información que trasportan) superpuestas sobre la capa de transporte sobre un red
subyacente heterogénea. Esta abstracción del nivel IP, conocida como redes overlay
también funcionan aplicando almacenamiento y reenvío de paquetes entre agentes de
la red overlay. Ejemplos de este tipo de redes conocidos fueron creados con el propósito
de diseminar información como Akamai CDN, BitTorrent, Skype, Joost, etc.
Ilustración 3: Modelo de Overlay Network [45]

 Crear un modelo de red a un nivel superior; Concepto Underlay
Sobre el que la que redes Overlay aisladas compitan. En el apartado siguiente se

presenta con un ejemplo concreto un modelo sustentado en esta idea.
 Virtual Networks
Alternativa compatible a la vez con las anteriores para desarrollar nuevos

protocolos y escenarios sobre recursos de red virtualizados, al mismo tiempo de
permitir el desarrollo de las nuevas tecnologías de comunicación permite ir
reusando la infraestructura actual. Plantea desafíos de seguridad y confianza para
la los recursos físicos al igual que los entornos de virtualización de servidores.
Ilustración 4: Modelo de virtualización completa de la red.
El punto de vista que este trabajo plantea es el de Virtual Networks, este concepto como
mencionábamos presenta desafíos para abordar nuevos escenarios y para mitigar el
impacto hacia un modelo de futuro. Es importante seguir fomentando la evolución del
Internet actual, teniendo un impacto positivo en la forma como millones de personas viven,
trabajan y se comunican.
La principal razón del éxito del modelo actual de internet es que la red no tiene
conocimiento acerca de las aplicaciones, es decir las funciones de aplicación reside en
los nodos finales. Internet interconecta muchas tecnologías diferentes e IP es el protocolo
de trasporte mejor soportado.
Esto deja puerta abierta a la innovación por un lado, es bueno si realmente el operador de
la red no le interesa que la red tenga conocimiento de las aplicaciones, pero sin embargo
esto puede ser un factor importante con motivos de optimizar el rendimiento según la
aplicación, dispositivo cliente, mejoras de seguridad, asuntos legales entre otros.
Con estos puntos en cuenta analizamos la tendencia de uso del actual modelo y los focos
emergentes en vías de aplicar una heurística con la que plantear una adaptación menos
disruptiva que la tendencia clean slate.

Vemos como la red con diferencia de lo ocurrido con el hardware en los centros de datos no
ha sufrido una transición profunda. Esto, genera un cuello de botella a las mejoras que
aporta la virtualización y el actual despliegue de Internet. Actualmente el paradigma está
obligando al modelo a evolucionar la manera de definir las redes. La comunidad que
investiga en el desarrollo de alternativas a las redes tradicionales trabaja en el concepto de
Software-Defined Networking que rompe con el modelo convencional donde la red decide
qué acciones lleva a cabo, desacoplando plano de control (control plane) que administra
toda la información correspondiente a la red en sí misma y hace operativo el plano de
datos, aquel en el que se ejecutan las operaciones necesarias para el reenvío de tráfico
(forwarding plane). Planteando una transición del modelo basada en la virtualización de
la red y la extensión de esta según el concepto de Overlay Networks mencionado
anteriormente.
1.2.3. EXTENDER LA RED EN LA CAPA DE VIRTUALIZACIÓN: REDES DEFINIDAS POR

SOFTWARE
El concepto de red virtual distribuida puede ser entendido como una red virtualmente
extendida a de nivel de enlace según el modelo de referencia OSI, desplegada sobre los
sistemas operativos de una infraestructura física distribuida geográficamente, pudiendo ser
esta pública o privada. Esta capa “elevada” compatible con Ethernet es compatible con la
virtualización de sistemas que pueden utilizar estos nuevos recursos virtuales para
interconectarse.
La virtualización de aquellos subsistemas necesarios para networking surge como una
tecnología complementaria a la virtualización de sistemas ; permitiendo de manera más
sencilla movilidad de equipos entre redes dentro de un mismo host, escalabilidad,
flexibilidad de crecimiento, una herramienta genérica para montar escenarios de pruebas
para modelos de red y producción, reconfigurable, superpuesta a la capa de aplicación,
capaz de dividirse a su vez con VLANs (Virtual Local Area Networks), con preservación de
la privacidad, con usos en entornos de aplicación que interconectan de forma transparente
con otras redes (virtuales o físicas), desafiar a los problemas de mantener sistemas que
requieren de redes con direccionamiento IPv4 que coexistan sobre redes IPv6 , mitigar la
fragmentación de la red y otras que pueden surgir con redes de nueva generación y la
tendencia actual de trasladarlo todo a servicios y disponibilidad móvil.
Los Hypervisors 80x86 introducidos en los noventa implementan puentes de red en
software. Estos bridges no permiten habilitar o aplicar políticas al tráfico, es decir, el tráfico
entre máquinas en el mismo host físico pasa directamente de VM a VM, por lo que los
administradores de toda red no tienen oportunidad de manejar o controlar el tráfico por las
VIF (virtual interfaces).
Nuestro objetivo hace hincapié en el concepto distribuido que nos permite crear estos
espacios de red, conectar, desconectar y ampliar sencillamente por software, creando redes

escalables y distribuidas a la vez. Tal que, podamos construir una red virtual extremo a
extremo superando las heterogeneidades del nivel subyacente.
Las primeras propuestas que hablan de capas aisladas, elevadas en el nivel de aplicación y
extremo a extremo, surgen de los precursores de modelos disruptivos al modelo Internet
diseñado hace más de treinta años [5], con fines de llegar a soluciones para propósitos
concretos y generales. Así las primeras propuestas de Overlay Networks como RON [38],
VIOLIN [35], VIGO [37] entre otras.
Con las mejoras del kernel para Linux y las primeras técnicas de virtualización surgen para
escenarios de laboratorio proyectos como User Mode Linux (UML). Son adoptados para el
modelado de escenarios de laboratorio ahorrando en recursos hardware en un mismo host,
con el proyecto VNUML (Virtual Network UML) y que consigue un mayor alcance en
colaboración de la herramienta EDIV [34] para laboratorios distribuidos y su última versión
ya que utiliza virtualización VNX [33]. Este último salto (en el que nos encontramos hoy
día), se consigue con el manejo de la para- virtualización y virtualización de hardware de
entrada salida, Libvirt [39], LibNetVirt [104 ], Virt-IO [28] y UMView [11] son algunos de
estos importantes avances de este campo.
Actualmente el equipo del proyecto virtualsquare sobre el eje principal de VDE (Virtual
Distributed Ethernet) [2] ha desarrollado un framework de componentes y herramientas
para crear redes virtuales compatibles con Ethernet que son desplegadas sobre equipos
físicos aislados o distribuidos por Internet. Es un proyecto de código abierto impulsado
principalmente por la universidad de Bolonia (Italia) y que es ya soportado para la
virtualización de sistemas con herramientas como KVM [24][28] (Kernel Based Virtual
Machine proyecto emergente de Red Hat™) y VirtualBox™[18] ( adquirida por Oracle™ con
una importante comunidad de desarrolladores para la versión de código abierto) ambas
sobre sistemas GNU/Linux. Este proyecto tiene un importante valor didáctico y práctico
para construir redes virtuales distribuidas compatibles con el hardware existente, quizás
por esta causa ha sido que no ha calado al sector de la industria que realiza sistemas para
electrónica de red y circuitos integrados para aplicaciones específicas (ASICs). Un
compromiso más “cercano” entre software (ya sea este de virtualización o no) y hardware
aporta generalmente mejor eficiencia en el rendimiento además de cuanto más específico
sea para el propósito que quiere desempeñar. No es un tema que se discuta aquí pero que
comprendemos es una premisa a la hora de adoptar soluciones y tendremos presente para
hallar un compromiso según el ámbito (investigación o producción) de rendimiento y
compatibilidad.
A grandes rasgos la otra gran vertiente al concepto de virtual distributed networking la
ofrecen el tándem formado por la compañía de virtualización VMware™[8] y el fabricante
mundial de hardware y software para telecomunicaciones Cisco Systems™. Juntos, ofrecen
su solución más completa en el producto VMware vSphere 5.0 Enterprise Plus Edition [29]
en la que Cisco incorpora su switch virtual con capacidad para conexiones distribuidas
Cisco 1000V [62] y VMware [17] añade mejoras de comunicación para interfaces virtuales
e integración con este switch distribuido. Entre las novedades de la última versión cabe

destacar el uso del protocolo de enlace LLDP (Link Layer Discovery Protocol) de
descubrimiento de red estándar del IEEE ya que en versiones anteriores únicamente
permitían el uso de CDP (Cisco Discovery Protocol) para integrarse con dispositivos Cisco
virtuales y físicos. Esta solución además de los costes de hardware y electrónica de red Cisco
para un mejor aprovechamiento del Hypervisor, tiene un coste de licencia muy elevado por
tratarse del producto más avanzado y completo de la compañía estadounidense.
La opción opensource al tandem VMware y Cisco es la apuesta que proviene la fundación
Apache formada por XEN Server 6.0 con Open vSwitch [19]. Concretamente este switch
virtual opensource contiene muchas de las características deseables para una nueva
generación de edge switches [3]. Open vSwitch se diseña para permitir flexibilidad en la
asignación de recursos, permite visibilidad y control del tráfico que maneja, aplicar políticas
y una gestión centralizada entre otras. Este último y relativamente reciente proyecto ha
evolucionado rápidamente, revolucionando e implicando a industria tecnológica y
universidades en la estandarización del protocolo OpenFlow (concepto previamente
introducido por Ethane orientado a redes empresariales en 2007) [9] con el objetivo de
definir redes definidas por software o SDN (Software Defined Networks) para
experimentación de nuevas arquitecturas y que supone un esfuerzo de hacer más flexible la
infraestructura de red del modelo rígido y “osificado” por el protocolo TCP/IP,
estandarizado en 1981.
Apps Apps Apps Apps Apps

Apps Apps
Sistema Operativo
Hardware reenvío Sistema Sistema Sistema Sistema Sistema
especializado Operativo Operativo Operativo Operativo Operativo
Apps Apps Apps Apps Capa de virtualización general o silicing
Sistema Operativo Sistema Operativo

Hardware reenvío Hardware reenvío
especializado especializado HW reenvío simple
HW reenvío simple HW reenvío simple

Apps Apps
Sistema Operativo
Hardware reenvío
especializado HW reenvío simple
Ilustración 5: Transición conceptual del modelo convencional al modelo de red definida por software.
En esta arquitectura de red emergente SDN, se desacopla la lógica de control de la red en

una capa elevada sobre el plano de retransmisión o reenvío, siendo esta directamente
programable por software. Las tablas de encaminamiento son definidas mediante la
interfaz de programación o API (Aplication Program Interface) del protocolo OpenFlow (en
el que profundizaremos durante todo desarrollo del proyecto) y son gestionadas a través de
un OpenFlow Controller que procesa de forma aislada diferentes flujos de datos

simultáneamente. Lo que extiende las posibilidades de interoperar con distintas redes ya

sea para experimentación o para casos en producción de forma segura.
El principal objetivo de crear caminos lógicos independientes para el tráfico sobre una
infraestructura física común es para preservar y mejorar en la mayoría de casos el grado de
escalabilidad y seguridad de los servicios disponibles en la red física.
Las redes definidas por software (Software Defined Network) surgen como posibilidad
abierta en el ámbito de la investigación para estudiar/experimentar soluciones a los
problemas del actual modelo de internet en cuanto a eficiencia, escalabilidad, funcionalidad
y seguridad. Aprovechando además una fuerte necesidad de mercado para agilizar la
gestión el crecimiento de servicios en los centros de datos ha impulsado que el protocolo
OpenFlow se convierta en eslabón referente de este concepto. Enumeramos etapas
importantes en este avance de las SDNs:
 2004: Primeros trabajos sobre un nuevo paradigma de gestión:
o RCP [76]
o 4D [77]
o SANE[78]
o Ethane
 2008: Software-Defined Networking (SDN)
o NOX Network Operating System [79]
o OpenFlow Switch interface
o Se adopta la estandarización del protocolo OpenFlow 1.0
o Se incita a que sea implementado en hardware a fabricantes
 2011: Open Networking Fundation [54]
o Más de 30 empresas participan
o Google, Yahoo!, Verizon, DT, Microsoft, Facebook,Telefónica
o Miembros: Cisco, Juniper, HP, Dell, Broadcom, IBM,etc.
o Evolución del protocolo OpenFlow v.1.3
 2013:
o Inter-Datacenter WAN using SDN and OpenFlow [57]
o OpenDayLight a Linux Fundation Collaborative Project [80]
Hay numerosos proyectos que participan en la evolución del Internet actual, teniendo un
impacto positivo en la forma como millones de personas viven, trabajan y se comunican. Y
como se deben prestar estos servicios para hacerlos más eficientes ininterrumpidos y
seguros.
Esta transición implica mejorar no solo las prestaciones sino la calidad en la gestión y
organización de la red de forma que resulte más eficiente y adecuada al consumo actual de
servicios. Estos retos serán con mayor certeza factores decisivos para grandes proveedores
de servicios, que participan activamente en la investigación crear y simplificar grandes
redes virtuales distribuidas.

2. ANÁLISIS DE OBJETIVOS Y METODOLOGÍA

2.1. DESAFÍOS
Investigamos el nexo desde un punto de vista evolutivo y menos disruptivo, con el fin de
conformar redes distribuidas usando virtualización de los componentes pensando en el
Internet del Futuro. De forma que, en una capa sobrepuesta a la red física veamos una
simplificación de nodos interconectados, abstrayéndonos del nivel subyacente que
suponemos conectado. Las técnicas de virtualización, son sin duda presente y futuro hacia
este modelo.
El paradigma de red definida por software o Software-Defined Network (termino que
utilizaremos indistintamente) y la plasmación de este modelo en la implementación del
protocolo de referencia OpenFlow, será el motivo de análisis teórico en este capítulo y
empíricamente en los siguientes. Cabe destacar los frentes actuales que al modelo
tradicional IP se le plantean (además de las cuestiones al modelo del apartado 1.2.1),
escenarios que estarán en los nuevos escenarios del Internet del futuro.
2.1.1. ENTORNOS MÚLTIPLE ARRENDATARIO ESCALABLES
Es adecuado mencionar en este apartado el concepto de todo “as a service” vinculado al

cloud computing o modelo de computación en la nube, por ser el escenario multi-tenant
(multi arrendatario) por excelencia en el que se aplica y el continuo crecimiento que
tiene actualmente. En él, los clientes acceden a sus servicios en internet sin necesidad
de ser experto en la gestión de los recursos que usan. Este modelo de prestaciones de
servicios directamente desde Internet está estrechamente ligado a las nuevas
tendencias de uso de la red e implica un aprovisionamiento bajo demanda y de la
elasticidad de los recursos para entornos múltiplemente arrendados de centros de
datos. Un ejemplo común de la computación en nube es la nube pública, donde un
proveedor de servicio en “la nube” ofrece sus servicios a múltiples clientes dentro de
la misma infraestructura ofreciendo aislamiento. Esta demanda de servicios/recursos
de forma natural y elástica se consigue con la conjunción de hypervisors confiables y de
VMs invocadas de forma flexible a través de mecanismos de control de acceso a la red
distribuida.
2.1.2. REQUISITOS DE MOVILIDAD DE LAS MÁQUINAS VIRTUALES
Una de las principales ventajas de la virtualización de servidores es la movilidad de las

VMs. Una máquina virtual puede migrarse de un servidor a otro mientras está
funcionando, con y sin necesidad de apagarla, y podemos reiniciar la misma máquina
virtual en una nueva ubicación. Un requisito para esto es que la máquina mantenga su
dirección(es) IP y la dirección(es) MAC de sus interfaces en la nueva ubicación para
evitar el derribo de la comunicación existente.

Actualmente, a los servidores en los centros de datos se les asignan direcciones IP

basadas en la ubicación física, por ejemplo, por lo general en base al switch (top of rack)
para cada armario rack de servidores o la VLAN configurada para los servidores. Al
final, este trabajo está bien para servidores físicos, que no movemos, pero restringe la
colocación y la movilidad de las máquinas virtuales dentro del centro de datos.
Buscamos una solución que permita la escalabilidad en entornos multi-tenant, que una
máquina virtual pueda desplegar sus servicios en cualquier ubicación del centro de
datos, sin verse preocupados por las restricciones y limitaciones de las subredes a las
que están conectados los servidores.
2.1.3. EXTENSIÓN DE LAS REDES VIRTUALES
En la literatura de organización y gestión eficiente de data centers encontramos el

término pod que consiste en uno o más racks de servidores que comparten la
conectividad para almacenamiento, red y en algunos casos incluso conductos para
cableado y refrigeración. Los inquilinos del centro de datos pueden comenzar en un pod
y debido al crecimiento de la demanda de sus servicios requieran de más
servidores/VMs en otros pods, si nos fijamos en aquellos que no están totalmente
utilizando todos sus recursos vemos que la red virtual debería proporcionar
conectividad con todos los recursos disponibles para extender el pod y ampliar los
recursos VMs al arrendatario.
2.1.4. TAMAÑO DE LAS TABLAS DE ENCAMINAMIENTO
Hoy día con los entornos virtualizados, aumentan las exigencias de tablas de
encaminamiento de switches. En lugar de una sola capa de enlace en cada dirección, la
infraestructura de red debe aprender las direcciones de enlace de las VMs
individualmente que podrían llegar a 100 por servidor. Esto es un requisito, ya que el
tráfico desde/hacia las máquinas virtuales al resto de la red física que conecta la
infraestructura.
Esto requiere más capacidad en el desempeño de los switches para gestionar estas
tablas, en comparación con los entornos no virtualizados. Causando más inundación de
paquetes y desbordamientos cuando las direcciones en uso sobrepasan la capacidad de
las tablas de encaminamiento.
2.1.5. DESACOPLAMIENTO DE LA CONFIGURACIÓN LÓGICA Y FÍSICA
Los operadores del centro de datos deben ser capaces de alcanzar una alta utilización
de los recursos de sus servidores y de las capacidades de la red. Para una asignación
eficiente y flexible, debemos ser capaces de extender una instancia virtual a través de
los servidores en cualquier rack del centro de datos. Esto se puede lograr extendiendo
las VLAN (hay trabajos sobre este asunto como TRILL o OTV) [46].

Sin embargo, con el fin de limitar el dominio de difusión (broadcasting) de cada VLAN,
las tramas multi-destino dentro de la misma VLAN deben estar optimizadas para que
solo circulen por aquellos dispositivos que tienen configurada esa VLAN. Con la
migración por cargas de trabajo, la red física puede necesitar reconfiguraciones que
típicamente requieren tiempo y son propensas a errores (ej. Listas de control de acceso,
encaminamiento, etc.).
2.1.6. COMUNICACIONES ENTRE MÁQUINAS VIRTUALIZADAS Y NO VIRTUALIZADAS
Dentro de los centros de datos no todas las comunicaciones serán VM-VM. Continuarán
utilizando para propósitos específicos servidores físicos, routers tradicionales para
proveer servicios VPN de nivel 2 y 3, balanceadores de carga, firewalls, sistemas de
detección de intrusiones, etc. Esto no podemos obviarlo y considerar que la capa de red
virtualizada debe ser compatible con los sistemas existentes.
2.1.7. TRANSICIÓN A IPV6
IPv6 aumenta el espacio de direcciones, aprovecha para ofrecer mejoras y extensiones

en cuanto a QoS, seguridad, movilidad, etc. Pero ocurre que, IPv4 e IPv6 son
incompatibles. Se diseñó teniendo en cuenta esto como se definen en el RFC 2893
(actualizado en RFC 4213) los mecanismos de transición a IPv6 para host y routers.
Es evidente que no puede actualizarse todo Internet en un día, es como cambiar las alas
a un avión en pleno vuelo. Es obligatorio garantizar un periodo de coexistencia e incluso
tener en cuenta servicios que deban extinguirse sin migrarse.
La transición es costosa: Routers, PCs, aplicaciones y formación. La clave del éxito de

IPv6 es el proceso de transición. En nuestra interpretación y análisis del Internet del
Futuro planteamos que los mecanismos de virtualización y extensión de la red
orientada a la abstracción de la tecnología de red, son un importante nexo con la
transición de IPv6. Quizás se ha asociado a problemas de seguridad el direccionamiento
público y la utilización en entornos extendidos aislados como redes virtuales sea un
avance en este ámbito.
Extender el ámbito de la red y concepto de extremo a extremo son aptitudes que se abstraen
del uso actual de internet y saca a la luz los problemas de diseño que lastran el desarrollo
actual de internet [6] [2] [7]. Considerar estas herramientas tiene un importante papel para
la investigación y la transición del modelo actual al modelo de Futuro Internet [4], como se
llama en investigación a los desarrollos en investigación para el Internet de Futuro. Para
esto será necesario crear dominios de pruebas y la coexistencia de las redes de nueva
generación con las actuales.
Durante los últimos años han surgido diferentes enfoques para extender la red creando
redes Overlay Networks y/o virtualizar a nivel de enlace para cubrir las limitaciones del
modelo actual. Regidos en su comportamiento por la osificación sobre la pila de protocolo

IP resultando poco flexibles. Señalar algunos proyectos para extender la red como VXLAN
(Virtual eXtensible LAN), L2VPNs (Level 2 Virtual Private Networks) y que destacan en busca
de un desacoplamiento lógico y físico de la red como VLAN (Virtual Local Area Network) con
hasta 4096 (12bits) para identificadores VLAN. TRILL (Transparent Interconnection of Lots
of Links) interesante proyecto basado en Routing Bridges pero con inconvenientes de
aplicabilidad [55 ] y LISP (Locator/Identifier Separation Protocol) como alternativa de
encaminamiento que destaca los problemas del acoplamiento identificador y localizador en
la red del modelo IP soportado por CISCO. [46]
Ilustración 6: Representación del concepto de osificación y acoplamiento a IP. [92]
La revolución se centra en la virtualización de la red. Switches, routers y la gestión de los

mismos. Suponiendo que estamos ya un mundo conectado, veamos la Red como otro
servicio ídem al agua potable o la corriente eléctrica. Una red conectada donde abstraemos
la gestión y la decisión de que flujo de entradas o de paquetes (flow entries) está permitido
y cuál no.
La arquitectura SDN (Software Defined Network) como principal diferencia incorpora las
novedades a la lógica de red desacoplándose del modelo IP, separando el plano de control y
el de datos. El otro factor fundamental para poder coexistir con IP es el de poder actuar
sobre los elementos de la red sin comprometer al fabricante ni el comportamiento de los
sistemas que ya funcionan a través de los mismos dispositivos, mientras experimentamos
con OpenFlow. Esta dualidad nos facilita una transición dinámica, menos disruptiva con la
organización actual de la red.
Ilustración 7: Slicing de la la red: Separación del tráfico del producción del de experimentación a su vez subdivididle
en subespácios.

¿Por qué esta arquitectura va a tener más calado que otros proyectos para su implantación
en una infraestructura tan grande como Internet? El principal punto a favor de SDN es que
cuenta con el apoyo del sector industrial. Fabricantes de hardware, electrónica de red,
telefonía y proveedores de servicios participan. Esto puede considerarse relativamente
bueno en algunos aspectos y negativo en otros, como en el de la estandarización y el
desarrollo de interfaces abiertas. Con la creación de proyectos alternativos propietarios en
torno al mismo concepto pueden surgir intereses propios en lugar de aunar un interés
común ante un desafío tan grande como el FI (Internet del Futuro).
La red definida por software o Software Defined Network, es el modelo reglado que tras un
profundo estudio antes y durante el desarrollo de este documento hemos escogido como
nexo con las redes de nueva generación y futuro de Internet.
Disponemos de software y equipamiento hardware con prestaciones duales para explorar
con esta arquitectura de red y desplegar un sencillo servicio de ingeniería de tráfico de
red centralizado utilizando el protocolo OpenFlow. Otras perspectivas para el mismo
problema puramente virtualizadas no han implicado al sector industrial y no han tenido el
calado de SDN aunque el marco teórico sea muy coherente. Veremos además que
tecnologías soportan este marco teórico y porque SDN permite la coexistencia y renovación
del modelo IP siendo una solución compatible “hacia atrás y hacia adelante”.
2.2. VIRTUALIZACIÓN DE LA RED, PROPUESTA OVERLAY

Una red virtual sobre la propia red física define el concepto denominado en la literatura
como Overlay Networks [2], la comunicación dentro del mismo domino virtual (sandboxes
[26]) se realiza “extremo a extremo” como si estuvieran conectadas a un mismo switch en
un red local. En esta capa Overlay compiten o se interconectan independientemente de la
tecnología y los propósitos que tengan las capas superiores.
En la actualidad existen diversas propuestas y protocolos Overlay, pero estos no fueron
diseñados para resolver los inconvenientes a nivel de enlace de grandes centros de datos
mayoritariamente virtualizados. Mencionaremos algunos de ellos durante el desarrollo del
proyecto, señalando aquí las premisas de diseño que debemos tener en cuenta antes de
trabajar con las tecnologías constructivas para la implementación de red Overlay.
 Sistemas altamente distribuidos: La red overlay debe poder trabajar en entornos

en los que podría haber miles de conexiones a switches (que pueden estar dentro
de lo hipervisores) y más sistemas finales conectados a ellos (peticiones, clientes,
VMs, etc.). Este sistema altamente distribuido reduce el costo operativo de las
conexiones extremo a extremo, mejor aún si además no tiene sobrecarga para los
terminales finales.
 Muchas redes virtuales altamente distribuidas con escasa conectividad: Si

tenemos muchas redes virtuales dispersas también tenemos repartidos los
terminales finales que se conectan a la red virtual distribuida y la carga entre los

switches virtuales distribuida, si tenemos conectividad limitada entre redes es

importante que una poda eficiente del tráfico multi-destinatario, que debemos
tenerlo en cuenta.
 Los sistemas finales debemos considerar que son altamente dinámicos: El
modelo actual de uso de la red está ligado a la movilidad. Los terminales finales
conectados a las redes virtuales puede ser móviles pueden crear, eliminar, apagar o
encender su conexión en cualquier momento durante el acceso a nuestra red.
 Mantener la compatibilidad con el amplio despliegue de switches y routers sin
necesidad de realizar reemplazos a gran escala: El primer switch de salto
requerirá nuevo equipamiento hardware y/o software. Dependiendo si la solución
de virtualización es basada en software o hardware que modifique las cabeceras en
las tramas de datos.
 Infraestructura virtual de red gestionada desde un único dominio de red
administrativo: Consiste en que se opere desde el centro de datos y no a través de
Internet. Esto concierne a la seguridad y a la mejora de disponibilidad de los
servicios.
OpenFlow surgió en la Universidad de Stanford, principalmente para hacer experimentos

sobre la red que utilizaban a diario [56] , quisieron incitar a los fabricantes de tecnología de
red a añadirlo a sus productos para despliegues de redes troncales entre armarios de
cableado y campus universitarios.
Tener dominios de experimentación para laboratorio con la semejanza y las dimensiones
de un entorno en producción tan grande como Internet para pruebas es sumamente
complejo, a la hora de desarrollar nuevos modelos de futuro al mismo tiempo. El mejor
escenario a escala de Internet para experimentar con las tecnologías del futuro internet es
el propio Internet.
Ilustración 7: Inter-Datacenter Software Defined WAN [57]
Los primeros testbeds o bancos de pruebas han surgido en torno a las universidades
formando lo que habíamos bautizado en la introducción el ARPANET contemporáneo de la
arquitectura de red definida por software. Proyectos como VIOLIN, PlanetLab, Emulab VINI,

GENI, OFELIA o FIBRE. [35][36][51] son algunos ejemplos. Concretamente nos extenderemos
en el siguiente capítulo en el proyecto europeo Ofelia.
A la hora de buscar escenarios ventajosos “no experimentales” donde pueda adoptarse el
modelo de red definida por software puede parecer evidente si miramos las necesidades
que cubre. Grandes centros de datos, proveedores de servicios en la nube (término acuñado
que hemos repetido para servicios distribuidos disponibles en Internet) o proveedores de
servicios ISPs que requieran de un alto grado de disponibilidad de sus servicios están
obligados a mantener una infraestructura de red flexible de área extensa. Aquellos que
pretendan innovar en mejorar la gestión reduciendo la complejidad y los costes para crecer
o disminuir las prestaciones de los mismos, optarán por la abstracción del control de la red.
Otros escenarios menos evidentes pueden ser interconectar redes para propósitos
específicos a Internet, refiriéndonos a redes de sensores, redes vehiculares o redes
comerciales.
Estos principales nodos proveedores de servicios distribuidos además de balancear las
necesidades de sus usuarios y garantizar la disponibilidad de los mismos se extienden
geográficamente adoptando un esquema de red virtualizado como el de la figura 10
estableciendo grandes planos transversales de control de la red. Esta abstracción de la
tecnología de encaminamiento permite con las modificaciones en las tablas de flujo
correspondientes reconducir el tráfico para reducir costes energéticos, desconectar
equipamiento en horas valle, mantenimientos en el plano de encaminamiento y/o mejorar
la tecnología hardware subyacente preparada para el Internet del Futuro (por ejemplo
mejorando la implantación del protocolo IPv6) o mejorando la eficiencia del plano de
conmutación para propósito más específico.
La gestión de la red como un tejido virtual en lugar de como una colección de cajas
individuales nos enseña la vista horizontal de esta arquitectura, esta abstracción de Overlay
Networks independientes del protocolo, basadas en un estándar de interconexión
(OpenFlow es el candidato más avanzado en esta área), con gestión centralizada, que facilite
el crecimiento y la interconexión, es la ruptura con la osificación del modelo tradicional IP
y es un importante paso de transición.
2.3. ANÁLISIS Y CONTRIBUCIÓN
En SDN quizás el dispositivo del que más se habla es el switch de red, de los switches
ethernet en particular. Por años, los switches ethernet han crecido en velocidad y densidad,
proporcionando a los centros de datos uplinks para sus hosts, blade centers y
almacenamiento a través de ethernet. Con el advenimiento de la virtualización de servidores
gracias a los hipervisores, el switch software también se ha hecho importante, agregando
tráfico y sacándolo fuera del hypervisor hacia la red física.

2.3.1. REDES DEFINIDAS POR SOFTWARE: SDN Y OPEN FLOW
SOFTWARE-DEFINED NETWORK
La organización Open Networking Fundation que difunde y regula la estandarización de

Software-Defined Networking (SDN), la define como una arquitectura emergente, flexible,
manejable, rentable y adaptable. Siendo ideal para entornos con gran ancho de banda y
naturaleza dinámica, como la de las aplicaciones de hoy en día. Esta arquitectura
desacopla el control de la red de la funciones de encaminamiento, permitiendo
programar directamente el control de la red, y a la infraestructura subyacente abstraerse
de la aplicaciones y servicios sobre ella.
Ilustración 8: Diagrama general arquitectura SDN, el plano de control que tiene toda la lógica SDN que separa
la infraestructura de encaminamiento de las aplicaciones.
SDN básicamente se auto define con tres abstracciones: abstracción distribuida, reenvío
o forwarding distribuido y configuración distribuida. OpenFlow concretamente es una
implementación o un detalle para implementar este modelo de redes definidas por
software. Veamos con detalle las principales propiedades de la arquitectura SDN:
o Directamente Programable: El control es directamente programable ya que esta

desacoplado de las funciones de encaminamiento que ser realizan en el nivel subyacente.
o Ágil: Abstrayendo el control del reenvío de paquetes, facilita las tareas a los
administradores de ajustar dinámicamente el flujo de tráfico por toda la red para
satisfacer necesidades cambiantes.
o Gestión Centralizada: La inteligencia de la red está centralizada en controladores
basados en software SDN que mantienen un vista global de la red, siendo el motor de
aplicaciones y políticas, similar a un “cerebro” de red.
o Configuración programable: Permite a los administradores de red, configurar,
administrar, securizar y optimizar recursos de red muy rápido y de forma dinámica,

automáticamente con programas SDN que pueden ser escritos por los propios
administradores y no dependen de software propietario.
o Basada en estándares abiertos e independientes de fabricantes: Cuando se
implementan estándares abiertos, las instrucciones del controlador SDN pueden ser
entendidas a múltiples aplicaciones y dispositivos compatibles con el estándar
independientemente del fabricante.
OPENFLOW
Ya nos hemos referido a OpenFlow por lo estrechamente ligado al concepto de Software

Defined Network. Es el primer interfaz estándar definido para las comunicaciones entre
la capa de control y de encaminamiento de una arquitectura SDN. Por este motivo
OpenFlow y SDN son términos promovidos para hablar de virtualización de la red.
OpenFlow se basa en la idea de un conmutador Ethernet con una tabla de flujo interna y
una interfaz estandarizada para añadir y eliminar entradas de flujo (flow tables).[72]
En una red OpenFlow puede haber un controlador (OpenFlow Controller o OFC) por
switch o un mismo controlador puede estar ligado múltiples switches para gestionar
una red completa. Esta red OpenFlow puede ser virtualizable de forma que cada
aplicación reciba parte de los recursos del switch OpenFlow, que serán un grupo de
puertos y parte del espacio de encaminamiento del termino flow space. Varios switches
virtuales conectados entre ellos se denomina una porción o rodaja de la red, del termino
slice of network que utilizaremos indistintamente y encontramos en la documentación
en este ámbito. Esto por ejemplo nos permitirá utilizar un slice para tráfico en
producción y otro slice (1...N) para experimentación con nuevos protocolos, gestión de la
red, otras redes de carácter Overlay o diseñar mejoras sin comprometer una proporción
de red a la otra.
Ilustración 9: Ejemplo de red básica OpenFlow.

Como vemos en la ilustración 9, el plano software es manejado a través de un canal

seguro por el controlador OpenFlow. Esta información que envía el controlador a los
switches denominados flow entrys será la procesada a la hora de decidir el forwarding.
Estas entradas de flujos que como veremos pueden tener información de nivel de enlace,
de red o de transporte en una única entrada (L2-L4). Esta abstracción del modelo de
reenvío para encaminar flows simplifica el plano de encaminamiento.
Este controlador tiene al menos una tabla de entradas Flow Table con la que comprará
el tráfico que reciba, comparándolo con las entradas o flow entries. Un mismo OFC puede
manejar varias tablas según los espacios virtuales que gobierne.
El controlador asume la lógica del plano de control convirtiéndose en un equipo de

decisión del plano de control. En un despliegue de experimentación (como los que
nosotros vamos a trabajar en el siguiente capítulo) puede que este impacto sea permisivo
pero en escenarios como el de la ilustración 7 basado en un planteamiento inter-data
center de Google es necesario construir un servicio de ingeniería de tráfico centralizado.
Se denomina un Bandwidth Broker and Traffic Engineering [57]. Esto es, un servicio
encargado de recopilar métricas de utilización y de la topología en tiempo real del nivel
de red y el consumo de recursos (ej. ancho de banda) de aplicaciones y servicios. Con
estos datos, se calculan las asignaciones necesarias para cada camino de datos traffic
flows que serán programados en los switches utilizando OpenFlow. En el caso de cambios
en la demanda o eventos que se produzcan en la red, el servicio recalcula la asignación
de caminos y reprogramará los switches.
Ilustración 10: Arquitectura SDN plano de Control y Datos, esquema de red definida por software con
centralización y agente o bróker para la ingeniería del tráfico definida por software para la interconexión
de sitios a gran escala. [57]

Ilustración 11: Ejemplos de entradas de encaminamiento según los campos que maneja de cada tipo de equipo
y las acciones que determina. En términos de flows manejamos para decidir por donde encaminar información
de distintos niveles del modelo IP, esta abstracción es muy potente para simplificar la gestión de
encaminamiento y la seguridad.
En general, la lógica programada (al final el comportamiento del switch virtual) a

través del controlador OpenFlow dependerá del escenario para el que se diseñe.
Dotando desde el comportamiento más básico como un concentrador o hub o más
avanzadas con capacidades propias de switching, firewall o totalmente personalizadas
al propósito de la red. Definiremos algunos tratamientos y comportamientos sobre los
laboratorios prácticos del siguiente capítulo.

ENCAMINAMIENTO VIRTUALIZADO ASISTENCIA HARDWARE
Experimentar con escenarios de red, crear laboratorios con un cierto realismo con el
propósito de recrear el modelo SDN es posible utilizando equipos PC con tarjetas de red
multi-puerto o varias tarjetas de red, que podría alcanzar a una capacidad conmutación
aproximada de hasta 5 Gbps [81]. Otra alternativa son las tarjetas programables tipo
NetFPGA para investigación, aunque el desarrollo e implementación es difícil y el entorno
tiene sus limitaciones, OpenFlow se ha desplegado en estas tarjetas y esta trabajado y
documentado [61], existen espacios de experimentación SDN con esta tecnología (el
proyecto GENI comenzó así y algunos centros universitarios que participan en la red
Europea Ofelia utilizan equipamiento con NetFPGA en sus islas).
Un despliegue tan grande como el actual Internet llevó a pensar en modificar la

electrónica de red existente ya desplegada, pero esta verticalmente muy integrada,
compleja y cerrada por los fabricantes. Este es uno de los motivos por los que
sustentamos que una transición menos disruptiva hacia un futuro pasa por extender la
red en una capa virtual, abstrayéndose del hardware que la implementa el plano de
conmutación. Un nivel de abstracción suele acarrear un desacoplo en el compromiso
hardware-software que se traduce en una degradación del rendimiento, pero las
prestaciones actuales de hardware sea especificó o no hacen que sea asumible por la
simplificación, mejor aprovechamiento y en general las ventajas experimentadas ya en
la virtualización de sistemas, llevadas a la red con este nivel de abstracción.
Tal como el número de núcleos por servidor en los sistemas de computación se ha

incrementado, ha crecido el número de máquinas virtuales que puede alojar un servidor
anfitrión y este agregarle ancho de banda correspondiente. Hay posibilidades de mejorar
el hardware de red a nivel físico para el propósito de virtualizar.
 HARDWARE BASED VIRTUAL SWITCHES
Como era de esperar, ídem a como evolucionaron/mejoraron las arquitecturas de

procesadores para virtualización, la tendencia conduce a mejorar la tecnología hardware
para acelerar la conmutación en entornos virtualizados. VMDq de Intel proporciona
acelerado por hardware para conmutación en NICs (Network Interface Cards) como otros
SR-IOV NIC [3].
En la implementación del switch OpenFlow principalmente hay dos espacios de trabajo o

componentes principales, una parte que se ejecuta en el espacio de usuario denominado
en también slow path o camino lento y una parte más rápida fast path [1] que esta
residente en el kernel. Con la aceleración hardware para el encaminamiento se pretende
trasladar el fast path al silicio para transmitir y recibir paquetes directamente desde y
hacia la máquina virtual correspondiente.

Ilustración 12: Vista de conmutación de paquetes con soporte hardware para la virtualización de interfaces de
red.
Con la intención de permitir que la función de conmutación entre máquinas virtuales se

lleve a cabo totalmente por un dispositivo de la red física surgen hardware-based
virtual switches, se han estandarizado revisiones del formato de la trama Ethernet IEEE
802.1Q para manejar tramas de máquinas virtuales en la misma red física. Un caso
particular es VN-Tag [82] que incluyen en esencia dos campos, el identificador de fuente
de envió virtual SVIF_ID y el identificador de interfaz virtual destino DVIF_ID. Para esto
en hardware implementa consciencia para identificar este tipo de tráfico y encaminarlo
por la red hacía la máquina virtual destino. Otra perspectiva es la de Virtual Ethernet
Port Aggregator, VEPA [82] tiene como objetivo principal permitir que el tráfico de VMs
salga y regrese por el mismo puerto físico para habilitar el switching entre máquinas
virtuales. A diferencia que los switches virtuales que ofrecen los hypervisors x86 que
comentamos en la introducción, este equipamiento está en el primer salto de red
optimizando el tráfico inter VMs y además permitiendo al administrador de red ganar
acceso a la gestión y visibilidad del tráfico, aplicar características de seguridad, control,
filtrado, inspección, etc.
Cisco System por ejemplo mejora con una solución hardware-based en combinación
del software hypervisor que el tráfico de las VMs pase por el dispositivo conectado a la
red directamente. Distribuye tarjetas controladoras de red optimizadas para
virtualización [61] (basado en el mismo estándar que VN-Tag). Los equipos anfitrión que
las equipan en conjunto con VMware ESX® mejoran la integración y prestaciones del
switch virtual software de este hypervisor, es la solución Cisco Nexus 1000V ® que
reemplazó al VMware’s distributed switch. Si no se utiliza este equipamiento hardware
específico de Cisco, el hipervisor intermedia las conexiones entre las VMs y el switch
virtual Cisco Nexus perdiendo eficiencia.

Regresando a OpenFlow, hemos visto que es el protocolo que actúa entre el plano de
control y el de datos. Los llamaremos indistintamente plano de conmutación, de datos
o datapath, en él podemos encontrarnos con lo siguiente:
o OpenFlow switches (Pueden ser routers,firewalls).

o No es necesario tener protocolos de routing.
o Software (kernel, hypervisor, user space),
o Hardware (fabricantes de electrónica de red, NetFPGAs, ASICs, OpenFlow optimized
ASICs)
Elegir hardware preparado para SDN a día de hoy no es cuestión baladí. Debido
principalmente a que hardware de la red actual no está diseñado para un plano de
control desacoplado. Sin embargo el lanzamiento de la especificación OpenFlow v1.0
junto con la demanda de aplicar esta tecnología ha llevado a fabricantes a proveer
equipos de networking OpenFlow. Utilizando plataformas hardware ya existentes, los
fabricantes han realizado modificaciones en sus sistemas operativos de red (NOS)
analizando e interrumpiendo el proceso comprendido de fases secuenciales normal y
bifurcando su flujo de comportamiento para flow packets que se procesaran
independientemente. Esta arquitectura llamada comúnmente en pipeline en el ámbito
de arquitectura de computadores separada se llama OpenFlow pipeline, el proceso de
encaminamiento normal se lleva a cabo en el pipeline del equipo de nivel 2, nivel 3 o
nivel 4 según sea. A este tipo de swicthes que soportan la operación de dos tipos son
denominados Hybrid OpenFlow Switches, frente a los que irán surgiendo que solo
realizan operaciones en su pipeline OpenFlow.
Con el fin de lograr este nivel de flexibilidad se realizan switches mejorados para este
propósito más específico, esto requiere también flexibilidad y rendimiento en el manejo
de sus tablas de reenvío. La solución rápida que se ha adoptado para las primeras fases
de experimentación y pruebas en el hardware real, se está aprovechando las memorias
de contenido direccionable que incorporan Ternary Content Addressable Memory.
 TCAM (TERNARY CONTENT ADDRESSABLE MEMORY) Y OPENFLOW
Conocer cómo se comporta el hardware donde se desenvuelve la búsqueda de entradas

y toma de decisiones de un equipo OpenFlow es importante a la hora de abordar el
diseño. Estas características hardware pueden influir a la hora del diseño y
comportamiento de una SDN basada en OpenFlow [20].
CAM (Content Addresasble Memory) es un tipo de memoria única en la que podemos

hacer búsquedas en un ciclo de reloj y de comparar en paralelo múltiples campos a la vez
en una búsqueda. Esta es la forma más común para mejorar hardware de búsqueda en
ASIC (application-especific integrated circuit). Para los programadores, CAM se puede
describir como un array lógico asociativo. Entre los típicos mecanismos de búsqueda
mejorados en hardware destacan Binarias (Binary CAM) y ternarias (Ternary CAM).

TCAM se presta naturalmente a ser el gran aliado para la instanciación de flujo desde un
controlador SDN e inyectar entradas de reenvío con un alto grado de flexibilidad a través
de varios campos de las cabeceras Ethernet e IP. Por ejemplo, 10-tupla OpenFlow v1.0
con los campos Ingress Port, Ethec Src, Ether Dst, Ether Type, Vlan ID, IP Dst, IP Src, TCP
Dst, TCP Src, IP Proto. [72]
Ilustración 13: Encabezado de una túpla OpenFlow.
La mayoría de fabricantes implementan TCAM para hacer comparaciones como listas de

control de acceso (ACLs) y manejar cabeceras de nivel 2 hasta nivel 4 de IP. El software
que utiliza TCAM se ha sido modificado o bien en su HAL (hardware abstraction layer),
capa de abstracción hardware o en su código software expandiendo las funciones de los
algoritmos de búsqueda para ampliar la capacidad de TCAM para búsquedas de
OpenFlow.
Por lo tanto, podemos decir que OpenFlow es meramente un mecanismo que explota las
tablas TCAM extendiendo las capacidades para manejo de flujos de datos. Con esta
función se consigue que un switch que para aquellas coincidencias en su flujo de entrada
realice una acción, es decir para un operador o ingeniero de la red esto es similar a
decidir rutas basándose en unas políticas de comportamiento. Ahora podemos
desacoplar la lógica y desde un agente administrador externo indicar el comportamiento
en término de flows a través de un socket TCP, utilizando un protocolo de mensajería
estructurado para describir la política de comportamiento y las reglas para los flujos que
insertamos en la memoria TCAM.
Ilustración 14: Operación de ejemplo funcionamiento Ternary CAM en OpenFlow [20]

El ingeniero de la red debe conocer las particularidades para un buen diseño y conseguir
así el mejor desempeño a las prestaciones actuales de SDN con Opeflow. El segundo factor
en el que vamos a interesarnos para mejorar el rendimiento en la búsqueda y manejo de
entradas de flujos es el escalado de la red. Según diferentes autores se denomina a este
escalado del tráfico en macroflows y microflows o también llamados coarse flows y fine
flows o granular flows, básicamente se trata de escalar el tráfico haciendo un reenvió de
paquetes según las condiciones de “filtrado” para la función de matching (comparación
de entradas con la tabla de comportamiento del switch) menos estrictas (más gruesas)
o más específicas (más finas) de las tuplas. A la hora de elegir reglas de la tabla de flujo
proactivas, será muy importante la utilización de normas de tamaño apropiado, a fin de
superar la longitud y anchura de las tablas de flujo TCAM.
Ilustración 15: La granularidad y separación en el plano de datos en flujos bastos y finos para mejorar el
coste de procesamiento y tiempos de encaminamiento [63].
 Segregación del plano de datos
Fine o Granular Flows, significa que las reglas de la tabla de flujo son muy precisas y
coinciden en un conjunto muy específico de tráfico. Podríamos comparar este modo al
comportamiento de rutas en IPv4 para reenvío, dado que las redes OpenFlow y SDN
operan mediante el reenvío de flujos basados en tuplas OpenFlow , recordamos que estas
permite mucha más granularidad. Puede significar un juego de valores específicos en
campos que van a través de Ethernet (L2-Datos), IP (L3 Red), TCP / UDP (L4-
Transporte). Esta implementación para conseguir un alto nivel de eficiencia y de
particularidades requiere de Granular Flow Processor – multicore NPUs. Supongamos el
caso extremo siguiente, equipamientos ASICs para mantener todas las tablas de Internet,
no sería viable aunque imaginemos que fuesen los prefijos /24 “solamente”. Es necesario
resumir estas tablas con prefijos de forma gruesa que redujésemos el reenvío y el tamaño
de las tablas en lugar de potenciar rutas a host.

Coarse Flows se refiere a que coincide con una amplia gama de flujos. Esto se podría
asemejar a rutas predeterminadas para encauzar tráfico entre redes más amplias, lo que
requiere menos entradas de flujo. Así es como vamos a implementar SDN con hardware
limitado, utilizando proactive flows y separando adecuadamente el tráfico.
Si hacemos un repaso a los equipos según los niveles en los que actúan veremos mejor la
granularidad que conseguimos con en encaminamiento o reenvío basado en flows.
o Capa 2 – Switching (VLAN, MAC, src/dest Port), eficaz si están en memoria.

o Capa 2 ½ – Label Switching (802.1.Q, MPLS, LSP, FEC, LIB, LFIB)
o Capa 3 – Routing (Routers, L3 Switches, VRF (Virtual Routing Forwarding),
enrutamiento IPv4 e IPv6.)
o Capa 4 – UDP/TCP ports (Típicamente manejados por cortafuegos)
El reenvío basado en flujos a través de protocolos como OpenFlow consolida

conceptualmente la funcionalidad de diversos tipos de hardware de red para un
propósito común en uno. En teoría los mismos métodos para manejar entradas de nivel
2 a 4 (en la mayoría de casos), se podrían simplificar reducir e incluso unificar en una
única instanciación en las tablas de flujo o flow tables. (Ver ilustración 15).
ENCAMINAMIENTO VIRTUALIZADO ASISTENCIA SOFTWARE
Los switch en los hipervisores tradicionales proveen como hemos comentado en

puntos anteriores poco acceso al tráfico que pasa por ellos. El tráfico VM-to-VM no pasa
a través del cable físico y no puede ser trazado por esta vía. Es importante el soporte a
software de monitorización como los que señalamos NetFlow, SNMP, sFlow y port-
mirroring (SPAN y RSPAN) [3]. La virtualización de red surge para conectar
virtualmente cada VM a un switch virtual. Los hipervisores 80x86 introducidos en los
90 VMware, XEN, KVM, etc…, implementaban el componente Virtual Ethernet Bridge,
otros vSwitch, común en distribuciones Linux para compartir el medio físico a través
de este concentrador virtual con prestaciones muy limitadas. Se han analizado
proyectos y herramientas de virtualización del nivel de enlace por software, finalmente
nos decantamos por la solución más compatible con OpenFlow integrada en el propio
kernel GNU Linux Open vSwitch que hemos utilizado en experimentación, en busca de
encajar con el paradigma SDN toda una solución de transición a un nuevo modelo, que
también nos permita experimentar. Sirva como bagaje a la hora de abordar desafíos
futuros en esta línea la sección del apéndice 5.2 de proyectos software que contribuyen
a la virtualización de la red, donde se extiende este estudio.
Resumimos en esta tabla comparativa teniendo en cuenta factores a la hora de plantear

una solución con elementos hardware y software.

Ilustración 16: Contraste de aquellos aspectos generales a tener en cuenta en el diseño para una red con las
tecnologías que disponemos y que contribuyen al modelo de red definida por software [83].
 PLANO DE CONTROL: OPENFLOW CONTROLLER
Como el término SDN propiamente indica, el encaminamiento lo definimos desde el

software. El OFC (OpenFlow Controller) es el principal elemento coordinador del plano
de datos en la red o redes definidas por software que utilizan OpenFlow repetimos. El
controlador actúa como una capa de middleware de red que abstrae los componentes de
la red física subyacente. Cambia el modelo de programación de la red, pasa de ser
distribuido (los dispositivos de la red se comunican unos con otros para determinar las
trayectorias de reenvío) a este sistema centralizado, aprovechando la eficiencia
hardware de los switches.
Indicar que la eficiencia del controlador, estabilidad, opciones de configuración, facilidad

de programación, los recursos que consume, interfaz e información relevante que aporta,
son factores bajo estudio y mejora por los diversos colectivos que los impulsan [65] y
genera una competencia positiva del desarrollo de la red definida por software. Vamos a
señalar algunos proyectos que hemos revisado para la elaboración de este trabajo y que
por sus particularidades tengamos como referencia a la hora de abordar un desafío SDN,
ya sea para pruebas de laboratorio o para entornos en producción. También se deja como
reseña al lector para que sigua aquel que le parezca más interesante (ventaja de este
modelo desacoplado por otro lado) según esté más cómodo con un mecanismo de
comunicación u otro con la red, lenguaje de programación que utiliza, consumo de
recursos, etc.
Está definido en la especificación de OpenFlow que la conexión entre los equipos de

reenvío y el controlador (externo) es vía TCP utilizando por defecto el puerto 6633 de la
máquina controlador (puede modificarse). Esta comunicación es privada e incorpora
cifrado en el canal establecido entre el controlador y el switch mediante SSL/TLS cuando
se inicia la sesión. Como veíamos en la figura simplificada en la Ilustración 9.
Una vez señalado esto veamos algunos de los principales OFC con sus principales
características y que ventajas aportan a la red definida por software, siendo también

una forma de ampliar los horizontes de este modelo y ver las ventajas de este elemento
centralizado. Existen fuentes que recopilan aquellos proyectos que surgen en torno a
SDN y OpenFlow, donde descubrir algunas otras que no se tratan aquí [85] [84].
Con un controlador SDN que programa la red, los operadores ya no se encuentran en

posición de tener que programar los dispositivos de red de manera individual a través
de medios tradicionales, como la interfaz de líneas de comando en cada uno de los
equipos de la red. Además, se pueden crear paradigmas únicos de reenvío de la red en
base a criterios, como los costos o los requerimientos de la política de seguridad [75]. En
esta programación de los switches vía software es donde se encuentra la promesa de
flexibilidad de la SDN. El controlador es una plataforma en la cual ejecuta el software, y
a la vez es una pasarela o gateway de comunicaciones a través del cual se puede
comunicar el software.
Es importante destacar que por encima del controlador existen aplicaciones para el
controlador que se conectan al él para enviar órdenes. Trabajar indirectamente con la
red mediante aplicaciones, ya sea, recopilando datos, a través de un servicio web o
aplicativo, leer/modificar/incorporar/quitar entradas de flujos o utilizar APIs para
integrarse con otros proyectos para compartir infraestructura, comprobar el estado de
los switches, conectar/desconectar puertos, validar decisiones administrativas que se
envían al controlador de la red e incluso métricas que ayuden a la ingeniería del tráfico
para definir la red. El desarrollo de aplicaciones sobre el controller permite innovar a un
nivel más alto ofreciendo mejores funcionalidades y con menor riesgo.
En la ilustración 17 reflexionamos comparando algunos de los principales proyectos OFC,

tras experimentar individualmente con algunos de ellos y otros por sus características y
documentación. Hemos elegido para nuestra experimentación Floodlight [60][74] que
utilizaremos en los laboratorios del siguiente apartado. Principalmente por su
documentación, detalle de las topologías aceptadas (pocos controladores soportan
bucles en la topología) y por su REST API, en favor de adoptar una forma simplificada y
extensible para interconectar el controlador con otros componentes en la
lectura/creación y edición de entradas en un switch OpenFlow (hardware o software).
Floodlight experimenta una evolución continua y estable, con soporte industrial, que le
ayuda a convertirse en uno de los controladores más viables para un ecosistema OF bajo
nuestro criterio. Existen otras alternativas se pueden adaptar para satisfacer sus
necesidades, según el proyecto que se vaya a finaliza y seguro que esta no es la definitiva.
Se empieza a buscar la estabilidad y evitar limitaciones de algunos de estos proyectos
con gran perspectiva pero aún inmaduros o con poco mantenimiento de su comunidad.
Señalamos también POX, que es interesante por su naturaleza y carácter didáctico. Con
la parametrización de lógica de control al controlador definida en lenguaje python. POX
simplifica la forma de definir el comportamiento de la red definida por software,
veremos algún ejemplo sencillo ya que de cara a experimentar puede ser valiosa la

agilidad y sencillez que presta. Existen algunos controladores propios de fabricantes de

equipamiento compatible con OpenFlow que no hemos contemplado.
De cara a continuar con el análisis evolutivo, destacamos un proyecto emergente de la

Fundación Linux apoyado por una amplia lista con los más importantes fabricantes
hardware (Cisco, Juniper, IBM, Ericcson, NEC, etc) y software (RedHat, Microsoft,
VMware, etc) llamado OpenDayLight que “promete” más características soportadas pero
aún está en periodo de desarrollo y pre-lanzamiento [80].
Características NOX POX Beacon Floodlight Ryu
Lenguaje(s) está C++ Python Java Java Python

desarrollado
Lenguaje(s) C, C++, Python Java Java, Python Python

soportados por Python
el controlador
Tiene una No Si Si Si Si
comunidad
activa
Ampliamente No No Si Si No
Documentado
Provee REST API No No No Si Si

(Básica)
Tiene Interfaz Python+ Python+QT4, Web Java, Web Web

Gráfica QT4 Web
Soporta bucles No No No Si No
en la topología
Soporta No No No Si No
conexiones con
islas no-OF
Soporta No No No No No
conexiones entre
islas OF con
bucle
Soporte para No No No Si Si
OpenStack
Ilustración 17: Tabla comparativa con características destacables para decidirnos por un controlador
OpenFlow en nuestra experimentación

 ADMINISTRACIÓN DE LOS RECURSOS, NETWORK HYPERVISOR
Los grandes proveedores de red “delegan” subconjuntos de hardware de red y/o tráfico
a otros operadores de red o usuarios. Si aplicamos estrictamente el concepto de
virtualización visto al principio a la red hemos denominado network hypervisor a lo
siguiente: el componente que gobierna los recursos asignados a cada cliente virtual de
recursos de red, entendiendo como anfitrión que vamos a dividir y aislar una red más
grande totalmente conectada.
Ídem a como en la virtualización de sistemas que hacemos divisiones de los recursos es

posible con un hipervisor de red. Se trata de un OpenFlow controller particular que actúa
como hypervisor/proxy entre un switch y varios controladores OpenFlow. Permitiendo
hacer “rodajas” o dividir el switch en múltiples switch en paralelo, este concepto se
denomina en la literatura slicing a network.
OpenFlow dispone de un controlador de este tipo para hacer slicing de los recursos:
FlowVisor [65], es un network hypervisor desarrollado en Standford que actúa como
proxy entre el plano de reenvío y el plano de control de los dispositivos de red. Este
elemento permite que múltiples OFC puedan dialogar con múltiples switches.
Flowvisor es la parte más importante para aislar y soportar múltiples experimentos, es

un proxy transparente entre islas con recursos OpenFlow. Básicamente el Flowvisor
supervisa que los mensajes OpenFlow operan dentro de su rebanada o slice, es decir
asegurando el aislamiento entre flowspaces que se hayan definido.
OFELIA Control Framework (OCF) [93] es un conjunto de herramientas software

integradas para la gestión de recursos actualmente para bancos de pruebas. Controla el
ciclo de vida de la experimentación, reserva de recursos, instancias, configuración y
monitorización. Es un conjunto completo software que actúa como frontend para
intercambio de información y gestión de los recursos OpenFlow y VMs, definición de
flowspaces sobre equipamiento OpenFlow, configuración creación de máquinas virtuales
XEN y recursos EmuLAB [58]. Está influenciado por la experiencia de otra
infraestructura similar para la administración de la arquitectura GENI. Veremos con más
detalle cómo funciona, trabajaremos con esta herramienta en el laboratorio práctico
agregando y manejando recursos que la infraestructura de las diferentes islas del
proyecto OFELIA proporciona.
VerTIGO [69] es una evolución de Flowvisor, que añade inteligencia a la arquitectura

permitiendo añadir enlaces y puertos virtuales, también se desarrolla dentro del
programa OFELIA FP7.

2.3.2. MÉTODO DE CONTRIBUCIÓN AL PROYECTO
Definiendo redes por software, utilizando como referencia OpenFlow 1.0, analizaremos
como el modelo SDN hace frente a los desafíos del apartado 2.1. Sobre un software de
experimentación local y sobre el despliegue real del proyecto FP7 Ofelia, a través del acceso
facilitado por la fundación i2Cat (Barcelona).
Con el análisis de la herramienta escogida pretendemos experimentar los siguientes puntos
que se abordan en la teoría:
 Naturaleza dinámica
o Solicitar/cambiar recursos dinámicamente
o Escalabilidad
 Vista unificada de los recursos sobre una capa elevada
o Concepto de red Overlay
o Gestión unificada y simplificada
 Implementaciones software y hardware
o Virtualización de los recursos
o Experiencia plano de control y datos desacoplados
o Vista hacía una transición/actualización de niveles inferiores
 Encaminamiento basado en túplas avanzadas
o Red basada en flows
o Comunicaciones inter domino
 Gestión/análisis del tráfico virtualizado
o Problema en la virtualización de red en hipervisores convencionales
o Reutilización de equipamiento actual
En el siguiente capítulo expondremos escenarios prácticos tipo. A día de hoy con algunas
limitaciones pero sin perder de vista el objetivo de utilizar SDN como caso de reflexión
hacia el Internet del Futuro. Tengamos en cuenta que OpenFlow no es SDN pero es la
irrupción real para al modelo.

3. DISEÑO Y RESOLUCIÓN CASO PRÁCTICO:

OPENFLOW NETWORK
El análisis teórico previo resulta propio a la hora de elegir un diseño y las herramientas para
trabajar con una implementación en las tecnologías de la red definida por software.
Actualmente OpenFlow es el único protocolo implantado para la arquitectura de red
definida por software o SDN. En la siguiente ilustración se muestra una pila donde ubicar
los elementos software que se han definido compatibles con OpenFlow que se adaptan a la
arquitectura SDN según su función. Este diagrama servirá como referencia cuando
mencionemos las aplicaciones que utilizaremos para los ensayos prácticos. Los elementos,
de forma genérica ya han sido mencionados en los capítulos anteriores.
Ilustración 18: Diagrama de bloques de una infraestructura OpenFlow completa.
Para este análisis empírico-analítico, experimentaremos utilizando las herramientas de las

diferentes capas de la infraestructura para:
 Definir la red por software
 Gestionar los recursos (slicing en la infraestructura de Ofelia)
 Definir el comportamiento de la red, OpenFlow Controller.
 Gestionar, modificar y obtener datos de comportamiento de la red
 Monitorizar el tráfico y los elementos de la red OpenFlow
 Incidencias en la experimentación con OpenFlow
Haciendo uso de Mininet [49] como software de emulación para definir redes virtuales en
un equipo local, se convierte en una interesante forma de comprender el funcionamiento

con esta herramienta didáctica y para experimentación. Después con el despliegue real del
proyecto FP7 Ofelia, con el propósito de concluir aspectos ventajosos y contras de este
modelo de red haciendo referencias a los propósitos del Internet del Futuro.
Es fundamental conocer la lógica de comportamiento en el procesamiento de entradas en
un switch OpenFlow. Este comportamiento vendrá dado por la versión del protocolo OF
que implemente y podremos comprobarlo en la especificación del mismo a la hora de definir
la red. En la mayoría de equipamiento hardware actual esta implementada la versión 1.0,
es la que hay desplegada en el equipamiento del proyecto Ofelia. Es comprensible que la
versión que encontremos en dispositivos de fabricantes vaya un paso por detrás en favor
de no comprometer la estabilidad ni la imagen de marca, en comparación con la versión que
podemos encontrar en compilaciones propias sobre hardware programable e la
implementaciones software como las del referente Open vswitch. A partir de la versión 1.2
se cuenta con soporte completo para direcciones y tratamiento de las cabeceras IPv6,
podremos probar estas compilaciones en escenario local con la herramienta MININET.
Ilustración 19: Diagrama del flujo de paquetes a través de un switch de OpenFlow versión 1.3.2. Función de
matching.
En la sección 2.3.1 veíamos como se implementa OpenFlow en la electrónica de red, de

forma que pueda coexistir con ligeras modificaciones de los fabricantes para entornos
físicos con tráfico convencional denominados OpenFlow Hybrid switches. Con esto
explicábamos las diferentes formas de instanciación de flujos en la red. Podríamos
conseguir más eficiencia cuanto más proactiva sea, manejar aquello que nos interese y
descartar aquel que no. La regla de comportamiento definido para el tráfico no controlado
es fundamental para evitar que retorne tráfico al controlador, incrementando el tráfico en
la red.
Vemos en la ilustración 19 anterior, la lógica de la función matching para la última versión
OF. 13.2. Esta lógica define el comportamiento ante la entrada de paquetes en el switch.

Contrastando la figura de la versión OF 1.3.2 con la siguiente ilustración 20, vemos

modificaciones en la función de matching. Aparece una tabla específica denominada table-
miss para decidir cómo procesar los paquetes coincidentes para los que no haya una flow
entry creada, las dos opciones son: descartarlos (drop) o pasarlos a otra tabla para enviarlos
al controlador a través del canal de control, incorporándolo en estos mensajes que
intercambia el OpenFlow Controller y con baja prioridad. Esto se traduce también en que
exige un comportamiento más reactivo y eficiente del tráfico, también más seguro si
explícitamente indicamos aquello que permitimos por la red y lo demás se descarta. Aunque
la tendencia es la instanciación de flujos híbrida aprovechando la agilidad de un modelo
reactivo y la granularidad de actuación proactiva; para optimizar debemos controlar mejor
las entradas no deseadas para evitar tráfico adicional en la red de datos.
Ilustración 20: Diagrama del flujo de paquetes a través de un switch de OpenFlow versión 1.2. Función de
matching.
En los siguientes apartados, ponemos en práctica las herramientas que hemos mencionado
para nuestro laboratorio práctico utilizando para el despliegue de topologías Mininet y FP7
Ofelia gestionando una infraestructura real. Representaremos un escenario tipo donde
enviemos tráfico en una red virtualmente distribuida definida por software, según una
filosofía reactiva y proactiva definiremos ejemplos de comportamiento para flujos de
entrada. No olvidemos que uno de los esfuerzos de este modelo es la gestión simplificada
de la red y así lo hemos querido transmitir con una selección de herramientas. De entre las
evaluadas hemos conformando una vista completa al lector de los elementos del diagrama
de bloques de la ilustración 18. Aproximar estos escenarios a la casuística del Internet del
Futuro, verificando tramas de datos y analizar la red usando las mismas herramientas de
captura de tramas y análisis de rendimiento de la red convencional acercando el modelo
tradicional a este.
Mencionaremos a partir de ahora comandos y/o parámetros necesarios para los escenarios
que planteamos, indicamos las referencias a las especificaciones y tutoriales para
profundizar en este ámbito. Las pruebas aquí realizadas se han ejecutado y probado antes
de mostrar los resultados, con el objetivo de experimentar el comportamiento teórico y
obtener conclusiones.

3.1. MININET, SOFTWARE DE EXPERIMENTACIÓN LOCAL PARA SDN

Para adquirir experiencia en el funcionamiento de la red definida por software con
OpenFlow usaremos a plataforma de emulación Mininet.
Mininet proviene de la Univeridad de Standford (California); es un sistema para la creación
rápida de grandes prototipos de redes con recursos limitados, en un único ordenador [49].
Creando una red virtual realista, equipos sobre un kernel real, switches y el código de la
aplicación en una sola máquina (VM, nube o nativa), disponible para funcionar en segundos
solo con el comando mn. Ver estructura de funcionamiento en la figura 24.
Ilustración 21: MiniNet crea una red virtual creando procesos en el host por cada espacio de nombres de red y
conectándolos virtualmente como pares Ethernet (Veth). En este ejemplo, se conectan dos host a un OpenFlow
switch en espacio de usuario [49].
3.1.1. DEFINIR TOPOLOGÍA DE RED, MININET 2.0
Hemos utilizado la versión preinstalada sobre una máquina virtual denominada mininet-
2.0.0-113012-amd64-ovf disponible desde la web del proyecto Mininet. Incluye la versión
estable Mininet 2.0.0 [59]. Instalada en máquina virtual con sistema operativo GNU Linux
Ubuntu 12.10 64bits sobre VirtualBox. Recomendamos esta instalación porque ha sido
configurada y testada por los propios creadores en Standford, con las ventajas añadidas de
desplegar el laboratorio virtualizado para experimentación, solo requiere un equipo
anfitrión con sistema operativo 64bits y VirtualBox [18]. Destacar que la versión MININET
2.0.0 (nov, 2012) o MININET HiFi (denominada así en numerosos documentos de
experimentación), ha soportado numerosas evaluaciones de rendimiento y fidelidad para la
recreación de entornos de red, destaca además por sus significantes mejoras de estabilidad
y rendimiento con respecto a la anterior.

Cualquier topología de red puede ser fácilmente diseñada e implementada en Mininet,

mediante el uso de una API en Python. Podemos ver en la documentación ejemplos para
aprender a implementar una red, compilarla y ejecutarla directamente.
La única indicación para generar la topología es que dependiendo del controlador que
conectemos a la red y según que topologías concretas, pueden ocasionar problemas de
comportamiento en la red. Generalmente son provocadas por bucles e interconexión con
otras islas OF y no-OF. Debemos examinar las condiciones de la red que necesitamos
definir nuestra, ya que Mininet no nos va a poner restricciones y para aproximar al lector
al tiempo de despliegue que conlleva una topología definida.
Un ejemplo de crear una red con 9 switches y 64 equipos conectados tardó unos 5 segundos.
Utilizando la máquina virtual GNU Linux Ubuntu preconfigurada por Stanford para Mininet
con VirtualBox [18], dando acceso a un núcleo del procesador y 1024MB de memoria RAM.
El equipo anfitrión es un ordenador personal portátil con procesador Intel® Core™ i5-
2520M, 8GB de memoria Ram DDR3 y disco duro de estado sólido.
Mininet puede utilizar el componente switch OpenFlow/Stanford de referencia o utilizar uno

externo, esto es una de los elementos que a la hora de definir la topología debemos aportar
indicando con esto las características de los switches que despliega. A la hora de definir la
red debemos indicar que utilizaremos la versión Open vSwitch del kernel del sistema
operativo (concretamente para los experimentos hemos usado 1.4.3 estable), con el
parámetro –ovsk para que se ejecute en el fast path en lugar de en espacio de usuario con
la opción disponible con la opción disponible —switch user.
sudo mn —custom mytopo.py —topo mytopo —mac –ovsk —pre myifconfig2.sh —controller remote
Ilustración 22: Comando para arrancar Mininet con una topología personalizada en mytopo.py, con simplificación
de las direcciones MAC secuenciales con la opción –mac, y cargando la configuración de los equipos (ifconfig)
conectados a la red --pre (sino se pone por defecto o se puede poner después), por último queda preparado para
controlador remoto. [59]
Podemos comprobar cómo están conectados los equipos una vez desplegada la red con los
siguientes comandos.
 Dump: Muestra información de los componente creados para la red y de los procesos
en espacio de usuario asociados en ejecución.
 Nodes: Listado de nodos.
 Net: Listado de la conexiones de red, detallando la interfaz de red conectada.

En la instalación de Mininet se incluyen herramientas de ejemplo en lenguaje python con el

objetivo de servir de ayuda a la hora de comenzar a trabajar con la definición de escenarios.
Algunas implementaciones generan topologías con unas determinadas características, otras
definen comportamientos particulares para el tratamiento de paquetes. El ejemplo
miniedit.py, es un pequeño editor mediante el cual podemos definir una topología y
arrancarla con Mininet, (habitual ver ejemplos con esta herramienta en la documentación)
sirve como herramienta de apoyo a la hora de definir flujos estáticos, teniendo una
representación de la topología.
Ilustración 23: Con MiniEdit definimos una topología y directamente podemos ponerla en marcha para
experimentar.
Para los escenarios prácticos del siguiente capítulo hemos utilizado al menos dos switches.
Como escenario tipo de tráfico entre dos islas OpenFlow, que puede ser la interconexión
entre pods o dominios interconectados a través de tecnologías de extensión de la red de
nivel 2 como las que reseñamos en el Apéndice 5.1.
Ilustración 24: Escenario con los elementos básicos OpenFlow que simularemos dentro de un equipo portátil [49]

Podemos utilizar el OpenFlow Controller de referencia --controller ref por la interfaz

localhost puerto 6684 mediante el comando dpctl o conectar otro controlador externo
mediante una conexión TCP al puerto 6683. Utilizaremos la segunda opción dado que será
el esquema habitual en la realidad y un controlador externo permite opciones más
avanzadas. Pasando como parámetro --controller remote al arrancar Mininet,
estará listo para que se conecten al puerto por defecto.
Una vez conectado el controlador a la red comenzará a detectar equipos OpenFlow en el
nivel de enlace. El OpenFlow Discovery Protocol (OFDP) aprovecha la capa de enlace de
Discovery Protocol (LLDP) con modificaciones sutiles para realizar la detección de
topología de una red OpenFlow. Estas modificaciones se denominan funciones OFDP.
Tengamos en cuenta para analizar problemas de conexión o el estado exitoso de la misma
entre el switch o el OpenFlow Hypervisor y el controlador, de los mensajes de información
y depuración que el controlador presenta. Los mensajes de error del tipo
OFPT_ERROR_MSG están recogidos en la especificación del protocolo correspondiente a la
versión que se implementa aportando mucha información relevante para detectarlos y
corregirlos.
Diseñar la red y decidir el comportamiento de la misma para la instanciación en términos
de flujos o flows. Definiremos así en nuestros laboratorios prácticos OpenFlow
experimentos según las distintas formas de instanciación de flujos, analizando de forma
coherente los resultados con la teoría.
 Instanciación Reactiva
Cuando un nuevo flow llega al switch, el agente software OpenFlow del switch realiza una
búsqueda en las tablas de flujos, ya sea una búsqueda ASIC o en una tabla de flujo software
si se trata de un virtual switch o vSwitch software, si no se encuentra ninguna coincidencia
para para este flow, el switch reacciona creando un paquete OFP (OpenFlow Packet) y lo
envía a su controlador solicitando instrucciones de comportamiento. Reacciona según el
tráfico y consulta al controlador OpenFlow creando una regla en la entrada de tráfico basado
en la instrucción que reciba. Esto puede ser demasiado costoso con unas cuantos cientos
de miles de entradas para mantener además de que genera mucho tráfico de consulta,
siendo costoso tanto para unidades de procesamiento equipadas en equipos de red + ASICs
(Network Processor Units) o en CPUs de propósito general para vSwitches.
Según una filosofía reactiva, como una acción de comportamiento “normal” o

predeterminada en el controlador para todas las entradas permite la rápida integración de
dominios OpenFlow / SDN conectados a la red nativa. El modo de actuar se define
previamente y cuando se conecta a la red se comportará según la forma de proceder
cargada. Procesar los paquetes que llegan al controlador usando una acción por defecto

como el reenvío tradicional soportado en switches, o funcionalidades comunes como un

si de un hub o un L2 switch con soporte VLAN (802.1q) se tratase, o añadir características
convenientes para la detección de bucles (802.1d) como presta la especificación OpenFlow
[72], entre otras. Estas funciones, también llamadas aplicaciones para el controlador
podemos reutilizarlas, desarrollar nuevas o mejorar las existentes si están disponibles para
ello. [73][74]
Ilustración 25: Capturas del analizador de trafico Wireshark filtrando el tráfico OpenFlow en un escenario
MININET reactivo. Veamos la inserción de tramas FLOW MOD reactiva tras la generación de tráfico ICMP entre
los host 2 y 3.
Laboratorio 1: POX basic l2_learning_switch
 Plano de datos: Topología MININET en árbol profundidad 3 (7 switches).

 Plano de control: l2_learning_switch definido en python (reactivo)
 Controlador: POX
 Aplicaciones: componentes adicionales monitorización GUI.
 Objetivo: Ejemplo didáctico primera red con MININET en el plano de datos y el
controlador POX como ejemplo didáctico del plano de control definido por software
con un ejemplo definido en el lenguaje interpretado python.
Como primera opción para introducirnos en el funcionamiento de un controlador

utilizaremos POX por su carácter didáctico para un escenario reactivo. Utilizaremos un
comportamiento de ejemplo similar al de un switch de nivel 2 como ejemplo de norma
reactiva, seleccionado de entre los muchos componentes para POX [73]. Python por ser un
lenguaje interpretado simplifica mucho el código necesario para definir funciones en el
controlador, es una de las razones por las que sigue teniendo una fuerte comunidad

académica y comunidad que lo prefiere al original NOX desarrollado en C, aunque es menos

eficiente.
Con los componentes de comportamientos seleccionados de entre los que proporciona la
comunidad a este proyecto o propios que desarrollemos. Arrancamos el controlador POX
pasando como parámetros los componentes que actuarán en la red conectada, previamente
desplegada con Mininet.
#!/usr/bin/env python
# Copy and paste https://github.com/hip2b2/poxstuff/blob/master/of_sw_tutorial.py
from pox.core import core

import pox.OpenFlow.libOpenFlow_01 as of
log = core.getLogger()
table = {}
def send_packet(event, dst_port = of.OFPP_ALL):

msg = of.ofp_packet_out(in_port=event.ofp.in_port)
if event.ofp.buffer_id != -1 and event.ofp.buffer_id is not None:
msg.buffer_id = event.ofp.buffer_id
else:
if event.ofp.data:
return
msg.data = event.ofp.data
msg.actions.append(of.ofp_action_output(port = dst_port))
event.connection.send(msg)
def _handle_dumbhub_packetin(event):
packet = event.parsed
#print debug packets

print packet
send_packet(event, of.OFPP_ALL)
log.debug(“Broadcasting %s.%i -> %s.%i” %

(packet.src, event.ofp.in_port, packet.dst, of.OFPP_ALL))
# launch whichever implementation you want via function

def launch():
core.OpenFlow.addListenerByName(“PacketIn”, _handle_dumbhub_packetin)
log.info(“L2 learning switch is running.”)
Ilustración 26: : Código Python para definir el comportamiento de reenvío similar a un switch, definidos en el
directorio ../pox/pox/forwarding/l2_learning.py de la instalación de POX.
Para el siguiente ejemplo hemos lanzado el controlador POX con la aplicación de

comportamiento l2_learning_switch. Este componente concretamente aprende direcciones
L2 aunque no lo es puramente basándose en direcciones MAC. Ya que su comportamiento
es instalar flujos con el mayor número de coincidencias de una túpla para el tráfico que
recibe y reenviar los paquetes. Por ejemplo, las diferentes conexiones TCP se traducirán en
diferentes flujos. En este ejemplo incluimos más componentes que recopilan información

del controlador, transporte de mensajes y que arrancan un módulo aplicativo web para
representarla a modo de monitor de la red. Veamos en la figura las entradas que completa
con el tráfico ICMP generado entre todos los nodo.
Tras desplegar la red Mininet y lanzar con el comando pingall (propio de Mininet) lanzamos
una comprobación de ping de todos a todos. La generación de tramas de descubrimiento
genera información de cómo están conectados los elementos al switch y el controlador
recopila toda la información de los mensajes que intercambia para formar entradas de
flujos, representadas en con el módulo de representación web POXDESK [88] que actúa de
monitor.
./pox.py forwarding.l2_learning samples.pretty_log web messenger messenger.log_service

messenger.ajax_transport OpenFlow.of_service poxdesk
Ilustración 27: En la línea de comandos lanzamos POX con las aplicaciones correspondientes para el ejemplo. En
el navegador web POXDESK muestra la información recopilada para cada switch, tras haber generado paquetes
de comprobación en consola entre todos los equipos de la red.
 Instanciación Proactiva
En lugar de reaccionar a un paquete, el controlador OpenFlow podría cargar la flow table

con el comportamiento para el tráfico coincidente que entre al switch, basado en static flows.
Similar al comportamiento de una tabla de ruta convencional, con la salvedad y mejora de
definir la correspondencia granular a un prefijo destino en un árbol de búsqueda. Al
predefinir todos los flujos y sus acciones antes de tiempo en las tablas de flujo los paquetes
son reenviados en un tiempo de respuesta lineal; si el comportamiento para la tabla está en
la TCAM o en la implementación software de los vSwitch, eliminando las latencias
introducidas de consulta para cada flow.

El reenvío proactivo, permite al ingeniero de tráfico instalar reglas de flujo ajustables para
reenviar, reescribir o descartar tráfico. Potenciales usos por ejemplo son las políticas de
cortafuegos para procesar tráfico L2-L4 por puertos específicos, direcciones MAC o IP
Las reglas pueden ser instaladas para la transmisión selectiva de flujos dirigidos a puertos,
por ejemplo para monitorización de tráfico. Otro escenario podría ser a medida que nuevos
usuarios se conectan a la red, los paquetes pueden ser redirigidos a un servidor de
autenticación o un portal captivo (SNAC incluye un módulo con esta funcionalidad), lo que
podría añadir una política de seguridad basada en la identidad. El tráfico puede ser enviado
por vínculos particulares en función del precio del ancho de banda, la hora del día, la latencia
de controlador a cambio, mecanismos de encaminamiento ad-hoc o cualquier otra
restricción.
Laboratorio 2: Floodlight push static flows
 Plano de datos: Topología Mininet en árbol profundidad 2 (3 switches).

 Plano de control: Definido estáticamente, proactivo.
 Controlador: Floodlight
 Aplicaciones: curl, Avior y programa python para comprobación del flujo creado.
 Objetivo: Definición completa en los equipos de la red de un flujo de
comportamiento puramente proactivo descartando el resto del tráfico.
En los siguientes ejemplos vamos a utilizar Floodlight (versión estable 0.85). Esta es otras
de las ventajas de este modelo definido por software, y es que, el plano de control es
independiente al controlador que utilicemos, siempre y cuando implemente el protocolo
adecuadamente. Floodlight [60] es un proyecto con un importante apoyo del sector
industrial (particularmente de la compañía BigSwitch), utilizaremos la REST API para
intercambiar entradas con el controlador, los componentes que incorpora ofrecen mucha
información de topología y estado de la red. Es común encontrar ejemplos o referencias a
este controlador en experimentos, por su funcionamiento y su documentación oficial
además por ser además de los pocos que manejan situaciones con bucles [74] [72] [20].
Otra de las ventajas del modelo por software es que podemos añadir reglas de forma
centralizada al controlador para gobernar toda una red y no de forma individual en los
nodos intermedios, routers o firewalls de un modelo estático.
FloodLight por defecto incorpora el componente forwarding; para este escenario concreto
queremos un comportamiento de reenvió proactivo, lo que significa que el switch solo
enviará paquetes al controlador si tiene una entrada explicita que coincida y una acción con
instrucciones. El resto de paquetes no controlados en la miss-table serán descartados.
A continuación indicamos los pasos para excluir la carga de este componente al controlador
y compilar la aplicación Floodlight para nuestro entorno, hemos actualizado la máquina
virtual a la siguiente la versión Java 1.7.0.25 en la máquina de laboratorio Mininet.

Definimos la topología para el ejemplo con Mininet como vemos en la ilustración siguiente:
Ilustración 28: Diagrama de la topología definida para ejemplo utilizando una red puramente reactiva, definiendo
en los switches s1, s2 y s3 las entradas correspondientes para que h1 y h4 estén conectados. Para definir esta
topología con mininet y controlarla con Floodlight hemos utilizado el siguiente comando:
sudo mn—topo tree,depth=2 --mac—switch ovsk—controller remote
1. #’apt-get install build-essential ant python-dev eclipse default-jdk git curl’
2. ‘git clone git://github.com/floodlight/floodlight.git’
3. cd floodlight
4. vi src/main/resources/floodlightdefault.properties
5. Remove the line “net.floodlightcontroller.forwarding.Forwarding, \”.
6. Ejecutamos ant para contruir el ejecutable .jar en la ruta ~/floodlight/target
7. ’ant’
8. java -jar target/floodlight.jar
Pasos previos de instalación, configuración y compilación de Floodlight sin

Ilustración 29:
aplicación de reenvío para comportamiento puramente proactivo.

Una vez que tenemos un controlador sin ningún comportamiento establecido por defecto
para el reenvío, utilizaremos la técnica de transferencia de estado representacional
denominada REST (Representational State Transfer) para establecer entradas en la tablas
de reenvió del controlador. Floodlight implementa esta aplicación en los componentes por
defecto para aceptar entradas según su REST API [74], modificaciones (flow mods) o
consultas de reglas de flujos. Para ello es necesario indicar para un switch la entrada
coincidente y acción a realizar.
Los campos para cada entrada y las acciones son las definidas en la especificación OpenFlow,
de nuevo referirnos a la especificación estándar ayuda a que el manejo de la red sea lo más
independiente de las aplicaciones, con la salvedades propias de los lenguajes de
programación o aplicativos que utilicemos. Existen extensiones propias de fabricantes a la
especificación estándar lo cual obliga a que si queremos utilizarlas el controlador tiene
también que implementarlas. Mediante el comando curl desde un terminal GNU Linux
como cliente transferiremos las modificaciones de flujo o flow mods en el formato de
marcas para intercambio de datos ligeros JSON (JavaScript Object Notation) utilizado en
servicios web. El controlador OpenFlow en este caso que actúa como un proveedor de
servicios en la comunicación e interpreta la entrada o push flow entry añadiéndola a sus
tablas directamente sin más interacción.
Otra opción en lugar de interactuar directamente con el controlador mediante la REST API,
es la de conectar un aplicación controlador (Controller Aplication) veasé la “pila” OpenFlow
de la figura 18, que interactúa por la API con el controlador.
La aplicación vinculada al controlador que vamos a utilizar en este caso Avior es un módulo
de control para Floodlight. Es un proyecto de código abierto desarrollado por el equipo
Marist OpenFlow Reserch Project e IBM. Avior fue diseñado para llenar un vacío en el ámbito
de la administración de Floodlight e impulsando el desarrollo de aplicaciones abiertas en
este ámbito. La aplicación se ejecuta de forma independiente del controlador y se comunica
con el controlador utilizando el REST API por defecto, equivalentes a si las introducimos
manualmente en el controlador, para los experimentos hemos utilizado la versión AVIOR
1.3 [89]
Desplegamos la red Mininet, lanzamos el controlador Floodlight previamente compilado

para nuestra instalación como indicamos en la ilustración 29. Para aprovechar la
granularidad es importante manejar un listado con la nomenclatura Hexadecimal o Decimal
con los protocolos de nivel de enlace (campo ether-type) y nivel IP (campo protocol), así
como el diagrama de la red para conocer los puertos que aplicamos, en nuestro ejemplo
establecemos el camino puramente estático o proactivo para comunicar h1 y h4 sin
restricciones de tráfico, dirigiendo el tráfico por los puertos intermedios.

a) Modificaciones tabla switch 2 para conectar puertos host1 y switch1 bidireccional
{”switch”:”00:00:00:00:00:00:00:02”,”name”:”allow_h1_s1”,”active”:”true”,
“priority”:”32000”,”actions”:”output=3”,”ingress-port”:”1”}
{”switch”:”00:00:00:00:00:00:00:02”,”name”:”allow_s1_h1”,”active”:”true”,
“priority”:”32000”, “actions”:”output=1”,”ingress-port”:”3”}
b) Modificaciones tabla switch 1 para conectar puertos s2 y s2 bidireccional
{”switch”:”00:00:00:00:00:00:00:01”, “name”:”allow_s3_s2”, “active”:”true”,

{”switch”:”00:00:00:00:00:00:00:01”,”name”:”allow_s2_s3”,”active”:”true”,
c) Modificaciones tabla switch 3 para conectar puertos s2 y s2 bidireccional
{”switch”:”00:00:00:00:00:00:00:03”, “name”:”allow_s1_h4”, “active”:”true”,

{”switch”:”00:00:00:00:00:00:00:03”, “name”:”allow_h4_s1”, “active”:”true”,

d) Modificaciones tabla switch 1 para descartar tráfico solo en sentido h1 a h4

(unidireccional)
{”switch”:”00:00:00:00:00:00:00:01”, “name”:”allow_s2_s3”, “active”:”true”,

“priority”:”32000”,”ingress-port”:”1”}
Ilustración 30: Pares de entradas estáticas a, b, c transferidas al controlador para establecer el camino
bidireccional entre el host 1 y el host 4, en el apartado d, modificamos en el switch central el paso en un sentido.
Cuando la prioridad de una entrada en una tabla es cero, significa que si hay un paquete
que coincide con una regla con prioridad mayor que cero tiene preferencia. El valor máximo
es 32768. Con esto podríamos definir un comportamiento estándar sino hay una regla con
más prioridad que haga que se comporte de otra forma.
No especificar ninguna acción, en lugar de especificar alguna medida para eliminar paquetes
equivale a descartar o DROP en la tabla de matching.

Ilustración 31: Aplicación cliente – servidor ejecutándose en los host 1 (servidor) y host 4 (cliente), Tras poner en
el switch 1 la regla d) de la ilustración anterior que descarta el tráfico en sentido h1 -> h4 que pasa por el switch 1.
En el apéndice 5.3 Ilustración 45, podemos ver ejemplos de otras entradas avanzadas
probadas en este escenario a través de la REST API con el controlador Floodlight en modo
proactivo.
Ilustración 32: Para verificar que el flujo de datos se establece satisfactoriamente, ejecutamos una aplicación
python cliente-servidor simulando un comportamiento heartbeat que comprueba la conexión entre los nodos a
través de un socket, cuando aplicamos las entradas a,b,c anteriores, recibe respuesta.
 Instanciación de flujo Híbrida
Una combinación de ambos comportamientos podría permitir la flexibilidad para un

conjunto del tráfico y continuar preservando las prestaciones de reenvío proactivo de baja
latencia para el resto del tráfico (términos de nano segundos). El mecanismo reactivo aun
siendo más costoso añade una seguridad granular que puede ser razonable si la política de
decisión es importante y precisa.

Pretendemos con estos modos de operación señalar aquellos factores que pueden afectar al
rendimiento de la SDN en favor de que se escoja un modo de operación acertado en el
diseño. Evitando que el primer paquete que llegue al switch tenga que ser consultado al
controlador por ejemplo.
Laboratorio 3: Floodlight Forwarding & Static Flow management
 Plano de datos: Topología Mininet lineal 5 switches.

 Plano de control: Reenvió NORMAL [72] reactivo y regla estática para descartar
tráfico para definir instanciación de flujos híbrida
 Controlador: Floodlight
 Aplicaciones: AVIOR.
 Objetivo: Instanciación híbrida, añadiendo a una red con comportamiento reactivo
static flows, ejemplo con regla para tráfico IPv6 sin soporte completo de OF 1.0.
Para el siguiente laboratorio añadiremos entradas de comportamiento estáticas a un

comportamiento normal de reenvío. Combinando la instanciación reactiva y con la
instanciación proactiva para aquellas entradas que programemos. Particularmente
definiremos una entrada para descartar el tráfico IPv6.
Por defecto cuando compilamos y arrancamos el controlador FloodLight incluye el módulo
de reenvió reactivo (que habíamos excluido en el ejemplo anterior). Para este ejemplo
vamos a seguir los mismos pasos de compilación, dejando la referencia a este módulo
net.floodlightcontroller.forwarding.Forwarding en el fichero.
Floodlight desde sus comienzos fue diseñado para trabajar en entornos con ambos tipos de
redes, es decir, con OpenFlow y sin OpenFlow switches. El algoritmo estándar de forwarding
precargado encontrará todas las islas OpenFlow que haya conectadas al controlador entre
dispositivos origen y destino ; los flow mods que se instalen en la tabla del controlador
vendrán dados por el camino más corto y si se recibe un paquete de entrada sin un punto
de conexión definido para este en el dispositivo, se realiza inundación del paquete por todos
los puertos (excepto por el de entrada) con el menor número de árbol de expansión (acción
OFPP_FLOOD en la especificación).
Utilizando la aplicación conectada al controlador Avior nuevamente, ahora con una

perspectiva de comportamiento hibrida ante la llegada de tráfico, conectaremos sobre el
nivel del controlador esta aplicación de gestión más intuitiva, para cargar manualmente
tuplas avanzadas en el controlador, denominadas también static flows. Al mismo tiempo
que monitorizamos el equipamiento en la red, podemos granular el tráfico que avanza por
la red como hablábamos en la sección 2.3.1 de la segregación del plano de datos con
escenarios híbridos. Partiendo de una red con un comportamiento de forwarding NORMAL,

como el de un switch L2 convencional con soporte VLAN (indicado en la especificacion

OpenFlow), tenemos conectividad entre todos los nodos de nuestra topología, utilizamos el
direccionamiento link local de ipv6 para el dominio de enlace creado haciendo más sencillo
el direccionamiento sin necesidad de routers o configuraciones.
Ilustración 33: Panel principal de AVIOR con la información que obtiene del controlador Floodlight conectado a
Mininet. Desde aquí con la opción de Manage Flows podemos enviar reglas al controlador (genera e inserta
utilizando REST API). Abajo destacar las entradas estáticas configuradas para el switch señalado, vemos que son
de tipo estático.
Para definir reglas en escenarios IPv6 utilizamos el parámetro ether type 0x86DD, como
vemos en el ejemplo. Aunque sin la misma granularidad que para IPv4 porque OF 1.0 no
permite el tratamiento de cabeceras IPv6, que comienza a realizarse en versiones OF 1.2 y
superiores. Junto a la concordancia con puerto, información de MAC o de transporte un
ajuste para concordancia de entradas bastante preciso.
Ilustración 34:En la imagen vemos como introducimos una regla para el tráfico identificado en la cabecera
Ethernet Type que sea 0x86DD que corresponde a IPv6 no se realice acción, por tanto, se descarta acorde a la
especificación de OpenFlow (acción DROP). En la ilustración anterior vemos las coincidencias que ocurren para
esta entrada.

root@mininet-vm:~# ifconfig
h1-eth0 Link encap:Ethernet HWaddr 00:00:00:00:00:01
inet addr:10.0.0.1 Bcast:10.255.255.255 Mask:255.0.0.0
inet6 addr: fe80::200:ff:fe00:1/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:176 errors:0 dropped:156 overruns:0 frame:0
TX packets:24 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:11984 (11.9 KB) TX bytes:2052 (2.0 KB)
root@mininet-vm:~# ping6 fe80::200:ff:fe00:2%h1-eth0

PING fe80::200:ff:fe00:2%h1-eth0(fe80::200:ff:fe00:2) 56 data bytes
64 bytes from fe80::200:ff:fe00:2: icmp_seq=1 ttl=255 time=3.78 ms
^C
--- fe80::200:ff:fe00:2%h1-eth0 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2005ms
rtt min/avg/max/mdev = 0.097/1.488/3.783/1.635 ms
root@mininet-vm:~# ping6 fe80::200:ff:fe00:2%h1-eth0
PING fe80::200:ff:fe00:2%h1-eth0(fe80::200:ff:fe00:2) 56 data bytes
From fe80::200:ff:fe00:1 icmp_seq=1 Destination unreachable: Address unreachable
Ilustración 35 : Configuración de red del equipo host1 conectado al swith1 y lanzando ping6 a equipo host2,
responde hasta que ejecutamos “push” para la regla denegar_ip6 (ver ilustración 34) que lo envía al controlador.
No afecta al resto de tráfico comportándose según la norma reactiva del controlador con forwarding activo.
3.2. OFELIA, INFRAESTRUCTURA EXPERIMENTACIÓN BASADA EN OPENFLOW
OFELIA es un proyecto financiado por la Unión Europea dentro del marco FP7 programa
para la investigación y el desarrollo tecnológico. Tiene una duración de 7 años desde 2007
hasta 2013. Proporciona un espacio de experimentación donde se interconectan diferentes
testbeds distribuidos por Europa y América del Sur (Brasil). Esta red de experimentación es
de acceso libre para las instituciones de investigación y académicas. Esto permite testear
escenarios realistas y el posterior despliegue de la tecnología que ha probado en la
infraestructura. Han construido la primera gran red de “switches” (conmutadores)
OpenFlow de Europa, hecho que vemos importante para la experimentación y migración a
un Internet del futuro.
La investigación de internet del futuro necesita entornos flexibles a gran escala que
soporten virtualización de los recursos, y que permitan nuevos algoritmos de control y
encaminamiento. En este contexto como hemos mencionado SDN (Software-Defined
Networking) es un “nuevo” paradigma para las redes de comunicaciones, que permite crear
nuevos tipos de aplicaciones, tecnologías y modelos de negocio. Además, permite escalar los
dispositivos y servicios existentes y optimizarlos.
Para administrar las infraestructuras, OFELIA ha desarrollado su propio OFELIA Control
Framework (OCF), un software de control con licencia de software libre y que se basa en
una arquitectura escalable y distribuida [94], basándose en Expedient [95] un framework
para GENI de la universidad de Stanford. OCF ofrece una administración del ciclo de vida

de los recursos, monitoreo de los mismos y una orquestación automática del experimento,
utilizando recursos distribuidos y heterogéneos. A cada centro de recursos que participa en
el proyecto en una zona geográficamente distante le denominaremos isla, como se refieren
en el proyecto.
Ilustración 36: Panel de control OFC, creación de VM en nuestra slice sobre los recursos de una isla agregada al
proyecto y al slice.
El panel de control oculta la complejidad de las configuraciones de interconectar una isla y

su federación dentro de Ofelia. Provee la suficiente información para que los usuarios que
experimentan puedan definir sus entornos utilizando recursos heterogéneos y escalables.
Permitiendo hacer reserva de recursos y poner en ejecución experimentos en toda OFELIA
con elevado nivel de abstracción.
Para la realización de experimentos, los usuarios solicitan y reciben el control sobre una red
virtual que se compone de un subconjunto (slicing) de la red física de OFELIA. Esta red física
está compuesta por todas las islas agregadas y federadas en el proyecto.
¿Qué recursos proporciona OFELIA a través del Ofelia Control Framework?
 Máquinas virtuales finales. Con un sistema operativo GNU/Linux Debian Squezee
instalado. A esta máquina paravirtualizada sobre sus sistemas con XEN le podemos
configurar la memoria RAM asignada. Acceder a ellas remotamente por ssh por la
interfaz eth0 reservada para el control , instalar software y configurar el resto de
interfaces de red que proveen, que suelen ser dos o tres (según las que disponga el
anfitrión en esa isla), estas interfaces son para experimentar y están conectadas
(bridge) a la red OpenFlow.
 Una máquina virtual de las anteriores será donde instalar el controlador de la red
OpenFlow. Permitiendo que el usuario recurra a la implementación del controlador
que desee y se asigne al slice desde el panel de gestión de OFELIA.
 Un subconjunto de la red general denominado flowspace (rutas de datos asignados
en la estructura de conmutación OpenFlow como el plano de datos para
experimentar). El control de este flowspace irá dirigido a la máquina que asignemos
como controlador de nuestra slice.

 A través de una interfaz gráfica de usuario (GUI), el usuario puede crear y ejecutar
experimentos. Cada isla tiene su panel de acceso y configuración web a través del
cual se permite el control de los recursos en todas las islas federadas (según
también los niveles de acceso). Hemos accedido desde la isla i2cat en Barcelona a
los recursos de las demás islas que hay actualmente operativas o parcialmente
operativas (ver Ilustración 37)
En OFELIA [90] la federación se divide en dos: Intra-Federación e Inter-Federación. Todas

las islas tienen el control y conectividad de datos experimentales a través de túneles
OpenVPN en Gante (Bélgica). Para obtener acceso, es necesario registrarse en OFELIA
(datos personales, universidad, motivo, etc.…) y a partir de entonces configurar el acceso
OpenVPN con las credenciales generadas y asignadas.
Algunas de las islas tienen conectividad a la red GEANT [66]; la red informática europea
multi-gigabit más grande del mundo dedicada a la investigación y la enseñanza, se está
conectando con redes similares de otras partes del mundo para crear una única red mundial
de investigación. Estas islas tienen conectividad de capa 2 (GRE) y pueden obtener
velocidades de transmisión cercanas a 1 Gigabit por segundo. En el caso de las islas que
actualmente no están conectados a la red GEANT, la conectividad se establece a través de
VPN (OpenVPN) a través de Internet > 23Mbps. .
Ilustración 37: Islas con recursos disponibles (Agosto 2013) para agregar y solicitar recursos para experimentar
en Ofelia (Agosto 2013). También es posible desde fuera de panel de control de Ofelia consultar a través de una
url pública el estado de los recursos de las islas [94].

Nos centraremos en la abstracción de las heterogeneidades del espacio de red. Durante el

desarrollo de este proyecto se ha aportado un retorno con la creación de tickets a i2Cat
miembro de OFELIA y líder en el proyecto de desarrollo del OFC, también ante problemas
de funcionamiento de la infraestructura, la isla i2Cat ha sido nuestro punto de acceso a la
infraestructura europea Ofelia (se ha experimentado con recursos en Berlín, Catania y
Trento). Actualmente OFC está en la versión 0.5, hemos seguido desde principios de 2012
con versión 0.3 hasta ahora, con una evolución en cuanto a robustez y fiabilidad
importantes, así como la integración y federación de otras islas unidas de países Europeos
al proyecto OFELIA.
Ilustración 38: Configuración y topología de la isla i2Cat en la primera fase del proyecto OFELIA, conectada a la
red GEANT a través del enlace con IBBT en Gante. En esta fase participaban (TU Berlin, ETH Zürich, IBBT Gent,
UNIVBRIS University of Bristol e I2Cat Barcelona) [90].
En la anterior ilustración veíamos la topología configurada con el equipamiento particular

de la isla en Barcelona, utilizando switches con soporte OpenFlow 1.0 marca NEC modelo
P8800/S3640-24T2XW. Es interesante ver las diferentes islas como están configuradas
dependiendo del equipamiento que se les ha proporcionado antes de seleccionar que
topología queremos definir para nuestra abstracción virtual de esa red, lo que
denominamos en Ofelia nuestro flowspace. (Detalle de los testbet [94])
Generalmente esta selección del espacio de trabajo suele definir una reserva granular
gruesa de recursos (coarse flows o macroflows visto en la sección 2.3.1), de modo que sea
el controlador quien defina el comportamiento fino, Así no restringimos a priori el tráfico
que van a cursar las aplicaciones.

Ilustración 39: Solicitud de recursos y espacio de flujos definido (en blanco) para nuestro experimento
(seleccionados los puertos/conexiones de los switches), podemos elegir tuplas compatibles con OF. El identificador
VLAN será asignado como medida de aislamiento de flowspaces de Ofelia sino se indica expresamente o no esta
entre los disponibles. Detallado en el laboratorio 4.
3.2.1. DEFINIR RED DE EXPERIMENTACIÓN CON OFELIA CONTROL FRAMEWORK
Ofelia Control Framework actúa por lo que ya podemos intuir del capítulo anterior (dejando
a un lado la gestión de usuario e integración con XEN para proveer máquinas virtuales)
como un hypervisor/proxy que intermedia organizando los recursos en red de OFELIA,
utilizando Flowvisor que vimos en el análisis teórico. Interesados en la virtualización de los
recursos de la red y como conforma una rebanada virtual del hardware, analizamos esta
particularidad en Ofelia y es que, utilizan el puerto por defecto 6633 para conectarse con
los switches de forma transparente al usuario (no debe ser tenido en cuenta esto para quien
experimenta en la red). Esto es utilizado para hacer slicing del tráfico y redirigir a nuestro
controlador el subconjunto del tráfico que corresponde atendiendo a la solicitud de
flowspace aprobada (se solicitan previamente hasta que se aprueban para
experimentación).
Laboratorio 4: Escenario real a gran escala, con instanciación de flujos híbrida
 Plano de datos: Topología grafo cerrado definida en OFELIA con OF switches.

 Plano de control: híbrido (instanciación reactiva y proactiva)
 Controlador: Floodlight 0.85
 Aplicaciones: OFELIA Control Framework, curl para enviar entradas REST API, y el
componente web de Floodlight para monitorizar e interpretar la topología.

 Objetivo: Trabajar con topologías reales, instanciación híbrida en un escenario de

gran escala, manejando un flowspace asignado con un subconjunto de los recursos
y experimentando con el concepto de slicing. Repetimos el ejemplo del laboratorio
3 añadiendo a una red con comportamiento reactivo static flows, ejemplo con regla
para tráfico IPv6 sin soporte completo de OF 1.0.
El siguiente experimento es semejante al laboratorio tres bajo una perspectiva híbrida

veremos cómo instalar reglas de flujo estáticas en una red con un comportamiento de switch
que actúa de forma reactiva, con el valor añadido en la experimentación de que se realiza
sobre un flowspace de un slice de la infraestructura Ofelia. Afianzando los conceptos de
granularidad gruesa y fina para definir la red, ya que en este escenario real definiremos en
un subconjunto de los recursos reales que posee la red de experimentación. Comprendiendo
las posibilidades de granularidad del tráfico sumado a la división virtual de los recursos.
Definiendo nuestra red por software teniendo un comportamiento por defecto y reglas
estáticas con prioridad. Veremos a continuación como hacemos uso de OFELIA Control
Framework para definir la red por software y la coherencia de su funcionamiento con lo que
obtenemos del experimento.
En este trabajo no pretendemos realizar un tutorial de uso de panel de control de Ofelia, por
lo que obviaremos los pasos previos de registro, solicitud de acceso y configuración de
OpenVPN para acceder la isla de paso. Esta información de bienvenida está disponible en la
documentación oficial del proyecto. [93]
Con este laboratorio realista a gran escala pretendemos aproximar con un escenario SDN
la respuesta a los desafíos que planteábamos en la sección 2.1 con ejemplos.
 Infraestructura multi-arrendatario  Ejemplo Ofelia
 Movilidad de las máquinas virtuales  Flowpace  actualizar static flows.
 Extender las redes virtuales  Agregados e Intra-Federación.
 Tamaño de tablas de encaminamiento  Tuplas avanzadas L2 – L4 y granularidad,
tiempo de expiración de reglas incorporadas en los switches.
 Desacoplamiento lógica y física  Desacoplamiento plano de control y datos.
 Comunicación entre virtual y no -virtual  Posibilidades OpenFlow HW y SW.
 Transición Ipv6  Herramienta para la extensión de la red a nivel underlay y
compatible para escenarios Overlay con Ipv6 (ejemplo Internet Of things)
Para analizar y experimentar con más notoriedad la instanciación de flujos reactiva

ejecutaremos el controlador en una isla externa (fuera del flowspace) concretamente en la
máquina virtual que hemos llamado lynx (1024 MB de RAM asignados) sobre el servidor
VMS1 en TUB (Berlín) a través de la Overlay de control. Este elemento tiene el control de la
red desde fuera e interconecta “pods” del centro de datos de i2cat, creando dos máquinas
virtuales en equipos anfitrión diferentes de i2cat (Rodoreda, y Verdaguer) llamadas Ikki y
Shun.

Ilustración 40: Topología con los recursos agregados al slice (llamado Slice0) de experimentación con los agregados
de Barcelona i2Cat OpenFlow Infraestructure e i2Cat servers y de Berlin TUB OF AM y TUB Servers. Señalamos
donde está ubicado la vm con el controlador. Señalado el equipo anfitrión donde se aloja en controlador
Desde el panel de acceso de nuestra isla Ofelia podemos acceder a todos los recursos
federados en la red para incorporarlos a nuestro proyecto, pudiendo crear distintas slices
con los recursos de los agregados, ya sean máquinas virtuales o recursos de red. Para esta
experimentación partimos de que tenemos creada una slice y en ella hemos agregado los
recursos de i2Cat (Barcelona) y TUB (Berlín).
Independientemente de tener o no asignado espacio de flujo para nuestro controlador,
tenemos acceso a las VMs que añadamos en las redes participantes a través de la interfaz de
red eth0 conectada a la red de control (Overlay de control) definida para todas las máquinas
cuando se crean y que NO se debe modificar para seguir vinculada a la red Ofelia (esta red
no se representa en el diagrama de topología). Esta interfaz es por la que se configura el
controlador y es el único para todos los agregados (de cualquier isla) en la slice.
OFELIA utiliza la subdivisión por VLAN aplicada para aislar las porciones de los usuarios.
Es un campo que se añade a la solicitud del flowspace, se indica en la solicitud expresamente
en base a las cabeceras soportadas en OpenFlow para nuestro flowspace o por el contrario
si hacemos una petición simple se añade una petición de identificador VLAN disponible para
la solicitud realizada que se nos reporta cuando se concede vía email. Esta técnica añade
seguridad y aislamiento para usuarios aunque tiene limitaciones al número de VLAN ID
disponibles, lo que puede ser un límite o una mala decisión para escenarios gigantes.
En el marco de trabajo y mantenimiento de Ofelia existe una autoridad que controla la
autorización y la asignación de este identificador VLAN, OFELIA Assigned Number Authority
(OANA). Aunque teóricamente puede ser solicitado dentro del rango (0-4095) existen

rangos reservados con fines de gestión que no se pueden solicitar, control o futuros que
están adecuadamente documentadas [90]. Esta asignación corresponde con lo visto en la
sección 2.31 con el concepto de coarse flows o flujos gruesos.
En nuestro ejercicio de laboratorio controlaremos un subconjunto de red OpenFlow en la
isla i2Cat correspondiente a un flowspace elegido expresamente VLAN ID 20.
Ilustración 41: Flowspace solicitando expresamente VLAN id 20 y aprobado (en azul), abajo el controlador
asignado para TODOS los agregados a este slice. Correspondiente a una máquina fuera de la isla de i2Cat agregada
al mismo slice.
Hemos instalado Floodlight como hemos visto en los laboratorios con Mininet sin
diferencias, con la función de forwarding por defecto. OFC enviará el tráfico de
experimentación para nuestro flowspace, recordamos que tendrá acceso a un subconjunto
de los recursos solicitados en una vista unificada para nuestras aplicaciones, como vemos
en la ilustración 42.
Ilustración 42: Escenario Floodlight Controller como SDN Controller.

Ilustración 43: Arriba red completa en la isla I2Cat y abajo subconjunto asignado, con dos VMs arrancadas y
detectadas por el controlador porque utilizan 802.1q en una de sus interfaces para que ese tráfico sea gestionado
por el controlador.
El servicio de descubrimiento de enlace es responsable de descubrir y mantener el estado

de los enlaces en la red OpenFlow, por defecto Floodlight lo incorpora (módulo
net.floodlightcontroller.linkdiscovery.internal.LinkDiscoveryManager ) y podemos utilizar su
servicio web en la URL http://10.216.X.X:8080/ui/index.html para obtener un grafo visual
de la topografía que descubre. También podemos utilizar la REST API para consultarlo con
el comando siguiente: curl -s http://localhost:8080/wm/topology/links/json
Para completar el mismo ejemplo que para el laboratorio tres introducimos una regla de
ejemplo reactiva para descartar el tráfico Ipv6 y revisamos que el controlador la acepta.

curl -d ‘{”switch”:”00:10:00:00:00:00:00:05”,”name”:”drop_ipv6”,
“cookie”:ingress-port”:”2”,”ether-type”:”34525”,”active”:”true”,
“priority”:”32768”,”actions”:””}’
http://10.216.16.42:8080/wm/staticflowentrypusher/json
Ilustración 44: Instalamos las entradas en el switch, “static flow push” drop_ipv6
Tras introducir este la entrada de flujo estática, el resultado es el mismo que en ejemplo del
laboratorio 3, impidiendo tráfico de las pruebas ipv6 link local a la máquina Shun conectada
al switch al que aplicamos la regla.
Ilustración 45: Captura de los recursos que tenemos asignados y que reconoce el controlador, abajo los flows activos
para el switch con ID 00:10:00:00:00:00:00:05 /10.216.12.4:41437.
3.3. ANÁLISIS DE LA EXPERIMENTACIÓN CON SDN Y OPENFLOW

En la sección anterior hemos afianzado el análisis teórico, con los ejemplos prácticos de los
laboratorios. De modo que sirva como reflexión y estímulo para abordar situaciones en el
crecimiento de SDN. Complementando a la idea de que el modelo que se plantea es válido
para escenarios reales, que ofrece versatilidad para definir la red mediante software, y todo

ello de una forma centralizada. Hemos aportado información sobre las herramientas de
experimentación local y despliegue físico.
De la experimentación con SDN y OpenFlow en los escenarios con Mininet y Ofelia,
señalamos aquellos.
 Abstracción, innovación
Un fundamental valor de SDN es la abstracción, desde nuestro punto de vista abre las
puertas a la innovación. Acostumbrados a manejar en el plano de red numerosos
protocolos, con su complejidad y de nuevas especificaciones para mejorar funcionalidades;
este modo, aproxima al acceso a la red de forma unificada. Esto beneficia a la innovación
con el desarrollo de escenarios Overlay y aplicaciones que no tengan que “preocuparse” por
lo que ocurre en el nivel de abajo y al sector industrial que colaborará por “modernizar” la
red con su equipamiento y las nuevas tecnologías de transmisión.
 Solución no específica de fabricante
Para innovar es importante poder recrear de forma sencilla escenarios similares a los que
nos encontraremos en un despliegue real. Actualmente tenemos esta posibilidad con
Mininet y la perspectiva de modificar ligeramente la electrónica de red para el soporte de la
especificación OpenFlow nos permite tener despliegues con hardware de diferente
fabricante como los que tenemos en las diferentes islas de Ofelia (NEC, HP, NetFPGA).
SDN pretende construir una disciplina que no sea específica de fabricantes, hemos
simulado por software Mininet una topología para experimentar con redes definidas por
software. Nos permite definir la topología que deseemos abstrayéndonos de los problemas
reales de interconexión, ídem a lo que obtenemos desde el panel de control de Ofelia aunque
ajustándonos a los recursos físicos que se implantan.
Al “cerebro” de la red (semejanza para referirnos al controlador OpenFlow), le resulta
indiferente la implementación que tenga el switch (ya sea software, hardware, fabricante)
siempre y cuando implemente la especificación OpenFlow soportada. De este modo hemos
comprobado el mismo controlador, componentes, herramientas y comportamiento de
entradas antes de ponerlas en producción, con los mismos resultados sin realizar cambios.
La experimentación local y real difiere principalmente en las latencias que afectan a la
comunicación real en el escenario OFELIA (que analizamos a continuación). La emulación
de los equipos de la red (host y switches) como procesos del sistema en Mininet consigue
una reproducción fiel para el escenario, pero no tenemos el aislamiento del sistema de
ficheros de las “VMs”, tampoco de carga de la red, etc. Ya que todo está en la misma máquina,
pero hace sencillas las tareas de experimentación con un coste computacional bajo. El
controlador interpreta los switches fielmente como equipos que implementan OpenFlow
software (nos ocurrirá para las implementaciones software que veremos cómo fabricante
del switch es Nicira Networks) totalmente transparente como se experimenta con OFELIA.

 Programación de flujos
Conceptos propios de programación son aplicable al modelo SDN: Abstracción, modularidad

y simplicidad: La red es programable y de forma centralizada.
Hemos querido que el lector interpretase con el primer laboratorio, un ejemplo sencillo
(para que fuera más atractivo pero existen ejemplos disponibles para POX más complejos)
de como en unas pocas líneas en lenguaje interpretado python pueden dar funcionalidad a
una topología utilizando el paradigma de red definida por software, siendo totalmente
operativa tanto en laboratorio como en infraestructura real.
La utilización de un “motor” más o menos eficiente en nuestro sistema, optimizados para un
determinado tráfico y eficientes, dependerá para la finalidad que destinemos la red o según
el control que hagamos sobre ella. El tratamiento de entradas está en la decisión del
Ingeniero de tráfico de la red definida por software. La potencia de este modelo se reduce a
la expresión matching  action en este elemento programado, y la implementación de un
mecanismo estándar de comunicación con este controlador añade modularidad a la
infraestructura. Hemos visto con Floodlight el mecanismo para hilvanar este controlador
con las aplicaciones y proyectos orientados al modelo Infraestructura como Servicio (IaaS).
Hablamos de la REST API que utilizamos para comunicamos de una forma estándar con el
controlador y desde este único punto gobernar toda una red. Hemos visto como
aplicaciones utilizan estos mecanismos para abstraer a un nivel de aplicación este control.
Esta interfaz de actuación con el controlador requiere de mecanismos de seguridad en la
sesión, para evitar modificaciones en las entradas de flujo no autorizadas. En el caso de
Ofelia requiere de credenciales para el acceso a la red de control que permiten al
administrador enviar estas reglas por la red y que sean aceptadas por nuestro controlador,
no hemos tenido en cuenta esto en la experimentación con Mininet es un requisito proteger
el acceso al control.
 Optimización
La granularidad y la posibilidad de tuplas avanzadas L2-L4 que hemos repetido a lo largo

del documento, abre todo un abanico de posibilidades que cuanto más se acoplen a los
servicios de la red Overlay mayor grado de eficiencia y seguridad tendremos aunque puede
que requieran más rendimiento para matching de las mismas en memoria.
El “inconveniente” que hemos experimentado trasladando el control de la red a una isla
externa utilizando instanciación de flujos reactivas e intercambiando tráfico entre
máquinas que están próximas (en saltos de red) es el que tarda la comunicación en
resolverse. Para una entrada para la cual no hay definido un comportamiento, el switch
consulta al controlador que le envía la correspondiente push flow entry, indicando por
donde es alcanzable su extremo o que interrogue por todos los puertos por ejemplo, según
el comportamiento que tenga definido. Estas entradas se cargan en el switch con un tiempo
de expiración según la especificación y no se vuelven a consultar sino expiran. Esta

operación tiene un impacto inicial dependiente de la latencia entre el switch y el

controlador. Esta latencia inicial puede ser asumible pero debe tenerse en cuenta en el
diseño (de hecho puede ser similar a latencias que sufrimos en el modelo tradicional IP).
Aplicaciones en tiempo real o comunicaciones sensibles extremo a extremo como las
conversaciones de voz, son sensibles a la variabilidad de las latencias del canal y el efecto
jitter. El tiempo de expiración de las entradas, sirve de auto-mantenimiento según la
capacidad de las tablas de entrada de los switches y aventajan al tráfico más habitual en un
comportamiento reactivo.
Ilustración 46: Prueba ICMP (primeros quince paquetes) entre dos máquinas virtuales “shun” e “ikki” en la misma
isla (Barcelona), en azul a través del controlador remoto (lynx.vms1.Berlin) que se encaminan de forma reactiva.
En naranja vemos el tiempo de respuesta a través de las interfaces de control de Ofelia (eth0). Aparecen dos
ejemplos con el mismo experimento realizado en días diferentes y hora del día para contemplar diferencias
según carga de trabajo de la red compartida.

Si queremos optimizar la eficiencia del canal llegaremos a un compromiso entre flexibilidad

y eficiencia con la instanciación de flujo proactiva (también de acuerdo a las
prestaciones del switch), bien para descartar tráfico o para evitar consultas al controlador.
Para mejorar la eficiencia del canal (optimizando las consultas al controlador) debemos
dotar con información proactiva al plano de datos, indicando que las dos máquinas
están conectadas dentro de la misma isla con las reglas convenientes, examinando la
topología. La ventaja de llevarnos el control de la red donde más convenga por otro lado,
extiende las posibilidades, disponibilidad, movilidad, etc. De forma transparente al usuario
de aplicaciones en la cima de la pila OpenFlow, o más aún el cliente consumidor de la red en
última instancia que desconoce de la virtualización de la red.
Hemos comprobado que con la herramienta Iperf que el orden de transferencia entre los
nodos en i2Cat y TUB es ~ 30Mb/s. Coincide aproximadamente con la descripción inicial
que hacíamos de la infraestructura para las islas que no están directamente conectadas a la
red GEANT proporcionada por la documentación de Ofelia. Hemos comprobado esto antes
de hacer las pruebas de la Ilustración 46.
 Direccionamiento
Los problemas de direccionamiento son ahora menos, desvinculándonos de IP para el

control, En los ejemplos hemos utilizado direcciones Ipv6 link local para una red que a nivel
de enlace puede extenderse por varias islas de Ofelia, pudiendo utilizar IP, o direcciones
MAC para establecer reglas (cabeceras IPv6 en versiones superiores a la 1.2). En el
laboratorio 2 hemos utilizado reglas basadas en puertos de entrada donde está encaminado
para establecer el flow. Estos espacios de flujos que tanto hemos mencionado permiten
definir Overlay Networks diseñadas según un propósito específico, dando oportunidad para
interconectar nuevos espacios.
 Balanceo de carga y tolerancia a fallos
Una importante observación es que el uso de switches basado en OpenFlow concretamente

permite definir redes libres de bucles ayudando a reducir el desperdicio del ancho de banda,
debido principalmente a la utilización eficaz de todos los enlaces disponibles, podríamos
llamarlo balanceo de flujos. Existen propuestas de utilización de OpenFlow para
maximizar el rendimiento de la red en combinación con MTCP (Multi Pathing TCP protocol)
[101] y manejando topologías con bucles con Floodlight [103].
Una cuestión que no se ha planteado ha sido la tolerancia a fallos del controlador,
podemos utilizar un mecanismo tipo heartbeat mejorado como el que hemos implementado
en python a nivel de aplicación para controlar el funcionamiento de la red y detectar la
perdida de actividad del controlador y tratar de relanzarlo o conectar otro, pero puede
suponer una interrupción del servicio (mecanismos de control “artesanales”). Actualmente
no podemos establecer otros controladores en “sombra” por si falla el principal de nuestra
slice desde el panel de control de Ofelia. Tampoco parece que Floodlight lo soporte de
momento según su documentación.

Ilustración 47: Balanceo de flujos de datos, camino path-1 y path-2. [103]
 Administración y monitorización
La abstracción virtual de la red permite que el tráfico entre sus componentes pueda ser
analizado con las herramientas de monitorización convencionales y nuevas que surgen
para hacer análisis en términos de flows [96]. Las comunicaciones no se resuelven dentro
del Hypervisor 80x86 como ocurría antes sino que están enlazadas al slice y/o flowspace
conectado. El acceso mediante mecanismos estándares, API para desarrollo o conexión de
aplicaciones como hemos visto con el uso de REST, amplia la potencia de poder leer datos,
definir las acciones para cada entrada de flujo, definir estáticamente comportamientos para
replicar, analizar, balancear, reconducir o aislar el tráfico rápidamente de forma
centralizada mediante la definición de flujos ídem mecanismos que implementan los
switches que conocemos.
Ilustración 48: Capturas de tráfico IPv6 con el analizador de red wireshark, los mecanismos de sobre un despliegue
con MININET conectada a un controlador POX.

 Seguridad
En Ofelia hemos visto el mecanismo de aislamiento de para que cada usuario utilice su
flowspace. Esta medida por identificador VLAN (que puede ser por otro campo de la túpla
OpenFlow soportado) puede no ser adecuada si se usa un proveedor de servicios con
muchos clientes pero es perfectamente válida para discriminar el tráfico dirigido a nuestro
controlador en este entorno con menos usuarios (límite 12 bits ID VLAN). Hemos visto con
el ejemplo de los laboratorios 3 y 4 como establecer reglas proactivas para descartar tráfico
IPv6. Utilizar estos mecanismos proactivos en equipos frontera en redes Overlay con
propósitos muy específicos puede además de optimizar los caminos que toman los flujos,
granular solo aquel tráfico que deseamos semejante al comportamiento de un firewall.
4. CONCLUSIONES Y VÍAS FUTURAS:

SDN como modelo conceptual y OpenFlow concretamente por la implementación que
permite llevar a cabo esta concepto, tendrán éxito en un proceso de “migración” hacia un
Internet del futuro. Aprovechando en principio posibilidades de la electrónica de red con
ligeras modificaciones para OpenFlow, hasta que fabricantes optimicen su hardware para
esto, y con el desarrollo de proyectos software para que fabricantes puedan desplegarlo
como si de un sistema operativo para red se tratase (NOS Network Operating System),
véase Indigo por ejemplo [60]. Parece solo el comienzo para una transición suave a mejorar
la tecnología actual y a la innovación. Es importantísimo el interés que los primeros
experimentos en Stanford despertaron en la industria del networking, esto refleja que
efectivamente había una brecha de cara afrontar los desafíos futuros con un modelo
limitado. Este equipamiento SDN tiene un coste económico más elevado que el
equipamiento IP, el esfuerzo del ETSI (European Telecommunications Standards Institute)
actualmente está en la estandarización de las funciones de virtualización de la red o NFV
[85][102] que suponga una modernización menos costosa a proveedores de red.
Aquí no hemos analizado la eficiencia de los componentes ni controladores que ya se realiza
en otros artículos [48] [91] [103]. El nivel de abstracción que esta solución consigue no
supone una capa más de interpretación con la consecuente latencia añadida en el plano de
datos, sino evolución integrada en el mismo plano. La dualidad del equipamiento híbrido
permite utilizar los equipos con redes convencionales al mismo tiempo que desplegar
entornos OpenFlow para nuevos despliegues y mantener compatibilidad. Las mejoras
hardware que optimicen la función de comprobación de entradas en memoria o en rápidas
bases de datos como maneja Open vSwitch [19] en software, son mejoras en ambos aspectos
relevantes de cara a la trayectoria de su implantación.
Actualizaciones para hacer compatible con OpenFlow hardware tradicional red y las
mejoras de rendimiento que surjan para aumentar las prestaciones de la función de flow

matching ya sea software o hardware ayudará a una mayor eficiencia en resolver entradas
de flujo más avanzadas con menor coste.
Añadiendo este nivel de abstracción podremos aproximar lo que parecía utópico para la
experimentación hace unos años de representar escenarios para innovación tan reales
como Internet, ejemplos de estos son GENI, OFELIA u OPENLAB a nivel educacional, pero a
nivel privado Google ha presentado planes estratégicos ligados a SDN [57], y NEC ha llegado
a acuerdos en Japón para desplegar OpenFlow en hospitales con bastante éxito [85].
Documentación y APIs homogéneas añaden disciplina al desarrollo, potencian el
desarrollo de herramientas y aplicaciones para la Ingeniería del tráfico; que permitan
aportar consciencia, atendiendo a valores de uso, costes, contenido, patrones, etc.
Homogeneizar los mecanismos de comunicación con el nivel overlay y con las tecnologías
underlay permitirá flexibilizar el avance de este modelo de red definido por software hacía
el internet del futuro. Esto no quiere decir que desaparezca el perfil del administrador de
redes que conocemos hoy día, evoluciona en un avance en la gestión centralizada y al
perfeccionamiento del plano de datos. Esta abstracción es la antesala a una renovación de
las tecnologías subyacentes a alta velocidad ya sean inalámbricas, cableadas por cobre o
medios ópticos.
El encaminamiento no acoplado a IP no tiene por qué ser agnóstico al contenido, la
versatilidad que ofrece un mecanismo basado en flujos, permite añadir consciencia de las
aplicaciones y moldear desde el control según requerimientos de las mismas o
características específicas de los protocolos a nivel superior de forma anticipada.
Permitiéndonos establecer la lógica de control que nos convenga, ya sea con motivos de
ahorre de costes, tratamiento del tráfico, etc. Interconectando puertos virtualmente como
en el laboratorio 2, ligado a una dirección MAC origen, o aislamiento VLAN.
Aventajándonos de la eficiencia del nivel de enlace y utilizar el enrutamiento como lo
conocemos realmente los equipos frontera.
El hecho de tener redes virtuales con un subconjunto de recursos que hacen más
aprovechable el hardware subyacente, tiene impactos directos en consumos energéticos
en flexibilidad y dinamización de los centros de datos, los grandes proveedores de
servicios tendrán que ser los primeros en adoptar este tipo de soluciones en el modelo
multi- arrendatario que emerge. Aunque este no es el único escenario, los problemas
energéticos y trabajos de encaminamiento reactivo, proactivos, geográfico, etc. Son desafíos
comunes en de redes ad-hoc con y sin infraestructura.
Redes multimedia, redes de sensores, encaminamiento ad-hoc o experimentos con nuevos
protocolos que podemos interconectar con cualquier cosa con energía y conectable. El
internet del futuro está estrechamente ligado al concepto de Internet of Things o el internet
de las cosas.
El Internet del Futuro según nuestro criterio pasa por establecer nexos con el modelo
tradicional IP que conduzcan a un modelo que reorganice y armonice este gran sistema
que ha cambiado los hábitos de comportamiento de las personas, quizás en previsión del
siguiente salto debemos anticiparnos al futuro partiendo de que estamos en el que el que

podemos decir la etapa del Internet en las personas, en auge y lo próximo será ligarlo a
cualquier cosa que pueda aportar información a un sistema ya sea de forma activa o pasiva.
Este avance en el ideal de “todo conectado y de la misma forma” simplificará el acceso
a la red y mitigará las diferencias para interactuar en ella. El concepto introducido por SDN
y OpenFlow concretamente, siendo el pegamento de transición tangible a la innovación y el
ensayo en este campo. Si todos estamos conectados, importa quién o que está conectado,
mecanismos o modelos basados en identidad [6] para el control de acceso según la persona
o cosa que participe en la red gana interés. Entre la información sujeta a una persona o cosa
puede estar su identificación en la red (que podría ser una dirección IPv6) ligada a un perfil
de persona o cosa conectada; por esto, una simplificación de los mecanismos, periféricos,
integración con el usuario y las cosas en de acceso a la red (desafiante en el ámbito de la
seguridad) son a nuestro parecer objeto de interés ligado a este concepto en un
planteamiento de la futura internet.
Ilustración 49: Internet of Things, evolución de los dispositivos conectados a internet realizada por Intel ®.

5. REFERENCIAS
1. Ben Pfaff, Justin Pettit, Teemu Koponen, Keith Amidon, Martin Casado from Nicira
Networks and Scott Shenker from UC Berkeley. Computer Science Division.
Extending Networking into the Virtualization Layer. 2009
2. Rezo Davoli, Department of Computer Science Unversity of Bologna,(Italy) VDE:
Virtual distributed Ethernet. Technical Report Jun 2004.
3. Justin Pettit, Jesse Gross, Ben Pfaff, Martin Casado, Nicira Networks, Palo Alto. CA.
Simon Crosby rom Citrix Systems, Ft.Lauderdale. Virtual Switching in an Era of
Advanced Edges. 2nd Workshop on Data Center–Converged and Virtual Ethernet
Switching (DC-CAVES), ITC. 2010.
4. Shpetimi Latifis, Pardue University. Ing. USBMed. An Analysis on the future of
Internet Architectures. ISSN: 2027-5846 Vol2, No1, Ene-Jun 2011.
5. Matthew Chapman Caesar. Identity-based routing. Electrical Engineering and
Computer Sciences University of California at Berkeley Technical Report No.
UCB/EECS-2007-114.
6. José Bastida García. Integración de Redes: “Modelos basados en Identidad”. Trabajo
Asignatura MNTI. Universidad de Murcia. Febrero 2011.
7. José Bastida García. Herramientas de Virtualización de Sistemas y Redes Ethernet.
Trabajo asignatura Tecnología para la Investigación en la Ingeniería Informática,
Universidad de Murcia. Septiembre 2011.
8. VMWare ™ Distributed Switch: http://www.vmware.com/products/vnetwork-
distributed-switch/overview.html
9. Martìn Casado, Michael J. Freedman, Justin Pettit, Jianying Luo, and Nick McKeown
Stanford University. Scott Shenker U.C. Berkeley and ICSI. Ethane: Taking Control of
the Enterprise. ACM SIGCOMM Computer Communication Review. Vol. 37. No. 4.
ACM, 2007
10. Antonio F. Gomez-Skarmeta1, Pedro Martinez-Julia1, Joao Girao2, Amardeo Sarma.
Identity based Architecture for Secure Communication in Future Internet.
Communication and Information Engineering, University of Murcia (Spain),
EU2NEC Laboratories Europe,Heidelberg (Germany). Proceedings of the 6th ACM
workshop on Digital identity management. ACM, 2010. p. 45-48.
11. Renzo Davoli, Michael Goldweber .Virtual Square Users, Programmers & Developers
Guide. Department of Computer Science Unversity of Bologna, (Italy).
12. Hui-Min Tseng, Hui-Lan Lee, Jen-Wei Hu, Te-Lung Liu, Jee-Gong Chang, Wei-Cheng
Huang. National Center for High-Performance Computing, Taiwan. 1521-9097/11
IEEE 2011.
13. Virtualization architecture using the ID/Locator split concept for Future Wireless
Networks. Chakchai So-In, Raj Jain , Subharthi Paul, Jianli. Department of Computer
Science & Engineering, Washington University in St. Louis. Department of Computer
Science, Faculty of Science, Khon Kaen University (Thailand).Sept. 2010.
14. The Locator Identifier Separation Protocol (LISP). David Meyer, Cisco Systems. The
Internet Protocol Journal, Volume 11.
15. VirtualSquare project wiki.< http://wiki.virtualsquare.org>
16. A Study of a KVM-based Cluster for Grid Computing. Michael Fenn, Michael A.
Murphy, and Sebastien Goasguen School of Computing Clemson University, Clemson
(US).

17. VMWare ™ Distributed Switch: <http://www.vmware.com/products/vnetwork-

distributed-switch/overview.html>
18. Oracle Virtual Box Community :
<http://www.oracle.com/technetwork/community/developer-vm/index.html>
19. Open vSwitch, An Open Virtual Switch: <http://openvswitch.org/>
20. Brent Salisbury . TCAMs and OpenFlow – What Every SDN Practitioner Must Know.
<www.sdncentral.com> Jul. 01, 2012.
21. Borden, T.L.,Hennessy, J.P., Rymarczyk, J.W. IBM Systems Journal. Multiple operating
systems on one processor complex. IBM Systems Journal Volume: 28, Issue: 1. 1989.
22. JPerf: http://sourceforge.net/projects/jperf/
23. Wireshark: http://www.wireshark.org/
24. KVM: http://www.linux-kvm.org/page/Main_Page
25. David González Aragón, Tutor: Miquel Martín Mateo, Director: Toni Oller Arcas.
Infraestructuras como servicio en arquitecturas de nubes privadas. Trabajo fin de
Master. Universidad Oberta de Cataluña. Junio 2013.
26. On the Design of Virtual Machine Sandboxes for Distributed Computing in Wide-
area Overlays of Virtual Workstations . David Isaac Wolinsky , Abhishek Agrawal, P.
Oscar Boykin, Justin R. Davis, Arijit Ganguly, Vladimir Paramygin, Y. Peter Sheng,
Renato J. Figueiredo. Advanced Computing and Information Systems, University of
Florida, Civil and Coastal Engineering, University of Florida (US).
27. Cisco Nexus 1000 v series:
<http://www.cisco.com/en/US/products/ps9902/prod_white_papers_list.html>
28. Virt-IO: <http://wiki.libvirt.org/page/Virtio>
29. What’s New in VMware vSphere™ 5.0 Networking . VmWare ™. Technical Marketing
Documentation v.1.0 April 2011.
30. Towards Virtual Networks for Virtual Machine Grid Computing. Ananth I.
Sundararaj Peter A. Dinda. Department of Computer Science, Northwestern
University (US).
31. Virtual Distributed Environments in a Shared Infrastructure. Paul Ruth, Xuxian
Jiang, Dongyan Xu, Sebastien Goasguen, Purdue University (US). . IEEE Computer
may 2005.
32. UMview: View-OS implemented as a System Call Virtual Machine. Renzo Davoli
University of Bologna, Michael Goldweber Xavier University, Ludovico Gardenghi
University of Bologna(Italy).
33. Distributed virtual scenarios over multi-host Linux environments. Fernandez, D.;
Cordero, A.; Somavilla, J.; Rodriguez, J.; Corchero, A.; Tarrafeta, L.; Galan, F.;
Dept. de Ing. de Sist. Telematicos, Universidad Politécnica de Madrid,(Spain)
34. VNUML: http://neweb.dit.upm.es/vnumlwiki/index.php/Ediv_tunnel_cluster
35. VIOLIN: Virtual Internetworking on Overlay Infrastructure. Xuxian Jiang, Dongyan
Xu. Purdue University. 2003.
36. VNET: PlanetLab Virtualized Network Access, Mark Huang, Princeton University.
June 2005.
37. From virtualized resources to virtual computing grids: the In-VIGO system.
Sumalatha Adabala, Vineet Chadha, Puneet Chawla, Renato Figueiredo, José Fortes∗,
Ivan Krsul, Andrea Matsunaga, Mauricio Tsugawa, Jian Zhang, Ming Zhao, Liping
Zhu, Xiaomin Zhu Advanced Computing and Information Systems (ACIS)
Laboratory, University of Florida,
38. Resilient overlay networks. David G. Andersen. Massachusetts Institute of
Technology.2001.

39. LibVirt: http://libvirt.org/

40. Intel® Virtualization Technology for Directed I/O. Architecture Specification.
Revision: 1.3 Order Number: D51397-005
41. IOMMU Architectural Specification Advanced Micro Devices, Inc. AMD I/O
Virtualization Technology (IOMMU) Specification License Agreement.
42. Jack Lo Sr. Director, R&D. VMware and CPU Virtualization Technology PAC346.
Copyright © 2005 VMware, Inc. VMWorld 2005.
43. Gerald J. Popek University of California, Los Angeles and Robert P. Goldberg
Honeywell Information Systems and Harvard University. Formal Requirements for
Virtualizable Third Generation Architectures
44. Norbert Niebert, Stephan Baucke, Ibtissam El-Khayat, Martin Johnsson, Börje
Ohlman, Henrik Abramowicz, Klaus Wuenstel, Hagen Woesner, Jürgen Quittek, Luis
M. Correia Ericsson Research, Corporate Unit, Ericsson GmbH, Ericsson Allee 1, D-
52134 Herzogenrath, Germany. Ericsson Research, Corporate Unit, Ericsson AB, 164
80 Stockholm, Sweden. Alcatel-Lucent, Bell Labs, Lorenzstr.10, D-70435 Stuttgart,
Germany. Telecommunication Networks Group (TKN), TU Berlin, Einsteinufer 25,
D-10587 Berlin, Germany. NEC Laboratories Europe, Kurfürsten-Anlage 36, D-
69115, Heidelberg, Germany .IST/IT – Technical University of Lisbon, Av. Rovisco
Pais, P-1049-001 Lisbon, Portugal. “The Way 4WARD to the Creation of a Future
Internet”. 2008
45. Kohei Shiomoto, Ichiro Inoue, Tomonori Takeda, Shinichiro Chaki, Takeshi Akaike,
and Haruhisa Hasegawa “Toward a New Paradigm for Packet Service”. NTT Network
Service Systems Laboratories Musashino-shi, 180-8585 Japan
46. T.Narten,Ed. IBM, M.Sridharan Microsoft, D.Dutt Cisco, D.Black EMC, L. Kreeger
Cisco. Problem Statement: Overlays for Network Virtualization. IETF Draft October
31, 2011.
47. Scott Shenker with Martin Casado, Teemu Koponen, Nick McKeown. The Future of
networking and the past of the protocols. SDN Abastractions June 2011.
http://www.slideshare.net/martin_casado/sdn-abstractions
48. Romero De Tejada Muntaner, Guillermo. Evaluation of OpenFlow Controllers.
Octubre 2012. Tesis Doctoral. KTH.
49. Bob Lantz Network Innovations Lab DOCOMO USA Labs Palo Alto, CA, USA, Brandon
Heller Dept. of Computer Science and Nick McKeown Dept. of Electrical Engineering
and Computer Science, Stanford University Stanford, CA, USA. A Network in a
Laptop: Rapid Prototyping for Software-Defined Networks. Hotnets ’10, October
20–21, 2010.
50. Rob Sherwood. Keynote talk at NANOG 53 Philadelphia, October, 2011. OpenFlow:
What is it and Where is it going?
51. Antônio Abelém1, Iara Machado2, José Augusto Suruagy Monteiro3, Luiz Cláudio
Schara Magalhães4, Michael Stanton2, 5 e Tereza Cristina M.B. Carvalho6
1Universidade Federal do Pará (UFPA) 2Rede Nacional de Ensino e Pesquisa
(RNP)3Universidade Salvador (Unifacs) 4Universidade Federal Fluminense (UFF)
5on secondment from Universidade Federal Fluminense (UFF) 6Universidade de
São Paulo (USP). Advances in developing a Future Internet testbed in Brazil
52. Massimo RIMONDINI. Computer Networks Research Group. Roma Tre University
(Italy). Tecnologie per la Virtualizzazione delle Reti di Calcolatori. October 2010.
53. Hui-Min Tseng ,Hui-Lan Lee , Jen-Wei Hu , Te-Lung Liu , Jee-Gong Chang , Wei-Cheng
Huang, Nat. Center for High-Performance Comput., Hsinchu, Taiwan. Network

Virtualization with Cloud Virtual Switch. 2011 IEEE 17th International Conference
on Parallel and Distributed Systems.
54. ONF.Open Networking Fundation. <https://www.opennetworking.org/>
55. J.Touch and R.Perlmann, “Transparent Interconnection of Lots of Links (TRILL):
Problem and applicability statement,” RFC 5556. May 2009.
56. Nick McKeown, Stanford University. Tom Anderson, University of Washington, Hari
Balakrishnan MIT, Guru Parulkar Stanford University, Larry Peterson Princeton
University , Jennifer Rexford Princeton University, Scott Shenker University of
California, Berkeley, Jonathan Turner Washington University in St. Louis. OpenFlow:
Enabling Innovation in Campus Networks, March 14, 2008
57. Urs Hözle, Google. A Software Defined WAN Architecture. 17 April 2012,
Opennetworksummit, Santa Clara. Silicon Valley.
58. Seetharaman, Paul Weissmann Deutsche Telekom Innovation Laboratories,
OpenFlow Tutorial OFELIA Summer School Nov 8, 2011Srini.
59. Bob Lantz, Nikhil Handigol, Brandon Heller y Vimal Jeyakumar. Introduction to
Mininet Documentation (updated for Mininet 2.0.0).
<https://github.com/mininet/mininet/wiki/Introduction-to-Mininet#>
60. Project Floodlight. Open Source Software for Building Software-Defined Networks.
©2013 Project Floodlight. All rights reserved.
< http://www.projectfloodlight.org/floodlight>
61. Jad Naous, David Erickson, G. Adam Covington, Guido Appenzeller, Nick McKeown.
Stanford University California, USA. Implementing an OpenFlow Switch on the
NetFPGA platform. En Proceedings of the 4th ACM/IEEE Symposium on
Architectures for Networking and Communications Systems. ACM, 2008. p. 1-9.
62. Cisco Nexus 1000V Switch for VMware vSphere, Virtual Machine Networking:
Standards and Solutions:
<http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9902/white
paper_c11-620065.html>
63. Rajesh Narayanan, Technology Strategist Office of the CTO, Dell Networking.
”Towards an Extensibility Framework and a Creating a New Application Innovation
Framework for Software Defined Networking”. European Workshop on Software
Defined Networking October 25-26, 2012 | Darmstadt, Germany.
64. VXLAN VMWare Software Defined Networking. Datacenter Networking Challenge:
<http://www.vmware.com/es/solutions/datacenter/vxlan.html>
65. Global Research Network Operation Center and INCNTRE. FlowVisor Overview
presentation. <https://OpenFlow.stanford.edu/display/DOCS/Flowvisor>
66. GÉANT website. Communications Networks, Content and Technology European
Commission Directorate General. < http://www.geant.net/>
67. B. Davie, Ed. J. Gross Nicira Networks, Inc. A Stateless Transport Tunneling Protocol
for Network Virtualization (STT). IETF Draft March 5, 2012.
68. Francesco Palmieri, Federico II University of Napoli, Italy. The Internet Protocol
Journal, Volume 11, No. 3 GMPLS Control Plane Services in the Next-Generation
Optical Internet.
69. Ramón Jesús Millán Tejedor. Integración de redes ópticas e IP con GMPLS.
Comunicaciones World nº 172, IDG Communications S.A, 2002.
70. Roberto Doriguzzi, Matteo Gerola. CREATE-NET collaboration with FP7-Ofelia:
Advanced Network Virtualisation Layer for OpenFlow Networks: VeRTIGO.
<https://github.com/fp7-ofelia/VeRTIGO#readme>

71. Nicola Ciulli. Coexistence of GMPLS and OpenFlow rationale & approaches, Head of
Research & Development, Nextworks with acknowledgments to the FP7 FIBRE
project. Pre-FIA Workshop May 7th 2013, Dublin.
72. OpenFlow Switch Specication Version 1.0.0 ( Wire Protocol 0x01 )December 31,
2009. <http://www.OpenFlow.org/documents/OpenFlow-spec-v1.0.0.pdf>
73. Murphy McCauley and Ali Al-Shabibi, Components in POX: POX Wiki, Stanford
University. <https://OpenFlow.stanford.edu/display/ONL/POX+Wiki>
74. Kuang-Ching Wang, Floodlight Documentation.
<http://docs.projectfloodlight.org/display/floodlightcontroller/Floodlight+Docu
mentation>
75. Ethan Banks, propietario, Packet Pushers Interactive, Network World (EE.UU.) –
CIOPeru.pe. SDN: Las partes fundamentals. ComputerWorld Venezuela.
76. Caesar, M. , Caldwell, D. , Feamster, N., Rexford, J., Shaikh, A., and Van Der Merwe, K.
Design and implementation of a Routing Control Platform. In Proc. NSDI (april
2005).
77. Greenberg, A., Hjalmtysson, G., Maltz, D. A., Myers, A., Rexford, J., Xie, G., Yan, H., Zhan,
J., and Zhang, H. A clean slate 4D approach to network control and management.
SIGCOMM CCR 35, 5 (2005), 41–54
78. Casado, M., Garfinkel, T., Akella, A., Freedman, M. J.,Boneh, D., Mckeown, N., and
Shenker, S. Sane: A Protection architecture for enterprise networks. In proc. Usenix
Security (august 2006).
79. Gude,N., Koponen, T., Pettit, J., Pfaff, B., Casado, M, Mckeown, N., and Shenker, s. NOX:
Towards an operating system for networks. In SIGCOMM CCR (july 2008).
80. OpenDayLight , Linux Fundation Collaborative Project.
81. Nick McKeown. OpenFlow and Software Defined Networks presentation. 2011
82. Hui-Min Tseng, Nat. Center for High-Performance Comput., Hsinchu, Taiwan Hui-
Lan Lee ; Jen-Wei Hu ; Te-Lung Liu ; Jee-Gong Chang ; Wei-Cheng Huang Hui-Min
Tseng. Network Virtualization with Cloud Virtual Switch. Parallel and Distributed
Systems (ICPADS), 2011 IEEE 17th International Conference.
83. Brandon Heller, SDN Stanford Team. OpenFlow Tutorial ONS presentation. April
2012.
84. Martin Casado, List of OpenFlow Software Projects (that I know of).
<http://yuba.stanford.edu/~casado/of-sw.html>
85. SDNCentral, The Independent Community & #1 Resource For Sdn And Nfv
Copyright 2012-2013 SDNCentral LLC, All Rights Reserved.
<http://www.sdncentral.com/comprehensive-list-of-open-source-sdn-projects/ >
86. sFlow Monitoring converged networks using the sFlow® standard
<http://blog.sflow.com/2013/05/controlling-large-flows-with-OpenFlow.html>
87. Ivan Shmakov How to use vlan dot1.q 802.1q, trunk. Wiki Debian Network
Configuration. < https://wiki.debian.org/NetworkConfiguration >.
88. Murphy McCauley. POX Web Interfaces. September 2012.
< http://www.noxrepo.org/2012/09/pox-web-interfaces/>
89. Jason Parraga, Ryan Flaherty. Marist – IBM OpenFlow Research project. Avior.
< http://OpenFlow.marist.edu/avior>
90. Matteo Gerola, CREATE-NET. Vasileios Kotronis , ETHZ, Leonardo Bergesio, i2CAT,
Bart Puype , IBBT, Marc Körner, Herbert Almus TUB, Julius Schulz-Zander, TUB-T-
Labs, Nikolaos Efstathiou UnivBRIS. OFELIA – OpenFlow in Europe – Linking
Infrastructure and Applications. OFELIA ICT-258365 Deliverable D4.2. © OFELIA
consortium 2010-2013.

91. Marcelo Pinheiro. OpenFlow Controllers Presentation.2011

92. Mark Handley UCL. Not your father’s Internet. Or, where did the Internet
architecture go?. And what can we do about it. Change-summerschool-2011
presentation.
93. OFELIA OpenFlow in Europe Linking Infrastructure and Applications.
<http://www.fp7-ofelia.eu/>
94. OFELIA documentation wiki.
<https://alpha.fp7-ofelia.eu/doc/index.php/Main_Page>
95. FIBRE, OFELIA Control Monitoring Framework.
< http://www.fibre-ict.eu/index.php/cmf/ofelia>
96. Cbench NEW, (controller benchmarker).
<http://www.OpenFlowhub.org/display/floodlightcontroller/Cbench+(New)>
97. Ramón Jesús Millán Tejedor. Integración de redes ópticas e IP con GMPLS. Publicado
en Comunicaciones World nº 172, IDG Communications S.A, 2002
<http://www.ramonmillan.com/tutoriales/gmpls.php>
98. SNAC, Nicira Policy Manager v0.4.0 documentation.
<http://archive.OpenFlow.org/downloads/snac_documentation.pdf>
99. Openstack. <http://www.openstack.org/software/openstack-networking/>
100. ZMap: Fast Internet-Wide Scanning and its Security Applications.
< https://zmap.io/paper.pdf>
101. Van der Pol, R., Boele, S., Dijkstra, F., Barczyk, A., van Malenstein, G., Chen, J. H., &
Mambretti, J. (2012, November). Multipathing with MPTCP and OpenFlow. In High
Performance Computing, Networking, Storage and Analysis (SCC), 2012 SC
Companion: (pp. 1617-1624). IEEE.
102. SDN/NFV Primer 6WIND © 2013: solving the critical performance challenges for
software-defined networks.
<http://www.6wind.com/software-defined-networking/sdn-nfv-primer>
103. Govindraj, S., Jayaraman, A., Khanna, N., & Prakash, K. R.. Project directed by
Professor Dirk Grunwald. OpenFlow: Load Balancing in enterprise networks using
Floodlight Controller. Telecommunications at the University of Colorado, Boulder,
May 4, 2012.
104. Turull, Daniel, Markus Hidell, and Peter Sjodin. "libNetVirt: the network
virtualization library." Communications (ICC), 2012 IEEE International Conference
on. IEEE, 2012.
105. ICT STATISTICS Home Page, © International Telecommunication Union
< http://www.itu.int/en/ITU-D/Statistics/Pages/default.aspx>

APÉNDICE:
A.1. ENCAMINAMIENTO VIRTUALIZADO ASISTENCIA DE LA RED
La introducción de NAT obliga a renunciar al paradigma extremo a extremo, por ello para
establecer un vínculo extremo a extremo con el objetivo de interconectar grandes entornos
corporativos o gubernamentales de forma segura, puede que dispongamos de circuitos
dedicados o servicios macrolan propios o proporcionados por los proveedores de servicios.
Un escenario común para examinar esta casuística es que, sobre estos enlaces converjan
numerosos servicios y utilicemos VLANs para gestionar de forma separada las redes,
pudiendo ocurrir que la electrónica de red intermedia no soporte etiquetas VLAN extremo
a extremo. Utilizar 802.1Q es un mecanismo para establecer de forma segura dominios
virtuales, aunque tiene limitación en la trama Ethernet de 12bits o 4096 VLANs.
IPv6 resolvería estos problemas ya que podríamos alcanzar con direcciones IPv6 públicas
extremo a extremo, en cualquier caso si establecemos un canal para la interconexión de
sedes debemos aplicar mecanismos de seguridad y cifrado como IPSec .
Veamos las principales tecnologías underlay de las que disponemos para ampliar una red
de área extensa, necesario a nivel subyacente para extender el plano de datos. La flexibilidad
con un bajo coste en inversión y un impacto mínimo son las premisas para una transición
menos disruptiva con las características de un diseño. Destacamos la necesidad de una
interfaz que simplifique la integración con los mecanismos de conexión underlay, LibNetVirt
es un importante avance en este campo que ya contempla Openflow.
 VPN (VIRTUAL PRIVATE NETWORK)
La conexión VPN a través de Internet es técnicamente una unión wide area network
(WAN) a nivel IP entre los sitios, al usuario le parece como si fuera un enlace privado—
de allí la designación “virtual private network”.
Existen diferentes topologías y protocolos para conformar esta red privada virtual muy
documentados y extendidos a día de hoy como PPTP, L2TP,IPSEC o SSL/TLS.
 OPENVPN (VIRTUAL PRIVATE NETWORK)
Este mecanismo valiéndose de interfaces virtuales, es puramente software a través de

un controlador TUN/TAP. Este controlador, funciona como un dispositivo Punto a
Punto o Ethernet el cual en vez de recibir paquetes a través de un medio físico, lo hace
a través del espacio de usuario y en vez de enviarlos por un medio físico los escribe en
el espacio de usuario. Permite mediante software establecer un túnel extremo a

extremo en espacio de usuario sobre el que conectarse a la red destino, lo cual lo hace
muy versátil para clientes VPN y configuraciones de acceso remoto a sedes.
Ilustración 50: Acceso a la red Ofelia configurado en un cliente OpenVPN para Android, accediento al panel de
control de Ofelia desde un dispositivo móvil.
 GRE ENCAPSULATION TUNNELING
Genereric Routing Encapsulation (GRE) es un protocolo originalmente desarrollado por

Cisco Systems que se ha convertido en un estándar de la industria definido en las RFC
1701, 1702 y 2784. Es un protocolo de túnel, es decir, que permite transportar
paquetes de una red a través de otra red diferente.
El establecimiento de túneles GRE consiste en establecer un túnel para encaminar entre

redes distintas, con la particularidad que sobre este protocolo se pueden encapsular
otros protocolos de nivel 2 y 3 . Este mecanismo de enlace más transparente para el
tráfico de red añade una ligera sobrecarga, pero por su capacidad multiprotocolo
permite experimentar o explotar protocolos (por ejemplo OpenFlow). Se adopta
generalmente sobre un canal seguro IPSec (GRE over IPSEC), (ver intra-federación
en Ofelia [90]), por su funcionalidad, seguridad y desempeño ha sido escogido como
herramienta para grandes despliegues como VPN punto a punto, gana interés para el
modelo distribuido de virtualización de la red y base para el tráfico de red definido por
software.
 STT (STATELESS TRANSPORT TUNNEL)
Alternativas como STT (Stateless Transport Tunnel) [67], otro protocolo de túnel para
crear redes superpuestas virtuales es particularmente útil cuando el hardware de los

dispositivos de red finales utiliza las capacidades mejoradas en hardware para

virtualización de la red, para mejorar el rendimiento que mencionábamos en la sección
anterior 3.3.2 para acceso directamente a la interfaz virtual o VIF.
 MPLS (MULTI PROPOSAL VPN)
MPLS es un estándar IP de conmutación de paquetes del IETF, que trata de

proporcionar algunas de las características de las redes orientadas a conexión a las
redes no orientadas a conexión.
En el encaminamiento IP sin conexión tradicional, la dirección de destino junto a otros

parámetros de la cabecera, es examinada cada vez que el paquete atraviesa un router;
lo cual supone que cada router pierda cierto tiempo dependiente del tamaño de su tabla
de encaminamiento y, además, como la ruta no puede predecirse, es difícil reservar
recursos que garanticen la calidad de servicio. Básicamente, MPLS combina las ventajas
del encaminamiento inteligente de nivel 3 con la rápida conmutación de nivel 2,
utilizando para ello la conmutación de paquetes por una pequeña etiqueta de longitud
fija; consiguiendo, de este modo, un mayor rendimiento en el transporte de paquetes
IP. Dicha etiqueta es asignada al paquete basándose en su dirección de destino, los
parámetros de tipo de servicio, la pertenencia a una red privada virtual, o siguiendo
otro criterio. Los dispositivos que incorporan el software de control MPLS, ya sean
routers o switches de la red troncal IP, se denominan LSR (Label Switching Routers).
MPLS nació con el fin de incorporar la velocidad de conmutación del nivel 2 al nivel 3;
a través de la conmutación por etiqueta (LSP o label switched path) sin necesidad de
IP; pero actualmente esta ventaja no es percibida como el principal beneficio, ya que
los gigarouters son capaces de realizar búsquedas de rutas en las tablas IP a suficiente
velocidad como para soportar todo tipo de interfaces.
Los beneficios que MPLS proporciona a las redes IP son: realizar ingeniería del tráfico
o TE (Traffic Engineering), cursar tráfico con diferentes calidades de clases de servicio
o CoS (Class of Service) o grados de calidad de servicio o QoS (Quality of Service), y
crear redes privadas virtuales o VPN (Virtual Private Networks) basadas en IP.
La migración a IP está provocando profundos cambios en el sector de las

telecomunicaciones y como hemos comentado en otros apartados la configuración es
uno de los retos más importantes para los ISP, inmersos actualmente en un proceso de
transformación de sus infraestructuras de cara a incorporar los beneficios de esta
tecnología.

 GMPLS (MULTI PROPOSAL VPN)
MPLS como una solución IP sobre Ethernet, IP sobre ATM, e IP sobre Frame Relay. No
se contempla la aplicación de MPLS a las redes ópticas de próxima generación, conocida
como GMPLS (Generalized MPLS), evolución del MPLS del IETF, de O-UNI (Optical
User-Network Interface) y del OIF (Optical Interface Forum), muy importante en la
nueva generación de enlace óptico para el plano de datos.
GMPLS es una extensión natural de MPLS para ampliar el uso de MPLS como un
mecanismo de control y provisión, no únicamente de caminos en dispositivos basados
en paquetes, sino también de caminos en dispositivos no basados en paquetes; como
los conmutadores ópticos de señales multiplexadas por división en longitud de onda,
los conmutadores de fibras ópticas, y los conmutadores de señales digitales
multiplexadas por división en el tiempo.
Entre sus principales ventajas destaca su múltiple aceptación en los estándares de

industria con interfaces (UNI, I-NNI, E-NNI) [97] que interoperan con fabricantes
distintos y está diseñado para conexiones cruzadas (cross-connect) con diferentes
tecnologías T-Eth, SDH/SONET, WDM/WSON, etc.
o GMPLS Y OPENFLOW:
El enfoque de GMPLS en el plano de control de estas diversas capas ya que cada una
de ellos puede utilizar físicamente diversos datos o planos de reenvío. La intención es
cubrir tanto la señalización y la parte de enrutamiento de ese plano de control. Por la
naturaleza de las transmisiones en medios ópticos se ha introducido la posibilidad de
que múltiples enlaces puedan ser combinados en un único enlace agrupado (link
bundling) y de establecer enlaces no numerados, definiendo un nuevo protocolo de
señalización denominado LMP (Link Management Protocol).
LMP puede separar los canales de datos y de control permitiendo que cada uno de ellos
pueda ser protegido y contabilizado de forma independiente. De este modo, LMP ayuda
a la localización de enlaces con fallos y a la verificación de la conectividad física entre
dos nodos vecinos, lo cual reduce la probabilidad de error en la provisión de servicios.
Una vez localizado el fallo, el LMP activará los mecanismos de protección y
restauración, activando otros LSP alternativos con el fin de solventar el problema.
Un planteamiento lógico podría ser el de abstracción del control basado en redes

definidas por software y aprovechar las ventajas de las tecnologías ópticas, eficiencia,
control precisión y robustez en el nivel subyacente, es decir OpenFlow over GMPLS
aunque hay autores que no lo planten así. La compatibilidad y coexistencia de estas

tecnologías se analiza de cara a escenarios donde puedan implementarse ambas [71].

Sin duda esta tecnología gana interés en la modernización del medio físico de Internet.
En el cuadro comparativo de la siguiente figura analizamos algunas de las

características de este planteamiento que tiene cierta similitud con el modelo
SDN/OpenFlow: Separación de los planos de control y datos, y ofrecer interfaces
abiertas para el control de los servicios de red.
OpenFlow: GMPLS/PCE:
Objetivo: Redes de Paquetes: Objetivo: Redes de transporte:
 No orientadas a la  Orientadas a la conexión

conexión (circuitos)
 Originalmente para  Originalmente para
centros de datos proveedores de servicios
corporativos  Enlaces troncales (Semi-
 Flows dinámicos estáticos o de larga vida)
 Monolítico, algunos  Estándares cross-connect
equipamientos tecnología  Sistemas programables
específica. con GMPLS/PCE como
 Plano de control y datos se plano de control y datos
controlan mezclados. independiente.
Ilustración 51: Concepto de separación de planos control/datos diferenciado principalmente según el área de
aplicación.
 LIBNETVIRT
Esta arquitectura permite que la gestión sea independientes de las tecnologías

subyacentes. Ofrecer las conexiones como las mencionadas en el nivel underlay,
proporcionando una interfaz única del nivel subyacente con controladores específicos
es lo que define LibNetVirt [105]. Similar al proyecto LibVirt [39] para la virtualizción
de sistemas, esta librearía provee al nivel superior de la plataforma un conjunto de
llamadas para instanciar redes virtuales proporcionando una abstracción homogénea
de la red.
Ilustración 52: Arquitectura LibNetVirt [105]

A.2. SOFTWARE-BASED VIRTUAL SWITCHES
En el marco de la virtualización distribuida a nivel de enlace surgen otros proyectos muy

interesantes aplicados a la experimentación y a la industria, hemos centrado el trabajo en
OpenFlow por tratarse de un nexo con el modelo de red definida por software que se adapta
a nuestro modo de manejar la transición a un futuro internet. No obstante estas
herramientas participarán en este cambio en el sector de la experimentación y la industria.
 VDE, VIRTUAL DISTRIBUTED ETHERNET
VDE es un proyecto de la Universidad de Bolonia que se define a sí mismo como la

navaja suiza para la virtualización de redes. Permite emular software en espacio de
usuario (utilizando View-OS) sobre GNU Linux con las capacidades de un switch de
nivel 2[15], como su propio nombre indica permite su funcionamiento de forma
distribuida como si de una red Ethernet física unida se tratase. Destaca la capacidad de
virtualización parcial de procesos completos, ofreciendo conectividad a varios tipos
de componentes software: emuladores, máquinas virtuales, sistemas reales de
aplicaciones y de conectividad [7]. Los entornos de virtualiazación basados en Linux
generalmente utilizan la implementación bridge o el código de VDE.
Virtual Distributed Ethernet puede ser utilizado de forma general como red privada
virtual a través de una red a través de Internet, así como una tecnología de apoyo a la
movilidad, una herramienta genérica para extender laboratorios en red,
reconfigurable, superpuesta a la capa de aplicación para crear VLANs con preservación
de la privacidad y otros alternativas [2]. El principal inconveniente según algunos
experimentos son interrupciones con algoritmos de control de la congestión del tráfico
ssh [52].
Ilustración 53: Extendiendo VDE: interconexión de switches mediante canal cifrado ssh.

 CISCO NEXUS V1000
Cisco Nexus® 1000V es el software switch con el que Cisco Systems enriquece el
hypervisor más potente de VMWare [61] provee una comprensiva y extensible
arquitectura para las máquinas virtuales y para el “cloud networking” [53]. Los switches
están diseñados para acelerar la virtualización y los despliegues múltiple arrendatario
mejorando la administración y de los recursos de forma transparente. Se integra con
VMWare vSphere hypervisor para la gestión de la red y es compatible con VMWare
vCloud Director para manejar centros de datos virtualizados con todo el equipamiento
de sistemas, almacenamiento red y seguridad con habilidades de control de servicios
de transporte hasta aplicación.
El producto que está dentro de la estrategia Cisco Open Network Environment (ONE),
supone una solución integral para ayudar a que las redes sean más abiertas,
programable y consciente de las aplicaciones. Modelo operativo sin interrupciones
para la virtualización de servidores y equipos de red de este fabricante en la tendencia
de creación de redes definida por software (SDN).
Como indicamos en las mejoras hardware que complementan a este tipo de switches
se encuentra el soporte en hardware basado en el estándar IEEE 802.1Q en
compromiso con un sistema operativo propietario especializado Cisco NX-OS. El tráfico
que pasa por estos switches se puede gestionar y analizar como el resto de la red
superando así esto que no ocurría con los hypervisor switch básicos.
Con la introducción de VXLAN en el Nexus 1000V, el aislamiento de la red entre las

máquinas virtuales se puede ampliar más allá de VLANs tradicionales para la creación
de redes a escala en la nube.
 MICROSOFT HYPER-V EXTENDIBLE SWITCH
Microsoft Extensible Hyper-V 3.0 switch [46] es un conmutador Ethernet virtual

software que se ejecuta en el sistema operativo que gestiona Hyper-V. A partir de
Windows Server 2012, el administrador de redes virtuales de Hyper-V se puede utilizar
para crear, configurar o eliminar switches de deferentes tipos, ya sean externos
internos o privados. La principal diferencia con el modelo de Cisco es que Microsoft
hizo lo correcto a nuestro criterio creando una arquitectura extensible vSwitch y
documentó a fondo todas las API (hay suficiente documentación para poner en práctica
su propio extendible switch compatible según fabricantes). Un reflejo de esta ventaja es
que en pocos meses de la disponibilidad de Hyper-V 3.0 extendible switch al menos dos
conmutadores virtuales (Cisco Nexus 1000V y PF1000 de NEC también software)
estaban disponibles para Hyper-V.

 OPEN VSWITCH
Open vSwitch es un switch software multicapa con licencia open source Apache 2.
Además de que está incluido en los módulos del kernel Linux 2.6.18 en adelante, tiene
soporte especial para Citrix XenServer y Red Hat Enterprise Linux hosts. Además de
implementar una plataforma virtual testada para entornos en producción que soporta
los estándares de gestión y administración de red está abierto su desarrollo a nuevas
extensiones para reenvío y control.
Ídem a las soluciones de Cisco-VMware y Microsoft, Open vSwitch tiene características

para al administrador de redes de un switch virtual en entornos virtualizados,
integrándose con los dispositivos hardware-based que hemos mencionado en el
apartado anterior para el acceso directo a las interfaces virtuales [3]. Permitiendo
establecer un nexo entre las soluciones de virtualización y la red física así como
extendiendo la red de forma distribuida, soportando múltiples tecnologías de
virtualización basadas en Linux incluidas Xen/XenServer,KVM y VirtualBox.
Ilustración 54: Arquitectura Open vSwitch.
Destacamos las principales características, suficientes para el total desempeño y

despliegue de la red virtualizada distribuida por software.
 Estándar 802.1Q VLAN permitiendo puertos modo access y modo trunk

 “Bonding” de interfaces con y sin LACP Link Aggregation Control
 NetFlow, sFlow®, y port mirroring para incrementar la visabilidad.
 QoS (Quality of Service) y políticas avanzadas.
 GRE, GRE sobre IPSEC, VXLAN, y LISP tunneling
 802.1ag gestión de fallos de conectividad
 OpenFlow 1.0 y soporte para extensiones extras.
 Base de datos transaccional eficiente usando C y Python
 Alto rendimiento en el reenvió de paquetes a nivel de Kernel de Linux.
Destacamos la inclusión OpenFlow lo cual gana interés en despliegues híbridos con

dispositivos OpenFlow hardware. Existe hardware disponible de fabricantes como

Broadcom que está apoyando a la universidad de Stanford a elaborar su implementación

hardware con OpenFlow y fabricantes que preparan switches disponibles con esta
tecnologías como HP o NEC (utilizados en la red Ofelia) entre otros.
 OPENFLOW SWITCH
OpenFlow switch se ejecuta es la implementación de referencia OpenFlow con una

pila mínima OpenFlow que registra las especificaciones y se ejecuta en espacio de
usuario user-space a diferencia de Open vSwitch que es Kernel-based.
Este referente se ejecuta en lo que hemos denominado cuando separábamos las

funciones de reenvió en hardware en el slow-path, por ejecutarse en el espacio de
usuario no estamos esperando alta eficiencia ni rendimiento. Esta distribución de
referencia se provee para entornos sencillos, experimentación o con fines didácticos
incluye un sencillo OpenFlow Controller de referencia que conecta con el OpenFlow
switch por la interfaz de loopback para definir en la red comportamientos básicos de un
hub o switch.
A.3. OPENFLOW CONTROLLERS
 OPENFLOW REFERENCE CONTROLLER
La distribución de referencia de Stanford incluye un controlador que funciona en

espacio de usuario como un switch Ethernet que aprende las direcciones MAC de las
estaciones de la red conectadas para asociar a qué puerto enviar el tráfico en
combinación con el OpenFlow Switch de referencia. Tiene un carácter didáctico para
ver y aprender los mensajes que se envían, es sencilla y liviana para el sistema.
A través del comando dpctl por el puerto 6634 en la interfaz de loopback sobre la
misma máquina que se ejecuta el OpenFlow reference switch podemos establecer reglas
de flujos y depurar que ocurre en el switch obteniendo la información del controlador.
 NOX/POX
NOX forma parte de la historia de la arquitectura SDN [79]. Específicamente es una

plataforma para construir aplicaciones de control de la red. La primera tecnología SDN
como hemos mencionado en numerosas ocasiones en este trabajo es OpenFlow y NOX
fue el primer OpenFlow Controller desarrollado por Nicira en lenguaje C++, aunque se
donó a la comunidad investigadora en 2008 siendo base de otros proyectos en este
ámbito.

POX es el controlador SDN desarrollado en leguaje python a partir de NOX orientado a

la educación e investigación. Además de crecer para ser un marco de interacción con
switches OpenFlow, es usado para explorar, prototipos con la virtualización de redes.
Siendo un buen compromiso entre agilidad para experimentar y prestaciones.
 SNAC
SNAC (Simple Network Access Control) es un controlador OpenFlow programado en C++

basado en NOX, aporta un gestor de políticas basado en web para gestionar los nodos
OpenFlow. Diseñado para reducir la complejidad en la gestión del controlador
aportando además información interpretada visualmente en una interfaz web de los
elementos que gobierna, rendimiento (flows por segundo) ,errores detectados, etc.
En alguna documentación se considera un controlador con propósito especial

recomendado para entornos en producción aunque aún es una versión beta [98],
destacamos algunas de sus características:
o Monitorización y gestión web: Web-Based Policy Manager

o Sistema de restauración de la red a un estado anterior (snapshots de red)
o Permite configurar portales captivos para nuevos clientes (captive portals).
La figura 19 representa las ventajas de la gestión centralizada de toda la red. Resume

en una interfaz la simplicidad como principal mejora que hemos mencionado en los
primeros capítulos del modelo definido por software en la administración de una red
completa a un nivel más elevado.
Actualmente SNAC con documentación escasa, no es un proyecto maduro como tantos

otros en esta materia, las empresas que lo respaldan parece que están apostando más
fuertemente por Floodlight.
Ilustración 55: Interfaz web de SNAC OpenFlow Policy Manager, sección donde podemos crear o seleccionar
instantáneas de la red en un punto concreto, como tenemos en la virtualización de sistemas: concepto snapshot.
Captura realizada en instalación realizada en la infraestructura Ofelia.

 RYU
Del término flujo (flow) en japonés, se trata de un Framework SDN, una plataforma para
crear aplicaciones SDN proporcionando librerías útiles y un API (Aplication
Programming Interface) bien definida (ver figura 7), completamente desarrollado en
lenguaje Python bajo licencia de código abierto Apache v2 apoyado por la compañía de
telecomunicaciones global NTT.
Entre las principales características y objetivos que persigue este proyecto y lo hacen
destacable señalamos:
o Objetivo de convertirse en un network controller estándar de facto para

plataformas SDN en distribuciones Linux (Fedora, RedHat, Ubuntu) y
sistemas que proveen infraestructura como servicio (IaaS) para el modelo
de cloud computing como el proyecto Openstack [99].
o Genérico y ágil, independiente del vendedor con soporte específico para
fabricantes de alta calidad y que soporte al mismo tiempo protocolos
abiertos como OpenFlow. Pretendiendo ser el gran controlador multi-
propósito.
o Un marco de desarrollo de aplicaciones como RYU aporta un valor añadido
al desarrollo de servicios de red a nivel de aplicación, servicios de red
convergentes sobre su API SDN. Integración con herramientas de
seguridad, aprovisionamiento, recuperación de desastres, etc.
Ilustración 56: Arquitectura RYU “Implement your apps by using Ryu SDN Framework”

 FLOODLIGHT
Se trata de un controlador OpenFlow desarrollado en Java y multiplataforma,

distribuido bajo licencia Apache Open Source aunque ha gozado el respaldo por
ingenieros de Big Switch Networks. Este proyecto surge de la bifurcación de otro
proyecto en el mismo lenguaje llamado Beacon desarrollado en Standford, basado en
eventos y operaciones con hilos que lo hace eficiente en arquitecturas multi CPU.
FloodLight aporta también una SDN API y cuenta ya con una amplia lista de
fabricantes hardware de swithes compatibles que lo amparan, también es compatible
con Openstack, concretamente para actuar entre los dispositivos de red como
proveedor de recursos de red network as a service.
Floodlight (que significa reflectante en castellano) cuenta con bastante respaldo

industrial y han surgido en torno a estas herramientas interesantes. Entre sus ventajas
destaca la implantación de una API REST (representational state transfer) para
intercambiar datos e instrucciones de manera similar a los servidores HTTP, usando
métodos familiares como GET y POST. Las APIs proporcionan una forma para que
aplicaciones externas al controlador le digan a éste que debería pasar en la red.
a) Lanzamos el controlador en Segundo plano y comprobamos que está listo
mininet@mininet-vm:~$ java –jar target/floodlight &
15:13:10.561 INFO [n.f.c.i.Controller:main] Listening for switch connections on

0.0.0.0/0.0.0.0:6633
b) Modificamos flujos de entrada en los switches mediante la REST API:

comportamiento NORMAL switch L2 ver especificación OpenFlow 1.0.
mininet@mininet-vm:~$ curl -d ‘{”switch”: “00:00:00:00:00:00:00:01”,

“name”:”switch1_accion_normal”, “cookie”:”0”, “priority”:”0”, “active”:”true”,
“actions”:”output=normal”}’ http://127.0.0.1:8080/wm/staticflowentrypusher/json
{”status” : “Entry pushed”}
c) Modificamos flujos de entrada en los switches mediante la REST API:

Permitir el acceso a un servidor web
mininet@mininet-vm:~$ curl -d ‘{”switch”:

“00:00:00:00:00:00:00:01”,”name”:”allow_web_access”,”ingress-
port”:”19”,”cookie”:”0”,”dst-ip”:”x.x.x.x.x”,”dst-port”:”80”, “ether-type”:”2048”,
“protocol”:”6”, “priority”:”32768”, “active”:”true”, “actions”:”output=all”}’

d) Modificamos flujos de entrada en los switches mediante la REST API:

Denegar el acceso a un servidor web
mininet@mininet-vm:~$ curl -d ‘{”switch”:

“00:00:00:00:00:00:00:01”,”name”:”drop_web_access “name”:”drop-web-access-all”,
“ingress-port”:”19”, “cookie”:”0”, “dst-port”:”80”, “ether-type”:“2048”,
“protocol”:”6”, “active”:”true”, “priority”:”32768”, “actions”:””}’
e) Eliminamos todas las entradas de la tabla de flujos switch

(utilizamos el DPID para referirnos al switch concreto)
mininet@mininet-vm:~$ curl
http://127.0.0.1:8080/wm/staticflowentrypusher/clear/00:00:00:00:00:00:00:01/json
Ilustración 57: Ejemplos de otras entradas avanzadas probadas a través de la REST API con el controlador
Floodlight en modo proactivo. EN b) la acción NORMAL hace que se comporte como un switch L2 según la
especificación para esta acción en la documentación de OpenFlow 1.0. e) Indica como eliminar todas las entradas
creadas para un switch funcionado con la REST API.
A.4. SOFTWARE ÚTIL EN LOS LABORATORIOS
 Cliente de terminal
Hemos utilizado mtputty disponible en: http://ttyplus.com/multi-tabbed-putty/,

para Windows, es estable y permite el reenvío de X11 para cargar aplicaciones
gráficas, en nuestro caso han sido principalmente wireshark, AVIOR y gnuplot.
Principalmente ha sido útil para tener organizadas múltiples terminales a las vm de
experimentación, desde una misma herramientas permitiendo visualizar a la vez
varios equipos, sobre todo en un despliegue como Ofelia si queremos tener una
referencia de donde están ubicadas las máquinas añadiendo una descripción a la
conexión.
 Servidor de ventanas X
Hemos utilizado xming para Windows. Es una implementación portátil del sistema
de ventanas X para sistemas operativos Microsoft Windows basado en el servidor
xorg de UNIX.

 Hipervisor/Monitor de virtualización
VirtualBox [18] ha sido la herramienta escogida por ser gratuita principalmente

para el despliegue de máquinas virtuales de experimentación, algunos de los
proyectos mencionados en el proyecto como Mininet (cuya experimentación se ha
realizado completamente en una máquina virtual), Floodlight, Ryu y otros
proporcionan máquinas virtuales para experimentación, portables al formato de
Virtualbox.
Es necesario la configuración de reglas de reenvío de puertos (NAT) para redirigir
el tráfico al equipo anfitrión, para acceso ssh o pruebas acceso a los servicios web.
 Monitorización, escáner de la red y pruebas de rendimiento
o Iperf (tool for measuring maximum TCP and UDP bandwidth)

o NPtcp (NetPIPE - network protocol independent performance evaluator)
o Sflow , (monitoring network). Habilitar tráfico Sflow en el controlador
OpenFlow [86]
o Cbench (Controller Benchmarker) [96]
o Wireshark (protocol analyzing) con soporte OpenFlow. (preinstalado en la
plantilla de Ofelia y Mininet).
o Zmap (very fast network scanner)[100]
 Configuración 802.1Q en sistemas operativos GNU/Linux
o vlan package
o Configuración de la interfaz 802.1.q [87]
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 10.216.12.123
netmask 255.255.252.0
gateway 10.216.12.1
dns-nameservers 10.216.24.2 195.235.113.3
# Interfaz VLAN 802.1q
auto eth1
iface eth1 inet manual
auto vlan20

iface vlan20 inet static
address 192.168.20.123
netmask 255.255.0.0
vlan_raw_device eth1
#no configurada
auto eth2
Ilustración 58: Fichero /etc/network/interfaces configurado en máquina virtual ensayo Ofelia, llamada ikki.
 Programa python de comprobación heartbeat para hacer comprobaciones de flujos

entre nodos, consta de un proceso cliente y un proceso servidor preparado para la
conexión.
#!/usr/bin/python
import socket
host = '10.0.0.4'
port = 55000
backlog = 5
size = 1024
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.bind((host,port))
s.listen(backlog)
while (1):
client, address = s.accept()
data = client.recv(size)
if data:
client.send(data)
client.close()
Ilustración 59: Servidor realizado en python que acepta peticiones, ajustaremos ip y puerto manualmente antes de
ejecutarlo según el test.

#!/usr/bin/python
import socket
import time
ADMINISTRATOR = 'jbg3@um.es'
host = '10.0.0.4'
port = 55000
size = 1024
while (1):
try:
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((host,port))
s.send('Keeep Alive')
data = s.recv(size)
s.close()
print 'Received from ', host, ': ', data
time.sleep (5)
except:
print 'There has been some problem with the connection... Send an email(s)
to ', ADMINISTRATOR
time.sleep (5)
Ilustración 60: Cliente socket realizado en python que conecta con el de la ilustración 57, ajustaremos ip y puerto
manualmente antes de ejecutarlo según el ensayo.
* * * *

Redes Virtuales Distribuidas Basadas en Openflow, Hacia La Internet Del Futuro - Virtual Distributed Network Based On Openflow, Towards The Future Internet

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Redes Virtuales Distribuidas Basadas en Openflow, Hacia La Internet Del Futuro - Virtual Distributed Network Based On Openflow, Towards The Future Internet

Transféré par

Droits d'auteur :

Formats disponibles

UNIVERSIDAD DE MURCIA

Memoria del Trabajo Fin de Máster

Itinerario de Redes y Telemática:

Virtual Distributed Networks Based on OpenFlow,

Redes Virtuales Distribuidas Basadas en OpenFlow,

José Bastida García

D. Antonio Fernando Skarmeta Gómez

Murcia, 13 de Septiembre de 2013

Máster en Nuevas Tecnologías en Informática

Máster en Nuevas Tecnologías en Informática

1.1. VIRTUALIZACIÓN ............................................................................................................... 13

2.1. DESAFÍOS ......................................................................................................................... 25

3.1. MININET, SOFTWARE DE EXPERIMENTACIÓN LOCAL PARA SDN ................................................. 50

Máster en Nuevas Tecnologías en Informática

A.1. ENCAMINAMIENTO VIRTUALIZADO ASISTENCIA DE LA RED ........................................................ 88

Máster en Nuevas Tecnologías en Informática

Máster en Nuevas Tecnologías en Informática

ILUSTRACIÓN 43: ........................................................................................................................................ 72

Máster en Nuevas Tecnologías en Informática

Máster en Nuevas Tecnologías en Informática

Máster en Nuevas Tecnologías en Informática

Máster en Nuevas Tecnologías en Informática

Máster en Nuevas Tecnologías en Informática

Máster en Nuevas Tecnologías en Informática

Los sistemas mainframe tenían importante capacidad de computación y empezaron a

Ilustración 1: Ejemplo consola de login de CMS.

Máster en Nuevas Tecnologías en Informática

Máster en Nuevas Tecnologías en Informática

Máster en Nuevas Tecnologías en Informática

exponencial), ligado al aumento del número de usuarios y el incremento del número de

Ilustración 2: “Networking of information”. [44]

Internet es un tejido artificial de contenidos como hoy día lo conocemos y se ha convertido

1.2.1. CUESTIONES AL MODELO

Máster en Nuevas Tecnologías en Informática

Comenzando con la primera generación de IP asignadas en clases, de tipo A, B, C y el

La introducción de NAT obliga a renunciar al paradigma extremo a extremo de las

o La reasignación dinámica de direcciones no puede ser gestionada

El aumento de niveles de multihoming en Internet actualmente produce un

Máster en Nuevas Tecnologías en Informática

Ley de Moore. Incrementando el costo de routers para mantener la capacidad al día y la

Hay una amplia variedad de soluciones a este problema en la literatura, pero la

En general para los ISP se incrementa la necesidad de configurar reglas incluidos

Actualmente una dirección de red es utilizada tanto por los equipos de

1.2.2. EVOLUCIÓN DEL MODELO

Máster en Nuevas Tecnologías en Informática

limitados a mantener la persistencia de las conexiones extremo a extremo ante cambios en

 Empezar desde cero; Clean Slate

Aceptar la necesidad de un cambio profundo desde cero, nuevos paradigmas,

 Abstracción sobre la actual topología; Concepto Overlay Network

Ilustración 3: Modelo de Overlay Network [45]

Máster en Nuevas Tecnologías en Informática

 Crear un modelo de red a un nivel superior; Concepto Underlay

Sobre el que la que redes Overlay aisladas compitan. En el apartado siguiente se

Alternativa compatible a la vez con las anteriores para desarrollar nuevos

Ilustración 4: Modelo de virtualización completa de la red.

Máster en Nuevas Tecnologías en Informática

1.2.3. EXTENDER LA RED EN LA CAPA DE VIRTUALIZACIÓN: REDES DEFINIDAS POR

Máster en Nuevas Tecnologías en Informática

Máster en Nuevas Tecnologías en Informática

Apps Apps Apps Apps Apps

Apps Apps Apps Apps Capa de virtualización general o silicing

Sistema Operativo Sistema Operativo

HW reenvío simple HW reenvío simple