Servicios personalizados
Español (pdf)
Articulo en XML
Referencias del artículo
Enviar articulo por email
Citado por SciELO 
Similares en
SciELO 
Permalink
Introducción
La infraestructura actual de la Tecnología de la Información y la Comunicación está evolucionando hacia la virtualización con el propósito de reducir costos en la instalación y el mantenimiento de dispositivos de hardware dedicado, así como para cumplir la demanda en términos de flexibilidad y escalabilidad para los servicios que se implementan en las redes.
La virtualización implica la abstracción de los recursos de computación entre el hardware de la máquina física y el software o sistema operativo de la máquina virtual. Permite ejecutar varias máquinas virtuales en un mismo hardware, compartiendo recursos y con la posibilidad de asignarlos de manera dinámica a cada máquina, lo que permite que cada una funcione de manera autónoma. La Virtualización de Funciones de Red (NFV, de Network Function Virtualization) es una iniciativa para virtualizar servicios de red (NS, de Network Service) que ha alcanzado gran auge en los últimos años debido a que representa la transferencia de funciones de red, desde proveedores específicos y hardware propietario, a software hospedado en sistemas de propósito general (COTS). La NFV es una tecnología relevante para los proveedores de servicios de internet por varias razones. Primero que todo, tiene el potencial de permitir una reducción de los costos en la inversión (CapEx) y en la operación de las redes (OPEX); así como un incremento de su velocidad de expansión. Además, permite incrementar la flexibilidad de la red para la entrega rápida de servicios, una opción difícil de alcanzar con los métodos tradicionales.
Los administradores de centros de datos y proveedores de servicios de telecomunicaciones están cada vez más interesados en la realización de pruebas de pre-despliegue a la NFV, que no es más que la evaluación y caracterización del rendimiento de la red virtual antes de optar por grandes despliegues [1]. Para lograr esto, se han desarrollado plataformas de pruebas cuyo objetivo es la evaluación del correcto funcionamiento de la NFV. Los proveedores de servicios de telecomunicaciones deben ser capaces de validar su posible implementación de NFV en diferentes tipos de entornos de virtualización, comparar el rendimiento con disímiles orquestadores, gestores de funciones de red virtualizada (VNFM), e integrar las pruebas con componentes específicos. Además, necesitan tener cierto nivel de confianza en el código proveído por terceros para tener seguridad de que las Funciones de Red Virtualizadas (VNFs, de Virtual Network Function) y los NS se comportarán como se espera inmediatamente después de que se implementen y pongan en producción. Actualmente, en el mercado existen plataformas de prueba para la NFV proporcionados por los principales fabricantes de tecnologías como CISCO, Huawei, entre otros; así como plataformas de código abierto y modelos de negocio enfocados en esa dirección; no obstante, proveedores de servicios de telecomunicaciones, como ETECSA, que cuentan con una infraestructura de recursos estratégicos, y que deben adquirir estas tecnologías, también requieren tener plataformas de prueba propias en sus centros de datos para validar implementaciones de NFV. Basado en la problemática anterior se propuso como objetivo del presente trabajo proponer plataformas de pruebas de pre-despliegue de NFV, de código abierto para el proveedor de servicio.
La contribución principal del presente trabajo es una selección de plataformas de prueba de código abierto para los sistemas bajo prueba, considerando la arquitectura de la Virtualización de las Funciones de Red (NFV) y lo reflejado en la literatura internacional. Estas plataformas son necesarias para realizar pruebas de pre-despliegue en las redes de operadores de telecomunicaciones que empleen NFV.
En la primera parte del artículo se presenta una breve revisión de los fundamentos teóricos de la NFV. En la segunda parte se exponen las consideraciones generales que se tuvieron en cuenta para seleccionar las plataformas de prueba, además de una selección de estas divididas en los sistemas bajo prueba de la NFV. Finalmente, se realiza una validación de la propuesta realizada a través de dos casos de uso de despliegue de las plataformas de prueba de NFV.
2.- Selección de plataformas de prueba para la nfv
La virtualización de funciones de red apunta a la transformación de la forma en la que los operadores de red diseñan las redes, a través de la evolución de las tecnologías de virtualización para consolidar muchos tipos de equipos de red en servidores estándar de altas capacidades, que podrían ubicarse en centros de datos, nodos de red y en las instalaciones del usuario final. De acuerdo con el modelo referencial del ETSI [2], la arquitectura NFV está compuesta por tres bloques funcionales: la infraestructura de NFV (NFVI, de NFV Infrastructure), las VNFs y la orquestación y gestión de la NFV (NFV MANO, de NFV Management and Orchestration) como muestra la figura 1. Esta última, se compone por los bloques de gestor de infraestructura virtualizada (VIM), Gestor de VNF (VNFM, de Virtual Network Functions Manager) y Orquestación de la NFV (NFVO). Para la investigación que se llevó a cabo fue de gran importancia analizar los principales gestores de infraestructura virtual (VIM) de código abierto utilizados a nivel mundial. Se analizaron las plataformas OpenStack [3], OpenVIM y CloudStack [4, 5, 6] por constituir VIMs ampliamente utilizados para la NFV.
Cómo en el presente trabajo se realiza la selección de plataformas de prueba de código abierto para la NFV enfocadas en las pruebas de pre-despliegue ampliamente solicitadas por los proveedores de servicios, se analizaron un conjunto de proyectos y modelos de negocio enfocados a la realización de pruebas a la NFV (Plataforma de prueba de CNLabs, Spirent Velocity, IXIA, Open Lab de Huawei, Laboratorio de Referencia de Telefónica), así como plataformas de código abierto (Gym [7], Tng-bench [8], proyectos de la Fundación Linux: OPNFV [9]). Se partió de un conjunto de consideraciones generales para la correcta selección de estas plataformas y se eligió el gestor de infraestructura virtual a emplear en el despliegue de las plataformas de prueba según los sistemas bajo prueba que se analizan.
2.1- Consideraciones sobre las plataformas de prueba para la nfv
Previo a la selección de las plataformas de prueba se hace necesario contar con el despliegue de una NFV. Actualmente existen proyectos enfocados en este sentido que cubren las diferentes partes de la arquitectura como es el caso de OSM, ONAP y SONATA que poseen implementaciones de NFVM y NFVO de código abierto [10,11]; además, OPNFV permite desplegar NFVI y proyectos como OpenStack, OpenVIM proveen VIM. Estos son de gran importancia en la evolución de las implementaciones de código abierto de la NFV.
En la presente investigación se analizaron las plataformas existentes y se seleccionaron las adecuadas para realizar pruebas de pre-despliegue las cuales, además, deben cubrir las necesidades de los proveedores de servicio de telecomunicaciones de ser capaces de evaluar y caracterizar los sistemas bajo prueba antes de pasar a producción. Bajo este criterio se descartaron las plataformas de GIM y TNGBENCH, por ser plataformas enfocadas solamente a pruebas de investigación. Del mismo modo, según la bibliografía consultada, existen plataformas propietarias que requieren de pago y se desconoce el código y modelos de negocios que brindan el servicio de realización de pruebas en sus propios laboratorios, lo que puede no ser conveniente para infraestructuras de proveedores de red que posean recursos estratégicos cuya información no puede ser divulgada. Esto llevó a que se descartaran las siguientes plataformas: Spirent Velocity, CNLabs, NFV/SDN Open Lab de Huawei, los laboratorios de IXIA, y los de Referencia de NFV de Telefónica. Para la validación y la verificación de las VNF y los NS se analizaron dos plataformas, VTP (VNF Test Platform) de ONAP y el proyecto 5GTANGO, que cumplen los requerimientos del proveedor de servicio y son plataformas de código abierto. Basados en el alcance de cada plataforma, su documentación y soporte, etc. se seleccionará con posterioridad la más adecuada.
Se definieron los sistemas bajo prueba para los que se seleccionaron las plataformas de prueba: VIM, NFVI, VNF/NS. No fueron considerados los sistemas bajo prueba del NFVM y del NFVO porque en la bibliografía revisada no se encontraron las plataformas necesarias para su evaluación. Asimismo, se seleccionaron las plataformas de prueba acordes con las necesidades de cada sistema bajo prueba (SUT, de System Under Test).
2.2- Selección del VIM
Entre los gestores de infraestructura de NFV existentes en el mercado, se consideró OpenStack la solución de VIM adecuada para esta investigación por sus fortalezas. Entre estas se encuentran que OpenStack posee interfaces estandarizadas entre los elementos de la NFV y la infraestructura y que es una arquitectura conectable con APIs (Interfaz de Programación de Aplicaciones) documentadas, UIs (Interfaz de Usuario), servicios compartidos, opciones automatizadas para las VNFs y otras funciones de integración. Además, posee complementos y controladores de red comercial y de código abierto populares y cuenta con una comunidad global sobresaliente que contribuye a un rápido ritmo de innovación, trabajando en requisitos únicos de NFV a la que pertenecen usuarios, comunidades relacionadas y organizaciones de estándares. Desde el año 2013, se producen lanzamiento de nuevas funciones para NFV en las versiones de OpenStack [12].
Al analizar a OpenStack como un gestor de infraestructura adecuado para esta investigación, también se tuvo en cuenta: la valoración de las empresas, su adopción rápida, sus múltiples beneficios y el fuerte compromiso de la comunidad, etc. Esto se puede apreciar en los resultados presentados, en octubre de 2016, de la encuesta conducida por Heavy Reading [13] y oficiada por la Fundación OpenStack, que ofrecen una mirada al gran despliegue que ha tenido este gestor, lo que representa, en opinión de las autoras, un punto importante a considerar porque si se seleccionan plataformas de prueba para un gestor de infraestructura ampliamente desplegado y con gran aceptación, se estarían logrando avances en la realización de pruebas al VIM. En la mencionada encuesta se explora el uso actual y los planes de adopción de los Proveedores de Servicios de Comunicaciones (CSP, Communications Service Providers) particularmente con respecto a NFV, 5G y nubes empresariales. Al respecto el encuestador recibió 113 respuestas de representantes de empresas de telecomunicaciones de todo el mundo (54% de los EEUU, 14,2% de Europa, 11,5 % de la región de Asia Pacífico, 8,9 % de América Central, Sudamérica y Canadá; y 2,7% de Medio Oriente) y el 85.6% considera que OpenStack es esencial o importante para su éxito. Además, que la industria de las telecomunicaciones está adoptando rápidamente a OpenStack para la NFV (60,3% lo utilizan o lo prueban, 37,8% lo está considerando para un total de 98,1% de los encuestados). A su vez, 73,5% de los encuestados está comprometido con OpenStack, principalmente contribuyendo con el software, y con los requisitos y casos de uso de NFV.
OpenStack constituye, según se expone en la literatura revisada, una de las soluciones de código abierto más óptima y robusta, y una de sus características más relevantes es su simplicidad. Otro de los motivos para la selección OpenStack es su diseño modular, que permite instalar los módulos en un único host o por separado, lo que dependerá del tamaño y el objetivo de la nube. Para entornos de pruebas lo usual es realizar la instalación en un único nodo. Adicionalmente, OpenStack controla y administra los recursos de computación, almacenamiento y red de la NFVI.
2.3- Selección de plataformas de prueba para el sistema bajo prueba NFVI
Para la realización de las pruebas a la capa de NFVI se escogieron plataformas de prueba de OPNFV. Las razones de esta selección son varias: destacan por ser plataformas de código abierto con una gran comunidad de desarrollo y en ocasiones ampliamente compatible con las pruebas de referencia de la ETSI, y cuentan con un grupo de pruebas que evalúan el SUT según el estándar de ETSI GS NFV-TST001. Además, las plataformas de prueba de OPNFV se encuentran bien documentadas y permiten la evaluación de la infraestructura de NFV que es gestionada por OpenStack.
Considerando las razones expuestas se seleccionaron las plataformas de pruebas de OPNFV Yardstick, Qtip, VSperf, Bottlenecks y NFVBench, estas últimas utilizadas como plugins de Yardstick (Figura 1).
Se seleccionó Yardstick debido a que permite verificar el cumplimiento de la infraestructura de NFV, desde la perspectiva de una VNF. Qtip se utiliza para la evaluación comparativa de rendimiento de la NFVI y VSperf para la evaluación de rendimiento del plano de datos de NFVI. Estas plataformas fueron seleccionadas como plugins de la plataforma Yardstick en aras de mantener la sencillez del diseño.
A su vez, Bottlenecks se utiliza para encontrar cuellos de botella en el sistema bajo prueba antes de comprometerse con un entorno de producción; mientras que NFVBench permite medir de forma automatizada el rendimiento de la red para los flujos de paquetes más comunes del plano de datos.
2.4- Selección de plataformas de prueba para el sistema bajo prueba VIM
Al constituir OpenStack un gestor de infraestructura virtual versátil y ser ampliamente utilizado en la industria de las telecomunicaciones se considera de importancia la realización de pruebas que permitan la validación del correcto funcionamiento de este VIM. Para esto se seleccionaron las plataformas Functest, dirigida principalmente a las pruebas funcionales en OpenStack, y Storperf para la evaluación comparativa de rendimiento de almacenamiento para OpenStack.
2.5- Selección de plataformas de prueba para el sistema bajo prueba VNF y NS
Del análisis del proyecto de VTP y de 5GTANGO (software SONATA) se puede obtener que la validación y verificación de servicios de red de terceros sobre infraestructuras operativas permiten garantizar la confiabilidad en implementaciones de nivel de operador. Tanto el proyecto VTP de ONAP como el de 5GTANGO están creando un programa para garantizar la interoperabilidad de los VNF y NS. Dado que este resulta un tema decisivo, ETSI NFV ISG ha publicado una serie de documentos que proporcionan una metodología para la validación y pruebas previas despliegue del servicio [14, 15, 16].
Un problema presente es la falta de estandarización de la notación y descripción de la prueba de validación y verificación. Las soluciones de orquestación como 5GTANGO u OSM basan sus modelos de descriptores en las especificaciones de ETSI [15], mientras que la plataforma de automatización de red abierta (ONAP) se basa en TOSCA.
En cuanto a la estandarización, TOSCA especifica el formato de archivo de servicio en la nube (CSAR), que es un formato genérico para empaquetar todo tipo de aplicaciones en la nube, incluidos VNF y NS. Sin embargo, el formato CSAR es demasiado impreciso para muchos casos de uso de NFV, por lo que ETSI especifica un formato de paquete extendido para VNF[15]. Por su parte, el proyecto 5GTANGO especifica una versión extendida del formato de paquete de ETSI para no solo incluir VNF y NS en un solo paquete, sino también para poder agruparlos con un conjunto de escenarios de prueba que pueden ser utilizados por su plataforma de validación (V&V) [17].
Analizando lo anteriormente expuesto se seleccionó para la realización de las pruebas a las VNFs y los NS, la plataforma SONATA V&V que utiliza la MANO SONATA como orquestador y como modelo de descriptores los basados en el estándar ETSI (Figura 3).
Como se plantea en la bibliografía [19], SONATA es un orquestador que ha tenido gran influencia en el ecosistema de NFV. Debido a su enfoque en las redes 5G se ha desarrollado como un orquestador capaz de manejar los cada vez más complejos servicios asociados a esta tecnología. La naturaleza de código abierto de SONATA y su comunidad la ha llevado a ser una fuerte solución para la Gestión y Orquestación de NFV. El último lanzamiento de SONATA fue la versión 5.1, disponible libremente para descargar y listo para ser instalado. Es una solución que trabaja activamente en colaboración con otros proyectos de código abierto cómo es el caso de OSM.
Es importante destacar que las VNF y las NS están asociadas al descriptor y por ende al orquestador para el cual fueron creadas, por lo que existe una gran dependencia entre las capas de la arquitectura VNFs y MANO. Las MANOs disponibles no implementan el estándar en [15] completamente, por lo que existe incompatibilidad entre los descriptores de diferentes orquestadores, entonces, depende de para qué MANO esté hecha el descriptor de VNF que se necesite probar (ONAP, OSM, SONATA)[20].
Por otra parte, el módulo de validación y verificación de 5GTANGO puede ser usado para validar VNFs y NSs, pero estas deben ser empaquetadas usando los descriptores de 5GTANGO [21]. El proveedor de servicio necesita evaluar no solo las VNFs empaquetadas por los descriptores de 5GTANGO. Ante este inconveniente se analizó una posible solución a este problema, que, aunque pudiera tener sus limitaciones para casos particulares, constituye una alternativa prometedora. La propuesta es utilizar la posibilidad que brindan gran cantidad de vendedores que ofrecen las VNFs en múltiples archivos con la imagen de disco y los descriptores separados. También los vendedores dan la posibilidad de que en muchos casos se puedan crear/modificar los descriptores, que son usualmente archivos YAML (YAML no es lenguaje de marcado) que describen como la VNF debe ser desplegada. La solución sería traducir dicho descriptor a los de 5GTANGO sobre la base de que es posible evaluar las VNFs con 5GTANGO mientras hayan sido empaquetadas por el SDK de la plataforma. Cuando los resultados correctos sean obtenidos, se volverá a empaquetar la VNF, en la solución del vendedor para ser enviada a producción. La posibilidad de modificar el empaquetado de las VNF fue introducida por la especificación ETSI ISG NFV Release 3, en su acápite VNF software modification, donde analiza el soporte a los cambios en el empaquetado de una VNF a través del manejo de las imágenes de software y requerimientos de aspectos relacionados. Esta nueva funcionalidad propuesta por el ETSI también incluye mejoras y una nueva interfaz para apoyar la coordinación entre el VNFM y la instancia de VNF durante el proceso de modificación [22].
3- Validación de la selección de plataformas de prueba para la NFV
Anteriormente, se presentó una selección de plataformas de pruebas de código abierto para la NFV basadas en estándares y para varios SUT, con el objetivo de posibilitar al proveedor de servicio la evaluación de los elementos de la arquitectura NFV en aras de lograr una reducción en los costos y acelerar la velocidad en la entrega de servicios.
A continuación, se realiza la validación de la selección de las plataformas de prueba, la cual comienza con la caracterización del despliegue de la NFV que se va a emplear en un caso de estudio de implementación de dichas plataformas.
3.1- Caracterización del despliegue de NFV
Para la implementación de las plataformas de prueba seleccionadas el proveedor de servicios debe contar con un despliegue de la NFV que se desea probar, el cual puede variar de un proveedor de servicios a otro. Es importante tener presente que en un despliegue de NFV se deben considerar las capas de su arquitectura y emplear hardware COTS y tecnologías de virtualización.
En este despliegue de NFV se utiliza como NFVI y VIM lo propuesta por la Fundación Linux en su proyecto OPNFV, donde desarrolla una plataforma NFV de referencia basada en documentos de la ETSI NFV ISG. Este proyecto requiere, para su correcto despliegue, requerimientos que serán aportados por el caso de estudio (Plataforma SONATA). Una de las NFVI y VIM sobre las que trabaja SONATA es OPNFV FRASER en su versión 6.2 [23]. Cabe destacar que no debería haber ninguna restricción para conectar la plataforma de servicio de SONATA a una infraestructura de OpenStack desplegada por otras versiones de OPNFV; si se asume que existe retrocompatibilidad en el método de autenticación y en los Heat Templates entre la versión de OpenStack [24]. En el despliegue que se propone, se seleccionó la versión OPNFV FRASER versión 6.2 por cuanto ha sido probada por la comunidad de SONATA cumpliéndose los requerimientos necesarios que necesita su plataforma.
Para realizar la instalación de OPNFV FRASER 6.2 se utiliza el instalador Apex [25], del proyecto OpenStack Triple O, como herramienta de despliegue. La selección se basa en las recomendaciones de los creadores del proyecto 5GTANGO [24] y para su instalación se sigue la guía oficial de OPNFV [25]. Es importante comprender los elementos básicos de un despliegue de este tipo para implementar correctamente OPNFV. Triple-O significa OpenStack en OpenStack lo que significa que OpenStack será usado para instalar OpenStack, o sea que en esta metodología de despliegue existen dos instalaciones de OpenStack. Esto se conoce como undercloud y overcloud. Undercloud se utiliza para el despliegue de overcloud y este último es OPNFV. La instalación de OPNFV es una nube de OpenStack con funciones de NFV integradas que se instalarán mediante una implementación todo en uno más pequeña de OpenStack.
Adicionalmente, OPNFV distingue diferentes tipos de controladores SDN, opciones de implementación y características en “escenarios”. Estos “escenarios” son universales en todos los instaladores de OPNFV, aunque algunos pueden ser compatibles o no con cada instalador. La nomenclatura estándar para un escenario es <Plataforma VIM> <Tipo de Controlador de SDN> <Características> <Ha/noHa>.
El escenario que se selecciona es “os-nosdn-kvm_ovs_dpdk-noha.yaml” por recomendación de los desarrolladores de la plataforma SONATA [26]. La nomenclatura del escenario seleccionado significa:
“os”: se utiliza el VIM OpenStack.
“nosdn”: sin controlador de SDN.
“kvm_ovs_dpdk”: utiliza el más reciente proyecto OPNFV KVM4NFV, además de el Open vSwitch y dpdk como controlador de interfaz de red para el procesamiento rápido de paquetes
“noha”: no es de alta disponibilidad.
Este escenario está compuesto por servicios comunes de OpenStack que están habilitados de manera predeterminada, incluyendo Nova, Neutron, Glace, Cinder, Keystone y Horizon. Opcionalmente y por defecto, los servicios de Tacker y Congress también están habilitados. Ceph se utiliza como almacenamiento de fondo para Cinder en todos los nodos implementados. Este escenario se implementa con Apex con un nodo controlador y dos de computo (o menos) debido a que no es altamente disponible [27].
3.2- Implementación de la plataforma de prueba para VNF y NS: Sonata
Basado en la caracterización del despliegue de NFV que se describió anteriormente y en las consideraciones de despliegue de la plataforma SONATA, el diseño de la implementación del caso de estudio para probar VNF y NS se muestra en la figura 4.
La necesidad de cumplir con el enfoque del proveedor de servicio de evaluar VNFs de diferentes vendedores trajo consigo que se planteara usar la plataforma de prueba de SONATA para analizar tanto los casos de VNFs basados en sus descriptores como los VNFs resultantes de traducir los descriptores de VNFs de terceros al esquema de descriptores de SONATA.
Por lo antes dicho, se plantea como primera selección de VNF para probar en la plataforma SONATA, la encontrada en el repositorio [28] que posee varios ejemplos de servicios de red y sus correspondientes VNFs que pueden ser usadas para probar el SDK de SONATA y su plataforma de servicio. Se debe aclarar que las VNFs que se encuentran en este repositorio son en su mayoría contenedores Docker que pueden ser usadas directamente en el emulador de 5GTANGO. Es importante aclarar que las VNFs que se encuentran en este repositorio son para la realización de pruebas y no para fines comerciales. Para este caso de estudio se seleccionó sonata-ovs1-vnf-docker que es un OpenvSwitch dentro de un contenedor de VNF.
La segunda selección de la VNF a probar corresponde con el Proyecto Sample VNF de OPNFV [29], que constituye un repositorio de ejemplos de VNFs (aproximaciones de código abierto de VNFs de grado Telco, pero no son un producto comercial), del cual se seleccionó el vFirewall. Una vez descargada esta VNF se pasa a la separación del archivo Organización Internacional de Normalización (ISO) de la VNF de su descriptor y entonces se despliega en el SDK de la plataforma SONATA con el objetivo de empaquetarlo con sus descriptores. Una vez que la VNF no SONATA cuente con el descriptor de SONATA esta puede ser desplegada en la plataforma de servicio para aplicarle las pruebas de validación y verificación.
En la plataforma de prueba, la primera acción del motor de prueba del bloque V&V es solicitar el despliegue del servicio de red o la VNF, para esto es necesario la implementación de una capa MANO. Para este caso de estudio se utiliza la plataforma de servicio de SONATA (capa MANO). La plataforma de servicio de SONATA es desplegada en un contenedor docker. Tan pronto como la VNF (puede considerarse tanto el Openvswitch o el vFirewall que se seleccionó anteriormente) es desplegada, el motor de prueba desplegará las sondas apropiadas en el ambiente sandbox y la configura. Ya listas las condiciones necesarias el escenario de prueba se ejecutará.
Con el objetivo de tener información que permita la caracterización general del SUT que se está evaluando, se consideró el sistema de estrellas del proyecto 5GTANGO que permite puntuar el SUT de acuerdo con los resultados de múltiples pruebas y mapear la puntuación en una clasificación predefinida que ofrece una calificación general del SUT. Es importante destacar que este sistema no reemplaza los datos de prueba sin procesar que serán enviados al catálogo.
Se plantea realizar pruebas de caja negra, porque permite realizar pruebas funcionales y no funcionales, además de ser adecuadas para las pruebas de conformidad de la interfaz lo que permite evaluar los puntos de referencia entre el MANO y la infraestructura y los NS descritos en la arquitectura de referencia ETSI NFV. Las pruebas de caja blanca no se utilizan en este caso de estudio porque están enfocadas mayormente a los servicios de red. Además, se estableció almacenar los resultados de las pruebas en el catálogo de SONATA para hacer uso de los mecanismos de valor agregado de este que permiten perfeccionar la toma de decisiones a la hora de seleccionar VNFs y NS específicos a las necesidades de los operadores.
Otro desafío de la NFV es admitir y simplificar la creación de paquetes de servicio de red y descriptores, incluso para configuraciones complejas. 5GTANGO aborda este desafío al proporcionar un SDK que admite la creación de paquetes y descriptores de servicios de red. Esto tiene importancia para el caso de estudio porque va a permitir empaquetar con los descriptores de SONATA aquellas VNF/NS que no pertenezcan al proyecto 5GTANGO, pero necesiten ser evaluadas en el V&V (ejemplo el vFirewall seleccionado con anterioridad del proyecto Sample VNF de OPNFV).
Para el caso de estudio que se analiza, se utiliza la versión de SONATA (versión 4). En la guía de instalación disponible; se muestra un diagrama de la plataforma 5GTANGO desplegada por OpenStack RDO que es mucho más simple que la implementación de VIM a través del instalador Apex. Sin embargo, una instalación con OpenStack RDO requiere de pago a diferencia de Apex; por lo que se seleccionó este último. Una vez que la instalación de OpenStack funciona correctamente se puede trabajar con la plataforma 5GTANGO. Para ello se instala la Plataforma de Servicio, el V&V y el SDK; se conecta la plataforma de OpenStack al SP (el VIM OpenStack se ejecuta dentro del SP como una abstracción de la infraestructura) y se construyen los NSs (usando el SDK) para realizar su despliegue sobre OpenStack.
3.3- Conclusiones
La selección de plataformas de prueba de código abierto agrupadas en sistemas bajo prueba representa los requerimientos y necesidades de los proveedores de servicio y es muy útil para la realización de pruebas de pre-despliegue. Estas plataformas permiten conocer el funcionamiento de las capas de la arquitectura NFV, evaluar la NFV antes de pasar al ambiente de producción y dimensionar eficientemente los recursos de hardware, de infraestructura virtualizada y las funciones de red virtual.
