El Controlador SDN e Interfaces

Como se ha mencionado anteriormente, SDN permite abstraer los recursos de red subyacentes a aplicaciones y servicios de red. Para lograr este objetivo, el controlador debe mantener una estructura o arquitectura en particular. Göransson et al. [24] presentan una arquitectura genérica para el controlador SDN que se muestra en la Figura 2.8. En esta arquitectura se destacan las interfaces o APIs (Aplication Programming Interfaces) Southbound y Northbound, módulos base que proporcionan servicios específicos y aplicaciones SDN que frecuentemente se incluyen con el controlador.

En la sección anterior se indicó que el API Southbound es utilizado para interactuar con los dispositivos SDN, siendo OpenFlow uno de los protocolos más utilizados. No obstante, existen otras propuestas que permiten cumplir algunos de los objetivos de SDN. Estas propuestas utilizan de forma remota las funciones que se incorporan en los dispositivos de red, empleando métodos tradicionales como SNMP, CLI, NETCONF o APIs REST (Representational State Transfer). Ciertamente, estas propuestas alternativas pueden ser consideradas interfaces Southbound ya que permiten manipular los dispositivos de red y proporcionar la inteligencia y comportamiento previsible que se espera en una red controlada por SDN. Sin embargo, este tipo de soluciones están destinadas a actuar sobre la configuración del dispositivo y los protocolos de red que éste soporta. Por lo tanto, estas soluciones no permiten ejercer un control detallado del tráfico, como lo hace OpenFlow, ya que no permiten definir reglas de envío en el plano de datos.

Continuando con la descripción de la anatomía del controlador SDN, los módulos base se encargan de presentar una visión abstracta de la infraestructura de red subyacente a las aplicaciones externas a través de servicios. Estos servicios son accesibles a través del API Northbound. Las aplicaciones consumen estos servicios para proporcionar nuevas funcionalidades de control. El controlador puede definir un diseño basado en plugins para implementar los servicios base con el objetivo de adaptarse a los requisitos de una red individual.

Para las aplicaciones SDN, una función clave proporcionada por el controlador es el API que permite acceder a la configuración de la red. En algunos casos, este API Northbound es una interfaz de bajo nivel que proporciona acceso a los dispositivos de red de una manera común y consistente. En este caso, esa aplicación es consciente de los dispositivos individuales, pero está protegida de sus diferencias. En otros casos, el controlador puede proporcionar un API de alto nivel que proporciona una abstracción de

35

la propia red, de modo que el desarrollador de la aplicación no debe preocuparse de los dispositivos individuales, sino de la red como un todo. La arquitectura de referencia SDN propuesta por la ONF [22] también describe la opción para implementar la recursividad en la capa de aplicación. Las aplicaciones pueden ofrecer servicios a través del API Northbound para simplificar y fomentar la creación de nuevos servicios avanzados o funcionalidades con un mayor nivel de abstracción. Por ejemplo, una aplicación de control de acceso a la red (NAC) podría utilizar el servicio de conmutación de capa 2 (L2) subyacente para implementar su funcionalidad sin necesidad de implementar todo el servicio de conmutación de L2. Del mismo modo, la aplicación NAC también podría ofrecer su funcionalidad como un servicio a otras aplicaciones.

Figura 2.8 Arquitectura genérica de un controlador SDN [24].

Como se puede notar, el API Northbound desempeña un rol crítico en la creación de herramientas para gestionar la red y, por lo tanto, en la consolidación del paradigma SDN. Sin embargo, la falta de estandarización ha obligado a que diferentes controladores propongan diferentes tipos de APIs. Aunque existe un consenso sobre el concepto de servicios básicos y recursividad entre los diferentes controladores, el API Northbound es altamente heterogéneo debido a que cada controlador SDN trata de imponer su propia visión acerca del modelo operativo de este API. Esta situación promueve el efecto “lock-in” del controlador lo cual representa una desventaja significativa que pone en peligro el principio de apertura SDN.

Como lo mencionan Trois et al. [26], el API Northbound puede ser implementado por un controlador de diferentes maneras: como un marco que proporciona un API, como un lenguaje de programación SDN de alto nivel o como un API remoto. Las dos primeras opciones representan un modelo dependiente del controlador, caracterizado por atar a los desarrolladores a una tecnología de controlador específica y restringir la portabilidad de las aplicaciones. Por otra parte, al estar los planos de aplicación y control fuertemente acoplados, ambos deben ejecutarse en el mismo servidor y deben implementarse con el mismo lenguaje de programación.

Con el fin de superar la dependencia de la plataforma del controlador SDN, diferentes controladores también proporcionan un API Northbound basado en REST, el cual se ha convertido en el API remoto predominante. Debido a que cada controlador tiene su propia visión acerca de la implementación del API basado en REST, se han presentado diferentes propuestas para guiar su correcta implementación, tal es el caso del grupo de trabajo NBI de la ONF [27], el Software-Defined Networking Research Group (SDNRG) [28] y Li et al. [29]. Por definición, la tecnología REST es extensible y proporciona un acoplamiento débil entre clientes y servidores, sin embargo, no es adecuado para todos los casos de uso. Las aplicaciones externas podrían necesitar un canal de comunicación bidireccional y full-duplex para interactuar con los servicios base u otras aplicaciones. HTTP es un protocolo unidireccional donde las funciones de los servidores y los clientes no son intercambiables y una solicitud siempre se inicia por

36

un cliente. HTTP también utiliza un paradigma petición-respuesta que restringe que los clientes y los servidores puedan comunicarse entre sí simultáneamente. En cuanto a las aplicaciones en tiempo real, la naturaleza “locuaz” de HTTP y la iniciación/terminación continua de conexiones aumenta significativamente el tiempo necesario para procesar el encabezado y la carga útil para miles de pares de solicitud/respuesta. Además, los servicios proporcionados por el API están restringidos por el número reducido de verbos HTTP estándar, lo cual podría perjudicar la expresividad del API.

En la actualidad, el grupo de trabajo NBI de la ONF ha propuesto un enfoque distinto para el API Northbound. Como se muestra en la Figura 2.9, en lugar de definir otra API más, este grupo de trabajo ha definido un API en la parte superior de las APIs base del controlador, con un nivel de abstracción mayor. De esta manera, las capacidades de la interfaz se basan en “propósitos” o “intents” en lugar de la programación detallada de las tablas de OpenFlow. Este enfoque permite separar completamente las implementaciones de sistemas consumidores y proveedores y, representar solicitudes humano/máquina originadas en el consumidor, tan simple como sea posible [30].

Por ejemplo, un API basada en intents permitiría a las aplicaciones realizar solicitudes abstractas como

“permitir que el host A se comunique con el host B”. En respuesta a esta solicitud, el controlador SDN realizaría la programación automática de flujos en todos los dispositivos que forman parte de la trayectoria desde el host A al B. En comparación con un API tradicional, la obtención del mismo resultado involucraría realizar la programación manual de todos los dispositivos que forman parte del trayecto entre el host A y B, lo cual incrementaría la complejidad de la aplicación. De acuerdo con

Görasson et al. [24], el concepto de intents se basa en tres características fundamentales:

• Abstracción: El objetivo de un controlador SDN, al igual que con los sistemas operativos en

general, es ocultar los detalles del hardware subyacente a la aplicación que se ejecuta en la parte superior.

• Declarativo: Especificar qué hacer, en lugar de como hacerlo, es una característica de los

sistemas declarativos.

• Agnóstico del protocolo: Una interfaz declarativa abstracta oculta detalles del proceso de

programación de red, permitiendo que diferentes protocolos se utilicen en diferentes situaciones.

Figura 2.9 Interfaz Northbound basada en “propósitos” o “intents”. Representa un paso hacia la creación de un

API que elimina la necesidad de conocer y comprender los detalles de los dispositivos en la red física [24].