Hispanopedia Wiki
Articulo de referencia

Arquitectura de interconexión recursiva

La Arquitectura de Interred Recursiva (RINA) es una nueva arquitectura de red informática propuesta como alternativa a la arquitectura del conjunto de protocolos de Internet act...

Hispanopedia WikiContenido en espanolLectura gratuita

La Arquitectura de Interred Recursiva (RINA) es una nueva arquitectura de red informática propuesta como alternativa a la arquitectura del conjunto de protocolos de Internet actualmente dominante . Los principios en los que se basa 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, que toma 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 estratificación debe hacerse en función del alcance/escala, con un único conjunto recurrente de protocolos, en lugar de en función de 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 mediante nuevos conceptos y entidades que materializan funciones de red actualmente específicas de protocolos como BGP , OSPF y ARP . De esta forma, RINA afirma admitir características como movilidad, multihoming y calidad de servicio sin necesidad de protocolos especializados adicionales como RTP y UDP , así como permitir una administración de red simplificada sin necesidad de conceptos como sistemas autónomos y NAT .

Descripción general

Figura 1. Procesos de aplicación distribuidos (DAP) y sus componentes.

RINA es el resultado de un esfuerzo por desarrollar principios generales en redes informáticas que se apliquen en todas las situaciones. RINA es la arquitectura específica, la implementación, la plataforma de pruebas y, en última instancia, el despliegue del modelo conocido informalmente como modelo IPC, [ 2 ] aunque también aborda conceptos y resultados que se aplican a cualquier aplicación distribuida, no solo a redes. Proveniente de aplicaciones distribuidas, la mayor parte de la terminología proviene del desarrollo de aplicaciones en lugar de redes, lo cual es comprensible, dado que el principio fundamental de RINA es reducir las redes a IPC.

The basic entity of RINA is the Distributed Application Process or DAP, which frequently corresponds to a process on a host. Two or more DAPs constitute a Distributed Application Facility or DAF, as illustrated in Figure 1. These DAPs communicate using the Common Distributed Application Protocol or CDAP, exchanging structured data in the form of objects. These objects are structured in a Resource Information Base or RIB, which provides a naming schema and a logical organization to them. CDAP provides six basic operations on a remote DAP's objects: create, delete, read, write, start and stop.

In order to exchange information, DAPs need an underlying facility whose task is to provide and manage IPC services over a certain scope. This facility is another DAF, called a Distributed IPC Facility or DIF. A DIF enables a DAP to allocate flows to one or more DAPs, by just providing the names of the targeted DAPs and the desired QoS parameters such as bounds on data loss and latency, ordered or out-of-order delivery, reliability, and so forth. For example, DAPs may not trust the DIF they are using and may therefore protect their data before writing it to the flow via a SDU protection module, for example by encrypting it. The DAPs of a DIF are called IPC Processes or IPCPs. They have the same generic DAP structure shown in Figure 3, plus some specific tasks to provide and manage IPC. These tasks, as shown in Figure 4, can be divided into three categories, in order of increasing complexity and decreasing frequency:

  1. data transfer,
  2. data transfer control and
  3. layer management.

A DAF thus corresponds to the application layer, and a DIF to the layer immediately below, in most contemporary network models, and the three previous task categories correspond to the vast majority of tasks of not just network operations, but network management and even authentication (with some adjustments in responsibility as will be seen below).

Figure 2. Example of RINA networks and IPCP components

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 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 estar estructuradas en DIF de alcance creciente. La Figura 3 muestra un ejemplo de cómo podría estructurarse la Web con RINA: la capa más alta es la más cercana a las aplicaciones, correspondiente al correo electrónico o los sitios web; las capas más bajas agregan y multiplexan el tráfico de las capas superiores, correspondiente a las redes troncales de los ISP . Los DIF de múltiples proveedores (como Internet pública u otros) flotan sobre las capas de los ISP. En este modelo, se distinguen tres tipos de sistemas: hosts, que contienen DAP; enrutadores internos, internos a una capa; y enrutadores de borde, en los límites de una capa, donde los paquetes suben o bajan una capa.

Figura 3. Múltiples redes RINA que dan soporte a varias interredes.

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 busca reutilizar la mayor cantidad de teoría posible y eliminar la necesidad de diseñar protocolos ad hoc, reduciendo así la complejidad de la construcción, la gestión y la operación de la red.

Nomenclatura, direccionamiento, enrutamiento, movilidad y multiconexión.

Como se explicó anteriormente, la dirección IP es un identificador de nivel demasiado bajo para basar la multihoming y la movilidad de manera eficiente, además de requerir tablas de enrutamiento más grandes de lo necesario. La literatura RINA sigue la teoría general de Jerry Saltzer sobre direccionamiento y nombres. 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 debe 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 debe 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.

Figura 4. Ilustración de la teoría de Saltzer sobre la denominación y el direccionamiento.

Saltzer took his model from operating systems, but the RINA authors concluded it could not be applied cleanly to internetworks, which can have more than one path between the same pair of nodes (let alone whole networks). Their solution is to model routes as sequences of nodes: at each hop, the respective node chooses the most appropriate attachment point to forward the packet to the next node. Therefore, RINA routes in a two-step process: first, the route as a sequence of node addresses is calculated, and then, for each hop, an appropriate attachment point is selected. These are the steps to generate the forwarding table: forwarding is still performed with a single lookup. Moreover, the last step can be performed more frequently to exploit multihoming for load balancing.

With this naming structure, mobility and multihoming are inherently supported[5] if the names have carefully chosen properties:

  1. application names are location-independent to allow an application to move around;
  2. node addresses are location-dependent but route-independent; and
  3. attachment points are by nature route-dependent.

Applying this naming scheme to RINA with its recursive layers allows the conclusion that mapping application names to node addresses is analogous to mapping node addresses to attachment points. Put simply, at any layer, nodes in the layer above can be seen as applications while nodes in the layer below can be seen as attachment points.

Protocol design

The Internet protocol suite also generally dictates that protocols be designed in isolation, without regard to whether aspects have been duplicated in other protocols and, therefore, whether these can be made into a policy. RINA tries to avoid this by applying the separation of mechanism and policy in operating systems to protocol design.[6] Each DIF uses different policies to provide different classes of quality of service and adapt to the characteristics of either the physical media, if the DIF is low-level, or the applications, if the DIF is high-level.

RINA uses the theory of the Delta-T protocol[7] developed by Richard Watson in 1981. Watson's research suggests that sufficient conditions for reliable transfer are to bound three timers. Delta-T is an example of how this should work: it does not have a connection setup or tear-down. The same research also notes that TCP already uses these timers in its operation, making Delta-T comparatively simpler. Watson's research also suggests that synchronization and port allocation should be distinct functions, port allocation being part of layer management, and synchronization being part of data transfer.

Security

Figure 5. Organization of security functions in RINA.

To accommodate security, RINA requires each DIF/DAF to specify a security policy, whose functions are shown in Figure 5. This allows securing not just applications, but backbones and switching fabrics themselves. A public network is simply a special case where the security policy does nothing. This may introduce overhead for smaller networks, but it scales better with larger networks because layers do not need to coordinate their security mechanisms: the current Internet is estimated as requiring around 5 times more distinct security entities than RINA.[8] Among other things, the security policy can also specify an authentication mechanism; this obsoletes firewalls and blacklists because a DAP or IPCP that can't join a DAF or DIF can't transmit or receive. DIFs also do not expose their IPCP addresses to higher layers, preventing a wide class of man-in-the-middle attacks.

The design of the Delta-T protocol itself, with its emphasis on simplicity, is also a factor. For example, since the protocol has no handshake, it has no corresponding control messages that can be forged or state that can be misused, like that in a SYN flood. The synchronization mechanism also makes aberrant behavior more correlated with intrusion attempts, making attacks far easier to detect.[9]

Background

The starting point for a radically new and different network architecture like RINA is an attempt to solve or a response to the following problems which do not appear to have practical or compromise-free solutions with current network architectures, especially the Internet protocol suite and its functional layering as depicted in Figure 6:

Figure 6. Functional layering of the TCP/IP architecture
  • Transmission complexity: the separation of IP and TCP results in inefficiency, with the MTU discovery performed to prevent IP fragmentation being the clearest symptom.
  • Performance: TCP itself carries rather high overhead with its handshake, which also causes vulnerabilities such as SYN floods. Also, TCP relies on packet dropping to throttle itself and avoid congestion, meaning its congestion control is purely reactive, not proactive or preventive. This interacts badly with large buffers, leading to bufferbloat.[10]
  • Multihoming: the IP address and port number are too low-level to identify an application in two different networks. DNS doesn't solve this because hostnames must resolve to a single IP address and port number combination, making them aliases instead of identities. Neither does LISP, because i) it still uses the locator, which is an IP address, for routing, and ii) it is based on a false distinction, in that all entities in a scope are located by their identifiers to begin with;[11] in addition, it also introduces scalability problems of its own.[12]
  • Mobility: the IP address and port number are also too low-level to identify an application as it moves between networks, resulting in complications for mobile devices such as smartphones. Though a solution, Mobile IP in reality shifts the problem entirely to the Care-of address and introduces an IP tunnel, with attendant complexity.
  • Management: the same low-level nature of the IP address encourages multiple addresses or even address ranges to be allocated to single hosts,[13] putting pressure on allocation and accelerating exhaustion. NAT only delays address exhaustion and potentially introduces even more problems. At the same time, functional layering of the Internet protocol suite's architecture leaves room for only two scopes, complicating subdivision of administration of the Internet and requiring the artificial notion of autonomous systems. OSPF and IS-IS have relatively few problems, but do not scale well, forcing usage of BGP for larger networks and inter-domain routing.
  • Security: the nature of the IP address space itself results in frail security, since there is no true configurable policy for adding or removing IP addresses other than physically preventing attachment. TLS and IPSec provide solutions, but with accompanying complexity. Firewalls and blacklists are vulnerable to overwhelming, ergo not scalable. "[...] experience has shown that it is difficult to add security to a protocol suite unless it is built into the architecture from the beginning."[14]

Though these problems are far more acutely visible today, there have been precedents and cases almost right from the beginning of the ARPANET, the environment in which the Internet protocol suite was designed:

1972: Multihoming not supported by the ARPANET

In 1972, Tinker Air Force Base[15] wanted connections to two different IMPs for redundancy. ARPANET designers realized that they couldn't support this feature because host addresses were the addresses of the IMP port number the host was connected to (borrowing from telephony). To the ARPANET, two interfaces of the same host had different addresses; in other words, the address was too low-level to identify a host.

1978: TCP split from IP

Initial TCP versions performed the error and flow control (current TCP) and relaying and multiplexing (IP) functions in the same protocol. In 1978 TCP was split from IP even though the two layers had the same scope. By 1987, the networking community was well aware of IP fragmentation's problems, to the point of considering it harmful.[16] However, it was not understood as a symptom that TCP and IP were interdependent.

1981: Watson's fundamental results ignored

Richard Watson in 1981 provided a fundamental theory of reliable transport[17] whereby connection management requires only timers bounded by a small factor of the Maximum Packet Lifetime (MPL). Based on this theory, Watson et al. developed the Delta-t protocol [7] which allows a connection's state to be determined simply by bounding three timers, with no handshaking. On the other hand, TCP uses both explicit handshaking as well as more limited timer-based management of the connection's state.

1983: Internetwork layer lost

Figure 7. The Internet architecture as seen by the INWG

Early in 1972 the International Network Working Group (INWG) was created to bring together the nascent network research community. One of the early tasks it accomplished was voting an international network transport protocol, which was approved in 1976.[18] Remarkably, the selected option, as well as all the other candidates, had an architecture composed of three layers of increasing scope: data link (to handle different types of physical media), network (to handle different types of networks) and internetwork (to handle a network of networks), each layer with its own address space. When TCP/IP was introduced it ran at the internetwork layer on top of the Host-IMP Protocol, when running over the ARPANET. But when NCP was shut down, TCP/IP took the network role and the internetwork layer was lost.[19] This explains the need for autonomous systems and NAT today, to partition and reuse ranges of the IP address space to facilitate administration.

1983: First opportunity to fix addressing missed

La necesidad de una dirección de nivel superior a la dirección IP se comprendía 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 seguía utilizando puertos conocidos para identificar las aplicaciones. La llegada de la web y el protocolo HTTP generó la necesidad de nombres de aplicación, lo que dio lugar a las URL. No obstante, las URL vinculan cada instancia de aplicación a una interfaz física de un ordenador y a una conexión de transporte específica, ya que contienen el nombre DNS de una interfaz IP y el número de puerto TCP, lo que traslada los problemas de multiconexión y movilidad a las aplicaciones.

1986: El colapso de la congestión toma a Internet por sorpresa.

Aunque el problema del control de congestión en las redes de datagramas se conocía desde los años 70 y principios de los 80, [ 10 ] [ 20 ] el colapso de la congestión en 1986 tomó a Internet por sorpresa. Lo que es peor, el control de congestión adoptado —el esquema de prevención de congestión de Ethernet , con algunas modificaciones— se implementó en TCP.

1988: La gestión de redes da un paso atrás.

En 1988, IAB recomendó usar SNMP como protocolo inicial de administración de red para Internet para luego pasar al enfoque orientado a objetos de CMIP . [ 21 ] SNMP fue un paso atrás en la administración de red, justificado como una medida temporal mientras se implementaban los enfoques más sofisticados necesarios, pero la transición nunca se produjo.

1992: Segunda oportunidad para corregir el problema de la dirección perdida

En 1992, el IAB produjo una serie de recomendaciones para resolver los problemas de escalabilidad de Internet basado 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 siguiente versión de IP (IPv7) basada en CLNP ; o continuar la investigación sobre nombres, direccionamiento y enrutamiento. [ 22 ] CLNP era un protocolo basado en OSI que direccionaba nodos en lugar de interfaces, resolviendo 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 fue no cambiar la semántica de la dirección IP, que continúa nombrando la interfaz, perpetuando el problema de multihoming. [ 13 ]

Proyectos de investigación

Desde la publicación del libro PNA en 2008 hasta 2014, se ha realizado un gran trabajo de investigación y desarrollo de RINA. Un grupo informal conocido como la Sociedad Pouzin , que lleva el nombre de Louis Pouzin , [ 23 ] coordina varios esfuerzos internacionales.

Equipo de investigación de BU

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 continuar investigando los fundamentos de RINA, desarrollar una implementación prototipo de código abierto sobre UDP/IP para Java [ 24 ] [ 25 ] y experimentar con ella sobre la infraestructura GENI. [ 26 ] [ 27 ] La ​​Universidad de Boston también es miembro de la Pouzin Society y contribuye activamente a los proyectos FP7 IRATI y PRISTINE. Además, la Universidad de Boston ha incorporado conceptos y teoría de RINA en sus cursos de redes informáticas.

FP7 IRATI

IRATI es un proyecto financiado por el FP7 con 5 socios: i2CAT, Nextworks, iMinds, Interoute y la Universidad de Boston. Ha producido una implementación de RINA de código abierto para el sistema operativo Linux sobre Ethernet . [ 28 ] [ 29 ]

FP7 PRISTINE

PRISTINE es un proyecto financiado por el FP7 con 15 socios: WIT-TSSG, i2CAT, Nextworks, Telefónica I+D, Thales, Nexedi, B-ISDN, Atos, la Universidad de Oslo , Juniper Networks , la Universidad de Brno, IMT-TSP, CREATE-NET, iMinds y UPC. Su objetivo principal es explorar los aspectos de programabilidad de RINA para implementar políticas innovadoras de control de congestión, asignación de recursos, enrutamiento, seguridad y gestión de redes.

IRINA, ganadora de la convocatoria abierta de GÉANT3+

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 de Interconexión Recursiva (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 del arte actual de las redes y con arquitecturas nuevas relevantes en investigación; realizará un estudio de caso sobre cómo se podría utilizar mejor RINA en los escenarios NREN; y presentará una prueba de laboratorio del estudio.

Véase también

Referencias

  1. ↑ Day, John (2008). Patrones en la arquitectura de redes: Un regreso a los fundamentos . Prentice Hall. ISBN 978-0-13-225242-3.
  2. ↑ Day, John; Matta, Ibrahim; Mattar, Karim (2008). Networking is IPC: A guiding principle to a better internet . Proceedings of the 2008 ACM CoNEXT Conference on - CONEXT '08. ACM Press. pp. 1– 6. doi : 10.1145/1544012.1544079 . ISBN  978-1-60558-210-8. S2CID 3287224 . 
  3. ↑ Mattar, Karim; Matta, Ibrahim; Day, John; Ishakian, Vatche; Gursun, Gonca (12 de julio de 2008). Transporte declarativo: No más protocolos de transporte que diseñar, solo políticas que especificar (Informe). hdl : 2144/1707 .
  4. ↑ J. Saltzer (agosto de 1993). Sobre la denominación y vinculación de destinos de red . Grupo de trabajo de redes. doi : 10.17487/RFC1498 . RFC 1498 .Informativo.
  5. ↑ Ishakian, Vatche; Akinwumi, Joseph; Esposito, Flavio; Matta, Ibrahim (julio de 2012). "Sobre el soporte de la movilidad y la multiconexión en arquitecturas recursivas de Internet". Computer Communications . 35 (13): 1561– 1573. doi : 10.1016/j.comcom.2012.04.027 . hdl : 2144/3809 . S2CID 3036132 . 
  6. ↑ Hansen, Per Brinch (abril de 1970). "El núcleo de un sistema de multiprogramación". Communications of the ACM . 13 (4): 238– 241. doi : 10.1145/362258.362278 . S2CID 9414037 . 
  7. 1 2 Watson, RW (4 de diciembre de 1981). Especificación del protocolo Delta-t: borrador de trabajo (Informe). doi : 10.2172/5542785 . OSTI 5542785 . 
  8. ↑ Small, Jeremiah (2012). Patrones en seguridad de redes: un análisis de la complejidad arquitectónica en la seguridad de redes con arquitectura interred recursiva (Tesis). hdl : 2144/17155 .
  9. ↑ Boddapati, Gowtham; Day, John; Matta, Ibrahim; Chitkushev, Lou (2012). Evaluación de la seguridad de una arquitectura de Internet completamente nueva . 2012 20.ª Conferencia Internacional IEEE sobre Protocolos de Red (ICNP). págs. 1–6 . doi : 10.1109/ICNP.2012.6459947 . ISBN  978-1-4673-2447-2. S2CID 7500711 . 
  10. 12Pouzin, L. (April 1981). "Methods, Tools, and Observations on Flow Control in Packet-Switched Data Networks". IEEE Transactions on Communications. 29 (4): 413–426. doi:10.1109/TCOM.1981.1095015.
  11. ↑Day, John (2008). Why Loc/Id Split Isn't the Answer(PDF) (Report).
  12. ↑D. Meyer; D. Lewis (January 23, 2009). Architectural Implications of Locator/ID separation. IETF. I-D draft-meyer-loc-id-implications-01.
  13. 12R. Hinden; S. Deering (February 2006). IP Version 6 Addressing Architecture. Network Working Group. doi:10.17487/RFC4291. RFC4291.Draft Standard. Obsoletes RFC 3513. Updated by RFC 5952, 6052, 7136, 7346, 7371 and 8064.
  14. ↑D. Clark; L. Chapin; V. Cerf; R. Braden; R. Hobby (December 1991). Towards the Future Internet Architecture. Network Working Group. doi:10.17487/RFC1287. RFC1287.Informational.
  15. ↑Froehlich, Fritz E.; Kent, Allen (1992). "ARPANET, the Defense Data Network, and Internet". The Froehlich/Kent Encyclopedia of Telecommunications. Vol. 5. CRC Press. p. 82. ISBN 978-0-8247-2903-5.
  16. ↑Kent, C. A.; Mogul, J. C. (1987). Fragmentation considered harmful. Proceedings of the ACM workshop on Frontiers in computer communications technology. pp. 390–401. doi:10.1145/55482.55524. ISBN 978-0-89791-245-7. S2CID 10042690.
  17. ↑Watson, Richard W (1981). "Timer-based mechanism in reliable transport protocol connection management". Computer Networks. 5 (1): 47–56. doi:10.1016/0376-5075(81)90031-3.
  18. ↑McKenzie, Alexander (2011). "INWG and the Conception of the Internet: An Eyewitness Account". IEEE Annals of the History of Computing. 33: 66–71. doi:10.1109/MAHC.2011.9. S2CID 206443072.
  19. ↑ Day, John (2011). ¿Cómo diablos se pierde una capa? Conferencia Internacional de 2011 sobre la Red del Futuro. págs. 135–143 . doi : 10.1109/NOF.2011.6126673 . ISBN  978-1-4577-1607-2. S2CID 15198377 . 
  20. ↑ Lam; Lien (octubre de 1981). "Control de congestión de redes de comunicación de paquetes mediante límites de búfer de entrada: un estudio de simulación". IEEE Transactions on Computers . C-30 (10): 733–742 . doi : 10.1109/TC.1981.1675692 .
  21. ↑ V. Cerf (abril de 1988). Recomendaciones del IAB para el desarrollo de estándares de gestión de redes de Internet . Grupo de trabajo de redes. doi : 10.17487/RFC1052 . RFC 1052 .Estado desconocido.
  22. ↑ Internet Architecture Board (julio de 1992). IP Versión 7 ** BORRADOR 8 ** . IETF . ID draft-iab-ipversion7-00.
  23. ↑ Russell, Andrew L.; Schafer, Valérie (2014). "A la sombra de ARPANET e Internet: Louis Pouzin y la Red de las Cícladas en la década de 1970". Tecnología y Cultura . 55 (4): 880– 907. doi : 10.1353/tech.2014.0096 . S2CID 143582561. Proyecto MUSE 562835 .   
  24. ↑ Esposito, Flavio; Wang, Yuefeng; Matta, Ibrahim; Day, John (abril de 2013). Instanciación dinámica de capas como servicio (PDF) . Simposio USENIX sobre diseño e implementación de sistemas en red (NSDI '13).
  25. ↑ Wang, Yuefeng; Matta, Ibrahim; Esposito, Flavio; Day, John (28 de julio de 2014). "Introducción a ProtoRINA: un prototipo para la programación de políticas de redes recursivas" . ACM SIGCOMM Computer Communication Review . 44 (3): 129– 131. doi : 10.1145/2656877.2656897 . S2CID 1007699 . 
  26. ↑ Wang, Yuefeng; Esposito, Flavio; Matta, Ibrahim (2013). Demostración de RINA utilizando la plataforma de pruebas GENI . Segundo taller de investigación y experimentación educativa de GENI de 2013. págs. 93–96 . doi : 10.1109/GREE.2013.26 . ISBN  978-0-7695-5003-9. S2CID 6735043 . 
  27. ↑ Wang, Yuefeng; Matta, Ibrahim; Akhtar, Nabeel (2014). Experimentando con políticas de enrutamiento usando ProtoRINA sobre GENI . Tercer Taller de Investigación y Experimentación Educativa de GENI 2014. pp. 61–64 . doi : 10.1109/GREE.2014.11 . ISBN  978-1-4799-5120-8. S2CID 16799199 . 
  28. ↑ Vrijders, Sander; Staessens, Dimitri; Colle, Didier; Salvestrini, Francesco; et al. (Marzo de 2014). "Creación de prototipos de la arquitectura recursiva de Internet: el enfoque del proyecto IRATI" . Red IEEE . 28 (2): 20– 25. doi : 10.1109/MNET.2014.6786609 . hdl : 1854/LU-5730910 . S2CID 7594551 .  
  29. ↑ Vrijders, Sander; Staessens, Dimitri; Colle, Didier; Salvestrini, Francesco; et al. (2014). Evaluación experimental de un prototipo de Arquitectura InterRed Recursiva . Conferencia de Comunicaciones Globales IEEE 2014. págs. 2017-2022 . doi : 10.1109/GLOCOM.2014.7037104 . hdl : 1854/LU-5955523 . ISBN   978-1-4799-3512-3. S2CID 13462659 . 
  • Sitio web de la Sociedad Pouzin: http://pouzinsociety.org
  • Página de formación de RINA en el sitio web de IRATI, disponible en línea en http://irati.eu/education/
  • Repositorio de documentos de RINA gestionado por TSSG, disponible en línea en http://rina.tssg.org. Archivado el 22/09/2018 en Wayback Machine.
  • Tutorial de RINA en la conferencia IEEE Globecom 2014, disponible en línea en http://www.slideshare.net/irati-project/rina-tutorial-ieee-globecom-2014