1. Large scale RINA Experimentation on FIRE +
Use cases, results, benefits
RINA Workshop @ Telefonica
Eduard Grasa, Fundació i2CAT

2. STRUCTURE: LAYERING
2

3. RINA macro-structure (layers)
Single type of layer, consistent API, programmable policies
Host
Border router Interior Router
DIF
DIF DIF
Border router
DIF
DIF
DIF (Distributed IPC Facility)
Host
App
A
App
B
Consistent API
through layers
• Layers (DIFs) are distributed applications that provide IPC services to higher layers (which
may be DIFs or other forms of distributed applications)
• Layers are resource allocators: they manage the layer resources (memory in buffers,
scheduling capacity, bandwidth) and provide them to competing flows.
3

4. • RINA recursive layering structure cleans up and generalizes the current
protocol stack.
• Example 1: PBB-VPLS (Virtual Private LAN Service)
– Uses MAC-in-MAC encapsulation to isolate provider’s core from customers addresses and VLANs
Recursive, generic layer structure (I)
(see ARCFIRE deliverable D2.2 for detailed examples http://ict-arcfire.eu)
4

5. Recursive, generic layer structure (I)
(see ARCFIRE deliverable D2.2 for detailed examples http://ict-arcfire.eu)
• RINA recursive layering structure cleans up and generalizes the current
protocol stack.
• Example 1: PBB-VPLS (Virtual Private LAN Service)
– Uses MAC-in-MAC encapsulation to isolate provider’s core from customers addresses and VLANs
PtP DIF PtP DIF PtP DIF PtP DIF
PtP DIFPtP DIFPtP DIFPtP DIF PtP DIF PtP DIF PtP DIF
5

6. • RINA recursive layering structure cleans up and generalizes the current
protocol stack.
• Example 1: PBB-VPLS (Virtual Private LAN Service)
– Uses MAC-in-MAC encapsulation to isolate provider’s core from customers addresses and VLANs
Metro DIF Metro DIF
PtP DIF PtP DIF PtP DIF PtP DIF
PtP DIFPtP DIFPtP DIFPtP DIF PtP DIF PtP DIF PtP DIF
Recursive, generic layer structure (I)
(see ARCFIRE deliverable D2.2 for detailed examples http://ict-arcfire.eu)
6

7. • RINA recursive layering structure cleans up and generalizes the current
protocol stack.
• Example 1: PBB-VPLS (Virtual Private LAN Service)
– Uses MAC-in-MAC encapsulation to isolate provider’s core from customers addresses and VLANs
Metro DIF Metro DIFCore DIF
PtP DIF PtP DIF PtP DIF PtP DIF
PtP DIFPtP DIFPtP DIFPtP DIF PtP DIF PtP DIF PtP DIF
Recursive, generic layer structure (I)
(see ARCFIRE deliverable D2.2 for detailed examples http://ict-arcfire.eu)
7

8. • RINA recursive layering structure cleans up and generalizes the current
protocol stack.
• Example 1: PBB-VPLS (Virtual Private LAN Service)
– Uses MAC-in-MAC encapsulation to isolate provider’s core from customers addresses and VLANs
Provider VPN Service DIF
Metro DIF Metro DIFCore DIF
PtP DIF PtP DIF PtP DIF PtP DIF
PtP DIFPtP DIFPtP DIFPtP DIF PtP DIF PtP DIF PtP DIF
Recursive, generic layer structure (I)
(see ARCFIRE deliverable D2.2 for detailed examples http://ict-arcfire.eu)
8

9. • RINA recursive layering structure cleans up and generalizes the current
protocol stack.
• Example 1: PBB-VPLS (Virtual Private LAN Service)
– Uses MAC-in-MAC encapsulation to isolate provider’s core from customers addresses and VLANs
Green Customer VPN DIF
Provider VPN Service DIF
Metro DIF Metro DIFCore DIF
PtP DIF PtP DIF PtP DIF PtP DIF
PtP DIFPtP DIFPtP DIFPtP DIF PtP DIF PtP DIF PtP DIF
Recursive, generic layer structure (I)
(see ARCFIRE deliverable D2.2 for detailed examples http://ict-arcfire.eu)
9

10. • Example 2: LTE (Long Term Evolution)
– Uses PDCP, GTP to transport user’s IP payload, and also relies on internal IP network.
IP (e.g. Internet)
TCP or UDP
PDCP GTP-U GTP-U
RLC
MAC
L1
UDP
IP (LTE transport)
MAC MAC. . .
L1 . . . L1
UDP
IP (LTE transport)
MAC MAC. . .
L1 . . . L1UE
eNodeB S-GW P-GW
EPS bearerEPS bearer
LTE-Uu
S1-U S5/S8
MAC
L1
SGi
Recursive, generic layer structure (II)
(see ARCFIRE deliverable D2.2 for detailed examples http://ict-arcfire.eu)
10
Bridging

11. • Example 2: LTE (Long Term Evolution)
– Uses PDCP, GTP to transport user’s IP payload, and also relies on internal IP network.
IP (e.g. Internet)
TCP or UDP
PDCP GTP-U
Bridging
GTP-U
RLC
MAC
L1
UDP
IP (LTE transport)
MAC MAC. . .
L1 . . . L1
UDP
IP (LTE transport)
MAC MAC. . .
L1 . . . L1UE
eNodeB S-GW P-GW
EPS bearerEPS bearer
LTE-Uu
S1-U S5/S8
MAC
L1
SGi
PtP DIF PtP DIF PtP DIF PtP DIF
PtP DIF
Recursive, generic layer structure (II)
(see ARCFIRE deliverable D2.2 for detailed examples http://ict-arcfire.eu)
11

12. • Example 2: LTE (Long Term Evolution)
– Uses PDCP, GTP to transport user’s IP payload, and also relies on internal IP network.
IP (e.g. Internet)
TCP or UDP
PDCP GTP-U GTP-U
RLC
MAC
L1
UDP
IP (LTE transport)
MAC MAC. . .
L1 . . . L1
UDP
IP (LTE transport)
MAC MAC. . .
L1 . . . L1UE
eNodeB S-GW P-GW
EPS bearerEPS bearer
LTE-Uu
S1-U S5/S8
MAC
L1
SGi
Mobile Operator Transport
DIF
Mobile Operator Transport
DIF
PtP DIF PtP DIF PtP DIF PtP DIF
PtP DIF
Recursive, generic layer structure (II)
(see ARCFIRE deliverable D2.2 for detailed examples http://ict-arcfire.eu)
12
Bridging

13. • Example 2: LTE (Long Term Evolution)
– Uses PDCP, GTP to transport user’s IP payload, and also relies on internal IP network.
IP (e.g. Internet)
TCP or UDP
PDCP GTP-U GTP-U
RLC
MAC
L1
UDP
IP (LTE transport)
MAC MAC. . .
L1 . . . L1
UDP
IP (LTE transport)
MAC MAC. . .
L1 . . . L1UE
eNodeB S-GW P-GW
EPS bearerEPS bearer
LTE-Uu
S1-U S5/S8
MAC
L1
SGi
Multi-access radio DIF
Mobile Operator Transport
DIF
Mobile Operator Transport
DIF
PtP DIF PtP DIF PtP DIF PtP DIF
PtP DIF
Recursive, generic layer structure (II)
(see ARCFIRE deliverable D2.2 for detailed examples http://ict-arcfire.eu)
13
Bridging

14. • Example 2: LTE (Long Term Evolution)
– Uses PDCP, GTP to transport user’s IP payload, and also relies on internal IP network.
IP (e.g. Internet)
TCP or UDP
PDCP GTP-U GTP-U
RLC
MAC
L1
UDP
IP (LTE transport)
MAC MAC. . .
L1 . . . L1
UDP
IP (LTE transport)
MAC MAC. . .
L1 . . . L1UE
eNodeB S-GW P-GW
EPS bearerEPS bearer
LTE-Uu
S1-U S5/S8
MAC
L1
SGi
Mobile Access Network Top Level DIF
Multi-access radio DIF
Mobile Operator Transport
DIF
Mobile Operator Transport
DIF
PtP DIF PtP DIF PtP DIF PtP DIF
PtP DIF
Recursive, generic layer structure (II)
(see ARCFIRE deliverable D2.2 for detailed examples http://ict-arcfire.eu)
14
Bridging

15. • Example 2: LTE (Long Term Evolution)
– Uses PDCP, GTP to transport user’s IP payload, and also relies on internal IP network.
IP (e.g. Internet)
TCP or UDP
PDCP GTP-U GTP-U
RLC
MAC
L1
UDP
IP (LTE transport)
MAC MAC. . .
L1 . . . L1
UDP
IP (LTE transport)
MAC MAC. . .
L1 . . . L1UE
eNodeB S-GW P-GW
EPS bearerEPS bearer
LTE-Uu
S1-U S5/S8
MAC
L1
SGi
Public Internet DIF (or user VPN DIF, or app-specific DIF, …)
Mobile Access Network Top Level DIF
Multi-access radio DIF
Mobile Operator Transport
DIF
Mobile Operator Transport
DIF
PtP DIF PtP DIF PtP DIF PtP DIF
PtP DIF
Recursive, generic layer structure (II)
(see ARCFIRE deliverable D2.2 for detailed examples http://ict-arcfire.eu)
15
Bridging

16. • Example 3: Data Center Network with NVO3
– Network Virtualization Over Layer 3, uses overlay virtual networks on top of the DCN’s fabric layer 3 to
support multi-tenancy
• Recursion provides a cleaner, simpler solution than virtualization
– Repeat the same building block, with the same interface.
ToR ToRFabric Spine Fabric
Server ServerIPv4 or IPv6 (Fabric layer)
UDPVM VM
Ethernet Ethernet Ethernet Ethernet
VXLAN802.1Q802.3 802.1Q
IPv4 or IPv6 (tenant overlay)
TCP or UDP or SCTP, … (transport layer)
802.3
bridging
Recursive, generic layer structure (III)
(see ARCFIRE deliverable D2.2 for detailed examples http://ict-arcfire.eu)
16

17. • Example 3: Data Center Network with NVO3
– Network Virtualization Over Layer 3, uses overlay virtual networks on top of the DCN’s fabric layer 3 to
support multi-tenancy
• Recursion provides a cleaner, simpler solution than virtualization
– Repeat the same building block, with the same interface.
ToR ToRFabric Spine Fabric
Server ServerIPv4 or IPv6 (Fabric layer)
UDPVM VM
Ethernet Ethernet Ethernet Ethernet
VXLAN802.1Q802.3 802.1Q
IPv4 or IPv6 (tenant overlay)
TCP or UDP or SCTP, … (transport layer)
802.3
bridging
PtP DIF PtP DIF PtP DIF PtP DIF
PtP DIF PtP DIFPtP DIFPtP DIF
Recursive, generic layer structure (III)
(see ARCFIRE deliverable D2.2 for detailed examples http://ict-arcfire.eu)
17

18. • Example 3: Data Center Network with NVO3
– Network Virtualization Over Layer 3, uses overlay virtual networks on top of the DCN’s fabric layer 3 to
support multi-tenancy
• Recursion provides a cleaner, simpler solution than virtualization
– Repeat the same building block, with the same interface.
ToR ToRFabric Spine Fabric
Server ServerIPv4 or IPv6 (Fabric layer)
UDPVM VM
Ethernet Ethernet Ethernet Ethernet
VXLAN802.1Q802.3 802.1Q
IPv4 or IPv6 (tenant overlay)
TCP or UDP or SCTP, … (transport layer)
802.3
bridging
PtP DIF PtP DIF PtP DIF PtP DIF
PtP DIF PtP DIFPtP DIFPtP DIF
DC Fabric DIF
Recursive, generic layer structure (III)
(see ARCFIRE deliverable D2.2 for detailed examples http://ict-arcfire.eu)
18

19. • Example 3: Data Center Network with NVO3
– Network Virtualization Over Layer 3, uses overlay virtual networks on top of the DCN’s fabric layer 3 to
support multi-tenancy
• Recursion provides a cleaner, simpler solution than virtualization
– Repeat the same building block, with the same interface.
ToR ToRFabric Spine Fabric
Server ServerIPv4 or IPv6 (Fabric layer)
UDPVM VM
Ethernet Ethernet Ethernet Ethernet
VXLAN802.1Q802.3 802.1Q
IPv4 or IPv6 (tenant overlay)
TCP or UDP or SCTP, … (transport layer)
802.3
bridging
PtP DIF PtP DIF PtP DIF PtP DIF
PtP DIF PtP DIFPtP DIFPtP DIF
DC Fabric DIF
Tenant DIF
Recursive, generic layer structure (III)
(see ARCFIRE deliverable D2.2 for detailed examples http://ict-arcfire.eu)
19

20. PROTOCOLS WITHIN A GENERIC LAYER
20

21. Separation of mechanism from policy
21
IPC API
Data Transfer Data Transfer Control Layer Management
SDU Delimiting
Data Transfer
Relaying and Multiplexing
SDU Protection
Retransmission Control
Flow Control
RIB Daemon
RIB
CDAP Parser/Generator
CACEP
Enrollment
Flow Allocation
Resource Allocation
Routing
Authentication
StateVector
StateVector
StateVector
Data TransferData Transfer
Retransmission ControlRetransmission Control
Flow Control
Flow Control
Namespace Management Security Management
• All layers have the same mechanisms and 2 protocols (EFCP for data transfer, CDAP for layer
management), programmable via policies.
– All data transfer and layer management functions are programmable!
• Don’t specify/implement protocols, only policies
– Re-use common layer structure, re-use policies across layers
• This approach greatly simplifies the network structure, minimizing the management overhead and
the cost of supporting new requirements, new physical media or new applications
EFCP

22. Error and Flow Control Protocol (EFCP)
• One of the main results discussed in Patterns in Network Architecture
(PNA), later formalised in RINA.
– PNA/RINA only proof this is possible and show a way of arriving to the result. If others
propose simpler frameworks with the same capabilities we should definitely go for them.
• By separating data transfer protocol elements between mechanism (invariant)
and policy (variant), it is possible to specify a data transfer protocol framework
from which multiple data transfer protocols can be generated by
– Choosing a concrete syntax (length of PCI fields)
– Plugging in the right policies
• See EFCP specification for an example of such protocol framework
22

23. EFCP (II)
• 1 common data transfer PDU
– Abstract syntax: (presence/absence and length of fields varies
– E.g.: point to point links -> no need for addresses
– 1 application only per IPCP -> no need for cep-ids (e.g. some IoT protocols)
• A few control PDUs (Ack, ack & flow ctrl, etc.)
• Policy plug-in points to customize for different environments and application requirements
– Flow control (window/rate-based), retransmission control, congestion control
23

24. E.g. Results on congestion control (I)
• “Congestion control in the Recursive Internetwork Architecture”
– P. Teymoori, M. Welzl, S. Gjessing, E. Grasa, R. Riggio, K. Rausch, D. Siracussa
– IEEE ICC 2016
– https://www.researchgate.net/publication/301657524_Congestion_Control_in_the_Recursive
_InterNetworking_Architecture_RINA
– “… we have shown that congestion control in RINA “naturally” exhibits properties of various
improvements that have been made to (or at least proposed for) the Internet, without
inheriting the problems that come from imposing these mechanisms on an architecture
that was not made for them … ”
24

25. Results on congestion control (II)
• RINA can solve the Internet c. c. problems by:
– Breaking up the control loop in shorter ones
– Controlling flow aggregates inside the network and
– Enabling the deployment of arbitrary controllers per DIF
• Follow up: OCARINA project (lead by U of Oslo)
25

26. DIF API
• register / unregister (app name)
– Associate applications to DIFs
• allocate_flow(dest_app_name, QoS attributes)
– Allocate a flow to a destination app name (may name a group of apps), with a certain QoS
(reliable delivery, in order delivery, bounds on delay/jitter, minimum capacity, etc.)
• read/write (port_id)
• deallocate_flow(port_id)
– Free up resources associated to the flow
26

27. Dynamic negotiation of cep-ids and policies
per flow
• Application calls “allocate”
– Provides dest. app name and flow requirements
• IPCP(source) selects EFCP policies and computes source cep-id, sends message to IPCP (dest)
• IPCP (dest) does access control check, selects EFCP policies and computes dest cep-id
• Today
– applications have to select the protocol explicitly
– static (well-known) ports as cep-ids
– No app names, addresses exposed to apps
27

28. NAMING, ADDRESSING, MOBILITY
28

29. Naming & addressing
Application names: Assigned to applications. Location independent. Uniquely identify application within an application
namespace. In general name a set (can have a single member).
Addresses: Location-dependent synonym of an App name. Facilitates locating the app within a certain context (e.g. IPCPs in
a DIF). Its scope is restricted to the DIF.
Port-ids: Identifies one end of a flow within a system (local identifier), only id shared with user.**
Connection endpoint ids (cep-ids): Identify the EFCP instances that are the endpoints of a connection.
QoS-id: Identifies the QoS cube to which the EFCP PDUs belong (PDUs belonging to the same QoS-id receive receive a
consistent treatment through the DIF).
29

30. Implications for multi-homing
G
A
B
C
E
D
F
H
1
2
6
5
8
3 14
18
17 16
15
19
21
13
20
9
11
10
12
4
7
2
2
G
A
B
C
E
D
F
H
1
2
3
1
2
1
3
4
1
2
3
1
2
3
1 2
3
1
1
2
2
2
• Addressing the node instead of the interface: 3-4x
time next-hop/forwarding table reduction!
• No need for special protocols to support multi-
homing
Addresses assigned to interfaces Addresses assigned to nodes
30

31. Flows and addresses
31

32. Multiple DIFs scenario, continuous renumbering
• Service provider scenario
– 41 nodes
– Two MAN networks
– 1 core network
– 18 CPEs
• Each CPE allocates 10 flows to
other
– 180 concurrent flows
32
Access
Router
PtP DIF
CPE
Edge
Service
Router
Metro
Edge
Router
Metro
Edge
Router
Metro BB DIF
Metro service DIF
PtP DIF PtP DIF
PtP DIF PtP DIF
Metro P
router
PTP DIF
Residential customer service DIF
Host
PtP DIF
Public Internet or App-specific or VPN DIF
Backbon
e Router
Backbon
e router
PtP DIF PtP DIF
Backbone DIF
Provider
Edge
Router
Provider
Edge
Router
PtP DIF
Customer network Service Prov. 2Service Prov. 1 network
Access Aggregation Service Edge Core Internet Edge
Public Internet or App-specific or VPN DIF
Home DIF
Customer Premises Equipment
Access Router
MAN Access Router
MAN Core Router
Edge Services Router
Backbone router

33. Results at the Virtual Wall (II)
No packet loss
0.00
1.00
2.00
3.00
4.00
5.00
6.00
7.00
8.00
1 4 7 10 13 16 19 22 25 28 31 34 37 40 43 46 49 52 55 58 61 64 67 70 73 76 79 82 85 88 91 94 97 100 103 106 109 112 115 118 121 124 127 130 133 136 139 142 145 148 151 154 157 160 163 166 169 172 175 178
Endtoenddelay(ms)
Samples (individual flows)
Mean of end-to-end delay for each flow (ms)
No renumber
Renumber
0.00
0.50
1.00
1.50
2.00
2.50
3.00
3.50
4.00
4.50
5.00
1 4 7 10 13 16 19 22 25 28 31 34 37 40 43 46 49 52 55 58 61 64 67 70 73 76 79 82 85 88 91 94 97 100 103 106 109 112 115 118 121 124 127 130 133 136 139 142 145 148 151 154 157 160 163 166 169 172 175 178
Standarddeivaonofe2edelay(ms)
Samples (inidividual flows)
Standard devia on of end to end delay (ms)
No renumber
Renumber
33

34. Implications
• With a proper naming and addressing structure in place, life network
renumbering can be done
– without impacting existing flows
– without the need of extra protocols or mechanisms
– in a fully automated way (minimize opex and network downtime)
• Use cases
– Network consolidation (e.g. acquisition of other networks)
– Update network addressing scheme to optimize routing (e.g. due to changes in network
topology)
– Better support for mobility (change address of moving nodes if they attach to different
subnets)
34

35. Implications for mobility
1.2.1 1.2.2 1.2.3 1.2.51.2.4
1.1.1 1.1.2
Subnet1
(1.x.y)
2.2.1 2.2.2 2.2.3 2.2.52.2.4
2.1.1 2.1.2
Subnet2
(2.x.y)
0.1.0 0.2.0
2.0.11.0.1
35
(1) IPCP in MH
@ 1.0.1
(2) IPCP in MH
@ 1.0.1
@ 2.0.1
(3) IPCP in MH
@ 2.0.1
1.0.1
2.0.1
IPCPs in Base Stations IPCPs in Base Stations
IPCPs in edge routers
IPCPs in core
routers
IPCPs in core
routers

36. Mobile network with multiple layers
Border
Router
Core DIF
Under DIFs
Border
Router
Under DIFs
Border RouterBase StationMH
Radio DIF
Under
DIFs
District DIF
Metro DIF
Regional DIF
Public Internet DIF
Application-specific DIF
Mobile Infrastructure NetworkCustomer Terminal
…
…
…
Under DIFs
Operator core
• Create as many DIFs as needed depending on density of mobile devices and speed of mobility in
different parts of the mobile network
• Each application can use the DIF that provides enough scope and QoS for its communication
needs -> not restricted to the “top ones”
• All layers have the same structure and protocols, implementations can be highly optimized;
overhead of adding new layers is minimal
36

37. Example with 4 levels (where needed)
Urban Sub-urban Urban UrbanDense Urban
BS DIF District DIF
LegendMetro DIF Regional DIF
37

38. Scenario: physical systems
• Single service provider with small edge DC to host latency-critical or high-
bandwidth services
38
Large-scale RINA Experimentation on FIRE+ 14
UE
1
UE
2
AR
1
AR
2
AR
3
AR
4
AR
5
AR
6
ER
1
ER
2
CR
1
ISP
1
ISP
2
SRV
5
SRV
6
SRV
1
SRV
2
SRV
3
SRV
4
ToR
2
ToR
1
DC
GW
Small DC
Service Provider net
Data Center Gateway
User Equipment
Provider Access Router
Edge Router
Provider 1 Core Router
ISP Router
Server
Top of Rack Router
• Six access routers
– WiFi Aps
• 2 Edge routers
• 1 Core router
• 1 small DC
– 1 DC GW
– 2 TORs
– 2 servers at each ToR
• 2 Mobile Hosts (UEs)
– 1 roaming, 1 static

39. Scenario: DIFs
• Mobile network DIF: provides DMM and supports service DIFs
• Internet DIF: provides access to apps available through servers at the Internet
• Slice1 DIF: provides UE1 access to apps available through provider DC
• Slice 2 DIF: provides UE2 access to apps available through provider DC
39
UE Access 1 Edge 1 Core 1
ISP1 Server6
Mobile network DIF
Internet DIF
DAF (rina-tgen or rina-echo-time)
Shim DIF WiFi Shim DIF Eth Shim DIF Eth
Shim DIF Eth Shim DIF Eth
UE
2
A1
A4
A2 E1
C1
E2
Mobile
Network DIF
I1
UE C1
S1
S2I2
Internet DIF
A3
A5
A6
DC
UE Access 2 Edge 1 DC
Gateway
ToR 1 Server 1
Mobile network DIF
Enterprise 1 VPN DIF
DAF (Any demo app)
Shim DIF WiFi Shim DIF Eth Shim DIF Eth Shim DIF Eth Shim DIF Eth
S2
GW
S4Enterprise 2
VPN DIF
DC Fabric DIF
S1
UE
1
GW
S3Enterprise 1
VPN DIF
UE
2 S2
S1
S3
S4
GW
ToR
1
ToR
2

40. Application discovery (I)
40
Access 2 Edge 1 DC
Gateway
ToR 1 Server 1
Mobile network DIF
Slice 1 DIF
Shim DIF WiFi Shim DIF Eth Shim DIF Eth Shim DIF Eth Shim DIF Eth
DC Fabric DIF
A C
UE
App_name: rina-echo-time.server-aneto--

41. Application discovery (II)
41
UE Access 1 Edge 1 Core 1
ISP1 Server5
Mobile network DIF
Internet DIF
Shim DIF WiFi Shim DIF Eth Shim DIF Eth
Shim DIF Eth Shim DIF Eth
A B
App_name: rina-echo-time.server-montblanc--

42. Application discovery (III)
42Large-scale RINA Experimentation on FIRE+ 20
App_name: rina-echo-time.server-ll--
Access 2 Edge 1
Shim DIF WiFi Shim DIF Eth
A
UE
Mobile network DIF
D

43. Some results on Mobility Management
• “Mobility Management in RINA networks: experimental validation of architectural
policies”
– E. Grasa, L. Bergesio, M. Tarzan, D. Lopez, S. van der Meer, J. Day, L. Chitkushev
– IEEE WCNC 2018, Barcelona
– Paper not online yet
– “This paper analyses what properties such schema needs to have, and discusses how Internet
mobility solutions are missing parts of it. Then it looks at RINA, a network architecture with a
complete naming scheme. Theoretical analysis backed up by experimental validation of the main
properties for mobility support shows that managing mobility in RINA networks not only is simpler
and easier to scale compared to the Internet situation, but also that no special protocols or
mechanisms need to be added to RINA in order to support mobility.”
43

44. Some results on cost of mobility
• “On supporting mobility and multi-homing in Recursive Internet
Architectures”
– V. Ishakian, J. Akinwuni, F. Esposito, I. Matta
– Computer Communications, 2012, Vol. 35, Issue 13
– http://www.cs.bu.edu/fac/matta/Papers/RINA-ComCom2012.pdf
– “In this paper, we present a specification of the process of ROuting in Recursive
Architectures (RORA). We also perform an average-case cost analysis to compare the
multihoming / mobility support of RINA, against that of other approaches such as LISP and
Mobile-IP. Extensive experimental results confirm the premise that the RINA architecture and
its RORA routing approach are inherently better suited for supporting mobility and
multihoming.”
44

45. Results on topological addressing in large-scale
DCs
• “Benefits of topological routing policies in RINA-enabled large-scale
DataCentres”
– S. Leon, J. Perello, D. Careglio, E. Grasa, D. Lopez, P. Aranda
– IEEE Globecom 2016
– https://www.researchgate.net/publication/309782103_Benefits_of_Programmable_Topological_R
outing_Policies_in_RINA-Enabled_Large-Scale_Datacenters
– “… we propose rule-based topological routing and forwarding policies tailored to the
characteristics of publicly available Google’s and Facebook’s DCNs… Numerical results show
that the scalability of our proposal depends on the number of concurrent failures in the DCN
rather than its size (e.g., number of nodes/links), dramatically reducing the total amount of routing
and forwarding information to be stored at nodes. “
45

46. SECURITY
46

47. Security: DIFs are securable containers
Secure layers instead of protocols, expose less to apps, scope
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
RINA IP protocol suite
Consistent security model, enforced by each layer via pluggable
policies
Each protocol has its own security model/functions (IPsec, TLS,
BGPsec, DNSsec, etc.)
Scope as a native construct: controlled connectivity by default Single scope (global), connectivity to everyone by default. Scope
via ad-hoc means: firewalls, ACLs, VLANs, VPNs, etc.
Complete naming and addressing, separation of synchronization
from port allocation
4747
47

48. Results on security (I)
• “Assessing the security of a clean-slate Internet architecture”
– G. Bodappati, I. Matta, J. Day, L. Chitkushev
– IEEE International Conference on Network Protocols
– http://www.cs.bu.edu/techreports/pdf/2009-021-clean-slate-internet-security.pdf
– “In this paper, we show how, without the aid of cryptographic techniques, the bare-bones
architecture of RINA can resist most of the security attacks faced by TCP/IP. We also show
how hard it is for an intruder to compromise RINA. Then, we show how RINA inherently
supports security policies in a more manageable, on-demand basis”
48

49. Separating port allocation from sync.
Complete application naming
• With app-names no need for well-known ports.
Port-ids of local scope (not in protocol headers)
• CEP-ids (in protocol headers) dynamically
generated for each flow
49
IPCPP
A
App
A
Port-id
read/
write
1
EFCP instance,
cep-id
8736
IPCPP
A
App
B
Port-id
read/
write
4
EFCP instance,
cep-id
9123
Synchronization
• Well-known ports used to identify app endpoints;
statically assigned. @s exposed to apps.
• Ports used also to identify TCP instances (in
protocol headers). Attacker only needs to guess
source port-id
RINA TCP/IP
IP@:
12
Port
read/
write 12
TCP instance,
port
12
IP @:
78
Port
read/
write
78
TCP instance,
port
78
TCP PM
A
TCP PM
A

50. Scope as a native construct
Recursion provides isolation
• Size each DIF to the scope supported applications need
– Only allow those that really need to connect to the apps
• No need for extra tools to do that: scope is built-in
– DIFs are securable containers, no need for firewalls
50
Internet (TCP/IP) RINA
Default model Global connectivity Controlled connectivity
Control scope via Firewalls, ACLs, VLANs, Virtual Private
Networks, etc..
Scope native concept in architecture
(DIF)
Example: Provider’s network
internal layers hidden from
customers and other providers

51. Results on security (II)
• “Patterns in network security: an analysis of the architectural complexity
in securing RINA networks ”
– J. Small
– Master thesis
– http://rina.tssg.org/docs/js-002.7-patterns_in_network_security.pdf
– “Based on the evidence presented, RINA seems to be able to deliver on security
requirements with substantially less complexity in terms of number of protocols, required
number of flows, and especially the required number of distinct mechanisms, compared to
the Internet protocol suite”
51

52. Separation of mechanism from policy
52
IPC API
Data Transfer Data Transfer Control Layer Management
SDU Delimiting
Data Transfer
Relaying and Multiplexing
SDU Protection
Retransmission Control
Flow Control
RIB Daemon
RIB
CDAP Parser/Generator
CACEP
Enrollment
Flow Allocation
Resource Allocation
Routing
Authentication
StateVector
StateVector
StateVector
Data TransferData Transfer
Retransmission ControlRetransmission Control
Flow Control
Flow Control
Namespace Management Security Management
• All layers have the same mechanisms and 2 protocols (EFCP for data transfer, CDAP for layer
management), programmable via policies.
• Don’t specify/implement security protocols, only security policies
– Re-use common layer structure, re-use security policies across layers
• This approach greatly simplifies the network structure, minimizing the cost of security and
improving the security level
– Complexity is the worst enemy of security (B. Schneier)
Authentication
Access control (layer mgmt
operations)
Access control
(joining the DIF)
Coordination of security functionsConfidentiality,
Integrity
Source: J. Small master thesis

53. Results on security (III)
• “From protecting protocols to protecting layers: designing, implementing and
experimenting with security policies in RINA ”
– E. Grasa, O. Rysavy, O. Lichtner, H. Asgari, J. Day, L. Chitkushev.
– IEEE ICC 2016
– https://www.researchgate.net/publication/304625404_From_protecting_protocols_to_layers_
Designing_implementing_and_experimenting_with_security_policies_in_RINA
– “In this paper we explore the security properties of the Recursive InterNetwork Architecture,
analyzing the principles that make RINA networks inherently more secure than TCP/IP-based
ones. We perform the specification, implementation and experimental evaluation of the first
authentication and SDU protection policies for RINA networks. RINA's approach to securing
layers instead of protocols increases the security of networks, while reducing the complexity
and cost of providing security ”
53

54. NETWORK MANAGEMENT
54

55. Network management
Commonality is the key to effective network management
From managing a set of layers, each with its own protocols,
concepts and definitions …
… to managing a common, repeating structure of two protocols
and different policies
• Commonality and consistency in RINA greatly simplifies management models, opening the door
to increased automation in multi-layer networks
– Reduce opex, network downtime, speed-up network service delivery, reduce components that need to be
standardised
55
55

56. Some results on network management
• “Simplifying multi-layer network management with RINA”
– S. van der Meer, B. Gaston, E. Grasa, M. Crotty, M. A. Puente
– TEERNA Networking Conference
– https://tnc16.geant.org/core/presentation/667
– “This paper performs a comparative analysis in the complexity of managing an IP-based and
a RINA-based large-scale multi-tenant data centre networks. Configuration management is
the main target of the analysis although some hints on performance and security
management are also provided. The analysis shows that the commonality built into the RINA
architecture and the single type of recursive layer with a uniform API greatly reduces the
complexity of the models the Network Management System (NMS) uses to understand the
state of the managed network.”
56

57. Some results on network management
• “Taming policy complexity: Model to Execution”
– S. van der Meer, J. Keeney, L. Fallon
– IEEE NOMS 2018
– Paper not online yet
– “However, policy-based management as a standalone domain has never been evaluated in
terms of which parts are variant / invariant, i.e. which parts of policy-based management can
be domain-, model-, language-, use case-independent. In this paper, we introduce and
define a formal universal policy model that does exactly that. The result is a model that can
be used to design, implement, and deploy immutable policy infrastructure (engine and
executor) being able to execute (virtually) any policy model.”
57

58. DEPLOYMENT / INTEROP
58

59. Deployment
New technology but incremental deployment
• RINA can be deployed incrementally where it has the right incentives, and
interoperate with current technologies (IP, Ethernet, MPLS, etc.)
– Over IP (just like any overlay such as VXLAN, NVGRE, GTP-U, etc.)
– Below IP (just like any underlay such as MPLS or MAC-in-MAC)
– Next to IP (gateways/protocol translation such as IPv6)
IP Network
RINA Provider
RINA Network
Sockets ApplicationsRINA supported Applications
IP or Ethernet or MPLS, etc
59

60. RINA application API
60

61. Overlays: RINA over X via shim DIFs
61
ToR ToRFabric Spine FabricServer Server
IPv4 or IPv6 (Fabric layer)VM VM
Ethernet Ethernet Ethernet Ethernet
Tenant DIF
Ethernet
UDP
Ethernet
Sh,. memSh,. mem
Shim DIF HV Shim DIF HV
Shim DIF UDP
App
B
App
A

62. IP over RINA
• IP over RINA over Ethernet
• Potential use cases
– IP VPNs
– SD-WAN (distributed enterprise, DC interconnect)
– Metro and/or core network capable of multiple QoS and support for multiple tranports
– DC fabric
62
DIF
Shim DIF Eth Shim DIF Eth
IP layer
. . .

63. IP over RINA: provider-based IP VPNs
63
DIF
Ethernet
blue-pe2-
rina_ip
blue-pe1-
rina_ip
PE router 1 PE router 2
3 5
port-id port-id
App name: <VPN id>-<node name>-RINA_IP-
Process
name
Process
instance
Entity
name
P router 1 P router 2
Ethernet Ethernet
Shim DIF Eth Shim DIF Eth Shim DIF Eth

64. Gateways (e.g. Transport layer gateways)
64

65. Research, open source, specs
• Current research projects
– FP7 PRISTINE (2014-2016) http://ict-pristine-eu
– H2020 ARCFIRE (2016-2017) http://ict-arcfire.eu
– Norwegian project OCARINA(2016-2021)
– BU RINA team http://csr.bu.edu/rina
• Open source implementations
– IRATI (Linux OS, C/C++, kernel components, policy framework, RINA over X) http://github.com/irati/stack
– RINASim (RINA simulator, OMNeT++) https://rinasim.omnetpp.org/
– ProtoRINA (Java, RINA over UDP) https://github.com/ProtoRINA/users/wiki
– rlite (Linux OS, C/C++, kernel components, minimize footprint) https://github.com/vmaffione/rlite
• RINA specifications
– Pouzin Society (experimental specs) http://pouzinsociety.org
– ISO SC6 WG7 (active in two projects: Future Network – Architectures, Future Network- Protocols)
1
2
3
4
1
2
3
1
2 65
4
65