Virtualización y Virtualización de Funciones de Red (NFV)

La virtualización del RGW es actualmente la principal tendencia en este campo debido a dos razones. En primer lugar, las tecnologías de virtualización han alcanzado un alto nivel de madurez, utilizándose ampliamente para aumentar la eficiencia y la flexibilidad del Centro de Datos. En segundo lugar, la virtualización permite continuar utilizando el paradigma de redes tradicional basado en capas (L1 – L7). En función de estas razones, se consideran dos enfoques para implementar la virtualización del RGW. El primer enfoque, propone que las funciones de red específicas como el encaminamiento o NAT se ejecuten sobre diferentes instancias virtualizadas dentro del propio RGW. Así, Ibañez et al. [53] proponen la virtualización de la plataforma OSGi que se ejecuta en el RGW con el objetivo de crear múltiples instancias, cada una de las cuales proporciona un conjunto de funciones o servicios definidos y controlados por un ISP específico. Similarmente, Whiteaker et al. [54] definen una Pasarela de Alojamiento de Servicios (Service-hosting Gateway, SHG) que actúa como una plataforma de ejecución mediante la virtualización del sistema operativo donde ésta se ejecuta. Los usuarios deciden los servicios que se ejecutarán en un SHG individual siguiendo un modelo de tienda de aplicaciones y, a través de la virtualización, cada servicio se ejecutará en una máquina virtual separada.

Ciertamente, las propuestas de Ibañez et al. y Whiteaker et al. proporcionan flexibilidad para integrar nuevos servicios o funciones al RGW a través de técnicas de virtualización y permiten que el usuario residencial escoja cuales servicios agregar. Sin embargo, las propuestas aíslan al usuario de las tareas de gestión ya que los servicios son utilizados principalmente por el ISP y además no se especifica si tales servicios tienen como objetivo abordar los requerimientos del usuario residencial. Adicionalmente, debido a los recursos computacionales disponibles limitados del RGW, ambos enfoques presentan una desventaja importante que puede restringir el desempeño de determinados servicios avanzados con altas demandas de recursos computacionales. Además, si los servicios en ejecución exigen más recursos, es obligatoria una actualización de hardware del RGW. Esta opción es poco adecuada, ya que representa un incremento sustancial de CaPex y, en consecuencia, los procedimientos correspondientes con respecto a la implementación, el mantenimiento y la gestión pueden ser problemáticos.

El segundo enfoque, propone externalizar las funciones de red del RGW. Cruz et al. [55], presentan una arquitectura para virtualizar el RGW. La mayoría de las funciones del RGW se mueven a la infraestructura del operador utilizando virtualización y nubes privadas mientras se mantiene un dispositivo drásticamente simplificado en las instalaciones del usuario. Este enfoque está estrechamente relacionado con el paradigma de virtualización de funciones de red (NFV) analizado en la sección 2.3 y, en particular, con el caso de uso de aplicabilidad propuesto orientado a la virtualización del entorno residencial [56]. En este escenario, un dispositivo L2 (capa 2) reemplaza al RGW estándar y las funciones restantes de nivel superior, como el encaminamiento o NAT, se proporcionan como Funciones de Red Virtualizadas (VNFs) en la infraestructura de NFV (NFVI) del ISP.

Broadband Forum con base en el enfoque de ETSI para virtualizar el RGW propone la arquitectura NERG (Network Enhanced Residential Gateway) [57]. En esta arquitectura se define el gateway virtual (vG) como un componente lógico encargado de contener las funciones de red que son externalizadas del RGW estándar. Se plantea que un MS-BNG (Multi-Service Broadband Network Gateway) o una NFVI asociada se encargue de alojar a los diferentes vGs y sus correspondientes funciones, ya sean VNFs o PNFs. NERG también plantea el caso en el que un determinado tráfico en el vG pueda necesitar utilizar un diferente grupo de servicios o cadena de servicio para lo cual se debería implementar un direccionamiento selectivo y clasificación de tráfico. Broadband Forum desarrolla un poco más esta idea en TR-345 [58] donde se propone implementar una NFVI para aumentar o reemplazar los servicios proporcionados por el BNG con VNFs. En este escenario, una función de clasificación localizada en un MS-BNG físico es responsable de direccionar el tráfico del suscriptor a un grafo de servicio o SFC

56

desplegada en el NFVI. A su vez, la asignación se puede aplicar a todo el tráfico de suscriptor o flujos específicos.

En un informe elaborado conjuntamente entre OPNFV y OpenDayLight [59] se indica que la virtualización del CPE (Customer Premises Equipment) se ha convertido en el caso de uso más popular de aplicación de NFV y SDN, destacando que su implementación satisfactoria requiere el uso de SFCs que permitan acceder a otras funciones de red. El informe argumenta que, aunque el CPE virtual (vCPE) es un caso de uso que se puede aplicar tanto en entornos empresariales como residenciales, los requisitos y enfoques para los dos casos son bastante diferentes. Por ejemplo, en el caso de un vCPE empresarial, se podría requerir que una funcionalidad específica se ejecute localmente en la sucursal mientras que, en otro caso con el objetivo de reducir el costo y la complejidad de la sucursal, algunas de las funciones de su CPE podrían implementarse en el centro de datos de la empresa.

En el informe de 2017 sobre Virtual Edge y SD-WAN [60] realizado por SDX central se indica que la tecnología vCPE empresarial puede ejecutar las instancias virtualizadas en las instalaciones del cliente (a veces en equipos de menor costo), en oficinas centrales (CO) o puntos de presencia (PoP) o en centros de datos. Varias arquitecturas vCPE empresariales proporcionan enfoques híbridos que permiten ejecutar diferentes funciones en diferentes ubicaciones para optimizar la latencia, la gestionabilidad y el costo.

La iniciativa CORD32 _{(Central Office Re-architected as a Data Center) [61] aprovecha las tecnologías}

SDN, NFV y Cloud para proponer un nuevo diseño que transforme la central de telecomunicaciones (CO) en un centro de datos. El objetivo es reemplazar el hardware propietario y cerrado con software que se ejecuta en dispositivos de acceso, conmutadores y servidores genéricos o estándar para mejorar la provisión de servicios de telecomunicaciones. Se ofrecen soluciones orientadas a entornos residenciales (R-CORD), empresariales (E-CORD) y móviles (M-CORD). La propuesta residencial de CORD incluye una Red de Acceso Óptica Definida por Software (SDOAN) compuesta por un OLT (Optical Line Terminal) habilitado para OpenFlow y su complemento de software designado como OLT virtual (vOLT). Al igual que ETSI y Broadband Forum, R-CORD también virtualiza el RGW o CPE, colocando un dispositivo “bare-metal switch” en casa del usuario y desplegando un Gateway de Subscriptor virtual (vSG)33 _{en la Nube de la oficina central que contiene un conjunto de funciones}

seleccionadas por el usuario. Todos los componentes residenciales de CORD están orquestados por una plataforma de administración centralizada.

De la revisión realizada se observa un claro consenso en cuanto a la propuesta de virtualización del RGW (vRGW) basada en el paradigma NFV, no obstante, faltan aspectos por considerar para consolidar el enfoque. Por ejemplo, Broadband Forum al centrarse en mostrar los beneficios de NERG y especificar algunos requisitos para conseguirlos, omite la descripción detallada sobre cómo agregar nuevas funciones de red al vG. Si bien el TR-345 tiene la intención de soportar la arquitectura NERG, el direccionamiento de tráfico con base en una 5-tupla o en la aplicación (L7) que realiza la función de clasificación del MS-BNG, no representa un mecanismo preciso que permita identificar flujos de tráfico específicos de la red residencial y, por lo tanto, no se proporcionaría la capacidad plena de satisfacer los requerimientos de un tipo de tráfico determinado. CORD va más allá de las propuestas de Broadband Forum y presenta una plataforma unificada con base en los principios del “Cloud Networking”. Sin embargo, R-CORD en su propuesta, no considera la creación de SFCs personalizadas por flujo de tráfico para una red residencial dada. Por otra parte, CORD no termina de definir el tipo de dispositivo a colocar en casa del usuario. Si bien en la descripción del vSG se propone reducir el RGW o CPE a un “bare-

metal switch”, en la descripción de la OLT virtual (vOLT)34 _{se indica que el sistema extremo a extremo}

propuesto incluye un CPE controlado por OpenFlow. No obstante, no existe una aplicación de ONOS que se encargue de controlar dicho CPE. La aplicación vOLT solamente se encarga de controlar la OLT compatible con OpenFlow.

Si bien es cierto que NFV aprovecha la capacidad de las tecnologías en la Nube para proporcionar dinámicamente diferentes tipos de servicios con determinados requisitos computacionales, este

32 _{https://opencord.org/}

33 _{https://wiki.opencord.org/pages/viewpage.action?pageId=1278090} 34 _{https://wiki.opencord.org/pages/viewpage.action?pageId=1278086}

57

paradigma se centra en proporcionar una réplica virtualizada de un dispositivo de red implementado con hardware específico y, por lo tanto, la propuesta de vRGW al colocar un dispositivo L2 restringe las capacidades de direccionamiento requeridas para controlar con precisión flujos de tráfico. Por ejemplo, resulta más eficaz filtrar tráfico no deseado localmente antes que realizarlo en el vRGW o podría presentarse la necesidad de asignar una prioridad a un determinado tipo de tráfico (Differentiated Services Code Point, DSCP) antes de que ingrese al vRGW. Por otra parte, aunque el enfoque de vRGW en principio permite agregar diferentes VNFs las cuales podrían estar destinadas a abordar temas relacionados a la Facilidad de Gestión, Visibilidad, QoS/QoE o Seguridad, no se garantiza una participación activa y total del usuario residencial en las tareas de gestión de sus propias redes. Así, se podría decir que la virtualización del RGW aborda, en parte, los problemas asociados a las redes residenciales como son la limitada usabilidad, alto grado de heterogeneidad del entorno y limitada flexibilidad para mejorar el servicio de conectividad de red provisto.