La virtualización de funciones de red (NFV) [1] es un concepto de arquitectura de red que aprovecha las tecnologías de virtualización de TI para virtualizar clases enteras de funciones de nodos de red en bloques de construcción que pueden conectarse o encadenarse para crear y entregar servicios de comunicación.
NFV se basa en técnicas tradicionales de virtualización de servidores , como las que se utilizan en TI empresarial. Una función de red virtualizada , o VNF , se implementa dentro de una o más máquinas virtuales o contenedores que ejecutan diferentes software y procesos, además de servidores, conmutadores y dispositivos de almacenamiento comerciales de gran volumen (COTS), o incluso infraestructura de computación en la nube . en lugar de tener dispositivos de hardware personalizados para cada función de red, evitando así la dependencia del proveedor.
Por ejemplo, se podría implementar un controlador de borde de sesión virtual para proteger una red sin el costo y la complejidad típicos de obtener e instalar unidades físicas de protección de red. Otros ejemplos de NFV incluyen balanceadores de carga virtualizados , firewalls , dispositivos de detección de intrusiones y aceleradores WAN , por nombrar algunos. [2]
El desacoplamiento del software de función de red de la plataforma de hardware personalizada genera una arquitectura de red flexible que permite una gestión ágil de la red, implementaciones rápidas de nuevos servicios con una reducción significativa de CAPEX y OPEX.
El desarrollo de productos dentro de la industria de las telecomunicaciones tradicionalmente ha seguido estándares rigurosos de estabilidad, cumplimiento de protocolos y calidad, lo que se refleja en el uso del término grado de operador para designar equipos que demuestran este alto factor de confiabilidad y rendimiento. [3] Si bien este modelo funcionó bien en el pasado, inevitablemente condujo a ciclos de producto largos, un ritmo lento de desarrollo y dependencia de hardware propietario o específico, por ejemplo, circuitos integrados de aplicaciones específicas (ASIC) hechos a medida. Este modelo de desarrollo resultó en retrasos significativos al implementar nuevos servicios, planteó desafíos complejos de interoperabilidad y un aumento significativo en CAPEX/OPEX al escalar los sistemas e infraestructura de red y mejorar las capacidades de servicio de red para satisfacer las crecientes demandas de carga y rendimiento de la red. Además, el aumento de una competencia significativa en las ofertas de servicios de comunicación por parte de organizaciones ágiles que operan a gran escala en la Internet pública (como Google Talk , Skype , Netflix ) ha estimulado a los proveedores de servicios a buscar formas innovadoras de alterar el status quo y aumentar los flujos de ingresos. .
En octubre de 2012, un grupo de operadores de telecomunicaciones publicó un documento técnico [4] en una conferencia en Darmstadt, Alemania , sobre redes definidas por software (SDN) y OpenFlow . El Llamado a la acción que concluye el Libro Blanco condujo a la creación del Grupo de especificación industrial (ISG) de virtualización de funciones de red (NFV) [5] dentro del Instituto Europeo de Normas de Telecomunicaciones (ETSI). El ISG estaba formado por representantes de la industria de las telecomunicaciones de Europa y más allá. [6] [7] ETSI ISG NFV aborda muchos aspectos, incluida la arquitectura funcional, el modelo de información, el modelo de datos, los protocolos, las API, las pruebas, la confiabilidad, la seguridad, las evoluciones futuras, etc.
El ETSI ISG NFV ha anunciado la Versión 5 de sus especificaciones desde mayo de 2021 con el objetivo de producir nuevas especificaciones y ampliar las especificaciones ya publicadas en función de nuevas características y mejoras.
Desde la publicación del documento técnico, el grupo ha producido más de 100 publicaciones, [8] que han ganado una mayor aceptación en la industria y se están implementando en destacados proyectos de código abierto como OpenStack, ONAP, Open Source MANO (OSM), por nombrar algunos. pocos. Debido a las actividades activas de enlace cruzado, también se hace referencia a las especificaciones ETSI NFV en otros SDO como 3GPP, IETF, ETSI MEC, etc.
El marco NFV consta de tres componentes principales: [9]
El componente básico tanto de NFVI como de NFV-MANO es la plataforma NFV. En la función NFVI, consta de recursos de almacenamiento y procesamiento físicos y virtuales, y software de virtualización. En su función NFV-MANO, consta de administradores VNF y NFVI y un software de virtualización que opera en un controlador de hardware . La plataforma NFV implementa funciones de nivel de operador que se utilizan para administrar y monitorear los componentes de la plataforma, recuperarse de fallas y brindar seguridad efectiva, todo lo cual es necesario para la red de operador público.
Un proveedor de servicios que sigue el diseño NFV implementa una o más funciones de red virtualizadas, o VNF . Un VNF por sí solo no proporciona automáticamente un producto o servicio utilizable a los clientes del proveedor. Para crear servicios más complejos, se utiliza la noción de encadenamiento de servicios , donde se utilizan múltiples VNF en secuencia para brindar un servicio.
Otro aspecto de la implementación de NFV es el proceso de orquestación . Para crear servicios altamente confiables y escalables, NFV requiere que la red pueda crear instancias de VNF, monitorearlas, repararlas y (lo más importante para una empresa proveedora de servicios) facturar por los servicios prestados. Estos atributos, denominados características de nivel de operador [11] , se asignan a una capa de orquestación para proporcionar alta disponibilidad y seguridad, y bajos costos de operación y mantenimiento. Es importante destacar que la capa de orquestación debe poder gestionar las VNF independientemente de la tecnología subyacente dentro de la VNF. Por ejemplo, una capa de orquestación debe poder administrar un SBC VNF del proveedor X que se ejecuta en VMware vSphere , así como un IMS VNF del proveedor Y que se ejecuta en KVM.
La percepción inicial de NFV fue que la capacidad virtualizada debería implementarse en los centros de datos. Este enfoque funciona en muchos casos, pero no en todos. NFV supone y enfatiza la mayor flexibilidad posible en cuanto a la ubicación física de las funciones virtualizadas.
Por lo tanto, idealmente las funciones virtualizadas deberían ubicarse donde sean más efectivas y menos costosas. Eso significa que un proveedor de servicios debe tener libertad para ubicar NFV en todas las ubicaciones posibles, desde el centro de datos hasta el nodo de red y las instalaciones del cliente. Este enfoque, conocido como NFV distribuido, se ha enfatizado desde el principio a medida que se desarrollaba y estandarizaba NFV, y se destaca en los documentos NFV ISG publicados recientemente. [12]
En algunos casos, existen claras ventajas para un proveedor de servicios al ubicar esta funcionalidad virtualizada en las instalaciones del cliente. Estas ventajas van desde la economía hasta el rendimiento y la viabilidad de las funciones que se virtualizan. [13]
La primera prueba de concepto (PoC) pública de múltiples proveedores de D-NFV aprobada por ETSI NFV ISG fue realizada por Cyan, Inc. , RAD , Fortinet y Certes Networks en Chicago en junio de 2014, y fue patrocinada por CenturyLink . Se basó en el equipo D-NFV de borde del cliente dedicado de RAD que ejecutaba el firewall de próxima generación (NGFW) de Fortinet y el motor de cifrado/descifrado virtual de Certes Networks como funciones de red virtual (VNF) con el sistema Blue Planet de Cyan orquestando todo el ecosistema. [14] La solución D-NFV de RAD, una unidad de terminación de red (NTU) de Capa 2 / Capa 3 equipada con un módulo de servidor D-NFV X86 que funciona como un motor de virtualización en el borde del cliente, estuvo disponible comercialmente a finales de ese mes. . [15] Durante 2014, RAD también organizó una Alianza D-NFV, un ecosistema de proveedores e integradores de sistemas internacionales especializados en nuevas aplicaciones NFV. [dieciséis]
Al diseñar y desarrollar el software que proporciona los VNF, los proveedores pueden estructurar ese software en componentes de software (vista de implementación de una arquitectura de software) y empaquetar esos componentes en una o más imágenes (vista de implementación de una arquitectura de software). Estos componentes de software definidos por el proveedor se denominan componentes VNF (VNFC). Los VNF se implementan con uno o más VNFC y se supone, sin pérdida de generalidad, que las instancias de VNFC se asignan 1:1 a imágenes de VM.
En general, las VNFC deberían poder ampliarse y/o ampliarse . Al poder asignar CPU flexibles (virtuales) a cada una de las instancias de VNFC, la capa de administración de red puede ampliar (es decir, escalar verticalmente ) la VNFC para proporcionar el rendimiento/rendimiento y las expectativas de escalabilidad en un solo sistema o una sola plataforma. De manera similar, la capa de administración de red puede escalar (es decir, escalar horizontalmente ) una VNFC activando múltiples instancias de dicha VNFC en múltiples plataformas y, por lo tanto, alcanzar las especificaciones de rendimiento y arquitectura sin comprometer las otras estabilidades de las funciones de VNFC.
Los primeros en adoptar dichos proyectos de arquitectura ya han implementado los principios de modularidad de NFV. [17]
La virtualización de funciones de red es altamente complementaria a SDN. [4] En esencia, SDN es un enfoque para construir equipos y software de redes de datos que separa y abstrae elementos de estos sistemas. Para ello, desacopla el plano de control y el plano de datos entre sí, de modo que el plano de control resida centralmente y los componentes de reenvío permanezcan distribuidos. El avión de control interactúa tanto con el rumbo norte como con el rumbo sur . En dirección norte, el plano de control proporciona una vista abstracta común de la red para aplicaciones y programas de nivel superior que utilizan API de alto nivel y paradigmas de gestión novedosos, como las redes basadas en intenciones. En dirección sur, el plano de control programa el comportamiento de reenvío del plano de datos, utilizando API a nivel de dispositivo del equipo de red física distribuido por la red.
Por lo tanto, NFV no depende de los conceptos SDN o SDN, pero NFV y SDN pueden cooperar para mejorar la gestión de una infraestructura NFV y crear un entorno de red más dinámico. Es completamente posible implementar una función de red virtualizada (VNF) como una entidad independiente utilizando paradigmas de orquestación y redes existentes. Sin embargo, existen beneficios inherentes al aprovechar los conceptos de SDN para implementar y administrar una infraestructura NFV, particularmente cuando se analiza la administración y orquestación de servicios de red (NS), compuestos por diferentes tipos de funciones de red (NF), como funciones de red física ( PNF) y VNFs, y colocados entre diferentes infraestructuras NFV geolocalizadas, y por eso se están definiendo plataformas multiproveedor que incorporen SDN y NFV en ecosistemas concertados. [18]
Un sistema NFV necesita un sistema central de orquestación y gestión que tome las solicitudes del operador asociadas con un NS o un VNF y las traduzca en el procesamiento, almacenamiento y configuración de red adecuados necesarios para poner en funcionamiento el NS o VNF. Una vez en funcionamiento, el VNF y las redes a las que potencialmente está conectado deben monitorearse para determinar su capacidad y utilización, y adaptarse si es necesario. [19]
Todas las funciones de control de red en una infraestructura NFV se pueden lograr utilizando conceptos de SDN y NFV podría considerarse uno de los principales casos de uso de SDN en entornos de proveedores de servicios. [20] Por ejemplo, dentro de cada sitio de infraestructura NFV, un VIM podría depender de un controlador SDN para instalar y configurar las redes superpuestas que interconectan (por ejemplo, VXLAN) los VNF y PNF que componen un NS. Luego, el controlador SDN configuraría los conmutadores y enrutadores de la infraestructura NFV, así como las puertas de enlace de la red, según sea necesario. De manera similar, un administrador de infraestructura de área amplia (WIM) podría confiar en un controlador SDN para configurar redes superpuestas para interconectar NS que se implementan en diferentes infraestructuras NFV ubicadas geográficamente. También es evidente que muchos casos de uso de SDN podrían incorporar conceptos introducidos en la iniciativa NFV. Los ejemplos incluyen cuando el controlador centralizado controla una función de reenvío distribuido que, de hecho, también podría virtualizarse en equipos de procesamiento o enrutamiento existentes.
NFV ha demostrado ser un estándar popular incluso en sus inicios. Sus aplicaciones inmediatas son numerosas, como la virtualización de estaciones base móviles , plataforma como servicio (PaaS), redes de entrega de contenidos (CDN), acceso fijo y entornos domésticos. [21] Se prevé que los beneficios potenciales de la NFV serán significativos. Se espera que la virtualización de las funciones de red implementadas en hardware estandarizado de uso general reduzca los gastos operativos y de capital, y los tiempos de introducción de servicios y productos. [22] [23] Muchos proveedores importantes de equipos de red han anunciado soporte para NFV. [24] Esto ha coincidido con anuncios de NFV de importantes proveedores de software que proporcionan las plataformas NFV utilizadas por los proveedores de equipos para construir sus productos NFV. [25] [26]
Sin embargo, para lograr los beneficios previstos de la virtualización, los proveedores de equipos de red están mejorando la tecnología de virtualización de TI para incorporar atributos de nivel de operador necesarios para lograr alta disponibilidad , escalabilidad, rendimiento y capacidades efectivas de gestión de red. [27] Para minimizar el costo total de propiedad (TCO), las características de nivel de operador deben implementarse de la manera más eficiente posible. Esto requiere que las soluciones NFV hagan un uso eficiente de los recursos redundantes para lograr una disponibilidad de cinco nueves (99,999 %), [28] y de los recursos informáticos sin comprometer la previsibilidad del rendimiento.
La plataforma NFV es la base para lograr soluciones NFV eficientes de nivel de operador. [29] Es una plataforma de software que se ejecuta en hardware multinúcleo estándar y está construida con software de código abierto que incorpora características de nivel de operador. El software de la plataforma NFV es responsable de reasignar dinámicamente los VNF debido a fallas y cambios en la carga de tráfico y, por lo tanto, juega un papel importante en el logro de una alta disponibilidad. Hay numerosas iniciativas en marcha para especificar, alinear y promover capacidades de nivel de operador NFV, como ETSI NFV Proof of Concept, [30] ATIS [31] Plataforma abierta para el proyecto NFV, [32] Carrier Network Virtualization Awards [33] y varios proveedores. ecosistemas. [34]
El vSwitch, un componente clave de las plataformas NFV, es responsable de proporcionar conectividad tanto de VM a VM (entre VM) como entre las VM y la red externa. Su rendimiento determina tanto el ancho de banda de los VNF como la rentabilidad de las soluciones NFV. El rendimiento del estándar Open vSwitch (OVS) tiene deficiencias que deben resolverse para satisfacer las necesidades de las soluciones NFVI. [35] Los proveedores de NFV están informando de importantes mejoras de rendimiento para las versiones OVS y Accelerated Open vSwitch (AVS). [36] [37]
La virtualización también está cambiando la forma en que se especifica, mide y logra la disponibilidad en las soluciones NFV. A medida que las VNF reemplazan los equipos tradicionales dedicados a funciones, se produce un cambio de la disponibilidad basada en equipos a un enfoque en capas, de extremo a extremo y basado en servicios. [38] [39] La virtualización de funciones de red rompe el acoplamiento explícito con equipos específicos, por lo que la disponibilidad se define por la disponibilidad de los servicios VNF. Debido a que la tecnología NFV puede virtualizar una amplia gama de tipos de funciones de red, cada una con sus propias expectativas de disponibilidad de servicios, las plataformas NFV deben admitir una amplia gama de opciones de tolerancia a fallas. Esta flexibilidad permite a los CSP optimizar sus soluciones NFV para cumplir con cualquier requisito de disponibilidad de VNF.
ETSI ya ha indicado que una parte importante del control del entorno NFV se realizará mediante orquestación automatizada. NFV Management and Orchestration (NFV-MANO) se refiere a un conjunto de funciones dentro de un sistema NFV para gestionar y orquestar la asignación de recursos de infraestructura virtual a funciones de red virtualizadas (VNF) y servicios de red (NS). Son el cerebro del sistema NFV y un facilitador clave de la automatización.
Los principales bloques funcionales dentro del marco arquitectónico NFV-MANO (ETSI GS NFV-006) son:
El punto de entrada en NFV-MANO para los sistemas de soporte de operaciones externas (OSS) y los sistemas de soporte empresarial (BSS) es el NFVO, que se encarga de gestionar el ciclo de vida de las instancias de NS. La gestión del ciclo de vida de las instancias VNF que constituyen una instancia NS es delegada por la NFVO a uno o más VNFM. Tanto la NFVO como los VNFM utilizan los servicios expuestos por uno o más VIM para asignar recursos de infraestructura virtual a los objetos que administran. Se utilizan funciones adicionales para gestionar VNF en contenedores: las funciones de gestión de servicios de infraestructura de contenedores (CISM) y de registro de imágenes de contenedores (CIR). El CISM es responsable de mantener las cargas de trabajo en contenedores, mientras que el CIR es responsable de almacenar y mantener la información de las imágenes de software del contenedor del sistema operativo. El comportamiento de NFVO y VNFM está impulsado por el contenido de las plantillas de implementación (también conocidas como descriptores de NFV), como un descriptor de servicio de red. (NSD) y un descriptor VNF (VNFD).
ETSI ofrece un conjunto completo de estándares que permiten un ecosistema abierto donde las funciones de red virtualizadas (VNF) pueden ser interoperables con sistemas de gestión y orquestación desarrollados independientemente, y donde los componentes de un sistema de gestión y orquestación son ellos mismos interoperables. Esto incluye un conjunto de especificaciones de Restful API [40] , así como las especificaciones de un formato de empaquetado para entregar VNF a proveedores de servicios y de las plantillas de implementación que se empaquetarán con las imágenes de software para permitir la gestión del ciclo de vida de VNF. Las plantillas de implementación pueden basarse en TOSCA o YANG . [41] [42]
Una representación OpenAPI (también conocida como Swagger) de las especificaciones API está disponible y se mantiene en el servidor forge de ETSI, junto con archivos de definición TOSCA y YANG que se utilizarán al crear plantillas de implementación.
El conjunto completo de especificaciones publicadas se resume en la siguiente tabla.
Una descripción general de las diferentes versiones de las representaciones OpenAPI de las API de NFV-MANO está disponible en la wiki de ETSI NFV.
Los archivos OpenAPI, así como los archivos de definición TOSCA YAML y los módulos YANG aplicables a los descriptores NFV están disponibles en ETSI Forge.
Se están llevando a cabo estudios adicionales dentro del ETSI sobre una posible mejora del marco NFV-MANO para mejorar sus capacidades de automatización e introducir mecanismos de gestión autónomos (ver ETSI GR NFV-IFA 041).
Un estudio de rendimiento reciente sobre NFV se centró en el rendimiento, la latencia y la fluctuación de las funciones de red virtualizadas (VNF), así como en la escalabilidad de NFV en términos de la cantidad de VNF que puede admitir un único servidor físico. [43] Hay plataformas NFV de código abierto disponibles, una de las cuales es openNetVM. [44] openNetVM es una plataforma NFV de alto rendimiento basada en contenedores DPDK y Docker. openNetVM proporciona un marco flexible para implementar funciones de red e interconectarlas para construir cadenas de servicios. openNetVM es una versión de código abierto de la plataforma NetVM descrita en los artículos NSDI 2014 y HotMiddlebox 2016, publicada bajo la licencia BSD. El código fuente se puede encontrar en GitHub:openNetVM [45]
A partir de 2018, muchos proveedores de VNF comenzaron a migrar muchos de sus VNF a una arquitectura basada en contenedores. Estas VNF, también conocidas como funciones de red nativas de la nube (CNF), utilizan muchas innovaciones implementadas comúnmente en la infraestructura de Internet. Estos incluyen el escalado automático, el soporte de un modelo de implementación de DevOps/entrega continua y ganancias de eficiencia al compartir servicios comunes entre plataformas. A través del descubrimiento y la orquestación de servicios, una red basada en CNF será más resistente a fallas de recursos de infraestructura. La utilización de contenedores y, por lo tanto, prescindir de la sobrecarga inherente a la virtualización tradicional mediante la eliminación del sistema operativo invitado puede aumentar en gran medida la eficiencia de los recursos de la infraestructura. [46]
{{cite journal}}: Citar diario requiere |journal=( ayuda )