Elementos de Información de MANO

En la sección anterior se indicó que MANO define un conjunto de repositorios para realizar el despliegue y posterior gestión de las instancias de NS y VNF. En este contexto, Garay et al. [43] indican que los procesos de despliegue de servicios y de gestión global del ciclo de vida correspondiente se basan en los elementos de información que describen el servicio de red y sus componentes, tanto como plantillas en un catálogo de servicios y como registros de instancias. La Figura 2.14 (a) muestra los elementos de información definidos por ETSI. Es importante mencionar que un servicio de red puede contener funciones de red físicas (PNF) y que un grafo de envío de VNF (VNFFG) puede hacer referencia a otros elementos de información en el servicio de red, como PNF, VL y VNF. Adicionalmente, un VNFFG también contiene un elemento denominado como ruta de envío de red (NFP) que describe un flujo de tráfico en el NS basado en políticas de decisión.

44

Figura 2.14 Elementos de información: (a) Estructura de alto nivel, (b) Distribución en catálogos y registros

[42].

A continuación, se listan las plantillas de despliegue definidas en NFV para describir por completo los atributos y requisitos necesarios para la puesta en marcha del servicio de red.

a. Los Descriptores de Servicio de Red (NSDs) se consideran elementos de información de servicio

de red de nivel superior y permiten especificar el servicio de red a ser creado. NSD hace referencia a todos los demás descriptores que describen componentes que forman parte del servicio de red.

b. Un descriptor de VNF (VNFD) describe la VNF en términos de su despliegue y requisitos de

comportamiento operacional. VNFD es principalmente utilizada por el gestor de VNFs (VNFM) en el proceso de instanciación de la VNF y de la gestión del ciclo de vida de la correspondiente instancia.

c. Un descriptor de grafo de envío de VNF (VNFFGD) describe la topología (o una parte) del

servicio de red, haciendo referencia a VNFs, PNFs y enlaces virtuales que los conectan.

d. Un descriptor de enlace virtual (VLD) describe los requerimientos de recursos necesarios para el

enlace entre VNF, PNF y puntos finales del servicio de red, basado en las opciones de enlace que están disponibles en el NFVI.

e. Un descriptor de función de red física (PNFD) describe los requisitos de conectividad, interfaz e

indicadores clave de rendimiento (KPIs) de enlaces virtuales para una función de red física adjunta.

El NFVO incorpora todos los descriptores. NSD, VNFFGD y VLD son incorporados en el catálogo de NS mientras que VNFD es incorporado en el catálogo de VNF como parte de un paquete de VNF. Como resultado del proceso de instanciación, se crean registros para representar las nuevas instancias creadas. Los elementos de información denominados como registro de Servicio de Red (NSR), registro de VNF (VNFR), registro de Enlace Virtual (VLR) y registro de VNFFG (VNFFGR) proporcionan una colección de elementos de datos que pueden ser necesarios para modelar el estado de las instancias de NS, VNF, VNFFG o VL, respectivamente. Estos registros son el resultado de combinar elementos de información NSD, VNFD, VNFFGD y VLD con parámetros de entrada/salida intercambiados en tiempo de ejecución a través de diferentes interfaces producidos y/o consumidos por bloques funcionales NFV- MANO.

Durante el ciclo de vida de las instancias respectivas, los registros se actualizan para reflejar los cambios resultantes de la ejecución de las operaciones de gestión del ciclo de vida tanto de servicios de red como

45

de VNFs. La Figura 2.14 (b) resume la relación existente entre descriptores y, posteriores instancias y registros del paradigma NFV.

• Modelado de Elementos de Información

Ciertamente, todas las funcionalidades de gestión y orquestación de servicios de red que proporciona NFV giran en torno a los elementos de información e interfaces propuestas. En el documento de gestión y orquestación propuesto por ETSI [42], se proporcionan detalles de la estructura de estos elementos de información, mostrando en detalle la información que podrían contener cada uno de ellos. Adicionalmente, el documento incluye ejemplos de modelado de elementos de información utilizando diferentes lenguajes o modelos tales como YANG, SID, OVF y TOSCA.

Por otra parte, considerando el nexo existente entre NFV y las tecnologías de computación en la Nube, las plantillas de despliegue para aplicaciones basadas en la Nube también son consideradas como posibles modelos para representar elementos de información de NFV. Chappell [44] resalta que existen diferentes plantillas de despliegue que están tratando de establecerse como estándares en el entorno de la Nube como TOSCA propuesto por OASIS, la plantilla de orquestación Heat (HOT) bajo el desarrollo

de la comunidad de OpenStack15_{, las plantillas CloudFormation presentadas por los servicios web de}

Amazon y Juju Charms de Canonical. También se indica, que existe un creciente interés por TOSCA ya que éste actualmente soporta conceptos más avanzados que Heat y puede ser utilizado por diferentes plataformas de computación en la Nube. Martino et al. [45] proporcionan más detalles sobre las ventajas de TOSCA como la posibilidad de declarar flujos de trabajo gracias al lenguaje imperativo que posee, la definición de un mecanismo de validación y vinculación detallado a través de requisitos y capacidades o la disposición de un conjunto de relaciones predefinidas capaces de vincular componentes de las aplicaciones basadas en la Nube, entre otras.

A continuación, se proporciona una breve descripción de cada uno de estos modelos, haciendo énfasis en TOSCA considerando sus destacadas características.

▪ YANG. El IETF define a YANG como un lenguaje de modelado de datos utilizado para modelar

datos de estado y configuración manipulados por el protocolo de configuración de red (NETCONF) [46]. Con respecto a NETCONF, el IETF indica que es un protocolo que proporciona mecanismos para instalar, manipular y eliminar la configuración de dispositivos de red [9]. YANG se utiliza para modelar dispositivos y servicios de red, es decir, un objeto y sus atributos. Por ejemplo, un dispositivo como un enrutador puede modelarse en YANG y ser configurado a través de NETCONF.

▪ SID (Shared Information and Data model). Conocido también como Marco de Información

(SID) es un componente del proyecto “Frameworx” de TM Forum16 _{el cual tiene como objetivo}

proporcionar un modelo de información y un vocabulario común para toda la información compartida entre las cosas de interés (entidades) y las relaciones (asociaciones) entre estas entidades.

▪ OVF (Open Virtualization Format). El DMTF17 (Distributed Management Task Force) ha

desarrollado la especificación de OVF [47] con el objetivo de estandarizar un formato abierto, seguro, eficiente y extensible para empaquetar y distribuir software que se ejecutará en sistemas virtuales. OVF se basa en varios estándares del modelo de información común (CIM) definido también por DMTF y permite la creación de sistemas virtuales portátiles y el transporte de sistemas virtuales entre plataformas de virtualización. Considerando la amplia adopción de OVF y CIM en aplicaciones basadas en la Nube, se los puede considerar como punto de partida en el desarrollo de estándares para describir VNFs, en particular, el elemento unidad de despliegue virtual (VDU).

▪ Juju Charms. Juju18 es desarrollado y ofrecido por Canonical, como una aplicación para el fácil

despliegue y administración de aplicaciones pre-configuradas y pre-definidas. Juju utiliza una

15 _{https://www.openstack.org/}

16 _{https://www.tmforum.org/information-framework-sid/} 17 _{https://www.dmtf.org/standards/ovf}

46

colección de componentes de software denominados “Charms” los cuales contienen todas las instrucciones necesarias para implementar y configurar aplicaciones basadas en la Nube. Cada “Charm” es un paquete estructurado de archivos que describen la configuración (normalmente

codificada en YAML19_{) y los scripts de acciones (denominados hooks) para gestionar operaciones}

del ciclo de vida tales como instalación, escalado, actualización, etc. Juju en sí se considera más adecuado como un VNFM, pero un “Charm” podría ser utilizado para definir los descriptores de NFV.

▪ HOT (Heat Orchestration Template). HOT20 representa una de las plantillas soportadas por

Heat21_{. En el programa de orquestación de OpenStack, Heat es el proyecto principal el cual}

implementa un motor de orquestación para lanzar múltiples aplicaciones compuestas basadas en la Nube utilizando plantillas en forma de archivos de texto que pueden ser tratadas como código. Heat soporta nativamente el formato CFN compatible con CloudFormation, y HOT ha sido diseñado para reemplazarlo. HOT está codificado en YAML y utiliza una forma muy sencilla para representar datos.

▪ TOSCA (Topology and Orchestration Specification for Cloud Applications). Lipton [48]

indica que la portabilidad de servicios que se despliegan en infraestructuras basadas en la Nube es una necesidad en aumento, principalmente para eliminar el efecto de dependencia de un proveedor en particular y disminuir los costos de diseño, despliegue y mantenimiento. Para enfrentar este desafío, se ha propuesto que la portabilidad y la capacidad de gestión de un servicio que se ejecuta en una infraestructura en la Nube sigan un enfoque basado en estándares. Es así, que OASIS ha definido un comité técnico denominado como TOSCA para abordar la especificación del estándar requerido. Garay et al. [43] indican que TOSCA define un lenguaje y un metamodelo para describir servicios, sus componentes, relaciones y procedimientos de gestión. Los principales elementos que definen un servicio se representan en la Figura 2.15 (a) y se listan a continuación:

a. Una plantilla de topología define la estructura de un servicio como un conjunto de plantillas

de nodos y plantillas de relación que definen conjuntamente el modelo de topología como un grafo dirigido (no necesariamente conectado).

b. Las plantillas de nodo y relación especifican las propiedades y las operaciones (a través de

interfaces) disponibles para manipular el componente. Las relaciones enlazan nodos diferentes y pueden tener diversos significados (por ejemplo, una relación entre un nodo "motor de proceso" y un nodo "servidor de aplicaciones" podría significar "alojado por").

c. Los planes definen los modelos de proceso que se utilizan para crear y terminar un servicio,

así como para administrar un servicio durante toda su vida útil.

El perfil NFV de TOSCA [40] especifica un modelo de datos para NFV utilizando el lenguaje TOSCA en consonancia con los principios definidos por ETSI. La Figura 2.15 (b) muestra la relación de correspondencia entre los elementos que componen la plantilla de servicio de TOSCA y los elementos de información de NFV, la misma que puede resumirse de la siguiente manera:

a. NSD se describe utilizando una plantilla de servicio.

b. VNFD, VNFFGD, VLD y PNFD son consideradas como plantillas de nodo con tipos de nodo apropiados.

c. VNFD se puede describir adicionalmente utilizando otra plantilla de servicio con un tipo de nodo sustituible.

La Figura 2.16 muestra un ejemplo de un descriptor de servicio de red (NSD) implementado mediante el perfil NFV de TOSCA. El servicio de red está compuesto por VNF1 y VNF2. Cada VNF está descrita como una plantilla de nodo, cuyo tipo se sustituye por una plantilla de servicio diferente. VNFD1 y VNFD2 son plantillas de servicio que describen los requisitos de comportamiento operacional de cada VNF en detalle e incluidas en el NSD. Como se puede

19 _{YAML es un formato de serialización de datos legible por humanos. http://yaml.org/} 20 _{https://docs.openstack.org/heat/latest/template_guide/hot_spec.html#hot-spec} 21 _{https://wiki.openstack.org/wiki/Heat}

47

observar, el NSD permite la composición dinámica de servicios de red, integrando diferentes VNFs y especificando su comportamiento en conjunto.

Figura 2.15 Plantilla de servicio de TOSCA: (a) Elementos y las relaciones entre ellos22, (b) Establecimiento

de la correspondencia entre la plantilla de servicio definida en TOSCA y el descriptor de servicio de red definido en NFV [40].

Figura 2.16 Descripción de un servicio de red mediante el perfil NFV de TOSCA. Los enlaces virtuales

(VLs) requeridos por VNF1 son proporcionados por NSD mediante un proceso de substitución. Todos los archivos de descripción utilizados tienen la extensión yaml.

Mijumbi et al. [36] proporcionan un cuadro comparativo de los diferentes modelos, sin incluir HOT ni Juju Charms, en el cual se destaca su objetivo, campo de aplicación, desafíos de investigación, entre otros. Los autores también puntualizan que los modelos mencionados no fueron desarrollados considerando los requisitos específicos del paradigma NFV, por tal motivo se los ha adaptado de alguna manera y se espera que evolucionen con el tiempo. Por ejemplo, YANG proporciona una forma de describir “qué es un servicio”, sin describir “cómo se debe implementar un servicio”, la topología de los

22 _{http://docs.oasis-open.org/tosca/TOSCA/v1.0/os/TOSCA-v1.0-os.html}

(a) (b)

tosca_definitions_version: tosca_simple_profile_for_nfv_1_0_0 description: VNFDs in import section should be already on-boarded imports: - VNFD1 - VNFD2 topology_template: inputs: node_templates: VNF1: type: tosca.nodes.nfv.VNF1 requirements: - virtualLink1: VL1 - virtualLink2: VL2 VNF2: type: tosca.nodes.nfv.VNF2 VL1: type: tosca.nodes.nfv.VL properties: network_name: net_mgmt vendor: tacker VL2: type: tosca.nodes.nfv.VL properties: network_name: net0 vendor: tacker

48

recursos subyacentes o cómo los recursos pueden estar relacionados o dependientes unos de otros. Por otra parte, TOSCA es un lenguaje estándar creado específicamente para la orquestación. Sin embargo, TOSCA no proporciona una interfaz de configuración que permita controlar las operaciones del ciclo de vida de las instancias desplegadas en tiempo de ejecución. Para solventar este inconveniente, se pueden combinar soluciones para compensar funcionalidades faltantes como lo propone Chappell [44]. Así, TOSCA y su modelo de despliegue centrado en las aplicaciones permitiría desplegar instancias de VNF con un conjunto inicial de configuraciones en la NFVI mientras que un API de configuración basada en modelos como NETCONF/YANG permitiría realizar reconfiguraciones específicas del servicio a la instancia de VNF en tiempo de ejecución.