Application-aware routing es un cambio de enfoque a la hora de enrutar los paquetes de datos a través de una red IP, y está muy relacionado a SD-WAN, Policy-based routing y el uso de SLAs (Service Level Agreements).
Los 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.
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.
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.
SDN y NFV plantean soluciones nuevas a varios problemas relacionados con las comunicaciones. Hablamos de las ventajas de estas tecnologías y el papel que desempeñarán en la evolución del sector.
Durante los últimos 2 años se habla mucho sobre la tecnologías SDN/NFV, que prometen cambios importantes en el actual escenario de las comunicaciones. Son muchas las voces que han señalado que el actual estatus de la red no permite la evolución rápida, la aparición de nuevos protocolos, ni facilita la puesta en práctica de nuevos servicios.
Podemos plantearnos la evolución de los protocolos existentes o crear nuevos protocolos que se ajusten a las necesidades actuales, pero introducir cambios en la red implica riesgos que no se quiere asumir. La red tiene sus deficiencias, pero funciona. Esta falta de interés en la evolución hace que algunos proclamen que la actual Internet está osificada.
La puesta en marcha de nuevos servicios de red obliga a los operadores a la creación de overlays por encima de la actual red IP. Estos overlays (túneles, VLAN, etc.) es un primer paso para la virtualización de la red.
Otro problema al que se enfrentan los operadores es que el ciclo de vida de un equipo es cada vez más corto, debido a la evolución muy rápida de la tecnología. Esto pone en aprietos a los operadores tanto desde el punto de vista técnico como económico (CAPEX/OPEX).
La tecnologías SDN y NFV se presentan como una solución para paliar los problemas anteriores.
SDN son las siglas de Software Defined Networking. La idea detrás de este concepto consiste en gestionar las redes de datos separando el plano de control del plano de datos. Las redes actuales se basan en el uso de cajas negras (routers) en las cuales el plano de control (protocolos de routing, listas de acceso, políticas…) y el plano de datos (switching, routing) no se pueden separar. Esto obliga a una adaptación por parte del operador a las características funcionales de cada fabricante.
El enfoque SDN consiste en centralizar el plano de control para, desde él, establecer la lógica de funcionamiento de la red formada por switches/routes (cajas blancas o bare-metal). Desde la parte central (SDN controller) se aplicará la lógica de switching/routing (flow tables) a los equipos por medio de protocolos como OpenFlow. Las operaciones de switching/routing se realizan basándose en las reglas almacenadas en las flow tables en los switches/routes.
1. Al ubicarse el software del controlador SDN en un lugar centralizado tendrá una visión global del estado de la red y podrá tomar decisiones globales, pudiendo actuar a la vez sobre todas las flow tables de los equipos. Esto es una ventaja frente a los actuales protocolos de routing dinámico, donde cualquier modificación del estado de la red tarda un tiempo finito en propagarse y durante el cual la red está en un estado de routing no estable.
2. A través de la interfaz OpenFlow (southbound API) se independiza el plano de control del plano de datos. Esto permite una integración más fácil de nuevos equipos a la red.
3. SDN permite que una parte de la red transporte tráfico en producción y otra parte tráfico para pruebas, que permita la innovación de funcionalidades y servicios. Es una suerte de virtualización de la red que permite el transporte de diferentes tipos de tráfico sin que se afecten entre ellos.
4. La mayoría de los controladores SDN del mercado (OpendayLight, FloodLight,…) tienen un interfaz (northbound API) con software de orquestación (OpenStack) desde donde se definen las políticas de la red.
5. Los controladores SDN actualmente en producción están escritos en lenguaje Java, lo cual reduce la pendiente de la curva de aprendizaje.
NFV son las siglas de Network Function Virtualization. La idea detrás de estas siglas consiste en lo siguiente: igual que en un Data Center (DC), desde orquestadores como OpenStack, se puede iniciar máquinas virtuales (VM) bajo demanda y que corran sobre cualquier servidor físico del DC. También se podrían iniciar funcionalidades de red en cualquier servidor accesible vía IP. Las funcionalidades de red virtualizadas (VNF) corren dentro de máquinas virtuales o en dockers. El conjunto de servidores sobre los que corren las VNFs, constituyen la red NFVI (NFV Infraestructure). Dichos servidores podrán estar situados en cualquier punto de la red del operador.
En principio no es necesario que NFV y SDN vayan de la mano, aunque sí se complementan. De hecho muchos de los objetivos y de las ventajas de ambas tecnologías son comunes.
Ejemplos de VNFs son los aceleradores de WAN, firewalls, seguridad, balanceadores, etc., es decir, todas las aplicaciones que hasta ahora se realizaban por medio de appliances. Además, se pueden añadir funciones típicas de routing como IPsec, túneles, routing dinámico, etc.
Hay ventajas de NFV que son comunes a las que se obtienen con SDN.
1. El tiempo necesario para tener operativa una funcionalidad de red se reduce considerablemente al no ser imprescindible un hardware específico. Es una cuestión de software.
2. Las VNFs corren sobre servidores off-the-shell.
3. Reduce la “osificación” de la red al permitir la innovación y su implantación de forma rápida.
4. Se independiza del hardware al poder ejecutarse sobre servidores off-the-shell.
5. Las operaciones de red se simplifican al poder realizarse de forma centralizada.
Este es el primer escenario de uso de estas tecnologías. Mediante orquestadores como OpenStack se gestionan las VMs para las operaciones de computación y el almacenamiento virtual. Las VMs, localizadas en distintos servidores, acceden a una red de nivel 2 por medio de soluciones como Open Virtual Switch (OVS). OVS tiene la característica de traspasar los límites de un servidor y garantizar el acceso al mismo switch virtual a VMs, que corren sobre servidores distintos. OVS puede ser gestionado por medio de controladores SDN como OpenDayLight.
Igual que las VMs de computación se pueden instanciar VNFs dentro de los límites del DC.
El éxito de la arquitectura de cloud basada en orquestadores + controladores + OVS se extiende a la WAN. Desde OpenStack se debe poder instanciar VNFs en los servidores de NFVI. Estos servidores pueden estar localizados en distintos puntos de la red del operador, por ejemplo, en los puntos de presencia del operador (POP).
Este esquema da lugar al concepto de vCPE (Virtual CPE): las funcionalidades de red ahora localizadas en las instalaciones del cliente pasan en parte a los servidores localizados en el POP o al propio cloud, dependiendo de las necesidades de latencia de los protocolos involucrados.
Las VNFs no evitan a los operadores depender de una red como la actual, con conectividad IP entre todos los puntos de la red. La infraestructura NFVI necesita que todos los servidores estén interconectados y accesibles desde el cloud.
SDN/NFV constituyen un desafío para los fabricantes de routers al presentar cambios tan radicales en la arquitectura actual de la red. Teldat no es ajena a este cambio y tiene como objetivo adaptarse al nuevo escenario. Un primer paso ha sido la posibilidad de ejecutar aplicaciones VNFs sobre nuestros routers, pudiendo separar los servicios de transmisión facilitados por el router, de los servicios de red puestos en práctica por las aplicaciones que corren en el router.