Download - 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
Applications X and Y are known (instantiated by kernel)
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
Applications X and Y are known (instantiated by kernel)
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!
Two systems connected by a wire
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)
Applications X and Y -> need to register a name that is unique over both systems!
IPC ProcessIRM IRM
IPC Resource Managerbasically creates/destroys IPC processes.Ideally: part of the OS
Two systems connected by a wire
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.
Applications X and Y -> need to register a name that is unique over both systems!
reg(pid, name);
unreg(pid);
alloc (name, …);
dealloc (port_id);
IRMIRM
DISTRIBUTED APPLICATION FACILITY
Two systems connected by a wire
17
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.
Applications X and Y -> need to register a name that is unique over both systems!
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
DISTRIBUTED IPC FACILITY
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
Building networks: enrollment
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
Building networks: flow allocation
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
Transmission Control
Transmission Control
Retransmission Control
Retransmission Control
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
Building networks: enrollment
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
Building networks: flow allocation
38
X Y
A1 A2 B1 B2
C2 C1 E1 E2
F1 F2F3 F4
D1 D3D2
38
Basic concept of RINA
39
Basic concept of RINA
40
Basic concept of RINA
41
Basic concept of RINA
42
Basic concept of RINA
43
“Simplicity is prerequisitefor reliability” – E. Dijkstra
The lowest layer: shim DIFs
44
DISTRIBUTED IPC FACILITY
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
Data Transfer Protocol (DTP)
Data Transfer Control Protocol
(DTCP)
(N-1)-DIF A (N-1)-DIF B
Queues
Relaying and Multiplexing Task
EFCP
9
Data Transfer Protocol (DTP)
• 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
Data Transfer Protocol (DTP)
Data Transfer Control Protocol
(DTCP)
(N-1)-DIF A (N-1)-DIF B
Queues
Relaying and Multiplexing Task
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
Data Transfer Protocol (DTP)
Data Transfer Control Protocol
(DTCP)
(N-1)-DIF A (N-1)-DIF B
Queues
Relaying and Multiplexing Task
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
(N-1)-DIF A (N-1)-DIF B
Queues
Relaying and Multiplexing Task
EFCP Delimiting
Data Transfer Protocol
Data Transfer Control
(N-1)-DIF A (N-1)-DIF B
Queues
Relaying and Multiplexing Task
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
Data Transfer Protocol
Data Transfer Control
(N-1)-DIF A (N-1)-DIF B
Queues
Relaying and Multiplexing Task
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
Large scale RINA Experimentation on FIRE +
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
Large scale RINA Experimentation on FIRE +
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
aggregation (Carrier Eth, MPLS, …)
Metropolitan
aggregation
Metropolitan
aggregation (Carrier Eth, MPLS, …)
Metropolitan
aggregation
Metropolitan
aggregation (Carrier Eth, MPLS, …)
• 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
Large scale RINA Experimentation on FIRE +
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.)
Large-scale RINA Experimentation on FIRE+ 10
(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
Large-scale RINA Experimentation on FIRE+ 13
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
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 V
ecto
r State
Ve
ctor
State V
ecto
r
Data Transfer Data 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
Large scale RINA Experimentation on FIRE +
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 PtP DIF PtP DIF PtP 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
PtP DIF PtP DIF PtP DIF PtP DIF
DC Fabric DIF
Tenant DIF
Large scale RINA Experimentation on FIRE +
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
Large scale RINA Experimentation on FIRE +
Thank you!
42
Large scale RINA Experimentation on FIRE +
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
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 V
ecto
r State
Ve
ctor
State V
ecto
r
Data Transfer Data Transfer
Retransmission Control
Retransmission Control
Flow Control Flow Control
Increasing timescale (functions performed less often) and complexity
Namespace Management
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
Confiden.ality,integrity
Opera&ngontheIPCP’sRIB
Accesscontrol
IPCProcess
Appl.Process
Accesscontrol(DIFmembers)
Confiden.ality,integrity
Authen.ca.on
AccesscontrolOpera.onsonRIB
DIFOpera&onLogging
DIFOpera&onLogging
Separation of mechanism from policy
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
RetransmissionControl
RetransmissionControl
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
Separation of mechanism from policy
5
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
RetransmissionControl
RetransmissionControl
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
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
© John Day, 2014 Rights Reserved
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
© John Day, 2014 Rights Reserved
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
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
RetransmissionControl
RetransmissionControl
FlowControlFlowControl
NamespaceManagement
SecurityManagement
Accesscontrol(layermgmtopera.ons)
Accesscontrol(joiningtheDIF)
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
@ictpristine Athens, 27th June 2016 1
Agenda
Introduction
OMNeT++ Handbook
Component overview
Interactive Demo
@ictpristine Athens, 27th June 2016 2
@ictpristine Athens, 27th June 2016 3
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
@ictpristine Athens, 27th June 2016 4
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
@ictpristine Athens, 27th June 2016 5
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
@ictpristine Athens, 27th June 2016 6
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
http://ict-pristine.eu/?p=772
Skype group chat
skype:?chat&blob=-bdq6qH_uDXIlbRk_4_XwqZyplfXPl4IzCq4P-S0BrsttjgPR8CNJKV9-Yyn1TYopaYZD2g3bIC_Yv0C
@ictpristine Athens, 27th June 2016 7
@ictpristine Athens, 27th June 2016 8
OMNeT++ Handbook
The fast and the furios basic 101 introductorycourse about OMNeT++
Simulation Module
Modules
Gates (input, output, inout), messages
@ictpristine Athens, 27th June 2016 9
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
@ictpristine Athens, 27th June 2016 10
Module’s Hierarchy
Simple
Compound
Network
@ictpristine Athens, 27th June 2016 11
IDE
@ictpristine Athens, 27th June 2016 12
Simulation
@ictpristine Athens, 27th June 2016 13
Scheduledmessages
Componentparameters
Console log
Detachedgraphical
component detail
Control buttons
@ictpristine Athens, 27th June 2016 14
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
@ictpristine Athens, 27th June 2016 15
Computation Systems ①
@ictpristine Athens, 27th June 2016 16
Computation Systems ②
Hosts and Routers
@ictpristine Athens, 27th June 2016 17
DAF Components
Application Process
contains AE(s)
manages DAF enrollment
data and mgmt flows
@ictpristine Athens, 27th June 2016 18
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
@ictpristine Athens, 27th June 2016 19
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
@ictpristine Athens, 27th June 2016 20
TCP/IP vs. RINA
@ictpristine Athens, 27th June 2016 21
IPC Process
@ictpristine Athens, 27th June 2016 22
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
@ictpristine Athens, 27th June 2016 23
Error and Flow Control Protocol
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
@ictpristine Athens, 27th June 2016 24
EFCP Instance
DTP Actual Data Transfer
DTCP Handles Flow Control and
Retransmission
@ictpristine Athens, 27th June 2016 25
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
@ictpristine Athens, 27th June 2016 26
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
@ictpristine Athens, 27th June 2016 27
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?
@ictpristine Athens, 27th June 2016 28
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
@ictpristine Athens, 27th June 2016 29
@ictpristine Athens, 27th June 2016 30
Interactive Demo
How IPC works between two hosts interconnected to a common node?
HostA Switch HostB
HostA HostBSwitch
Topology
@ictpristine Athens, 27th June 2016 31
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
@ictpristine Athens, 27th June 2016 32
HostA HostBSwitch
1) Setup network
Create new simulation in folderexamples/Athens/Demo
@ictpristine Athens, 27th June 2016 33
1) Setup network
Open Demo.ned and add two Host1AP onto canvas and one InteriorRouter2Int
Rename them with F6
Connect them with DatarateChannel
@ictpristine Athens, 27th June 2016 34
1) Setup network
Change DatarateChannel properties
Setup delay, ber, datarate
@ictpristine Athens, 27th June 2016 35
1) Setup network
Copy config.xmlfrom examples/Demos/UseCase4/config.xml
@ictpristine Athens, 27th June 2016 36
2) Schedule simulation
Assign addresses
Bind config.xml
Schedule AEMyPing
@ictpristine Athens, 27th June 2016 37
3) Run
@ictpristine Athens, 27th June 2016 38
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
@ictpristine Athens, 27th June 2016 39
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
@ictpristine Athens, 27th June 2016 40
RINASim● Comments?
Questions?Suggestions?
@ictpristine Athens, 27th June 2016 41
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
DIF components for a complete RINA stack
IPCProcess
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 Vecto
rState V
ector
State Vecto
r
Data Transfer Data Transfer
Retransmission Control
Retransmission Control
Flow ControlFlow Control
Namespace Management
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
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
Normal IPC Process datapath
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
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
Normal IPC Process datapath
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
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
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)
Error and Flow Control Protocol
Relaying and Multiplexing Task
SDU Protection
. . .
Normal IPCP(Layer Mgmt)
RIB & RIB Daemon
librina
Resource allocation
Flow allocation
Enrollment
Namespace Management
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