it modelLos proveedores de servicios de red se enfrentan a un gran reto: mejorar la agilidad en el despliegue de nuevos servicios competitivos frente a las exigencias del mundo IT. ¿Cómo afrontarlo?

No solo se trata de reducir los costes del equipamiento de red para mantener la competitividad, sino también de desplegar servicios en un tiempo muy inferior al actual. Las IT exigen a los proveedores de red un mayor ancho de banda y eso implica la constante mejora de la red con nuevo equipamiento y tecnologías de acceso. Además, los proveedores de red están intentando competir con las IT y proveedores de contenidos, definiendo y acelerando al máximo su producción.

Todo servicio, al final, debe estar constituido por un conjunto de equipos, físicos o virtuales, y una configuración adecuada para cada uno de ellos. Sin lugar a dudas, la instalación y configuración del equipamiento es una tarea con muchos costes.

A día de hoy, los procesos de configuración de los equipos están basados en el uso de scripts codificados por personal experto. La automatización del proceso se ve entorpecida por la variación del equipamiento para adaptarse a nuevos servicios y costes. Los nuevos equipos implican períodos de aprendizaje y generar nuevos scripts.

Dado que los procedimientos actuales no contribuyen a reducir costes (CAPEX/OPEX), ni el tiempo de puesta en explotación, es necesario un nuevo enfoque: definir cómo debe ser un servicio, frente al enfoque actual, basado en cómo se pone en producción.

La definición de un servicio debe realizarse por medio de un lenguaje formal que permitirá especificar el servicio, dando lugar a un modelo. Ese modelo deberá ser reconocido e interpretado por las herramientas de gestión del proveedor de servicios. Es evidente que las herramientas actuales OSS/BSS ya no serán válidas y será necesario adaptaciones al nuevo modelo.

En qué consiste un Modelo de Servicio?

Como hemos dicho, la manera de poder definir un servicio es utilizando un lenguaje formal que permita modelarlo, especificando los elementos que constituyen el servicio y sus relaciones. En el modelo de servicio no se especifica el fabricante último de un determinado equipo ni cómo es su esquema de configuración.

Las ventajas de este enfoque son evidentes al permitir especificar formalmente un servicio de una manera rápida, utilizando una librería de elementos que permitirán confeccionarlo. Lógicamente la pregunta clave es: ¿cómo se llega finalmente a una serie de configuraciones necesarias para el funcionamiento de los equipos, a partir de un modelo genérico?

El mecanismo no es sencillo, pero una vez conseguido podrá automatizar el proceso. Básicamente consiste en el mapeo del modelo de servicio en modelos que especifican formalmente las configuraciones necesarias para su funcionamiento. Dependiendo del tipo de equipo se generará su correspondiente modelo de configuración, ya que no está garantizado que los modelos sean válidos para todos los fabricantes. Los modelos obtenidos del mapeo se emplearán en la configuración de los equipos involucrados en el servicio.

En la actualidad, los modelos formales de definición de servicios y de configuración han generado un gran interés en el sector. Como consecuencia, han aparecido iniciativas con este objetivo de negocio con las cuales los fabricantes de equipos deben tener relación directa, con el fin de llevar a buen puerto las necesidades de los proveedores.

Son especialmente relevantes algunos ejemplos de lenguajes como TOSCA, para la definición de servicios y YANG para la definición formal de configuraciones. El primero es un lenguaje con aplicación directa al mundo SDX/NFV, mientras que el segundo es un lenguaje ya conocido hace tiempo y empieza a estar en los portfolios de algunos fabricantes. Junto con YANG suele aparece el protocolo NETCONF para el transporte de configuraciones y su gestión.

TOSCATopology and Orchestration Specification for Cloud Applications (TOSCA) es un lenguaje basado en templates que permite definir un servicio y su despliegue en una infraestructura Cloud. En TOSCA hay dos elementos básicos para conformar un servicio:

1. Nodos: puede ser una subred, una red, un servidor, un servicio, una NFV, etc.

Relaciones: describe cómo los nodos se conectan unos con otros. Además, también se incluye en la definición ciclos de vida de los nodos, políticas y aspectos operacionales.

La manera de especificar los templates es mediante YAML, aunque inicialmente se utilizó XML.

Actualmente, TOSCA está siendo objeto de interés en proyectos como Juju, Cloudify, IBM Cloud Orchestrator y OpenStack Heat.

YANG/NETCONFYet Another Next Generation (YANG) es un lenguaje formal de modelo de datos ampliamente utilizado en la definición de configuraciones e interfaces.

Una configuración podemos considerarla como un conjunto de datos que deben estar ordenados y que pueden depender de otros valores. El modelo YANG interpreta los datos de configuración como un árbol jerarquizado, en el que cada nodo tiene un valor o bien es el punto de conexión de otros nodos. Cada nodo queda perfectamente definido junto con la interacción con otros nodos. Un aspecto importante de YANG es

la imposición de límites sobre los valores de un nodo, restringiendo la aparición de un nodo o su valor a la aparición de otros nodos o valores dentro de la jerarquía.

En un modelo genérico YANG se incluyen los datos de configuración, datos de estado, Remote Procedure Call (RPC) y notificaciones.

Junto con YANG es habitual el protocolo NETCONF o Network Configuration Protocol. Se trata de protocolo de transferencia y gestión de configuraciones. Los modelos YANG son directamente mapeados en formato XML y transmitidos por el protocolo NETCONF, garantizando la atomicidad de cada transferencia, obteniendo un resultado correcto o erróneo. Además, permite la gestión de configuraciones. Hay 3 tipos de configuraciones: candidata, sobre la cual se han realizado los cambios, running, que es la que se está ejecutando en el equipo y startup que es la configuración almacenada en el equipo y que se usa en el arranque. Una configuración candidata puede transformarse en running y esta a su vez en startup si los cambios realizados en la configuración son considerados correctos.

Conclusión

La modelización, tanto de servicios como de configuraciones, es un concepto que los fabricantes de equipamiento de red, tanto físico como virtual, debemos tener en consideración, no ya largo plazo, sino en el presente. Es uno de los puntos de una lista de elementos que los proveedores de servicios de red necesitan tener operativos para su subsistencia frente a la competencia de las IT.


Sobre el autor

Juan Rodrigo

Comparte este post

Tweet about this on TwitterShare on LinkedInShare on Google+Email this to someone