Update on IRATI technical work after month 6

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. – Doesn’t protect its SDUs when writing them to an N-1 DIF. – Doesn’t 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 specific events. • System calls (User space -> Kernel) – For user-originated atomic actions, or belonging to fast-paths, the definition of a set of system calls provides an efficient and less resource consuming approach for synchronous user to kernel dialogues (e.g. read/write operation) • Sysfs (Kernel configuration and monitoring) – It allows to configure 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

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 don’t 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 shouldn’t 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. It’s 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, it’s 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 – It’s 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 • It’s 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: – It’s limited to IP addresses – There’s no practical way to register another network address on top • Only IP assigned to the device is advertised – There’s 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 • I’t s C++ based – rinad: • Contains daemons and applications – IPC Manager and IPC Process daemons – A testing application (RINABand) • It’s 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) • It’s execution model is event-based • It’s 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 there’s 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

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

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 doesn’t 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 didn’t 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