Delivering on simpler, faster guaranteed networking

New networking technology has always alluded to the positive outcomes it will bring to the table, a route to increase the good things with the network, where it goes even faster, bigger and more software- programmable. While there is a hidden balance at play here for the network operator, were they have to ensure that bad things don’t happen, and this can only be done by imposing invariant properties and eliminating waste.

Networks are becoming ever more complex, and network management approaches are trying to be “more clever” (SDN is an example) or “more simpler” (Zero Touch Automation is an example). Industry analyst are suggesting that the return on investment (ROI) on these approaches is a ration of 20 to 1 in favour of ”make it simpler”.

RINA is a universal framework for distributed computing based on networking fundamentals and is in essence an abstraction framework, one that collapses complexity. As recently highlighted by John Day RINA offers a clear path to the “opportunities for decentralized management”.

The RINA DMS (Distributed Management System), as developed through the ARCFIRE project, is a tool that demonstrates that RINA leads to simplification of management definitions, implementations, and that coordinated management can evolve from complex workflows to a strategy-oriented management task.

A single manager can simultaneously perform on an adequate number of strategies, with a manager being able to scale out/up and scale in/down, in the case where a single manager is insufficient.

The best way to internalise this, is to consider the ”Towers of Hanoi” method of visualising RINA networks. With TCP/IP there is a ”beads on a string model”, which you can draw with crayons as boxes and lines that represent the implementation mechanisms.

In contrast, RINA (which is recursive in nature) uses nested scopes, which represent the functional outcomes. The implementation of each scope is hidden from adjacent layers. It’s a ”Russian doll of concatenated information photocopiers”. Inside each photocopier is yet more photocopiers. A piece of wire is just a hardware implementation of the ”copy data” API.

The charting innovation, as seen in the figure below, is a simple thing but really brings the essential difference to life. It shows the standard RINA example with its original design (top) and then 4 graphs generated by the DMS. Each graph shows the network from a different perspective: network (nodes) the individual nodes with their DIF structure, the Point-to-Point graph the nodes and their connections, the DIF graph all DIFs in the network, and the network graph the created IPC processes and their DIF relationship.


Now, these four graphs are isolated, since it is very hard to show a 3-dimensional network (as any RINA network is) in a 2-dimensional frame. We can however look at nodes and their DIFs (so essentially the network/nodes graph) and use the idea of an onion diagram (or stacked pie charts, or stacked donut charts). Looking at operating system, one of the classic layouts used is showing `rings’ of its elements (such as device drivers) with the kernel being in the core, surrounded by device drivers, and applications being in the outer ring. Now we can create a 2-D finger print of nodes and the DIFs they use, and we can even show some connections. The top part in the figure below shows how that will look like for the standard RINA network example.


We can even go one step further and try for 3-D, as shown in the bottom of the figure. We simply turn the 2-D nodes and show all the DIFs plus the connections. This view is node-centric, it shows the nodes with their DIFs, top to bottom. If we reverse the 3-D towers, we get a DIF-centric view, with top-level DIFs being the larger parts of the towers. Here, larger DIFs have a wider scope, the smallest DIFs being Point-to-Point connections with the smallest possible scope. So we can show very different network and DIF properties using the same visualisation.

Footnote: Hat tip to ARCFIRE advisory board members Martin Geddes and Sue Rudd for their valuable input on this post. 

Leave a comment

Your email address will not be published. Required fields are marked *