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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
After flow allocation
15/10/13
15

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.
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.
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.
Placement of the different PMs
15/10/13
19

20.
State diagram
15/10/13
20

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.
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
15/10/13
22