PRISTINE RINA presentation for the Software Development Kit (ICC 2016)

1. An SDK to exploit RINA programmability
A Software Development Kit to
exploit RINA programmability
Eduard Grasa (presenter), Vincenzo Maffione, Francesco
Salvestrini, Leonardo Bergesio, Miquel Tarzan
FP7 PRISTINE
ICC 2016, Kuala Lumpur, May 24th 2016

2. WHAT IS RINA?1
2

3. RINA highlights
• 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: communication (flows) between 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
1
2
3
4
5
6
3

4. From the “TCP/IP” protocol suite …
• Functional layers organized for modularity, each layer provides
a different service to each other
– As the RM is applied to the real world, it proofs to be incomplete.
As a consequence, new layers are patched into the reference
model as needed (layers 2.5, VLANs, VPNs, virtual network
overlays, tunnels, MAC-in-MAC, etc.)
(Theory) (Practice)
4

5. … to the RINA architecture
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
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
Control
Retransmission
Control
Flow Control
Flow Control
Increasing timescale (functions performed less often) and complexity
Namespace
Management
Security
Management
5

6. Deployment
Clean-slate concepts but incremental deployment
Large-scale RINA Experimentation on FIRE+ 6
• IPv6 brings very small improvements to IPv4, but requires a
clean slate deployment (not compatible to IPv4)
• 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

7. RECURSION, VIRTUALIZATION
AND PROGRAMMABILITY
2
7

8. Recursion instead of virtualization (I)
• 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
8

9. Recursion instead of virtualization (I)
• 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
9
PtP DIF PtP DIF PtP DIF PtP DIF
PtP DIFPtP DIFPtP DIFPtP DIF PtP DIF PtP DIF PtP DIF

10. Recursion instead of virtualization (I)
• 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
10
Metro DIF Metro DIF
PtP DIF PtP DIF PtP DIF PtP DIF
PtP DIFPtP DIFPtP DIFPtP DIF PtP DIF PtP DIF PtP DIF

11. Recursion instead of virtualization (I)
• 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
11
Metro DIF Metro DIFCore DIF
PtP DIF PtP DIF PtP DIF PtP DIF
PtP DIFPtP DIFPtP DIFPtP DIF PtP DIF PtP DIF PtP DIF

12. Recursion instead of virtualization (I)
• 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
12
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

13. Recursion instead of virtualization (I)
• 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
13
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

14. Recursion instead of virtualization (II)
• Example 2: LTE (Long Term Evolution)
– Uses PDCP, GTP to transport user’s IP payload, and also relies on internal
IP network.
14
IP (e.g. Internet)
TCP or UDP
PDCP GTP-U
Protocol
conversion
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

15. Recursion instead of virtualization (II)
• Example 2: LTE (Long Term Evolution)
– Uses PDCP, GTP to transport user’s IP payload, and also relies on internal
IP network.
15
IP (e.g. Internet)
TCP or UDP
PDCP GTP-U
Protocol
conversion
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

16. Recursion instead of virtualization (II)
• Example 2: LTE (Long Term Evolution)
– Uses PDCP, GTP to transport user’s IP payload, and also relies on internal
IP network.
16
IP (e.g. Internet)
TCP or UDP
PDCP GTP-U
Protocol
conversion
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

17. Recursion instead of virtualization (II)
• Example 2: LTE (Long Term Evolution)
– Uses PDCP, GTP to transport user’s IP payload, and also relies on internal
IP network.
17
IP (e.g. Internet)
TCP or UDP
PDCP GTP-U
Protocol
conversion
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

18. Recursion instead of virtualization (II)
• Example 2: LTE (Long Term Evolution)
– Uses PDCP, GTP to transport user’s IP payload, and also relies on internal
IP network.
18
IP (e.g. Internet)
TCP or UDP
PDCP GTP-U
Protocol
conversion
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

19. Recursion instead of virtualization (II)
• Example 2: LTE (Long Term Evolution)
– Uses PDCP, GTP to transport user’s IP payload, and also relies on internal
IP network.
19
IP (e.g. Internet)
TCP or UDP
PDCP GTP-U
Protocol
conversion
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
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

20. Recursion instead of virtualization (III)
• 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. 20
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
Protocol conversion,
Local bridging

21. Recursion instead of virtualization (III)
• 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. 21
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
Protocol conversion,
Local bridging PtP DIF PtP DIF PtP DIF PtP DIF
PtP DIF PtP DIFPtP DIFPtP DIF

22. Recursion instead of virtualization (III)
• 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. 22
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
Protocol conversion,
Local bridging PtP DIF PtP DIF PtP DIF PtP DIF
PtP DIF PtP DIFPtP DIFPtP DIF
DC Fabric DIF

23. Recursion instead of virtualization (III)
• 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. 23
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
Protocol conversion,
Local bridging PtP DIF PtP DIF PtP DIF PtP DIF
PtP DIF PtP DIFPtP DIFPtP DIF
DC Fabric DIF
Tenant DIF

24. Network Programmability
• Centralized control of data
forwarding
– GSMPv3 (label switches:
ATM, MPLS, optical),
OpenFlow (Ethernet, IP,
evolving)
• APIs for controlling network
services & network devices
– ONF SDN architecture,
IEEE P1520 (P1520
distinguished between
virtual devices and
hardware)
24
ONF‘s SDN architecture

25. Separation of mechanism from policy
25
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
Control
Retransmission
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

26. DESIGN AND IMPLEMENTATION
OF AN SDK FOR IRATI3
26

27. IRATI design: decisions and tradeoffs
27
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

28. Overview of IRATI and its SDK
Normal IPC Process
(Layer Management)
User space
IRATI RINA implementation
Kernel
Kernel IPC Manager
Normal IPC Process
(Data Transfer/Control)
Shim IPCP
over 802.1Q
IPCP Daemon
(Layer Mgmt)
IPC Manager
Daemon
Normal IPCP
(Data Transfer)
SHIM
IPCP
App
zoom in
zoom in
zoom in
Normal IPCP
(Data transfer)
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 IPCP
(Layer Mgmt)
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
Enroll.
sequence
SDK support
Routing
policyIPC Manager
librina
Manag
ement
Agent
IPCM
logic
Network
Manager
(NMS DAF)
SDK support
RIB & RIB
Daemon
Shim
IPCP
Shim
IPCP

29. RINA Plugins Infrastructure (RPI)
Kernel RPI (kRPI)
29
PolicySet lifecycle PolicySet classes• Different policy-set class per
component, since each
component has different
policies.
● “OO” approach
● All policy set classes derive
from base class
● All components derive from
base class
● Plugins are Loadable Kernel Modules (LKM)
● They publish a set of policy sets, becomes available to the RINA stack.
● Factories, named after each policy set, provide operations to create/delete instances of
policy set classes

30. RINA Plugins Infrastructure (RPI)
User-space RPI uRPI)
30
● Same concepts as kRPI (factories, lifecycle, policy classes), different impl
● Plugins are shared objects dynamically loaded by the IPCP Daemon, loaded
through the libdl library

31. SDK Usage: Experimentation with IRATI
Data transfer policies: RMT and EFCP
31
• Programmed data transfer policies
to manage congestion in a
distributed cloud environment.
• Two touch points: i) ECN-marking
policies for the RMT; ii) flow
control policies that react to ECN-
marked PDUs in EFCP
“TCP Tahoe” (EFCP) + RED (RMT)
DEC Binary feedback (EFCP and RMT)

32. ONGOING RINA INITIATIVES
4
32

33. Research, open source, standards
• 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++)
– ProtoRINA (Java, RINA over UDP, quick prototyping)
• Key RINA standardization activities
– Pouzin Society (experimental specs) http://pouzinsociety.org
– ISO SC6 WG7 (2 new projects: Future Network – Architectures, Future
Network- Protocols)
– ETSI Next Generation Protocols ISG
1
2
3
4
1
2
3
1
2
3
33