1. RINA: Update on Research and
Prototyping Activities
Global Future Internet Summit
September 14th
, 2012
Eduard Grasa
Research Manager @ DANA
Fundació i2CAT

2. Before we start… our perspective
 What is the “Future Internet”?
 We don’t know, we’re just interested in building better computer networks
and finding out the correct ways of doing so.
 Is RINA “clean slate”?
 We’re retaking the direction of computer network research in the mid-70s,
continuing where INWG left off, and learning from the success and mistakes
of 40+ years of computer networking. If we were starting with “no
assumptions” we would not be learning from the past (“Those who don’t know
history are destined to repeat it”)
 What are the design goals of RINA?
 No design goals, we just look at solving the problem of computer networking
and try to maximize the invariances and minimize the discontinuities. All the
results and insights have emerged from listening to the problem.
 Do you have all the answers?
 No way! We’re just beginning to explore the properties of a new paradigm*
that simplifies computer networking by orders of magnitude. Do you want to
join us?
2* Not so new to be honest, initial computer network research (CYCLADES, INWG) was headed in this

3. Outline
 Quick Introduction to RINA
 Java prototype over IP
 Inter DIF Directory
 RINA Security Assessment
 FP7 IRATI Project: Kernel prototype over
Ethernet
3

4. RINA Architecture
4
• A structure of recursive layers
that provide IPC (Inter
Process Communication)
services to applications on
top
• There’s a single type of layer
that repeats as many times
as required by the network
designer
• Separation of mechanism
from policy
• All layers have the same functions, with different scope and range.
– Not all instances of layers may need all functions, but don’t need more.
• A Layer is a Distributed Application that performs and manages IPC.
– A Distributed IPC Facility (DIF)
• This yields a theory and an architecture that scales indefinitely,
– i.e. any bounds imposed are not a property of the architecture itself.
© John Day, All Rights Reserved, 2011

5. Naming and addressing in RINA
 All application processes
(including IPC processes) have a
name that uniquely identifies
them within the application
process namespace.
 In order to facilitate its operation
within a DIF, each IPC process
within a DIF gets a synonym that
may have be structured to
facilitate its use within the DIF
(i.e. an address).
5
 The scope of an address is the DIF, addresses are not visible outside of the DIF.
 The Flow Allocator function of the DIF finds the DIF IPC Process through which a
destination Application process can be accessed.
 Because the architecture is recursive, applications, nodes and PoAs are relative
 For a given DIF of rank N, the IPC Process is a node, the process at the layer N+1
is an application and the process at the layer N-1 is a Point of Attachment.
1 2 3 4
1 2 1 2 3 1 2
1 21 2
DIF A
DIF B
DIF C
DIF D
DIF E DIF F

6. RINA vs. the current Internet
 Architecture:
 Current: 5/7? layers, layers “2.5”, layer violations, “overlays”, “virtual networks”,
“middleboxes” (NATs, firewalls, application-layer gateways) Getting complex!
Unforeseen interactions
 RINA: Repeating structure, DIF (one type of layer, repeat as needed)
 Naming, addressing and routing:
 Current: No independent application names, no node names, just PoA names,
routing on PoAs (no wonder why multi-homing and mobility is hard to support)
 RINA: Complete naming & addressing, routing on the node; support for multi-
homing and mobility without special protocols. No need for global address
space.
 Congestion control:
 Current: Put in TCP, the worst place it could be, since it maximizes the delay and
variance of the control loop (makes the system chaotic: self-similar traffic)
 RINA: Each layer can perform congestion control, confining the effects of
congestion to that layer. The delay and variance of control loops can be
bound. 6

7. RINA vs. the current Internet
 Scalability:
 Current: Limited due to the fixed number of layers in the architecture
 RINA: Recursion provides a divide and conquer approach, the way to scalability
 Security:
 Current: No systematic approach to security, secure each protocol or add boxes in
between to improve security (firewalls).
 RINA: Strong design tells you where security functions go in the architecture (see
later in the presentation). DIFs are securable containers.
 Quality of Service:
 Current: Best effort is the dogma, “network neutrality”
 RINA: Each DIF is free to provide the QoS classes it wants, using different policies for
resource allocation, routing and data transfer
 Management:
 Current: Complex, reflecting the complexity in the architecture and the high
number of protocols.
 RINA: The commonality in the structure simplifies management by orders of
magnitude, 7

8. Outline
 Quick Introduction to RINA
 Java prototype over IP
 Inter DIF Directory
 RINA Security Assessment
 FP7 IRATI Project: Kernel prototype over
Ethernet
8

9. RINA Adoption strategy
 Start as an overlay to IP, validate technology, work on initial
concepts, develop DIF machinery.
 Useful by itself: internetwork layer(s), decouple application from infrastructure,
improved application API, support for multi-homing and mobility.
9
IP
Ethernet
Physical Media
Applications
Today
TCP or UDP
IP
Ethernet
Physical Media
Applications
Current Prototype
TCP or UDP
DIF
DIF
…
Ethernet
Physical Media
Applications
DIF
DIF
…
IP
Physical Media
Applications
TCP or UDP
DIF
DIF
…
Physical Media
Applications
DIF
DIF
…
End goal

10. RINA over IP benefits: Internetwork
layer(s)
 What if application A wants to communicate with Application C?
 It cannot do it, unless you start deploying middleboxes like NATs, application-layer gateways,
… The architecture doesn’t accommodate internetworking!
10
Data Link Data Link Data Link Data Link Data Link
IP
IP Layer A (Public Internet)
IP
IP Layer B (Enterprise
Network)
TCP
Appl. A Appl. B
Data Link Data Link Data Link Data Link Data Link
IP
IP Layer A (Public Internet)
IP
IP Layer B (Enterprise
Network)
Shim DIF
Appl. A Appl. B Appl. C
Shim DIF
DIF
TCP
Appl. C

11. RINA over IP benefits: Separate
applications from infrastructure
 There is no separate application namespace, but synonyms that
stand for an IP address and a TCP/UDP port number:
 A path to an application.
 This makes anything but client/server hard to achieve, e.g. mobility
 In RINA application names are independent of the layers below
(DIFs)
 Application names can be structured in a way that makes sense for
the application
 The application name doesn’t contain the semantics of where the
application is in the network (i.e. what is its point of attachment to the
layer below) 11
 http://pouzinsociety.org
Synonym of an
interface of a host
Port (Endpoint of TCP
connection)
:80

12. RINA over IP benefits: Next
generation VPN
 DIFs are customizable VPNs that can span multiple IP layers.
 Each DIF has its own addressing scheme, security mechanisms (authentication,
authorization), routing strategy, resource allocation strategy (support for
different levels of QoS), flow control strategy, data transfer/data transfer
control, …
 Processes (and not systems) are members of the DIFs (different processes can
access different DIFs in each system). Processes may not have access to the
whole range of DIFs available on their system
 DIFs open the door to VPNs optimized for certain applications
12
Data Link Data Link Data Link Data Link Data Link
IP
IP Layer A (Public Internet)
IP
IP Layer B (Enterprise
Network)
Shim DIF
Appl. A Appl. B Appl. C
Shim DIF
DIF

13. Architectural model
DIF
System (Host)
IPC
Process
IPC
Process
Mgmt
Agemt
System
(Router)
IPC
Process
IPC
Process
IPC
Process
Mgmt
Agemt
System
(Host)
IPC
Process
IPC
Process
Mgmt
Agemt
Appl.
Process
DIF DIF
Appl.
Process
IPC API
Data Transfer Data Transfer Control Layer Management
SDU Delimiting
Data Transfer
Relaying and
Multiplexing
SDU Protection
Transmission
Control
Retransmission
Control
Flow Control
RIB
Daemon
RIBRIB CDAP
Parser/Generator
CACEP Enrollment
Flow Allocation
Resource
Allocation
Forwarding Table
Generator
Authentication
StateVector
StateVectorStateVector
Data TransferData Transfer
Transmission
Control
Transmission
Control
Retransmission
Control
Retransmission
Control
Flow Control
Flow Control
13
IPC
Resource
Mgt.
Inter DIF
Directory
SDU
Protec
tion
Multipl
exing
IPC Mgt. Tasks
Other Mgt. Tasks
Application Specific
Tasks
Increasing timescale (functions performed less often) and complexity

14. The Shim DIF
14
Public Internet Private IP
network
“Shim IPC
Process”
“Shim IPC
Process”
IPC
Process
“Shim IPC
Process”
IPC
Process
IPC
Process
“Shim IPC
Process”
Shim DIFShim DIF
DIF
Appl.
Process
Appl.
Process
UDP flow UDP flow
TCP
flow(s)
TCP
flow(s)
 The “shim IPC Process” for IP layers is not a “real IPC Process”. It just
presents an IP layer as if it was a regular DIF.
 Wraps the IP layer with the DIF interface.
 Maps the names of the IPC Processes of the layer above to IP addresses in the
IP layer.
 Creates TCP and/or UDP flows based on the QoS requested by an “allocate
request”.

15. Implementation platform
 Implemented as part of the TINOS framework (a network
protocol experimentation framework)
 https://github.com/PouzinSociety/tinos
 Implemented in Java, using the OSGi technology (OSGi
container provided by Eclipse Virgo)
 OSGi is a component model that facilitates building modular Java
applications
 Developed on Mac OS X and Linux Debian, but should be multi-
platform (support all the platforms that Eclipse Virgo supports)
 Found some OS resource allocation issues with Mac OS X
 Not yet fully integrated with TINOS (once it is, it will be possible to
instantiate several “systems” within a single Java process, using
XMPP as the underlying “physical substrate”)
15

16. Java Virtual Machine
Why using TINOS instead of raw Java?
To facilitate experimentation: bigger scenarios without adding more hardware
IP (Jnode)
Data Link Data Link Data Link
Shim DIF
Data Link Data Link
IP (Jnode)
Shim DIF
DIF
Java Virtual Machine
IP (Jnode)
Data Link Data Link Data Link
Shim DIF
Data Link Data Link
IP (Jnode)
Shim DIF
DIF
Java Virtual Machine
Data Link
IP (OS stack)
Shim DIF
Java Virtual
Machine
Data Link
IP (JNode)
Shim DIF
Public
Internet
Data
Link
IP
(O
Sstack)
Shim
DIF
DIF
XMPP network
LAN
 With TINOS multiple nodes can be created within
the same Java JVM, with different network
connectivity with each other and other JVMs
(TINOS uses adapted IP stack from JNode and
XMPP for this)

17. Current status & some conclusions
 Since all the layers have the same mechanisms with different policies,
implementation becomes much simpler than today’s protocol
suite(therefore more effort can be devoted to making it more robust and
efficient)
 Also no need to distinguish between ‘physical’ or ‘virtual’ networking protocols: it’s all IPC.
 Customization & innovation in networking becomes much easier
 Just focus on the area you’re interested in and change the relevant policies for yours (NOTE:
Today “changing the policies” in the prototype means modifying the code, since
developing a pluggable policy framework is out of the scope of the initial prototype)
 Interoperability with existing networking technologies is not an issue
 Just wrap the XX layer as a shim DIF, and there you go 17
IPC API
Data Transfer Data Transfer Control Layer Management
SDU Delimiting
Data Transfer
Relaying and
Multiplexing
SDU Protection
Transmission
Control
Retransmission
Control
Flow Control
RIB
Daemon
RIBRIB CDAP
Parser/Generator
CACE Enrollment
Flow Allocation
Resource
Allocation
Forwarding Table
Generator
AuthenticationStateVector
StateVectorStateVector
Data TransferData Transfer
Transmission
Control
Transmission
Control
Retransmission
Control
Retransmission
Control
Flow Control
Flow Control

18. Outline
 Quick Introduction to RINA
 Java prototype over IP
 Inter DIF Directory
 RINA Security Assessment
 FP7 IRATI Project: Kernel prototype over
Ethernet
18

19. What’s a layer?
 Although the term “layer” has been extensively used in
networking, the concept itself has not been clearly defined.
 In its origin layers were adopted from its use in operating systems.
But in operating systems, using layers is a choice, whereas using
layers in networks is a necessity because of the distributed
shared state of different scopes
 The necessary and sufficient condition for a layer is distributed
shared state of different scope.
 Therefore we can describe a layer as the collection of
application processes that share state.
Physical
Data Link
Network
Transport
Application
Host or End System
Router
Less
Scope
More
Scope
19

20. Application discovery involves also layer
discovery
host H2
router R2 router R3
host H1
Layer 1
web server
application
B
web
browser
application
A
router R4
router R1
host H4
Layer 3
Layer 2
Layer 4
Layer 6
Layer 5
router R5
host H3
web server
application
C
20

21. The InterDIF Directory (IDD)
 A distributed application, Distributed Application Facility (DAF) as
it’s called in RINA, which is a collection of two or more
cooperating application processes in one or more processing
systems, which exchange information using IPC and maintain
shared state
 The IDD DAF maintains a distributed database that keeps
mappings of application names to list of supporting layers
 The IDD is responsible for two main distinct functions:
a) Discovery of the application
b) Creation of the supporting DIF
21

22. A) Discovery of the application (I)
 IDD-Request
 Destination IDD Name, Source IDD Name, Requested Application
Process Name, Access Control Information, Quality of Service,
Termination Condition
 Forwarding of the request between the peer IDDs until the
destination application is found or the pre-defined termination
condition is met
host H2
router R2 router R3
host H1
web server
application
B
web
browser
application
A
router R4
router R1
host H4
Layer 6
router R5
host H3
...
Layer 1
Layer 3
Layer 2
Layer 4Layer 5
IDD DAF
web server
application
C
22

23. A) Discovery of the application (II)
 Confirmation that the requested application is executing in
the destination system and authorization check that the
requesting application has the rights to access it
host H2
router R2 router R3
host H1
web server
application
B
web
browser
application
A
router R4
router R1
host H4
Layer 6
router R5
host H3
...
Layer 1
Layer 3
Layer 2
Layer 4Layer 5
IDD DAF
web server
application
C
23

24. B) Creation of the supporting DIF
 A DIF supporting the communication between the two user
applications has to be found
 This either involves creating a new DIF from scratch or
expanding (joining) an existing one so that it spans from the
source to the destination system
host H2
router R2 router R3
host H1
web server
application
B
web
browser
application
A
router R4
router R1
host H4
Layer 6
router R5
host H3
...
Layer 1
Layer 3
Layer 2
Layer 4Layer 5
IDD DAF
web server
application
C
24

25. Current status
 Ph.D. thesis ongoing
 Defined the IDD Framework. Current research is focused in
application discovery; looking at different policies to perform
the IDD search, the replication of the directory information,
and compare them in terms of:
 Time to discover the requested application
 Average number of messages generated on the IDD DAF per search
 Average number of hops needed to locate the destination application
 Time to distribute directory updates, and average number of messages
generated by directory update
 Java simulator of the IDD is being implemented. After results
have been tested in the simulator, the IDD framework and
some selected policies will be ported to the prototypes
25

26. Outline
 Quick Introduction to RINA
 Java prototype over IP
 Inter DIF Directory
 RINA Security Assessment
 FP7 IRATI Project: Kernel prototype over
Ethernet
26

27.  Benefits of having an architecture instead of a protocol suite: the
architecture tells you where security related functions are placed.
 Instead of thinking protocol security, think security of the architecture: no
more ‘each protocol has its own security’, ‘add another protocol for
security’ or ‘add another box that does security’
Allocating a flow to
destination application
Access control
Sending/receiving PDUs
through N-1 DIF
Confidentiality, integrity
Placement of security related functions
27
N DIF
N-1 DIF
IPC
Process
IPC
Process
IPC
Process
IPC
Process Joining a DIF
authentication,
access control
Sending/receiving PDUs
through N-1 DIF
Confidentiality, integrity
Allocating a flow to
destination application
Access control
IPC
Process
Appl.
Process
Access control
(DIF members)
Confidentiality, integrity
Authentication
Access control
(Flow allocations to apps)
DIF Operation
Logging
DIF Operation
Logging

28. DIFs are securable containers
 Master thesis on RINA security assessment (results to be
published)
 Possible attacks to a DIF
 Information required to perform these attacks
 Mitigation measures against these attacks
 Comparison to the current Internet
 Concludes that DIFs are securable containers if proper
standard security tools are used (authentication, access
control, confidentiality, integrity and strong auditing)
 Securable = A structure used to hold or transport something that can be
made to be not subject to threat
 Again, with a proper structure in place, achieving better
security in networks is much simpler and cost-effective than
in the current situation
28

29. Outline
 Quick Introduction to RINA
 Java prototype over IP
 Inter DIF Directory
 RINA Security Assessment
 FP7 IRATI Project: Kernel prototype over
Ethernet
29

30.  What? Main goal
 To advance the state of the art of RINA towards an architecture reference model and
specifications that are closer to enable implementations deployable in production
scenarios. The design and implementation of a RINA prototype on top of Ethernet will
enable the experimentation and evaluation of RINA in comparison to TCP/IP.
 Who? 4 partners
 How? Requested 870.000 € funding to the EC to perform 5 activities
 WP1: Project management
 WP2: Architecture, Use cases and Requirements
 WP3: Software Design and Implementation
 WP4: Deployment into OFELIA testbed, Experimentation and Validation
 WP5: Dissemination, Standardisation and Exploitation
Project at a glance
Nextworks
Interoute
i2CAT
IBBT

31. Thanks for your attention!
You can contact me at
eduard.grasa@i2cat.net
More information about RINA at http://rina.tssg.org,
http://pouzinsociety.org, http://csr.bu.edu/rina
More information about the prototype at
https://github.com/PouzinSociety/tinos/wiki/RINA-Prototype
More information about IRATI at
http://irati.eu