Recursive Internetwork Architecture: Difference between revisions

Content deleted Content added
Hayazin (talk | contribs)
Introduction: Fixed bad/inconsistent style
Hayazin (talk | contribs)
Introduction: First series of modifications aimed at addressing the neutrality problem.
Line 40:
==Introduction==
[[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 “IPCor model”"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 capturesof theRINA common elements ofconcretizes distributed applications, calledin Distributed Application Facilities or DAFs, as illustrated in the Figure to the right2. 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 DAP’s externally visible information is represented by objects and structured in a Resource Information Base or 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).
 
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 SDU ([[Service Data Unit)|SDU]] Protection module.
 
[[File:RINA-arch.png|thumb|350px|Figure 3. Example of RINA networks and IPC Process components]]
 
DIFs, being DAFs, 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 elementscategories are ordered inby increasing complexity and decreasing frequency of use, with elementsdata at the far lefttransfer being used the simplest and most (perfrequent, packetlayer processing)management butbeing the leastmost complex, and elementsleast tofrequent, theand rightdata beingtransfer notcontrol often used,in but very complexbetween. All the layers provide the same functions and have the same structure and components,; howeverall adaptation comes from configuring these components arevia configuredpolicy via<ref>I. policiesMatta, inJ. orderDay, V. Ishakian, K. Mattar and G. Gursun. Declarative transport: No more transport protocols to adaptdesign, only policies to differentspecify. Technical Report BUCS-TR-2008-014, CS Dept, Boston. U., July 2008</ref>. This mirrors the [[separation of mechanism and policy]] common in operating environmentssystems.
 
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, whichwhere godata one layergoes up or down) one layer.
 
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.
In short, RINA has the following features:
 
* 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).
* 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.
* 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.
* 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.
* 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.
* 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.
* 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.
* 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.
 
==RINA compared to [[TCP/IP]]==