SOLUCIONES PARA UN ORQUESTADOR DE SERVICIOS DE RED SOLUTIONS FOR A NETWORK SERVICES ORCHESTOR

“IX Simposio Internacional de Telecomunicaciones”

SOLUCIONES PARA UN ORQUESTADOR DE SERVICIOS DE

RED

SOLUTIONS FOR A NETWORK SERVICES ORCHESTOR

Alejandro Delgado Brito

, Dr. Félix F. Alvarez Paliza

_,

1 Desoft Cienfuegos, Cuba, alejandrodelgadobrito1@gmail.com 2 Universidad Central “Marta Abreu” de Las Villas, Cuba, fapaliza@uclv.edu.cu

RESUMEN

La rápida aparición de las tecnologías de red definidas por software (SDN), la virtualización de funciones de red (NFV), junto con el número cada vez mayor de usuarios de Internet móvil, está allanando el camino hacia un cambio radical en las infraestructuras de red de próxima generación. Estos nuevos desafíos emergentes exigen servicios de red ágiles que consumen pocos recursos de red, almacenamiento y cómputo en infraestructuras heterogéneas y dominios administrativos. Coordinar el control de recursos y la creación de servicios a través de dominios interconectados y diversas tecnologías se convierte en un gran desafío. Los esfuerzos de las diferentes áreas de investigación y desarrollo se están dedicando a permitir que los procesos de orquestación automaticen, coordinen y administren la implementación y operación de los servicios de red. En este trabajo, se profundiza en el tema de la Orquestación de Servicios de Red (NSO), se revisan los antecedentes históricos, los proyectos de investigación más relevantes y las tecnologías habilitadoras. Se realiza una evaluación para determinar, en base a la Conformidad con la arquitectura de referencia ETSI NFV MANO, Arquitectura de software y componentes, que solución de NSO; reflejada por organismos internaciones reconocidos: OSM, OpenStack Tacker y ONAP. Sobre la base del análisis anterior, se presentan una serie de soluciones sobre el tema dinámico y estratégico de la orquestación de servicios de red.

Palabras Clave: Orquestación de servicios de red, NSO, OSM, OpenStack, ONAP, SDN, NFV

ABSTRACT

The rapid emergence of software-defined network technologies (SDN), the virtualization of network functions (NFV), together with the increasing number of mobile Internet users, is paving the way for a radical change in the infrastructure of next generation network. These new emerging challenges require agile network services that consume few network, storage and computing resources in heterogeneous infrastructure and administrative domains. Coordinating the control of resources and the creation of services through interconnected domains and various technologies becomes a great challenge. The efforts of the different areas of research and development are being dedicated to allow the orchestration processes to automate, coordinate and manage the implementation and operation of the network services. In this work, the theme of the Network Services Orchestration (NSO) is deepened, the historical background, the most relevant research projects and the enabling technologies are reviewed. An evaluation is carried out to determine, based on the Compliance with the reference architecture ETSI NFV MANO, Software architecture and components, which NSO solution; reflected by recognized international organizations: OSM, OpenStack Tacker and ONAP. On the basis of the

“IX Simposio Internacional de Telecomunicaciones”

previous analysis, a series of solutions on the dynamic and strategic theme of the orchestration of network services are presented.

Keywords

: Network Service Orchestration, NSO, OSM, OpenStack, ONAP, SDN, NFV.

1. INTRODUCCIÓN

Las infraestructuras de telecomunicaciones constan de una gran variedad de tecnologías de dominios especializados, como redes de radio, acceso, transporte y centro de datos (virtualizado). El diseño, la implementación y la operación de los servicios de extremo a extremo suelen ser manuales y los procesos largos se realizan a través de los Sistemas de soporte de operación (OSS) tradicionales, lo que da como resultado largos plazos de entrega (semanas o meses) hasta la entrega efectiva del servicio [1]. Además, los flujos de trabajo involucrados suelen verse obstaculizados por los peligros incorporados de las infraestructuras que están fuertemente acoplados a las topologías físicas y restricciones específicas de hardware. Los avances tecnológicos bajo las banderas de las Redes Definidas por Software (SDN) [2] y la Virtualización de las Funciones de Red (NFV) [3] ofrecen nuevas formas en que los operadores de red pueden crear, implementar y administrar sus servicios. SDN y NFV, así como la computación en la nube, introducen nuevos medios para la utilización eficiente y flexible de sus infraestructuras a través de un paradigma de servicio centrado en el software [4]. Sin embargo, para realizar este paradigma, es necesario modelar el servicio de extremo a extremo y tener la capacidad de abstraer y automatizar el control de los recursos físicos y virtuales que prestan el servicio. El conjunto coordinado de actividades detrás de dicho proceso se conoce comúnmente como orquestación. En general, la orquestación se refiere a la idea de seleccionar y controlar automáticamente múltiples recursos, servicios y sistemas para cumplir ciertos objetivos (por ejemplo, un cliente que solicita un servicio de red

específico). En conjunto, el proceso debe ser oportuno, coherente, seguro y conducir a una reducción de costos debido a la automatización y la virtualización. Nos referimos a la Orquestación de Servicios de Red (NSO) como los procesos automatizados de administración y control involucrados en el despliegue de servicios y las operaciones realizadas principalmente por operadores de telecomunicaciones y proveedores de servicios, que involucran diferentes tipos de recursos y potencialmente múltiples proveedores.

En la actualidad todavía no hay una comprensión alta y de definición práctica de la NSO, no solo en la comunidad de redes, sino también propiamente a los que están vinculados a dicho proceso. Existen varias soluciones, pero cada una difiere en gran medida en correspondencia con otra puesto que el enfoque técnico general está muy fragmentado y muestra poca consolidación en torno a una noción general de que es la orquestación de servicios de red.

El objetivo principal de este trabajo es la evaluación para determinar, en base a determinadas características suministradas por organismos internacionales reconocidos, que solución en torno al término Orquestador de Servicios de Red (NSO) tiene mayores prestaciones. Presentamos un estudio en profundidad y actualizado sobre la orquestación de servicios de red, tecnologías de habilitación, soluciones reales, desafíos abiertos y oportunidades de investigación.

2. CONTENIDO

Algunas de las soluciones de orquestación existentes solo están vinculadas a un entorno de

“IX Simposio Internacional de Telecomunicaciones” red específico y, además, algunas de ellas pueden

orquestar un número limitado de servicios [5]. En esta sección, se presenta una descripción de los principales marcos de orquestación, incluidas las soluciones de código abierto y propuestas. Los proyectos abarcan diferentes tecnologías y dominios.

2.1. Soluciones de código abierto

Las Fundaciones de código abierto, como la Fundación Apache y la Fundación Linux, se están convirtiendo cada vez más en las entidades de alojamiento para grandes proyectos de código abierto de colaboración en el área de redes. Los proyectos más importantes son ONOS, CORD, Open Daylight, OPNFV y, recientemente, ONAP, formada por la fusión de Open-Orchestrator (Open-O) y ECOMP. Todos los proyectos son importantes para crear una plataforma bien definida para la orquestación de servicios.

2.1.1. Cloudify

Cloudify [6] es un marco centrado en la orquestación para la orquestación en la nube que se enfoca en la optimización de la orquestación y gestión NFV. Proporciona un NFVO y un VNFM genérico en el contexto del NFV ETSI, y puede interactuar con diferentes VIM, contenedores y dispositivos e infraestructuras no virtualizados. Cloudify está alineado con la arquitectura de referencia de MANO pero no es totalmente compatible.

Para ayudar a contribuir a la adopción de código abierto de NFV-MANO, Cloudify se involucra y patrocina diversos proyectos de NFV y organizaciones de estándares, como la especificación TOSCA, ARIA, la Plataforma de automatización de redes abiertas (ONAP) y la arquitectura DCIS Cube de la OTAN [7].

2.1.2. ESCAPE

Basado en la arquitectura propuesta por el proyecto EU FP7 UNIFY [8], ESCAPE (Entorno de Creación de Prototipos de Cadena de Servicio Extensible) es un marco de prueba de concepto NFV que admite tres capas principales de la arquitectura UNIFY: (i) capa de servicio, (ii) capa de orquestador y, (iii) capa de infraestructura [9]. Puede operar como un orquestador de múltiples dominios para diferentes dominios tecnológicos, así como diferentes dominios administrativos. ESCAPE también es compatible con la gestión remota de dominios (orquestación recursiva), y funciona con modelos de abstracción de recursos conjuntos (redes y nubes) [10].

2.1.4. ONAP

Bajo la bandera de la Fundación Linux, la Plataforma de Automatización de Red Abierta (ONAP) [11] resultó de la unión de dos iniciativas MANO de código abierto (OPEN-O [12] y OpenECOMP [13]). La plataforma de software ONAP implementa una arquitectura e implementación unificadas, con capacidades robustas para el diseño, creación, organización, monitoreo y administración del ciclo de vida de las funciones de red físicas y virtuales [14].

Actualmente, ONAP está siendo apoyado e impulsado por los principales operadores de redes y nubes y proveedores de tecnología en todo el mundo [15]. Por lo tanto, ONAP se puede utilizar para diseñar, desarrollar e implementar servicios de red dinámicos a través de la red del proveedor de servicios y / o dentro de su propia nube.

2.1.5. OPEN BATON

Construido por el Instituto Fraunhofer Fokus y la Universidad Técnica de Berlín, Open Baton [16] es una implementación de referencia de código abierto de la NFVO basada en la especificación

“IX Simposio Internacional de Telecomunicaciones” ETSI NFV MANO y el estándar TOSCA. Le permite

ser una plataforma independiente del proveedor (es decir, interoperable con diferentes soluciones de proveedores) y fácilmente extensible (en todos los niveles) para admitir nuevas funcionalidades y plataformas existentes.

La versión actual de Open Baton 4 incluye muchas características y componentes diferentes para crear un entorno completo totalmente compatible con la especificación NFV. Entre los más importantes están: (i) un NFVO (que expone las API de TOSCA), (ii) un VNFM genérico y un servidor Juju VNFM, (iii) un mercado integrado dentro del panel de control de Open Baton, (iv) un sistema de autoescalado y gestión de fallas y (v) un potente motor de eventos para el envío de la ejecución de eventos del ciclo de vida.

Finalmente, Open Baton se incluye como un proyecto de apoyo en el proyecto denominado Orquesta12_{. Esta iniciativa de OPNFV busca} integrar las funcionalidades de orquestación de Open Baton con los proyectos OPNFV existentes para ejecutar escenarios de prueba (y proporcionar comentarios) sin necesidad de modificaciones en sus proyectos.

2.1.6. Open Source MANO (OSM)

ETSI Open Source MANO [17] es un proyecto alojado en ETSI para desarrollar una plataforma Open Source NFV-MANO alineada con los modelos de información de ETSI NFV y que cumple con los requisitos de las redes de producción de NFV. El proyecto lanzó su versión cinco [18] en diciembre de 2018 y presentó mejoras en las capacidades de bucle cerrado y el modelado y la lógica de redes. Además, esta versión proporciona una instalación nativa en la

nube y una nueva interfaz de red, alineada con la especificación NTSV NFV ETSI SOL005 [19].

La arquitectura OSM tiene una clara división de la función de orquestación entre el Orquestador de Recursos y el Orquestador de Servicios. Integra iniciativas de software de código abierto como Riftware como Orquestador de Servicos de Red y GUI, OpenMANO como Orquestador de Recursos (NFVO) y Juju Server como Manejador de Configuraciones (G-VNFM).

2.1.7. Tacker

Tacker [20] es un proyecto OpenStack para crear un VNFM genérico y un NFVO para implementar servicios de red y VNF en una plataforma de infraestructura Nube / NFV (por ejemplo, OpenStack). Tacker se basa en el marco arquitectónico ETSI MANO, que proporciona una pila funcional para orquestar los servicios de red de extremo a extremo utilizando VNF.

Tacker también realiza la asignación a SFC (Cadena de funciones de servicio) y admite el escalado automático y el perfil NFV TOSCA (mediante el uso de un traductor térmico).

Los componentes de Tacker se integran directamente en OpenStack y, por lo tanto, proporcionan una interoperabilidad limitada con otros VIM. Combina la NFVO y la VNFM en un solo elemento, sin embargo, internamente, las funcionalidades están divididas. Otra limitación es que solo funciona en entornos de dominio único.

2.1.8. Tenor

Desarrollado por el proyecto T-NOVA [21], el enfoque principal de esta plataforma de orquestación Multitenant / Multi NFVI-PoP es administrar todo el servicio de ciclo de vida de NS,

“IX Simposio Internacional de Telecomunicaciones” optimizando el uso de recursos de TI y redes.

TeNOR [22] presenta una arquitectura basada en una colección de servicios de colaboración acoplados libremente (también conocidos como arquitectura de microservicios) que aseguran una operación modular del sistema. Los microservicios son responsables de administrar, proporcionar y monitorear los NS / VNF, además de forzar los acuerdos de SLA y determinar los recursos de infraestructura necesarios para respaldar una instancia de NS.

2.2 Resultados y Discusión

En este epígrafe se seleccionaron de las soluciones anteriormente presentadas los proyectos de OSM, ONAP y OpenStack Tacker por ser de los más relevantes dentro de las tecnologías de NSO. Se dejaron fuera de este estudio los proyectos como OpenBaton y TeNor porque el apoyo de la industria, la participación de contribuyentes externos y una mayor sostenibilidad pueden ser un desafío para estos proyectos, por lo que por ahora no formaran parte del alcance de esta publicación.

La idea es justamente realizar una matriz en donde se describan algunas características que agrupen ventajas y desventajas de las tres soluciones, siendo este el objetivo de la comparación.

Antes de todo se hace necesario definir las características o criterios que serán objeto de evaluación en la matriz que correspondan a las tres soluciones, siendo importante manifestar que los criterios han sido seleccionados teniendo como base lo planteado por el ETSI [23]. A continuación, se citarán los más importantes:

 Conformidad con la arquitectura de referencia NFV MANO

 Arquitectura de software

 Enfoque de definición NSD

 Soporte VIM y VNFM

 Capacidades para aprovisionar el servicio de extremo a extremo.

 Interacción con organismos y comunidades de normalización relevantes.

A continuación, se hace una breve descripción de los criterios a evaluar:

Conformidad con la arquitectura de referencia ETSI NFV MANO

ETSI ha desarrollado un marco arquitectónico de referencia y especificaciones para la gestión y la orquestación de NFV. El marco se centra en la operación VNF de soporte en diferentes hipervisores y recursos informáticos. También cubre la organización y la gestión del ciclo de vida de los recursos físicos y virtuales. A continuación, se muestra dicho marco en la figura 1:

“IX Simposio Internacional de Telecomunicaciones”

Arquitectura de software y componentes

Como es de esperar, todas las soluciones de Orquestación NFV son plataformas de software integradas complejas combinadas desde múltiples componentes.

Enfoque para la definición de NSD

El Descriptor de servicio de red (NSD) especifica los componentes y las relaciones entre ellos que se implementarán en la parte superior de IaaS durante la instanciación del servicio NFV. Las plataformas de orquestación suelen utilizar algún lenguaje de plantillas para definir NSD. Si bien la industria en general considera a TOSCA como un estándar de facto para definir las NSD, también existen enfoques alternativos disponibles en varias plataformas.

Soporte VNFM y VIM

El despliegue del servicio NFV se realiza en el IaaS apropiado, que en sí mismo es un conjunto de recursos de computación, red y almacenamiento virtualizados. La arquitectura de referencia ETSI MANO identifica un componente para administrar estos recursos virtualizados. Este componente se conoce como el administrador de infraestructura virtual (VIM). Tradicionalmente, la comunidad de código abierto trata a OpenStack / KVM como un VIM estándar "de facto". Sin embargo, un servicio NFV puede abarcar varios tipos de VIM y varios hipervisores. Por lo tanto, el soporte multi-VIM es un requisito común para un motor de orquestación.

Además, un elemento separado en una arquitectura MANO de NFV es el Administrador de VNF, que es responsable de la administración del ciclo de vida del VNF en particular. El componente VNFM puede ser genérico, tratar el VNF como una

caja negra y realizar operaciones similares para varios VNF, o puede haber un VNFM específico del proveedor que tenga capacidades únicas para la administración de un VNF determinado. Tanto la comunicación VIM como la VNFM se realizan a través de puntos de referencia apropiados, según lo definido por la arquitectura MANO de NFV.

Capacidades para aprovisionar un servicio de extremo a extremo.

El aprovisionamiento de servicios NFV consta de varios pasos, como la creación de instancias de VNF, la configuración, el aprovisionamiento de redes subyacentes, etc. Además, un servicio NFV puede abarcar múltiples nubes y ubicaciones geográficas. Este tipo de arquitectura requiere una gestión compleja del flujo de trabajo por parte de un orquestador NFV, y coordinación y sincronización entre las entidades de infraestructura.

Interacción con organismos de normalización y comunidades relevantes.

Cada uno de los proyectos revisados tiene un fuerte apoyo de la industria y comunidades. Dependiendo de la naturaleza de cada comunidad y las prioridades del proyecto, hay un enfoque diferente en la colaboración con una industria, otros proyectos de código abierto y organismos de estandarización.

Cabe destacar que los criterios mencionados anteriormente son los más sobresalientes para la matriz de análisis comparativo a nivel general. Dicho esto, la matriz quedaría de la siguiente manera:

“IX Simposio Internacional de Telecomunicaciones”

Tabla1: Comparativa entre las diferentes soluciones [11], [18], [20]

Características

Soluciones

OSM ONAP OpenStack Tacker

Conformidad con la arquitectura de

referencia NFV MANO

Dado que ETSI aloja este proyecto, intenta cumplir

con la arquitectura de referencia MANO NFV de

ETSI, respetando sus especificaciones.

Muchos de sus componentes están fuera del

alcance de la arquitectura NFV-MANO, por lo que los puntos de referencia entre los componentes de ONAP

no (parecen) coincidir con los puntos de referencia

NFV-MANO.

Se basa en la ETSI MANO, para formar su arquitectura, y proporciona un stack funcional para la orquestación de servicios

de red extremo a extremo utilizando VNFs. Arquitectura de software Consta de 3 componentes básicos: Orquestador de servicios(SO), Orquestador de Recursos(RO) y el módulo de configuración y abstracción de VNF (VCA). Ofrece la capacidad de administrar instalaciones e implementaciones nativas en la nube en entornos de nube

administrados por Kubernetes.

Proporciona un catálogo de VNF para los descriptores de VNF y las

API para la gestión del ciclo de vida de las VNF, junto con capacidades como la supervisión de VNF, el escalado automático y

la recuperación automática.

Enfoque de definición NSD

Sigue la especificación oficial de MANO, que tiene

definiciones tanto para NSD como para descriptores de VNF

(VNFD).

Está fuera del alcance formalmente especificado de

ETSI NFV para NFVO y VNFM.

Utiliza un flujo de trabajo llamado "Mistral" que se ejecuta en base a plantillas, para crear una instancia de un servicio o una aplicación.

Soporte VIM y VNFM

OSM inicialmente se consideró una plataforma multi-VIM, y es compatible

con OpenStack, VMware, OpenVIM, OpenDaylight,

ONOS, Floodlight y AMAZON WebServices.

Aprovecha la arquitectura ETSI NFV MANO y el modelo de información como

referencia, e implementa la gestión del ciclo de vida completo y FCAPS de VNF y

NS.

Actualmente implementa VNF en una sola instalación de OpenStack (VIM). A través del soporte de VIM multisitio, puede

implementar VNF en múltiples instalaciones de OpenStack, a través del componente NFV

Orchestrator (NFVO). Capacidades para aprovisionar el servicio de extremo a extremo. Admite la implementación del servicio NFV que

abarca varios VIM.

Es agnóstico a los servicios y recursos que administra.

Construye un administrador de VNF genérico y un orquestador de

NFV utilizando OpenStack como plataforma de infraestructura NFV. Interacción con organismos y comunidades de normalización relevantes.

Sigue las especificaciones, los puntos de referencia y

las interfaces correspondientes establecidas por el ETSI. También presenta relación

con OpenStack y OpenDaylight.

Toma enfoques para aprovechar las diferencias y

las características complementarias entre las

comunidades de fuente abierta y las normas.

Recibe los requisitos de NFV a través de la colaboración con OPNFV y directamente de las telecomunicaciones involucradas

“IX Simposio Internacional de Telecomunicaciones” Resumiendo, el estado actual de las plataformas

de orquestación NFV antes analizadas, podemos arribar a lo siguiente:

OpenStack Tacker

 Solución de trabajo.

 Actividad limitada.

 Técnicamente completo, pero demasiado integrado a VIM.

ONAP

 Difícil de empezar puesto que ONAP al ser formado mediante la fusión de dos grandes proyectos, se requiere de numerosas líneas de código para echarlo a andar.

 Enorme actividad

 Técnicamente completo, pero quizás demasiado amplio para nuestros casos de uso.

 Enorme apoyo de la comunidad y de las principales empresas de tecnología del mundo.

OSM

 Solución de trabajo

 Gran actividad

 Grandes avances en su versión 5

 Enorme apoyo de la comunidad y de las principales empresas de tecnología del mundo, siendo alojado por ETSI

3. CONCLUSIONES

En este trabajo sobre el análisis de las diferentes soluciones de orquestador de servicios de red, destacamos su creciente importancia y tratamos de contribuir a una comprensión general de los conceptos comunes y los diversos enfoques hacia las realizaciones prácticas de la NSO. Presentamos tecnologías habilitadoras, clarificamos las definiciones detrás del término

orquestación e hicimos una comparativa entre algunas de las diferentes soluciones que engloban el término NSO.

Después del citado análisis del que fueron objeto de estudio las tres soluciones seleccionadas, donde se abordaron sus ventajas y desventajas más sobresalientes, podemos concluir que la solución OSM es la que mejores prestaciones presenta y la que mejor pudiera adaptarse al contexto de la realidad que vive hoy nuestro sistema empresarial debido a:

 Versatilidad al ser solventada por más de 70 compañías tecnológicas de diferentes ramas de la industria.

 Gran comunidad libre de la que es sencillo ser miembro.

 Curva de aprendizaje inferior a otras tecnologías en lo que a despliegue se refiere.

 Precios asequibles en la adquisición de infraestructura para su correcto funcionamiento.

 Presenta facilidades para adaptarse en entornos complejos, propios de nuestra realidad.

 Enorme retroalimentación a través de la comunidad lo que propicia una acelerada corrección de bugs y el desarrollo de nuevas funcionalidades.

4. REFERENCIAS BIBLIOGRÁFICAS

Service Orchestration», 2017. 2. Kreutz, D., Ramos, F.M.V., Esteve

Rothenberg, C., Azodolmolky, S., Uhlig, S., y , Esteves Verissimo, P.,

«Software-Defined Networking: A Comprehensive Survey.», Proceedings of the IEEE 103, pp. 14-76, 2015.

3. Mijumbi, R., Serrat, J., De Turck, F.,

Boutaba, R., y Gorricho, J.l., Bouten, N.,

«Network Function Virtualization: State-of-the-Art and Research Challenges.», IEEE

“IX Simposio Internacional de Telecomunicaciones” Communications Surveys & Tutorials 18, pp.

236-262, 2017.

4. Sonkoly, B., Szabo, R., Westphal, F.J., y

Jocha, D., Czentye, J., Kind, M.,

«UNIFYing Cloud and Carrier Network Resources: An Architectural View», presentado en IEEE Global

Communications Conference (GLOBECOM), 2015, pp. 1-7.

5. Kuklinski, S.,Dinh, K.T., I.G., y Destre, C.,

Ben Yahia, «Design principles of

generalized network orchestrators», presentado en 2016 IEEE International Conference on Communications Workshops (ICC), 2016, pp. 430-435.

6. GigaSpaces, «Cloudify», 2015. [En línea]. Disponible en: http://cloudify.co/.

7. Cloudify, «DCIS Cube Architecting Initiative.», 2018a.

8. UNIFY, F., «UNIFY: Unifying Cloud and Carrier Networks.», 2013.

9. Csoma, A., Sonkoly, B., Csikor, L.,

Tavernier, W., Sahhaf, S., y Nemeth, F., Gulyas, A., «Escape: Extensible service

chain prototyping environment using

mininet, click, netconf and pox», presentado en Proceedings of the 2014 ACM

Conference on SIGCOMM, New York, NY, USA., 2014, pp. 125-126.

10. Sonkoly, B., Czentye, J., S., Tavernier,

W., Risso, F., y Szabo, R., Jocha, D., Elek, J., Sahhaf, «Multi-domain service

orchestration over networks and clouds: A unified approach.», ACM SIGCOMM Computer Communication Review 45, pp. 377-378, 2015b.

11. Foundation, L., «ONAP - Open Network Automation Platform», 2017a.

12. Linux Foundation., «Open Orchestrator.», 2017.

13. AT&T, «ECOMP ( Enhanced Control , Orchestration , Management & Policy ) Architecture White Paper.», 2016.

14. Foundation, L., «ONAP Developer Wiki.», 2017b.

15. Cloudify, «ONAP: Orchestration for Real Results.», 2018b.

16. Fraunhofer, Berlin, T., «Open Baton: An open source reference implementation of the ETSI Network Function Virtualization MANO specification», 2017.

17. ETSI, «Open Source MANO.», 2016. 18. Hoban, A., Canonical, A.I., Francisco, E.,

Ramon, J., Telefonica, S., García De Blas,G., Gianpietro, T., Whitestack, L., Canonical, M.S., Harper, y M., Marchetti, M., Silvia, S., Etsi, A., Little Vmware, V.,Tierno, A., Telefonica, S., Boyer, «OSM

Release FIVE Technical Overview. Technical Report.ETSI.», 2018.

19. ETSI Industry Specification Group (ISG)

NFV, «ETSI GS NFV-SOL 005 V2.4.1:

Network Functions Virtualisation (NFV) Release 2; Protocols and Data Models; RESTful protocols specification for the Os-Ma-nfvo Reference Point.», 2018.

20. OpenStack Foundation, «Tacker - OpenStack.», 2016.

21. FP7 project T-NOVA, b., «T-NOVA Project, Network Functions as a Service over Virtualised Infrastructures.», 2016.

22. Riera, J.F., Batall, J., Petralia, G., Liberati,

F., Giuseppi, A., Pietrabissa, A., Ceselli, A., Petrini, A., Trubian, M., Papadimitrou, P., Dietrich, D., Ramos, A., Melin, J., Xilouris, G., Kourtis, A., Kourtis, T., y Markakis, E.K.,Bonnet, J., Das, M., McGrath, M., «Tenor: Steps towards an

orchestration platform for multi-pop nfv deployment», presentado en 2016 IEEE NetSoft Conference and Workshops (NetSoft), 2016, pp. 243-250.

23. ETSI, «Network Functions Virtualisation: An Introduction, Benefits, Enablers, Challenges & Call for Action», presentado en SDN and OpenFlow World Congress, 2012.