Controlador MūL

MūL, es un controlador Openflow (SDN) con un núcleo que tiene una infraestructura multi-hilo
desarrollado en C. Posee una interfaz north bound multinivel para conectar las aplicaciones.

Está diseñado para garantizar rendimiento y confiabilidad que es lo que se necesita desplegar en redes
críticas. Tiene soporte para varias versiones de Openflow.

Historia
MuL se deriva de la palabra sánscrita Mūla que significa “raíz” o “base”.

Su desarrollo se debe a que desde la aparición de OpenFlow y SDN, hubo necesidad de un controlador
de calidad con alto rendimiento y disponible abiertamente. Aunque existían buenos controladores en
el mundo opensource, ninguno parecía adaptarse a las necesidades de los desarrolladores de MuL.

El diseño de MuL está regido por:

1. Confiabilidad
2. Rendimiento
3. Capacidad de hospedar aplicaciones modularmente

El desarrollo del núcleo es en lenguaje C para garantizar el rendimiento pero al ser modular y soportar
aplicaciones como plugins permite que estas se desarrollen en otros lenguajes. Está bajo licencia
GPLv2. Existe una versión profesional disponible en BSD con un costo para aquellas organizaciones
que traten de construir una solución comercial.

El 9 de julio del 2014 fue liberada la versión 4.0.1 donde se resaltan las siguientes características [1]:

 Soporte para Openflow v1.4

 Soporte para (casi) todas las características de Openflow v1.3.
 Compatible con las versiones 1.0 y 1.3 de Openflow
 Soporte para la API REST
 Documentación mejorada
 Grande mejoras en las características de la CLI
 Gran cantidad de correcciones para la estabilidad y seguridad
 Soporte para superposiciones
 Soporte SSL (TLSv1.2)
 Enlace a las API mediante Python para scripting avanzado

Componentes
MuL está diseñado para permitir flexibilidad. Hacia el sur puede soportar múltiples APIs south-bound.
Mientras que hacia el norte, interactúa con las aplicaciones a través de una ML-API y REST NB-API. Las
aplicaciones que utilizan ML-API disponen de la opción de ser hospedadas en línea en el mismo espacio
de direcciones donde se ejecuta el proceso del núcleo MuL por tanto se ejecutan en el mismo contexto
y se obtiene el máximo rendimiento. Con los SDK que vienen con MuL, el desarrollador de la aplicación
o la propia aplicación como tal no necesitan saber cómo y dónde se está ejecutando.

El núcleo multi-hilo se optimiza usando una programación cache-aware para obtener el máximo
rendimiento especialmente de las CPUs Intel.
Mul también tiene un diseño altamente modular. Varios componentes tienen incorporada la
protección del espacio de direcciones y se pueden insertar eliminados o reiniciados dinámicamente
sin afectar a los demás.
Comparación con otros controladores SDN
Los análisis realizados por los desarrolladores de Open MuL con la herramienta CBENCH y publicados
el 22 de junio de 2014 en su sitio dieron los siguientes resultados:

En un artículo publicado en enero del 2013 [2] usando la herramienta HCPROBE se probaron los
siguientes controladores: NOX, POX, Beacon, Floodlight, MuL, Maestro y Ryu. También se habían
incluidos Trema, Flower y Nettle pero fueron descartados antes de terminar pues no estaban
preparados para la evaluación bajo una carga grande.

Las comparaciones se realizaron en

 Rendimiento/escalabilidad
 Confiabilidad
 Seguridad

Los resultados fueron los siguientes:

Rendimiento/escalabilidad

El rendimiento promedio alcanzado con diferentes hilos (con 32 switches y 105 host por switch)
El rendimiento promedio alcanzado con diferentes switches (con 8 hilos y 105 host por switch)

El rendimiento promedio alcanzado con diferentes cantidades de host (con 8 hilos y 32 switches)

En cuanto a la latencia el tiempo promedio de respuesta de los controladores demostró una

correlación insignificante con el número de host conectados. Con un switch conectado con 105 hosts
los resultados se muestran en la siguiente tabla, siendo la mínima latencia 10-6 segundos/flujo:

Controlador Latencia
NOX 91,531
POX 323,443
Floodlight 75,484
Beacon 57,205
MuL 50,082
Maestro 129,321
Ryu 200,021
La menor latencia correspondió a MuL.

En sentido general los mejores resultados fueron obtenidos por Beacon.

Confiabilidad
Los experimentos mostraron que MuL y Maestro comenzaron a desechar PacketIns luego de varios
minutos de trabajo, lo que indica que no está listo para el trabajo 24/7

Seguridad
Las pruebas realizadas fueron:

 Cabecera OpenFlow malformada

1. Longitud del mensaje incorrecta: MuL no se quebró. Maestro y NOX sí. Ryu fue el que
mejor manejó la situación que ignoró el mensaje sin cerrar la conexión.
2. Versión OpenFlow no válida: MuL cerró la conexión con el switch al igual que POX y
Ryu.
3. Tipo de mensaje OpenFlow incorrecto: MuL, al igual que Ryu, ignoro el mensaje.
Solicitó otro FeaturesRequest al switch y luego de recibir la respuesta cerro la
conexión.
 Mensaje OpenFlow malformado
4. Mensaje PacketIn: MuL cerró la conexión luego de recibir la respuesta a su solicitud
adicional de FeaturesRequest.
5. Mensaje Port status: MuL al igual que todos los controladores procesaron
correctamente este mensaje malformado.

Un resumen de estas pruebas se muestra en la siguiente tabla

Celdas rojas: Controlador se quebró

Celdas naranja: Controlador cerró la conexión
Celdas amarillas: Controlador procesó el mensaje sin quebrarse o cerrar la conexión pero el error no
fue detectado.
Celda verde: El controlador pasó correctamente la prueba

El comportamiento esperado para un controlador OpenFlow al recibir un mensaje malformado es que

lo ignore y lo quite de la cola de entrada sin afectar otros mensajes. Si lo procesa sin indicar un error
eso posiblemente cause un funcionamiento de la red incorrecto.
Comparación entre controladores libres
Característica Beacon Floodlight NOX POX Trema Ryu ODL MuL

Soporte OF v1.0 OF v1.0 OF v1.0 OF v1.0 OF v1.3 OF v1.0, OF v1.0 OF v1.0,

OpenFlow v1.2, v1.3 y v1.3 y la
ext. Nicira v1.4

Lenguaje donde Java Java C++ Python Ruby/C Python Java C

está desarrollado

Provee REST API No Si No No Si (Básica) Si (Básica) Si Si

Interfaz Gráfica Web Web Python+ Python+ No Web Web No

QT4 QT4, Web

Soporte de Linux, Mac Linux, Mac Linux Linux, Mac Linux Linux Linux, Linux
plataformas OS, OS y OS y Mac OS y
Windows Windows Windows Windows
y Android

Multiprocesos Si Si Si No Si No Si Si

Tiempo en el 4 años 2 años 6 años 1 año 2 años 1 año 5 meses 1.5 años
Mercado

Documentación Buena Buena Media Pobre Media Media Media Buena

Criterios para evaluar un controlador

Soporte OpenFlow: Al elegir un controlador OpenFlow se necesita entender la funcionalidad de

OpenFlow que el controlador soporta actualmente, como también la hoja de datos del proveedor para
implementar las nuevas versiones del protocolo OpenFlow, tales como la v1.3 y la v1.4.

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

Funcionalidad de la red: Con el fin de tener la mayor flexibilidad en términos de cómo los flujos son
enrutados, es importante que el controlador SDN pueda tomar decisiones de enrutamiento basado
en múltiples campos de la cabecera de OpenFlow. Relativo al tráfico de enrutamiento, una importante
funcionalidad en un controlador SDN es su capacidad para descubrir múltiples caminos desde el origen
del flujo a su destino y para dividir el tráfico para un flujo dado a través de múltiples enlaces.

Escalabilidad: En el entorno actual las empresas deben esperar que los controladores que adquieran
puedan soportar un mínimo de 100 switches. También hay que asegurarse de que el controlador
pueda reducir al mínimo la proliferación de las entradas de la tabla de flujo.

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

Programación de Red: Los tipos de programación que las empresas deben buscar en un controlador
SDN son la capacidad de redirigir el tráfico y la posibilidad de aplicar filtros sofisticados a los paquetes.
Un controlador SDN también puede soportar la programación, proporcionando plantillas que
permitan la creación de secuencias de comandos CLI (Interfaz de Línea de Comando o Command Line
Interface, por sus siglas en inglés) que, a diferencia de la configuración tradicional de gestión, permiten
la programación dinámica de la red.

Confiabilidad: Una de las técnicas que un controlador SDN puede utilizar para aumentar la fiabilidad
de la red, es la capacidad de descubrir múltiples caminos desde el origen hasta el destino. Relativo a
la disponibilidad de las conexiones externas, es importante que el controlador soporte tecnologías
alternativas de diseño, como el VRRP y MC LAG, que tienen como objetivo aumentar la fiabilidad de
la red. En cuanto a la disponibilidad del controlador de sí mismo, es fundamental que el controlador
se construya utilizando redundancia tanto para las características de hardware como para las de
software. También es imprescindible que este permita los clusters.

Seguridad de Red: Con el fin de proporcionar seguridad a la red, un controlador SDN debe ser capaz
de soportar la autenticación de clase empresarial y la autorización de los administradores de la red.
Además, los administradores de red deben ser capaces de bloquear el acceso al tráfico de control SDN.
Además, debido a que un controlador SDN es un candidato para un ataque malicioso, este necesita la
capacidad de limitar las comunicaciones de control, y ser capaz de alertar a los administradores de red
cuando la red está experimentando una sospecha de ataque.

Monitorización centralizada y visualización: Un controlador SDN tiene que ser capaz de utilizar los
datos ofrecidos por el protocolo OpenFlow para identificar los problemas en la red y automáticamente
cambiar la ruta que toma un flujo determinado. También debe ser capaz de descubrir y presentar una
visualización de los enlaces físicos de la red. Otra característica fundamental es que debería ser posible
monitorizar el controlador SDN utilizando protocolos y técnicas estándares. Por ejemplo, con esto será
posible controlar la salud del controlador y de las redes virtuales que el controlador soporta usando
SNMP.

Fabricantes de controladores SDN: Aquí se debe evaluar es la competencia técnica del vendedor. En
particular, se debe evaluar la resistencia global del proveedor, así como la profundidad de su
organización de ingeniería. Una prueba de fuego clave que se debe aplicar es "¿Tiene el proveedor los
recursos financieros y técnicos para apoyar el desarrollo en curso que se asociará con SDN?" Las
organizaciones no pueden permitirse el lujo de tener sus iniciativas SDN perjudicadas por el uso de un
proveedor que no puede mantenerse al día con el entorno SDN que cambia rápidamente.

Checklist of Key SDN Controller Functionality

Below is a checklist of the ten criteria that IT organizations should use to evaluate SDN controllers.

OpenFlow Support

IT organizations need to understand the OpenFlow functionality that the controller currently supports,
including support for optional features and extensions to the protocol. IT organizations also need to
understand the vendor’s roadmap to implement new versions of OpenFlow.

Network Virtualization

It must be possible to dynamically create policy-based virtual networks to meet a range of

requirements. These virtual networks must abstract and pool network resources in a manner similar
to how server virtualization abstracts and pools compute resources.

Network Functionality

This includes the ability to discover multiple paths from origin to destination and to split the traffic
across multiple links. It also includes the ability to utilize a rich set of constructs that enable the
creation of L2 and L3 networks within a tenant-specific virtual network.

Scalability
An SDN controller should be able to support a minimum of 100 switches. It must also be able to
mitigate the impact of network broadcast overhead and the proliferation of flow table entries.

Performance

An SDN controller must be able to pre-populate the flow tables to the degree possible and it must
have processing and I/O capabilities that ensure that the controller is not a bottleneck in the creation
of flow entries.

Network Programmability

It must be possible to apply sophisticated filters topackets. The SDN controller should provide
templates that enable the creation of scriptable CLIs that allow for the dynamic programming of the
network.

Reliability

It must be possible to have multiple network paths from origin to destination. The SDN controller
should also be built using both hardware and software redundancy features and it must be possible
to cluster the controllers.

Security of the Network

It must be possible to apply enterprise class authentication and authorization and to completely
isolate each virtual network. The SDN controller must be able to rate limit the control
communications.

Centralized Management and Visualization

An SDN controller should enable the IT organization to choose the classes of traffic that it monitors
and it should present to the IT organization a visualization of both the physical network and the
multiple virtual networks that run on top of it.

The SDN Controller Vendor

The vendor must demonstrate that it has the financial and technical resources to support the ongoing
development that will be associated with SDN. The vendor must also demonstrate its long-term
position and momentum in the SDN marketplace.
Notas:

Una razón por la que se necesita entender la hoja de datos, es que algunas funciones importantes
como el soporte de IPv6 no es parte de OpenFlow v1.0 pero se incluyen a partir del estándar OpenFlow
v1.2.

La disociación de las redes virtuales de las redes físicas permite a las empresas realizar cambios en la
red física, como por ejemplo la ampliación horizontal de la capacidad, sin afectar los flujos existentes.
De manera similar, una de las muchas ventajas de tener la virtualización de la red es que permite un
completo aislamiento entre cada segmento de red.

Esta capacidad elimina limitaciones de STP y aumenta el rendimiento y la escalabilidad de la red,

también con esto se puede eliminar la necesidad de añadir a la complejidad de la red nuevos
protocolos como TRILL (Transparent Interconnection of Lots of Links) o SPB (Shortest Path Bridging).

pero también hay que tener en cuenta que este número también depende de los casos de uso de SDN
que soportan.

Estas métricas de desempeño influyen en gran medida cuando hay que implementar controladores
adicionales. Por ejemplo, si los switches en una SDN inician más flujos de los que pueden ser
soportados por el controlador o los controladores SDN existentes, hay que añadir más controladores.

Por ejemplo, por razones de seguridad se puede elegir que el tráfico entrante a un servidor pase a
través de un firewall. Sin embargo, con el fin de no consumir los recursos del servidor de seguridad
con el tráfico limpio, se puede optar por redirigir el tráfico que es saliente del servidor a no pasar por
el firewall.

Si el controlador SDN establece varias rutas entre el origen y el destino, la disponibilidad de la solución
no se ve afectada por la interrupción de un solo enlace. Alternativamente, si el controlador SDN sólo
establece una única ruta del origen al destino, cuando ocurra un fallo en el enlace, el controlador debe
ser capaz de redirigir el tráfico rápidamente a un enlace activo. Esto requiere que el controlador esté
controlando continuamente la topología de la red.

Estas métricas de desempeño influyen en gran medida cuando hay que implementar controladores
adicionales. Por ejemplo, si los switches en una SDN inician más flujos de los que pueden ser
soportados por el controlador o los controladores SDN existentes, hay que añadir más controladores.

Dado el creciente interés en SDN, numerosos fabricantes han entrado en el mercado y muchos más
han anunciado su intención de entrar. Debido a la volatilidad del mercado SDN en general, y del
mercado del controlador SDN, en particular, las organizaciones que están evaluando los controladores
SDN deben centrarse no sólo en los atributos técnicos del controlador, sino también en un par de
atributos claves del vendedor que está proporcionando el controlador.
Bibliografía:

[1] http://openmul.wordpress.com/2014/07/09/openmul-release-v4-0-1-is-available

[2]
http://www.researchgate.net/profile/Ruslan_Smeliansky/publication/247161000_Advanced_Study_
of_SDNOpenFlow_controllers/file/3deec5214c88b0b98a.pdf