RINA is a new network architecture that provides a consistent API across layers through a recursive model. The PRISTINE project has made advances in RINA including developing an open source implementation called IRATI and a simulator called RINASim. IRATI focuses on being flexible, modular, and programmable. Key components like IPC processes and policies are under development. Experiments show potential benefits of RINA for areas like congestion control, security, and simplifying VM networking. Further work includes improving core protocols, developing policy specifications, quantifying benefits, and engaging with standards bodies.

1. #ict-pristine
RINA: Recursive InterNetwork Architecture
Last advances from the PRISTINE project
Leonardo Bergesio on behalf of
The PRISTINE consortium

2. RINA INTRODUCTION
2
1
#ict-pristine

3. RINA higlights
• Network architecture resulting from a fundamental theory of
computer networking
• Networking is InterProcess Communication (IPC) and only IPC.
Unifies networking and distributed computing: the network is a
distributed application that provides IPC
• There is a single type of layer with programmable functions, that
repeats as many times as needed by the network designers
• All layers provide the same service: a communication instance
(flow) to two or more application instances, with certain
characteristics (delay, loss, in-order-delivery, etc)
• There are only 3 types of systems: hosts, interior and border routers.
No middleboxes (firewalls, NATs, etc) are needed
• Deploy it over, under and next to current networking technologies
3
1
2
3
4
#ict-pristine
5
6

4. From here …
4
Host
Enterprise router
IEEE 802.3 (Ethernet)
Enterprise router
TCP/UDP
Host
App
A
App
B
Application
A
Sockets API
OS Sockets
Layer
1. Bind/Listen to interface and port
2. Accept incoming connections
3. Connect to a remote address/port
4. Send datagram
5. Write data (bytes) to socket
6. Read data (bytes) from socket
7. Destroy socket
IP
IEEE 802.11 (WiFi)
Carrier Ethernet
Switch
IEEE 802.1q (VLAN)
IEEE 802.1ah (PBB)
Each tech has a different
API, and all are different
from the application API
Carrier Ethernet
Switch
#ict-pristine

5. To here!
5
Host
Border router Interior Router
DIF
DIF DIF
Border router
DIF
DIF
DIF
Host
App
A
App
B
Consistent
API through
layers
App A
Layer (DIF) API
IPC
Process
1. Register/Unregister App
2. Allocate/Deallocate flows
3. Write data (SDUs) to flows
4. Read data (SDUs) from flows
5. Get layer information
#ict-pristine

6. Internal layer organization
6#ict-pristine

7. IRATI: OPEN SOURCE RINA
IMPLEMENTATION
7
2

8. • … but can also be the basis of RINA-based products
– Tightly integrated with the Operating System
– Capable of being optimized for high performance
– Enables future hardware offload of some functions
– Capable of seamlessly supporting existing applications
– IP over RINA
RINA implementation goals
• Build a platform that enables RINA experimentation …
– Flexible, adaptable (host, interior router, border router)
– Modular design
– Programmable
– RINA over X (Ethernet, TCP, UDP, USB, shared memory, etc.)
– Support for native RINA applications
8
1
2
3
4
5
1
2
3
4
5
#ict-pristine

9. Some decisions and tradeoffs
9
Decision Pros Cons
Linux/OS vs other
Operating systems
Adoption, Community, Stability,
Documentation, Support
Monolithic kernel (RINA/
IPC Model may be better
suited to micro-kernels)
User/kernel split
vs user-space only
IPC as a fundamental OS service,
access device drivers, hardware
offload, IP over RINA, performance
More complex
implementation and
debugging
C/C++
vs Java, Python, …
Native implementation
Portability, Skills to master
language (users)
Multiple user-space
daemons vs single one
Reliability, Isolation between IPCPs
and IPC Manager
Communication overhead,
more complex impl.
Soft-irqs/tasklets vs.
workqueues (kernel)
Minimize latency and context
switches of data going through the
“stack”
More complex kernel
locking and debugging

10. High-level software arch.
10

11. PRISTINE contributions: SDK, policies, NMS
11
Normal IPC Process
(Layer Management)
User space
IRATI stack
Kernel
Kernel IPC Manager
Normal IPC Process
(Data Transfer/Control)
Shim IPCP
over 802.1Q
Shim IPCP
for HV
Shim IPCP
TCP/UDP
IPC Process Daemon
(Layer Management)
IPC Manager Daemon
Normal IPC Process
(Data Transfer/Control)
Shim IPCP
TCP/UDP
Shim IPCP
for HV
Shim IPCP
over 802.1Q
Application
zoom in
zoom in
zoom in
Normal IPC Process
(Data Transfer/Control) Error and Flow Control Protocol
Relaying and Multiplexing Task
SDU Protection
SDK support
RTT
policy
Txctrl
policy
ECN
policy
. . .
SDK support
Forwar
policy
Schedu
policy
MaxQ
policy
Monit
policy
SDK support
TTL
policy
CRC
policy
Encryp
policy
Normal IPC Process
(Layer Management)
RIB & RIB
Daemon
librina
Resource
allocation
Flow allocation
Enrollment
Namespace
Management
Security
Management
Routing
SDK support
Auth.
policy
Acc.ctrl
policy
Coord
policy
SDK support
Address
assign
Directory
replica
Address
validat
SDK support
New flow
policy
SDK support
PFTgen
policy
Pushbak
notify
SDK support
Enroll.
sequenc
e
SDK support
Routing
policyIPC Manager
RIB & RIB
Daemon
librina
Manageme
nt agent
(NMS DAF)
IPCM logic
Network Manager
(NMS DAF)
#ict-pristine

12. Implementation status (I)
IPCP components
IRATI objectives, outcomes and lessons learned 12
IPCP component SDK Available policies / comments
CACEP Y No authentication, password-based, cryptographic (RSA keys)
SDU Protection N
On/off hardcoded default policies, no SDK support yet: CRC32
(Error Check), hopcount (TTL enforcement), AES encryption
CDAP N Google Protocol Buffers (GPB) encoding, no support for filter op
Enrollment Y Default enrollment policy based on enrollment spec
Flow Allocation Y Simple QoS-cube selection policy (just reliable or unreliable)
Namespace Mgr. Y Static addressing, fully replicated Directory Forwarding Table
Routing Y Link-state routing policy based on IS-IS
Res. Allocator Y PDU Fwding table generator policy with input from routing
EFCP Y Retx. Control policies, window-based flow control, ECN receiver
RMT Y
Multiplexing: simple FIFO, cherish/urgency. Forwarding: longest
match on dest. address, multi-path forwarding, LFA. ECN marking

13. Open source IRATI
13
• IRATI github side
• http://irati.github.io/stack
• Hosts code, docs, issues
• Installation guide
• Experimenters (tutorials)
• Developers (software arch)
• Mailing list for users and
developers
• irati@freelists.org
• Procedures to contribute under
discussion, doc ongoing
#ict-pristine

14. RINASIM: RINA SIMULATOR
14
3

15. RINASim
● RINASim is independent framework implemented for OMNeT++
● Source code is publicly available on github
(https://github.com/kvetak/RINA)
● Easy issue submitting
● Fast integration of partners contribution
● Documentation is automatically generated using Doxygen
● Partners contribute via dedicated branch (fork/merge
procedure)
● New release ~every month
● Available also as an virtual-machine OVF appliance for VmWare
or VirtualBox
15#ict-pristine

16. RINA Simulator Model
Main building blocks
@ictpristine 16
Main RINA Simulator model (systems and physical links)
Border
Router
Interior Router Hosts
● 1 N-level IPC
Process
● X > 2 N-1
level IPC
Processes
● 1 N-level IPC
Process
● X >= 2 N-1
level IPC
Processes
● X >= 1 N-2
level IPC
Processes
● A flexible number of
IPCPs, but not for
relaying
● X >= 1 Application
Processes
● 1 DIF Allocator
#ict-pristine

17. SOME ONGOING WORK AND
RESULTS
17
4

18. Simplifying VM Networking with RINA
21
• No need to perform TCP/UDP checksumming since shared memory
communication is protected from corruption
– Checksumming is not actually performed by modern paravirtualized NICs
(e.g. virtio-net, xen-netfront)
• No need to implement
complex and expensive
NIC emulation.
• No need to generate
and assign MAC
addresses,
• No need to create and
configure software L2
bridges to connect VMs
and hypervisor physical
NICs together.
• Users of the shim DIF are
not restricted to the
Ethernet MTU
(1500/9000 bytes)
– Commonly bypassed
using the TCP
Segmentation
Offloading (TSO).
#ict-pristine

19. Experimental results (prototype)
IRATI objectives, outcomes and lessons learned 22Experimental scenario
Host to VM communication
VM to VM communication

20. Congestion control (I)
• In RINA CC is a generalization of how it is done in the Internet
• Benefits:
– “Naturally” gaining from properties of various previous improvements in
the Internet, without inheriting their problems (PEPs), flow aggregation
– Customization of CC policies to each layer needs (not one size fits all)
– With explicit detection, congestion effects can be confined to a single layer
(faster and more local response to congestion)
23
… 2-DIF
1-DIF
…
Some
DIFs
RM
T
RA
EFC
P
Some
DIFs
N-DIF
Sender Receiver
RM
T
RA
RM
T
RA
EFC
P
RM
T
RA
EFC
P
RM
T
RA
RM
T
RA
EFC
P
RM
T
RA
EFC
P
R
M
T
RA
EFC
P……
#ict-pristine

21. Congestion control (II): simulations
• Horizontal: consecutive DIFs
• Vertical: stacked DIFs
24
S
1
R
1
Router
1
TCP
Contro
l
Loop
Split-
TCP
Control
Loops
S1
Sn
R1
Rn
Router1 Router2
…
…
n = 5, 10, 15 n = 1
#ict-pristine

22. • TCP (iperf) vs. RINA with two different cc policy sets deployed in the red
DIF. 4 flows, Throughput vs. Experiment time
Congestion control (III): prototype
#ict-pristine
TCP
RINA with RED PS
RINA with Jain PS
Experiment setup

23. Security overview: placement of security
functions in RINA
26
Allocating a flow to
destination application
Access control
Sending/receiving SDUs
through N-1 DIF
Confidentiality, integrity
N DIF
N-1 DIF
IPC
Process
IPC
Process
IPC
Process
IPC
Process Joining a DIF
authentication, access
control
Sending/receiving SDUs
through N-1 DIF
Confidentiality, integrity
Allocating a flow to
destination application
Access control
IPC
Process
Appl.
Process
DIF Operation
Logging/Auditing
DIF Operation
Logging/Auditing
• IPC Process components involved in security
• CACEP: Authentication policies
• Security Coordination: Credential Management, Access Control
Decisions (allow new IPC Processes in the DIF, accept flows to
applications), Intrusion Detection/Prevention?, other?
• SDU Protection: Confidentiality mechanisms (encryption)
• RIB Daemon: Logging of operations in the DIF
#ict-pristine

24. Security: DIFs are securable containers
• Different security policies depending on who can join the DIF and trust on
N-1 DIFs
• Recursion provides isolation: internal provider layers are not visible to other
customer or provider networks (unless the provider’s systems are physically
compromised)
IRATI objectives, outcomes and lessons learned 27
Interior
Router
Customer
Border
Router
Interior
Router Border
Router
P2P DIF
Interior
Router
P2P DIF
Border
Router
P2P DIF P2P DIF
Interior
Router
Border
Router
Provider 1 Backbone DIF
P2P DIF
Border
Router
Provider 1 Regional DIF
Multi-provider DIF
P2P DIF
Access DIF
P2P DIFP2P DIF
Customer network Provider 1 network Provider 2 network
IPCP
A
IPCP
B
IPCP
C
P2P DIF P2P DIF
IPCP
D

25. Example: AuthPassword policy
(implemented in prototype)
28
IPCP
A
IPCP
B
Target of application
connection
Initiator of application
connection
1
M_CONNECT
AuthPolicy.name = PSOC_authentication-
password
AuthPolicy.version = 1
AuthPolicy.options = cipher
2
Generate random
challenge string
CHALLENGE REQUEST
random challenge string
3
XOR challenge string
with password, hash
result and return reply
CHALLENGE REPLY
XORed result
4
XOR random
challenge with
password, hash and
compare with
response
M_CONNECT_R
@ictpristine

26. IPCP
A
IPCP
B
Target of application
connection
Initiator of application
connection
1
M_CONNECT
AuthPolicy.name = PSOC_authentication-ssh2
AuthPolicy.version = 1
AuthPolicy.options = <proposed algorithms, DH
pubKey>
2
Select algorithms. Generate key
pair for DH. Combine with peer’s
pubKey to generate shared
secret. Hash to generate
encryption keys.
Enable decryption. Send
message. Enable encryption
DH Exchange
DH pubKey, selected algorithms
3
Select algorithms.
Combine peer’s
pubKey with DH key
pair to generate
shared secret. Hash
to generate
encryption key,
enable encryption
and decryption.
Client Challenge
Client random challenge encrypted with RSA pub key
4
<Now communication is encrypted>
Client Challenge response and Server Challenge
Hashed, decrypted client random challenge
Server random challenge encrypted with RSA public key
Generate key pair
for DH. Load RSA
key pair for
authentication.
Generate random
challenge. Encrypt with
RSA public key
Generate random
challenge. Encrypt with
RSA public key
Decrypt challenge with RSA
private key. XOR with shared
secret and hash.
5
Server Challenge Response
Hashed, decrypted server random challenge
Decrypt server
challenge with RSA
private key. XOR with
shared secret and hash.
Combine client
challenge with shared
secrete and hash.
Compare with received
value
Combine server challenge with
shared secrete and hash.
Compare with received value
6
M_CONNECT_R
Example: AuthSSH2 policy (implemented in prototype)

27. FINAL REMARKS
30
5

28. Final remarks
• Progress on improvement of core protocols (EFCP, CDAP). Started
working on policy specifications for authentication, access
control, SDU Protection, routing, congestion control and resource
allocation.
• Prototype (programmable via SDK) and Simulator maturing as
they are used in experiments. Getting ready to become usable to
newcomers (experiment tutorials under development).
• Started quantifying RINA benefits on particular areas and specific
scenarios/use cases (more to come during the following year).
Current focus is congestion control, resource allocation, routing,
security and network management.
• Started working with SDOs to educate them on RINA and consider
possible standardisation activities (ISO, ETSI). 5G and IoT are areas
of potential interest.
31
1
2
3
4
#ict-pristine

29. Further information can be found here.
Twitter @ictpristine
www www.ict-pristine.eu
<Thank you!>