There are many challenges to achieve next generation networks. Many of the “marketed” benefits of 5G cannot be achieved unless the network allows new approaches to Security, End to End (E2E) Service Layers that are independent of lower layer resource allocation and guarantee Quality of Service (QoS).

In fact ARCFIRE advisory board member Sue Rudd has gone one step further and has done a great job of analyzing the seven critical challenges to meet the demands of both fixed and mobile Next Generation Broadband networking.

These challenges include :

• Unique Identifiers – Unique ‘Names’ for billions of IoT devices.
• Security that is inherent in the system or services design and that prevents applications from attacking either the network or other applications.
• Services that operate seamlessly both over any layer 1 physical Transport and any layer 2 Protocol to enable true Fixed Mobile Convergence.
• Global layer 2 support of vLAN Connectivity for Global Cloud and Software Defined Data Centers.
• End to End Services – for seamless end user to Service/Applications Assurance.
• Guaranteed Quality of Service (QoS and Security for ‘Network Slicing’ Latency, Bandwidth SLAs.
• Bursty Traffic Management that can mix hugely bursty video traffic efficiently with voice calling, mobile money transactions and occasional messaging.

But I wonder how can these challenges truly be addressed by patching the existing architecture ?

Without a strong architectural approach, like the one RINA proposes, 5G and Next generation Networks cannot really address these seven challenges, and in fact without a new architectural approach will be a no go on deployment.

Here at ARCFIRE we have taken some time to show how the principles of RINA would apply to the structure of Next generation Networks and are now in throws of running experiments in real world environments to prove those principles.

Firstly to the structure of these principles:

“Different layers, same functions but different policies“: In RINA all layers perform the functions required to provide distributed IPC over a certain scope and range of QoS. Layers are units of resource allocation, not units of modularity. Each layer manages a set of resources (buffers, scheduling capacity, bandwidth) using a common invariant structure, regardless if the layer manages a point to point medium, performs aggregation over a metropolitan network or provides a VPN service to a certain application. The RINA approach solves the “different layers, different functions” limitation

“Strict layering: layers are black boxes“. Each RINA layer is independent of each other, a DIF can only use the services of lower layer DIFs by invoking the operations in the lower DIF API – hence no layer violations are allowed. Within a layer all the functions (data transfer, data transfer control and layer management) have different degrees of dependence or coupling to each other. The design of the different protocol frameworks within a RINA DIF makes sure that all the DIF functions have enough information available for its correct operation. Therefore problems such as the one suffered by IP fragmentation which are due to “functions in different layers that are not independent” just do not occur in RINA.

“Variable number of layers, decided at design time“. In RINA – the architecture does not bound the number of layers that can be found in a network. Each network should use the number of layers that optimally solve its resource allocation and security requirements: no more and no less. Therefore the network architect has considerable freedom and flexibility in designing the network, while still bounding the overall complexity due to the use of the inmutable common infrastructure at each layer – regardless of its ranking/positioning. This environment contrasts with the “fixed and static” number of layers in current network architectures, where concepts such as network virtualisation, tunnels and overlays have to be introduced to work around this limitation at the cost of increasing the overall system complexity.

“Consistent API across layers“. In RINA since all layers provide the same IPC service, the API offered by all layers is the same. This API allows instances of application processes to allocate and use communication flows to other applications, defining a set of requirements for the quality of the communication flow. The network is just a distributed application, a form of distributed computing specialised to do IPC. This property of RINA architecture not only addresses the “incomplete and/or missing layer APIs limitation, but it also does it with the simplest possible solution: a common layer API from the application to the wires.

“Clear division of the functions of each layer“. Each DIF performs functions to provide IPC over a certain scope and range of QoS (data transfer and data transfer control functions), as well as the functions to autonomically manage this IPC service within the layer (layer management functions). Data transfer functions are loosely coupled to data transfer control functions via a state vector, and both data transfer and data transfer control functions are loosely coupled to layer management functions via the RINA Information Base (RIB). There is no need for concepts such as “separate data and control planes” with different protocols, all the functions of a layer are cleanly split between the aforementioned three categories. This approach is also usually followed by IEEE protocols (such as IEEE 802.11), RINA just generalises it to all layers.

ARCFIRE’s D2.2 Converged Service Provider Network Design Report [pdf], Section 3.8 has more details.

Secondly to the ARCFIRE experiments, as can be seen from D4.3 Design of experimental scenarios, selection of metrics and KPIs, the Experiment 3: RINA as an alternative to MPLS and Experiment 4: Dynamic and seamless renumbering, are going some way to proving the key performance indicators (KPIs) that address the serious challenges of next generation networks, and that an architectural approach like RINA is the only way to go.