La arquitectura recursiva de interredes (RINA) es una nueva arquitectura de red informática propuesta como alternativa a la arquitectura de la suite de protocolos de Internet actualmente dominante . Los principios detrás de RINA fueron presentados por primera vez por John Day en su libro de 2008 Patterns in Network Architecture: A return to Fundamentals . [1] Este trabajo es un nuevo comienzo, teniendo en cuenta las lecciones aprendidas en los 35 años de existencia de TCP/IP , así como las lecciones del fracaso de OSI y las lecciones de otras tecnologías de red de las últimas décadas, como CYCLADES , DECnet y Xerox Network Systems . Los principios fundamentales de RINA son que las redes informáticas son simplemente comunicación entre procesos o IPC, y que la superposición debe realizarse en función del alcance/escala, con un único conjunto recurrente de protocolos, en lugar de basarse en la función, con protocolos especializados. Las instancias de protocolo en una capa interactúan con las instancias de protocolo en capas superiores e inferiores a través de nuevos conceptos y entidades que reifican de manera efectiva las funciones de red actualmente específicas de protocolos como BGP , OSPF y ARP . De esta manera, RINA afirma admitir características como movilidad, multihoming y calidad de servicio sin la necesidad de protocolos especializados adicionales como RTP y UDP , así como permitir una administración de red simplificada sin la necesidad de conceptos como sistemas autónomos y NAT .
RINA es el resultado de un esfuerzo por desarrollar principios generales en redes de computadoras que se apliquen en todas las situaciones. RINA es la arquitectura, implementación, plataforma de prueba y, en última instancia, implementación específicas del modelo conocido informalmente como modelo IPC, [2] aunque también trata conceptos y resultados que se aplican a cualquier aplicación distribuida, no solo a las redes. Al provenir de aplicaciones distribuidas, la mayor parte de la terminología proviene del desarrollo de aplicaciones en lugar de las redes, lo cual es comprensible, dado que el principio fundamental de RINA es reducir las redes a IPC.
La entidad básica de RINA es el Proceso de Aplicación Distribuida o DAP, que frecuentemente corresponde a un proceso en un host. Dos o más DAP constituyen una Instalación de Aplicación Distribuida o DAF, como se ilustra en la Figura 1. Estos DAP se comunican utilizando el Protocolo de Aplicación Distribuida Común o CDAP, intercambiando datos estructurados en forma de objetos. Estos objetos están estructurados en una Base de Información de Recursos o RIB, que les proporciona un esquema de nombres y una organización lógica. El CDAP proporciona seis operaciones básicas en los objetos de un DAP remoto: crear, eliminar, leer, escribir, iniciar y detener. [ cita requerida ]
Para intercambiar información, los DAP necesitan una función subyacente cuya tarea es proporcionar y gestionar servicios de IPC en un ámbito determinado. Esta función es otra DAF, denominada Distributed IPC Facility o DIF. Una DIF permite a un DAP asignar flujos a uno o más DAP, simplemente proporcionando los nombres de los DAP de destino y los parámetros de calidad de servicio deseados, como límites de pérdida de datos y latencia, entrega ordenada o desordenada, confiabilidad, etc. Por ejemplo, los DAP pueden no confiar en el DIF que están utilizando y, por lo tanto, pueden proteger sus datos antes de escribirlos en el flujo a través de un módulo de protección SDU , por ejemplo, cifrándolos. Los DAP de un DIF se denominan IPC Processes o IPCP. Tienen la misma estructura genérica de DAP que se muestra en la Figura 3, más algunas tareas específicas para proporcionar y gestionar IPC. Estas tareas, como se muestra en la Figura 4, se pueden dividir en tres categorías, en orden de complejidad creciente y frecuencia decreciente: [ cita requerida ]
Por lo tanto, en la mayoría de los modelos de red contemporáneos, un DAF corresponde a la capa de aplicación y un DIF a la capa inmediatamente inferior, y las tres categorías de tareas anteriores corresponden a la gran mayoría de las tareas no solo de operaciones de red, sino también de gestión de red e incluso de autenticación (con algunos ajustes en la responsabilidad, como se verá más adelante). [ cita requerida ]
Los DIF, al ser DAF, a su vez utilizan otros DIF subyacentes, llegando hasta el DIF de capa física que controla los cables y conectores. De aquí proviene la recursión de RINA. Todas las capas de RINA tienen la misma estructura y componentes y proporcionan las mismas funciones; difieren solo en sus alcances, configuraciones o políticas (reflejando la separación de mecanismo y política en los sistemas operativos). [3] Como se muestra en la Figura 2, las redes RINA suelen estructurarse en DIF de alcance creciente. La Figura 3 muestra un ejemplo de cómo se podría estructurar la Web con RINA: la capa más alta es la más cercana a las aplicaciones, correspondiente al correo electrónico o sitios web; las capas más bajas agregan y multiplexan el tráfico de las capas superiores, correspondientes a las redes troncales de ISP . Los DIF de múltiples proveedores (como Internet pública u otros) flotan sobre las capas de ISP. En este modelo, se distinguen tres tipos de sistemas: hosts, que contienen DAP; enrutadores interiores, internos a una capa; y enrutadores de borde, en los bordes de una capa, donde los paquetes suben o bajan una capa.
En resumen, RINA conserva los conceptos de PDU y SDU, pero en lugar de estratificar por función, lo hace por alcance. Las capas no corresponden a diferentes responsabilidades, sino a diferentes escalas, y el modelo está diseñado específicamente para ser aplicable desde una única conexión Ethernet punto a punto hasta la Web. Por lo tanto, RINA es un intento de reutilizar la mayor cantidad posible de teoría y eliminar la necesidad de un diseño de protocolo ad hoc, reduciendo así la complejidad de la construcción, la gestión y la operación de la red en el proceso. [ cita requerida ]
Como se explicó anteriormente, la dirección IP es un identificador de nivel demasiado bajo en el que basar la multilocalización y la movilidad de manera eficiente, además de requerir que las tablas de enrutamiento sean más grandes de lo necesario. La literatura de RINA sigue la teoría general de Jerry Saltzer sobre direccionamiento y denominación. Según Saltzer, se deben identificar cuatro elementos: aplicaciones, nodos, puntos de conexión y rutas. [4] Una aplicación puede ejecutarse en uno o más nodos y debería poder moverse de un nodo a otro sin perder su identidad en la red. Un nodo puede estar conectado a un par de puntos de conexión y debería poder moverse entre ellos sin perder su identidad en la red. Un directorio asigna un nombre de aplicación a una dirección de nodo, y las rutas son secuencias de direcciones de nodo y puntos de conexión. Estos puntos se ilustran en la Figura 4.
Saltzer tomó su modelo de los sistemas operativos, pero los autores de RINA concluyeron que no se podía aplicar de forma limpia a las interredes, que pueden tener más de una ruta entre el mismo par de nodos (y mucho menos redes completas). Su solución es modelar las rutas como secuencias de nodos: en cada salto, el nodo respectivo elige el punto de conexión más apropiado para reenviar el paquete al siguiente nodo. Por lo tanto, RINA enruta en un proceso de dos pasos: primero, se calcula la ruta como una secuencia de direcciones de nodo y luego, para cada salto, se selecciona un punto de conexión apropiado. Estos son los pasos para generar la tabla de reenvío: el reenvío todavía se realiza con una única búsqueda. Además, el último paso se puede realizar con mayor frecuencia para aprovechar el multihoming para equilibrar la carga. [ cita requerida ]
Con esta estructura de nombres, la movilidad y el multihoming se admiten de forma inherente [5] si los nombres tienen propiedades cuidadosamente elegidas:
La aplicación de este esquema de nombres a RINA con sus capas recursivas permite concluir que la asignación de nombres de aplicaciones a direcciones de nodos es análoga a la asignación de direcciones de nodos a puntos de conexión. En pocas palabras, en cualquier capa, los nodos de la capa superior pueden considerarse aplicaciones, mientras que los nodos de la capa inferior pueden considerarse puntos de conexión.
El conjunto de protocolos de Internet también dicta en general que los protocolos se diseñen de forma aislada, sin tener en cuenta si algunos aspectos se han duplicado en otros protocolos y, por lo tanto, si estos pueden convertirse en una política. RINA intenta evitar esto aplicando la separación de mecanismo y política en los sistemas operativos al diseño de protocolos. [6] Cada DIF utiliza diferentes políticas para proporcionar diferentes clases de calidad de servicio y adaptarse a las características de los medios físicos, si el DIF es de bajo nivel, o de las aplicaciones, si el DIF es de alto nivel.
RINA utiliza la teoría del protocolo Delta-T [7] desarrollado por Richard Watson en 1981. La investigación de Watson sugiere que las condiciones suficientes para una transferencia confiable son limitar tres temporizadores. Delta-T es un ejemplo de cómo debería funcionar esto: no tiene una configuración o desconexión de la conexión. La misma investigación también señala que TCP ya utiliza estos temporizadores en su funcionamiento, lo que hace que Delta-T sea comparativamente más simple. La investigación de Watson también sugiere que la sincronización y la asignación de puertos deberían ser funciones distintas, siendo la asignación de puertos parte de la gestión de capas y la sincronización parte de la transferencia de datos.
Para garantizar la seguridad, RINA requiere que cada DIF/DAF especifique una política de seguridad, cuyas funciones se muestran en la Figura 5. Esto permite proteger no solo las aplicaciones, sino también las redes troncales y las estructuras de conmutación. Una red pública es simplemente un caso especial en el que la política de seguridad no hace nada. Esto puede introducir una sobrecarga para redes más pequeñas, pero se escala mejor con redes más grandes porque las capas no necesitan coordinar sus mecanismos de seguridad: se estima que Internet actual requiere alrededor de 5 veces más entidades de seguridad distintas que RINA. [8] Entre otras cosas, la política de seguridad también puede especificar un mecanismo de autenticación; esto deja obsoletos los firewalls y las listas negras porque un DAP o IPCP que no puede unirse a un DAF o DIF no puede transmitir ni recibir. Los DIF tampoco exponen sus direcciones IPCP a capas superiores, lo que evita una amplia clase de ataques de intermediarios.
El diseño del propio protocolo Delta-T, con su énfasis en la simplicidad, también es un factor. Por ejemplo, dado que el protocolo no tiene protocolo de enlace, no tiene mensajes de control correspondientes que se puedan falsificar ni estados que se puedan usar de forma incorrecta, como en una inundación SYN. El mecanismo de sincronización también hace que el comportamiento aberrante esté más correlacionado con los intentos de intrusión, lo que hace que los ataques sean mucho más fáciles de detectar. [9]
El punto de partida para una arquitectura de red radicalmente nueva y diferente como RINA es un intento de resolver o una respuesta a los siguientes problemas que no parecen tener soluciones prácticas o libres de compromisos con las arquitecturas de red actuales, especialmente el conjunto de protocolos de Internet y su estructura funcional en capas como se muestra en la Figura 6:
Aunque estos problemas son mucho más visibles hoy en día, ha habido precedentes y casos casi desde el comienzo de ARPANET , el entorno en el que se diseñó el conjunto de protocolos de Internet:
En 1972, la base aérea Tinker [15] quería conexiones a dos IMP diferentes para redundancia. Los diseñadores de ARPANET se dieron cuenta de que no podían soportar esta característica porque las direcciones de host eran las direcciones del número de puerto IMP al que estaba conectado el host (tomando prestadas las direcciones de la telefonía). Para ARPANET, dos interfaces del mismo host tenían direcciones diferentes; en otras palabras, la dirección era de un nivel demasiado bajo para identificar un host.
Las versiones iniciales de TCP realizaban las funciones de control de flujo y error (actual TCP) y de retransmisión y multiplexación (IP) en el mismo protocolo. En 1978, TCP se separó de IP a pesar de que las dos capas tenían el mismo alcance. En 1987, la comunidad de redes era muy consciente de los problemas de la fragmentación de IP, hasta el punto de considerarla perjudicial. [16] Sin embargo, no se entendía como un síntoma de que TCP e IP fueran interdependientes.
En 1981, Richard Watson proporcionó una teoría fundamental de transporte confiable [17] según la cual la administración de la conexión requiere solo temporizadores limitados por un pequeño factor del Tiempo Máximo de Vida del Paquete (MPL). Basándose en esta teoría, Watson et al. desarrollaron el protocolo Delta-t [7] que permite determinar el estado de una conexión simplemente limitando tres temporizadores, sin protocolo de enlace. Por otro lado, TCP utiliza tanto protocolo de enlace explícito como una administración más limitada basada en temporizadores del estado de la conexión.
A principios de 1972 se creó el International Network Working Group (INWG) para reunir a la naciente comunidad de investigación en redes. Una de las primeras tareas que realizó fue votar un protocolo de transporte de red internacional, que fue aprobado en 1976. [18] Sorprendentemente, la opción seleccionada, así como todos los demás candidatos, tenía una arquitectura compuesta por tres capas de alcance creciente: enlace de datos (para manejar diferentes tipos de medios físicos), red (para manejar diferentes tipos de redes) e interconexión de redes (para manejar una red de redes), cada capa con su propio espacio de direcciones. Cuando se introdujo TCP/IP, se ejecutaba en la capa de interconexión de redes sobre el protocolo Host-IMP , cuando se ejecutaba sobre ARPANET. Pero cuando se cerró NCP , TCP/IP asumió el papel de red y se perdió la capa de interconexión de redes. [19] Esto explica la necesidad de sistemas autónomos y NAT en la actualidad, para particionar y reutilizar rangos del espacio de direcciones IP para facilitar la administración.
La necesidad de una dirección de nivel superior a la dirección IP se entendió bien desde mediados de la década de 1970. Sin embargo, no se introdujeron los nombres de aplicación y se diseñó e implementó el DNS, que siguió utilizando puertos conocidos para identificar aplicaciones. La llegada de la web y el HTTP creó la necesidad de nombres de aplicación, lo que dio lugar a las URL. Sin embargo, las URL vinculan cada instancia de aplicación a una interfaz física de una computadora y a una conexión de transporte específica, ya que la URL contiene el nombre DNS de una interfaz IP y el número de puerto TCP, lo que transmite los problemas de multihoming y movilidad a las aplicaciones. [ cita requerida ]
Aunque el problema del control de la congestión en las redes de datagramas se conocía desde los años 70 y principios de los 80, [20] [21] el colapso de la congestión en 1986 tomó a Internet por sorpresa. Lo que es peor, el control de la congestión adoptado -el esquema de prevención de la congestión de Ethernet , con algunas modificaciones- se incluyó en TCP.
En 1988, IAB recomendó utilizar SNMP como el protocolo de gestión de red inicial para Internet para luego realizar la transición al enfoque orientado a objetos de CMIP . [22] SNMP fue un paso atrás en la gestión de red, justificado como una medida temporal mientras se implementaban los enfoques más sofisticados requeridos, pero la transición nunca ocurrió.
En 1992, el IAB elaboró una serie de recomendaciones para resolver los problemas de escalabilidad de la Internet basada en IPv4 : consumo de espacio de direcciones y explosión de información de enrutamiento. Se propusieron tres opciones: introducir CIDR para mitigar el problema; diseñar la próxima versión de IP (IPv7) basada en CLNP ; o continuar la investigación sobre nombres, direccionamiento y enrutamiento. [23] CLNP era un protocolo basado en OSI que se dirigía a nodos en lugar de interfaces, solucionando el antiguo problema de multihoming que se remontaba a ARPANET y permitiendo una mejor agregación de información de enrutamiento. Se introdujo CIDR, pero el IETF no aceptó un IPv7 basado en CLNP. El IAB reconsideró su decisión y comenzó el proceso IPng, que culminó con IPv6 . Una de las reglas para IPng era no cambiar la semántica de la dirección IP, que sigue nombrando la interfaz, perpetuando el problema de multihoming. [13]
Desde la publicación del libro de PNA en 2008 hasta 2014, se ha realizado una gran cantidad de trabajo de investigación y desarrollo de RINA. Un grupo informal conocido como la Sociedad Pouzin, que lleva el nombre de Louis Pouzin , [24] coordina varios esfuerzos internacionales.
El equipo de investigación RINA de la Universidad de Boston está dirigido por los profesores Abraham Matta, John Day y Lou Chitkushev, y ha recibido varias subvenciones de la National Science Foundation y la CE para seguir investigando los fundamentos de RINA, desarrollar una implementación de prototipo de código abierto sobre UDP/IP para Java [25] [26] y experimentar con él sobre la infraestructura GENI. [27] [28] La BU también es miembro de la Pouzin Society y colaboradora activa de los proyectos IRATI y PRISTINE del 7PM. Además de esto, la BU ha incorporado los conceptos y la teoría de RINA en sus cursos de redes informáticas.
IRATI es un proyecto financiado por el FP7 con cinco socios: i2CAT, Nextworks, iMinds, Interoute y la Universidad de Boston. Ha producido una implementación RINA de código abierto para el sistema operativo Linux sobre Ethernet. [29] [30]
PRISTINE es un proyecto financiado por el 7PM con 15 socios: WIT-TSSG, i2CAT, Nextworks, Telefónica I+D, Thales, Nexedi, B-ISDN, Atos, Universidad de Oslo, Juniper Networks, Universidad de Brno, IMT-TSP, CREATE-NET, iMinds y UPC. Su principal objetivo es explorar los aspectos de programabilidad de RINA para implementar políticas innovadoras para el control de la congestión, la asignación de recursos, el enrutamiento, la seguridad y la gestión de la red. [ cita requerida ]
IRINA fue financiado por la convocatoria abierta GÉANT3 + y es un proyecto con cuatro socios: iMinds, WIT-TSSG, i2CAT y Nextworks. El objetivo principal de IRINA es estudiar el uso de la arquitectura recursiva de interredes (RINA) como base de las arquitecturas de red NREN y GÉANT de próxima generación. IRINA se basa en el prototipo IRATI y comparará RINA con el estado actual de la técnica de redes y la arquitectura de borrón y cuenta nueva relevante en investigación; realizará un estudio de caso de uso sobre cómo se podría utilizar mejor RINA en los escenarios de NREN; y mostrará una prueba de laboratorio del estudio. [ cita requerida ]