Transcript PowerPoint-presentatie - IRATI Investigating RINA as an Alternative

Unreliable inter
process
communication in
Ethernet: Migrating
to RINA with the
shim DIF
8/04/2015
Sander Vrijders, Dimitri
Staessens, Didier Colle,
Mario Pickavet
Ghent University – iMinds
Eleni Trouva, Eduard
Grasa
i2CAT
John Day, Lou Chitkushev
Boston University
1
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
8/04/2015
2
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)
8/04/2015
3
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
8/04/2015
4
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
8/04/2015
5
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
8/04/2015
6
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 )
8/04/2015
7
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
8/04/2015
8
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
8/04/2015
9
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
8/04/2015
10
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
8/04/2015
11
Architectural model
Application Specific
Tasks
System (Host)
System
(Router)
Appl.
Process
Other Mgt. Tasks
Appl.
Process
Mgmt
Agemt
System
(Host)
IPC Mgt. Tasks
Multipl
exing
SDU
Protec
tion
IPC
Resource
Mgt.
Mgmt
Agemt
Inter DIF
Directory
IPC
Process
DIF
IPC
Process
Mgmt
Agemt
Shim IPC
Process
Shim DIF
over TCP/UDP
Shim IPC
Process
Shim IPC
Process
Shim DIF
over Ethernet
IPC API
Data Transfer
DataTransfer
Transfer
Data
Data
Transfer
Relaying and
Multiplexing
SDU Protection
Layer Management
Data Transfer Control
State Vector
State Vector
State Vector
SDU Delimiting
IPC
Process
Transmission
Transmission
Transmission
Control
Control
Control
Retransmission
Retransmission
Retransmission
Control
Control
Control
Flow Control
Flow Control
Flow Control
RIB
Daemon
RIB
CACEP
Enrollment
Authentication
Flow Allocation
CDAP
Parser/Generator
Resource
Allocation
Forwarding Table
Generator
Increasing timescale (functions performed less often) and complexity
Shim IPC
Process
Recursive InterNet Architecture
 Recognizes the three phases all communication
goes through!
 Other advantages of RINA:
 Inherent support for QoS
 Multihoming and mobility
 More secure
8/04/2015
13
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
8/04/2015
14
After flow allocation
8/04/2015
15
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)
8/04/2015
16
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
8/04/2015
17
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
8/04/2015
18
Placement of the different PMs
8/04/2015
19
State diagram
8/04/2015
20
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
8/04/2015
21
Questions ?
Sander Vrijders
[email protected]
www.ibcn.intec.ugent.be
Internet Based Communication
Networks and Services (IBCN)
Department of Information
Technology (INTEC)
Ghent University - iMinds
8/04/2015
22