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