#ict-pristine
IRATI: An open source RINA
implementation for Linux/OS
Eduard Grasa on behalf of
The PRISTINE consortium

OVERVIEW: GOALS AND
HIGH LEVEL DESIGN
2
1
#ict-pristine

• … 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
3
1
2
3
4
5
1
2
3
4
5
#ict-pristine

Some decisions and tradeoffs
4
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

High-level software arch.
5

PRISTINE contributions: SDK, policies, NMS
6
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)

Implementation status (I)
General
IRATI objectives, outcomes and lessons learned 7
Component Summary of status
Management Agent
Initial implementation ready: IPCP creation, destruction;
assignment to a DIF; triggering of enrollment operation; query RIB
Manager Initial PoC ready, working on integration with Management Agent.
Shim IPCP over
802.1q
Wrap a VLAN interface or a full Ethernet interface with the DIF API.
Uses own implementation of ARP internally. Single QoS cube.
Shim IPCP over
TCP/UDP
Wrap a TCP/UDP-IP layer with the DIF API. Two QoS cubes: reliable
(“implemented” with a TCP connection) and unreliable (UDP)
Shim IPCP for HV
Allow VM-to-host communications over shared memory wrapping
it with the DIF API.
Normal IPC Process See next slides
SDK (kernel RPI)
Support for RMT and EFCP. Need to improve granularity of policy-
sets and add support for SDU Protection.
SDK (user-space RPI)
Support for enrollment, auth, flow allocation, namespace mgr,
resource allocator, routing. Need CDAP, RIB Daemon support.

Implementation status (I)
IPCP components
IRATI objectives, outcomes and lessons learned 8
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

QUICK DEMO
9
2

Overlay2
2
Quick demo scenario
10
VLAN 110 VLAN 100
Shim DIF over
802.1Q, “100”
Shim DIF over
802.1Q “110”
test1.IRATI
16
test2.IRATI
17
test3.IRATI
18
“Normal.DIF”
Server
app
Client
app
System 1 System 2 System 3
eth1eth2eth1eth1
• Nothing too fancy, just show how IPCPs are created and configured currently,
2 levels of DIFs and the “rina-echo-time” application on top
Overlay1
1“vpn.DIF”

EXPERIMENTAL ACTIVITIES
11
3

• Decide the number and scope of the layers (DIFs) in the network, .
Example:
– Three ISPs that use multiple DIFs internally for traffic aggregation
purposes
– ISP alliance DIF: the three ISPs get together to support a number of
specialized DIFs
• Public Internet DIF (General purpose), Corporate VPN DIF, Interactive Video
DIF
Designing RINA networks (I)
Number, scope of layers and goal of each one
12
ISP 2 Metro DIF
ISP 2 Regional DIF
ISP 2 Backbone DIF
ISP 3 Metro DIF
ISP 3 Backbone DIF
ISP 1 Metro DIF
ISP 1 Backbone DIF
ISP Alliance DIF
Public Internet DIF
Corporate VPN DIFInteractive Video
DIF

Designing RINA networks (II)
QoS cubes to be supported by each layer
• Identify the types of traffic that should be served by each layer and
dimension it. Ideally, for each type of traffic, we would like to know:
– Characterization in terms of burstiness, offered load, etc
– Required statistical bounds on loss and delay (e.g. 99% of time
loss should be less than 5%) -> can be derived from required QoE
– Reliable and/or in order delivery of data required?
• From that information the number and characteristics of QoS cubes
required can be derived.
13

Designing RINA networks (III)
Policy sets of each layer
• Design new (or use existing) policy sets that allow each layer to reach
its design goals taking into account its operational environment
(offered traffic, QoS cubes supported, N-1 DIFs).
– Connectivity graph, addressing, routing, data transfer, delimiting, resource
allocation, relaying and multiplexing, authentication, authorization, SDU protection,
etc
14
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
StateVectorStateVector
Data TransferData Transfer
Retransmission
Control
Retransmission
Control
Flow Control
Flow Control
Increasing timescale (functions performed less often) and complexity
Namespace
Management
Security
Management

Designing RINA networks (IV)
Network Management System
• Analyze the role of the Network Management System (“monitor and
repair”), a number of configurations are possible – from fairly
centralized to autonomic.
• Understand the different operating ranges of the network, decide
monitors/triggers to sense them and design strategies to
automatically transition between different policy sets associated to
the operating ranges.
15
Mgr
MA MA MA
MA
MA
MA
MA
MA

Designing RINA networks (V)
Interoperating with legacy technology
• If it has to interoperate with existing technology or support legacy apps,
understand the required tooling for interoperation: shim DIFs,
gateways, legacy application support.
16
GatewayVIFIB Node
TCP or UDP
Public Internet
(IPv6)
Ethernet
Gateway
VIFIB Node VIFIB Node
Ethernet (VLAN)
Shim IPC
Process
Shim IPC
Process Public Internet (IPv4)
Ethernet Ethernet. . . Ethernet Ethernet. . .
Shim IPC
Process
Shim IPC
Process
Shim IPC
Process
IPC
Process
IPC
Process
IPC
Process
IPC
Process
SlapOS base
DIF
Shim DIF over UDP
Shim DIF
over 802.1Q
Shim DIFs
Gateway
Legacy
app
faux
Faux Sockets

Performance experiments (I) goodput
17
• Note: The prototype is not performance-optimized yet
• An extra layer doesn’t add too much overhead

Performance experiments (II) delay
18
RTT directly over the shim DIF
RTT directly over normal
IPCP over shim
• Adding an extra DIF doesn’t
incur a significant penalty on
processing delay

Experiments we are currently setting up
Distributed cloud scenario
19
• Authentication, encryption
• Multi-layer congestion control/avoidance
• Delay/loss multiplexing (multiple QoS classes)

Experiments we are currently setting up
Datacentre networking scenario
20
• Multi-layer congestion
control/avoidance
• QoS-aware multipath routing
• Routing in multiple layers

OPEN SOURCE INITIATIVE
21
4

Open source IRATI
22
• 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

Planned contributions to (open) IRATI
23
Open IRATI
FP7 PRISTINE project
• Software Development Kit (RPI)
• Simple configuration tools
• Management Agent
• Enhanced CDAP and RIB libraries
• Several IPCP Policies
• Bug fixes
• Faux sockets? Network Manager?
Contribs during 2015 and 1H 2016
G3+ OC winner IRINA project
• Traffic generation modules for test apps,
bug fixes
April/May 2015
You
• Lots to do!
Let’s talk!

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