Unreliable inter process communication in Ethernet: Migrating to RINA with the shim DIF

1. Unreliable inter process communication in Ethernet: Migrating to RINA with the shim DIF Sander Vrijders, Dimitri Staessens, Didier Colle, Mario Pickavet Ghent University – iMinds Eleni Trouva, Eduard Grasa i2CAT John Day, Lou Chitkushev Boston University

2. Communication between application processes • Not to be confused with communication between interfaces  TCP/IP !!! • Basic premise: All networking is inter process communication and IPC only • All communication goes through three phases: • Enrollment • Flow allocation • Data transfer

3. Enrollment • Creates/maintains/distributes/deletes the information within a layer that is needed to create instances of communication • Often ignored in the current internet architecture • Addresses, maximum packet size, … • More well-formed enrollment phases in IEEE 802.11 (WiFi) and IEEE 802.1q (VLAN)

4. Flow allocation • Creates/maintains/deletes the shared state between connection endpoint-ids necessary to support the functions of the data transfer phase • For unicast: between 2 communication processes • Also often ignored, forgotten • Without a flow allocation phase, all Protocol Data Units (PDUs) are implicitly accepted

5. Data transfer • The actual sending of data • In the current architecture the other phases are often skipped • Immediately skipping to data transfer causes unreliable inter process communication

6. Examining the Ethernet Header • Ethernet II: specification released by DEC, Intel, Xerox (hence also called DIX Ethernet)

7. Examining the Ethernet header • IEEE 802.3 Frame • Combined with IEEE 802.2 (LLC)

8. Ethertype • Identifies the syntax of the encapsulated protocol • Layers below need to know the syntax of the layer above • Layer violation! • Same for the protocol id in the IPv4 header

9. Consequences of using an Ethertype • Also means only one flow can be distinguished between an address pair • The MAC address doubles as the connection endpoint-id

10. Same problem with LLC? • Source and Destination Service Access Points (SAPs) are the connection endpoint-ids • Allow for more than one flow to be distinguished between two communicating nodes • Still fixed endpoints • All traffic will still be accepted

11. Recursive InterNet Architecture (RINA) • New internetwork architecture • Unified theory of networking • A layer = a distributed application that provides IPC over a certain scope, called a Distributed IPC Facility (DIF) • Recurse as much as needed • Can be configured to a certain policy

12. Architectural model Application Specific Tasks System (Host) System (Host) System (Router) Other Mgt. Tasks IPC Mgt. Tasks DIF IPC Resource Mgt. Multiplexing Inter DIF Directory SDU Protection Shim DIF over Ethernet Shim DIF over TCP/UDP IPC API Shim IPC Process Appl. Process Appl. Process IPC Process Mgmt Agemt IPC Process Shim IPC Process Shim IPC Process Mgmt Agemt IPC Process Shim IPC Process Mgmt Agemt Layer Management Data Transfer Data Transfer Control Transmission Control SDU Delimiting CACEP Transmission Control Enrollment Transmission Control RIB Daemon Authentication Data Transfer Flow Allocation State Vector Data Transfer State Vector Data Transfer Retransmission Control State Vector Retransmission Control Retransmission Control RIB Resource Allocation Relaying and Multiplexing CDAP Parser/Generator Flow Control Flow Control Flow Control Forwarding Table Generator SDU Protection Increasing timescale (functions performed less often) and complexity

13. Recursive InterNet Architecture • Recognizes the three phases all communication goes through! • Other advantages of RINA: • Inherent support for QoS • Multihoming and mobility • More secure

14. Flow allocation in RINA • Application A performs a flow allocation request • Application B responds to this request • Accept • Deny • If positive reply, a flow is created: • Port-id is assigned for further reference • Connection (with CEP-id) is maintained in lower layer while there is active data transfer

15. After flow allocation

16. Flow allocation in TCP/IP • UDP has the same problem as Ethernet • No flow allocation • “Well-known ports”  security risk • Either manual configuration needed for flow allocation • Or use of other protocols (for instance SIP) • TCP has an incomplete flow allocation phase • But, overloads the uses of the TCP port (port-id and CEP-id)  another security risk • So, no decoupling of the flow allocation (port-id) and data transfer phase (CEP-id)

17. Shim IPC process for 802.1q • Interfaces a new model to a legacy implementation  shim • Allows RINA DIFs to use it unchanged • Only provides the capability of a legacy layer • Simulates flow allocation

18. Shim IPC process over 802.1q • Spans a single Ethernet segment • VLAN id is shim DIF name: joining the VLAN is considered enrolling in the shim DIF • Uses Ethernet II: Only one user of the shim DIF • Reuses the Address Resolution Protocol (ARP) • In RINA knowing which application is available at what address(es) is part of enrollment • For DIFs with small scope it can be part of flow allocation, just broadcast the allocate request

19. Placement of the different PMs

20. State diagram

21. Conclusion • Creating the shim DIF over Ethernet reveals something about the nature of layers • For reliable inter process communication, three phases have to be present • Port-id and CEP-id have to be decoupled! • Port-ids seem to be a necessity for a clean separation of layers

22. Questions ? Sander Vrijders sander.vrijders@intec.ugent.be www.ibcn.intec.ugent.be Internet Based Communication Networks and Services (IBCN) Department of Information Technology (INTEC) Ghent University - iMinds