|
The '''Recursive InterNetwork Architecture (RINA)''' is a new computer [[network architecture]] proposed as an alternative to the architecture of the currently mainstream [[Internet protocol suite]]. The principles behind RINA were first presented by [[John Day (computer scientist)|John Day]] in his 2008 book ''Patterns in Network Architecture: A return to Fundamentals''.<ref name="PNA">''Patterns in Network Architecture: A Return to Fundamentals'', John Day (2008), Prentice Hall, {{ISBN|978-0-13-225242-3}}{{pn|date=October 2023}}</ref> This work is a fresh start, taking into account [[#Background|lessons learned]] in the 35 years of [[TCP/IP]]’s existence, as well as the lessons of [[OSI model|OSI]]’s failure and the lessons of other network technologies of the past few decades, such as [[CYCLADES]], [[DECnet]], and [[Xerox Network Systems]]. RINA's fundamental principles are that [[computer network]]ing is just [[Inter-Process Communication]] or IPC, and that layering should be done based on scope/scale, with a single recurring set of protocols, rather than based on function, with specialized protocols. The protocol instances in one layer interface with the protocol instances on higher and lower layers via new concepts and entities that effectively [[Reification (computer science)|reify]] networking functions currently specific to protocols like [[BGP]], [[OSPF]] and [[Address Resolution Protocol|ARP]]. In this way, RINA claims to support features like mobility, [[multihoming]] and [[quality of service]] without the need for additional specialized protocols like [[Real-time Transport Protocol|RTP]] and [[User Datagram Protocol|UDP]], as well as to allow simplified network administration without the need for concepts like [[Autonomous system (Internet)|autonomous systems]] and [[Network address translation|NAT]].
The '''Recursive InterNetwork Architecture (RINA)''' is a computer [[network architecture]] that unifies [[distributed computing]] and [[telecommunications]]. RINA's fundamental principle is that [[computer network]]ing is just [[Inter-Process Communication]] or IPC. RINA reconstructs the overall structure of the [[Internet]], forming a model that comprises a single repeating layer, the DIF (Distributed IPC Facility), which is the minimal set of components required to allow distributed IPC between application processes. RINA inherently supports mobility, [[multihoming|multi-homing]] and [[Quality of Service]] without the need for extra mechanisms, provides a secure and programmable environment, motivates for a more competitive marketplace, and allows for a seamless adoption.
==Overview==
==History and Motivation==
[[File:RINA-DAF.png|thumb|350px|Figure 1. Distributed Application Processes (DAPs) and their components]]
The principles behind RINA were first presented by [[John Day (computer scientist)|John Day]] in his book “Patterns in Network Architecture: A return to Fundamentals”...<ref name="PNA">Patterns in Network Architecture: A Return to Fundamentals, John Day (2008), Prentice Hall, ISBN 978-0132252423</ref> This work is a start afresh, taking into account lessons learned in the 35 years of [[TCP/IP]]’s existence, as well as the lessons of [[OSI]]’s failure and the lessons of other network technologies of the past few decades, such as [[CYCLADES]], [[DECnet]], and [[Xerox Network Systems]].
RINA is the result of an effort to work out general principles in [[computer networking]] that apply in all situations. RINA is the specific architecture, implementation, testing platform and ultimately deployment of the model informally known as the IPC model,<ref>{{cite book |doi=10.1145/1544012.1544079 |chapter=Networking is IPC: A guiding principle to a better internet |title=Proceedings of the 2008 ACM CoNEXT Conference on - CONEXT '08 |date=2008 |last1=Day |first1=John |last2=Matta |first2=Ibrahim |last3=Mattar |first3=Karim |pages=1–6 |isbn=978-1-60558-210-8 |s2cid=3287224 }}</ref> although it also deals with concepts and results that apply to any distributed application, not just to networking. Coming from distributed applications, most of the terminology comes from application development instead of networking, which is understandable, given that RINA's fundamental principle is to reduce networking to 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.{{fact|date=October 2023}}
From the early days of telephony to the present, the [[telecommunications]] and computing industries have evolved significantly. However, they have been following separate paths, without achieving full integration that can optimally support [[distributed computing]]; the paradigm shift from [[telephony]] to distributed applications is still not complete. Telecoms have been focusing on connecting devices, perpetuating the telephony model where devices and applications are the same. A look at the current [[Internet protocol suite]] shows many symptoms of this thinking:<ref name="INWG">A. McKenzie, “INWG and the Conception of the Internet: An Eyewitness Account”; IEEE Annals of the History of Computing, vol. 33, no. 1, pp. 66-71, 2011</ref>
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 [[Service Data Unit|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:{{fact|date=October 2023}}
* The network routes data between interfaces of computers, as the public switched telephone network switched calls between phone terminals. However, it is not the source and destination ''interfaces'' that wish to communicate, but the distributed ''applications''.
# data transfer,
* Applications have no way of expressing their desired service characteristics to the network, other than choosing a reliable ([[Transmission Control Protocol|TCP]]) or unreliable ([[User Datagram Protocol|UDP]]) type of transport. The network assumes that applications are homogeneous by providing only a single quality of service.
# data transfer control and
* The network has no notion of application names, and has to use a combination of the interface address and transport layer port number to identify different applications. In other words, the network uses information on “''where''” an application is located to identify “''which''” application this is. Every time the application changes its point of attachment, it seems different to the network, greatly complicating multi-homing, mobility, and security.
# 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).{{fact|date=October 2023}}
Several attempts have been made to propose architectures that overcome the current Internet limitations, under the umbrella of the [[Future Internet]] research efforts. However, most proposals argue that requirements have changed, and therefore the [[Internet]] is no longer capable to cope with them. While it is true that the environment in which the technologies that support the [[Internet]] today live is very different from when they where conceived in the late 1970s, changing requirements are not the only reason behind the Internet's problems related to multihoming, mobility, security or QoS to name a few. The root of the problems may be attributed to the fact the current [[Internet]] is based on a tradition focused on keeping the original [[ARPANET]] demo working and fundamentally unchanged, as illustrated by the following paragraphs.
[[File:RINA-arch.png|left|thumb|350px|Figure 2. Example of RINA networks and IPCP components]]
'''1972. Multi-homing not supported by the ARPANET'''. In 1972 the [[Tinker Air Force Base]] wanted connections to two different IMPs ([[Interface Message Processors]], the predecessors of today's routers) 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, therefore it had no way of knowing that they belong to the same host. The solution was obvious: as in operating systems, a logical address space naming the nodes (hosts and routers) was required on top of the physical interface address space. However, the implementation of this solution was left for future work, and it is still not done today: “''IP addresses of all types are assigned to interfaces, not to nodes''”.<ref name="IPv6">R. Hinden and S. Deering. IP Version 6 Addressing Architecture. RFC 4291 (Draft Standard), February 2006. Updated by RFCs 5952, 6052</ref> As a consequence, routing table sizes are orders of magnitude bigger than they would need to be, and multi-homing and mobility are complex to achieve, requiring both special protocols and point solutions.
DIFs, being DAFs, in turn use other underlying DIFs themselves, going all the way down to the physical layer DIF controlling the wires and jacks. This is where the recursion of RINA comes from. All RINA layers have the same structure and components and provide the same functions; they differ only in their scopes, configurations or policies (mirroring the [[separation of mechanism and policy]] in operating systems).<ref>{{cite report |last1=Mattar |first1=Karim |last2=Matta |first2=Ibrahim |last3=Day |first3=John |last4=Ishakian |first4=Vatche |last5=Gursun |first5=Gonca |title=Declarative Transport: No More Transport Protocols to Design, Only Policies to Specify |date=12 July 2008 |hdl=2144/1707 }}</ref> As shown in Figure 2, RINA networks are usually structured in DIFs of increasing scope. Figure 3 shows an example of how the Web could be structured with RINA: the highest layer is the one closest to applications, corresponding to email or websites; the lowest layers aggregate and multiplex the traffic of the higher layers, corresponding to [[ISP]] backbones. Multi-provider DIFs (such as the public Internet or others) float on top of the ISP layers. In this model, three types of systems are distinguished: hosts, which contain DAPs; interior routers, internal to a layer; and border routers, at the edges of a layer, where packets go up or down one layer.
'''1978. [[Transmission Control Protocol]] (TCP) split from the [[Internet Protocol]] (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, although the two layers had the same scope. This would not be a problem if: i) the two layers were independent and ii) the two layers didn't contain repeated functions. However none of both is right: in order to operate effectively IP needs to know what TCP is doing. IP fragmentation and the workaround of MTU discovery that TCP does in order to avoid it to happen is a clear example of this issue. In fact, as early as in 1987 the networking community was well aware of the IP fragmentation problems, to the point of considering it harmful.<ref>C.A. Kent and J.C. Mogul. Fragmentation considered harmful. Proceedings of Frontiers in Computer Communications Technologies, ACM SIGCOMM, 1987</ref> However, it was not understood as a symptom that TCP and IP were interdependent and therefore splitting it into two layers of the same scope was not a good decision.
[[File:RINA-Internets.png|thumb|350px|Figure 3. Multiple RINA networks supporting several internetworks.]]
'''1981. Watson's fundamental results ignored'''. Richard Watson in 1981 provided a fundamental theory of reliable transport,<ref>R. Watson. Timer-based mechanism in reliable transport protocol connection management. Computer Networks, 5:47–56, 1981</ref> 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 <ref name="deltat">R. Watson. Delta-t protocol specification. Technical Report UCID-19293, Lawrence Livermore National Laboratory, December 1981</ref> in which the state of a connection at the sender and receiver can be safely removed once the connection-state timers expire without the need for explicit removal messages. And new connections are established without an explicit handshaking phase. On the other hand, TCP uses both explicit handshaking as well as more limited timer-based management of the connection’s state. Had TCP incorporated Watson's results it would be more efficient, robust and secure, eliminating the use of SYNs and FINs and therefore all the associated complexities and vulnerabilities to attack (such as [[SYN flood]]).
In short, RINA keeps the concepts of PDU and SDU, but instead of layering by function, it layers by scope. Layers correspond not to different responsibilities, but different scales, and the model is specifically designed to be applicable from a single point-to-point Ethernet connection all the way up to the Web. RINA is therefore an attempt to reuse as much theory as possible and eliminate the need for ad-hoc protocol design, and thus reduce the complexity of network construction, management and operation in the process.{{fact|date=October 2023}}
'''1983. Internetwork layer lost, the Internet ceases to be an Internet'''. 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.<ref name="INWG"/> A remarkable aspect is that the selected option, as well as all the other candidates, had an architecture composed of 3 layers of increasing scope: data link (to handle different types of physical medias), network (to handle different types of networks) and internetwork (to handle a network of networks), each layer with its own addresses. In fact when TCP/IP was introduced it run at the internetwork layer on top of the [[Network Control Program]] and other network technologies. But when NCP was shut down, TCP/IP took the network role and the internetwork layer was lost.<ref name="lostlayer">J. Day. How in the Heck Do You Lose a Layer!? 2nd IFIP International Conference of the Network of the Future, Paris, France, 2011</ref> As a result, the Internet ceased to be an Internet and became a concatenation of IP networks with an end-to-end transport layer on top. A consequence of this decision is the complex routing system required today, with both intra-___domain and inter-___domain routing happening at the network layer <ref name="EGP">E.C. Rosen. Exterior Gateway Protocol (EGP). RFC 827, October 1982. Updated by RFC 904.</ref> or the use of NAT, [[Network Address Translation]], as a mechanism for allowing independent address spaces within a single network layer.
===Naming, addressing, routing, mobility and multihoming===
[[File:INWG-arch.png|thumb|350px|Figure1. The Internet architecture as seen by the INWG]]
As explained above, the IP address is too low-level an identifier on which to base multihoming and mobility efficiently, as well as requiring routing tables to be bigger than necessary. RINA literature follows the general theory of [[Jerry Saltzer]] on addressing and naming. According to Saltzer, four elements need to be identified: applications, nodes, attachment points and paths.<ref name="Saltzer">J. Saltzer. On the Naming and Binding of Network Destinations. {{IETF RFC|1498}} (Informational), August 1993</ref> An application can run in one or more nodes and should be able to move from one node to another without losing its identity in the network. A node can be connected to a pair of attachment points and should be able to move between them without losing its identity in the network. A directory maps an application name to a node address, and routes are sequences of node addresses and attachment points. These points are illustrated in Figure 4.
[[File:Saltzer-naming.png|thumb|350px|Figure 4. Illustration of Saltzer's theory on naming and addressing.]]
'''1983. First opportunity to fix addressing missed'''. The need for application names and distributed directories that mapped application names to internetwork addresses was well understood since mid 1970s. They were not there at the beginning since it was a major effort and there were very few applications, but they were expected to be introduced once the “host file” was automated (the host file was centrally maintained and mapped human-readable synonyms of addresses to its numeric value). However, application names were not introduced and DNS, the [[Domain Name System]], was designed and deployed, continuing to use well-known ports to identify applications. The advent of the web and [[HTTP]] caused the need for application names, introducing [[URLs]]. However the URL format ties each application instance to a physical interface of a computer and a specific transport connection (since the URL contains the DNS name of an IP interface and TCP port number), making multi-homing and mobility very hard to achieve.
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.{{fact|date=October 2023}}
'''1986. [[Congestion collapse]] takes the Internet by surprise'''. Despite the fact that the problem of congestion control in datagram networks had been known since the very beginning (in fact there had been several publications during the 70s and early 80s,<ref>D. Davies. Methods, tools and observations on flow control in packet-switched data networks. IEEE Transactions on Communications, 20(3): 546–550, 1972</ref><ref>S. S. Lam and Y.C. Luke Lien. Congestion control of packet communication networks by input buffer limits - a simulation study. IEEE Transactions on Computers, 30(10), 1981.</ref>) the congestion collapse in 1986 caught the Internet by surprise. What is worse, it was decided to adopt the [[congestion avoidance]] scheme from [[Ethernet]] networks with a few modifications, but it was put in TCP. The effectiveness of a congestion control scheme is determined by the time-to-notify, i.e. reaction time. Putting congestion avoidance in TCP maximizes the value of the congestion notification delay and its variance, making it the worst place it could be. Moreover, congestion detection is implicit, causing several problems: i) congestion avoidance mechanisms are predatory: by definition they need to cause congestion to act; ii) congestion avoidance mechanisms may be triggered when the network is not congested, causing a downgrade in performance.
With this naming structure, mobility and multihoming are inherently supported<ref>{{cite journal |last1=Ishakian |first1=Vatche |last2=Akinwumi |first2=Joseph |last3=Esposito |first3=Flavio |last4=Matta |first4=Ibrahim |title=On supporting mobility and multihoming in recursive internet architectures |journal=Computer Communications |date=July 2012 |volume=35 |issue=13 |pages=1561–1573 |doi=10.1016/j.comcom.2012.04.027 |s2cid=3036132 |hdl=2144/3809 |hdl-access=free }}</ref> if the names have carefully chosen properties:
'''1992. Second opportunity to fix addressing missed'''. In 1992 the [[Internet Architecture Board]] (IAB) produced a series of recommendations to resolve the scaling problems of the [[IPv4]] based Internet: address space consumption and routing information explosion. Three types of solutions were proposed: introduce CIDR ([[Classless Inter-Domain Routing]]) to mitigate the problem, design the next version of IP (IPv7) based on [[CLNP]] (ConectionLess Network Protocol) and continue the research into naming, addressing and routing.<ref>Internet Architecture Board. IP Version 7 ** DRAFT 8 **. Draft IAB IPversion7, july 1992</ref> CNLP was an OSI based protocol that addressed nodes instead of interfaces, solving the old multi-homing problem introduced by the [[ARPANET]], and allowing for better routing information aggregation. CIDR was introduced but the [[IETF]] didn't accept an IPv7 based on CLNP. IAB reconsidered its decision and the IPng process started, culminating with [[IPv6]]. One of the rules for IPng was not to change the semantics of the IP address, which continues to name the interface perpetuating the multi-homing problem.<ref name="IPv6"/>
# application names are ___location-independent to allow an application to move around;
There are still more wrong decisions that have resulted in long-term problems for the current Internet, such as:
# node addresses are ___location-dependent but route-independent; and
# 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.
* In 1988 IAB recommended using the [[Simple Network Management Protocol]] (SNMP) as the initial network management protocol for the Internet to later transition to the object-oriented approach of the [[Common Management Information Protocol]] (CMIP).<ref>Internet Architecture Board. IAB Recommendations for the Development of Internet Network Management Standards. RFC 1052, april 1988</ref> SNMP was a step backwards in network management, justified as a temporal measure while the required more sophisticated approaches were implemented, but the transition never happened.
* Since [[IPv6]] didn’t solve the multi-homing problem and naming the node was not accepted, the major theory pursued by the field is that the IP address semantics are overloaded with both identity and ___location information, and therefore the solution is to separate the two, leading to the work on [[Locator/Identifier Separation Protocol]] (LISP). However all approaches based on LISP have scaling problems <ref name="lispis">D. Meyer and D. Lewis. Architectural implications of Locator/ID separation. Draft Meyer Loc Id implications, january 2009</ref> because i) it is based on a false distinction (identity vs. ___location) and ii) it is not routing packets to the end destination (LISP is using the locator for routing, which is an interface address; therefore the multi-homing problem is still there).<ref name="lispno">J. Day. Why loc/id split isn’t the answer, 2008. Available online at http://rina.tssg.org/docs/LocIDSplit090309.pdf</ref>
* The recent discovery of [[bufferbloat]] due to the use of large buffers in the network. Since the beginning of the 80s it was already known that the buffer size should be the minimal to damp out transient traffic bursts,<ref>L. Pouzin. Methods, tools and observations on flow control in packet-switched data networks. IEEE Transactions on Communications, 29(4): 413–426, 1981</ref> but no more since buffers increase the transit delay of packets within the network.
* The inability to provide efficient solutions to security problems such as authentication, access control, integrity and confidentiality, since they were not part of the initial design. As stated in <ref>D. Clark, L. Chapin, V. Cerf, R. Braden and R. Hobby. Towards the Future Internet Architecture. RFC 1287 (Informational), December 1991</ref> “''experience has shown that it is difficult to add security to a protocol suite unless it is built into the architecture from the beginning''”.
===Protocol design===
==Terminology==
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.<ref name="policy">{{cite journal |last1=Hansen |first1=Per Brinch |title=The nucleus of a multiprogramming system |journal=Communications of the ACM |date=April 1970 |volume=13 |issue=4 |pages=238–241 |doi=10.1145/362258.362278 |s2cid=9414037 }}</ref> 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.
* '''Application Entity'''. A task within a DAP directly involved with exchanging application information with other DAPs.
* '''Common Distributed Application Process (CDAP)'''. CDAP enables distributed applications to deal with communications at an object level, rather than forcing applications to explicitly deal with serialization and input/output operations. CDAP provides the application protocol component of a Distributed Application Facility (DAF) that can be used to construct arbitrary distributed applications, of which the DIF is an example. CDAP provides a straightforward and unifying approach to sharing data over a network without having to create specialized protocols.
* '''Distributed Application Facility (DAF)'''. A collection of two or more cooperating DAPs in one or more processing systems, which exchange information using IPC and maintain shared state. In some Distributed Applications, all members will be the same, i.e. a homogeneous DAF, or may be different, a heterogeneous DAF.
* '''Distributed Application Process (DAP)'''. The instantiation of a [[computer program]] executing in a processing system intended to accomplish some purpose. A Distributed Application Process contains one or more tasks or Application-Entities, as well as functions for managing the resources (processor, storage, and IPC) allocated to this DAP.
* '''Distributed IPC Facility (DIF), Layer'''. A collection of two or more DAPs cooperating to provide Interprocess Communication (IPC). A DIF is a DAF that does IPC. The DIF provides IPC services to Applications via a set of API primitives that are used to exchange information with the Application’s peer.
* '''IPC Process (IPCP)'''. An Application-Process, which is a member of a DIF and implements locally the functionality to support and manage IPC using multiple sub-tasks.
* '''Processing System'''. The hardware and software capable of executing programs instantiated as DAPs that can coordinate with the equivalent of a “test and set” instruction, i.e. the tasks can all atomically reference the same memory.
* '''Protocol Data Unit (PDU)'''. The string of octets exchanged among the Protocol Machines (PM). PDUs contain two parts: the PCI, which is understood and interpreted by the DIF, and User-Data, that is incomprehensible to this PM and is passed to its user.
* '''Resource Information Base (RIB)'''. For the DAF, the RIB is the logical representation of the local repository of the objects. Each member of the DAF maintains a RIB. A Distributed Application may define a RIB to be its local representation of its view of the distributed application. From the point of view of the OS model, this is storage.
* '''Service Data Unit (SDU)'''. The amount of data passed across the (N)-DIF interface to be transferred to the destination application process. The integrity of an SDU is maintained by the (N)-DIF. An SDU may be fragmented or combined with other SDUs for sending as one or more PDUs.
RINA uses the theory of the Delta-T protocol<ref name="deltat"/> 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.
==Introduction to RINA==
[[File:RINA-DAF.png|thumb|350px|Figure 2. Distributed Application Processes (DAPs) and their components]]
RINA is the result of an effort that tries to work out the general principles in [[computer networking]] that applies to everything. RINA is the specific architecture, implementation, testing platform and ultimately deployment of the theory. This theory is informally known as the Inter-Process Communication “IPC model” <ref>John Day, Ibrahim Matta and Karim Mattar. Networking is IPC: A guiding principle to a better Internet. In Proceedings of the 2008 ACM CoNEXT Conference. ACM, 2008</ref> although it also deals with concepts and results that are generic for any distributed application and not just for networking.
===Security===
The IPC model captures the common elements of distributed applications, called DAFs (Distributed Application Facilities), as illustrated in the Figure to the right. A DAF is composed by two or more Distributed Application Processes or DAPs, which collaborate to perform a task. These DAPs communicate using a single application protocol called CDAP (Common Distributed Application Protocol), which enables two DAPs to exchange structured data in the form of objects. All of the DAP’s externally visible information is represented by objects and structured in a Resource Information Base (RIB), which provides a naming schema and a logical organization to the objects known by the DAP (for example a naming tree). CDAP allows the DAPs to perform six remote operations on the peer’s objects (create, delete, read, write, start and stop).
[[File:RINA-sec.png|thumb|350px|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.<ref>{{cite thesis |last1=Small |first1=Jeremiah |title=Patterns in network security: an analysis of architectural complexity in securing recursive inter-network architecture networks |date=2012 |hdl=2144/17155 }}</ref> 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.
In order to exchange information, DAPs need an underlying facility that provides communication services to them. This facility is another DAF whose task is to provide and manage Inter Process Communication services over a certain scope ; hence this DAF is called DIF: Distributed IPC Facility - the DIF can be thought of as a layer. A DIF enables a DAP to allocate flows to one or more DAPs, by just providing the names of the targeted DAPs and the characteristics required for the flow (bounds on data loss and delay, in-order delivery of data, reliability, etc.). DAPs may not trust the DIF they are using, therefore may decide to protect their data before writing it to the flow - for example using encryption - via the SDU (Service Data Unit) Protection module.
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.<ref>{{cite book |doi=10.1109/ICNP.2012.6459947 |chapter=Assessing the security of a clean-slate Internet architecture |title=2012 20th IEEE International Conference on Network Protocols (ICNP) |date=2012 |last1=Boddapati |first1=Gowtham |last2=Day |first2=John |last3=Matta |first3=Ibrahim |last4=Chitkushev |first4=Lou |pages=1–6 |isbn=978-1-4673-2447-2 |s2cid=7500711 }}</ref>
[[File:RINA-arch.png|thumb|350px|Figure 3. Example of RINA networks and IPC Process components]]
==Background==
DIFs can also be the users of other underlying DIFs, creating in this way the recursive structure of the RINA architecture. The DAPs that are members of a DIF are called IPC Processes or IPCPs. They have the same generic DAP structure shown in Figure 2, plus some specific tasks to provide and manage IPC. These tasks, as shown in Figure 3, can be divided into three categories: data transfer, data transfer control and layer management. The elements are ordered in increasing complexity and frequency of use, with elements at the far left being used the most (per packet processing) but the least complex, and elements to the right being not often used, but very complex. All the layers provide the same functions and have the same structure and components, however these components are configured via policies in order to adapt to different operating environments.
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:
[[File:TCPIP-arch.png|thumb|350px|Figure 6. Functional layering of the [[TCP/IP]] architecture]]
As depicted in Figure 2 RINA networks are usually structured in DIFs of increasing scope, starting from the so-called lower layers and going up closer to the applications. A provider network can be formed by a hierarchy of DIFs multiplexing and aggregating traffic from upper layers into the provider’s backbone. None of the provider internal layers need to be externally visible. Multi-provider DIFs (such as the public Internet or others) float on top of the [[ISP]] layers. Only three types of systems are required: hosts (which contain applications), interior routers (systems that are internal to a layer) and border routers (systems at the edges of a layer, which go one layer up or down). In short, RINA has the following features:
* Transmission complexity: the separation of [[Internet Protocol|IP]] and [[Transmission Control Protocol|TCP]] results in inefficiency, with the [[Path MTU Discovery|MTU discovery]] performed to prevent [[IP fragmentation]] being the clearest symptom.
* It builds on a very basic premise, yet fresh perspective that networking is not a layered set of different functions but rather a single layer of distributed Inter-Process Communication (IPC) that repeats over different scopes. Each instance of this repeating IPC layer implements the same functions/mechanisms but policies are tuned to operate over different ranges of the performance space (e.g. capacity, delay, loss).
* Performance: TCP itself carries rather high overhead with its handshake, which also causes vulnerabilities such as [[SYN flood]]s. 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]].<ref>{{cite journal |last1=Pouzin |first1=L. |title=Methods, Tools, and Observations on Flow Control in Packet-Switched Data Networks |journal=IEEE Transactions on Communications |date=April 1981 |volume=29 |issue=4 |pages=413–426 |doi=10.1109/TCOM.1981.1095015 }}</ref>
* [[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 [[hostname]]s must resolve to a single IP address and port number combination, making them aliases instead of identities. Neither does [[Locator/Identifier Separation Protocol|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;<ref name="lispno">{{cite report |last1=Day |first1=John |date=2008 |title=Why Loc/Id Split Isn't the Answer |url=https://psoc.i2cat.net/sites/default/files/LocIDSplit090309.pdf }}{{self-published inline|date=October 2023}}</ref> in addition, it also introduces scalability problems of its own.<ref name="lispis">D. Meyer and D. Lewis. Architectural Implications of Locator/ID separation. https://tools.ietf.org/html/draft-meyer-loc-id-implications-01</ref>
* 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,<ref name="IPv6" /> 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. [[Open Shortest Path First|OSPF]] and [[IS-IS]] have relatively few problems, but do not scale well, forcing usage of [[Border Gateway Protocol|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. [[Transport Layer Security|TLS]] and [[IPsec|IPSec]] provide solutions, but with accompanying complexity. [[Firewall (computing)|Firewalls]] and [[Blacklist (computing)|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."<ref>D. Clark, L. Chapin, V. Cerf, R. Braden and R. Hobby. Towards the Future Internet Architecture. {{IETF RFC|1287}} (Informational), December 1991</ref>
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:
* It is based on a comprehensive theory of networking; it does not represent another patch, or point-solution to a piece of the problem. RINA does not propose to simply add a new “session layer” to perform some extra functionality for bridging ISP networks. Instead it takes a clean slate approach and begins with a comprehensive general theory of IPC where the number of IPC layers (DIFs) may vary at different parts of the Internet depending on the range of the resource allocation problem that must be addressed. The greater the operating ranges in a network, the more IPC layers it may have. Thus configuring the appropriate number of IPC layers allows for more predictable services to be delivered to users.
===1972: Multihoming not supported by the ARPANET===
* This repeating structure scales indefinitely, thus it avoids current problems of growing routing tables, and supports features such as multi-homing and mobility, with little or no cost. By indefinitely we mean that the nature of RINA does not impose any limits. There may be physical limits and other constraints.
In 1972, Tinker Air Force Base<ref name="tinker-AFB">{{cite book |chapter= ARPANET, the Defense Data Network, and Internet |title= The Froehlich/Kent Encyclopedia of Telecommunications |author1=Fritz. E Froehlich |author2= Allen Kent |publisher= CRC Press |year=1992 |pages=82 |volume=5 |isbn=978-0-8247-2903-5 |chapter-url= https://books.google.com/books?id=3s0yBitFcy8C&pg=PA82 }}</ref> wanted connections to two different [[Interface Message Processor|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===
* An application process using a DIF only knows the name of the destination application process. It has no knowledge of addresses and there are no so-called “well-known ports”. Joining a DIF requires that the new member must be authenticated according to the policies of this particular facility. This yields a far more secure architecture.
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.<ref>{{cite book |doi=10.1145/55482.55524 |chapter=Fragmentation considered harmful |title=Proceedings of the ACM workshop on Frontiers in computer communications technology |date=1987 |last1=Kent |first1=C. A. |last2=Mogul |first2=J. C. |pages=390–401 |isbn=978-0-89791-245-7 |s2cid=10042690 }}</ref> However, it was not understood as a symptom that TCP and IP were interdependent.
===1981: Watson's fundamental results ignored===
* Stacking DIFs on top of each other allows networks to be built from smaller and more manageable layers of limited scope. This divide-and-conquer strategy gives providers more resource management options than just over-provisioning. It also provides the basis for operating subnetworks at much higher utilization than in the current Internet.
Richard Watson in 1981 provided a fundamental theory of reliable transport<ref name="watson1981a">{{cite journal | first = Richard W | last = Watson | title = Timer-based mechanism in reliable transport protocol connection management | journal = Computer Networks | volume = 5 | issue = 1 | pages = 47–56 | year = 1981 | doi = 10.1016/0376-5075(81)90031-3 }}</ref> 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 <ref name="deltat">{{cite report |last1=Watson |first1=R.W. |title=Delta-t protocol specification: working draft |date=4 December 1981 |doi=10.2172/5542785 |doi-access=free }}</ref> 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===
* RINA leverages the well-known concept of separating mechanism from policy in operating systems.<ref name="policy">P. Brinch Hansen. The nucleous of a multiprogramming system. Communications of the ACM, 13(4): 238-241, 1970</ref> Applying this separation to network protocols allows a DIF to provide a common minimal set of mechanisms that once instantiated with the appropriate policies allows any transport solution to be realised.<ref>I. Matta, J. Day, V. Ishakian, K. Mattar and G. Gursun. Declarative transport: No more transport protocols to design, only policies to specify. Technical Report BUCS-TR-2008-014, CS Dept, Boston. U., July 2008</ref> Not only the transport functions of a DIF benefit from this approach, but also other ones such as management, authentication or access control; making the DIF a fully configurable container capable of effectively operating on top of heterogeneous physical medias and to provide differentiated levels of QoS to different types of applications.
[[File:INWG-arch.png|thumb|350px|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.<ref name=":0">{{cite journal |doi=10.1109/MAHC.2011.9 |title=INWG and the Conception of the Internet: An Eyewitness Account |date=2011 |last1=McKenzie |first1=Alexander |journal=IEEE Annals of the History of Computing |volume=33 |pages=66–71 |s2cid=206443072 }}</ref> 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 [[Network Control Protocol (ARPANET)|Host-IMP Protocol]], when running over the ARPANET. But when [[Network Control Protocol (ARPANET)|NCP]] was shut down, TCP/IP took the network role and the internetwork layer was lost.<ref name="lostlayer">{{cite book |doi=10.1109/NOF.2011.6126673 |chapter=How in the Heck do you lose a layer!? |title=2011 International Conference on the Network of the Future |date=2011 |last1=Day |first1=John |pages=135–143 |isbn=978-1-4577-1607-2 |s2cid=15198377 }}</ref> This explains the need for autonomous systems and NAT today, to partition and reuse ranges of the IP address space to facilitate administration.
* DIFs can be configured to not only provide the fundamental services of the traditional networking lower layers but also the services of application relaying (e.g. mail distribution and similar services), [[transaction processing]], [[content distribution]] and [[peer-to-peer]]. This removes the barrier created by the Transport Layer in the current Internet, opening potential new markets for ISPs to provide IPC services directly to their customers leveraging their expertise in resource management of lower layers.
===1983: First opportunity to fix addressing missed===
* It turns out that private networks (with private addresses) are the norm. IPC processes are identified by addresses internal to the DIF and public networks are simply a degenerate case of a private network. This lays the foundation for major competition and innovation and avoids the rigidness of the current Internet structure. There's not just a single network where everybody has to be attached to; with RINA network operators, service providers and users have a choice of which networks to provide and which networks to join.
The need for an address higher-level than the IP address was well understood since the mid-1970s. However, application names were not introduced and DNS was designed and deployed, continuing to use well-known ports to identify applications. The advent of the web and [[HTTP]] created a need for application names, leading to URLs. URLs, however, tie each application instance to a physical interface of a computer and a specific transport connection, since the URL contains the DNS name of an IP interface and TCP port number, spilling the multihoming and mobility problems to applications.{{fact|date=October 2023}}
===1986: Congestion collapse takes the Internet by surprise===
==RINA compared to [[TCP/IP]]==
Though the problem of congestion control in datagram networks had been known since the 1970s and early 80s,<ref>{{cite journal |last1=Pouzin |first1=L. |title=Methods, Tools, and Observations on Flow Control in Packet-Switched Data Networks |journal=IEEE Transactions on Communications |date=April 1981 |volume=29 |issue=4 |pages=413–426 |doi=10.1109/TCOM.1981.1095015 }}</ref><ref>{{cite journal |title=Congestion Control of Packet Communication Networks by Input Buffer Limits—A Simulation Study |journal=IEEE Transactions on Computers |date=October 1981 |volume=C-30 |issue=10 |pages=733–742 |doi=10.1109/TC.1981.1675692 |last1=Lam |last2=Lien }}</ref> the [[congestion collapse]] in 1986 caught the Internet by surprise. What is worse, the adopted congestion control - the [[Ethernet]] [[congestion avoidance]] scheme, with a few modifications - was put in TCP.
===1988: Network management takes a step backward===
===Structure===
In 1988 IAB recommended using [[Simple Network Management Protocol|SNMP]] as the initial network management protocol for the Internet to later transition to the object-oriented approach of [[Common Management Information Protocol|CMIP]].<ref>Internet Architecture Board. IAB Recommendations for the Development of Internet Network Management Standards. {{IETF RFC|1052}}, April 1988</ref> SNMP was a step backwards in network management, justified as a temporary measure while the required more sophisticated approaches were implemented, but the transition never happened.
While in [[operating systems]] layers are a convenience - a way to achieve modularity - in networks layers are a necessity, since in networks there is distributed shared state of different scopes. Layers are the tool for isolating distributed shared state of different scopes, nothing else is required. The current Internet architecture uses a layered architecture with a fixed number of layers, every layer having the responsibility of a different function, as depicted in Figure 4 (functional layering).
===1992: Second opportunity to fix addressing missed===
[[File:TCPIP-arch.png|thumb|350px|Figure 4. Functional layering of the TCP/IP architecture]]
In 1992 the [[Internet Architecture Board|IAB]] produced a series of recommendations to resolve the scaling problems of the [[IPv4]]-based Internet: address space consumption and routing information explosion. Three options were proposed: introduce [[Classless Inter-Domain Routing|CIDR]] to mitigate the problem; design the next version of IP (IPv7) based on [[CLNP]]; or continue the research into naming, addressing and routing.<ref>Internet Architecture Board. IP Version 7 ** DRAFT 8 **. Draft IAB IPversion7, july 1992</ref> CLNP was an OSI-based protocol that addressed nodes instead of interfaces, solving the old multihoming problem dating back to the [[ARPANET]], and allowing for better routing information aggregation. CIDR was introduced, but the [[IETF]] didn't accept an IPv7 based on CLNP. IAB reconsidered its decision and the IPng process started, culminating with [[IPv6]]. One of the rules for IPng was not to change the semantics of the IP address, which continues to name the interface, perpetuating the multihoming problem.<ref name="IPv6">R. Hinden and S. Deering. "IP Version 6 Addressing Architecture". {{IETF RFC|4291}} (Draft Standard), February 2006. Updated by RFCs 5952, 6052</ref>
The current architecture just provides two scopes: data link (scope of layers 1 and 2), and global (scope of layers 3 and 4). However, layer 4 is just implemented in the hosts, therefore the “network side” of the Internet ends at layer 3. This means that the current Internet is able to handle a network with heterogeneous physical links, but it is not designed to handle heterogeneous networks, although this is supposed to be its operation. To be able to do it, it would require an “Internetwork” scope, which is now missing.<ref name="lostlayer"/> As ironic as it may sound, the current Internet is not really an internetwork, but a concatenation of IP networks with an end-to-end transport layer on top of them. The consequences of this flaw are several: both inter-___domain and intra-___domain routing have to happen within the network layer, and its scope had to be artificially isolated through the introduction of the concept of [[Autonomous System (Internet)]] and an [[Exterior Gateway Protocol]];<ref name="EGP"/> [[Network Address Translation]] (NATs) appeared as middleboxes in order to have a means of partitioning and reusing parts of the single IP address space.<ref>K. Egevang and P. Francis. The IP Network Address Translator (NAT). RFC 1631 (Informational), May 1994. Obsoleted by RFC 3022</ref>
With an internetwork layer none of this would be necessary: inter-___domain routing would happen at the internetwork layer, while intra-___domain routing within each network would occur at each respective network layer. NATs would not be required since each network could have its own internal address space; only the addresses in the internetwork layer would have to be common. Moreover, congestion could be confined to individual networks, instead of having to deal with it at a global scope as it is done today. The internetwork layer was there in previous internetwork architectures, for example, the INWG architecture depicted in Figure 3, which was designed in 1976. It was somehow lost when the [[Network Control Program]] was phased out ant the Internet officially started in 1983.
The second issue in functional layering is that each layer is supposed to provide a different function, and that this function must not be repeated in the other layers of the stack. A quick analysis on today’s protocols shows that there are repeated functions in different layers; what is more they tend to alternate: layer 1 provides multiplexing and relaying over a physical media, layer 2 provides error and flow control over a data link, layer 3 provides multiplexing and relaying over a network, layer 4 provides error and flow control end-to-end. Finally, the third issue is that layers have to be independent, in order to isolate the shared state of different scopes and allow scalability. Layer violations (layers that use other layer’s information in order to achieve their job) are in the order of the day, starting with the TCP pseudo-header calculated with the information of IP source and destination addresses.
RINA goes beyond the static layering concepts and defines a layer as a distributed application that provides IPC services to applications (or other layers) that use it. In RINA layers are recursive; there is not a fixed number of layers in the stack. The number of layers in any given network is variable. There are simply as many as deemed necessary by the network designers. All layers use the same protocols that can be policy-configured to optimally support the operational requirements of each particular layer. The protocols running at each layer have the potential to provide all the functionality required to allow the layer to operate efficiently: data transport, data transport control, multiplexing, relaying, congestion control, routing, resource allocation, enrollment, authentication, access control, integrity and so forth. The number of these functions instantiated at each layer and how they behave can be configured on a layer-by-layer basis.
===Naming, addressing, routing, mobility and multi-homing===
The current Internet architecture has an incomplete naming and addressing schema, which the reason why mobility and multi-homing require ad-hoc solutions and protocols tailored to different operational environments. The only names provided are Point of Attachment (PoA) names (IP addresses), which are usually confused to be node names. The result is that the network has no way to understand that the two or more IP addresses of a multi-homed node belong to the same node, making multi-homing hard. The same choice, naming the interface and not the node, forces the Internet to perform routing on the interface level instead of the node level, resulting in having much bigger routing tables than they really need to be. Mobility, which can be seen as dynamic multi-homing, is the next feature that suffers from having an incomplete naming schema.
In 1982, [[Jerry Saltzer]] in his work “On the Naming and Binding of network destinations” <ref name="Saltzer">J. Saltzer. On the Naming and Binding of Network Destinations. RFC 1498 (Informational), August 1993</ref> described the entities and the relationships that make a complete naming and addressing schema in networks. According to Saltzer four are the elements that need to be identified: applications, nodes, points of attachment to the network (PoA) and paths. An application can run in one or more nodes and should be able to move from one node to another without losing its identity in the network. A node can be connected to a pair of PoAs and should be able to move between them without losing its identity in the network. A directory maps an application name to a node address, and routes are sequences of nodes addresses and point of attachments.
[[File:Saltzer-naming.png|thumb|350px|Figure 5. Saltzer's point of view on naming and addressing in computer networks.]]
Saltzer took his model from operating systems, but it was not completely correct for internetworks, since there may be more than one path between the same pair of nodes (even whole networks!). The obvious solution is that routes are sequences of nodes, and at each hop each node chooses the most appropriate PoA (path) to forward the packet to the next node. Therefore, routing is a two-step process: First the route as a sequence of node addresses is calculated, and then, for each hop, an appropriate PoA to select the specific path to be traversed is chosen. 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 in order to exploit multi-homing for load-balancing.
With this naming structure, support for mobility and multi-homing is inherent, if the properties for the names are chosen with care: application names are ___location-independent to allow an application to move around, node addresses are ___location-dependent but route-independent. PoA addresses are by nature route-dependent. Applying this naming scheme to RINA, with recursive layers, an interesting observation can be made: mapping application names to node addresses is the same mapping than mapping node addresses to PoAs. In other words, for any layer N, nodes at the layer N+1 are applications and nodes at the layer N-1 are points of attachment, making this relationship relative.
The [[Locator/Identifier Separation Protocol]] (LISP or Loc/ID split) <ref name="lisp">D. Farinacci, V. Fuller, D. Meyer, and D. Lewis. Locator/ID Separation Protocol (LISP). Draft IETF LISP 18, december 2011</ref> has been proposed by [[IETF]] as a solution to issues as the scalability of the routing system. LISP main argument is that the semantics of the IP address are overloaded being to be both locator and identifier of an endpoint. LISP proposes to address this issue by separating the IP address into a locator part, which is hierarchical, and an identifier, which is flat. However this is a false distinction: in Computer Science it is impossible to locate something without identifying it and to identify something without locating it, since all the names are using for locating an object within a context.<ref name="Saltzer"/> Moreover, LISP continues to use the locator for routing, therefore routes are computed between locators (inter- faces). However, a path does not end on a locator but on an identifier, in other words, the locator is not the ultimate destination of the packet but a point on the path to the ultimate destination.<ref name="lispno"/> This issue leads to path-discovery problems, as documented by <ref name="lispis"/> whose solution is known not to scale.
RINA adopts and extends Saltzer’s model by supporting internetworks, and making it recursive. It has a complete naming and addressing schema, providing names for the basic entities of the network (nodes, PoAs and applications). As a consequence RINA supports mobility and multi-homing inherently <ref>V. Ishakian, J. Akinwuni, F. Esposito, I. Matta, "On supporting mobility and multihoming in recursive internet architectures". Computer Communications, Volume 35, Issue 13, July 2012, pages 1561-1573</ref>
===Protocol Design===
A protocol can effectively serve different applications with a wide range of requirements as long as this is the goal from the beginning of the protocol design. In RINA, policy and mechanism are separated, resulting in a framework than can be fine-tuned through policy specification. The mechanism of a protocol may be tightly bound, such as the headers of a data transfer packet, or loosely bound, as in some control and acknowledgment messages. The use of common mechanisms in conjunction with different policies, rather than the use of separate protocols brings greater flexibility.<ref name="policy"/> Each DIF can use different policies to provide different classes of quality of service to further adapt to the characteristics of the physical media (if the DIF is close to the lower end of the stack) or to the characteristics of the applications (if the DIF is close to the upper end of the stack).
By separating mechanism and policy, RINA dramatically simplifies networking. There is no longer a different set of modules and protocols for each capability in each layer. Instead, the elements of the DIF combine to accomplish functions that have previously required a multitude of individual specifications. The implications of this are significant: rather than hundreds of handcrafted protocols each with their own optimizations, there is a consistent repeating structure of two protocols (an application protocol, a data transfer protocol) and a common header and roughly a half dozen modules. In this approach there is thus far less to go wrong. A single replicable layer of a half dozen or so modules can be much more effectively engineered to be free of bugs and security holes than the literally hundreds of protocols in conventional Internetworking. Furthermore, the inherently constrained nature of policies makes it possible to circumscribe their side effects and ensure their proper behaviour. It is possible to define properties of policies that can be proved or tested that ensure proper behaviour.
The basis of the data transfer control protocol in RINA is the Delta-T protocol.<ref name="deltat"/> Watson proved that the necessary and sufficient conditions for reliable transfer is to bound three timers. Delta-T is an example of how this should work. It does not require a connection setup (such as TCP’s SYN handshake) or tear-down (like TCP’s FIN handshake) for integrity purposes. In fact, TCP uses the same three timers! So RINA avoids unnecessary overhead. Watson showed that synchronization and port allocation are distinct functions. Port allocation is part of DIF management, while synchronization is part of the data transfer protocol. In fact, maintaining the distinction also improves the security of connection setup, and avoids the need for separate protocols like [[IPSec]], since multiple transport connections can be associated to the same port allocation.
By separating mechanism from policy, RINA dramatically reduces the number of protocols required in the architecture, while still allowing each layer to be customized to provide different levels of quality of service. Applying Watson’s theory of separating port allocation from synchronisation enables simpler, more robust and more reliable data transfer protocols.
===Security===
The recursive model of the RINA architecture provides a clear security model in which the trust relationships between layers (DAFs or DIFs) and between members of a single layer are well identified. Figure 6 illustrates these trust boundaries, which facilitate the placement of the different security functions in the RINA architecture - in contrast to the Internet where security is designed in every protocol instead of at the system-level, making security complex, expensive and brittle. Research on RINA security properties to date has already produced some promising results.
[[File:RINA-sec.png|thumb|350px|Figure 6. Placement of security functions in the RINA architecture.]]
'''Resiliency to data transport attacks'''. IPCP (node) addresses are internal to a DIF and not exposed to applications, data connections are dynamically assigned connection-endpoint ids (CEP-ids) that are bound to dynamically assigned ports. Bodappati et al.<ref>G. Boddapati, J. Day, I. Matta, L. Chitkushev, "Assessing the security of a clean-slate Internet architecture," Network Protocols (ICNP), 2012 20th IEEE International Conference on , vol., no., pp.1,6, Oct. 30 2012-Nov. 2 2012</ref> showed that due to this decoupling of transport port allocation and access control from data synchronization and transfer RINA was much more resilient than TCP/IP to transport-level attacks such as port-scanning, connection opening or data-transfer.
'''DIFs are securable containers, no firewalls are necessary'''. Small et al. <ref>J. Small, J. Day, L. Chitkushev, “Threat analysis of Recursive Inter-Network Architecture Distributed Inter-Process Communication Facilities”. Boston University Technical Note.</ref> performed a threat analysis at the RINA architecture level, concluding that DIFs are securable containers. That is, if proper authentication, authorization, confidentiality, integrity protection and auditing policies are put in place (as identified in section 2.1) a DIF is a structure used to transport data that can be made to be not subject to thread. No external tools such as firewalls are required.
'''Complexity of RINA security is lower than that of the current Internet security'''. This is a consequence of the different approach to each of the architectures: the system design approach adopted by the RINA architecture, is based on identifying the proper placement of all the functions within the architecture - in contrast to the disorganized evolution of the Internet “protocol-suite” which leads to unnecessary redundancy and complexity. This is particularly evident in comparing the number of protocols and mechanisms required to add security to both RINA and the Internet: Small<ref>J. Small. “Patterns in Network Security: An analysis of architectural complexity in securing Recrusive Inter-Network Architecture Networks”. Master thesis, 2012. Boston University Library</ref> showed that the current Internet security had for 4-5 times the overhead of RINA security. Less overhead means not only less cost but also more effective security, since complexity is the worst enemy of security <ref>B. Schneier, “Complexity the worst enemy of Security”. Computer World, December 2012.</ref>
===Other aspects===
'''Quality of Service'''. Another shortcoming of the TCP/IP architecture is that there is no built-in mechanism that allows the network to provide specific QoS levels. Applications have no way of asking for certain QoS parameters, since the sockets API only allows to specify a reliable (TCP) or unreliable (UDP) transport service. Within RINA each DIF can support a set of QoS cubes (QoS classes with different restrictions on several QoS parameters such as bandwidth, delay, loss rate, ordered or not ordered delivery, jitter) and provide service guarantees to its clients. The DIF API allows applications (being general applications or other DIFs) to provide QoS requirements when they request an IPC service.
'''Greater robustness and more effective response to change.''' Response to change is far faster thanks to load balancing, quicker convergence due to much smaller routing table sizes, more responsive flow management, and, on the manpower side, simpler and more effective operational management. RINA provides all of the flexibility and survivability of connectionless networking while supporting all the service capabilities of connection-oriented networking. Data flows under hostile environments are far more reliable due to highly tuneable, situation-specific policies. As new demands arise, systems can be quickly reconfigured to accommodate them simply by configuring new policies.
'''A more competitive marketplace'''. The particular “best-effort” architecture adopted by the Internet does relegate providers to a commodity business. The Transport Layer (TCP) effectively seals the providers off in the lower layers with IP providing a best-effort service. This implies that everyone must do the same thing or nearly so, leaving little room for differentiation and competition and relegates them to a commodity business. RINA creates the robust feedback needed for a healthy marketplace.<ref>J. Day. Creating a viable economic model for a viable internet, 2008. Available online at http://rina.tssg.org/docs/PNAEcon080518.pdf</ref> An application API allows applications to request service with specific QoS requirements from the layer below. Each DIF can be configured to not only provide the traditional services of lower networking layers but also application-support (transport) services. This removes the barrier created by the Transport Layer in the current Internet, opening potential new markets for ISPs to provide IPC services directly to their customers, leveraging their expertise in resource management of lower layers and creating new competition with “host” providers. This distributed IPC can be configured to not only provide the fundamental services of the traditional networking lower layers but also the services of application relaying, e.g. mail distribution and similar services; transaction processing, and peer-to-peer.
[[File:RINA-Internets.png|thumb|350px|Figure 7. Multiple RINA networks supporting several internetworks.]]
'''Internetworking'''. In RINA the public Internet can be seen as a public e-mall floating on top of multiple providers. This is what we are trying to do today but lacking the right tools to do it. In RINA each level of the hierarchy has an independent address space, managed by the provider it belongs to. As opposed to what we are used today, other e-malls potentially more upscale are possible with other characteristics such as tighter security for joining, perhaps specialized to certain market segments, creating a real Internetwork. An example of several Internetworks is shown in Figure 7. Lower level DIFs belong to ISPs, which decide for the configuration, the address space and policies in these DIFs. Higher layer DIFs can be accessible by everybody. For example, Facebook could be considered boutique e-malls in contrast to the mega-malls like the Internet. It could benefit from the improved security and ability to create focused communities with tighter controls. There is no public network or address space to which one must belong. Any network you are part of is by choice. Networks have considerable flexibility in who they provide their services. This would encourage alliances among groups of providers with complementary interests to provide QoS services in competition with groups of other providers.
==Research projects==
From the publishing of the PNA book in 2008 untilto 2014, a lot of RINA research and development work has been done. There is a clear need for an international authority that coordinates the different ongoing activities, make sure their results are integrated in the basic reference model but at the same time are able to incorporate new knowledge or fix inconsistencies. An informal group known as the Pouzin Society (PSOC) <ref>Pouzin Society website: [http://www.pouzinsociety.org</ref>– Pouzin Society], named after [[Louis Pouzin]],<ref>A.{{cite L.journal |last1=Russell, V|first1=Andrew L. Schaffer.|last2=Schafer |first2=Valérie “In|title=In the shadowShadow of ARPAnetARPANET and Internet: Louis Pouzin and the Cyclades networkNetwork in the 1970s”.1970s Available|journal=Technology onlineand atCulture http://muse|date=2014 |volume=55 |issue=4 |pages=880–907 |doi=10.jhu.edu1353/journals/technology_and_culture/v055/55tech.42014.russell.html0096 |s2cid=143582561 |id={{Project MUSE|562835}} }}</ref> thecoordinates inventorseveral of [[datagrams]] and connectionless networking - has been taking thisinternational roleefforts.
===BU Research Team===
The RINA research team at Boston University <ref>Boston University’s RINA research team website: [http://csr.bu.edu/rina</ref> RINA research team at Boston University] is leadled by Prof.Professors Abraham Matta and Prof., John Day. BUand Lou Chitkushev, and has been awarded a number of grants from the [[National Science Foundation]] and EC in order to continue investigating the fundamentals of RINA, develop an [https://github.com/ProtoRINA/users/wiki open source prototype implementation over UDP/IP for Java] <ref>ProtoRINA{{cite githubconference site:|first1=Flavio |last1=Esposito |first2=Yuefeng |last2=Wang |first3=Ibrahim |last3=Matta |first4=John |last4=Day |title=Dynamic Layer Instantiation as a Service |conference=USENIX Symposium on Networked Systems Design and Implementation (NSDI ’13) |date=April 2013 |url=https://githubwww.comusenix.org/ProtoRINAsystem/usersfiles/wikinsdip13-paper11.pdf }}</ref><ref>{{cite journal |last1=Wang |first1=Yuefeng |last2=Matta |first2=Ibrahim |last3=Esposito |first3=Flavio |last4=Day |first4=John |title=Introducing ProtoRINA: a prototype for programming recursive-networking policies |journal=ACM SIGCOMM Computer Communication Review |date=28 July 2014 |volume=44 |issue=3 |pages=129–131 |doi=10.1145/2656877.2656897 |s2cid=1007699 |doi-access=free }}</ref> and experiment with it on top of the GENI infrastructure.<ref>Yuefeng{{cite book |doi=10.1109/GREE.2013.26 |chapter=Demonstrating RINA Using the GENI Testbed |title=2013 Second GENI Research and Educational Experiment Workshop |date=2013 |last1=Wang, Ibrahim|first1=Yuefeng |last2=Esposito |first2=Flavio |last3=Matta and|first3=Ibrahim Nabeel|pages=93–96 Akhtar|isbn=978-0-7695-5003-9 |s2cid=6735043 }}</ref><ref>{{cite book |doi=10.1109/GREE.2014.11 "|chapter=Experimenting with Routing Policies Using ProtoRINA over GENI". The|title=2014 Third GENI Research and Educational Experiment Workshop (GREE2014),|date=2014 March|last1=Wang 19–20,|first1=Yuefeng 2014,|last2=Matta Atlanta,|first2=Ibrahim |last3=Akhtar |first3=Nabeel |pages=61–64 |isbn=978-1-4799-5120-8 |s2cid=16799199 Georgia}}</ref> BU is also a member of the Pouzin Society and an active contributor to the FP7 IRATI and PRISTINE projects. In addition to this, BU has incorporated the RINA concepts and theory in their computer networking courses.
===FP7 IRATI===
IRATI <ref>The FP7 IRATI project website: [http://irati.eu</ref> IRATI] is an [[Seventh Framework Programme|FP7]]-funded project with 5 partners: i2CAT, Nextworks, iMinds, Interoute and Boston University,. whose mainIt goalhas isproduced toan produce an[https://irati.github.io/stack open source RINA implementation for the Linux OS on top of Ethernet,].<ref>S.{{cite journal |last1=Vrijders, D.|first1=Sander |last2=Staessens, D.|first2=Dimitri |last3=Colle, F.|first3=Didier |last4=Salvestrini, E.|first4=Francesco |last5=Grasa, M.|first5=Eduard |last6=Tarzan and L.|first6=Miquel |last7=Bergesio “Prototyping|first7=Leonardo |title=Prototyping the Recursiverecursive Internetworkinternet Architecturearchitecture: Thethe IRATI Projectproject Approach“,approach |journal=IEEE Network, Vol.|date=March 2014 |volume=28, no. |issue=2, March|pages=20–25 2014<|doi=10.1109/ref><ref>SMNET. Vrijders, D2014.6786609 Staessens,|hdl=1854/LU-5730910 D.|s2cid=7594551 Colle, F|url=https://biblio. Salvestrini, Vugent.be/publication/5730910 Maffione,|hdl-access=free L.}}</ref><ref>{{cite Bergesio,book M|doi=10. Tarzan, B1109/GLOCOM. Gaston, E2014.7037104 Grasa; “Experimental|chapter=Experimental evaluation of a Recursive InterNetwork Architecture prototype“,prototype |title=2014 IEEE GlobecomGlobal 2014,Communications Austin,Conference Texas</ref>|date=2014 FP7|last1=Vrijders IRATI|first1=Sander has|last2=Staessens already|first2=Dimitri open-sourced|last3=Colle the|first3=Didier first|last4=Salvestrini release|first4=Francesco of|last5=Maffione the|first5=Vincenzo RINA|last6=Bergesio implementation,|first6=Leonardo called|last7=Tarzan-Lorente as|first7=Miquel the|last8=Gaston project|first8=Bernat “IRATI”.<ref>Open|last9=Grasa IRATI|first9=Eduard github|pages=2017–2022 site,|hdl=1854/LU-5955523 available|isbn=978-1-4799-3512-3 at:|s2cid=13462659 http|url=https://iratibiblio.githubugent.iobe/stackpublication/5955523 }}</ref> The implementation will be further enhanced by the PRISTINE and IRINA projects.
===FP7 PRISTINE===
PRISTINE <ref>The FP7 PRISTINE project website: [http://ict-pristine.eu</ref> PRISTINE] is an FP7-funded project with 15 partners: WIT-TSSG, i2CAT, Nextworks, Telefónica I+D, Thales, Nexedi, B-ISDN, Atos, University of Oslo, Juniper Networks, Brno University, IMT-TSP, CREATE-NET, iMinds and UPC;. whoseIts main goal is to explore the programmability aspects of RINA to implement innovative policies for congestion control, resource allocation, routing, security and network management.{{fact|date=October 2023}}
===GÉANT3+ Open Call winner IRINA===
[http://www.geant.net/opencall/Optical/Pages/IRINA.aspx IRINA] was funded by the [[GÉANT3]]+ open call, and is a project with four partners: iMinds, WIT-TSSG, i2CAT and Nextworks. The main goal of IRINA is to study the use of the Recursive InterNetwork Architecture (RINA) as the foundation of the next generation NREN and GÉANT network architectures. IRINA builds on the IRATI prototype and will compare RINA against current networking state of the art and relevant clean-slate architecture under research; perform a use-case study of how RINA could be better used in the NREN scenarios; and showcase a laboratory trial of the study.{{fact|date=October 2023}}
== See also ==
* [[Protocol Wars]]
===GEANT3+ Open Call winner IRINA===
IRINA <ref>The IRINA project website: http://www.geant.net/opencall/Optical/Pages/IRINA.aspx</ref> was funded by the GEANT3+ open call, and is a project with four partners: iMinds, WIT-TSSG, i2CAT and Nextworks. The main goal of IRINA is to study the use of the Recursive InterNetwork Architecture (RINA) as the foundation of the next generation NREN and GÉANT network architectures. IRINA builds on the open source RINA prototype developed by the FP7 IRATI project. IRINA will compare RINA against current networking state of the art and relevant clean-slate architecture under research; perform a use-case study of how RINA could be better used in the NREN scenarios; and showcase a laboratory trial of the study.
==References==
{{reflistReflist|colwidth=30em}}
==External links==
* The Pouzin Society website: http://pouzinsociety.org
* RINA Education page at the IRATI website, available online at http://irati.eu/education/
* RINA document repository run by the TSSG, available online at http://rina.tssg.org {{Webarchive|url=https://web.archive.org/web/20180922195131/http://rina.tssg.org/ |date=2018-09-22 }}
* RINA tutorial at the IEEE Globecom 2014 conference, available online at http://www.slideshare.net/irati-project/rina-tutorial-ieee-globecom-2014
[[Category:Network_architectureNetwork architecture]]
|
