Redes Definidas por Software (SDN)

La aplicabilidad de los principios de SDN en entornos residenciales representa otra tendencia importante. Esta sección analiza las diferentes propuestas basadas en SDN considerando adicionalmente las diferentes configuraciones posibles relacionadas con la ubicación de los planos de control y datos, ya que los mismos se encuentran desacoplados y, la estrategia definida para abordar los requisitos relacionados a la Facilidad de Gestión, Visibilidad, QoS/QoE y Seguridad.

Yiakoumis et al. [62] y Gharakheili et al. [63] despliegan la capa de infraestructura SDN en el borde del ISP. Ambas propuestas permiten a los usuarios residenciales expresar sus propósitos o solicitudes a través de un "agente". Estos propósitos se traducen posteriormente a una semántica de red de bajo nivel y se entregan a un "agente de ISP" para modificar la configuración del nodo de borde. Ambos enfoques implementan las capas restantes en las instalaciones del ISP y pueden considerarse centradas en el usuario. Si bien las propuestas se enfocan en los requisitos de QoS y facilidad de gestión, Yiakoumis et al. no definen una estrategia que les permita abordar el resto de requisitos como lo hacen Gharakheili et al. al definir un enfoque basado en APIs. En este enfoque, desde un portal web, se acceden a dos APIs principales para modificar la configuración del dispositivo de borde. El enfoque es acertado, sin embargo, falta definir un marco o arquitectura que generalice la forma en la cual se ofrecen servicios desde la capa de control y el acceso a los mismos de una manera estándar, independientemente de la tecnología de controlador SDN subyacente utilizada.

Pediaditakis et al. [64] y Mortier et al. [65] proponen un RGW basado en Linux compuesto por un Open

vSwitch (OVS35_{) controlado por OpenFlow y un controlador NOX. En esta configuración, tanto el plano}

de datos como el de control están co-ubicados en el mismo dispositivo, proporcionando un RGW basado en SDN "todo en uno". Pediaditakis et al. proporcionan una aplicación para iPad encargada de guiar al usuario en la definición de políticas para gestionar el RGW. Un motor de políticas recibe la representación textual de la política desde la aplicación y la traduce a una descripción de tarea la cual se entrega al entorno de tiempo de ejecución para modificar la configuración del RGW. El entorno de tiempo de ejecución incorpora un servicio de configuración que permite representar la configuración general de la red como una colección de descripciones de tareas independientes de la plataforma y un gestor de monitoreo para almacenar información de uso y estado de la red. La propuesta permite abordar los requisitos desde la perspectiva del usuario, así como lo incluye activamente en las tareas de gestión. Ciertamente, las políticas que se pueden crear dependen de las tareas que se proporcionan en el servicio de configuración. Si bien la arquitectura propuesta considera que se pueden agregar más tareas, es complejo que una única aplicación haga uso de todas ellas de una manera eficiente para ofrecer una amplia variedad de funcionalidades de gestión considerando los requisitos de usuario. Mortier et al. proponen que el controlador NOX exporte una interfaz de servicios web para controlar módulos que implementan un servidor DHCP personalizado, controlan el envío y la asociación inalámbrica a través de filtrado e interceptan las búsquedas de DNS con el objetivo de proporcionar un control por flujo más preciso. Los autores indican que los servicios proporcionados por el API permiten crear interfaces para la gestión de la red orientada a usuarios no expertos, mostrando un ejemplo de un panel de invitados que

58

proporciona un punto de control central y una vista de la red. La arquitectura propuesta no considera extender las capacidades de gestión del API y dadas las reducidas opciones que se incorporan, no se garantiza que los requisitos de usuario se cumplan satisfactoriamente. Por otra parte, al implementar el plano de datos y control en el mismo dispositivo, ambos enfoques proporcionan una arquitectura cerrada que restringe el desempeño de los servicios que se ejecutan debido a los limitados recursos computacionales del hardware.

Otra configuración es presentada por Boussard et al. [66] y Gharakheili et al. [67]. En las instalaciones del usuario, la capa de infraestructura se implementa utilizando un RGW basado en SDN y las capas restantes se implementan en la infraestructura del ISP para proporcionar un entorno de gestión "basado en la Nube". Esta configuración aprovecha las capacidades de la infraestructura del ISP para superar las limitaciones de un RGW basado en SDN "todo en uno", como la disponibilidad limitada de recursos computacionales, los complejos procesos de actualización de software y hardware y la gestión remota. Boussard et al. proponen la creación de LANs definidas por software (SD-LANs) que representan redes virtuales/personales que incluyen diferentes dispositivos conectados y posibles servicios adicionales y funcionalidades del ISP o de terceros. Un controlador, denominado como “Majord’Home” abstrae los dispositivos u objetos conectados (CO) en la red residencial en objetos virtuales (VO) con el fin de proporcionar un control programable de ellos a través de una API común. El usuario final puede interactuar con Majord'Home a través de un cliente Android el cual proporciona una interfaz de usuario simple que permite la consulta de los diferentes VO pertenecientes a un controlador local o remoto para la creación de una SD-LAN.

Gharakheili et al. introducen el concepto de Proveedor de Gestión de Servicios (SMP) encargado de ejercer el control de configuración sobre el RGW en representación del usuario. SMP proporciona interfaces de personalización (portales web/aplicaciones) a los usuarios, traduciéndolas en operaciones de nivel de red invocadas mediante APIs. El API propuesto define tres categorías de interacciones: aplicaciones que emiten solicitudes para modificar el estado de la red, consultas para sondear el estado de la red y sugerencias para ayudar a mejorar el rendimiento. El SMP puede construir potentes servicios de valor agregado al componer estas APIs de red simples expuestas por el controlador. Como se sigue un enfoque “over-the-top”, diferentes partes interesadas (proveedor de ISP o RGW) pueden implementar las capacidades de SMP en diferentes ubicaciones (Nube privada o Nube de terceros). Si bien ambas propuestas optan por incluir al usuario en las tareas de gestión y abordan la mayoría de sus requisitos, la apertura está restringida en ambas propuestas debido a que los marcos o arquitecturas no fueron concebidos como entornos de desarrollo.

La especificación de APIs estándar es necesaria para desarrollar y agregar fácilmente nuevas aplicaciones de gestión a cargo de mejorar diferentes aspectos de las redes residenciales, así como definir un conjunto básico de servicios a nivel del controlador que permitan componer servicios con un nivel mayor de abstracción. Del mismo modo, un enfoque independiente del controlador SDN podría adoptarse para suprimir la dependencia de una tecnología específica. Aunque la ubicación del plano de control en las instalaciones del ISP es más adecuada en comparación con un RGW basado en SDN "todo en uno", se debe explotar de mejor manera la flexibilidad y escalabilidad inherentes de las tecnologías en la Nube y NFV. Para ello, se requiere una arquitectura que defina la forma en la cual las capas lógicas de SDN serán implementadas en la infraestructura de computación en la Nube del ISP con el fin de cumplir con los requisitos de la solución basada en SDN.

A diferencia de permitir a los usuarios gestionar sus propias redes, se propone un enfoque para delegar la gestión de la red residencial a expertos externos o sistemas autónomos. Adicionalmente, existen propuestas que se especializan en abordar un determinado requisito del usuario. Por ejemplo, Kim y

Feamster [68] y Calvert et al. [69] contribuyen a mejorar el requisito de Visibilidad utilizando un RGW

basado en SDN “todo en uno”. Kim y Feamster señalan que las mediciones de red pueden usarse para determinar si el rendimiento de la red residencial cumple con las expectativas del usuario. Calvert et al. proponen un sistema Registrador de Datos de Red Residencial que recopila datos de la red y proporciona a terceros esta información para crear nuevas aplicaciones a cargo de ayudar en la solución de problemas.

Con respecto a las mejoras en Seguridad, Feamster [70] propone externalizar la gestión de la seguridad.

59

estadísticas se envían a un controlador externo a cargo de realizar una inferencia distribuida para determinar el tráfico no deseado como botnets o malware y para filtrar el spam. Considerando que los requisitos de los usuarios son altamente heterogéneos, un enfoque basado en la externalización de la gestión debe enfrentar el desafío de cumplir con cada uno de ellos. Además, la adición de servicios de terceros representa un pago adicional que será cubierto, usualmente, por los usuarios finales.

Luo et al. [71] proponen un mecanismo para mitigar ataques de múltiples fases en Redes Residenciales Definidas por Software (SDHN). La detección de un evento en la red activa un proceso de evaluación de la seguridad basado en evidencia que utiliza un modelo de grafo de ataque e inferencia posterior. Con base en el resultado de la evaluación, el proceso de selección de contramedidas determina un plan de mitigación de ataque que indica al controlador SDN cómo instalar instancias de VNF en los nodos de red seleccionados. Aunque resulta de gran utilidad que los dispositivos de usuario final sean compatibles con las tecnologías SDN y NFV de acuerdo con el enfoque propuesto, los autores proporcionan una arquitectura de alto nivel, omitiendo detalles importantes que permitan comprender de mejor manera como se proporcionan todas las funcionalidades que se indican en la propuesta.

Con respecto a las mejoras en QoS/QoE, Jang et al. [72] proponen un marco de asignación de ancho de

banda consciente de la QoS para el hogar inteligente basado en SDN considerando dispositivos M2M (machine to machine) y dispositivos no M2M. Para este fin, se propone modificar el identificador de clase de QoS (QCI) propuesto por el 3GPP LTE para adaptarlo a los servicios del hogar inteligente y se propone un algoritmo de planificación que considera la equidad, el retraso y la prioridad. Un RGW habilitado para OpenFlow es desplegado en las instalaciones del usuario mientras que el ISP mantiene un “SDN Smart Home Cloud” destinado a crear una red virtual de hogar dedicada (Home VN) por cada hogar inteligente. Si bien se considera la infraestructura en la Nube del ISP, la propuesta es agnóstica del paradigma NFV. Además, un único controlador para varios hogares inteligentes no representa una solución adecuada considerando que un eventual fallo en el controlador SDN significaría que todos los hogares inteligentes perderían el servicio de asignación de ancho de banda.

Por otra parte, Abuteir et al. [73] proponen NAVS (Network Assisted Video Streaming) para realizar un conformado de tráfico dinámico para diferentes flujos de video en función de la política definida (por el usuario o pre-definidas por el sistema), el número de flujos de video, los bitrates de video disponibles y el ancho de banda del acceso a Internet. Para este fin, NAVS integra diferentes módulos para definir políticas, monitorizar el tráfico, analizar el MPD (Media Presentation Description), optimizar la QoE y conformar el tráfico. Los autores afirman que la asignación de ancho de banda para cada flujo de video se realiza en tiempo real. No obstante, no especifican la ubicación del controlador ni la tecnología de controlador utilizada lo cual afecta directamente a la capacidad de reacción de NAVS. Adicionalmente, los autores deberían considerar que el eventual uso de control “en banda” en SDN también podría afectar la capacidad de reacción, sobre todo en casos de congestión.

Si bien un RGW basado en SDN proporciona mejores condiciones en comparación con un RGW tradicional para optimizar los procesos de gestión y enriquecer el servicio de conectividad de red provisto, este enfoque se podría beneficiar de propuestas adicionales relacionadas a la red de acceso y al segmento inalámbrico de la red residencial con el propósito de proporcionar una solución integral.

Por ejemplo, Rükert et al. [74] proponen que tanto el RGW, el nodo de acceso, los conmutadores de la

red de agregación y el BRAS (Broadband Remote Access Server) sean compatibles con SDN. Este enfoque puede considerarse un caso ideal y, como argumentan los autores, la configuración de los flujos de tráfico puede ser más dinámica, optimizando el rendimiento de la red, especialmente para los servicios que consumen un gran ancho de banda.

En una aproximación similar, Gharakheili et al. [75] proponen que el nodo de acceso se conecte a un conmutador Ethernet SDN que a su vez se conecta a la red backhaul del ISP para proporcionar acceso a Internet. El conmutador SDN está controlado por un controlador SDN que se encuentra dentro de la red del ISP y expone APIs que son utilizadas tanto por el usuario final como por los proveedores de servicios de contenido (CSP) para gestionar de mejor manera el ancho de banda limitado del acceso a Internet. Con respecto a una Red de Acceso Definida por Software (SDAN), Kerpez et al. [76] indican que esta propuesta tiene como objetivo abstraer toda la red de acceso por medio de una interfaz unificada y

60

común para gestión y control que permite la creación ágil de nuevos servicios adaptados a las necesidades del usuario.

Considerando que los medios de transmisión ópticos se están convirtiendo en la opción preferida para las redes de acceso, se requiere que el nodo de acceso u OLT (Optical Line Terminal) sea compatible con los principios de SDN. En la actualidad, OLTs basados en SDN que implementen nativamente OpenFlow no están usualmente disponibles. Para solventar este inconveniente, Thyagaturu et al. [77] indican que se utiliza una capa de abstracción de hardware que permita convertir OLTs tradicionales en dispositivos controlados por OpenFlow. Diferentes propuestas están alineadas con este enfoque. Por ejemplo, Clegg et al. [78] presentan una GPON (Gigabit-capable Passive Optical Network) habilitada para OpenFlow. La capa de abstracción de hardware presenta al controlador externo OpenFlow un único conmutador distribuido con varios puertos, uno para el OLT y los puertos restantes para cada ONT (Optical Network Terminal). Lee et al. [79] presentan una propuesta similar en la cual un agente OpenFlow embebido reside dentro de la OLT. El agente interactúa con el controlador externo OpenFlow y el módulo GPON OMCI (ONT Management and Control Interface), transformando todo el sistema GPON en un conmutador virtual.

Gallo et al. [80] proponen aplicar los principios de SDN para abordar las complejidades de las redes residenciales inalámbricas. Los autores introducen la arquitectura “SDN@home” en la cual el plano de control de diversas redes domésticas inalámbricas (por ejemplo, entretenimiento, automatización o cuidado de la salud) está separado del plano de datos y, el RGW con soporte para múltiples tecnologías, actúa como un controlador central. Este enfoque permite que dispositivos inalámbricos de propósito general sean programados al instante mediante la instalación de programas de radio en función de diferentes escenarios de aplicación y condiciones cambiantes que afectan a la red residencial.