Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

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

1.620 visualizaciones

Publicado el

There is often a requirement to interface a new
model to a legacy implementation by creating a shim between them to make the legacy appear as close to the new model as possible. This is a common exercise, usually fraught with frustrations, but here we find the exercise reveals fundamental aspects about nature of layers that were previously not well understood. Here we will be primarily concerned with creating a shim between RINA and IEEE 802.1q (VLANs). The Recursive InterNet Architecture (RINA) proposes a network architecture derived from the fundamentals of InterProcess Communication (IPC). This yields a recursively layered architecture of Distributed IPC Facilities (DIFs).

Publicado en: Tecnología, Empresariales
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

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

  1. 1. Unreliable inter process communication in Ethernet: Migrating to RINA with the shim DIF 15/10/13 Sander Vrijders, Dimitri Staessens, Didier Colle, Mario Pickavet Ghent University – iMinds Eleni Trouva, Eduard Grasa i2CAT John Day, Lou Chitkushev Boston University 1
  2. 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 15/10/13 2
  3. 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) 15/10/13 3
  4. 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 15/10/13 4
  5. 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 15/10/13 5
  6. 6. Examining the Ethernet Header  Ethernet II: specification released by DEC, Intel, Xerox (hence also called DIX Ethernet) Preamble MAC dest MAC src 802.1q header (optional) Ethertype Payload FCS Interfram e gap 7 bytes 6 bytes 6 bytes 4 bytes 2 bytes 42-1500 bytes 4 bytes 12 bytes 15/10/13 6
  7. 7. Examining the Ethernet header  IEEE 802.3 Frame Preamble MAC dest MAC src 802.1q header (optional) Length Payload FCS Interfram e gap 7 bytes 6 bytes 6 bytes 4 bytes 2 bytes 42-1500 bytes 4 bytes 12 bytes  Combined with IEEE 802.2 (LLC) DSAP SSAP Control Information 1 byte 1 byte 1-2 bytes M bytes (M>=0 ) 15/10/13 7
  8. 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 15/10/13 8
  9. 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 15/10/13 9
  10. 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 15/10/13 10
  11. 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 15/10/13 11
  12. 12. Architectural model Application Specific Tasks System (Host) System (Router) Appl. Process Other Mgt. Tasks IPC Mgt. Tasks Multipl exing SDU Protec tion IPC Resource Mgt. Mgmt Agemt Inter DIF Directory IPC Process Shim IPC Process DIF IPC Process Shim DIF over TCP/UDP Appl. Process Mgmt Agemt Shim IPC Process Shim IPC Process Shim DIF over Ethernet IPC API Data Transfer Data Transfer Data Transfer Data Transfer Relaying and Multiplexing SDU Protection State Vector State Vector State Vector SDU Delimiting Layer Management Data Transfer Control Transmission Transmission Transmission Control Control Control Retransmission Retransmission Retransmission Control Control Control Flow Control Flow Control Flow Control CACEP RIB Daemon RIB RIB Enrollment Authentication Flow Allocation CDAP Parser/Generator Resource Allocation Forwarding Table Generator Increasing timescale (functions performed less often) and complexity System (Host) IPC Process Mgmt Agemt Shim IPC Process
  13. 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 15/10/13 13
  14. 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/10/13 14
  15. 15. After flow allocation 15/10/13 15
  16. 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) 15/10/13 16
  17. 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 15/10/13 17
  18. 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 15/10/13 18
  19. 19. Placement of the different PMs 15/10/13 19
  20. 20. State diagram 15/10/13 20
  21. 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 15/10/13 21
  22. 22. Questions ? Sander Vrijders Internet Based Communication Networks and Services (IBCN) Department of Information Technology (INTEC) Ghent University - iMinds 15/10/13 22