Master Thesis A study of RINA(*) a novel Internet architecture (*) Recursive InterNetwork Architecture Submitted by: Periklis Zisis, 732218 Supervisors: Prof. Dr. Shun-Ping Chen Prof. Dr. Johannes Gerdes Eng. Dr. Ioannis Korovesis Outline Challenge to the researchers of networking Motivation Current state of the Internet
Current Internet shortcomings The model of RINA and its implementation projects How is RINA related to SDN Conclusion Challenge to the researchers of networking In the science Computer Science , we face a special challenge: We build what we measure We dont have the Nature to test the theories for the structure of systems. Thus, it is
difficult to distinguish what is a principle and what is an artifact of the engineering decisions. John Day, the originator of RINA, challenges the network architecture researchers to explore the properties of the IPC model. Motivation I discovered RINA during my research regarding the current state of the Internet. There was a view according to which the Internet expanded so fast without much research and some of the current problems could be avoided if tackled at the beginning. The fact that RINA is an alternative Internet architecture which attempts to solve the current Internet shortcomings makes it a topic worth to be examined. My curiosity of how the Internet could be with an architecture other than the TCP/IP, intrigued my interest regarding RINA.
The purpose of this thesis is not to prove that RINA will solve the current Internet problems but to present a different approach of how the Internet could be designed. Introduction The Internet is changing and evolving rapidly. Its early design was guided by the endto-end principles. However, currently many fundamental networking principles are challenged, resulting to weaknesses in the current architecture. The demanding applications and the requirements of the networks have increased the complexity of the Internet and have led to an architectural patchwork. New architectures are being proposed to solve the weaknesses of the current Internet.
RINA is a clean-slate architecture which was developed as an alternative to TCP/IP. It focuses on the fundamentals of networking and moves one step further by identifying that networking is IPC. Current state of the Internet The current state of the Internet puzzles the networking community. Some of the reasons are the following: The Increase of personal devices, Big data and the numerous demanding applications like IPTV. There is a growing tussle between the different stakeholders i.e. ISPs, users and network provides which want to interfere in the communications and satisfy their needs. Lack of trust between the communicating endpoints.
The applications need to access numerous servers/databases before returning the data to the user. Current state of the Internet The present state of the Internet leads to debates related to the future of it. Evolutionary research vs clean slate. Focus on understanding and improving the current Internet (evolution) or on designing new architectures from scratch (clean-slate). Purists vs pluralists. Monolithic view of the architecture which is specified by a universal protocol (IP) and virtualization is a means for testing/deploying a new architecture or an architecture which arises from a set of various existing protocols and IP is just one component of the overall system i.e. the Internet. Current Internet shortcomings
The Internet is facing severe problems: Router table size is growing exponentially leading to scalability issues with the routing system. According to Cisco, the current routing tables have passed the 512k route mark! Routing is done on the interface and not on the node itself, which according to the researchers of RINA leads to scalability and mobility issues. The network has to use a combination of the interface address and transport layer port number to identify applications. The interface is named twice by the IP and MAC addresses! Current Internet shortcomings Naming and addressing issues. The IP address is the only name in the current architecture and has multiple uses i.e. overloading of IP address semantics. The IP address is used both to identify the host (in fact its interface) and to locate that host on the network. When a host uses a different network provider its IP address changes. Thus, both the network providing host access and the host identifier are changing.
The IP addresses are confused to be node names! Thus, networks cant understand that the two or more IP addresses of a multihomed node belong to the same node! The current architecture is not able to handle heterogeneous networks. Reasons: congestion control mechanisms, lack of scoping in the current layered system. Only two scopes: Data link (scope of layers 1 and 2) and global (scope of layers 3 and 4). Current Internet shortcomings Mobility is cumbersome and doesnt scale and there is no support for multihoming. The fact that addressing is performed on the interface rather than on the node itself makes it hard to deal with mobility and multihoming. The node loses its identity while it moves from one network to another!
Current Internet shortcomings Network management faces difficulties. The network administrators encounter problems with configuration, traffic engineering and routing. The management costs and the complexity of the networks are increased! Lack of flexibility due to numerous mechanisms and protocols. The network administrators have to configure each network separately! Weak security. The current TCP/IP architectures faces a lot of threats like DoS attacks, viruses etc. Any application can freely connect to any other application. The global addressing results to an exposure of the addresses and to well-known ports. Numerous protocols and mechanisms leading to a complex architecture and thus to complex networks. Each protocol has a job to do. Current Internet shortcomings
Quality of Service is difficult to do. There is no built in mechanism which allows the network to provide specific QoS. Other than a TCP or UDP type of transport, applications have no other way of expressing their desired services characteristics to the network! What are the causes of the current problems? The network worked much better than anyone had any reason to expect. But what has actually happened? Industry took over a promising but immature technology i.e. the ARPANET and although there was lack of prior experience, it went into production immediately. Functions of the same scope got isolated! Relaying/error control functions.
Limited number of layers! According to John Day, the main reason of the problems, is the lack of fundamentals and rules of thumb. The fundamental principles remain stable across different scopes and are independent of technology! Communication in the current Internet Two types of flows- TCP or UDP with fixed characteristics.
No names for applications but only IP addresses and ports. Need to know in which port an application is attached to -> well- known ports and the addresses are exposed to the applications. Numerous protocols and mechanisms. Why to split TCP from IP? According to Dijkstra , if there are two layers of the same scope, the functions in the layers must be completely independent. Splitting IP from TCP creates problems with fragmentation/reassembly. It breaks the rules!
Are separating Error and Flow control from relaying and multiplexing independent? No! IP also handles fragmentation across networks. If a packet gets fragmented in a router Chances are a fragment gets lost towards the next hop IP needs to reassemble the fragments in the next hop and wait for 1 MPL But TCP times out in the order of RTT-> retransmit
IP fragments the packet, chances are a fragment gets lost Now the next hop has 2 incomplete IP packets! The problems arise because IP needs to know what TCP is doing and this is a strong indicator that it was not a good idea to separate TCP and IP. The model of RINA R. Metcalfe of MIT project MAC in 1972 has observed that Networking is IPC. IPC is a set of mechanisms for the exchange of data among multiple processes(IPC). These mechanisms allow the processes in distributed systems to communicate with
each other by using IPC services. IPC provides shielding to the processes. RINA is a network architecture based on fundamentals among which is that networking is IPC. Thus, RINA identifies that networking can be seen as a set of recursive layers that provide distributed IPC services over different scopes. RINA is based on two principles: a) Recursion b) Separation policy from mechanism Recursion
John Day, noticed that the protocol functions are repeated in different layers. The same protocol can be used repeatedly in a protocol stack, encapsulating each layer in another instance of itself. Layers are recursive. No need for purpose-built protocols for each layer! No fixed number of layers in the stack! Due to the fact that layers recurse and can scale in order to form a large internet, the architecture is called Recursive.
RINAs architecture is based on a single type of layer (DIF), which is repeated in a recursive fashion as many times as required by the network designer. Separation of mechanism from policy In RINA, policy and mechanism are separated! In simple words, a policy means what we want to do and the mechanism how it can be done. John Day, took this concept from OS and applied it in networks. Result: There are only two kinds of mechanisms in protocols! Loosely bound and tightly bound These mechanisms can operate according to different policies. Thus, the same mechanisms can be used in different ways and can work across wide ranges of scope,
QoS and bandwidth -> An architecture will need less protocols! The result of the separation of mechanism from policy is that in RINA only two protocols are needed. One data transfer protocol, which is the EFCP One application protocol, which is the CDAP Recursion and separation of policy from mechanism Different examples of IPC between application process A and application process B.
The mechanisms for doing IPC in the different cases are the same, they just need a different configuration. It is a repeating structure: distributed applications doing IPC at a bigger scope(network) use the services of distributed IPC at smaller scopes(link). The DIF We have seen that in RINA there is a single repeating layer which has the same mechanisms and operates over different policies. This layer is called DIF(distributed IPC facility). It is black box which consists of IPC processes which provide IPC services in order the applications which are in the systems to communicate with each other. The communication is done by using names!
The DIFs have a scope. The greater the range in a network the more DIFs are required! A DIF can be thought of as a private network which is different from the traditional definition of layer in the TCP/IP architecture. o A DIF does not perform a single function but a coordinated set of policy managed functions to achieve the desired IPC service o The DIF separates various concerns, including operation over different timescales The DIFs can be dynamically instantiated and the policies can be tuned according to
the network conditions. The Structure of a DIF Processing at 3 timescales Fast IPC data transfer mechanisms which actually move the data (IP +UDP). Slower IPC data control mechanisms for retransmission, flow control etc. Even Slower IPC management mechanisms for routing, resource allocation etc. The protocols of RINA
One data transfer protocol : EFCP Its a combination of DTP and DTCP. The mechanisms are separated from policies. It is based on the soft state Delta- t protocol developed by Richard Watson. The DTP includes mechanisms which are tightly bound to the transfer PDU such as sequencing, fragmentation etc.
The DTCP includes mechanisms which are loosely bound to the transfer PDU such as flow control, retransmission etc. The protocols of RINA One application protocol: CDAP It consists of : CACE( used to establish application connection between two applications), Authentication(policy) It is an object oriented protocol (similar to CMIP) and provides the minimal six operations: create/delete, read/write and start/stop. From application to application what changes is the objects being manipulated while the
protocol remains stable! How RINA differs from TCP/IP Unlike TCP where a port number is mapped to one and only TCP connection, in RINA port allocation and data transfer are separate functions-> A single flow can be supported by one or more data transport connections. Security: By decoupling port allocation from synchronization-> Applications dont listen to a well-known port. Applications communicate by using names. In RINA the addresses are internal to a DIF and hidden from the applications. DIF is a securable container (implies that firewalls are unnecessary). RINA security is considerably less complex (requires less mechanisms) than TCP/IP. In order an IPC process to join a DIF(enrollment), it must first be authenticated! How RINA differs from TCP/IP
Routing is done on the node and not on the interface. The directory (IDD) is used to map the source and destination application names to node addresses. The route from source to destination is computed as a sequence of (N)- addresses where the next hop is a node address. Each IPC process knows how to map the (N)addresses to (N-1) addresses to determine the path. How RINA differs from TCP/IP Multihoming is solved by recognizing than routing is a two step process of picking the next hop and then selecting the path to the next hop. It can be seen as an IPC process having more than one (N-1) mappings. If a path to a node fails , RINA maps the node address to another operational interface. Mobility can be seen as a dynamic version of multihoming which means that any structure which can provide multihoming is also able to provide mobility without the
need of extra protocols. Each new PoA means that the mobile host joins a new DIF while dropping its participation from the old ones. How RINA differs from TCP/IP Naming and addressing scheme : All entities (nodes, applications, PoAs) in RINA are named. The application processes have names which are external and addresses which are internal and can be seen only by the members of the DIF. No global address space but instead a global namespace is required. Less protocols and mechanisms: By separating mechanism from policies, one protocol is required for data transfer and one for the communication between the applications. Thus, the architecture is less complex. Support of QoS requirements: RINA simply considers QoS to be a set of parameters inside the DIF. Furthermore, it provides multiple classes of QoS independent of the
applications. Each DIF can support a set of QoS characteristics by using its mechanisms which are hidden inside it. How RINA differs from TCP/IP RINA can be used in heterogeneous environments because there is no need for mechanisms that work well for all physical media. Each physical medium has its own DIF with specific characteristics. Adoption: RINA can be used over IP, under IP (similar to MPLS) or alongside IP. A Shim DIF which provides the RINA API can be used to connect RINA with the current TCP/IP stack. RINA and its implementation projects The projects of RINA prepare the tools and the platform which the network and application developers can use in order to advance the goal of RINA for a better Internet.
IRATI: Its goal is to explore RINA and develop a model which can be used in production scenarios like the data centers. IRATI uses the OFELIA testbed (Openflow) for experimentation activities. Open source prototypes over Ethernet for UNIX-like OS as well as over UDP/IP are currently under development. PRISTINE: Focuses on the programmability of RINA and aims at the implementation of a software development Kit for RINA. Use cases: data centers, carrier network. IRINA: Its strategy is to take the leadership in research networking back from the vendors. Focuses on performing use case studies in NREN scenarios. ProtoRINA: It is a prototype developed from Boston University and tested on its campus. It has been used to demonstrate the advantages of RINA and to experiment with different
policies. Software Defined Networking SDN focuses on programmable networks and attempts to simplify network management. Its main principle is the separation of control plane from the data plane. The control functionality is removed from the network devices->flexibility. The control logic is moved to the SDN controller which is used to control the network. The network devices (routers, switches) can be controlled through software applications. The most popular SDN mechanism is the OpenFlow, which allows the network administrators to configure devices of a network which are from different vendors, in a uniform way!
How RINA is related to SDN RINA supports SDN, by allowing users to set up a private network(by using DIFs) on top of physical networks. Both architectures make a clear distinction between the data transfer, data transfer control and management. Scoping is an aspect of both architectures. Each DIF provides IPC services over a certain scope. Similarly, in SDN the management layer is responsible for managing the network over a certain scope. However, the current SDN management layers have open issues and they are limited to a specific management scope( not easy to define new scopes)-> tied to the current architecture.
Adoption of RINA by SDN, in order to build a management architecture on top of a new network architecture which avoids the TCP/IP shortcomings. The recursive model of RINA can provide nested scoping and better manageability support. The application can be programmed recursively over different scopes through the RINA API. Conclusion RINA is a new formulation of how to do networking. It incorporates the lessons of the last 40 years and steps away from many things that have not worked out well. RINA does not aim to replace the Internet as we know it, neither that its the solution to all Internet problems. It symbolizes a new age of protocol research and implementation.
To add new capabilities to the networks To make networks more efficient, manageable and secure THANK YOU Questions? Backup slides For communication between the two applications in RINA the following are required: Application process naming-> RINA has a complete application naming scheme
Flows-> The flows can have many characteristics depending on different application requirements Communication medium API-> Used to request allocation of flows to other applications, by name Objects-> Each application decides on their contents A generic application connection establishment procedure, with authentication policies A single application protocol -> CDAP Backup slides
Watson, Delta-t protocol Briefly, Watson proved that the state of a connection at the sender and receiver can be safely removed once 3 timers expire and without explicit handshaking messages which currently happens in TCP/IP . In other words, Watson followed the idea that in order to achieve reliable connections, flow control can be done by binding on 3 timers: maximum packet lifetime, maximum retransmission time and maximum time before acknowledgement . Backup slides IDD(directory) Every processing system maintains an instance of IDD which is an application process and acts as a directory which enables the system to make available its applications as well as to discover other applications. The DAPs of the same DAF exchange messages
for the discovery of applications. As we mentioned before, the IPC processes must be on the same DIF in order to communicate . Thus, when the destination application is found, a new DIF has to be created (in case there is no common DIF between the two systems) in order for the two applications to communicate. Backup slides IDD is responsible for three functions: Maps the source and destination application names to IPC processes through which they are available. Discovery of applications- The DAPs exchange messages until the destination application process is found. To be specific, an IDD DAP can ask a peer DAP for a particular application by sending an IDD-request. This request contains the destinations IDD DAP name, the sources IDD DAP name and the requested applications name. The peer DAP which will receive the request, it will check the destination IDD DAP name and if it is not
itself, then it will forward the request to the appropriate DAP. Otherwise, it will look up its cache for the requested application process name and get the next IDD DAP that the request should be forwarded for the particular application name. When the destination application is found, the IDD will verify that the requested application is still there and the requesting application is allowed to access the requested application. Creation of a supporting DIF- When the destination application is found, a common DIF between the two systems which carry the communicating applications, is required. For the supporting DIF there are two possible options: a) use an existing DIF and expand it to span from the source to the destination or b) create a new DIF from scratch. If the source system is not allowed to access any of the already existing DIFs or if the existing DIFs cannot provide the requested QoS requirements, then a new DIF will be created. Backup slides SDN abstractions The forwarding devices or switches in SDN terminology comprise the physical network equipment and they can be routers, switches, access points etc The control plane needs a flexible forwarding model. To achieve this, a forwarding abstraction is needed in order to hide the details of the underlying hardware.
The control is logically centralized and provides a specification abstraction so that the whole network can be seen as a single system . This abstraction can be seen as network virtualization which provides a virtual image of the network. Underneath this virtual image there is the physical network. This gives us a simplified model and enables the SDN architecture to be applied over a wide range of applications and heterogeneous environments. In addition, the network operators can programmatically configure this simplified network abstraction, rather than having to configure each device separately. Distribution abstraction- to have a logically centralized controller. Backup slides Communication between 2 processes by using DIFs.
Lets consider two application processes (S and D) in two different systems The S application process resides in system 1 while the D resides in system 2. These two processes want to communicate. There is also an intermediate node between these two systems as well as the DIF A, DIF B and the DIF C. The application processes A1,A2 and A3 comprise the DIF A, the processes B1,B2 the DIF B and the processes C1,C2 the DIF C accordingly Backup slides The procedure in order for these two processes to communicate is the following: Firstly, the DIF A maps the names of S and D to the processes A1 and A3 accordingly through the IDD. The source application process S makes an allocate request using the DIF A and specifies the destination application (D) name. The flow allocator of A1 process, receives the request and if it is well formed, valid and there are enough
resources to honor it, it accepts it. Afterwards, the port-id of A1 is mapped to a CEP-id in order to create an EFCP instance at A1. The flow allocator of A1 looks up the local directory cache for the requested application process (D) and finds out that there is an entry that maps D to IPC process A3. Thus, it sends a create flow request to A3. This request is a CDAP protocol exchange. The flow allocator of A3 receives the create flow request and delivers it to the destination application process (D). The D makes an allocate response to A3. The flow allocator of A3 creates the necessary EFCP instance and sends a create flow response (CDAP) to A1.
If the response is positive, the two EFCP instances (identified by the CEP-ids) are concatenated and the application processes S and D can start sending/receiving data to/from each other. After communication is complete, S and D make a deallocation of the resources. Backup slides A set of distributed application processes is called DAF .The DAF performs different functions like weather forecast, genomics, communication service etc. The DAF operates over a DIF and it is used to manage the DIFs which make up the whole network.
The relation between these two facilities is that the DIF is a specialization of a DAF and provides only communication service, while the DAF has a more generic purpose. The IDD is a distributed application or as called in RINA, a DAF, which is a collection of two or more cooperating application processes in one or more processing systems Backup slides The port allocation state is created/deleted based on explicit requests, while the synchronization state is refreshed every time a dtp/dtcp packet is sent/received. The EFCP operates between the IPC processes in the source/destination systems There
is an EFCP instance for each different connection in each IPC process! Backup slides Fundamental Phases of communication When two systems exchange data, the phases and what has to be done in order for these two systems to communicate with each other are often neglected. Thus, the focus is mainly on the part of data transfer. However, in order for communication to occur, two phases must take place first. Firstly, enrollment must be done and afterwards the phase of establishment which is also known as synchronization or allocation. After these two phases, data transfer can begin and the two systems can start communicating with each other Backup slides Enrollment: This phase makes an object and its capabilities known to the network and it is used to create all the necessary information for communication. Establishment: The establishment phase creates, maintains and deletes the shared state necessary to support the data transfer phase. Data transfer: The data transfer begins, when the actual transfer of data is affected by the requested QoS Backup slides
In RINA, IPC processes need to be enrolled into the same DIF in order to exchange data. Enrollment is the phase by which an IPC process communicates with another IPC process in order to join a DIF. In order for an IPC process to join a DIF and make itself known inside that , the new member must know the name of the (N) - DIF that would like to join or the name of a member of that DIF. In the Figure, there is a large (N)-DIF. The DIF A represents a single IPC process and wants to join the (N)-DIF. There is a discovery application mechanism which is called IDD (further described in the next section), through which the IPC process A learns that the first IPC process of the (N)-DIF is the only reachable member and that they both share an underlying DIF which is the (N-1)-DIF (physical medium). The IPC process A, can use the (N-1)-DIF in order to allocate an (N-1) flow to the reachable member. After a flow is allocated, the CACE component of CDAP, is used to establish an application connection between the two processes. Once the address of the reachable IPC process is obtained and the application connection is established, authentication is also performed according to the policies of this particular (N)-DIF. If successfully
authenticated, the new member gets an address i.e. a synonym for the internal name in order to get known to the other members of the (N)-DIF . Backup slides After the enrollment phase, in which the new member A is enrolled to the (N) - DIF, the establishment phase (or allocation) for allocation of resources takes place. The resource allocator decides how many N-1 flows dedicated to data transfer will be allocated. At this point, we suppose that the IPC process A wants to allocate a flow with the IPC process B. Both processes are inside the same DIF (see Figure 3.14). At the establishment phase, the two communicating processes share information about their states (shared state). The source application process (A) generates an allocate request (IAP) and the Flow allocator creates a flow allocator instance, in order to manage each new flow. The source application process (A) has already a port-id which was acquired when it joined the (N)-DIF (enrollment). Backup slides When the flow allocator instance gets the allocate request of A, it instantiates an EFCP instance at the first point of the flow (A). The port-id is mapped to a CEP-id, which is used as an identifier for the EFCP instance. In general, the CEP-id is used to identify the shared state of one end of the flow.
Afterwards, the flow allocator instance checks its local directory cache. This directory maps the requested destination application names to a Next Place to look for it. In other words, it is used to find the IPC process through which the destination application (B) is accessible. If not found in its directory, it asks the neighbors. As a result, it points to the nearest neighbors until it finds B. When B is found, the flow allocator instance sends a create flow request to the address of the destination application process (B).The request for the creation of the flow is a CDAP protocol exchange. Afterwards, the destination sends back a create flow response. The source receives the create flow response (CDAP) from the destination, and if is positive, it instantiates an EFCP instance at the other end (B). The process B gets a port id which is again mapped to a CEP-id which is used as identifier. The source and destination CEP-ids are concatenated through the IAP for use as a connection id, and the flow allocation between A and B is now complete. The described procedure has the following advantages: 1) Access control can be done, 2) B can be found even if it moves.
At this point, either end may start the application protocol exchange. The data transfer phase between A and B can begin by using an underlying DIF! A can now start sending application SDUs to its peer. The SDU is delimited and transformed into user-data for a PDU. The SDU is delivered to the destination EFCP instance which is identified by the CEP-id and there it is processed. The resulting PDUs are delivered to the RMT for transmission. The RMT has already created a number of (N-1) flows of various QoS characteristics to various destinations.
RMT accesses the forwarding table to choose the (N-1) flow to send a PDU over. The PDU is queued on an outgoing (N-1) flow in order to be sent. This is achieved by consulting the forwarding table. After the communication between A and B is complete, deallocation of the resources takes place.