1. Investigating RINA as an Alternative to TCP/IP Update on technical work after M6 Prepared for the IRATI technical review

2. Outline Use cases description, requirements analysis, refinement of RINA specifications and high- level software architecture Software implementation Experimentation and validation Demo of current prototype 2Investigating RINA as an Alternative to TCP/IP 3. USE CASES DESCRIPTION AND REQUIREMENTS ANALYSIS Investigating RINA as an Alternative to TCP/IP 3 4. Integration testing use cases Shim DIF over Ethernet Goal: to ensure that the shim DIF over Ethernet provides the required functionality. The purpose of a Shim DIF is to provide a RINA interface to the capability of a legacy technology, rather than give the legacy technology the full capability of a RINA DIF. Investigating RINA as an Alternative to TCP/IP 4 The shim DIF over Ethernet wraps an Ethernet layer with the RINA API and presents it to the layer above as if it was a regular DIF (usually with restricted capabilities; very seldom current technologies provide a fully- formed layer). The only intended user of an Ethernet shim DIF is a normal IPC Process, as discussed in the shim DIF specification. 5. Integration testing use cases Turing machine DIF Goal: to provide a testing scenario to check a normal DIF complies with a minimal set of functionality (the Turing machine DIF). This DIF has the following characteristics: Supports the registration of an arbitrary number of applications. Supports an arbitrary number of flows between the same applications. Provides two QoS classes (cubes): unreliable (no guarantees on anything), and reliable (guarantees that SDUs written to a flow will not be lost and will arrive in order at the other end of the flow). Investigating RINA as an Alternative to TCP/IP 5 Requires no authentication to join it. Doesnt protect its SDUs when writing them to an N-1 DIF. Doesnt support fragmentation and reassembly of SDUs Can use more than one shim DIF as supporting DIFs (i.e. not all the IPC Processes in the DIF are one hop away, as it is the case with the shim DIF). 6. Cloud/network integration use case Introduction RINA applied to a hybrid cloud/network provider Mixed offering of connectivity (Ethernet VPN, MPLS IP VPN, Ethernet Private Line, Internet Access) + computing (Virtual Data Center) Investigating RINA as an Alternative to TCP/IP 6 Access Network Wide Area Network Datacenter Design 7. Cloud/Network integrationuse case Modeling Investigating RINA as an Alternative to TCP/IP 7 HV VM VM VM HV VM VM VM HV VM VM VM HV VM VM VM TOR HV VM VM VM HV VM VM VM HV VM VM VM HV VM VM VM TOR CE Data Center 1 HV VM VM VM HV VM VM VM HV VM VM VM HV VM VM VM TOR HV VM VM VM HV VM VM VM HV VM VM VM HV VM VM VM TOR CE Data Center 2 PE PE CE Customer 1 Site A PE CE Customer 2 Site A PE PE CE Customer 1 Site B CE Customer 1 Site C CE Customer 2 Site B MPLS backbone Internet GW Customer 2 Site C Public Internet End user 8. Cloud/Network integration use case Applying RINA Investigating RINA as an Alternative to TCP/IP 8 HV VM TOR Datacenter-wide DIF CE PE Backbone DIF P PE CE TOR HV VM Datacenter-wide DIF Backbone Provider top-level DIF Inter-datacenter DIF Customer A DIF Network Service Provider Core Network Provider Access network Provider Access network Datacenter 2 networkDatacenter 1 network HV VM TOR Datacenter-wide DIF CE PE Backbone DIF P PE CE Customer 1 site A DIFProvider top-level DIF Customer A DIF Interoute core network Access network Access network Customer 1 site A networkDatacenter 1 network 9. REFINEMENT OF RINA SPECIFICATIONS Investigating RINA as an Alternative to TCP/IP 9 10. Shim DIF over Ethernet General requirements Investigating RINA as an Alternative to TCP/IP 10 The task of a shim DIF is to put a small as possible veneer over a legacy protocol to allow a RINA DIF to use it unchanged. Not a RINA-conformant application. We are not trying to make legacy protocols provide full support for RINA. Anything more should be provided by the first full DIF. The shim DIF should provide no more service or capability than the legacy protocol provides. DIF System (Host) IPC Process Shim IPC Process Mgmt Agemt System (Router) Shim IPC Process Shim IPC Process IPC Process Mgmt Agemt System (Host) IPC Process Shim IPC Process Mgmt Agemt Appl. Process Shim DIF over TCP/UDP Shim DIF over Ethernet Appl. Process 11. Shim DIF over Ethernet Environment A shim DIF over Ethernet maps to a VLAN The DIF name is the VLAN name The shim DIF only supports on class of service: unreliable ARP can be used to map upper layer IPC Process names to shim DIF addresses (MAC addresses) Only one application (a normal IPC Process) can be registered at each shim IPC Process No way to differentiate between multiple flows from the same pair of shim IPC Processes Investigating RINA as an Alternative to TCP/IP 11 12. Source MAC @ (6 bytes) Source shim IPC Process address Destination MAC @ (6 bytes) Destination shim IPC Process address IEEE 802.1Q tag (2 bytes) DIF name Ethertype (2 bytes) 0x0D1F 12 Shim DIF over Ethernet Ethernet II PCI Application data Minimum length: 42 bytes (46 if 802.1Q not present) Maximum length: 1500 bytes Shim DIF over Ethernet Use of the Ethernet frame Investigating RINA as an Alternative to TCP/IP 13. Forwarding Table Generator Requirements and general choices Goal: Compute the PDU forwarding table of an IPC Process, for DIFs of medium-size (in the order of 200 IPC Processes) Forwarding table computation in RINA is all policy; i.e. each DIF can choose the way it wants to accomplish this task. Approach: Rely on well-known link-state routing techniques, translating them to the DIF environment Good enough for the environment under consideration Look at the mechanisms available in IS-IS and OSPF Investigating RINA as an Alternative to TCP/IP 13 14. Forwarding Table Generator High-level view and relationship to other IPC Process components Investigating RINA as an Alternative to TCP/IP 14 RIB Daemon 5 6 7 N-1 Flows to nearest neighbors (Layer management) Resource Allocator PDU Forwarding Table Generator Events N-1 flow allocated N-1 flow deallocated N-1 flow down N-1 flow up Neighbor B invoked write operation on object X CDAP Incoming CDAP messages from neighbor IPC Processes CDAP Outgoing CDAP messages to neighbor IPC Processes Invoke write operation on object X to neighbor A Update knowledge on N- 1 flow state Propagate knowledge on N- 1 flow state Recompute forwarding table PDU Forwarding Table Relaying and Multiplexing Task Lookup PDU Forwarding table to select output N-1 flow for each PDU 4321 N-1 Flows to nearest neighbors (Data Transfer) IPC Process Enrollment Task Events Enrollment completed successfully 15. Inter DIF Directory Introduction Investigating RINA as an Alternative to TCP/IP 15 The IPC Model posits a function that allows the Application Name Space to have a greater scope than any one DIF. Which we have called the Inter-DIF Directory (for lack of a better term) Entity associated with the IPC Management in DAPs may query what applications are available in a system. Two phases in IDD lifecyle Locate the destination application (search phase) Create a new DIF (or expand an existing one) with enough scope to allow source and destination applications to communicate DIFs NSM-DAPs 16. Inter DIF Directory Possible policies for the search phase Unstructured approaches (all processes in IDD-DAF have the same functionality): simple but low scalability Flooding with fixed TTL Flooding with increased TTL (expanding ring) Random walks Hint-biased random walks Structured approaches (some processes in IDD-DAF specialized to support higher scalability) Distributed Hash Tables (DHTs) - a la Chord Hierarchical organization of the application namespace (a la DNS) Start simple: focus on unstructured approaches (even if it limits its applicability to small sets of DIFs) -> Random walks Better scalability than flooding, at the cost of a higher delay Investigating RINA as an Alternative to TCP/IP 16 17. HIGH-LEVEL SOFTWARE ARCHITECTURE Investigating RINA as an Alternative to TCP/IP 17 18. High-level software architecture General requirements and choices Linux has been the chosen target platform for IRATI, due to It is widely used in different contexts Open source OS with a great community and documentation However the implementation aims to be as reusable as possible in similar environments other UNIX-based Operating Systems The implementation targets both the user-space and the kernel- space, since Low performance penalties have to be achieved for highly-frequent tasks (such as reading and writing data) -> Some components must be placed in the kernel There is the need to access device driver functionalities in order to be able to overlay RINA on top of Ethernet (or other networking technologies in the future) -> Some components must be placed in the kernel Investigating RINA as an Alternative to TCP/IP 18 19. High-level software architecture Introduction to the software framework Components have been partitioned into 3 categories: Daemons (in user-space) Libraries (in user-space) Kernel components Investigating RINA as an Alternative to TCP/IP 19 Libraries abstract out the communication details between user-space components and user-space and kernel components Kernel components implement the data transfer and data transfer control parts of normal IPC Processes, as well as shim DIFs (fast path) Daemons implement the layer management parts of IPC Processes, as well as the IPC Manager. 20. Inter-component communication Netlink sockets (User space User space/ User space -> Kernel / Kernel -> User space) Match many of our requirements (1:N, N:M, asynchronous, initiated communications by both-spaces). Netlink can support kernel to user- space communication due to its full-duplex channels, allowing the framework to warn the application about specic events. System calls (User space -> Kernel) For user-originated atomic actions, or belonging to fast-paths, the denition of a set of system calls provides an efcient and less resource consuming approach for synchronous user to kernel dialogues (e.g. read/write operation) Sysfs (Kernel configuration and monitoring) It allows to congure the different RINA components residing in kernel space, as well as obtaining metrics of these kernel components in user- space. Investigating RINA as an Alternative to TCP/IP 20 21. 21 Kernel User space Netlink Netlink Netlink System calls System calls Netlink System calls Netlink Error and Flow Control Protocol Relaying and Multiplexing Task SDU Protection Shim IPC Process over Ethernet Device Drivers (VLAN) frame in/out Shim IPC Process over TCP/UDP Sockets layer TCP/UDP in/out Kernel IPC Manager Application process Application specific logic librina-sduprotection librina-application librina-fauxsockets IPC Process Daemon RIB Daemon & RIB librina-sduprotection librina-application librina-cdap librina-ipcprocess PDU Forwarding Table Generator Flow Allocator Enrollment Res. Alloc. IPC Process Daemon RIB Daemon & RIB librina-application librina-cdap librina-ipcprocess PDU Forwarding Table Generator Flow Allocator Enrollment Res. Alloc. librina-sduprotection librina-sduprotection IPC Manager Daemon RIB Daemon & RIB librina-application librina-cdap librina-ipcmanager Management Agent IDD IPC Manager main logic Config files CLI 22. Mapping of the RINA model to the IRATI implementation 22 DIF System (Host) IPC Process System (Router) Shim IPC Process Mgmt Agent System (Host) Shim IPC Process Appl. Process Shim DIF over TCP/UDP Shim DIF over Ethernet Appl. 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 StateVector StateVector StateVector Data TransferData Transfer Transmission Control Transmission Control Retransmission Control Retransmission Control Flow Control Flow Control 22 IPC Process Daemon (User space) Normal IPC Process kernel components (Kernel) Mgmt Agent Mgmt Agent Librina-application library IPC Manager Daemon IPC Process IPC Process Shim IPC Process Shim IPC Process Shim IPC Process Shim IPC Process over Ethernet (kernel) Shim IPC Process over TCP/UDP (kernel) 23. Application Processes Regular applications that use one or more DIFs to communicate with other application processes. The librina-application library exposes the RINA services through the native RINA or the faux-sockets API Investigating RINA as an Alternative to TCP/IP 23 IPC Process librina-application Application process write_sdu / ev_wait / ev_poll / allocate / deallocate / register / unregister / query_dif_properties IPC Process IPC Manager Kernel User space System calls Netlink sockets Netlink sockets Netlink sockets open / close / listen/ bind / read / write librina-fauxsocketslibrina-sduprotection protect/ unprotect/ Application-specific logic Native RINA application Legacy application 24. IPC Process Daemon Implements the layer management components of a normal IPC Process (1 instance per normal IPC Process) Investigating RINA as an Alternative to TCP/IP 24 Normal IPC Process Application process User space System calls Netlink sockets librina-ipcprocess ipcp_ev_wait / ipcp_ev_poll / efcp_create / Application process Netlink sockets IPC Manager IPC Process IPC Process librina-application read/write/allocate/ System calls Netlink sockets RIB Daemon & RIB librina-cdap encode / decode / Resource Allocator Enrollment Flow Allocator PDU Forwarding Table Generator librina-sduprotection protect/ unprotect/ 25. IPC Manager Daemon Investigating RINA as an Alternative to TCP/IP 25 IPC Manager Application process Kernel User space System calls Netlink sockets librina-ipcmanager create_ipcprocess/ enroll/ assign/ notify_registration/ Application process Netlink sockets librina-application write/ ev_wait/ allocate/deallocate/ System calls RIB Daemon & RIB librina-cdap encode / decode / Inter DIF Directory Management Agent librina-sduprotection protect/ unprotect/ Main IPC Manager logic IPC Process IPC Process Config files CLI Management and configuration of IPC Process daemons and kernel components; hosts the local management agent and IDD 26. Libraries librina-application. Provides the APIs that allow an application to use RINA natively, enabling it to allocate and deallocate flows, read and write SDUs to that flows, and register/unregister to one or more DIFs. librina-ipcmanager. Provides the APIs that facilitate the IPC Manager to perform the tasks related to IPC Process creation, deletion and configuration. librina-ipc-process. APIs exposed by this library allow an IPC Process to configure the PDU forwarding table (through Netlink sockets), to create and delete EFCP instances (through system calls), to request the allocation of kernel resources to support a flow (through system calls also) and so on. librina-faux-sockets. Allow adapting a non-native RINA application (a traditional UNIX socket based application) to lay over the RINA stack. librina-cdap. Implementation of the CDAP protocol. librina-sdu-protection. APIs and implementation to use the SDU- protection module in user space to protect and unprotect SDUs (add CRCs, encryption, etc) librina-common. Common interfaces and data structures. Investigating RINA as an Alternative to TCP/IP 26 27. Kernel components Three types of components: Kernel IPC Manager: Coordinates and manages the different kernel components, and is the point of entry for reading/writing SDUs from user-space. Data transfer and data transfer control components of normal IPC Processes (EFCP, RMT, SDU Protection) Shim IPC Processes: to overlay RINA on top of different existing networking technologies (Ethernet, TCP/UDP, WiFi, USB, etc.) Investigating RINA as an Alternative to TCP/IP 27 Kernel Error and Flow Control Protocol Relaying and Multiplexing Task SDU Protection Shim IPC Process over Ethernet Device Drivers (VLAN) frame in/out Shim IPC Process over TCP/UDP Sockets layer TCP/UDP in/out Kernel IPC Manager 28. Outline Use cases description, requirements analysis, refinement of RINA specifications and high- level software architecture Software implementation Experimentation and validation Demo of current prototype 28Investigating RINA as an Alternative to TCP/IP 29. DEVELOPMENT ENVIRONMENT AND TOOLS Investigating RINA as an Alternative to TCP/IP 29 30. Dev & build environment (kernel) The dev & build environment is dictated by Linux: Kconfig, Kbuild and C We developed a lightweight ad-hoc framework: Per-component logging (and their filtering opt-in/opt-out) General (debugging) facilities e.g.: sysfs and debugfs integration Memory management & debugging e.g.: Memory block tampering & poisoning RINA specific data structures e.g. imaps, fmaps, rqueues Design patterns e.g.: factories, observers, robjects All the components of the stack use the framework Investigating RINA as an Alternative to TCP/IP 30 31. Dev & build environment (kernel) The framework has a small footprint and dependencies It could be easily ported to other kernels The code is already integrated into the native build system: Framework and stack functionalities can be enabled/disabled at configuration time (Kconfig) Various components are produced as kernel modules (Kbuild) E.g. Personalities, Core, Shim-IPCs All the IRATI kernel code is confined into its own directory No changes outside the net/rina directory Keeping the kernel up-to-date is straightforward Since the upstream is not frozen we can take updates and fixes while keeping our codebase up-to-date (till the end of the project) We already merged: Linux 3.9.2 (vanilla) Linux 3.10.0 (vanilla) Investigating RINA as an Alternative to TCP/IP 31 32. Dev & build environment (user) We adopted the autotools as a tool to create our build system The system: looks for and setups all the tools (configuration time) and runs them when necessary (build time) Adapts to a wide set of POSIX based systems The user-space part is constituted by self-contained SW packages, each: Detects its dependencies automatically Reacts opportunely when they are missing That way: the build environment is the correct build sequence Investigating RINA as an Alternative to TCP/IP 32 33. Dev & build environment (user) Automatically configures and builds Into a generic *NIX system (e.g. Linux/OS, *BSD) Without (almost no) user/developer intervention The developers environment is (almost) equal to the users one Intermediate build products are shipped no extra tools requirements on the user side A sufficiently up-to-date Linux/OS machine can build the stack We adopted Linux/Debian as the default OS It allows automatic (functional & regression) testing Investigating RINA as an Alternative to TCP/IP 33 34. DESIGN AND DEVELOPMENT, THE BIG PICTURE Investigating RINA as an Alternative to TCP/IP 34 35. Design and development Investigating RINA as an Alternative to TCP/IP 35 Personality mux/demux KIPCM KIPCM Core IPCP Instances map IPCP Factories Flows map EFCPRMT / PDUFTSDU Prot. IPCP Instance Framework(libs) RINA Netlink libnl / libnl-gen Third parties SW Packages rinad Netlinksyscalls RINABand HL ipcmd Core (C++) API (C++) API (C) SWIG HL wrappers (Java) SWIG LL wrappers (C++, for Java) SWIG LL wrappers (C++, for language X) SWIG HL wrappers (Language X) librina shim-eth-vlan shim-tcp-udp RINA-ARP shim-dummy User space Kernel space 36. DESIGN AND DEVELOPMENT, THE KERNEL SPACE Investigating RINA as an Alternative to TCP/IP 36 37. kobjects, ksets and krefs Linux has its generic object abstraction: kobject, kref and kset structkref { atomic_trefcount; } structkobject { const char * name; structkset { structlist_headentry; structlist_head list; structkobject * parent; spinlock_t const structklist_lock; structkset * kset; structkobjectkobj; structkobj_type * ktype; set_uevent_ops * uevent_ops; structsysfs_dirent * sd; }; structkrefkref; unsigned int state_initialized:1; unsigned int state_in_sysfs:1; unsigned int state_add_uevent_sent:1; unsigned int state_remove_uevent_sent:1; unsigned int uevent_suppress:1; }; Generic enough to be applied everywhere E.g. FS, HW Subsystems, Device drivers Investigating RINA as an Alternative to TCP/IP 37 Objects (dynamic) [re-]parenting (loosely typed) Sysfs integration Objects grouping References counting (explicit) Naming &sysfs 38. kobjects, ksets and krefs in our context They are the way to go for: An handful of classes and A small number of instances Otherwise the code gets bloated for: Ancillary functions & data structures (unnecessary) Resources usage We dont need all these functionalities (everywhere): We have a reduced (finite) number of different classes Reduced concurrency (can be missing, depending on the object) Object parenting is fixed(obj x is always bound to obj y) Smart-pointers and garbage-collection (almost) unnecessary Not all our objects must be published into sysfs Few of our objects needs look-up by name We have different lookups requirements (e.g. maps rather than lists) Inter-objects bindings shouldnt loose their type Investigating RINA as an Alternative to TCP/IP 38 39. Kernel-space components 39 User space Personality mux/demux syscalls / Netlink KIPCM KIPCM Core EFCPRMT / PDUFTSDU Prot. shim-eth-vlan Devices layer shim-tcp-udp Sockets layer IPCP Instances map IPCP Factories Flows map RINA-ARP IPCP Instance Framework(libs) RINA Netlink shim-dummy 40. Personalities The Personality layer is (almost) a kernel/user interface mux/demux Personality are represented by ids (uints) Demuxes user kernel Are associated to the personality instance Handled by the RINA stack instance bound to that id Muxes kernel user Each component holds bindings to parent components By walking the components hierarchy the personalities are automatically multiplexed They allow hot-plugging different RINA implementations (whole stacks) They have only to adopt the IRATI kernel/user interface This way: Different RINA implementations may share code They only have to agree on the kernel/user interface The IRATI personality is the default and only supported personality Other personalities might come later (PRISTINE ?) Investigating RINA as an Alternative to TCP/IP 40 41. The kernel/user interface: KIPCM + RNL Kernel interface = syscalls + Netlink messages KIPCM manages the syscalls Syscalls: a small-numbered, well defined set of (#8) calls: IPCs: ipc_create, ipc_destroy and ipc_configure Connections: connection_create, connection_destroy and connection_update SDUs: sdu_read and sdu_write RNL manages the Netlink part Netlink: #25 message types (with dynamic attributes): assign_to_dif_req, assign_to_dif_resp, dif_reg_notif, dif_unreg_notif, enroll_to_d if_req, enroll_to_dif_resp The syscall/netlink partitioning is due to Fast/slow paths partitioning: Netlink in the slow-lane (mostly configuration and management) Syscalls in the fast-lane (read and write SDUs) Bootstrapping needs: Syscalls to create a kernel component instance which will be using the Netlink layer functionalities later on Investigating RINA as an Alternative to TCP/IP 41 42. Normal IPCP EFCP RMT The KIPCM Core The KIPCM: 1. Manages IPC Processes and Flows 2. Its the initial point where recursion is transformed into iteration 3. Binds the IRATI kernel top (i.e. user-interface) bottom (i.e. shims) To perform 1 & 3, its data-model holds: Flows maps: port-id ipc-process-instance IPC Process instances For all the IPC Processes maps: ipc-process-id ipc-process-instance IPC Process Factories Only for the Shim IPC Processes 1 per shim IPC Process type To perform 2, the KIPCM inject/gets SDUs: IPCP EFCP RMT PDU-FWD Investigating RINA as an Alternative to TCP/IP 42 OUT IN KIPCM Core PDU-FWD-T User space syscalls Netlink Shim IPCP 43. They are used by Shim-IPC Processes to publish/un-publish their availability x = kipcm_ipcp_factory_register(, char * name, ) publish kipcm_ipcp_factory_unregister(x) unpublish The factory name is the way KIPCM can look for a specific shim Its published into sysfs too The IPC Process Factories Investigating RINA as an Alternative to TCP/IP 43 .init shim_x_init .fini shim_x_fini .create shim_x_create .destroy shim_x_destroy .configure shim_x_configure .flow_allocate_request(); .flow_allocate_response(); .flow_deallocate(); .application_register() .application_unregister(); .assign_to_dif(); .sdu_write(); Upon registration: A factory publishs its hooks into the KIPCM Upon user-request (SYS_ipc_create): The KIPCM creates a particular Shim IPC instance: 1. Looks for the correct factory (by name) 2. Calls the .create method 3. The factory returns an IPC Process compliant object 4. Binds that object into its data model Upon un-registration: The factory triggers the destruction of all the Shims IPC Processes it owns 44. The shim-eth-vlan Its the only functional shim A still instance is returned after .create Starts working upon successful configuration: Executes dev_add_pack binds to devs layer And implements Its job is as in the specs The plug-out (.destroy) Executes dev_remove_pack unbinds from devs layer But it does not use the Linux ARP Investigating RINA as an Alternative to TCP/IP 44 45. Linux ARP vs compliant ARP (RINA-ARP) ARP is too intertwined with IPv4: Its limited to IP addresses Theres no practical way to register another network address on top Only IP assigned to the device is advertised Theres no way to register handlers upon receipt of an ARP request/reply If we would use it, its constraints would harm/limit our implementation Even accepting the current ARP implementation: Lot of hacks would have needed to suit our (remaining) needs Hacks to be digested by the community too We decided to drop it and implement our own ARP We aim to provide such RFC-826 compliant implementation back to the community Investigating RINA as an Alternative to TCP/IP 45 46. Personality, core and shims They provide way to customize the stack at different kernel levels: Personality: new stack implementations Core: different internals behaviors Shims: support to other technologies We adopted a modular approach since the start It allows components hot-plugging at different levels Modules (and non modular components) may be reused: Our OO approach allows reusing components, e.g. IPC Process utils (e.g. for the shims) Core utils Investigating RINA as an Alternative to TCP/IP 46 47. Modules: .init, .exit & sharing Investigating RINA as an Alternative to TCP/IP 47 They MUST cleanup/free resources Stop activities clean-up unload IRATI Kernel IRATI User space Personality mux/demux syscalls / Netlink RINA syscalls Core RINA Netlink 2 module_init = rina_personality_register() 3 module_init = kipcm_ipcp_factory_register() Built-in (bootstrap) 1 5 module_exit = rina_personality_unregister() 4 module_exit= Kipcm_ipcp_factory_unregister() Shim IPC Process Shim IPC Process MUST ADOPT CAN ADOPT Non IRATI Compliant shims Other Stack Core Kernel 48. DESIGN AND DEVELOPMENT, USERLAND Investigating RINA as an Alternative to TCP/IP 48 49. Software packages The user-space components are implemented by different SW packages, at the moment: librina: Contains all the IRATI stack libraries And a set of regression & functional tests It s C++ based rinad: Contains daemons and applications IPC Manager and IPC Process daemons A testing application (RINABand) Its Java Based Investigating RINA as an Alternative to TCP/IP 49 50. librina Completely abstract the kernel interactions syscalls and Netlink Provides its functionalities to userland RINA programs Programs (applications & daemons) uses them via Scripting language extensions (e.g. as rinad, more later) Static/dynamic linking (i.e. for C/C++ programs) It is more a framework/middleware than a library With its memory model (explicit, no garbage collection) Its execution model is event-based Its C++ based Investigating RINA as an Alternative to TCP/IP 50 51. librina interface librina contains a set of components: Internal components External components And a portable framework to build components on top, e.g.: Patterns: e.g. singletons, observers, factories, reactors Concurrency: e.g. threads, mutexes, semaphores, condition variables Core: Netlink facilities, syscalls bindings High level objects: FlowSpecification, QoSCube, RIBObject Only the external components are exported as classes Investigating RINA as an Alternative to TCP/IP 51 52. RINA Manager NetlinkManager Event Queue NetlinkSession NetlinkSession NetlinkSessions librina core (HL) SW architecture Investigating RINA as an Alternative to TCP/IP 52 API applicationcdap faux-sockets ipc-process ipc-managersdu-protection framework RINA Netlink message parsers RINA Netlink Message formatters libnl / libnl_genl RINA syscallsNetlink socket nl_send() nl_recv() Application eventPoll() eventWait() eventPost() common 53. How to RAD, effectively ? OOP was the natural way to represent the entities So we embraced C++ as the core language: Careful usage produces binaries comparable to C The STL reduces the dependencies in the plain C vs plain C++ case Producing C bindings is possible But theres the ALBA prototype already working And ALBA prototype is Java based and ALBA has RINABand Investigating RINA as an Alternative to TCP/IP 53 54. Interfacing librina to other languages Investigating RINA as an Alternative to TCP/IP 54 SWIG example_wrap.c example.pyGCC libexample.so Python int fact(int n); example.h #include "example.h" int fact(int n) { } example.c /* File: example.i */ %module example %{ #include "example.h" %} int fact(int n); example.i Low level wrapper High level wrapper Native interface We adopted SWIG: the Software Wrapper and Interface Generator SWIG generates automatically () all the code needed to connect C/C++ programs to scripting languages Such as Python, Java and many, many others 55. librina wrapping cost The wrappers (.i files) are small: ~480 LOCs They produce ~13.5 KLOCS bindings ~1/28 ratio And the wrappers are the only thing needed to obtain bindings for a scripting language SWIG support vary on the target language, i.e. Java: so-so (not all data-types mapped natively) Python: good Our wrappers contain the missing support (Java) Bindings for other languages (i.e. Python) are expected to be straightforward Investigating RINA as an Alternative to TCP/IP 55 56. Software architecture Investigating RINA as an Alternative to TCP/IP 56 libnl / libnl-gen Kernel JNI Static/dynamic linking Third parties SW Packages rinad Netlinksyscalls Java imports Language X imports RINABand HL ipcmd Language X NI Core (C++) API (C++) API (C) SWIG HL wrappers (Java) SWIG LL wrappers (C++, for Java) SWIG LL wrappers (C++, for language X) SWIG HL wrappers (Language X) librina RINABand HL RINABand LL 57. Outline Use cases description, requirements analysis, refinement of RINA specifications and high- level software architecture Software implementation Experimentation and validation Demo of current prototype 57Investigating RINA as an Alternative to TCP/IP 58. Integration testing use cases from WP2 Shim DIF over Ethernet Goal: prepare the i2CAT and iMindstestbeds for this case Investigating RINA as an Alternative to TCP/IP 58 59. i2CAT Experimenta island Investigating RINA as an Alternative to TCP/IP 59 60. 60 Virtual Wall: Concept 61. 61 Virtual Wall: Topology Control 62. 62 Virtual Wall: Topology Control 63. Basic experiment on i2cat island Investigating RINA as an Alternative to TCP/IP 63 64. Basic Experiment on iMinds island(1) Use a LAN for the VLAN bridge Investigating RINA as an Alternative to TCP/IP 64 No additional configuration required, but no control over the VLANs 65. Basic Experiment on iMinds island (2) Use linux bridge for the VLAN bridge Investigating RINA as an Alternative to TCP/IP 65 Additional configuration of the linux bridge required, but full control over the VLANs 66. Basic Experiment on iMinds island (3) Use Open vSwitch for the VLAN bridge Investigating RINA as an Alternative to TCP/IP 66 Additional configuration of the open vswitch required through the controller, but full control over the VLANs 67. Outline Use cases description, requirements analysis, refinement of RINA specifications and high- level software architecture Software implementation Experimentation and validation Demo of current prototype 67Investigating RINA as an Alternative to TCP/IP 68. 68 Kernel User space Netlink Netlink Netlink System calls System calls Netlink System calls Netlink Error and Flow Control Protocol Relaying and Multiplexing Task SDU Protection Shim IPC Process over Ethernet Device Drivers (VLAN) frame in/out Shim IPC Process over TCP/UDP Sockets layer TCP/UDP in/out Kernel IPC Manager Application process Application specific logic librina-sduprotection librina-application librina-fauxsockets IPC Process Daemon RIB Daemon & RIB librina-sduprotection librina-application librina-cdap librina-ipcprocess PDU Forwarding Table Generator Flow Allocator Enrollment Res. Alloc. IPC Process Daemon RIB Daemon & RIB librina-application librina-cdap librina-ipcprocess PDU Forwarding Table Generator Flow Allocator Enrollment Res. Alloc. librina-sduprotection librina-sduprotection IPC Manager Daemon RIB Daemon & RIB librina-application librina-cdap librina-ipcmanager Management Agent IDD IPC Manager main logic Config files CLI 69. Current status of implementation 69 librina-ipcmanager IPC Manager main logic Config files CLI IPC Manager Daemon Kernel User space Netlink Shim IPC Process over Ethernet Device Drivers (VLAN) frame in/out Kernel IPC Manager Linux ARP implementation RFC-compliant ARP ARP in/out Shim Dummy IPC Process (Local communication) Application process (rinaband) Application specific logic librina-application Netlink Application process (rinaband) Application specific logic librina-application System calls System calls System callsNetlink 70. Demo: single machine IPC via shim-dummy Validate IPC Manager librina-ipc-manager librina-application Kernel IPC Manager Shims architecture Netlink communications System calls Shim-IPC process over Ethernet almost ready Delayed due to the need of partially re-implementing ARP Linux implementation doesnt follow RFC, it is optimized assuming IPv4 will be the single user of the protocol Investigating RINA as an Alternative to TCP/IP 70 71. RINAband application used for testing Server-mode Registers an application entity (AE) Negotiates a test with a client, including: Number of flows SDUs sent for each flow Size of SDUs Who sents the SDUs (client/server/both) Investigating RINA as an Alternative to TCP/IP 71 72. 1) IPC Process creation, and assingment to DIF 72 librina-ipcmanager IPC Manager main logic Config files CLI IPC Manager Daemon Kernel User space Kernel IPC Manager Shim Dummy IPC Process (Local communication) 1. Create IPC Process (type, name, id) System call 2. Assign to DIF (DIF configuration) Netlink message Shim dummy instance 73. 2) Application registration 73 librina-ipcmanager IPC Manager main logic Config files CLI IPC Manager Daemon Kernel User space Kernel IPC Manager Shim Dummy IPC Process (Local communication) Shim dummy instance Registered_apps: rina_band Application process (rinaband server) Application specific logic librina-application 1. Register app (app_name, [dif_name]) NL message 3. Register app (app_name, dif_name) NL message 2. Check permissions and select DIF(s) If app didnt provide DIF names 4. Register app resp (code) NL message 5. Register app resp (code) NL message 74. 3) Flow Allocation (II) 74 librina-ipcmanager IPC Manager main logic Config files CLI IPC Manager Daemon Kernel User space Kernel IPC Manager Shim Dummy IPC Process (Local communication) Shim dummy instance Registered_apps: rina_band Flows: 15, 24 Application process (rinaband server) Application specific logic librina-application Application process (rinaband client) Application specific logic librina-application 10. Allocate req result(code, port_id) NL message 9. Allocate req result (code) NL message 8. Positive allocate response, reply to source application 7. Allocate flow resp (port_id, code, notify_source) NL message 6. Allocate flow resp (port_id, code, notify_source) NL message 75. 4) Write SDU Investigating RINA as an Alternative to TCP/IP 75 Kernel User space Kernel IPC Manager Shim Dummy IPC Process (Local communication) Shim dummy instance Registered_apps: rina_band Flows: 15, 24 Application process (rinaband server) Application specific logic librina-application 1. write_sdu (15, buff, num_bytes) System call 2. Look for flow 15 and forward request to related IPC Process 3. Look what other port-id is related to flow 15 and post the SDU there 4. post_sdu(24, buff, num_bytes) 76. 5) Read SDU Investigating RINA as an Alternative to TCP/IP 76 Kernel User space Kernel IPC Manager Shim Dummy IPC Process (Local communication) Shim dummy instance Registered_apps: rina_band Flows: 15, 24 Application process (rinaband server) Application specific logic librina-application 1. read_sdu (24, buff, max_bytes) System call 2. Look for flow 24 and see if there are any SDUs waiting 77. 6) Flow deallocation 77 librina-ipcmanager IPC Manager main logic Config files CLI IPC Manager Daemon Kernel User space Kernel IPC Manager Shim Dummy IPC Process (Local communication) Shim dummy instance Registered_apps: rina_band Flows: 15, 24 Application process (rinaband server) Application specific logic librina-application Application process (rinaband client) Application specific logic librina-application 1. Deallocate flow (port_id) NL message 2. Deallocate flow (port_id) NL message 3. Deallocate flow and send response. Issue a flow deallocated notification for the other port_id of the flow 4. Flow deallocated (port_id, code) NL message 5. Flow deallocated (port_id, code) NL message 4. Deallocate response (code) NL message 5. Deallocate response(code) NL message 78. Investigating RINA as an Alternative to TCP/IP Thanks for your attention! More information at http://irati.eu You can follow the project at http://twitter.com/iratiproject