Recursive Internetwork Architecture: Difference between revisions

Revision as of 22:45, 13 November 2017

Revision as of 15:58, 28 November 2017

Line 76:

===Structure===

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 fixedfixed number of layers, every layer having the responsibility of a different function, as depicted in Figure 4 (functional layering).

[[File:TCPIP-arch.png|thumb|350px|Figure 4. Functional layering of the TCP/IP architecture]]

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 flawflaw are several: both inter-___domain and intra-___domain routing have to happen within the network layer, and its scope had to be artificiallyartificially 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). {{IETF RFC|1631}} (Informational), May 1994. Obsoleted by {{IETF 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 confinedconfined 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 fixedfixed 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===

Line 99:

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 identifieridentifier 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 flexibilityflexibility.<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 significantsignificant: 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 definedefine 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.

Line 128:

'''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 specificspecific QoS requirements from the layer below. Each DIF can be configuredconfigured 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 configuredconfigured 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.]]