eucnc rina-tutorial

Monday Tutorial sessions

An Introduction to RINA

Dimitri Staessens - iMinds

Networking is not about machines

2

The constructs we interact with are

computer programs

3

Addressing hardware is not flexible

enough

4

Virtualization

5

Networking is about interconnecting

software

6

We need to think processes not

machines

7

kill –SIGNAL <pid>

Inter process communication

8

Message passing Shared memory

Message Passing IPC has a simple API

9

fd[1] fd[0]

int pipe (pipefd, /* flags */);int read (pipefd[0], <buf>, len);int write (pipefd[1], <buf>, len);

Basic premise of RINA

10

“Networking is IPC”

Single system

11

IPC FACILITY

X Y

Applications X and Y are known (instantiated by kernel)

Part of OS

Single system: flow allocation

12

IPC FACILITY

X Y

Port ID Port ID

flow

Flow allocation: reserves resources in the IPC facility and assigns port ID’s ~ fd’s


Part of OS

<port_id> alloc (pid, …);

dealloc (port_id);

Implementation dependent

Message passingshared memory

Single system: connection

13

IPC FACILITY

X Y

Port ID Port ID

flow

Flow allocation: reserves resources in the IPC facility and assigns port ID’s ~ fd’s


Part of OS

<port_id> alloc (pid, …);

<port_id> accept (…);

dealloc (port_id);

read/write (port_id, sdu *, len);

Implementation dependent

Message passingshared memory

APPLICATION FACILITY

Connection (application protocol)

Two systems connected by a wire

14

X Y

Applications X and Y -> need to register a name that is unique over both systems!


15

X Y

IPC process: provides IPC service.Not only locally, but over 2 systems

Requires an IPC process component that manages the medium (MAC)


IPC ProcessIRM IRM

IPC Resource Managerbasically creates/destroys IPC processes.Ideally: part of the OS


16

DISTRIBUTED IPC FACILITY

X Y

Port ID Port ID

flowIPC Process

Locating an applicationif it’s not here, it’s over there… or doesn’t exist.


reg(pid, name);

unreg(pid);

alloc (name, …);

dealloc (port_id);

IRMIRM

DISTRIBUTED APPLICATION FACILITY


17


X Y

Port ID Port ID

flowIPC Process

Locating an applicationif it’s not here, it’s over there… or doesn’t exist.


reg(pid, name);

unreg(pid);

alloc (name, …);

dealloc (port_id);

IRM IRM

Multiple systems sharing a transmission

medium such as radio

18

X Y

Port ID Port ID

flowIPC Process

1 2

Z

3

Port ID

Need to synchronize names between the the systemsregister names (X,1), (Z,3), … -> directory functionsmall scope: broadcasting information is a feasible optionIPC Processes need addresses for scalability


IRMIRM IRM

IPC API

• APs communicate using a “port”

– portID: ~ file descriptor

• 6 operations:

– int _registerApp(appName, List<difName>)

– portId _allocateFlow(destAppName, List<QoSParams>)

– int _write(portId, sdu)

– sdu _read(portId)

– int _deallocate(portId)

– int _unregisterApp(appName, List<difName>)

19

Building networks

20

X YCommon Distributed Application Protocol

20

Building networks

21

X Y

21

C2 C1

A1 A2 B1 B2

E1 E2

Building networks: Normal IPCP

22

X Y

22

C2 C1

A1 A2 B1 B2

E1 E2

Normal IPC Process (IPCP)

D1

Building networks: Normal IPCP

23

X Y

23

C2 C1

A1 A2 B1 B2

E1 E2

Provides IPC to higher layers (DIFs/DAFs)Uses IPC from lower layers (DIFs)

Normal IPC Process (IPCP)

D1

Building networks: IPCP registration

24

X Y

A1 A2 B1 B2

C2 C1 E1 E2D1

24

IPCP D1 registers in 2 DIFs (A, B)

D1/A2D1/B1

Building networks: IPCP registration

25

X Y

A1 A2 B1 B2

C2 C1 E1 E2D1

25

D2

D1/A2D2/A1

D1/B1

Create IPCP D2, can register in DIF A (optional)

Building networks: flow allocation

26

X Y

A1 A2 B1 B2

C2 C1 E1 E2D1

26

D2

IPCP D2 allocates a flow with D1

D2 can now send messages to D1

D1/A2D2/A1

D1/B1

Building networks: enrollment

27

X Y

A1 A2 B1 B2

C2 C1 E1 E2D1

27

D2

A new operation: enrollment: “joining a DIF”

authenticationexchanging some basic information

configuration parametersaddresses

current equivalent: joining a wifi network

D1D2

D1/A2D2/A1

D1/B1


28

X Y

A1 A2 B1 B2

C2 C1 E1 E2

28

D3 performs the same procedures. DIF “D” now has 3 members

D1 D3D2

D1/A2D2/A1

D1/B1


29

X Y

A1 A2 B1 B2

C2 C1 E1 E2

F1 F2F3 F4

D1 D3D2

29

Flow allocation in normal IPCP

30

F1 F2

D1 D3D2

Flow allocation in normal IPCP

31

F1 F2

D1 D3D2

Flow allocation = reservation of resources

Flows vs Connections

32

F1 F2

D1 D3D2

Port_id Port_id

Cep-id Cep-id Cep-id Cep-id

Flow: implemented by a lower layer, between port_id’sResource: EFCP connection inside a layer, between CEP-id’s

Flow allocation = reservation of resources

Error and Flow Control Protocol

• DTP ~UDP

– Fragmentation

– Reassembly

– Sequencing

– Concatenation

– Separation

• DTCP ~ TCP

– Transmission control

– Retransmission control

– Flow control

• Loosely coupled by a state vector

• Based on Delta-t

33

Delta-t (Watson, 1981)

• Developed at L.Livermore labs, unique approach.

– Assumes all connections exist all the time.

– keep caches of state on ones with recent activity

• Watson proves that the conditions for distributed

synchronization are met if and only if 3 timers are bounded:

– Maximum Packet Lifetime: MPL

– Maximum number of Retries: R

– Maximum time before ACK: A

• That no explicit state synchronization, i.e. hard state, is

necessary.

– SYNs, FINs are unnecessary

• 1981:Watson shows that TCP has all three timers and more.

34

Inside the normal IPC process

IPC

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

RIB CDAP Parser/Generator

CACEP Enrollment

Flow Allocation

Resource Allocation

Forwarding Table Generator

Authentication

State V

ecto

rState

Ve

ctor

State V

ecto

r

Data Transfer Data Transfer





Flow ControlFlow Control

Appl.

Process

IPC Resource

Mgt.

SDU Protecti

on

Multiplexing

IPC Mgt. Tasks

Other Mgt. Tasks

Application Specific Tasks•Authentication of all processes

•RIB Daemon manages state objects

•EFCP protocol performs SDU transport

35


36

X Y

A1 A2 B1 B2

C2 C1 E1 E2

36

D3 performs the same procedures. DIF “D” now has 3 members

D1 D3D2

D1/A2D2/A1

D1/B1

Building networks

37

X Y

A1 A2 B1 B2

C2 C1 E1 E2

F1 F2F3 F4

D1 D3D2

37


38

X Y

A1 A2 B1 B2

C2 C1 E1 E2

F1 F2F3 F4

D1 D3D2

38

Basic concept of RINA

39


40


41


42


43

“Simplicity is prerequisitefor reliability” – E. Dijkstra

The lowest layer: shim DIFs

44


X Yconnection

Port ID Port ID

flowShim IPC Process

Wrap the IPC API around a legacy protocol

Ex. Ethernet

Shim DIF over UDP using DNS

45

Register in shim DIF

Flow allocation

Data transfer

Query directory

Flow allocation

Data transfer

Check if the name exists in the shim DIF (uniqueness!)

46

• 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 scalable architecture

Adoption path

47

TCP/IP or UDP/IP

Ethernet

Physical Media

ApplicationsEthernet

Physical Media

Applications

DIF

DIF…

Physical Media

ApplicationsToday

DIF

DIF…

TCP/IP or UDP/IP

Physical Media

Applications

DIF

DIF…

End goal

FP7 IRATI Project Prototype

IoT?

48

RINA: DTP + Flow Control

The Internet relies on TCP congestion control

What would happen if the dominant traffic becomes UDP?

User Mobility

49

X

Y

Mobility in RINA

50

DIF

X Y

LTE DIF

F3 F4

BACKHAUL DIF

Mobility in RINA

51

DIF

Y

F4

X

F3

BACKHAUL DIF

Mobility in RINA

52

DIF

Y

F4

X

F3

BACKHAUL DIF

Mobility in RINA

53

DIF

Y

F4

X

F3

BACKHAUL DIF

Mobility in RINA

54

DIF

Y

F4

X

F3

BACKHAUL DIF

Mobility in RINA

55

DIF

Y

F4

X

F3

BACKHAUL DIF

Mobility in RINA

56

DIF

Y

F4

X

F3

BACKHAUL DIF

Registration / Unregistration of Application in DIFs

No routing or address updates!

Device moves physically, but no IPCP moves logically within a DIF!

And flow allocations

Enroll / Unenroll in the LTE DIFs

57

Thank you.

Recursive Congestion Management in RINA

Peyman Teymoori

June 27, 2016

2

Layering in Networking – OSI vs. RINA

•  From the OSI perspective: each layer performs a specific task or tasks and builds upon the preceding layer until the communications are complete.

•  In Recursive InterNetworking Architecture (RINA): every layer (called “Distributed InterProcess Communication (IPC) Facility” (DIF)) has some mechanisms and policies with the goal of: –  providing and managing the communication among its entities

–  “Mechanisms” are the same in various DIFs. –  “Policies” can be programmed differently in various DIFs.

3

Congestion Control in RINA vs. the Internet

FP7-619305 PRISTINE Collaborative Project

Description of Work Part B: Page 113 of 115

B8.2. Work Package 3

Figure 2223 RINA an aggregate-based congestion control

Figure 2324 Distributed resource allocation approaches

Processes with specific functionality

Processes with generic functionality

4

Congestion Control in the Internet •  Problems with the Internet:

–  TCP scalability with: •  The diameter of the network •  The bottleneck link capacity •  The number of flows

–  Different link types

–  Split-TCP (PEPs): •  IPsec and SSL •  Scalability with the number of flows •  Processing delay at splitters

5

Congestion Control in RINA

•  Our goal: –  highlighting RINA Congestion Control (CC) benefits

Showing that improvements that have been done to TCP on the internet

"naturally appear" with RINA without their side effects

In 3 steps:

1.  Inspecting DIF and its modules, 2.  Showing DIF organizations, 3.  Comparative results

6

Step 1: Inspecting a DIF – IPC Process (IPCP)

≈ IP + UDP ≈ TCP

7

IPC Modules

Delimiting

Data Transfer Protocol (DTP)

Data Transfer Control Protocol

(DTCP)

(N-1)-DIF A (N-1)-DIF B

N-D

IF

(N-1

)-DIF

s

Queues

Relaying and Multiplexing Task Flow Aggregation

based on QoSCube!

EFCP

(N+1

)-DIF

s

8

Error and Flow Control Protocol (EFCP)

•  Ensures reliability, order, and flow and congestion control. •  Each EFCP instance consists of distinct instances of

–  Data Transfer Protocol (DTP), and –  Data Transfer Control Protocol (DTCP), (optional) which coordinate through a state vector.

•  Features: –  Win. based –  Rate based –  In/out of order delivery –  ACKs:

•  Delayed •  Selective •  Allowable gaps

Delimiting



(DTCP)


Queues

Relaying and Multiplexing Task

EFCP

9


•  Required •  Consists of tightly bound mechanisms found in all DIFs. •  Roughly equivalent to UDP. •  There is one instance of DTP for each flow. •  Some policies:

–  RTT Estimator, –  SenderInactivity, –  RcvrInactivity

Delimiting



(DTCP)


Queues


EFCP

10

Data Transfer Control Protocol (DTCP)

•  Optional •  Provides the loosely-bound mechanisms •  Each DTCP instance is paired with a DTP instance •  Controls the flow, based on its policies and the content

of the shared state vector. •  Some policies:

–  TxControl, –  SenderAck, –  RxTimerExpiry, –  ECN.

Delimiting



(DTCP)


Queues


EFCP

11

Step 2: Some DIF Configurations in RINA

•  Two simple RINA stack configurations by different organizations of DIFs

Delimiting

Data Transfer Protocol

Data Transfer Control


Queues


EFCP Delimiting




Queues


EFCP

12

A General DIF Configuration

“Error and Flow Control Protocol” (EFCP), “Relaying and Multiplexing Task” (RMT), “Resource Allocation” (RA).

Queue builds up

Reduces rate

Might be blocked

Queue builds up

Reduces rate

Might be blocked

Queue builds up

Reduces rate

This is the so-called pushback method.

Other feedback types are under investigation.

13

Step 3: A Comparative Example of Stacks 10 Mbps 75 ms

10 Mbps 25 ms

14

Horizontal: Consecutive DIFs

From P. Teymoori, M. Welzl, S. Gjessing, E. Grasa, R. Riggio, K. Rausch, D. Siracusa: "Congestion Control in the Recursive InterNetworking Architecture (RINA)", IEEE ICC 2016, Kuala Lumpur, Malaysia, 23-27 May 2016.

15

Vertical: Stacked DIFs

Topology: Results:

From the same publication

1 sender, 1 receiver: Sender sends flow 1 (large) at 0, and flow 2 (small) at time 10.

There is only one flow carrying packets here

There is only one flow carrying packets here

Scenario 1 Scenario 2

16

Around: In-Network Resource Pooling

•  A follow-up to: Psaras, Ioannis, Lorenzo Saino, and George Pavlou. "Revisiting Resource Pooling: The Case for In-Network Resource Sharing." Proceedings of the 13th ACM Workshop on Hot Topics in Networks. ACM, 2014

•  Easily implementable in RINA by an RMT routing policy

S1

S2

R1

R2

Router1

Router3

Router2

Router4

10 Mbps

10 Mbps

2 Mbps 3 Mbps

3 Mbps 10 Mbps

10 Mbps

10 Mbps

local stability, global fairness (1:1)

Result: Jain’s fairness index for the two flows was 0.999, which shows global fairness while local stability was provided through RINA-ACC

Delimiting




Queues


EFCP

17

Discussion

•  RINA can solve the Internet problems by –  breaking up the long control loop into shorter ones,

•  Link-specific congestion control

–  controlling flow aggregates inside the network, and •  Fewer competition among flows

–  enabling the deployment of arbitrary congestion control mechanisms per DIF.

•  Coupled with the policies in other modules

•  and of course, there are other questions that need to be answered before a full deployment.

18

Thank you!

Questions?

Large scale RINA Experimentation on FIRE +

RINA for converged operator networks in 5G scenarios

Leonardo Bergesio, Eduard Grasa – i2CAT

June 27th 2016, Athens


An Operator Network today and the converged vision

2

A (C)ON today..

Large-scale RINA Experimentation on FIRE+ 3

• Different access technologies use a dedicated aggregation and backbone

network segments, resulting in a poor utilization of the infrastructure.

• Users will have different subscriber profiles (mobile vs. fix).

• The provider must deploy duplicated service platforms (mobile vs. fix).

• Challenging service continuity when transitioning between type of access

• Management and deployment of new services cumbersome

A CON vision..

• Any access media, any application requirement

supported by a common network infrastructure

• Single architecture, single management system, single

users database (regardless of access)

4

Manage users and sessions, Local managed services

Capillarity, Capacity, Mobility support

Multiplexing Switching, Transport

Control functions, Regional managed services

Devices

Places

Users Access Aggregation Local Points of Presence Core Regional Data Centres

Radio

Fiber


The all-IP approach

Current protocol stack limitations

5

xDSL FTTH WiFi 4G

Building a CON today…

6

National DC Regional

DC(s)

Metropolitan

aggregation (Carrier Eth, MPLS, …)

Metropolitan

aggregation

… …

Metro

DC

Metro

DC

Access

Internet Border

Private peering with other operators , or Internet transit

To Internet eXchange Point (IXP)

IP eXchange border To IPX network (IMS traffic)

micro

DC

Metropolitan


Metropolitan

aggregation

Metropolitan


Metropolitan

aggregation

Metropolitan


• Micro DC: Mobile-edge computing, C-RAN

• Metro DC/Regional/National DCs: (functions splitted according desired degree of distribution by provider). Service platforms (DNS, SMTP, etc.), LTE EPC (S-GW, P-GW, MME), IMS, cloud hosting, user accounts, billing, NOC, etc.

Core/backbone

IP/MPLS

Are “All IP networks” fit for this purpose?

• Computer networking & telecom industry has been

steadily moving towards an “all IP” world.

– Is “all-IP convergence” a simple, scalable, robust,

manageable, performing and future-proof solution for all

types of computer networks?

• Could be if

– The “IP protocol suite” had been designed with generality in

mind, allowing its protocols to adapt to specific network

environments

– The “IP protocol suite” is well know for having no scalability,

performance or security issues

7

1

2 1

4 2


The RINA approach

And its benefits

8

There is a better approach: RINA

• 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 recursion, ease management

• All layers provide the same service: instances of communication (flows) to two or more application instances, with certain characteristics (delay, loss, in-order-delivery, etc) programmability, limited number of protocols + policies

• 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

9

1

2

3

4

5

6

“IP protocol suite” macro-structure

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

Network management Commonality is the key to effective network management

11

• 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

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

Naming and addressing, mobility, routing No need for special protocols

12

Name Indicates Property RINA IP

Application name What Location independent Yes No

Node address Where Location dependent, route independent

Yes No

Point of Attachment

How to get there

Route dependent Yes Yes (twice: IP, MAC)

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

No application names, addresses exposed to applications, well-known ports

Deployment Clean-slate concepts but incremental deployment

14

• 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 Applications RINA supported Applications

IP or Ethernet or MPLS, etc

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 (from 1998) (P1520 distinguished between virtual devices and hardware)

15

ONF‘s SDN architecture

Separation of mechanism from policy

16

IPC API


SDU Delimiting

Data Transfer


SDU Protection


Flow Control

RIB Daemon

RIB

CDAP Parser/Generator

CACEP

Enrollment

Flow Allocation

Resource Allocation

Routing

Authentication

State V

ecto

r State

Ve

ctor

State V

ecto

r




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


From all-IP to RINA

Examples exploiting recursion

17

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

24

Green Customer VPN DIF

Provider VPN Service DIF

Metro DIF Metro DIF Core DIF

PtP DIF PtP DIF PtP DIF PtP DIF

PtP DIF PtP DIF PtP DIF PtP DIF PtP DIF PtP DIF PtP DIF

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.

31

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 . . . L1 UE

eNodeB S-GW P-GW

EPS bearer EPS 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

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. 36

ToR ToR Fabric Spine Fabric

Server Server IPv4 or IPv6 (Fabric layer)

UDP VM VM

Ethernet Ethernet Ethernet Ethernet

VXLAN 802.1Q 802.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


DC Fabric DIF

Tenant DIF


A Service Provider Network design with RINA

37

Service provider, RINA, Internet (e-mall), wired Access

Access router

PtP DIF

CPE

Edge Service

Router

MAN P.E MAN P. E.

MAN Access DIF

MAN Core DIF PtP DIF PtP DIF

PtP DIF PtP DIF

MAN P

PtP DIF

Host Core Backbone DIF

PtP DIF

Core router Core router e-mall Access

Router

E-mall Border

Router

Customer network Service Prov. 1 network

Access Aggregation Service Edge Core Internet Edge

Internet ( e-mall) eXchange Point

Core PoP, city B Core PoP, city A

City A MAN City A Cabinets

PtP DIF PtP DIF PtP DIF

Service Provider Top Level DIF

E-mall 1 DIF

PtP DIF

E-mall 2 DIF

Service provider, RINA, Internet (e-mall) wireless Access

Access router

PtP DIF

Cell Tower (eNodeB)

Mobile Edge Service

Router

MAN P.E MAN P. E.

MAN Access DIF

MAN Core DIF PtP DIF

PtP DIF

PtP DIF PtP DIF

MAN P

Cell DIF

Mobile Host

(or border router)

Core Backbone DIF

PtP DIF

Core router Core router e-mall Access

Router

E-mall Border

Router

Service Prov. 1 network

Access Aggregation Service Edge Core Internet Edge

PtP DIF PtP DIF PtP DIF

Service Provider Top Level DIF

E-mall 1 DIF

PtP DIF

E-mall 2 DIF

Mobile Access DIF

Internet ( e-mall) eXchange Point

Core PoP, city B Core PoP, city A

City A MAN City A Cabinets

Cell sites

Example mobile network with RINA Better design

40

Border Router

Core DIF

Under DIFs

Border Router

Under DIFs

Border Router

Interior Router (Base Station)

Host (Mobile)

BD DIF (radio)

Under DIFs

District DIF

Metro DIF

Regional DIF

Public Internet DIF

Application-specific DIF

Mobile Infrastructure Network Customer Terminal

…

…

…

• In this example “e-mall” DIFs (providing access to applications) are available via the regional DIF, but could be available also through metro or district DIFs

– Essentially, every border router can be a “mobility anchor”, no need to do anything special.

Under DIFs

Operator core

Example with 4 levels (where needed)

41

Urban Sub-urban Urban Urban Dense Urban

BS DIF District DIF Legend Metro DIF Regional DIF

• 4 levels of DIFs may not be needed everywhere (e.g. suburban, not enough density to require a district DIF).

• If more levels needed to scale can be added anywhere in the network


Thank you!

42


Backup slides

43

RINA macro-structure (layers) Single type of layer, consistent API, programmable policies

44

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


SDU Delimiting

Data Transfer


SDU Protection


Flow Control

RIB Daemon

RIB


CACEP

Enrollment

Flow Allocation

Resource Allocation

Routing

Authentication

State V

ecto

r State

Ve

ctor

State V

ecto

r




Flow Control Flow Control

Increasing timescale (functions performed less often) and complexity


Security Management

Radio Access DIF and District DIF Example connectivity graphs

Multi-homed host

BR

BS

H H H

BS

H

Metro DIF

Metro DIF

Metro DIF

BR

BS

H H H

BS

H

Metro DIF

Metro DIF

Metro DIF

Multi-homed host

Metro DIF

Metro DIF

Metro DIF

District DIF 1 District DIF 2

Cell DIF Cell DIF

Cell DIF Cell DIF

DISTRICT DIF

BS = IPCP at Base Station H = IPCP at Host

BR = IPCP at Border Router

BS

H

BS

H H H

H

Cell DIF 1 (radio) Cell DIF 2

(radio)

District DIF

District DIF

District DIF

District DIF

District DIF

District DIF

CELL DIF

BS = IPCP at Base Station H = IPCP at Host

45

E-mall DIF

Metro DIF and Regional DIF Example connectivity graphs

METRO DIF

H = IPCP at Host BR = IPCP at Border Router

H H H H H

BR

H H H H H

BR

Multi-homed host

Reg. DIF

H H H H

H

BR

H

District DIF

District DIF

District DIF

BR

Regional DIF

H

H H H H H H H H H H H H H H H H H H H H H H H H H H H

Metro DIF

BR

H H H H H H H H H H H H H H H H H H H H H H H H H

Metro DIF

BR

BR

Metro DIF (fixed)

Public Internet DIF REGIONAL DIF

H = IPCP at Host

BR = IPCP at Border Router

46

Securing RINA networks

Tutorial 1: RINA: a future--proof approach towards re-architecting the infocomms protocol stack

supporting Cloud, IoT and beyond 5G requirements Securing RINA networks

Miquel Tarzan (presenter), Eduard Grasa, Ondrej Lichtner, Ondrej Rysavy, Hamid Asgari, John Day, Lou Chitkushev

FP7 PRISTINE EuCNC 2016, Athens, June 27th 2016

Recursive InterNetwork Architecture (layers, IPC processes, functions)

2

Protecting layers instead of protocols All layers have the same consistent, security model

3

•  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 (BGPsec, DNSsec, IPsec, TLS, etc.), 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’

Opera&ngontheIPCP’sRIB

Accesscontrol

Sending/receivingPDUsthroughN-1DIF

Confiden.ality,integrity

NDIF

N-1DIF

IPCProcess

IPCProcess

IPCProcess

IPCProcess JoiningaDIF

authen.ca.on,accesscontrol

Sending/receivingPDUsthroughNDIF


Opera&ngontheIPCP’sRIB

Accesscontrol

IPCProcess

Appl.Process

Accesscontrol(DIFmembers)


Authen.ca.on

AccesscontrolOpera.onsonRIB

DIFOpera&onLogging

DIFOpera&onLogging


4

IPCAPI

DataTransfer DataTransferControl LayerManagement

SDUDelimi&ng

DataTransfer

RelayingandMul&plexing

SDUProtec&on

RetransmissionControl

FlowControl

RIBDaemon

RIB

CDAPParser/Generator

CACEP

Enrollment

FlowAlloca&on

ResourceAlloca&on

Rou&ng

Authen&ca&on

StateVectorStateVectorStateVector

DataTransferDataTransfer



FlowControlFlowControl

NamespaceManagement

SecurityManagement

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

Authen.ca.on

Accesscontrol(layermgmtopera.ons)

Accesscontrol(joiningtheDIF)

Coordina.onofsecurityfunc.ons

Confiden.ality,Integrity


5

IPCAPI


SDUDelimi&ng

DataTransfer


SDUProtec&on


FlowControl

RIBDaemon

RIB


CACEP

Enrollment

FlowAlloca&on

ResourceAlloca&on

Rou&ng

Authen&ca&on






NamespaceManagement

SecurityManagement

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

Authen.ca.on



Coordina.onofsecurityfunc.ons

Confiden.ality,Integrity

Source:J.Smallmasterthesis

Decoupling Port Allocation and Synchronization

© John Day, 2014 Rights Reserved

IPCP1PA

AppA

Port-id

read/write 1

EFCPinstance,cep-id

8736

IPCP3PA

AppB

Port-id

read/write

4

EFCPinstance,cep-id

9123

Synchroniza9on

•  SYN-Ack Attack: must guess which of 2^16 CEP-id.•  Data Transfer: must guess CEP-id and seq num within window!•  Reassembly attack: Reassembly only done once.•  No well-known ports to scan.

Alloca9on

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

7

IPCPPA

AppA

Port-id

read/write 1

EFCPinstance,cep-id

8736

IPCPPA

AppB

Port-id

read/write

4

EFCPinstance,cep-id

9123

Synchroniza9on

•  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/IPIP@:12

Portread/write 12

TCPinstance,port

12

IP@:78

Portread/write

78

TCPinstance,port

78

TCPPMA

TCPPMA

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

8

Internet(TCP/IP) RINA

Defaultmodel Globalconnec*vity Controlledconnec*vity

Controlscopevia Firewalls,ACLs,VLANs,VirtualPrivateNetworks,etc..

Scopena*veconceptinarchitecture(DIF)

Example:Provider’snetworkinternallayershiddenfromcustomersandotherproviders

Enrollment

(N-1)-DIF

(N)-DIF

A

•  Nothing more than Applications establishing communication–  Authenticating that A is a valid member of the (N)-DIF–  Initializing it with the current information on the DIF –  Assigning it a synonym to facilitate finding IPC Processes in the DIF, i.e. an address


Connection Establishment

A BA B

–  A asks IPC to allocate communication resources to B–  Keep looking until we find an entry for it.–  Then go see if it is really there and whether we have access.–  Then tell A the result.

•  Advantages.–  We can enforce access control –  If B has moved, we find out and keep searching


CDAP + Access control for layer management

•  There’s only one application protocol, CDAP •  How layers can be managed?

–  Access control and operations applied to objects in the RIB

•  With access control, just one protocol suffices –  No need for one protocol for each function (routing, …)

11

IPCAPI


SDUDelimi&ng

DataTransfer


SDUProtec&on


FlowControl

RIBDaemon

RIB


CACEP

Enrollment

FlowAlloca&on

ResourceAlloca&on

Rou&ng

Authen&ca&on






NamespaceManagement

SecurityManagement



Customernetwork

InteriorRouter

CustomerBorderRouter

InteriorRouter Border

Router

P2P DIF

InteriorRouter

P2P DIF

BorderRouter

P2P DIF P2P DIF

InteriorRouter

BorderRouter

Provider1BackboneDIF

P2P DIF

BorderRouter

Provider1RegionalDIF

Mul&-providerDIF

P2P DIF

AccessDIF

P2P DIF P2P DIF

Provider1network

Provider2network

IPCPA

IPCPB

IPCPC

P2P DIF P2P DIF

IPCPD

•  DIFs are securable containers, strength of authentication and SDU Protection policies depends on its operational environment

•  DIFs shared between provider/customer (blue DIF) may require strong authentication and encryption, specially if operating over wireless (red DIF)

•  DIFs internal to a provider may do with no auth.: accessing the DIF requires physically compromising the provider’s assets (green and orange DIFs).

BorderRouter

Authentication and SDU protection policies

Authentication policy: SSH2-based (I)

•  Once applications (including IPCPs) have a flow allocated, go through application connection establishment phase –  Negotiate app protocol (CDAP) version, RIB version, authenticate

•  Specified authentication policy based on SSH2 authentication (uses per IPCP public/private RSA key pairs), adapted to the RINA environment

13

Authentication policy: SSH2-based (II)

14

Crypto SDU protection policy

•  Crypto policy that encrypts/decrypts PCI and payload of EFCP PDUs –  In general SDU protection is used by a DIF to protect its own data

(PCIs of data transfer PDUs and full layer management PDUs)

•  Not assuming N-1 DIF will provide reliable and in-order-delivery -> using counter mode (as in IPsec) –  AES128 and AES256 as supported encryption algorithms

•  HMAC code to protect integrity of PDU –  SHA256 chosen as hash algorithm

15

12

IPCPPA

IPCPPA

N-1flow

SDUProtec9on

SDUProtec9oncounter Encrypteddata HMAC

Experimentation with IRATI

16

ProviderBorderRouter1

ProviderBorderRouter2

CustomerBorderRouter

ShimDIFoverEth ShimDIFoverEth

IPCPA

IPCPB

access.DIF IPCPC

IPCPD

regional.DIF

IPCPE

IPCPF

IPCPG

mul9-provider.DIF

Customernetwork

Providernetwork

•  IRATI is an open source, programmable implementation of RINA for Linux, written in C/C++

•  Implemented plugins with authSSH2 auth. and SDU protection policies

17

Ques*ons?

RINASim● Vladimír Veselý

● Brno University of Technology, Czech Republic

● [email protected]

@ictpristine Athens, 27th June 2016 1

mailto:[email protected]

Agenda

Introduction

OMNeT++ Handbook

Component overview

Interactive Demo



Introduction

How to install?Where to get it?Documentation and useful links.

Requirements

OMNeT++ discrete event simulator

Windows, Linux, FreeBSD environment

Free for non-commercial purposes

Supported by versions 4.4, 4.5, 4.6

work in progress on 5.0

C++ for implementation, NED for description

C++11 with gcc 4.9.2

No other libraries or frameworks needed

Potential cooperation with INET framework


Installation

Out-of-the box

VM (http://nes.fit.vutbr.cz/ivesely/vm/RINASim.zip)

Windows

1) Download OMNeT++http://www.omnetpp.org/omnetpp

2) ./configure && makehttp://omnetpp.org/doc/omnetpp/InstallGuide.pdf

3) Download RINASimhttps://github.com/kvetak/RINA/archive/master.zip

4) Import RINASim project


http://nes.fit.vutbr.cz/ivesely/vm/RINASim.zip

http://www.omnetpp.org/omnetpp

http://omnetpp.org/doc/omnetpp/InstallGuide.pdf

https://github.com/kvetak/RINA/archive/master.zip

Navigation /src

/Common

/CS

/DAF

/DIF

/policies

/examples

/playground

… RINASim core source codes

… common or shared ADTs

… high-level nodes

… DAF components

… DIF components

… programmable set of policies

… accompanied scenarios

… unmainted/experimental scenarios


Documentation

Doxygen

http://nes.fit.vutbr.cz/ivesely/doxy

Important ADTs, ongoing work

PRISTINE D2.4 and D2.6

http://ict-pristine.eu/?p=472


Skype group chat

skype:?chat&blob=-bdq6qH_uDXIlbRk_4_XwqZyplfXPl4IzCq4P-S0BrsttjgPR8CNJKV9-Yyn1TYopaYZD2g3bIC_Yv0C


http://nes.fit.vutbr.cz/ivesely/doxy



skype:?chat&blob=-bdq6qH_uDXIlbRk_4_XwqZyplfXPl4IzCq4P-S0BrsttjgPR8CNJKV9-Yyn1TYopaYZD2g3bIC_Yv0C


OMNeT++ Handbook

The fast and the furios basic 101 introductorycourse about OMNeT++

Simulation Module

Modules

Gates (input, output, inout), messages


Languages

NED

to define models and interconnections

*.ned

C++

to implement model behavior

*.h and *.cc

Message definition

to deploy easily C++ message classes

*.msg


Module’s Hierarchy

Simple

Compound

Network


IDE


Simulation


Scheduledmessages

Componentparameters

Console log

Detachedgraphical

component detail

Control buttons


RINASim Overview

Components and their purpose

Design

Split between mechanism and policy

Interface like modules

Simulations allow changing of parameters

Statically preconfigured

NED parameters in omnetpp.ini

config.xml

On-the-fly


Computation Systems ①


Computation Systems ②

Hosts and Routers


DAF Components

Application Process

contains AE(s)

manages DAF enrollment

data and mgmt flows


DAF Components

IPC Resource Manager

interconnects APs with IPCs

passes messages fromapplications to DIFs

DIF Allocator

Maintains naming and addressing info

Knows how AP/IPCP is reachable via which IPCP


Common Distributed App Protocol

Simulation module used by AE and RIBd

CDAP

Sends/Receives CDAP messages

CDAPSplitter

Delegates CDAP message to appropriate module

CDAPMsgLog

Statistic collector

CACE + AUTH

Used by Enrollment or during authentication phase


TCP/IP vs. RINA


IPC Process


Flow Allocator

Manages flow lifecycle

FA Core functionality

FAI_portId_cepId Instance

NFlowTable Information about all (N)-DIF

flows

NewFlowRequestPolicy Score or Min compare

AllocateRetryPolicy Upon treshold reach

QoSComparerPolicy For multi QoSCube routing

purposes



EFCP

Manages EFCP instances

EFCPTable

Table of known EFCPIs

Delimiting_portId

Creates SDUs from incoming PDUs

EFCPI_cepId

Provides DTP and DTCP services

MockEFCPI

Provides unreliable communication for IPCP management messages

Simple en/decapsulater between SDUs and PDUs


EFCP Instance

DTP Actual Data Transfer

DTCP Handles Flow Control and

Retransmission


DTPState Holds all DTP related variables

DTCPState Holds all DTCP related variables

EFCP policies Triggered during various DTP states

RIB Daemon

Generates / Processes IPCP management messages

Main IPCP’s AE

RIBd Core functionality

CDAP Socket-like message

sender/receiver

Notifiers FA, Routing, Enrollment hooks

to RIBd

RIBdSplitter Passes CDAP msgs to/from

appropriate EFCPI


Resource Allocator Provides access to

(N-1)-DIFs and their resources

RA

Core functionality

Manages IPCP’s QoSCubes

NM1FlowTable

Information about current (N-1)-flows

PDUFwdGenerator

Forwarding information management

QueueAllocPolicy

How and when should RMT queues be

allocated?

QueueIdGenerator

In which RMT queue should a PDU be

stored?

AddressComparator

Syntax and comparison of addresses


Relaying and Multiplexing Task Relays incoming/outgoing PDUs to their proper destination (either an EFCP

instance or an (N-1)-flow)

RMT The core PDU forwarder

SchedulingPolicy When a PDU needs to be sent/received, which queue should it be taken from?

QueueMonitorPolicy Keeping information about port/queue states

MaxQueuePolicy What should happen to a queue when it overflows?

PDUForwardingPolicy Where should be PDU relayed based on a given header?


Routing

The policy computing optimal paths to other destinations by given metrics

Usually some sort of routing algorithm exchanging information with other members of a DIF



Interactive Demo

How IPC works between two hosts interconnected to a common node?

HostA Switch HostB

HostA HostBSwitch

Topology


Cookbook

Topology

2× host with single AP

1× interior router

2× datarate channel between

Task

1) Setup network

2) Schedule simulation

3) Run

Goal

To observe IPC between two hosts interconnected by a interior router


HostA HostBSwitch

1) Setup network

Create new simulation in folderexamples/Athens/Demo


1) Setup network

Open Demo.ned and add two Host1AP onto canvas and one InteriorRouter2Int

Rename them with F6

Connect them with DatarateChannel


1) Setup network

Change DatarateChannel properties

Setup delay, ber, datarate


1) Setup network

Copy config.xmlfrom examples/Demos/UseCase4/config.xml


2) Schedule simulation

Assign addresses

Bind config.xml

Schedule AEMyPing


3) Run


Notable Events

t=5

hostA enrolls to Layer01 and Layer11

t=10

hostA creats flows for AP communication

t=15

SourceA and DestinationB apps exchange ping messages

t=20

hostA deallocates Layer11 flow


Conclusion

RINASim

Educational tool

A way how to visualize what is happening in the nativeRINA network

Helping to improve learning curve

Research tool

http://ict-pristine.eu/?page_id=35


http://ict-pristine.eu/?page_id=35

RINASim● Comments?

Questions?Suggestions?


The IRATI stackA programmable RINA implementation for Linux/OS

27th June 2016Vincenzo Maffione, Nextworks

Pre-IRATI prototypes implementing RINA● ProtoRINA (https://github.com/ProtoRINA/users/wiki)● Alba (closed source)

High level design choices:

● Focus on validation of the architecture● Completely user-space implementations → written in Java● No direct access to Network Interfaces Cards (NICs) → only run over sockets

Consequences:

● Limited deployability for real world scenarios● Limited performance

https://github.com/ProtoRINA/users/wiki

DIF components for a complete RINA stack

IPCProcess

IPC API


SDU Delimiting

Data Transfer


SDU Protection


Flow Control

RIB Daemon

RIB


CACEP

Enrollment

Flow Allocation

Resource Allocation

Routing

Authentication

State Vecto

rState V

ector

State Vecto

r




Flow ControlFlow Control


Security Management

Increasing timescale (functions performed less often)

System (Host)

About IPC ProcessesThere are two categories:

● Normal IPC Processes○ Have RINA-compatible Northbound/Southbound

interfaces○ Implement all the DIF functionalities

● Shim IPC Processes○ Have a RINA-compatible Northbound interface

■ The IPC API○ Wrap the legacy transport technology they lay over

■ Ethernet (802.1q)■ TCP/IP■ Hypervisor shared-memory mechanisms

Shim IPC Process

(Normal) IPC Process

(Normal) IPC Process

0

1

2

Hardware

The IRATI stackOpen source RINA implementation for Linux OS, available at https://github.com/irati/stack.

Developed in 2013-2014 within the FP7-IRATI project, with the following goals:

● Implementation for a UNIX-like OS of all the basic DIF functionalities (Flow allocation, Enrollment, Routing, Data Transfer, Data Transfer Control, etc.) from scratch

● Support to run over Ethernet (802.1q)● Support to run inside Virtual Machines, using I/O paravirtualization● Support to run over the TCP/IP traditional network stack (through socket API)● Provide a solid baseline for further RINA research work

https://github.com/irati/stack

IRATI functionalities splitting (2)Split user-space functionalities in different daemon processes:

● A separate IPC Process Daemon to implement layer management functionalities of each IPC Process

● An IPC Manager Daemon to coordinate layer management among applications and IPC Process daemons

Rationale: each process in a different container → more reliable solution, minimize interferences in case of problems

IPC ProcessDaemon

IPC ProcessDaemon

N

UserKernel

Application

1

IPC ManagerDaemon

Application

Kernel

IPC ProcessDaemon

Application

N

Communication among componentsTwo mechanisms:

● System calls:○ Bootstrapping: create/destroy the kernel-path IPC Processes○ Used by applications and IPC Process Daemons to send and

receive SDUs (data-path)○ User-space-originated

● Netlink:○ A bus-like mechanism for IPC○ A linux-standard for applications controlling the network stack○ Control messages exchanged between

■ Applications ← → IPC Manager■ IPC Manager ← → IPC Process Daemons■ IPC Process Daemons ← → kernel

○ Messages are originated by user-space or kernel-space

netlink

IPC ProcessDaemon

IPC ProcessDaemon

N

UserKernel

Application

1

IPC ManagerDaemon

Application

Kernel

IPC ProcessDaemon

Application

N

IRATI design decisions

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, Performance Less portability

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

Core

Normal IPC Process datapath

IRATI kernel-space architecture (1)KIPCM → Manages the syscalls:

● IPCP management:○ ipc_create

○ ipc_destroy

● Flows management:○ allocate_port

○ deallocate_port

● SDUs I/O (fast-path):○ sdu_read

○ sdu_write

○ mgmt_sdu_read

○ mgmt_sdu_write

API Mux/Demux

Kernel IPC Manager

IPCP Factories

Kernel Flow Allocator

EFCP

RelayingMultiplexing

Task

PDU forwarding

function

Netlink support

Netlink, syscalls

User space

Shim over802.1q

RINA-ARPShim over

Hypervisors

kernel

Shim over TCP/UDP

SDU protection

Core


IRATI kernel-space architecture (2)Netlink support:

● Abstracts message’s reception, sending, parsing & crafting

● 40+ message types (control-path):

○ assign_to_dif_req

○ assign_to_dif_resp

○ register_app

○ unregister_app

○ ...

API Mux/Demux

Kernel IPC Manager

IPCP Factories


EFCP


Task

PDU forwarding

function

Netlink support

Netlink, syscalls

User space

Shim over802.1q

RINA-ARPShim over

Hypervisors

kernel

Shim over TCP/UDP

SDU protection

Core


IRATI kernel-space architecture (3)KIPCM:

● Counterpart of the IPC Manager● Manages the lifecycle the IPC

Processes and KFA○ ipcp-id → ipcp-instance

● Same API for all the IPC Processes regardless the type → abstraction

KFA:

● Counterpart of the Flow Allocator● Manages ports and flows

○ port-id → ipcp-instance

API Mux/Demux

Kernel IPC Manager

IPCP Factories


EFCP


Task

PDU forwarding

function

Netlink support

Netlink, syscalls

User space

Shim over802.1q

RINA-ARPShim over

Hypervisors

kernel

Shim over TCP/UDP

SDU protection

Kernel IPC Process factoriesDifferent IPC Process types:

● The Northbound interface is the same● Each IPC Process implements its “core” code:

● Shim IPC Processes:● Each type provides a different implementation

● Normal IPC Processes:● A programmable implementation for all of them

IPC Process factories:● Abstract factory design pattern● Used by IPC Processes modules to publish/unpublish their availability into the system

IPC Process kernel API

● The IPC Process kernel API is the same for all IPC Processes● Each type decides which operations will support● Some are specific for normal or shims, others are common to both

● .connection_create = normal_ connection_create

● . connection_update = normal _ connection_update

● . connection_destroy = normal _ connection_destroy

● .connection_create_arrived = normal _connection_arrived

● .pft_add = normal_pft_add

● . pft_remove = normal_pft_remove

● . pft_dump = normal_pft_dump

● .application_register = shim_application_register

● .application_unregister = shim_application_unregister

● .assign_to_dif = shim_assign_to_dif

● .sdu_write = shim_sdu_write

● .flow_allocate_request = shim_allocate_request

● .flow_allocate_response = shim_allocate_response

● .flow_deallocate = shim_deallocate

ipcp_ops →

The kernel normal IPC Process (1)Contains an EFCP container and a Relaying and Multiplexing Task

EFCP Container

● Multiple EFCP instances (one per connection)● Mux/Demux among EFCP instances

● EFCP instance:

○ Implements Watson’s Delta-T○ Data Transfer Protocol○ Data Transfer Control Protocol

■ Retransmission → RTX queue■ Flow control → Closed Window queue

○ State Vector for DTP and DTCP to interact

EFCP-C

EFCP-I

EFCP-I

EFCP-I

DTP

SV

DTCP

IPC Process API interface

Relaying Multiplexing Task (RMT)

The kernel normal IPC Process (2)Contains an EFCP container and a Relaying and Multiplexing Task

RMT

● Ingress queues○ For packets arriving from N-1 flows

● Egress queues○ For packets to be transmitted to N-1 flows

● Schedules transmission among queues○ Scheduling algorithm is policy → programmability

● Accesses the PDU Forwarding Table (PFT)○ Locally generated (EFCP-I) packets○ Foreign packets to be forwarded

EFCP-C

EFCP-I

EFCP-I

EFCP-I

DTP

SV

DTCP

IPC Process API interface

Relaying Multiplexing Task (RMT)

IRATI Shim IPC Processes● Implemented entirely in kernel-space → easy access to I/O devices● Lowest part of the IRATI stack --> They wrap a legacy transport technology● Currently 3 shims available:

● shim-eth-vlan:● Runs over 802.1Q (Ethernet with VLAN tagging)

● shim-hv:● Targets hypervisor-based environments (QEMU-KVM and Xen)● Allows removing unnecessary layering commonly used in traditional VM networking environments (e.g.

software bridges, virtual-NICs), with two advantages:● Increased performances● Reduced maintenance costs

● shim-tcp-udp● Runs RINA over traditional TCP or UDP sockets● Allows for interoperability over existing IP networks.

Shim-eth-vlan architecture

User-space

Kernel KIPCM / KFA

Shim IPC Process over 802.1Q

Devices layer

RINARP

rinarp_add rinarp_remove

rinarp_resolve

dev_queue_xmit

RINA IPC API

IPC Process Daemon

IPC Manager Daemon

shim_eth_rcv

shim_eth_destroyshim_eth_create

Normal IPC Process - instance

Normal IPC Process - instanceNormal IPC Process - instance

EFCP Container - instance

EFCP Instance

RMT - instance

PDU-FWD-T

Core O

IShim IPC Process

instance

Normal IPC Process - instance

EFCP Container - instance

EFCP Instance

RMT - instance

PDU-FWD-T

Core

IO

Shim IPC Processinstance

KIPCM / KFA

User space

User space

QueueQueue

Queue

QueueQueue

Queue

DTP DTCP

DT

DTP DTCP

DT

KIPCM / KFA

Packet workflow example

Legacy technology

Legacy technology

TX

RX

librina: the IRATI user-space library● Completely abstracts the interactions with the kernel

○ syscalls and netlink● Provides functionalities to applications and IRATI daemons● More a middleware than a library

○ Explicit memory allocation → no garbage collection○ Event-based○ Multi-threaded○ Built from scratch in C++ → STL only○ Design patterns → singletons, observers, factories, reactors○ Concurrency → threads, mutexes, semaphores, condition variables

librina architecture

API (C++)

Core (C++)

libnl/libnl-gen

Kernel

Perform action

Netlink Manager Netlink Message Parsers / Formatters

Message classes

Message classes

Messageclasses

Syscall wrappers

Message reader Thread

Message classes

Message classes

Proxy classes

Message classes

Message classes

Model classes

Message classes

Message classes

Event classes

libpthread

Concurrencyclasses

Logging framework

Events queue

Event Producer

User space

Get event

IRATI user-space architecture (2)● IPC Manager Daemon

● Manages the IPC Processes lifecycle● Broker between applications and IPC Processes● Local management agent, to interact with a remote DIF Management System● DIF Allocator client to search for applications - possibly not available through local DIFs

Kernel

User space

Netlinksockets

Normal IPC Process (Layer Management)Application C

RIB & RIB Daemon

librina

Resource allocation

Flow allocation

Enrollment

PDU Forwarding Table Generation

Application B

System calls Netlinksockets

Sysfs

IPC Manager

RIB & RIB Daemon

librina

Management agent

DIF Allocator

Main logic

System calls

Netlinksockets

SysfsApplication A

librina

Application logic

System calls Netlink

sockets

IRATI user-space architecture (3)

Kernel

User space

Netlinksockets

Normal IPC Process (Layer Management)Application C

RIB & RIB Daemon

librina

Resource allocation

Flow allocation

Enrollment

PDU Forwarding Table Generation

Application B

System calls Netlinksockets

Sysfs

IPC Manager

RIB & RIB Daemon

librina

Management agent

DIF Allocator

Main logic

System calls

Netlinksockets

SysfsApplication A

librina

Application logic

System calls Netlink

sockets

● IPC Process Daemon● Layer Management components (RIB Daemon, RIB, CDAP parsers/generators, CACEP, Enrollment, Flow

Allocation, Resource Allocation, Routing, PDU Forwarding Table Generation, Security Management)

IPC Manager DaemonIPC Manager Daemon (C++)

LibrinaIPC Process

FactoryIPC Process

Message classes

Message classes

Event classes

Event Producer

Message classes

Message classes

Model classes

System calls Netlink Messages

Console thread

local TCP Connection

Main event loop

EventProducer.eventWait()

IPC Manager core classes

IPC Process Manager

Flow ManagerApplication Registration

Manager

Call IPC Process Factory, IPC Process or Application Manager

Call operation on IPC Manager core classes

Application Manager

CLI Session

Message classes

Message classes

Consoleclasses

Operation result

Bootstrapper

Configuration fileCall operation on IPC Manager core classes

Message classes

Message classes

Configuration

classes

IPC Process DaemonIPC Process Daemon (C++)

librina (C++)IPC Manager

KernelIPC Process

Message classes

Message classes

Event classes

Event Producer

Message classes

Message classes

Model classes

System calls Netlink Messages

CDAP Message reader Thread

KernelIPCProcess.readMgmtSDU()

RIB Daemon

Resource Information Base

(RIB)

RIBDaemon.cdapMessageReceived()

Main event loop

EventProducer.eventWait()

Supporting classes

Delimiter EncoderCDAP parser

Layer Management function classes

Enrollment Task Flow Allocator

Resource Allocator

Forwarding Table

Generator

Registration Manager

Call IPCManager or KernelIPCProcess

RIBDaemon.sendCDAPMessage()

KernelIPCProcess.writeMgmtSDU()

Example workflow: Flow allocationAn application requests a flow to another application, without specifying what DIF to use

Application A

Kernel

User space

IPC Manager Daemon

IPC Process Daemon

1. Allocate Flow Request (NL)

2. Check app permissions

3. Decide what DIF to use

4. Forward request to adequate IPC Process Daemon

5. Allocate Flow Request (NL)

6. Request port-id (syscall)

7. Create connection request (NL)

8. On create connection response (NL), write CDAP message to N-1 port (syscall)

9. On getting an incoming CDAP message response (syscall), update connection (NL)

10. On getting update connection response (NL) reply to IPC Manager (NL)

11. Allocate Flow Request Result (NL)

12. Forward response to app

13. Allocate Flow Request Result (NL)

14. Read data from the flow (syscall) or write data to the flow (syscall)

Extending IRATI for programmability● Original IRATI stack had hardwired policies

● FP7-PRISTINE extends IRATI with a Software Development Kit (SDK)

○ Allows extension modules to be plugged in/out at run-time → Dynamic code loading

○ Define public APIs for each component of the normal IPC Process

■ To be used by plugins

○ SDK is implemented by the RINA Plugin Infrastructure (RPI):

■ User-space RPI (uRPI) to manage plugins for user-space components

■ Kernel-space RPI (kRPI) to manage plugins for kernel-space components

○ IPC Manager Daemon holds the catalog of plugins/policies installed on the system

● Added management agent subsystem in the IPC Manager daemon○ Allow management actions from remote DIF Management System

Policy-set concept● Policy-set = The set of all policies defined on a single component of the software

architecture○ A different policy set for each DIF component○ Rationale: different “behavioural” policies in the same component can cooperate (share state)

in a plugin-specific way.

● Two types of policies (software-wise):○ parameters, e.g. A-timer value for DTCP, MaxQLength for RMT queues○ behaviours, e.g. SchedulingPolicy for RMT, NewFlowAccessControl for the Security Manager

IRATI with programmability supportNormal IPCP(Data transfer)



SDU Protection

. . .

Normal IPCP(Layer Mgmt)

RIB & RIB Daemon

librina

Resource allocation

Flow allocation

Enrollment


Security Management

Routing

Ad

dre

ss

assi

gnm

ent

po

licy

Dir

ecto

ry

rep

licat

ion

po

licy

Ad

dre

ss v

alid

atio

n

po

licy

Enrollment sequence policy

Routing policy

TTL

po

licy

CR

C p

olic

y

Encr

ypti

on

po

licy

Forw

ard

ing

po

licy

Sch

edu

ling

po

licy

Max

Qp

olic

y

Mo

nit

ori

ng

po

licyNew flow policy

PFT

gen

erat

ion

p

olic

y

Push

bac

k n

oti

fy

po

licy

RTT

co

mp

uta

tio

n

po

licy

Tran

smis

sio

n c

on

tro

l p

olic

y

ECN

po

licy

Au

then

tica

tio

n p

olic

y

Acc

ou

nti

ng

con

tro

l p

olic

y

Co

ord

inat

ion

co

ntr

ol

po

licy

RINA kernel-space plugin infrastructure (kRPI)● Plugins are Loadable Kernel Modules (LKM)

○ They publish a list of policy-sets, which are made available to the IRATI stack.● Factories, named after each policy set, provide operations to create/delete instances of policy set classes

● Different policy-set class per component, since each component has different policies.

● “OO” approach○ All policy set classes derive from a base class○ All components derive from a base class

RINA user-space plugin infrastructure (uRPI)● Same concepts as kRPI (factories, lifecycle, policy classes), different implementation

● Plugins are shared objects dynamically loaded by the IPCP Daemon, loaded through the libdl library

Code status● Sources are partitioned into four different packages

○ rinad: provides the IPC Process & IPC Manager daemons (user-space parts)■ Depends on librina

○ rina-tools: provides the rina-echo-time application■ Depends on librina

○ librina: user-space libraries■ Depends on the IRATI modified Linux kernel

○ linux: the Linux sources enhanced with RINA functionalities (kernel-space parts)■ Sources almost confined in net/rina, to allow easier upgrades

● Build systems for librina, rinad and rina-tools is based on autotools

Thanks

librina sublibraries● librina-application

○ Provides the APIs that allow an application to use RINA natively■ allocate and deallocate flows■ read and write SDUs to that flows■ register/unregister to one or more DIFs

● librina-ipc-manager○ Provides the APIs that facilitate the IPC Manager to perform the tasks related to IPC Process management

■ creation, deletion and configuration of IPC Processes● librina-ipc-process

○ Provides APIs that allow an IPC Process to■ configure the PDU forwarding table■ create and delete EFCP instances■ request the allocation of kernel resources to support a flow

● librina-cdap○ Implementation of the CDAP protocol