Redes orientadas a servicios

Algunos padres de Internet como David D. Clark, Robert Braden, Scott Shenker o John Day llevan años haciendo hincapié en el funcionamiento poco óptimo de las redes actuales, argumentando que es demasiado inamovible, estático, poco configurable. Es difícil tanto la inclusión de nuevos protocolos que se adapten a los nuevos requerimientos de red y de usuario, como la adaptación de los ya existentes. De ahí que protocolos que no plantean cambios completamente incrementales en la red estén teniendo dificultades de implantación (como por ejemplo IPv6, pese a la necesidad por escasez de direcciones, o el uso global de otros protocolos de transporte que no sean TCP/UDP) .

Dentro de esta tendencia de añadir mayor capacidad de configuración de la red, conocida como Software-Defined Networking (SDN), han surgido diferentes aproximaciones, pero todas ellas tienen como objetivo una mayor separación de la capa de control respecto a la capa de datos. OpenFlow, por ejemplo, pretende la estandardización de un protocolo de control que permita configurar dinámicamente y de forma centralizada el reenvío de datos en los bridges y/o routers. Otros van más allá, y creen que la configurabilidad de la red no debe limitarse a un control de los flujos y que esta tendencia SDN nos lleva directamente a la completa virtualización de la red (Network as a Service / NaaS). Es importante no confundir con el concepto de virtualización de computadoras. NaaS pretende un paso más allá, disponiendo de toda una red física, con elementos distribuidos que son vistos como un todo, un conjunto de recursos de computación y de red, disponibles para su configuración bajo demanda del usuario. Ésta es la visión de compañías como por ejemplo VMWare (gracias a la adquisición de Nicira el verano pasado) o Arista, y están apostando fuerte por ello.

Pero en este artículo quería centrarme en las redes orientadas a servicio (y dejando el tema de la virtualización de la red para siguientes entradas). Las redes orientadas a servicio es una línea de SDN surgida antes que las comentadas anteriormente, aunque complementaria, pues sienta las bases de posibles métodos de virtualización de las redes, y podría hacer uso de OpenFlow para la coordinación de los elementos de red.

En esencia, la arquitectura orientada a servicios (Service Oriented Architecture), es un paradigma que define la arquitectura de software a partir de la modularización de funcionalidades en servicios y la combinación de ellos para dar un servicio final, más complejo.  Cierto es que la computación orientada a servicios no es algo especialmente novedoso, y está basada en los mismos conceptos que la computación orientada a componentes (CBC). Ambas parten de la división de un servicio complejo en funcionalidades más pequeñas (Atomic Services), las cuales deben tener unas interfaces de interacción bien definidas, realizar acciones concretas y bien acotadas, y un comportamiento auto-contenido, es decir, que la acción definida por un servicio atómico no dependa de otro (al menos no más allá de los datos que haya podido proporcionar previamente a través de la interfaz de entrada). Estos servicios pueden ser distribuidos en diferentes lugares, para después ser coordinados e invocados en un orden específico, dando lugar a un flujo de trabajo (workflow) determinado para ofrecer el servicio complejo. Este funcionamiento está ampliamente extendido en el ámbito de los Web-Services, los cuales se ayudan de lenguajes de definición de procesos guiados por reglas y requisitos de negocio para realizar el proceso de composición de los servicios.

¿Por qué no se puede aplicar los mismos conceptos de modularización en funcionalidades de red, y activar o desactivar características de forma dinámica (on Demand)?

¿Por qué siempre tenemos que realizar las conexiones utilizando los mismos protocolos si la red está formada por diferentes segmentos con características de canal muy diferentes?

¿Por qué estamos forzados a utilizar siempre (e incluso a veces por duplicado o triplicado) unas funcionalidades (seguridad, fiabilidad, sincronización, etc.) cuando a veces no las necesitamos ?

La idea de aplicar las arquitecturas orientadas a servicio a las redes tiene como objetivo separar funcionalidades básicas (p.ej. integridad de datos y control de errores, control de flujo, reenvío de paquetes, sincronización, mecanismos de seguridad), que están proveídas por diferentes elementos de red (o los extremos de la comunicación), y ubicarlas de forma dinámica en los diferentes dispositivos. Con esto conseguiríamos mejorar la eficiencia y reducir el consumo de los recursos red y reducir la redundancia de datos, seleccionando las funcionalidades sólo en caso de ser necesarias, bajo demanda. De esta forma, transformaríamos estas funcionalidades en servicios, independientes, fáciles de organizar y distribuir, y invocables remotamente mediante interfaces de control previamente definidas.

Algunos proyectos como SONATE (dentro del proyecto alemán G-LAB), ChoiceNet (liderado por Tilman Wolf, de la Universidad de Massachussets y con fondos de la NSF) o TARIFA (proyecto liderado por i2cat y con participación de La Salle R&D) han seguido esta línea.

En el caso de TARIFA, The Atomic Redesign of Internet Future Architecture, el cual hemos podido tener en La Salle participación directa, se definió una arquitectura basada en servicios y un conjunto básico de 21 servicios atómicos (Encoding and Signaling, Sequencing, Data Forwarding, Fragmentation and Reassembly, Access Control, Congestion Control, etc.). De éstos, en el proyecto finalmente sólo se implementaron algunos, haciendo una demostración sobre un escenario de 13 máquinas Linux (algunas actuando como routers otras como servidores o usuarios finales). Todas las máquinas constaban de una API de socket modificada, para configurar cuales de las funcionalidades/servicio atómicos se podrían activar en cada nodo.

Uno de los principales retos fue la orquestación de estos servicios, es decir el proceso de decisión de donde serán ubicados estos servicios. Este proceso estuvo basado en una serie de reglas estáticas, que funcionaron correctamente colocando mecanismos de encriptación de datos y diferentes controles de error sólo en algunos segmentos de red, en función de la fiabilidad de los enlaces. A pesar de ello, hay que tener en cuenta que la prueba se realizó en un entorno limitado (en cuanto a número de servicios) y controlado (topología y características de red conocidas), y todavía queda mucho trabajo por hacer en el campo de la composición de servicios a nivel de red.

Por suerte, hay muy buenas iniciativas alineadas con esta mentalidad, como el recién creado grupo en Network Functions Virtualisation (NFV) de European Telecommunication Standardisation Institute (ETSI), que pretende la virtualización de las funcionalidades de red como pequeños componentes SW, orquestables sobre una infrastructura de red virtualizada. Extenderemos la visión y el trabajo inicial de este grupo en siguientes entradas.