CK Geek: RINA: Breve introducción a su arquitectura y sus principios de arquitectura

En el anterior artículo hablamos sobre los defectos que tiene la arquitectura de red TCP/IP actual. Antes de empezar a desarrollar cómo RINA mejora los defectos que tiene la arquitectura actual, me gustaría matizar algo que considero importante. RINA no se plantea como un reemplazo del TCP/IP. RINA nace con la motivación de proponer una arquitectura nueva donde TCP/IP no puede llegar.

Figura 1: RINA: Breve introducción a su arquitectura y sus principios de arquitectura

RINA se puede desplegar de manera incremental interoperando con las tecnologías actuales. No necesita un despliegue limpio como por ejemplo si necesita IPv6. Es decir, puede funcionar en varios casos de uso distintos (por encima de una red Ethernet, por encima de una red IP, etcétera).

Principios de la arquitectura

RINA de manera general, se basa en el principio de maximizar los invariantes en la arquitectura, de modo que se pueda minimizar el número de protocolos. La siguiente figura ejemplifica esta afirmación de manera gráfica.

Figura 2: Representación abstracta de la arquitectura y los protocolos de red

actuales frente al objetivo deseado. Fuente: RINA ETSI Report

Lo que se pretende en RINA es solucionar la mayoría de problemas complejos dentro de la arquitectura, es decir, todas las cuestiones que no dependan de los requisitos de cada red, solucionarlos dentro de la arquitectura de manera que tendremos menos protocolos y estos se parecerán más entre ellos.

¿Qué es la red?

Como hemos explicado en el artículo anterior, la red no es más que el canal que permite comunicación entre aplicaciones (por ejemplo, Skype, e-Mail, WhatsApp, etcétera). Por tanto, la red es en sí misma, una aplicación distribuida especializada en proveer este canal de comunicación entre aplicaciones (es decir, procesos).

En RINA, a este canal se le llama DIF (Distributed IPC Facility), que viene a significar exactamente lo que veníamos diciendo, una aplicación que provee servicios de comunicación entre procesos. Como primer modelo podríamos tener un solo DIF que proporcione a dos aplicaciones capacidad para comunicarse.

Figura 3: Representación de un DIF para proporcionar IPC entre dos endpoints.

Fuente: Eduard Grasa, diapositivas Introducción a RINA

Pero no nos podemos quedar tranquilos así. Si solo tenemos un DIF para dar comunicación a todas las aplicaciones del mundo, no funcionaria, ergo no es escalable. Pero esto es algo que podemos solucionar de manera relativamente sencilla. Necesitamos aislar los diferentes scopes en las redes.

Figura 4: Representación de varios DIFs para proporcionar IPC entre 2

endpoints. Fuente: Eduard Grasa, diapositivas Introducción a RINA

Lo que tenemos en RINA entonces, son múltiples DIFs que proveen IPC entre ellos. Al fin y al cabo, un DIF simplemente es una aplicación distribuida. ¿Y cuántos DIFs se tienen que usar en una red? Pues tantos co mo el diseñador de la red considere oportunos para el caso de uso que se quiere proveer IPC. Por ejemplo, habrá un DIF (rojo) que estará por encima del nivel físico, que se adaptará a la tecnología que modula la información por debajo (aire, fibra, cable, etcétera); o bien puede interesar tener un segmento de red metropolitano (azul) más lejos de los usuarios, que agregue más cantidad de tráfico al flujo.

Al final, lo que tenemos es una arquitectura más abstracta y más sencilla, ya que en una red solo se tiene el mismo elemento repetido N veces. Con lo cual, gestionar la red se hace más fácil, ya que solo sabiendo cómo se comporta un DIF y cómo se relaciona con otro DIF (o aplicación, porque interactúan de la misma manera), se puede generalizar a cómo interactúa toda la red con todos los elementos que la componen. De aquí viene lo de Recursive en RINA, ya que (abusando del término) lo que se tiene es un mismo tipo de capa que se va repitiendo y se usan los servicios de una capa a otra de la misma manera que las aplicaciones usan los servicios de ella.

Importante hacer énfasis en que las distintas capas (distintos DIFs) no tienen funcionalidades distintas, solo se ocupan de proveer servicios de comunicación entre procesos en un scope. Entonces, un DIF provee servicios para que dos aplicaciones se comuniquen, pero… ¿Puede haber varias aplicaciones usando los servicios de un mismo DIF? Por supuesto, de hecho, de manera más concreta, un DIF proporciona los servicios de comunicación asignando recursos (memoria en buffers, capacidad de ancho de banda, etcétera) para las distintas aplicaciones. Luego, las aplicaciones piden un flujo de comunicación al DIF con unos requisitos concretos y compiten unas aplicaciones con otras para poder obtener ese flujo.

Dentro del DIF

¿Y qué hay dentro de un DIF exactamente? Dentro de los DIFs, siguiendo la filosofía de RINA, también se pretende simplificar al máximo su estructura interna (siguiendo el principio de maximizar las invariancias). Las funciones que hace un DIF se clasifican en tres tipos:

Funciones de transferencia de datos

Funciones de control de transferencia de datos

Funciones de gestión de capa

Para poder realizar estas funciones, se necesitan de protocolos, tal y como nos p asa en la arquitectura actual. Pero recordamos que queremos tener los mínimos protocolos y lo más simple posible. Para minimizar la variabilidad entre protocolos dentro del DIF al mínimo, lo que se hace es separar entre mecanismo y policy.

Los mecanismos son las partes fijas en un protocolo. Por ejemplo, el acknowledgement (ACK); que es un tipo de mensaje que se utiliza para saber si un paquete ha llegado correctamente a su destino.

Policy es la parte del protocolo que cambia. Por ejemplo, cuando y cómo enviar un ACK es una policy.

Y con esta premisa de separar entre mecanismo y policy, nos sale que solamente con dos protocolos es suficiente para cubrir las tres funcionalidades del DIF: EFCP para transferencia y control de transferencia de datos, y CDAP para gestión de capa.

Nombres y direccionamiento

Sin entrar mucho en detalle, ya que de esto ya hemos hablado en el otro artículo, RINA plantea un esquema de nombres que facilita la movilidad, simplifica el enrutamiento de tráfico y proporciona multi-homing de manera nativa.

Figura 5: Estructura de nombres y direccionamento en RINA.

Fuente: Eduard Grasa, diap ositivas Introducción a RINA

Como ya hemos discutido anteriormente, necesitamos que las aplicaciones tengan un nombre, y que lo conserven independientemente de donde se encuentren. Luego tenemos direcciones de nodo, que nos dan pistas sobre dónde viven las aplicaciones. A continuación mostramos una tabla comparativa con el sistema de nombres actual

Figura 6: Tabla comparativa.

Por último, tenemos las direcciones de punto de anclaje (point of attachment), que estas direcciones sí que nos dicen cómo llegar a donde viven las aplicaciones.

Conclusión

Si has llegado hasta al final, te habrás dado cuenta de que RINA proporciona una arquitectura bastante abstracta, y en consecuencia, el objetivo final de RINA es poder tener un framework que permita desarrollar protocolos y así poder simplificar las redes en general. Como he dicho en el principio del artículo, se puede aplicar RINA en ábmbitos concretos, como por ejemplo dentro de los centros de datos.

Figura 7: Future Internet and RIMA

Al ser una tecnología relativamente nueva, la idea es ir empezando con casos de usos muy sencillos y poco a poco irse moviendo a casos de usos más grande s y complejos. Os dejamos algunos enlaces que podrían ser interesantes.

Future Internet and RINA Architecture | EduTec&Cria: Charla de Eduard Grasa, la cual se ha usado de guía y referencia para escribir estos dos artículos. De hecho, estos dos artículos se podrían considerar como una síntesis/introducción de esta charla. Esta charla explica de manera muy entendedora y sencilla qué problemas tiene la arquitectura actual y cómo RINA puede solucionarlos.