Progressive Network Transformation with RINA

Kewin Rausch and Roberto Riggio, CREATE-NET

 

Nowadays, to pick up a famous quote, “the networks they are a-changing”.

With the advent of mobile devices, the change of the traffic pattern (which is moving from text-based to multimedia-enhanced), the introduction of virtualization functionalities and the birth of cloud services, the network has changed immensely in just ten years. This rate of change is accelerating, which increases the necessity for a programmable and dynamic network. SDN is proposing an agile, programmable, open-standards based solution that can be used to address this problem.

But are we using the right foundation for this new technology? The current concept of the network has worked well until now, but is based on a view of internetworking that is starting to show its limitations. The rigid server-client approach is now evolving to a more decentralized view, where we have more varied patterns of communication between processes. Network organization is becoming increasingly specialized to specific contexts, so what is really needed is a generic architecture compatible with the existing infrastructure and easily customizable to address the increasing range of specific requirements.

A possible answer to this question is an idea that is currently being evaluated as an alternative to the TCP/IP approach. RINA (an acronym for Recursive InterNetworking Architecture) is an emerging new concept of the network, based on the idea that networking is Inter Process Communication (IPC). Standard IPC services are repeated over different instances of a single type of layer. This approach allows for any number of cleanly separated layers (not restricted to five or seven layers, but instead as many, or as few, as your network needs). RINA is an architecture that, by design, not only replaces the current Internet functionalities, but naturally embraces the new emerging concepts such as SDN.

This is not the place for a discussion about pro and cons of this new approach; a lot of evaluation to explore the concept of Recursive Internetworking is already taking place. What I will try to evaluate now is: how much disruption will the introduction of this new technology produce? Is a total “reboot” of the system required? Do we have to throw away or rewrite the solutions that have already been done?

The answer to this question is: no, it’s not necessary. Companies all over the world have developed solutions using the current network technologies that cost millions of dollars and many years to be designed, developed and tested: changing all of this is not an option. What RINA can offer is the possibility to simply use all those solutions, while providing additional functionalities, in a more scalable way. How can this be done?

RINA offers software a simple ‘black box’ view of the network. Software simply requests services from the network (including QoS parameters such as bandwidth and delay) without having to worry about the details of it. Each network layer does exactly the same with respect to the layer below. Since RINA does not need to know anything about the traffic apart from the service that has been requested, it is straightforward to introduce it into existing systems.

The idea is, instead of using IP to move RINA traffic, we are using RINA to move IP traffic. This means that all the existing applications that work with IP will continue to work without any change. The IP layer operates normally, even though it is sitting on top of RINA; no change is required to the IP network configuration, firewalls or servers. RINA as a lower layer will transparently transport the IP data. You can also enhance this data transport, by applying a different routing strategy, a custom congestion control or a personalized scheduling policy, without affecting the configuration or the software architecture.

Figure 1

Figure 1 Server-client communication over IP with legacy, unmodified, software which is transported around using RINA architecture.

Figure 2

Figure 2 Pure IP clients, which do not know what RINA is, communicate with legacy servers in the service provider (Data Center) DC. Transmission within the DC is provided with RINA over Ethernet. Router nodes (R) encapsulate the IP traffic over RINA, which is then provided to applications on servers(S) as it was originally.

An additional functionality that you can gain from this approach is that it provides multiple private IP domains; since the traffic is transported by RINA, the routing is independent of the global IP layer. The layering organization of RINA allows you to handle this transparently with minimal performance costs.

This is not just a theoretical description; a prototype1 of “traffic tunneling” of IP over RINA has already been demonstrated by the PRISTINE project2 at the 2016 SDN World Congress in The Hague. The demonstration showed the transport of HTTP video streaming traffic (using standard IP-based VLC client and server) over a RINA network. Both the client and the server saw only an IP network, but reconfiguring the underlying RINA routing policy in the server ‘data center’ enabled the service chaining to be varied without changing the client or server configuration.

To recap, exploiting this clean slate RINA architecture (which integrates by design all a modern network needs) does not mean abandoning the software and hardware that makes the network of today, but rather integrates and enhances them. There is no need to incur a cost to adapt software to the new network, because the network can adapt to the software requirements. Now you can move and enhance legacy IP traffic without complex stack hacks, which are difficult to maintain and can disrupt existing features. This change provides the abstraction and flexibility that current, and future, software needs.

 

1https://github.com/IRATI/nori

2http://ict-pristine.eu/

 


 

Kewin RauschKewin Rausch joined CREATE-NET in 2014 as a Junior Research Engineer. He’s a computer scientist dedicated in the sector of Networking Research, bound to the job of translating theoretical ideas into working prototypes. Kewin, now, is mainly involved with Recursive Internetworking and 5G projects. His actual interests space from new generation protocols to computer security. When not in front of a computer, he enjoys hiking, star gazing and playing go.

 

Dr. Roberto Riggio is currently Chief Scientist at CREATE-NET, Italy and Guest Lecturer at the University of Trento, Italy. He is involved in several European 5G-PPP research projects and has directly generated more than 1 M€ in competitive funding. His research interests include performance isolation in 5G networks; end-to-end orchestration of 5G networks; and lightweight management and orchestration platforms for mobile edge computing. He has 2 granted patents and has published more than 70 papers in internationally refereed journals and conferences. He received several awards including: the IEEE INFOCOM 2013 Best Demo Award, the IEEE ManFI 2015 Best Paper Award, and the IEEE CNSM 2015 Best Paper Award. He serves in the TPC of leading conferences in the networking field and he is associate editor for the Wiley International Journal of Network Management and Editor for the Spring Wireless Networks journal. He is the co-founder of the IEEE Soft5G and of the IEEE 5GMan workshops. He is a member of the ACM and a Senior Member of the IEEE.

 

Editor:

Neil DaviesNeil Davies is an expert in resolving the practical and theoretical challenges of large scale distributed and high-performance computing. He is a computer scientist, mathematician and hands-on software developer who builds both rigorously engineered working systems and scalable demonstrators of new computing and networking concepts. His interests center around scalability effects in large distributed systems, their operational quality, and how to manage their degradation gracefully under saturation and in adverse operational conditions. This has lead to recent work with Ofcom on scalability and traffic management in national infrastructures.

Throughout his 20-year career at the University of Bristol he was involved with early developments in networking, its protocols and their implementations. During this time he collaborated with organizations such as NATS, Nuclear Electric, HSE, ST Microelectronics and CERN on issues relating to scalable performance and operational safety. He was also technical lead on several large EU Framework collaborations relating to high performance switching.  Mentoring PhD candidates is a particular interest; Neil has worked with CERN students on the performance aspects of data acquisition for the ATLAS experiment, and has ongoing collaborative relationships with other institutions.

 


 

Subscribe to IEEE Softwarization

Join our free SDN Technical Community and receive IEEE Softwarization.

Subscribe Now

 


Article Contributions Welcomed

Download IEEE Softwarization Editorial Guidelines for Authors (PDF, 122 KB)

If you wish to have an article considered for publication, please contact the Managing Editor at sdn-editor@ieee.org.

 


Past Issues

November 2018

March 2018

January 2018

December 2017

September 2017

July 2017

May 2017

March 2017

January 2017

November 2016

September 2016

July 2016

May 2016

March 2016

January 2016

November 2015


IEEE Softwarization Editorial Board

Laurent Ciavaglia, Editor-in-Chief
Mohamed Faten Zhani, Managing Editor
TBD, Deputy Managing Editor
Syed Hassan Ahmed
Dr. J. Amudhavel
Francesco Benedetto
Korhan Cengiz
Noel Crespi
Neil Davies
Eliezer Dekel
Eileen Healy
Chris Hrivnak
Atta ur Rehman Khan
Marie-Paule Odini
Shashikant Patil
Kostas Pentikousis
Luca Prete
Muhammad Maaz Rehan
Mubashir Rehmani
Stefano Salsano
Elio Salvadori
Nadir Shah
Alexandros Stavdas
Jose Verger