Virtualización de funciones de red - Network function virtualization

La virtualización de funciones de red (también virtualización de funciones de red o NFV ) es un concepto de arquitectura de red que utiliza las tecnologías de virtualización de TI para virtualizar clases enteras de funciones de nodo de red en bloques de construcción que pueden conectarse o encadenarse para crear servicios de comunicación.

NFV se basa en las técnicas tradicionales de virtualización de servidores, pero se diferencia de ellas, como las que se utilizan en la TI empresarial. Una función de red virtualizada, o VNF, puede consistir en una o más máquinas virtuales o contenedores que ejecutan diferentes software y procesos, además de servidores, conmutadores y dispositivos de almacenamiento estándar de alto volumen, o incluso infraestructura de computación en la nube , en lugar de tener dispositivos de hardware personalizados. para cada función de red.

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 equilibradores de carga virtualizados , firewalls , dispositivos de detección de intrusos y aceleradores de WAN .

Fondo

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 portadora para designar equipos que demuestran esta confiabilidad. Si bien este modelo funcionó bien en el pasado, inevitablemente condujo a ciclos de productos largos, un ritmo lento de desarrollo y dependencia de hardware específico o patentado, por ejemplo, circuitos integrados específicos de aplicación (ASIC) a medida . El aumento de la competencia significativa en los servicios de comunicación de organizaciones en rápido movimiento 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 de alterar el status quo.

Historia

En octubre de 2012, un grupo de operadores de telecomunicaciones publicó un informe técnico en una conferencia en Darmstadt, Alemania , sobre redes definidas por software (SDN) y OpenFlow . El llamado a la acción que concluyó 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) 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á. Desde la publicación del libro blanco, el grupo ha producido más de 100 publicaciones. En 2016, se lanza una versión de código abierto de alto rendimiento de NFV. openNetVM es una plataforma NFV de alto rendimiento basada en contenedores DPDK y Docker.

Marco de referencia

El marco de NFV consta de tres componentes principales:

  1. Las funciones de red virtualizadas (VNF) son implementaciones de software de funciones de red que se pueden implementar en una infraestructura de virtualización de funciones de red (NFVI).
  2. La infraestructura de virtualización de funciones de red (NFVI) es la totalidad de todos los componentes de hardware y software que crean el entorno donde se implementan los NFV. La infraestructura de NFV puede abarcar varias ubicaciones. La red que proporciona conectividad entre estas ubicaciones se considera parte de la infraestructura de NFV.
  3. El marco arquitectónico de gestión y orquestación de virtualización de funciones de red (NFV-MANO Architectural Framework) es la colección de todos los bloques funcionales, repositorios de datos utilizados por estos bloques y puntos de referencia e interfaces a través de los cuales estos bloques funcionales intercambian información con el fin de administrar y orquestar NFVI. y VNF.

El componente básico tanto para NFVI como para NFV-MANO es la plataforma NFV. En el rol de NFVI, consta de recursos de almacenamiento y procesamiento virtuales y físicos, y software de virtualización. En su función NFV-MANO, consta de administradores VNF y NFVI y software de virtualización que operan en un controlador de hardware . La plataforma NFV implementa características 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.

Aspectos prácticos

Un proveedor de servicios que sigue el diseño de 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 construir servicios más complejos, se usa la noción de encadenamiento de servicios , donde se usan múltiples VNF en secuencia para brindar un servicio.

Otro aspecto de la implementación de NFV es el proceso de orquestación . Para construir 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, 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 administrar los VNF independientemente de la tecnología subyacente dentro del VNF. Por ejemplo, una capa de orquestación debe poder administrar un SBC VNF del proveedor X que se ejecuta en VMware vSphere tan bien como un IMS VNF del proveedor Y que se ejecuta en KVM.

NFV distribuido

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 presume 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 la libertad de 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, ha sido enfatizado desde el principio a medida que se estaba desarrollando y estandarizando NFV, y es prominente en los documentos NFV ISG publicados recientemente.

En algunos casos, existen claras ventajas para que un proveedor de servicios ubique 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.

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 dedicado al cliente de RAD que ejecuta el cortafuegos 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 que orquesta todo el ecosistema. 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. Durante 2014, RAD también había organizado una D-NFV Alliance, un ecosistema de proveedores e integradores de sistemas internacionales que se especializan en nuevas aplicaciones de NFV.

Beneficios de la modularidad NFV

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 asume, sin pérdida de generalidad, que las instancias de VNFC se asignan 1: 1 a imágenes de VM.

En general, los 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 escalar (es decir, escalar verticalmente ) el 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 horizontalmente (es decir, escalar horizontalmente ) un VNFC activando múltiples instancias de dicho 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 planos de arquitectura ya han implementado los principios de modularidad de NFV.

Relación con SDN

SDN, o redes definidas por software , es un concepto relacionado con NFV, pero se refieren a dominios diferentes. La virtualización de funciones de red (NFV) y la inspección profunda de paquetes (DPI) podrían complementar de manera eficiente las funciones de SDN.

En esencia, las redes definidas por software (SDN) son un enfoque para construir equipos y software de redes de datos que separan y abstraen 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 resida de forma centralizada y los componentes de reenvío permanezcan distribuidos. El plano de control interactúa tanto hacia el norte y hacia el sur . En la 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. En la 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. 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 SDN para implementar y administrar una infraestructura NFV, particularmente cuando se mira la administración y orquestación de VNF, y es por eso que se están definiendo plataformas de múltiples proveedores que incorporan SDN y NFV en ecosistemas concertados.

Una infraestructura de NFV necesita un sistema de gestión y orquestación central que toma las solicitudes del operador asociadas con un VNF y las traduce en el procesamiento, almacenamiento y configuración de red adecuados necesarios para poner en funcionamiento el VNF. Una vez en funcionamiento, el VNF potencialmente debe ser monitoreado para determinar su capacidad y utilización, y adaptarse si es necesario.

Todas estas funciones se pueden lograr utilizando conceptos SDN y NFV podría considerarse uno de los casos de uso primarios de SDN en entornos de proveedores de servicios. 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 está controlando una función de reenvío distribuido que, de hecho, también podría virtualizarse en equipos de procesamiento o enrutamiento existentes.

Impacto de la industria

NFV ha demostrado ser un estándar popular incluso en su infancia. Sus aplicaciones inmediatas son numerosas, como la virtualización de estaciones base móviles , plataforma como servicio (PaaS), redes de entrega de contenido (CDN), acceso fijo y entornos domésticos. Se prevé que los beneficios potenciales de NFV serán significativos. Se espera que la virtualización de las funciones de red implementadas en hardware estandarizado de propósito general reduzca los gastos operativos y de capital, y los tiempos de introducción de servicios y productos. Muchos de los principales proveedores de equipos de red han anunciado su compatibilidad con NFV. 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.

Sin embargo, para obtener los beneficios anticipados de la virtualización, los proveedores de equipos de red están mejorando la tecnología de virtualización de TI para incorporar los atributos de nivel de operador necesarios para lograr alta disponibilidad , escalabilidad, rendimiento y capacidades de administración de red efectivas. 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%) y de los recursos informáticos sin comprometer la predictibilidad del rendimiento.

La plataforma NFV es la base para lograr soluciones NFV de nivel de operador eficientes. Es una plataforma de software que se ejecuta en hardware estándar de varios núcleos y se construye 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 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, ATIS Open Platform for NFV Project, Carrier Network Virtualization Awards y varios ecosistemas de proveedores.

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 los VNF como la rentabilidad de las soluciones NFV. El rendimiento estándar de Open vSwitch (OVS) tiene deficiencias que deben resolverse para satisfacer las necesidades de las soluciones NFVI. Los proveedores de NFV están notificando mejoras significativas en el rendimiento para las versiones de OVS y Accelerated Open vSwitch (AVS).

La virtualización también está cambiando la forma disponibilidad se especifica, se mide y lograrse en soluciones NFV. A medida que los 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. La virtualización de las 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 uno 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 VNF.

Gestión y orquestación (MANO)

La ETSI ya ha indicado que una parte importante del control del entorno de NFV se realiza a través de la automatización y la orquestación. Hay una secuencia MANO separada dentro de NFV que describe cómo se debe controlar la flexibilidad.

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 de forma independiente, y donde los componentes de un sistema de gestión y orquestación son interoperables. Esto incluye un conjunto de especificaciones de la API Restful , 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 administración del ciclo de vida de VNF. Las plantillas de implementación pueden basarse en TOSCA o YANG .

Una representación OpenAPI (también conocida como Swagger) de las especificaciones de la API está disponible en el servidor de forja ETSI , junto con los archivos de definición de 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.

Especificación Título
ETSI GS NFV-SOL 001 Descriptores de NFV basados ​​en la especificación TOSCA
ETSI GS NFV-SOL 002 Especificación de protocolos RESTful para el punto de referencia Ve-Vnfm
ETSI GS NFV-SOL 003 Especificación de protocolos RESTful para el punto de referencia Or-Vnfm
ETSI GS NFV-SOL 004 Paquete VNF y especificación de archivo PNFD
ETSI GS NFV-SOL 005 Especificación de protocolos RESTful para el punto de referencia Os-Ma-nfvo
ETSI GS NFV-SOL 006 Descriptores de NFV basados ​​en la especificación YANG
ETSI GS NFV-SOL 007 Especificación de la estructura de archivos del descriptor de servicio de red
ETSI GS NFV-SOL 009 Especificación de protocolos RESTful para la gestión de NFV-MANO
ETSI GS NFV-SOL 010 Especificación del paquete de instantáneas de VNF
ETSI GS NFV-SOL 011 Especificación de protocolos RESTful para el punto de referencia Or-Or
ETSI GS NFV-SOL 012 Especificación de protocolos RESTful para la interfaz de gestión de políticas
ETSI GS NFV-SOL 013 Especificación de aspectos comunes para las API RESTful NFV MANO
ETSI GS NFV-SOL 014 Especificación del modelo de datos YAML para la gestión de recursos virtualizados basada en descriptores
ETSI GS NFV-SOL 015 Especificación de patrones y convenciones para las API RESTful NFV-MANO
ETSI GS NFV-SOL 016 Especificación de procedimientos NFV-MANO

Una descripción general de las diferentes versiones de las representaciones de 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 de TOSCA YAML y los módulos YANG aplicables a los descriptores de NFV están disponibles en ETSI Forge .

Estudio de desempeño

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 la escalabilidad de NFV en términos de la cantidad de VNF que puede admitir un solo servidor físico. Las plataformas NFV de código abierto están disponibles, un representante es openNetVM. 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 documentos NSDI 2014 y HotMiddlebox 2016, publicada bajo la licencia BSD. El código fuente se puede encontrar en github: openNetVM

Funciones de red nativas de la nube

En 2018, muchos proveedores de infraestructura comenzaron a migrar muchos de sus VNF a una arquitectura basada en contenedores. Estas funciones de red nativas de la nube utilizan muchas de las mismas innovaciones que se implementan comúnmente en la infraestructura de Internet. Estos incluyen escalado automático, soporte de un modelo de implementación de entrega continua / DevOps y ganancias de eficiencia al compartir servicios comunes entre plataformas. A través del descubrimiento y la orquestación de servicios, un sistema basado en CNF será más resistente a fallas en los nodos. 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 enormemente la eficiencia de los recursos.

Ver también

Referencias

enlaces externos