Content deleted Content added
m Kvng moved page Recursive InterNetwork Architecture to Recursive Internetwork Architecture: camel case unnec |
m clean up, replaced: nucleous → nucleus, typo(s) fixed: connection’s → connection's (9) |
||
Line 17:
'''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, neither one is the case: in order to operate effectively IP needs to know what TCP is doing. The MTU discovery that TCP does in order to avoid IP fragmentation is a clear symptom of this interdependency. 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.
'''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
'''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 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 addresses. When TCP/IP was introduced it ran 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). {{IETF RFC|827}}, October 1982. Updated by {{IETF RFC|904}}.</ref> or the use of NAT, [[Network Address Translation]], as a mechanism for allowing independent address spaces within a single network layer.
Line 42:
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 or "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.
The IPC model of RINA concretizes distributed applications in Distributed Application Facilities or DAFs, as illustrated in Figure 2. A DAF is composed of two or more Distributed Application Processes or DAPs, which collaborate to perform a task. These DAPs communicate using a single application protocol called Common Distributed Application Protocol or CDAP, which enables two DAPs to exchange structured data in the form of objects. All of the
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, and is called a Distributed IPC Facility or DIF. A DIF can be thought of as a layer, and 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 such as bounds on data loss and delay, in-order delivery of data, reliability, etc. DAPs may not trust the DIF they are using, and therefore may decide to protect their data before writing it to the flow - for example using encryption - via the [[Service Data Unit|SDU]] Protection module.
Line 48:
[[File:RINA-arch.png|thumb|350px|Figure 3. Example of RINA networks and IPC Process components]]
DIFs, being DAFs, can in turn use other underlying DIFs themselves. This is the recursion of the RINA. 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 categories are ordered by increasing complexity and decreasing frequency, with data transfer being the simplest and most frequent, layer management being the most complex and least frequent, and data transfer control in between. All the layers provide the same functions and have the same structure and components; all adaptation comes from configuring these components via policy
As depicted in Figure 2, RINA networks are usually structured in DIFs of increasing scope. The highest layer is the one closest to applications, corresponding to email or Websites; the lowest layers aggregate and multiplex the traffic of the DAPs in the higher layers, corresponding to ISP backbones. Multi-provider DIFs (such as the public Internet or others) float on top of the [[ISP]] layers. Three types of systems are distinguished: hosts, which contain applications; interior routers, internal to a layer; and border routers, at the edges of a layer, where data goes up or down one layer.
Line 54:
To summarize, RINA uses the same concepts of PDU and SDU, but instead of layering by function, it layers by scope. Instead of considering that different scales have different characteristics and attributes, it considers that all communication has fundamentally the same behavior, just with different parameters. Thus, RINA is an attempt to conceptualize and parameterize all aspects of communication, thereby eliminating the need for specific protocols and concepts and reusing as much theory as possible.
==RINA compared to
===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 fixed 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 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). {{IETF RFC|1631}} (Informational), May 1994. Obsoleted by {{IETF RFC|3022}}</ref>
Line 65:
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 and 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
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.
Line 82:
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
===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">P. Brinch Hansen. The
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
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
===Security===
Line 98:
[[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. Boddapati 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 threat. No external tools such as firewalls are required.
| |||