Download slides

IRATI: An open source RINA
implementation for Linux/OS
Eduard Grasa on behalf of
The PRISTINE consortium
#ict-pristine
1
#ict-pristine
OVERVIEW: GOALS AND
HIGH LEVEL DESIGN
2
RINA implementation goals
• Build a platform that enables RINA experimentation …
–1
–2
–3
–4
–5
Flexible, adaptable (host, interior router, border router)
Modular design
Programmable
RINA over X (Ethernet, TCP, UDP, USB, shared memory, etc.)
Support for native RINA applications
• … but can also be the basis of RINA-based products
–1
–2
–3
–4
–5
Tightly integrated with the Operating System
Capable of being optimized for high performance
Enables future hardware offload of some functions
Capable of seamlessly supporting existing applications
IP over RINA
#ict-pristine
3
Some decisions and tradeoffs
Decision
Pros
Cons
Linux/OS vs other
Operating systems
Adoption, Community, Stability,
Documentation, Support
Monolithic kernel (RINA/
IPC Model may be better
suited to micro-kernels)
User/kernel split
vs user-space only
IPC as a fundamental OS service,
access device drivers, hardware
offload, IP over RINA, performance
More complex
implementation and
debugging
C/C++
vs Java, Python, …
Native implementation
Portability, Skills to master
language (users)
Multiple user-space
daemons vs single one
Reliability, Isolation between IPCPs
and IPC Manager
Communication overhead,
more complex impl.
Soft-irqs/tasklets vs.
workqueues (kernel)
Minimize latency and context
switches of data going through the
“stack”
More complex kernel
locking and debugging
4
High-level software arch.
5
PRISTINE contributions: SDK, policies, NMS
Enroll.
sequenc
e
Routing
policy
SDK support
SDK support
Enrollment
Routing
SDK support
Namespace
Management
librina
Security
Management
Pushbak
notify
Address
validat
Manageme
nt agent
(NMS DAF)
Directory
replica
RIB & RIB
Daemon
IPCM logic
Address
assign
Network Manager
(NMS DAF)
Normal IPC Process
(Layer Management)
PFT gen
policy
IPC Manager
SDK support
Resource
allocation
RIB & RIB
Daemon
Flow allocation
SDK support
Coord
policy
Acc. ctrl
policy
zoom in
Shim
Shim IPCP
IPCP
TCP/UDP
TCP/UDP
Normal
NormalIPC
IPCProcess
Process
(Data
(DataTransfer/Control)
Transfer/Control)
zoom in
ECN
policy
RTT
policy
Normal IPC Process
(Data Transfer/Control)
...
SDK support
Error and Flow Control Protocol
SDU Protection
Relaying and Multiplexing Task
IRATI stack
Encryp
policy
CRC
policy
TTL
policy
SDK support
SDK support
Monit
policy
Shim
ShimIPCP
IPCP
for
forHV
HV
Max Q
policy
Shim
Shim IPCP
IPCP
over
over802.1Q
802.1Q
Kernel IPC Manager
Tx ctrl
policy
librina
User space
Kernel
New flow
policy
Schedu
policy
Application
Normal IPC Process
IPC
Process
Daemon
(Layer
Management)
(Layer Management)
SDK support
Forwar
policy
IPC Manager Daemon
Auth.
policy
zoom in
6
Implementation status (I)
General
Component
Summary of status
Management Agent
Initial implementation ready: IPCP creation, destruction;
assignment to a DIF; triggering of enrollment operation; query RIB
Manager
Initial PoC ready, working on integration with Management Agent.
Shim IPCP over
802.1q
Wrap a VLAN interface or a full Ethernet interface with the DIF API.
Uses own implementation of ARP internally. Single QoS cube.
Shim IPCP over
TCP/UDP
Wrap a TCP/UDP-IP layer with the DIF API. Two QoS cubes: reliable
(“implemented” with a TCP connection) and unreliable (UDP)
Shim IPCP for HV
Allow VM-to-host communications over shared memory wrapping
it with the DIF API.
Normal IPC Process
See next slides
SDK (kernel RPI)
Support for RMT and EFCP. Need to improve granularity of policysets and add support for SDU Protection.
SDK (user-space RPI)
Support for enrollment, auth, flow allocation, namespace mgr,
resource
allocator,
routing.
Need learned
CDAP, RIB Daemon support.
IRATI objectives,
outcomes
and lessons
7
Implementation status (I)
IPCP components
IPCP component
SDK
Available policies / comments
CACEP
Y
No authentication, password-based, cryptographic (RSA keys)
SDU Protection
N
On/off hardcoded default policies, no SDK support yet: CRC32
(Error Check), hopcount (TTL enforcement), AES encryption
CDAP
N
Google Protocol Buffers (GPB) encoding, no support for filter op
Enrollment
Y
Default enrollment policy based on enrollment spec
Flow Allocation
Y
Simple QoS-cube selection policy (just reliable or unreliable)
Namespace Mgr.
Y
Static addressing, fully replicated Directory Forwarding Table
Routing
Y
Link-state routing policy based on IS-IS
Res. Allocator
Y
PDU Fwding table generator policy with input from routing
EFCP
Y
Retx. Control policies, window-based flow control, ECN receiver
RMT
Y
Multiplexing: simple FIFO, cherish/urgency. Forwarding: longest
8
IRATI objectives, outcomes and lessons learned
match
on dest. address, multi-path forwarding, LFA. ECN marking
2
QUICK DEMO
9
Quick demo scenario
Client
app
Server
app
Overlay2
2
test1.IRATI
16
Overlay1
1
“vpn.DIF”
test2.IRATI
17
“Normal.DIF”
test3.IRATI
18
Shim DIF over
802.1Q, “100”
eth1
System 1
•
VLAN 110
Shim DIF over
802.1Q “110”
eth2
eth1
System 2
VLAN 100
eth1
System 3
Nothing too fancy, just show how IPCPs are created and configured
currently, 2 levels of DIFs and the “rina-echo-time” application on top
10
3
EXPERIMENTAL ACTIVITIES
11
Designing RINA networks (I)
Number, scope of layers and goal of each one
• Decide the number and scope of the layers (DIFs) in the network,
. Example:
– Three ISPs that use multiple DIFs internally for traffic aggregation
purposes
– ISP alliance DIF: the three ISPs get together to support a number of
specialized DIFs
• Public Internet DIF (General purpose), Corporate VPN DIF, Interactive
Video DIF
Public Internet DIF
Interactive Video
DIF
Corporate VPN DIF
ISP Alliance DIF
ISP 1 Metro DIF
ISP 1 Backbone DIF
ISP 2 Metro DIF
ISP 3 Metro DIF
ISP 2 Regional DIF
ISP 3 Backbone DIF
ISP 2 Backbone DIF
12
Designing RINA networks (II)
QoS cubes to be supported by each layer
• Identify the types of traffic that should be served by each layer
and dimension it. Ideally, for each type of traffic, we would like
to know:
– Characterization in terms of burstiness, offered load, etc
– Required statistical bounds on loss and delay (e.g. 99% of
time loss should be less than 5%) -> can be derived from
required QoE
– Reliable and/or in order delivery of data required?
• From that information the number and characteristics of QoS
cubes required can be derived.
13
Designing RINA networks (III)
Policy sets of each layer
• Design new (or use existing) policy sets that allow each layer to
reach its design goals taking into account its operational
environment (offered traffic, QoS cubes supported, N-1 DIFs).
– Connectivity graph, addressing, routing, data transfer, delimiting, resource
allocation, relaying and multiplexing, authentication, authorization, SDU
protection, etc
IPC API
Data Transfer
Layer Management
Data Transfer Control
CACEP
SDU Delimiting
Relaying and
Multiplexing
State Vector
State
StateVector
Vector
DataTransfer
Transfer
Data
Data
Transfer
Retransmission
Retransmission
Retransmission
Control
Control
Control
RIB
Daemon
Authentication
Resource Allocation
CDAP
Parser/Generator
Flow Control
Flow Control
Flow Control
RIB
SDU Protection
Flow Allocation
Routing
Enrollment
Namespace
Management
Security
Management
Increasing timescale (functions performed less often) and complexity
14
Designing RINA networks (IV)
Network Management System
• Analyze the role of the Network Management System (“monitor
and repair”), a number of configurations are possible – from fairly
centralized to autonomic.
Mgr
MA
MA
MA
MA
MA
MA
MA
MA
• Understand the different operating ranges of the network,
decide monitors/triggers to sense them and design strategies to
automatically transition between different policy sets associated
to the operating ranges.
15
Designing RINA networks (V)
Interoperating with legacy technology
• If it has to interoperate with existing technology or support
legacy apps, understand the required tooling for interoperation:
shim DIFs, gateways, legacy application support.
Legacy
app
Gateway
Faux Sockets
Gateway
faux
IPC
Process
IPC
Process
Shim IPC
Process
Shim IPC
Process
Shim DIF
over 802.1Q
VIFIB Node
IPC
Process
Shim IPC
Process
Shim DIF over UDP
Shim IPC
Process
Shim IPC
Process
TCP or UDP
Public Internet
(IPv6)
Ethernet
Public Internet (IPv4)
Ethernet
Ethernet (VLAN)
IPC
Process
SlapOS base
DIF
VIFIB Node
...
Ethernet
VIFIB Node
Ethernet
...
Ethernet
Gateway
Shim DIFs
16
Performance experiments (I) goodput
•
Note: The prototype is not performance-optimized yet
•
An extra layer doesn’t add too much overhead
17
Performance experiments (II) delay
•
Adding an extra DIF doesn’t
incur a significant penalty on
processing delay
RTT directly over normal
IPCP over shim
RTT directly over the shim DIF
18
Experiments we are currently setting up
Distributed cloud scenario
•
Authentication, encryption
•
Multi-layer congestion control/avoidance
•
Delay/loss
classes)
multiplexing
(multiple
QoS
19
Experiments we are currently setting up
Datacentre networking scenario
•
Multi-layer
congestion
control/avoidance
•
QoS-aware multipath routing
•
Routing in multiple layers
20
4
OPEN SOURCE INITIATIVE
21
Open source IRATI
• IRATI github side
• http://irati.github.io/stack
• Hosts code, docs, issues
• Installation guide
• Experimenters (tutorials)
• Developers (software arch)
• Mailing list
developers
for
users
and
• [email protected]
• Procedures to contribute under
discussion, doc ongoing
22
Planned contributions to (open) IRATI
FP7 PRISTINE project
• Software Development Kit (RPI)
• Simple configuration tools
• Management Agent
• Enhanced CDAP and RIB libraries
• Several IPCP Policies
• Bug fixes
• Faux sockets? Network Manager?
Contribs during 2015 and 1H 2016
Open IRATI
You
• Lots to do!
Let’s talk!
G3+ OC winner IRINA project
• Traffic generation modules for test apps,
bug fixes
April/May 2015
23
<Thank you!>
Further information can be found here.
Twitter @ictpristine
www www.ict-pristine.eu