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 brindar servicios de comunicación.
La NFV se basa en técnicas tradicionales de virtualización de servidores , como las que se utilizan en la 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 programas y procesos, sobre servidores, conmutadores y dispositivos de almacenamiento de gran volumen listos para usar (COTS) comerciales, o incluso sobre una infraestructura de computación en la nube , en lugar de tener dispositivos de hardware personalizados para cada función de red, lo que evita la dependencia de un 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 de protección de red físicas. Otros ejemplos de NFV incluyen balanceadores de carga virtualizados , firewalls , dispositivos de detección de intrusiones y aceleradores de WAN , por nombrar algunos. [2]
La disociación 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 y la rápida implementación de nuevos servicios con una reducción significativa de CAPEX y OPEX.
El desarrollo de productos dentro de la industria de las telecomunicaciones ha seguido tradicionalmente estándares rigurosos de estabilidad, adherencia al protocolo y calidad, reflejados por 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 largos ciclos de productos, un ritmo lento de desarrollo y dependencia de hardware propietario o específico, por ejemplo, circuitos integrados específicos de la aplicación (ASIC) hechos a medida. Este modelo de desarrollo resultó en demoras significativas 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 la competencia significativa en las ofertas de servicios de comunicación de organizaciones ágiles que operan a gran escala en la Internet pública (como Google Talk , Skype , Netflix ) ha impulsado 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 libro blanco [4] en una conferencia en Darmstadt, Alemania , sobre redes definidas por software (SDN) y OpenFlow . La convocatoria de acción que concluía el libro blanco condujo a la creación del Grupo de Especificación de la Industria de Virtualización de Funciones de Red (NFV) (ISG) [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, incluyendo la arquitectura funcional, el modelo de información, el modelo de datos, los protocolos, las API, las pruebas, la fiabilidad, la seguridad, las futuras evoluciones, 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 basándose en nuevas características y mejoras.
Desde la publicación del libro blanco, 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 importantes proyectos de código abierto como OpenStack, ONAP, Open Source MANO (OSM), por nombrar algunos. Debido a las actividades de enlace cruzado activas, las especificaciones NFV de ETSI también se están haciendo referencia en otras 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 el rol de NFVI, consta de recursos de procesamiento y almacenamiento virtuales y físicos, y software de virtualización. En su rol de NFV-MANO, consta de administradores de VNF y NFVI y software de virtualización que operan 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 pública de operadores.
Un proveedor de servicios que sigue el diseño NFV implementa una o más funciones de red virtualizadas, o VNF . Una VNF por sí sola no proporciona automáticamente un producto o servicio utilizable a los clientes del proveedor. Para crear servicios más complejos, se utiliza el concepto de encadenamiento de servicios , en el que se utilizan varias VNF en secuencia para prestar 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 un negocio de proveedores de servicios) facturar los servicios prestados. Estos atributos, conocidos como características de nivel de operador [11] , se asignan a una capa de orquestación para brindar alta disponibilidad y seguridad, y bajos costos de operación y mantenimiento. Es importante destacar que la capa de orquestación debe poder administrar las VNF independientemente de la tecnología subyacente dentro de la VNF. Por ejemplo, una capa de orquestación debe poder administrar una VNF SBC del proveedor X que se ejecuta en VMware vSphere tan bien como una VNF IMS del proveedor Y que se ejecuta en KVM.
La percepción inicial de NFV era que la capacidad virtualizada debía implementarse en los centros de datos. Este enfoque funciona en muchos casos, pero no en todos. NFV presupone y enfatiza la mayor flexibilidad posible en cuanto a la ubicación física de las funciones virtualizadas.
Por lo tanto, lo ideal sería que las funciones virtualizadas se ubicaran donde sean más efectivas y menos costosas. Esto significa que un proveedor de servicios debería tener la libertad de ubicar la 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 distribuida, se ha enfatizado desde el principio a medida que se desarrollaba y estandarizaba la NFV, y es prominente en los documentos ISG de NFV publicados recientemente. [12]
En algunos casos, para un proveedor de servicios, ubicar esta funcionalidad virtualizada en las instalaciones del cliente presenta claras ventajas, que van desde la economía y el rendimiento hasta la viabilidad de las funciones que se virtualizan. [13]
La primera prueba de concepto (PoC) pública de múltiples proveedores 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 dedicado al borde del cliente de RAD que ejecuta 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 fines 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. [16]
Al diseñar y desarrollar el software que proporciona las 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). Las VNF se implementan con una o más VNFC y se supone, sin pérdida de generalidad, que las instancias de VNFC se asignan 1:1 a las imágenes de VM.
En general, las VNFC deberían poder escalarse verticalmente o horizontalmente . Al poder asignar CPU flexibles (virtuales) a cada una de las instancias de VNFC, la capa de administración de red puede escalar verticalmente (es decir, escalar verticalmente ) la VNFC para proporcionar las expectativas de rendimiento y escalabilidad en un solo sistema o una sola plataforma. De manera similar, la capa de administración de red puede escalar horizontalmente (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 la estabilidad de otras funciones de VNFC.
Los primeros en adoptar estos modelos 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. Lo hace desacoplando el plano de control y el plano de datos entre sí, de modo que el plano de control reside centralmente y los componentes de reenvío permanecen distribuidos. El plano de control interactúa tanto con el norte como con el sur . En la dirección norte, el plano de control proporciona una vista abstracta común de la red a aplicaciones y programas de nivel superior que utilizan API de alto nivel y paradigmas de gestión novedosos, como la red basada en intenciones. En la dirección sur, el plano de control programa el comportamiento de reenvío del plano de datos, utilizando API de nivel de dispositivo del equipo de red física distribuido por la red.
Por lo tanto, la virtualización de las funciones de red (NFV) no depende de las funciones de red definidas por software (SDN) ni de los conceptos de SDN, sino que ambas pueden cooperar para mejorar la gestión de una infraestructura de NFV y crear un entorno de red más dinámico. Es totalmente posible implementar una función de red virtualizada (VNF) como una entidad independiente utilizando paradigmas de red y orquestación existentes. Sin embargo, existen beneficios inherentes en el aprovechamiento de los conceptos de SDN para implementar y gestionar una infraestructura de NFV, en particular cuando se analiza la gestión y orquestación de los servicios de red (NS), compuestos por diferentes tipos de funciones de red (NF), como las funciones de red física (PNF) y las VNF, y colocados entre diferentes infraestructuras de NFV geolocalizadas, y es por eso que se están definiendo plataformas de múltiples proveedores que incorporan SDN y NFV en ecosistemas concertados. [18]
Un sistema NFV necesita un sistema central de orquestación y gestión que reciba las solicitudes de los operadores asociadas con un NS o un VNF, las traduzca al procesamiento, almacenamiento y configuración de red adecuados necesarios para poner en funcionamiento el NS o el VNF. Una vez en funcionamiento, el VNF y las redes a las que está conectado deben ser monitoreadas potencialmente para determinar su capacidad y utilización, y adaptadas si es necesario. [19]
Todas las funciones de control de red en una infraestructura NFV se pueden lograr utilizando conceptos 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 configurar las redes superpuestas que interconectan (por ejemplo, VXLAN) las VNF y PNF que componen un NS. El controlador SDN luego configuraría los conmutadores y enrutadores de infraestructura NFV, así como las puertas de enlace de red, según sea necesario. De manera similar, un administrador de infraestructura de área amplia (WIM) podría depender de un controlador SDN para configurar redes superpuestas para interconectar NS que se implementan en diferentes infraestructuras NFV geolocalizadas. También es evidente que muchos casos de uso de SDN podrían incorporar conceptos introducidos en la iniciativa NFV. Los ejemplos incluyen donde 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.
La 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 , la plataforma como servicio (PaaS), las redes de distribución de contenido (CDN), el acceso fijo y los entornos domésticos. [21] Se prevé que los beneficios potenciales de la NFV sean significativos. Se espera que la virtualización de las funciones de red implementadas en hardware estandarizado de uso general reduzca los gastos de capital y operativos, y los tiempos de introducción de servicios y productos. [22] [23] Muchos de los principales proveedores de equipos de red han anunciado su apoyo a la NFV. [24] Esto ha coincidido con los anuncios de NFV de los principales proveedores de software que proporcionan las plataformas NFV utilizadas por los proveedores de equipos para construir sus productos NFV. [25] [26]
Sin embargo, para obtener 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 de gestión de red efectivas. [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 se creó utilizando 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 las VNF debido a fallas y cambios en la carga de tráfico y, por lo tanto, juega un papel importante para lograr una alta disponibilidad. Hay numerosas iniciativas en marcha para especificar, alinear y promover las capacidades de nivel de operador de NFV, como ETSI NFV Proof of Concept, [30] ATIS [31] Open Platform for NFV Project, [32] Carrier Network Virtualization Awards [33] y varios ecosistemas de proveedores. [34]
El vSwitch, un componente clave de las plataformas NFV, es responsable de proporcionar conectividad tanto de VM a VM (entre VM) como entre VM y la red externa. Su rendimiento determina tanto el ancho de banda de las VNF como la relación coste-eficacia 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 mejoras significativas en el rendimiento tanto para las versiones OVS como para las 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 a 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 basado en servicios. [38] [39] La virtualización de funciones de red rompe el acoplamiento explícito con equipos específicos, por lo tanto, 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 servicio, 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 puede realizar mediante orquestación automatizada. La gestión y orquestación de NFV (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 habilitador 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 sistemas de soporte de operaciones externas (OSS) y sistemas de soporte de negocios (BSS) es el NFVO, que está a cargo de administrar el ciclo de vida de las instancias NS. La administración del ciclo de vida de las instancias VNF que constituyen una instancia NS es delegada por el NFVO a uno o más VNFM. Tanto el NFVO como los VNFM usan 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 administrar VNF en contenedores: las funciones Container Infrastructure Service Management (CISM) y Container Image Registry (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 de contenedores del SO. El comportamiento del NFVO y VNFM está impulsado por el contenido de las plantillas de implementación (también conocidas como descriptores NFV) como un Network Service Descriptor (NSD) y un VNF Descriptor (VNFD).
ETSI ofrece un conjunto completo de estándares que permiten un ecosistema abierto en el que las funciones de red virtualizadas (VNF) pueden ser interoperables con sistemas de gestión y orquestación desarrollados de forma independiente, y en el que los componentes de un sistema de gestión y orquestación son en sí mismos interoperables. Esto incluye un conjunto de especificaciones de API Restful [40], así como las especificaciones de un formato de empaquetado para entregar VNF a los 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 las 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 de API está disponible y se mantiene en el servidor ETSI forge, 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 NFV-MANO está disponible en la wiki 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 realizando estudios adicionales dentro del ETSI sobre la posible mejora del marco NFV-MANO para mejorar sus capacidades de automatización e introducir mecanismos de gestión autónoma (consulte ETSI GR NFV-IFA 041).
Un estudio reciente sobre el rendimiento de 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 solo 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 muchas 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. Estas incluyen escalabilidad automática, compatibilidad con 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 las fallas de los recursos de la infraestructura. El uso de contenedores y, por lo tanto, la eliminación de la sobrecarga inherente a la virtualización tradicional mediante la eliminación del sistema operativo invitado pueden aumentar en gran medida la eficiencia de los recursos de la infraestructura. [46]
{{cite journal}}: Requiere citar revista |journal=( ayuda )