VIP Model Call Girls NIBM ( Pune ) Call ON 8005736733 Starting From 5K to 25K...
ย
Rlite software-architecture (1)
1. A RINA light implementation
Vincenzo Maffione
20/02/2017
2. Introduction (1)
โ A Free and Open Source light implementation of RINA for Linux
โ Implementation splitted between user-space and kernel-space
โ KISS approach โ codebase is clean and essential
โ Focus:
โ basic functionality - do few things but to them well
โ stability and performance - support deployments with hundreds of nodes
โ minimality - avoid over-engineering
โ Main goal: a baseline implementation for future RINA products
โ Code and documentation available at https://github.com/vmaffione/rlite
3. Introduction (2)
โ ~ 27 Klocs (not including blanks)
โ kernel-space: ~ 9 Klocs
โ user-space: ~ 18 Klocs
โ including tools and example applications
โ Written mostly in C (some parts are C++ for convenience)
โ C: 14 Klocs
โ C++: 7 Klocs
โ Network applications can be written in C
โ Python bindings available to write network applications in Python
4. Introduction (3)
โ kernel-space is implemented as a set of out-of-tree kernel modules, which run
on the unmodified Linux kernel.
โ Linux Kbuild system is used to build the modules against the running kernel
โ Build time (no parallel make): 3-15 seconds
โ user-space is implemented as a set of shared libraries and programs
โ CMake is used to configure and build libraries and executables
โ Build time (no parallel make): 15-60 seconds
5. Basic features (1)
โ Applications:
โ Flow allocation and deallocation, with QoS specification
โ Application registration and unregistration
โ Data transfer
โ Stack administration:
โ Creation, deletion and configuration of IPCPs
โ Registration and enrollment among IPCPs
โ Monitoring and inspection
โ inspection of IPCPs in the system
โ inspection of RIBs
โ per-flow statistics
6. Basic features (2)
โ QoS (supported through DTCP):
โ Flow control
โ Retransmission control
โ Maximum allowable gap
โ Simple token-bucket rate-limiting
โ Decent performance (detailed performance plots to come)
โ About 9.5 Gbps on a 10 Gbit link without flow control and retransmission
โ About 6 Gbps on a 10 Gbit link with flow control
โ A lot of room for optimizations
โ Stability indicators
โ Done 10 days long VM-based experiments with up 35 nodes, two levels of normal DIFs and 50 flows
allocations per second
โ Done experiments with up to 10 levels of DIFs
8. Architecture overview (2)
โ kernel-space
โ Supports control operations
โ Implements datapath
โ Keeps state
โ user-space
โ Libraries to abstract interaction with kernel-space functionalities
โ A daemon to implement management part of (many) IPCPs
โ An iproute2-like command-line tool to administer the stack
โ Interactions between kernel-space and user-space only happen through character devices โ
therefore through file descriptors
9. Kernel-space architecture (1)
โ Supported functionalities:
โ IPCP creation, deletion and configuration (kernel keeps a per-IPCP data structure)
โ Flow (de)allocation (kernel keeps a per-flow data structure)
โ Application (un)registration (kernel keeps a data structure for each registered application)
โ RMT, DTP and DTCP components of the normal IPCP
โ Shim IPCP processes (e.g. interaction with network device drivers)
โ State is maintained in kernel-space:
โ user-space can crash or be restarted at any time
โ user-space can recover state from kernel
10. Kernel-space architecture (2)
โ User-space interacts with kernel-space only through two character devices
โ /dev/rlite for control operations
โ /dev/rlite-io for data transfer and synchronization
โ Consequently, interactions only happen through file descriptors
โ Both are โcloning devicesโ
โ each open() creates a new independent kernel-space instance
โ Both devices support blocking and non-blocking operation
โ Standard poll() and select() widely used with the devices
11. Kernel-space architecture (3)
โ /dev/rlite used for control operations
โ flow (de)allocation
โ Application (un)registration
โ IPCP creation, deletion and configuration
โ Management of PDU forwarding table
โ interactions between user-space and kernel-space parts of IPCPs
โ inspection and monitoring operations on flows and IPCPs
โ ...
12. Kernel-space architecture (4)
โ Control operations follow a request/response paradigm:
โ write() to the control device to submit a request message
โ Response messages (not always present) can be read through read()
โ The control device is used to avoid ioctls() and netlink
โ Easier porting to other OSes (e.g. FreeBSD)
โ Request and response messages are represented by packed structs and are
serialized/deserialized during the user-space โโ kernel-space transition
โ support for string (de)serialization
โ support for (apn, api, aen, aei) name (de)serialization
13. Kernel-space architecture (5)
โ /dev/rlite-io for data transfer and synchronization
โ read()
โ write()
โ select(), poll(), epoll()
โ Application workflow:
โ Use the control device to allocate a flow (kernel-space object)
โ Bind the flow to a newly-created data transfer file descriptor - this is the only task performed by
means of ioctl()
โ Use the data transfer file descriptor to exchange SDUs and/or wait for events
โ Close file descriptor to deallocate the associated flow
โ Special binding mode to exchange management SDUs
14. Kernel-space architecture (6)
โ Usual abstract factory pattern to manage different types of IPCPs
โ normal: implementation of the regular IPCP
โ shim-loopback: supports system-local IPC, with optional queued mode to decouple TX and RX
code-paths, and optional packet drop emulation
โ shim-eth: uses network device drivers to transmit and receive SDUs, sharing the device with
the Linux network stack
โ shim-udp4: tunnels RINA traffic over UDP socket; mostly implemented in user-space, only
data transfer is implemented in kernel-space
โ shim-tcp4: same as shim-udp4, but using a TCP socket; deprecated, since it duplicates
flow-control and congestion control done in higher layers
โ shim-hv: uses VMPI devices to transmit and receive SDUs
15. Some kernel-space internals
โ Reference counters widely used to manage lifetime of objects (e.g. IPCPs,
flows, registered applications, PDUs)
โ sk_buff-like approach to avoid copies throughout the datapath
โ dynamic allocation of PDU buffers
โ The amount of header space to reserve at allocation time is precomputed by the user-space
daemon, depending on the local IPCP dependency graph
โ All PDU queues are limited in size to keep memory usage under control
โ Deferred work (workqueues) used only when necessary, to keep latency low
โ Example: driver transmission routine directly executes in the context of an application write()
system call, when possible
17. user-space libraries
โ librlite (written in C)
โ main library, abstracts interactions with the rlite control device (/dev/rlite)
โ provides common utilities and helpers (application names, flow specification, control
messages, ...)
โ provides an API for RINA applications
โ Other libraries
โ librlite-conf (C): extends librlite with kernel-space IPCP management functionalities
โ librlite-cdap (C++): CDAP implementation based on Google Protocol Buffer
18. librlite - Overview
โ librlite provides API calls to interact with control device instances
โ Validation, serialization and deserialization of control messages in both directions (user โ
kernel, kernel โ user)
โ It defines a POSIX-like APIs for applications:
โ Reminiscent of the socket API, to ease porting of existing socket applications...
โ โฆ yet with the full power of RINA API (QoS support and complete naming scheme)
โ Easy to learn for grown-up network developers!
โ Documentation available at https://github.com/vmaffione/rlite/blob/master/include/rina/api.h
โ Other resources: https://github.com/IRATI/stack/wiki/Application-API
19. librlite - Application API
โ Main API calls:
โ int rina_open() โ fd
โ Opens a control device instance, returning a file descriptor.
โ int rina_flow_alloc(dif_name, local_name, remote_name, flowspec, flags) โ fd
โ Issues a flow allocation request and possibly wait for the associated response. Returns a file descriptor to be
used for data transfer.
โ int rina_register(fd, dif_name, appl_name, flags)
โ Register an application into a given DIF.
โ int rina_register(fd, dif_name, appl_name, flags)
โ Unregister an application from a given DIF.
โ int rina_flow_accept(fd, flags) โ remote_appl, flowspec
โ Wait and possibly accept an incoming flow request, where the destination application is one of the ones
registered to the control device referred by fd. Returns a file descriptor to be used for data transfer.
20. librlite-conf
โ It is the backend for the rlite-ctl stack administration tool
โ Exports the management and inspection functionalities:
โ IPCP creation
โ IPCP deletion
โ IPCP configuration
โ Fetch of current flows (with related statistics)
โ Dump state of a specific flow
โ Synchronization with uipcps daemon, to wait for the user-space part of an IPCP to show up
โ ...
21. librlite-cdap
โ CDAP implementation using Google Protocol Buffer as concrete syntax
โ Provides CDAP message constructors, serializers and deserializers
โ Provides CDAP connections object to send and receive CDAP messages
โ Each CDAP connection wraps a file descriptor
โ In this way CDAP can be used over arbitrary file descriptors
โ Primarily meant to be used with /dev/rlite-io file descriptors
โ No dependencies on other parts of rlite, can be reused as a stand-alone component
23. Uipcps daemon - Overview
โ A multi-threaded single-process daemon that implements management part of some IPCPs
โ When an IPCP is created by the kernel, the daemon gets notified, and creates the corresponding
user-space IPCP (uipcp)
โ For regular IPCPs, it implements:
โ Flow allocation RIB objects
โ Directory Forwarding Table RIB objects
โ Enrollment RIB objects and enrollment state machines
โ Routing RIB objects
โ Address allocation RIB objects
โ For shim-tudp4 IPCPs it implements UDP sockets setup and dynamic UDP port allocation
โ For shim-tcp4 IPCPs it implements TCP connection setup and teardown for both client and server
side (connect(), accept(), etc.)
24. Uipcps daemon - Internals
โ A custom event-loop thread for each IPCP
โ An additional thread that implements a UNIX socket server to serve requests coming from the
rlite-ctl tool (or other future agents)
โ Abstract factory pattern to manage different types of uipcps
โ Reference counters used to manage uipcps lifetime
โ Subsystems:
โ UNIX socket server, written in C
โ uipcps container for generic uipcp management (creation, deletion, โฆ), written in C
โ shim-udp4 and shim-tcp4 user-space implementation, written in C
โ normal IPCP user-space implementation, written in C++ manly because of CDAP
โ C++ code confined inside the uipcp-normal statically linked library.
25. Uipcps daemon - Subsystems
rlite-ctl
uipcp daemon
librlite-cdap
librlite
application
unix
server
uipcps
container
normal
shim
udp4
26. Uipcp daemon - Event loop
โ A custom event-loop on top of rlite control devices
โ The event-loop thread to select() over many file descriptors
โ rlite control devices: when events happen on the control device, event-specific callbacks get
executed
โ Other file descriptors: when an event is ready on one of those, an user-provided callback gets
executed
โ Supports timers, that can be used to execute a callback after a certain
amount of time
27. Uipcp daemon - Advanced features
โ The uipcp-containers module keeps track of the IPCPs in the local system
and the flows allocated among them
โ This information is maintained in a graph of local IPCPs
โ A node for each IPCP, an edge for each inter-IPCP flow
โ Graph used for automatic computation of:
โ per-IPCP Maximum SDU size (using the constraints provided by shim DIFs)
โ per-IPCP PCI header space to be reserved at kernel buffer allocation
โ Result of computation is pushed to the kernel for optimized operation
โ Optional automatic re-enrollment triggers to create N-1 flows where they are
missing
28. rlite-ctl
โ An ip-route2-like command-line tool to administer and monitor IPCP
processes
โ Functionalities:
โ IPCP creation and deletion
โ IPCP configuration
โ Registration of an IPCP to a DIF
โ Enrollment between a local IPCP and a remote IPCP
โ Show list of IPCPs
โ Show RIB of a DIF
โ Show list of flows
โ Dump state of a specific flow
29. Common functionalities
โ Common code is compiled both in user-space and kernel-space, to ease
maintenance:
โ Serialization and deserialization routines of control messages across user/kernel interface
โ Table-based serialization/deserialization, adding a new message is straightforward
โ Helper functions for RINA names - (APN, API, AEN, AEI) tuples.
30. Available RINA application
โ Example applications:
โ rinaperf: multi-threaded client/server capable of parallel flow allocation, implementing basic
connectivity and performance testing: ping, request-response, unidirectional bandwidth
โ rina-echo-async: single-threaded event-loop based client/server tool, capable of concurrent
flow allocation and concurrent flow management
โ Real application
โ nginx: RINA port of the popular Nginx server
โ dropbear: RINA port of the Dropbear ssh client/server
โ rina-gw: Event-loop application acting as an application gateway between a RINA network and
an IP network
โ It forwards TCP connections over RINA flows and the other way around
31. Demo
โ RINA/TCP gateway, to make TCP/IP world interact with RINA world
โ Minimally patched Nginx Web Server runs over RINA
TCP/IP
NETWORK
Proxy host
Client host 1
Web
browser
rina-gw
Server host 1
patched
nginx
RINA NETWORK
Client host 2
Web
browser
RINA flow
TCP connection
32. Demo
โ RINA/TCP gateway, to make TCP/IP world interact with RINA world
โ Minimally patched Nginx Web Server runs over RINA
VM A
patched
nginx
VM B
rina-gw Browser
n.1.DIF (normal)
Shim-eth (e.1.DIF)
TCP