An interview with Dr Eduard Grasa, i2CAT
Recursive InterNet Architecture (RINA) is a “return to fundamentals” redesign of data networking. (For an introduction, see my 2013 article “TCP/IP vs RINA”.) I interviewed Eduard Grasa of Fundacio i2CAT, a research centre in Barcelona. Eduard is a member of the European network research community who is actively leading cutting-edge research.
[Disclosure: My associates at Predictable Network Solutions Ltd are part of the PRISTINE consortium. I am on the external advisory board of the ARCFIRE project.]
MG: What is i2CAT and what is your role?
EG: The goal of i2CAT is to to perform innovation and technology transfer within the Internet infrastructure and applications space. We bring together universities, companies, government and citizens. Our focus is more on applied research, innovation and prototype development, rather than basic research (although there are some exceptions).
We have lots of freedom to explore new ideas. We decided to get involved in the RINA initiative, since it has the kind of long-term big impact that we seek. My personal involvement in RINA came after I completed my PhD here at i2CAT. I subsequently read John Day’s book on the fundamentals of networking, and knew i2CAT had to be involved in RINA somehow. Right now we are a great team of four people dedicated to RINA R&D activities.
Who should care about RINA and why?
RINA should interest users, operators, vendors and policy makers. All of these stakeholders should be concerned about society having a reliable underlying platform for distributed computing.
At the end of the day, networks are just an enabler, not an end goal in themselves. They help applications to deliver experiences of value to users. RINA is part of a process of deepening our understanding, so we can make networks as simple as possible. This frees up resources for more and better applications.
At present the people who are most interested in RINA are network researchers (although we see growing interest from funding and standards bodies). They have been working with TCP/IP for 40 years, despite its inflexibility. However, TCP/IP has been taken as being a general framework, whereby all problems have to be solved within an “all-IP” approach: Internet of Things, telephony over packet data, e-health, etc.
What’s the attraction of RINA to network researchers?
At present, each solution has to be developed for a specific context. There is a lot of pain as the supposedly general framework of TCP/IP doesn’t fit their application needs. As a result, they offer proposals for improving TCP/IP. This makes it ever more complex over time.
A different framework like RINA makes it easier to transfer general concepts to the real world. As it is a more general framework, it helps to reduce complexity. This means fewer bugs and fudges. So the real value of RINA is as a means of solving real-world problems of reliability, performance, capability and cost.
With TCP/IP you can combine RFCs to get point solutions to be RINA-like; but when you put everything together you get an expensive mess. Our working hypothesis is that RINA is indeed a general theory of computer networking.
For instance, there are innovative researchers working on the ∆Q performance calculus and resulting contention management technology. That technology was first implemented in TCP world. Its developers are looking at how it could have a better and simpler implementation in the RINA world. This is a win for everybody.
At what stage of development is RINA?
To gauge the development of RINA you have to differentiate the overall general reference model and its specification from specific (prototype) implementations. We are architects responsible for that general model. As researchers we are not professional implementers of products for sale and public use.
What motivates us is how RINA, being much newer than TCP/IP, offers a “playground” for new ideas. With the overall specification we have made good progress, advanced enough to demonstrate interoperability between RINA implementations. This is comparable to “vanilla” TCP/IP internetworking, with more advanced experimental specifications being currently drafted in European research projects.
We currently have three RINA prototypes:
- A software-based simulator
- An academic, Java-based research implementation by Boston University
- A Linux-based implementation here in Europe funded by the EU
One way of measuring RINA’s progress is through “technology readiness levels”(TRLs). These run from one (merely a concept never tried) through to ten (a fully matured market). TCP/IP is clearly at TRL10. Without the aim of being super-precise, but to provide some references to the reader:
- Software Defined Networking (SDN) is TLR9,
- Network Function Virtualisation (NFV) around TRLs 7-8, and
- some technologies labelled as “5G enablers” are around TRLs 4-5.
Our current work on RINA prototypes will soon reach TRL5. Once we’ve done the demonstrations at scale over the next couple of years, it will reach TRL6.
The EU is backing RINA through its R&D investments. What work are those projects undertaking?
There are three projects:
- IRATI (2013-2014): This was a RINA implementation for Linux, doing data networking over Ethernet (bypassing IP). The use case was to apply RINA at the data centre space. It’s an open source prototype that continues to be used.
- PRISTINE (2014-2016): This is a bigger project than IRATI. It is looking at the programmability of RINA, and how a single architecture offers solutions to a number of areas: congestion management, resource allocation, routing, security, and network management. It also in expands the number of use cases: SasS-style cloud networking, telco applications (e.g. NFV), and distributed clouds. There is an SDK and improved prototype, so more people can use it without needing to take a PhD first.
- ARCFIRE (2016-2017): This latest project has two main goals. Firstly, to take the prototype to TRL6. RINA is then a proven general design for delivery of services on any access technology. Secondly, we show that RINA is a simplerdesign for operator networks. This is framed as a “5G” goal, but we see it as broader: a design for a better kind of Internet.
The EU has dedicated pots of funding for technologies that are seen as “strategic”, such as 5G, SDN, and NFV. RINA is still not yet at that level; it is one of a number of point investments. That said, it is closely related to SDN and 5G. We are raising its visibility to make the EU more aware of its potential impact and strategic importance.
What are the benefits that RINA has demonstrated so far?
So far RINA has been demonstrated through concept analysis, simulations, and proofs of concept at a small scale. We know that it offers a complexity collapse in designing and building networks. This brings down skill level required to design and operate the network.
There are specific benefits in every aspect of networking. For example, take security, where there are many inefficiencies contributing to the insecurity of TCP/IP. This framework exposes network addresses to applications, so it’s easy to get information on the internals of an IP-based network. The mechanism to attack the network is built-in by design! In contrast, RINA is a set of completely isolated containers that can communicate in a controlled way. How those associate can be secured, hiding the network’s internal structure from applications.
Also, as one well-known security expert says, “complexity is the enemy of security”. If you can’t fully understand a system and reason about it, you can’t know where the vulnerabilities lie. Just look at the number of new RFCs and protocols coming out of the IETF each year: it just goes up and up. This results in a very complex security problem due to the lack of any clear structure.
Do you have any other examples of RINA’s benefits?
Yes. Another example is the bounding routing table sizes. The Internet is misnamed: it is really a “catenet” the concatenates networks, not a true internetwork with intermediate gateways. That means it has a flat structure, so internal and inter-network routing are done in a single layer. All applications also have to be in that single layer.
In order to scale, you have to make that layer get bigger, so routing tables go up in size. This makes routers more expensive and brittle. Whilst people may see the Internet as being big now, projections show it’s tiny compared to what we want to achieve. Yet we already have a lot of scaling problems.
We see proposed solutions like IPv6, but these all have the same fundamental problems, such as trying to scale a single layer. The constraints of the real world make it hard to deploy those technologies in an economic manner.
Mobility and multi-homing are also other areas where RINA adoption will bring considerable simplification, again due to the current Internet’s incomplete naming and addressing scheme. One of the results that ARCFIRE will be showing is how a RINA mobile access network is more efficient that current state of the art designs (such as LTE Advanced).
What are RINA’s benefits that you anticipate in future?
I see RINA offering increasing simplicity and lower overhead, with more security. Networks will over time become ever more responsive to application needs. That support is missing today, as applications lack a clean way in which to express their requirements.
RINA’s generality also means we can reason in abstract about networks, so it is far easier to secure. We can perform more sophisticated architecture and policy changes, and make their outcome predictable. This means we can make the network both more dynamic and cheaper at the same time.
Indeed, RINA is a framework to address many efficiency issues, such as power consumption. One way to get to low power use is to put lots of effort into electronics design (e.g. hardware with less energy consumption). The other way is to make more efficient use of what already exists. RINA’s smaller routing tables allow us to use 1/10 to 1/20 of the memory.
What are the technical challenges facing RINA going forward?
RINA is a network architecture, not a protocol (i.e. a style of construction, not a building). It tries to separate the general theory (“mechanism”) from specific solutions (“policies”). The key problem is to get this abstraction right. In doing so, we face two pressures.
One is to go faster, so as to make RINA visible soon and to get critical mass. The other is to slow down, as we can’t grow too fast. The risk is we get divergent solutions, or “polluted” versions of RINA that aren’t right due to invalid assumptions. So we need to balance these desires, so as to keep this abstraction “neat”.
We must also understand what sort of policies are the best ones for specific problems. So I might be an engineer who covered the basic concepts in university. I now need to apply those ideas to my data centre. The RINA community can offer me the right mechanisms, policies and trade-offs, and caution me against unwise or infeasible approaches.
So we need practice at how to instantiate the general theory to the point solutions to develop this body of experience and expertise. After all, if you need to update the general theory when you instantiate it, you don’t yet have a general theory! We so don’t want to recreate another mess like TCP/IP.
That means RINA is not a closed end state, as that’s not science. It will and must evolve since it is a working hypothesis for a general theory of computer networking. At the end of the day, we are not here to promote RINA, but rather to understand how computer networks actually work. That’s real science! In ten years’ time, our progress will be measured by how well we learn to see things differently.
What are the non-technical barriers that RINA faces?
The key problem is inertia: TCP/IP has a whole industry behind it, with a lot of investment and momentum. Changing minds is complicated. People in universities who are learning computing get taught IP as “the” way we do things; it’s all Cisco routers and subnets. They don’t get taught abstract models, or how to question these approaches.
When you come along as say “this is wrong for X, Y, Z reasons!”, people find it a big surprise. “Come on, how come it’s wrong? We have WiFi and the Internet!”, they say. So we need a critical mass of people offering a credible alternative. Our job is not to convince people for RINA’s own sake, but to offer them the deep understanding as to why the current model is a money pit. Once they understand that, then they will join our movement.
Another challenge is that you need the right people who can think beyond the short term. We have to develop a new theory, with supporting protocols and implementations. It’s so easy to carry on with existing approach, even if it doesn’t take us to where we want to go.
How does RINA relate to SDN, network virtualisation and 5G?
With SDN there are as many (if not more) SDNs as there are engineers writing SDN code! In contrast, RINA is a single flexible framework that can adapt to any application’s requirements. It is the “perfect” incarnation of SDN, and also much cheaper.
RINA makes the functions of a layer programmable, but only what’s important. Meanwhile, SDN can originate yet another complexity mess: it’s the “machine code” of network programming, while RINA is like a high-level language that makes it “safer” and “simpler”. There are more restricted definitions of SDN that are basically platform implementation approaches that separate out packet processing “faster” parts (e.g. forwarding done in silicon) from the rest (route computation done in general x86 hardware). RINA routers can leverage the same implementation strategy where it makes sense.
Virtualisation in RINA is both nowhere and everywhere: the Distributed IPC Functions (DIFs) are the layers that abstract (and hence virtualise) the underlying connectivity. Today you get taught the five-layer model in network engineering courses. When you have those fixed layers you virtualise each one independently. But if you have (only) as many layers as you need, don’t need to define “virtualisation”, as its already built-in as a first class part of the design.
5G for some people is just a new radio interface for mobile access networks, maybe with some updates in the mobile network core. Seen more holistically, it is about being able to support any application on any access technology with just one network infrastructure. For example, a polyservice network is a potential incarnation of 5G. With flexible layers we can adapt the policies of the layers (flow control, routing etc.) to the nature of the bearer and/or underlying layers. This is what we are looking into in the ARCFIRE project.
Where do you see the early commercial applications of RINA and when?
Ah, that needs a crystal balls that nobody has! Nonetheless, the RINA community sees two broad approaches to its initial adoption: On top of IP, and under IP. (RINA can also be deployed alongside IP.)
For “under IP”, the data centre is one example. We can also replace telecoms protocols like MPLS. This lets us carry IP (as well as many other network technologies) on top of one well-behaved network with traffic engineering and security. Another example is Metropolitan Area Networks (MANs) offering carrier Ethernet services. We can substitute for their “queue and mark” structures.
For “on top of IP”, RINA acts as a virtualisation solution, with network overlays on top of an IP substrate. You can add as many layers as you want to do services like VPNs, SD-WAN, or distributed cloud to the home.
I would envisage deployed and working commercial applications (at a small scale) around 2020, using RINA for strategic competitive advantage.
Who should get involved, and what’s the next step?
RINA opens up new “green field” markets, and is of immediate interest to network researchers, operators, vendors and standards bodies. We are coordinating these institutions through an informal group, the Pouzin Society (named after Louis Pouzin, a co-inventor of packet networking).
The role of the Pouzin Society is to disseminate the science and technology to the R&D community. It also curates the RINA specifications, so you can think of it as an embryonic standards body. As we grow and reach critical mass we will eventually reach size where it justifies having formal funding to do these tasks a more professional way.
A specific target group at present are standards development organisations (SDOs). We are starting to work with some of them, making the point that RINA is a better platform for new ideas then TCP/IP. We are in the process of engaging ISO and ETSI as our initial targets.
In order to make the first step, I would encourage readers to visit the Pouzin Society website, where we have a number of videos and papers. We are planning a workshop in Europe around October.
For the latest fresh thinking on telecommunications, please sign up for the free Geddes newsletter.
Read It Now
