#ict-pristine

IRATI: An open source RINA implementation for Linux/OS

Eduard Grasa on behalf of The PRISTINE consortium

2/6

OVERVIEW: GOALS AND HIGH LEVEL DESIGN1

#ict-pristine

3

• … 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

1

2

3

4

5

1

2

3

4

5

#ict-pristine

4

Some decisions and tradeoffs

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 splitvs 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

5

High-level software arch.

6

PRISTINE contributions: SDK, policies, NMS

Normal IPC Process (Layer Management)

User space

IRATI stack

KernelKernel IPC Manager

Normal IPC Process (Data Transfer/Control)

Shim IPCPover 802.1Q

Shim IPCPfor HV

Shim IPCPTCP/UDP

IPC Process Daemon(Layer Management)

IPC Manager Daemon

Normal IPC Process (Data Transfer/Control)

Shim IPCPTCP/UDP

Shim IPCPfor HV

Shim IPCPover 802.1Q

Application

zoom in

zoom in

zoom in

Normal IPC Process (Data Transfer/Control) Error and Flow Control Protocol

Relaying and Multiplexing TaskSDU Protection

SDK support

RTT

po

licy

Tx c

trl

polic

y

ECN

po

licy

. . .

SDK support

Forw

arpo

licy

Sche

dupo

licy

Max

Q

polic

y

Mon

it po

licy

SDK support

TTL

polic

y

CR

Cpo

licy

Encr

yppo

licy

Normal IPC Process (Layer Management)

RIB & RIB Daemon

librina

Resource allocation

Flow allocation

Enrollment

Namespace Management

Security Management

Routing

SDK support

Aut

h.po

licy

Acc

. ctr

lpo

licy

Coo

rdpo

licy

SDK support

Add

ress

as

sign

Dire

ctor

y re

plic

a

Add

ress

va

lidat

SDK support

New flowpolicy

SDK support

PFT

gen

polic

y

Push

bak

notif

y

SDK support

Enroll. sequence

SDK support

Routing policyIPC Manager

RIB & RIB Daemon

librina

Management agent

(NMS DAF)IPCM logic

Network Manager(NMS DAF)

IRATI objectives, outcomes and lessons learned 7

Implementation status (I)General

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.

IRATI objectives, outcomes and lessons learned 8

Implementation status (I)IPCP components

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

9

QUICK DEMO2

10

Overlay22

Quick demo scenario

VLAN 110 VLAN 100

Shim DIF over 802.1Q, “100”

Shim DIF over 802.1Q “110”

test1.IRATI16

test2.IRATI17

test3.IRATI18

“Normal.DIF”

Serverapp

Clientapp

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

Overlay11“vpn.DIF”

11

EXPERIMENTAL ACTIVITIES3

12

• 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

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 DIFCorporate VPN DIFInteractive Video

DIF

13

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.

14

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

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

State VectorState VectorState Vector

Data Transfer Data Transfer

Retransmission Control

Retransmission Control

Flow ControlFlow Control

Increasing timescale (functions performed less often) and complexity

Namespace Management

Security Management

15

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.

Mgr

MA MA MA

MA

MA

MA

MA

MA

16

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.

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 baseDIF

Shim DIF over UDP

Shim DIF over 802.1Q

Shim DIFs

GatewayLegacyapp

faux

Faux Sockets

17

Performance experiments (I) goodput

• Note: The prototype is not performance-optimized yet

• An extra layer doesn’t add too much overhead

18

Performance experiments (II) delay

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

19

Experiments we are currently setting upDistributed cloud scenario

• Authentication, encryption• Multi-layer congestion control/avoidance• Delay/loss multiplexing (multiple QoS

classes)

20

Experiments we are currently setting upDatacentre networking scenario

• Multi-layer congestion control/avoidance

• QoS-aware multipath routing• Routing in multiple layers

21

OPEN SOURCE INITIATIVE4

22

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

23

Planned contributions to (open) IRATI

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 fixesApril/May 2015

You• Lots to do! Let’s talk!

Further information can be found here.

Twitter @ictpristinewww www.ict-pristine.eu

<Thank you!>